Abram Опубликовано 4 февраля, 2015 · Жалоба linx, Зачем так делать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
linx Опубликовано 5 февраля, 2015 · Жалоба в основном из-за билинга, т.к. билинг не может передать в каком вилане будет абонент и в какой сети. accel - в связке с dhcp как понял решит эту проблему, шейпер будет уже выше на nat сервере, куда придут абоненты с 2-х билингов - это как раз lisg (почему нат тут - из-за физического расположения сети + железо производительнее в разы) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 5 февраля, 2015 · Жалоба linx У ацеля есть свой шейпер, управляемый по радиусу. По идее биллингу все равно. Смысл еще и lisg в этой схеме теряется, проще вместо него чистый NAT-бокс поставить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
linx Опубликовано 5 февраля, 2015 (изменено) · Жалоба у accel-pptpd с шейпером не так все просто, на исходящую скорость нужен ifb если судить по документации http://accel-ppp.org/wiki/doku.php?id=ru:shaperbasic lisg - по шейперу достаточно расписано и вроде все что нужно есть чистый нат-бокс не получится, хотя бы по той причине что где терминируются пользователи и где поднято bgp с магистралом и сорм географически разнесены, не могу на месте натить хотя бы той причине что нужно дотащить пользователей до зеркала с сормом ps. хотя по-любому придется начинать от обратного т.е. с accel-ppptpd - и если по шейперу не сложится, подниму lisg (в качестве шейпера) на nat-ах Изменено 5 февраля, 2015 пользователем linx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 5 февраля, 2015 · Жалоба Коллеги, добрый день. Изучаем функционал LISG, собрали последнюю версию, с радиусом завязали. Возник вопрос, поддерживается ли функционал скачивания сервисов по RADIUSу? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 5 февраля, 2015 · Жалоба Скачивание сервисов по радиусу? Это как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 5 февраля, 2015 · Жалоба Скачивание сервисов по радиусу? Это как? Ну, то есть сначала проходит запрос на авторизацию сессии, радиус отдает сервисы. Затем, в случае если ISG не знает сервиса, (не занесен в конфиге), он делает запрос к серверу по этому сервису, и получает в ответ описание. Это нужно для того, чтобы не заводить все возможные сервисы на всех брасах, а забирать их динамически с биллинга. Плюс ко всему, у нас биллинг отдает разные скорости на один и тот же сервис в зависимости от времени суток. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Igor Diakonov Опубликовано 5 февраля, 2015 · Жалоба Скачивание сервисов по радиусу? Это как? Это, видимо, вот так http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/isg/coa/guide/isg_ig/isgcoa3.html#wp1113141 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Abram Опубликовано 6 февраля, 2015 · Жалоба Во как. Нет, не умеет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
~pavel~ Опубликовано 18 февраля, 2015 · Жалоба Кто-нибудь может подсказать как поменять скорость на сервисе или поменять активный сервис без потерь??? Если сначала деактивировать сервис, а потом активировать другой, то при этом трафик все-таки теряется. есть какой-нибдь еще вариант??? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 20 февраля, 2015 · Жалоба Вроде есть возможность описать неактивный сервис и по CoA активировать его. Такой вопрос: Стоял LISG, все работало. В какой то момент (когда именно понять не удается) перестал резать скорость. Авторизация происходит нормально. А вот скорость не режет. Куда копать ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tvremtoh Опубликовано 23 марта, 2015 · Жалоба А реально ли изменение ограничения скорости шейпера на лету с помощью СоА ? Вроде как автор рекомендует для идентификации сессии использовать 4 атрибута и как бы говорит , что для главной сессии можно использовать Cisco-Account-Info="QU;512;256;D;512;256" .... Однако ограничение скорости сбрасывается лично у меня в ноль , новые параметры шейпера не устанавливаются . echo User-Name=10.10.14.161,Acct-Session-Id=EEF658C8352559ED,Nas-Port=4,Nas-Identifier="192.168.122.111",Cisco-Account-Info="QU;512;256;D;512;256"|/usr/local/freeradius/bin/radclient -x 10.10.10.2:3799 coa 5678 Может руки кривые ? Ткните носом че не так делаю . С консольки по типу /ISG.pl change_rate <Virtual# | Session-ID> <in_rate out_rate> все замечательно меняется . Уже задумался удаленно по SSH менять параметры очереди , но хочется красиво через СоА . Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 25 марта, 2015 (изменено) · Жалоба Вопрос по производительности с linux ISG. Сервер Proliant DL360G5, 1 x Intel® Xeon® CPU E5345 @ 2.33GHz, 4GB RAM. Сетевки встроенные, две Broadcom Corporation NetXtreme II BCM5708, driver: bnx2 version: 2.0.2 Собраны в бондинг, на бонде висят вланы, в сторону абонентов и на аплинк. Система Linux isg1 2.6.32-5-amd64 #1 SMP Mon Mar 26 07:00:19 UTC 2012 x86_64 GNU/Linux (знаю что старая, просто долгое время проблем не было, и не трогали :) Ядро ванильное, особо ничего не тюнили. lISG-0.11.3-alpha Дополнительно к ISG машина делает NAT и сливает netflow через ipt_netflow. Десяток правил проходят пакеты в iptables. Проблема такая. Когда общий трафик через бонд приближается к 1.4G в каждую сторону (например, 1G download + 400M upload у абонентов), резко растет загрузка процессора (число LA). Соответственно, растут пинги, сильно падает скорость у абонов, и прочее. Число абонентов в это время 1.2к, ~110kpps download + 90kpps upload в абонентском влане (соответственно, плюс столько же в аплинке). Что интересно - если трафик через бонд допустим 1.2G - то LA болтается в районе 0.00 - 0.01. Прерывания поделены вроде: root@isg1:~# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 --- 61: 314048990 314088388 313987066 313815289 PCI-MSI-edge eth0 62: 349329762 349279662 349388109 349542114 PCI-MSI-edge eth1 --- Сейчас нагрузка на бонде 650Mbps, top показывает: Tasks: 98 total, 1 running, 97 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0%us, 0.0%sy, 0.0%ni, 80.4%id, 0.0%wa, 0.0%hi, 19.6%si, 0.0%st Cpu1 : 0.0%us, 0.7%sy, 0.0%ni, 76.8%id, 0.0%wa, 0.0%hi, 22.5%si, 0.0%st Cpu2 : 0.3%us, 0.3%sy, 0.0%ni, 75.7%id, 0.0%wa, 0.3%hi, 23.3%si, 0.0%st Cpu3 : 0.3%us, 0.3%sy, 0.0%ni, 81.7%id, 0.0%wa, 0.0%hi, 17.6%si, 0.0%st Основные пожиратели процессорного времени - ksoftirqd и events. Внимание, вопрос! Куда бежать? Тюнить ядро? Обновлять ядро? Покупать нормальную сетевку типа http://shop.nag.ru/catalog/00006.Servery/02273.Setevye-karty/11473.E1G42ET ? Или расслабиться, и это предел данного сервака? Изменено 26 марта, 2015 пользователем seagull Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 29 марта, 2015 (изменено) · Жалоба Для этого старенького сервера 200к pps и так подвиг можно сказать. Особенно в такой хитрой схеме. Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе. Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть. По топу загрузка разделится менее красиво, но станет реальной и системе полегче будет. Ну и дальше, поставьте еще одну двухголовую карту и сделайте 2 нормальных бонда, на вход и на выход. Раскидайте 4 сетевки на 4 ядра - сервер вздохнет свободно. 2ух головая ET по ссылке вам конечно тоже хорошо поможет, но еще лучше - как я и говорил любая 2ух портовая карта(лучше тот же броадком, или intel PT), что б 4 порта сделать. Изменено 29 марта, 2015 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 30 марта, 2015 · Жалоба Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе. Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть. Хм, а не будут 2 ядра вхолостую молотить? Сетевки то с одной очередью, только 2 ядра получится занять? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 марта, 2015 · Жалоба seagull Дык в том то и дело, что сетевки с 1 очередью. Они и сейчас только 2 ядра занимают, но т.к. вы разрешили использовать все ядра - планировщик постоянно перекидывает обработку прерывания между ядрами, в итоге в 1 момент времени используется 1 ядро на 100%, а кроме того получаем снижение производительности из-за необходимости синхронизации разных CPU и вымывания кешей. Хотя в топе все красиво. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 30 марта, 2015 · Жалоба kayot, ок, понял, прерывания прибил, сегодня вечером, если нагрузка будет, посмотрю на результат... Вообще, уже по случаю заказали за недорого две таких ЕТ, как по ссылке, так что будем апгрейдится. А подскажите, как с 4 портами будет оптимальней сконфигурить? Я так понимаю - 2 бонда - аплинк и даунлинк, к ядру прибиваем RX от аплинка, TX от даунлинка? Бондинг сам по себе тут не будет проблем создавать? Ведь хрен знает, в какой канал у нас пакет прилетит? А вообще интересно - сколько можно выгадать таким шаманством? Единицы процентов? Десятки? Или собирать мелочь, и покупать что-то вроде http://shop.nag.ru/catalog/02275.Servery-HP/09193.360-G6-380-G6/14979.DL360G6_2xX5650_48GB чтобы уже очереди на 12 ядер раскидывать, а не на 4? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 марта, 2015 (изменено) · Жалоба 4 порта нужно привязать к 4 ядрам естественно. Очереди лучше вообще отключить, оставив 1 сокращённую(совмещенную, Т9) на порт(почему я предлагал дешёвые карты ставить, но если деньги на ЕТ есть - хуже точно не будет). Выиграть в вашей конфигурации можно раза в 3, чётко будет до 2г дуплекса пролезать. Изменено 2 апреля, 2015 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 2 апреля, 2015 · Жалоба kayot, докладываю ситуацию :) Вчера наблюдал общий трафик на бонде 1.46G. Соответственно, в влане на абонов - 1.07G/0.4G, 116/85kpps. LA не поднимался существенно. Для интересующихся - вот что вообще затюнено было: #CONNTRACK tuning: echo 524288 > /sys/module/nf_conntrack/parameters/hashsize echo 524288 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max echo 1024000 > /proc/sys/net/netflow/sndbuf /sbin/sysctl -w net.core.rmem_default=262144 /sbin/sysctl -w net.core.wmem_default=262144 # /sbin/sysctl -w net.core.rmem_max=8388608 /sbin/sysctl -w net.core.wmem_max=8388608 ifconfig eth0 txqueuelen 10000 ifconfig eth1 txqueuelen 10000 ethtool -G eth0 rx 1020 ethtool -G eth1 rx 1020 /sbin/sysctl -w net.netflow.hashsize=800000 sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=1800 sysctl -w net.netfilter.nf_conntrack_generic_timeout=180 sysctl -w net.netfilter.nf_conntrack_udp_timeout=10 sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60 sysctl -w net.netfilter.nf_conntrack_icmp_timeout=10 echo 4 > /proc/irq/61/smp_affinity echo 8 > /proc/irq/62/smp_affinity ethtool -C eth0 rx-usecs 40 ethtool -C eth1 rx-usecs 40 Кстати - интересный момент... smp affinity не применился, пока я не сделал для интерфейсов изменение параметров с ethtool... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
~pavel~ Опубликовано 2 апреля, 2015 · Жалоба kayot, докладываю ситуацию :) Вчера наблюдал общий трафик на бонде 1.46G. Соответственно, в влане на абонов - 1.07G/0.4G, 116/85kpps. LA не поднимался существенно. Ошибок на интерфейсах тоже нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
seagull Опубликовано 2 апреля, 2015 · Жалоба Ошибок на интерфейсах тоже нет? Ну сейчас на 12 миллиардов пакетов на одном интерфейсе 512 дропов, на другом 30. Так что можно сказать - нет... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 16 апреля, 2015 · Жалоба Протестировали модуль на одном из НАТ серверов. Машинка 2x Intel Xeon E5649, Intel X520-DA2, 8 гигов памяти На сервере запущено: NAT (1:1 и Overload) Conntrack Nfqueue, для фильтрации РКН ipt_netflow в ЧНН было 9555 сабскрайберных сессий генерящих 6,93+3.69 (10,62Gb/s трафика)@1,58Mpp/s и 816k записей в Conntrack. Модуль простоял двое суток под такой нагрузкой, и судя по всему это предел :( Как видно из графиков Начиная ~ с 10Gb/s in+out в логи начинаются сыпаться сообщения вида: [15193462.931241] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this) [15193464.562432] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this) [15193538.701591] ipt_ISG: ISG_IS_DYING is set, freeing (ignore this) И userspace ные Apr 3 17:09:24 nat-10g-4 kernel: [15192416.117801] ipt_ISG: Lost packet during sending data to listener (err=-11) Apr 3 17:09:24 nat-10g-4 kernel: [15192416.119128] ipt_ISG: Lost packet during sending data to listener (err=-11) Apr 3 17:09:24 nat-10g-4 kernel: [15192416.119941] ipt_ISG: Lost packet during sending data to listener (err=-11) Apr 3 17:09:24 nat-10g-4 kernel: [15192416.120452] ipt_ISG: Lost packet during sending data to listener (err=-11) И начинает лавинообразно расти загрузка CPU Мы не смогли посмотреть состояние непосредственно в момент проблемы, но ~ в 23.30 Perf top выглядел следующим образом 11.99% [kernel] [k] _raw_spin_lock_bh 5.07% [kernel] [k] ipt_do_table 4.64% [kernel] [k] netflow_target 4.55% [kernel] [k] _raw_spin_lock 3.80% [kernel] [k] ____nf_conntrack_find 3.39% [kernel] [k] ixgbe_clean_rx_irq 2.99% [kernel] [k] _raw_read_lock Похоже, архитектура модуля упирается в количество локов, мы пытались крутить параметр nehash_key_len, однако судя по всему он не имеет отношения к локам внутри ipt_isg. Машина у нас конечно не лучшая, 12 не сильно быстрых ядер, да еще и SMP но тем не менее без ISG, она спокойно жует 15-16Gb/s трафика и кладет в полку интерфейс по входящему направлению без существенных дропов и с 15% запасом по CPU/ С подобной проблемой LOCKов мы сталкивались, когда тестировали модуль IPT_netflow, тогда, силами AABC, его тогда удалось переписать :) Не смотря на не совсем удовлетворительное тестирование модуль нам весьма интересен, и не в ЧНН он работает вполне нормально, и авторизация (нам пришлось переписать User-space часть, т.к. наш биллинг умеет только Cisco command code) и CoA, и L4Redirect. Нагрузка модуля в нормальном режиме по тестам занимала +10% CPU от packet forwardingа ядра Linux и это на первый взгляд, сильно лучше чем Accel-ppp, который даже без сервисов, просто сожрал 10% CPU чтобы поделить трафик на сессии, и не совсем понятно поддерживает ли accel-ppp полисинг, т. к. шейпер кушает слишком много ресурсов. В связи с этим возникают вопросы, есть ли на текущий момент у модуля мейнтейнер? Интересно было бы переписать модуль под Lockless архитектру с целью увеличения производительности? Или проект уже мертв, и придется писать свое с нуля/таки пилить accel-ppp? Есть некоторое количество финансов, могли бы оплатить время разработчика, организовать стенд для тестирования. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 16 апреля, 2015 (изменено) · Жалоба В packet forwardingе ядра тоже локи и тоже все довольно печально с производительностью. Так еще и все эти софтинки вместе ну просто очень неоптимальны. Профита будет чуть больше, чем ничего. Ну реально, чуть-чуть лучше, чуть-чуть хуже - разве от этого что-то изменится? Если уже вкладывать, то пора это все под netmap переписывать, под современные процессоры. Изменено 16 апреля, 2015 пользователем ttttt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dazgluk Опубликовано 17 апреля, 2015 · Жалоба Произвоидительность Линуксового packet forwardingа нам известна :) Рядом стоит идентичный сервер, делает все тоже самое NAT, Netflow, NFQ но без LISG. Производительность там хоть и не высокая, но все же вполне линейно масштабируется, и к слову, ipt_netflow после доработок, там кушает всего 3-5% Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ. Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки. Не хотелось бы все переписывать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ttttt Опубликовано 17 апреля, 2015 · Жалоба Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки. Не понял этой вашей фразы. Вы тоже согласны, что глупо что-то переписывать ради микро профита? Это как раз о lisg. А что такое линейное масштабирование софта? Вы же хотите полку чуть-чуть отодвинуть оптимизацией и все, не называл бы это линейной масштабируемостью. Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ. Шейпер, полисер, классификатор, нэтфлоу и даже НАТ - это задачи, где сетевой стэк ОСи как бы и не нужен совсем. Пространство для оптимизаций просто огромное. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...