Dmitry76

Добрый день. Помогите с extfilter/DPDK. Коротко по сути: два одинаковых по железу сервера. Один сервер работает, второй как бы тоже работает (в логах пишет про отсылку ресетов), но пакеты с уведомлениями с порта сендера по факту не отправляются. В дампе ничего. Карточка (intel I350) точно рабочая. выводил ее с dpdk, пинги ходят. Пробовал использовать другой интерфейс (встроенных две) - та же беда. Сервер выключал по питанию, не помогло. Куда копать, что делать? Отсылка не работает. UPD. testpmd показывает дропы: ---------------------- Forward statistics for port 2 ---------------------- RX-packets: 1 RX-dropped: 0 RX-total: 1 TX-packets: 26517880 TX-dropped: 40341723 TX-total: 66859603 UPD2. Разобрался. Мой затуп. Перепутал в конфиге порты интерфейсов. Было несоответствие: интерфейс отправки был прописан как приемный, а один из двух интерйейсов приема был прописан как передающий. Привет порты в порядок и работает.

@max1976 Спасибо. Заработало нормально. Вопрос общего плана: а как понять, что сервер нормально справляется с нагрузкой по процессору? Ведь по extfilter нагрузка видится максимальной и вроде как это нормально. Нет этих вот полок с ksoftirq как в классическом кернел форвардинге/роутинге.

@max1976 речь идет о hugepagesz*hugepages?

Здравствуйте. Помогите понять, почему extfilter вылетает на старте, если rx queue >1? CPU: E5-1650 v2 @ 3.50GHz (1 сокет 6 ядер), сетевая Intel 82599ES (2x10 Gbit). ядро стартует с crashkernel=auto rhgb quiet nopti isolcpus=1,2,3,4,5 default_hugepagesz=1G hugepagesz=1G hugepages=4 При настройках одной очереди работает, если добавляю вторую - вылет. Эта карта в dpdk не поддерживает очереди приема больше одной? Или я что-то пропустил? Извините, новичок в этом вопросе. Вот лог при двух очередях: [port 0] queues = 0,1; 1,2

И еще на тему mtu. При включенной опции unit_preallocate (которая нужна для правильного заполнения аттрибута NAS-Port), на все стартующие интерфейсы выставляется дефолтовый MTU 1500 б. При этом согласования LCP игнорируются. Можно исправить такое поведение?

Подскажите, пожалуйста, есть ли возможность использовать несколько сетей в одном именованном пуле? Конструкция, типа: 192.168.0.0/24,name=pool1 10.0.0.0/24,name=pool1 прокатит?

myth увы, но это ограничения для одного источника (клиента, мак, не важно). Надо что-бы общее ограничение было. Пока есть какие-то затыки с базой радиус и в случае резкого наплыва (допустим BRAS был перезагружен) возникают блокировки и после этого затыки. Надо, грубо говоря, для 500 клиентов сгенерировать Access-Request'ы не в течение секунды, а скажем, 30-60 сек.

Подскажите, как правильно реализовать вот такое бутылочное горлышко... Все просто: есть схема клиент->accel->radius. Надо обграничить количество запросов на авторизацию каким-то определенным значением. Именно средствами акцеля. Я понимаю, многие пользователи не смогут сходу авторизоваться (особенно в случае перезагрузки сервера и массовых переконнектов), но тем не менее на текущий момент нужна такая реализация. Как это правильно сделать? Вижу два варианта: 1) в настройках радиус-авторизации выставить параметр req-limit: req-limit - number of simultaneous requests to server (0 - unlimited). 2) выставить padi-limit в секции pppoe в ненулевое значение. Тогда количество ответов на PADI будет ограничено и,соотвественно меньше будет генерироваться запросов на авторизацию для тех клиентов которые прошли полную Discovery фазу с этим сервером. Интересует поведение акцеля для запросов, которые превышают. Они отбрасываются или ставятся в очередь (вроде, по второму варианту сессия уходит в состояние starting в статистике). Спасибо!

