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, либо же принимают, но трафик не ходит. Есть решение?