[Abram]

linx,

Зачем так делать?

[linx]

в основном из-за билинга, т.к. билинг не может передать в каком вилане будет абонент и в какой сети. accel - в связке с dhcp как понял решит эту проблему, шейпер будет уже выше на nat сервере, куда придут абоненты с 2-х билингов - это как раз lisg (почему нат тут - из-за физического расположения сети + железо производительнее в разы)

[kayot]

linx

У ацеля есть свой шейпер, управляемый по радиусу. По идее биллингу все равно.

Смысл еще и lisg в этой схеме теряется, проще вместо него чистый NAT-бокс поставить.

[linx]

у accel-pptpd с шейпером не так все просто, на исходящую скорость нужен ifb если судить по документации http://accel-ppp.org/wiki/doku.php?id=ru:shaperbasic

lisg - по шейперу достаточно расписано и вроде все что нужно есть

 

чистый нат-бокс не получится, хотя бы по той причине что где терминируются пользователи и где поднято bgp с магистралом и сорм географически разнесены, не могу на месте натить хотя бы той причине что нужно дотащить пользователей до зеркала с сормом

 

ps. хотя по-любому придется начинать от обратного т.е. с accel-ppptpd - и если по шейперу не сложится, подниму lisg (в качестве шейпера) на nat-ах

Изменено 5 февраля, 2015 пользователем linx

[dazgluk]

Коллеги, добрый день.

 

Изучаем функционал LISG, собрали последнюю версию, с радиусом завязали.

Возник вопрос, поддерживается ли функционал скачивания сервисов по RADIUSу?

[Abram]

Скачивание сервисов по радиусу? Это как?

[dazgluk]

Скачивание сервисов по радиусу? Это как?

Ну, то есть сначала проходит запрос на авторизацию сессии, радиус отдает сервисы.

Затем, в случае если ISG не знает сервиса, (не занесен в конфиге), он делает запрос к серверу по этому сервису, и получает в ответ описание.

Это нужно для того, чтобы не заводить все возможные сервисы на всех брасах, а забирать их динамически с биллинга.

Плюс ко всему, у нас биллинг отдает разные скорости на один и тот же сервис в зависимости от времени суток.

[Igor Diakonov]

Скачивание сервисов по радиусу? Это как?

Это, видимо, вот так http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/isg/coa/guide/isg_ig/isgcoa3.html#wp1113141

[Abram]

Во как.

Нет, не умеет.

[~pavel~]

Кто-нибудь может подсказать как поменять скорость на сервисе или поменять активный сервис без потерь???

 

Если сначала деактивировать сервис, а потом активировать другой, то при этом трафик все-таки теряется.

 

есть какой-нибдь еще вариант???

[Ivan Rostovikov]

Вроде есть возможность описать неактивный сервис и по CoA активировать его.

 

Такой вопрос:

Стоял LISG, все работало.

В какой то момент (когда именно понять не удается) перестал резать скорость.

Авторизация происходит нормально. А вот скорость не режет.

Куда копать ?

[tvremtoh]

А реально ли изменение ограничения скорости шейпера на лету с помощью СоА ? Вроде как автор рекомендует для идентификации сессии использовать 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 менять параметры очереди , но хочется красиво через СоА .

[seagull]

Вопрос по производительности с 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

[kayot]

Для этого старенького сервера 200к pps и так подвиг можно сказать. Особенно в такой хитрой схеме.

Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе.

Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть. По топу загрузка разделится менее красиво, но станет реальной и системе полегче будет.

Ну и дальше, поставьте еще одну двухголовую карту и сделайте 2 нормальных бонда, на вход и на выход. Раскидайте 4 сетевки на 4 ядра - сервер вздохнет свободно.

 

2ух головая ET по ссылке вам конечно тоже хорошо поможет, но еще лучше - как я и говорил любая 2ух портовая карта(лучше тот же броадком, или intel PT), что б 4 порта сделать.

Изменено 29 марта, 2015 пользователем kayot

[seagull]

Главная печаль у вас в 2 сетевках и неприбитых прерываниях. Кто сказал что размазать по всем ядрам это правильно?? Это не более чем самообман и иллюзия свободного CPU в топе.

Для начала прибейте прерывания к ядрам на одной пластине, топологию для вашей системы думаю найдете как поглядеть.