Добрый день! Какая-то странная ситуация с авторизацией по chap. accel (в продакшн сейчас 1.10.0) не отдает в CHAP Challnge поле Name, точнее он пустой: 14:05:21.884027 PPPoE [ses 0xde01] CHAP, Challenge (0x01), id 1, Value 223964e0c4e94031555b815a52420726, Name Согласно RFC1994 это недопустимо: Name The Name field is one or more octets representing the identification of the system transmitting the packet. There are no limitations on the content of this field. For example, it MAY contain ASCII character strings or globally unique identifiers in ASN.1 syntax. The Name should not be NUL or CR/LF terminated. The size is determined from the Length field. При этом в rp-pppoe в поле Name отдается hostname. Это для 99.99% клиентов не проблема и они со своими длинками и тплинками плевать хотели на пустой атрибут. Но есть 0.01% абонентов, которые используют, например Cisco ASA 5505 и которые строго следуют стандартам и авторизация не проходит. Есть ли решение?

А скажите, какие-то подвижки в реализации session backup есть? Вроде, и исходники есть (accel-pppd/backup), но кроме упоминания, что "soft - restart daemon softly, e.g. keep existing connections if session backup is enabled (default)" нет.

Подскажите, если в конфиге bras указаны два радиус сервера и в ходе сессии абонента отказывает тот, который дал для него access-accept, то аккаунтинг в interim-update будет отсылаться на второй радиус? Или это касается только стартов?

Эта штука не поломалась. То есть, это не бага, а фича. Дело в том, что новый аксель создает пользовательский интерфейс после того как прошла успешная авторизация. Другими словами, когда шлется access-request, то на этом этапе еще нет номера порта, поэтому шлется <NAS-Port 4294967295> <NAS-Port-Id ""> Делается, это для того, чтобы не создавать лишнюю нагрузку на ядро при ненужном создании/удалении интерфейсов для юзеров, у которых закрытые лицевые счета. Получить номер порта можно из Accounting-Request. Там уже есть правильная информация: <NAS-Port 1189> <NAS-Port-Id "ppp1189"> Так что если у вас биллинг завязан на этом атрибуте именно в аксесс реквесте, то придется понижать версию до 1.9.0 Ну или пинайте биллинг, пусть берут из акаунтинга.

Возможно. Я обновил версию (1.9.0 -> 1.10.2) и теперь у этого абонента разрыв по Acct-Terminate-Cause Lost-Carrier>. Ну это уже другое дело, уже понятно,в какую сторону копать.

Подскажите, в каком случае аццель в режиме IPOE (старт сессии по dhcp) может разрывать по причине <Acct-Terminate-Cause User-Request>. Случай с pppoe понятен - клиент прислал PADT, PPP канал разобрался. А в случае IPOE? Клиент не продлил аренду адреса, так?

Добрый день! Подскажите как выдавать в режиме IPOE отдельные честные адреса для клиентов? Режим такой: mode=L2 start=dhcpv4 ip-unnumbered=1 proxy-arp=1 attr-dhcp-client-ip=DHCP-Client-IP-Address attr-dhcp-router-ip=DHCP-Router-IP-Address attr-dhcp-mask=DHCP-Mask Допустим, что на сервере 192.168.0.1/24 Если серая сеть, то проблем нет - редиус отдал в аттрибутах данные для DHCP ответа, клиент принял и заработал через NAT. А вот отдать клиенту честный адрес /32 как правильно? Роутеры tp-link понимают, когда в ответе DHCP шлюз отдается 192.168.0.1 маска 255.255.255.0, а IP клиента, пусть 5.5.5.5. Но другие клиенты отказываются принимать такие параметры DHCP, либо же принимают, но трафик не ходит. Есть решение?

