Jump to content
Калькуляторы

Гасит, если с опцией 82 юзать.

 

Так и юзаем, только start=up, а адреса раздаёт DHCP от LB. Все пакеты приходят юникастом с option82 через DHCP Relay от D-Link. (policy keep)

 

Но есть одна проблема, заключается она в том, что DHCP сервер проверяет только активную лизу для данного MAC адреса и выдаёт адрес без проверки option82, поэтому взяв чужую лизу так же получаем два одинаковых адреса и доступ. Биллинг объясняет это тем, что это было сделано в силу причин rfc, где option82 не обязана присутствовать в запросе REQEUST, этим начали пользоваться некоторые производители оборудования, в частности некоторые модели D-Link, а именно - в первоначальный запрос option 82 вставляется, а во всех последующих запросах на продление аренды она отсутствует. Хотя сейчас на наших D-Link она присутствует во всех запросах, но на других вендорах не включается option82 в REQUEST.

Edited by hsvt

Share this post


Link to post
Share on other sites

option82 - не должна присутствовать в юникаст запросе, в этом вся беда )

Share this post


Link to post
Share on other sites

Ну пока нагрузка была меньше(до 2к сессий) у меня этот же сервер работал порядка года без сбоев и проблем, с разными ядрами. С 3.10.10-3.10.33(время от времени обновлял порядка ради) точно работало без нареканий.

падать начинает при сессиях гдето 1.5-1.6к+ до этого значения на любом ядре было отлично.

У меня держался на 6500 онлайна, однако поймал непонятный клин (в логах ошибок нет) после чего начал сбрасывать понемногу юзеров с сообщением lcp: no echo reply. Причем, новых авторизаций не принимал. Такое впечатление, что soft shutdown сделали, но это не так. Заметил, что онлайн начал плавно снижаться (за сутки c 6500 до 4500). Решилось перезапуском демона. Centos 6.6, ядро 3.18.19 (ванильное, с ветки longterm). На втором сервере пока нормально.

Edited by Dmitry76

Share this post


Link to post
Share on other sites

На 3.18.10 список вызовов был другой, но суть та же, паника без внятного описания виновника. В следующий раз сфоткаю, не догадался.

 

Тут ругались в основном на новые ядра и ppp, но падает и на старых и на IPOE..

 

На машине кроме accel 1.9.0 нет ничего, никаких квагг или бирдов.

vlan_monitor не используется, статически поднято ~5k вланов. L2, vlan-per-user + proxy arp.

Шейпер встроенный не используется.

Падало оба раза вечером, в час пик, при ~2.5к сессий. Но иногда бывает и до 3к, падений нет.

 

Виновником видится только accel.

Share this post


Link to post
Share on other sites

accel-pppd без ipoe и vlan-monitor - обычное userspace ПО и падение ядра это баг ядра. Ставьте последнее с kernel.org, ванильное, делай фото и netconsole и пишите в netdev@ За вас никто не напишет

 

И вообще по скрину видно, что проблема в conntrack, лучше им сразк и написать

Share this post


Link to post
Share on other sites

s.lobanov

Т.е. accel без ppp/ipoe модулей не может систему уронить?

А proxy arp его? Просто модификация arp-таблицы из userspace?

Share this post


Link to post
Share on other sites

Уважаемые коллеги.

Может кто выскажет свои соображения, какая связка kernel + accel-ipoe считается самой стабильной для продакшена?

Я по постам как бы понял, что это kernel 3.2.x + accel-1.9.0, но может я неправильно думаю?

Например, поставить Wheezy 7.x + готовые пакеты accel под него с сайта разработчика -- так?

Схема L2-shared без QinQ с простым ip_unnumbered + NAT.

Адреса раздаёт dhcp-модуль freeradius по MAC либо option 82.

Share this post


Link to post
Share on other sites

Прекраснейший utm5-radius отправляет имя пула для выдачи адреса не атрибутом Framed-Pool, а через Cisco-AVPair "ip:addr-pool=POOLNAME" и, видимо, поэтому при подключении accel-ppp пишет в лог ppp: no free IPv4 address, несмотря на то что пул с таким именем в конфиге объявлен.

