hsvt Опубликовано 9 ноября, 2015 (изменено) · Жалоба Гасит, если с опцией 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. Изменено 9 ноября, 2015 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martini Опубликовано 9 ноября, 2015 · Жалоба option82 - не должна присутствовать в юникаст запросе, в этом вся беда ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dmitry76 Опубликовано 10 ноября, 2015 (изменено) · Жалоба Ну пока нагрузка была меньше(до 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). На втором сервере пока нормально. Изменено 10 ноября, 2015 пользователем Dmitry76 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
adeep Опубликовано 11 ноября, 2015 · Жалоба Ядро 4.2 Аццель 1.9.0 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 11 ноября, 2015 · Жалоба На 3.18.10 список вызовов был другой, но суть та же, паника без внятного описания виновника. В следующий раз сфоткаю, не догадался. Тут ругались в основном на новые ядра и ppp, но падает и на старых и на IPOE.. На машине кроме accel 1.9.0 нет ничего, никаких квагг или бирдов. vlan_monitor не используется, статически поднято ~5k вланов. L2, vlan-per-user + proxy arp. Шейпер встроенный не используется. Падало оба раза вечером, в час пик, при ~2.5к сессий. Но иногда бывает и до 3к, падений нет. Виновником видится только accel. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 11 ноября, 2015 · Жалоба accel-pppd без ipoe и vlan-monitor - обычное userspace ПО и падение ядра это баг ядра. Ставьте последнее с kernel.org, ванильное, делай фото и netconsole и пишите в netdev@ За вас никто не напишет И вообще по скрину видно, что проблема в conntrack, лучше им сразк и написать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 11 ноября, 2015 · Жалоба s.lobanov Т.е. accel без ppp/ipoe модулей не может систему уронить? А proxy arp его? Просто модификация arp-таблицы из userspace? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
byteplayer Опубликовано 11 ноября, 2015 · Жалоба Уважаемые коллеги. Может кто выскажет свои соображения, какая связка 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aak Опубликовано 12 ноября, 2015 · Жалоба Прекраснейший 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" (вижу в логах). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zlolotus Опубликовано 13 ноября, 2015 · Жалоба Коллеги, soft shutdown нормально отрабатывает? Может вызывать панику ядра? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 ноября, 2015 · Жалоба При soft shutdown вроде же просто перестают приниматься новые сессии? Причем он к ядру? К слову, похоже один из признаков бага ядра - LA при определенных условиях (массовый коннект к примеру) подскакивает и потом не падает ниже некоторой величины (0.5-1-2-3) даже ночью. На 4.1.12 вроде это рассосалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 13 ноября, 2015 · Жалоба Поделюсь своими наработками: 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 В принципе его можно заставить рестартовать процесс, а то и весь сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Maksel Опубликовано 15 ноября, 2015 · Жалоба К слову, в последнем срезе при указанном в конфиге 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 или нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 15 ноября, 2015 · Жалоба Подскажите, ни у кого на ядре 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 ноября, 2015 · Жалоба 4.1.12 попробуйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 15 ноября, 2015 · Жалоба 4.1.12 попробуйте. Да я бы из testing 4.2.0 попробовал.. займусь на днях. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 15 ноября, 2015 · Жалоба disappointed Не пробуйте ядра с '0' ревизией, шансы поймать на своей шкуре все внесенные баги при форке новой ветки ооочень велики :) Вероятно будет то же что и с 3.16.0 Лучше соберите руками 3.18.24 или 4.1.13 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 15 ноября, 2015 · Жалоба 3.16.0 это не 0, просто в дебиан их так называют Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
disappointed Опубликовано 15 ноября, 2015 · Жалоба 3.16.0 это не 0, просто в дебиан их так называют Попробовал сейчас 4.2.5 из репозитория тестинг, продержалось 15 минут и ушло в ребут. Кошмар какой-то, трейса удалённо не получил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
telecom Опубликовано 16 ноября, 2015 · Жалоба Подскажите, ни у кого на ядре 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 и использовать самосборные ядра, отключая все не нужное. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dmitry76 Опубликовано 16 ноября, 2015 · Жалоба Поделюсь своими наработками: 9k юзеров, под десяток pppoe, изредка зависали (переставали принимать новые сессии). 9k - это онлайн? Можете поделится информацией какой трафик при этом и на каком железе BRAS собран. У меня 6500, трафик в пиках до 6 Гбит (3 средний за сутки). Проц Xeon E5-1650 v3 @ 3.50GHz. 6 ядер. Прерывания разложены через smp_affinity, ну и RPS само собой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 16 ноября, 2015 · Жалоба трейса удалённо не получил. tty на rs232, ну и minicom с журналированием в лог-файл... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 17 ноября, 2015 · Жалоба На днях обновил сервер, с версии 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 17 ноября, 2015 · Жалоба А насколько стабильна нынешняя версия accel из git'a? Кто-то в продакшене использует? Надо обновлять свою 1.9.0, да как-то страшно, мало ли чего там за год сломалось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nik247 Опубликовано 17 ноября, 2015 (изменено) · Жалоба Юзаю на боевом: 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 Изменено 18 ноября, 2015 пользователем nik247 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...