Подскажите, а можно ли сделать такую вещь, чтобы после освобождения порта (речь идет о ppp), он не сразу занимался следующим авторизовываемым абонентом, а по возможности держался свободным какой-то время? Биллинг жалуется, что иногда старт по новой сессии они видят раньше, что стоп по этому же порту от предыдущего юзера. В логах аццеля последовательность правильная: сначала юзер отвалился (например по lcp timeout), а потом на этот порт подключает следующего. И это в одну секунду. С учетом, что авторизация происходит примерно 100-120 мс, то теоретически может быть, что очередь на самом радиусе создается иногда не в том порядке.

Кажется, в точку. А именно, выключение мультитредовости.По большому счету для accel оно не нужно, точнее нужно самому userspace процессу. Пока полет нормальный. Релоадил несколько раз - проходит нормально. Может, какие-то проблемы с межпроцессным взаимодействием, может у меня в конфиге что-то накручено - не знаю. Работет, наблюдаю.

Версия стоит 1.10.0 последний релиз. Такой же баг получался и если непосредственно делать в телнете акцеля (2000 порт). Через accel-cmd попробую.

Хотел бы уточнить, почему изредка при попытке перечитать конфиг акцеля (подавая команду reload в cli или через tcp) в ответ тут же отдается "failed". Но самое печальное при этом, что процесс вываливается из памяти вместе со всеми абонентами (сначала виден как <defunc>, и потом и следа его нет). После перезапуска - все ок. [root@acc45 ~]# echo "reload"|nc 127.0.0.1 2001 failed root@acc45 ~]# echo "pppoe interface show"|nc 127.0.0.1 2001|awk '{ SUM += $2} END { print SUM }' 0 [root@acc45 ~]# ps ax|grep acc 1832 ? Zsl 3050:51 [accel-pppd] <defunct>

Аксель 1.10.0 CentOS release 6.6 (Final) kernel 3.18.19 С дитрибутивным ядром были какие-то непонятки, проявляющиеся в отвале абонента. Особенно когда он начинал что-то качать. Вроде и LCP проходило, но сессия по нагрузкой долго не жила. Поэтому взял с kernel.org исходники ядра из ветки longterm и не 4. Полет нормальный. Пока таких сервера 4. В работе с августа. Что касается IPOE режима, пока нет статистики, в наличие только один сервер с 200 онлайна. У того вообще год аптайма.

Уже писали, что зависит от железа/системы. На практике по п.1 у меня 7000/700kpps7Gbps Centos 6.7 + Xeon E5-1650 v3 @ 3.50GHz + Intel 82599ES 10-Gigabit Но уже почти в упор по железу.

Почему не используете telnet? printf "password\rshow sessions match username login\rexit\r" | nc 172.31.0.1 2000 Оно понятно, что можно телнет. Его я и использую, но операторы просто взяли скрипт с сервера с rp-pppoe и он заработал как-есть. Потом я обновил и опа, поломалось. Ну да ладно, подправлю скрипт. Еще один момент: Было в логах: accel-pppd: ppp5010:: disconnected Стало: accel-pppd: :: disconnected Перестал указываться интерфейс. Если это фича, то, может, есть смысл вообще убрать эту строчку из логов, она уже не несет никакой смысловой нагрузки, а логи нагружает. UPD: По поводу disconnected понял. Это в случае, когда нет успешной авторизации и интерфейс еще не создан на этом этапе, поэтому не пишет. Это в новой версии так (выше на странице писали). Если простое завершение сессии, то пишет нормально, с именем интерфейса.

Еще один момент, относительно 1.10.0 В новом релизе модуль pppd_compat создает файлы radattr c правами доступа 600 (rw--), а предыдущий делал 644(rw r r). Операторы написали маленький скрипт себе в помощь для диагностики абонентов, он читал данные оттуда, брал значения шейперов, считал скорость и т.п. Теперь возникли проблемы с доступом. Понятно, что есть sudo, но такое наблюдение. Бага или фича - хз, как посмотреть.

Закомментировал "service-name" и взлетело. Пусть принимает любые запросы от клиента, мне не жалко. :-) Оставлю на выходные понаблюдать, а потом видно будет. Пока нра.

Максимум 1492.