Можно ли это учесть?

 

Так они эту фичу реализовали или нет? На днях поcтавил,пытался завести,чтобы на 2 pppoe-сервера (с циской без групп с разными аттрибутами) работало,но в логи сыпет 'ppp: no free IPv4 address' и не коннектит.

 

 

[ip-pool]
vendor=Cisco
attr=Cisco-AVPair
X.X.X.X/X,name=POOLNAME

 

нифига не работает,хоть радиус и отдает Cisco-AVPair "ip:addr-pool=POOLNAME" (вижу в логах).

Share this post


Link to post
Share on other sites

Коллеги, soft shutdown нормально отрабатывает?

 

Может вызывать панику ядра?

Share this post


Link to post
Share on other sites

При soft shutdown вроде же просто перестают приниматься новые сессии? Причем он к ядру?

 

К слову, похоже один из признаков бага ядра - LA при определенных условиях (массовый коннект к примеру) подскакивает и потом не падает ниже некоторой величины (0.5-1-2-3) даже ночью.

На 4.1.12 вроде это рассосалось.

Share this post


Link to post
Share on other sites

Поделюсь своими наработками:

9k юзеров, под десяток pppoe, изредка зависали (переставали принимать новые сессии).

Свежайший патч под последнее ядро http://marc.info/?l=linux-netdev&m=144661317420454&w=2

После него остались только очень редкие паники в conntrack, лишь на одном из серверов.

 

Еще что помогло от зависаний accel-ppp:

"unit-cache=2000", хотя думаю дело не в кешировании, а в том, что когда оно включается, я видел, что включаются какие-то locks в accel, возможно это делает race conditions менее вероятными.

 

И последняя мера, мониторю accel с помощью mmonit:

monitrc

....

check program pppoelife with path "/usr/local/bin/pppoealive" timeout 10 seconds

if status != 0 then alert

....

giantpppoe4 ~ # cat /usr/local/bin/pppoealive

#!/bin/sh

accel-cmd show stat

 

В принципе его можно заставить рестартовать процесс, а то и весь сервер.

Share this post


Link to post
Share on other sites

К слову, в последнем срезе при указанном в конфиге service name абоны с пустым service name игнорятся - неплохо было бы это сделать опциональным.

 

 

Просмотрел посление посты, не увидел решения.

Это очень актуально, к примеру в сети несколько серверов pppoe, для проверок нужно подключаться к конкретному.

Раньше было довольео просто при service-name=pr102, сервер принимал и конекты с пустым service name и pr102.

Теперь чтобы сервер начал принимать конекты абоненто, а у них как правили в пусто service name, приходится писать pppoe set Service-Name *,

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

Возвращаю pppoe set Service-Name pr102 - абоненты перестают подключаться.

 

Надо или вернуть как было, или сделать вкл-выкл. принимать сессия с пустым service name или нет?

Share this post


Link to post
Share on other sites

Подскажите, ни у кого на ядре 3.16.0 не было oops с отвалом сетевых интерфейсов?

 

У меня стоит связка pppd+rp-pppoe, первый раз oops был в апреле этого года, когда обновлял версию дистрибутива до stable,

с стоковым ядром 3.16.0 машина упала не проработав суток, чтобы не экспериментировать поставил постарее ядро из того же дистра - 3.2,

с ним всё классно работает но прерывания от карточки где ходит pppoe/l2 сливаются на одно ядро и RPS слабо помогает это исправить,

на 3.16.0 же прерывания уже отлично размазываются по всем ядрам, но всё портит внезапное падение машины..

Решил подождать полгода, думал что исправят баг.

 

Вчера снова попытался протестировать работу с 3.16.0 и снова машина внезапно срубилась в oops.

 

Мой дамп OOPS http://pastebin.com/BehztMDZ

Произошло в момент отключения ppp клиента.

 

Подобный чей-то с accel http://pastebin.com/3DhjaJmc

Share this post


Link to post
Share on other sites

disappointed

Не пробуйте ядра с '0' ревизией, шансы поймать на своей шкуре все внесенные баги при форке новой ветки ооочень велики :) Вероятно будет то же что и с 3.16.0

