Перейти к содержимому
Калькуляторы

Гасит, если с опцией 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.

Изменено пользователем hsvt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну пока нагрузка была меньше(до 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). На втором сервере пока нормально.

Изменено пользователем Dmitry76

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

s.lobanov

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Может кто выскажет свои соображения, какая связка 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Прекраснейший 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" (вижу в логах).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К слову, в последнем срезе при указанном в конфиге 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 или нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, ни у кого на ядре 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4.1.12 попробуйте.

Да я бы из testing 4.2.0 попробовал.. займусь на днях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

disappointed

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, ни у кого на ядре 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 и использовать самосборные ядра, отключая все не нужное.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

На днях обновил сервер, с версии 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.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем nik247

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.