Хм, а не будут 2 ядра вхолостую молотить? Сетевки то с одной очередью, только 2 ядра получится занять?

[kayot]

seagull

Дык в том то и дело, что сетевки с 1 очередью.

Они и сейчас только 2 ядра занимают, но т.к. вы разрешили использовать все ядра - планировщик постоянно перекидывает обработку прерывания между ядрами, в итоге в 1 момент времени используется 1 ядро на 100%, а кроме того получаем снижение производительности из-за необходимости синхронизации разных CPU и вымывания кешей. Хотя в топе все красиво.

[seagull]

kayot, ок, понял, прерывания прибил, сегодня вечером, если нагрузка будет, посмотрю на результат...

Вообще, уже по случаю заказали за недорого две таких ЕТ, как по ссылке, так что будем апгрейдится.

А подскажите, как с 4 портами будет оптимальней сконфигурить?

Я так понимаю - 2 бонда - аплинк и даунлинк, к ядру прибиваем RX от аплинка, TX от даунлинка? Бондинг сам по себе тут не будет проблем создавать? Ведь хрен знает, в какой канал у нас пакет прилетит?

 

А вообще интересно - сколько можно выгадать таким шаманством? Единицы процентов? Десятки?

Или собирать мелочь, и покупать что-то вроде http://shop.nag.ru/catalog/02275.Servery-HP/09193.360-G6-380-G6/14979.DL360G6_2xX5650_48GB чтобы уже очереди на 12 ядер раскидывать, а не на 4?

[kayot]

4 порта нужно привязать к 4 ядрам естественно. Очереди лучше вообще отключить, оставив 1 сокращённую(совмещенную, Т9) на порт(почему я предлагал дешёвые карты ставить, но если деньги на ЕТ есть - хуже точно не будет).

Выиграть в вашей конфигурации можно раза в 3, чётко будет до 2г дуплекса пролезать.

Изменено 2 апреля, 2015 пользователем kayot

[seagull]

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...

[~pavel~]

kayot, докладываю ситуацию :)

Вчера наблюдал общий трафик на бонде 1.46G.

Соответственно, в влане на абонов - 1.07G/0.4G, 116/85kpps.

LA не поднимался существенно.

 

Ошибок на интерфейсах тоже нет?

[seagull]

Ошибок на интерфейсах тоже нет?

 

Ну сейчас на 12 миллиардов пакетов на одном интерфейсе 512 дропов, на другом 30.

Так что можно сказать - нет...

[dazgluk]

Протестировали модуль на одном из НАТ серверов.

Машинка 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? Есть некоторое количество финансов, могли бы оплатить время разработчика, организовать стенд для тестирования.

[ttttt]

В packet forwardingе ядра тоже локи и тоже все довольно печально с производительностью. Так еще и все эти софтинки вместе ну просто очень неоптимальны. Профита будет чуть больше, чем ничего.

Ну реально, чуть-чуть лучше, чуть-чуть хуже - разве от этого что-то изменится?

Если уже вкладывать, то пора это все под netmap переписывать, под современные процессоры.

Изменено 16 апреля, 2015 пользователем ttttt

[dazgluk]

Произвоидительность Линуксового packet forwardingа нам известна :)

Рядом стоит идентичный сервер, делает все тоже самое NAT, Netflow, NFQ но без LISG.

Производительность там хоть и не высокая, но все же вполне линейно масштабируется, и к слову, ipt_netflow после доработок, там кушает всего 3-5%

 

Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ. Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки.

Не хотелось бы все переписывать.

[ttttt]

Учитывая стоимость серверов, главное чтоб софт линейно масштабировался по нагрузки.

Не понял этой вашей фразы. Вы тоже согласны, что глупо что-то переписывать ради микро профита? Это как раз о lisg.

А что такое линейное масштабирование софта? Вы же хотите полку чуть-чуть отодвинуть оптимизацией и все, не называл бы это линейной масштабируемостью.

 

Переписывать сетевой стек на NETMAP, это как минимум другой порядок по объему работ.

Шейпер, полисер, классификатор, нэтфлоу и даже НАТ - это задачи, где сетевой стэк ОСи как бы и не нужен совсем. Пространство для оптимизаций просто огромное.