Лучше соберите руками 3.18.24 или 4.1.13

Share this post


Link to post
Share on other sites

3.16.0 это не 0, просто в дебиан их так называют

Попробовал сейчас 4.2.5 из репозитория тестинг,

продержалось 15 минут и ушло в ребут. Кошмар какой-то, трейса удалённо не получил.

Share this post


Link to post
Share on other sites

Подскажите, ни у кого на ядре 3.16.0 не было oops с отвалом сетевых интерфейсов?

 

У меня стоит связка pppd+rp-pppoe, первый раз oops был в апреле этого года, когда обновлял версию дистрибутива до stable,

с стоковым ядром 3.16.0 машина упала не проработав суток, чтобы не экспериментировать поставил постарее ядро из того же дистра - 3.2,

с ним всё классно работает но прерывания от карточки где ходит pppoe/l2 сливаются на одно ядро и RPS слабо помогает это исправить,

на 3.16.0 же прерывания уже отлично размазываются по всем ядрам, но всё портит внезапное падение машины..

Решил подождать полгода, думал что исправят баг.

 

Вчера снова попытался протестировать работу с 3.16.0 и снова машина внезапно срубилась в oops.

 

Мой дамп OOPS http://pastebin.com/BehztMDZ

Произошло в момент отключения ppp клиента.

 

Подобный чей-то с accel http://pastebin.com/3DhjaJmc

У меня связка из pppd+rp-pppoe работает годами без падений на 3.14, 3.18. В Вашем случае могу рекомендовать уйти на x64 и использовать самосборные ядра, отключая все не нужное.

Share this post


Link to post
Share on other sites

Поделюсь своими наработками:

9k юзеров, под десяток pppoe, изредка зависали (переставали принимать новые сессии).

9k - это онлайн? Можете поделится информацией какой трафик при этом и на каком железе BRAS собран.

У меня 6500, трафик в пиках до 6 Гбит (3 средний за сутки). Проц Xeon E5-1650 v3 @ 3.50GHz. 6 ядер. Прерывания разложены через smp_affinity, ну и RPS само собой.

Share this post


Link to post
Share on other sites

трейса удалённо не получил.

tty на rs232, ну и minicom с журналированием в лог-файл...

Share this post


Link to post
Share on other sites

На днях обновил сервер, с версии 1.7.че-то-там, до последней из гита. Сервер обслуживает pptp и l2tp.

По pptp все хорошо, вот с l2tp были заморочки.

Проблема с l2tp проявлялась на пользовательских маршрутизаторах, в accel-ppp.log летели сообщения

warn: l2tp: incorrect avp received (type=6, M=1, must be 0)
warn: l2tp: incorrect avp received (type=8, M=1, must be 0)

TP-Link и D-Link вообще не хотели подключаться, по консультации с xebом, вписал опцию avp_permissive еще не документированную.

[l2tp]
avp_permissive=1

Маршрутизаторы начали работать, пока без нареканий. Но все еще есть маршрутизаторы, на которых осталась проблема, в руки пока не попадались, как попадутся, отпишусь.

 

Решил провести эксперимент с 2 радиус серверами, точнее отделить acct от auth в секции radius.(Сервер по факту один)

server=10.0.0.1,secret,auth-port=1812,acct-port=0,req-limit=50,fail-timeout=0,max-fail=0
server=10.0.0.1,secret,auth-port=0,acct-port=1813,req-limit=0,fail-timeout=0,max-fail=0

Таким образом req-limit=50 указывается только для auth.

Share this post


Link to post
Share on other sites

А насколько стабильна нынешняя версия accel из git'a? Кто-то в продакшене использует?

Надо обновлять свою 1.9.0, да как-то страшно, мало ли чего там за год сломалось.

Share this post


Link to post
Share on other sites

Юзаю на боевом:

accel-ppp version 87ddec14232bec6d533a0bd337468a7e56de0b80 (от 2015-07-08 19:42:23)

 

accel-ppp# show stat

uptime: 90.07:27:04

cpu: 0%

 

Режим: IPoE (L2, shared) + pppoe. До 1000 клиентов.

#Linux nas02 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u2 i686 GNU/Linu

Edited by nik247

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now