nsa2006

Есть такое дело, где то я читал что можно timeout где то в конфигурации подсунуть минимальный 1 сек, не идеал конечно но всё же быстрее. Вот нашёл! https://accel-ppp.org/forum/viewtopic.php?t=639 На тиках довольно быстрее подключает конечно, вроде как меньше секунды, но у тиков другие болезни. И ревущий пингвин, подключается быстро.

Интерфейсов > 3k а точнее 3.37K MAX dpkg -l "*image*" | grep ii ii linux-image-3.2.0-4-amd64 3.2.51-1 amd64 Linux 3.2 for 64-bit PCs ii linux-image-amd64 3.2+46 amd64 Linux for 64-bit PCs (meta-package) uname -r 3.2.0-4-amd64 Ничего не ложится. Использую unit-cache

А кто что скажет по этой теме? https://accel-ppp.org/forum/viewtopic.php?f=10&t=545 Что то обновление до 1.10 не решило проблему поедания soft-irq, на аналогичных брасах терминирующих PPPoE такой нагрузки не наблюдаю.

Спасибо, получилось!

Всем привет! Может кто сталкивался? После перевода домов, поднимаем внутри q-in-q pppoe для авто привязки порта, и плавного перехода на ipoe. Используем accel-ppp 1.9.0 ipoe ip-unnumbered, недельки две назад на одном из брасов накатил версию с гита заметил отклонения в работе, не стал особо разбираться и вернулся на 1.9.0. Вот недавно вышла 1.10.0, по форуму пишут что это исправления и дополнения 1.9.0, однако глюк остался. В общем проблема выглядит так! На IPoE подобных проблем не наблюдаю. После подключения посредством pppoe внутри q-in-q после определенного времени, сессия закрывается с стороны radius и ip адрес арендует кто то другой. То есть получается не работает аккаунтинг. С стороны accel сессия остается и получается дубликат по ip адресу, вижу следующее: 1. show sessions ip,uptime match type pppoe order ip ip | uptime -----------------+---------- 172.16.12.172 | 00:14:01 192.168.240.172 | 00:31:22 192.168.241.172 | 00:01:22 192.168.250.171 | 00:05:47 192.168.251.171 | 00:06:05 192.168.251.171 | 00:31:18 192.168.252.171 | 00:31:22 192.168.253.171 | 00:06:22 192.168.253.171 | 00:36:17 192.168.254.171 | 00:06:17 192.168.255.171 | 00:41:18 2. В логах радиуса наблюдаю следующее до обновления на 1.10.0 После обновления на 1.10.0 Откуда берется port 4294967295? Что вообще происходит, это баг или что то я не докрутил?

Существуют методы детектирования и подавления unicast атак на уровне accel-ppp? В последние два дня наблюдаю всплески, в одно и тоже время с разных BRAS!

Cекция ipoe Это 1-й BRAS где клиент по факту подключен! show sessions match calling-sid 2c:ab:25:64:90:f8 ifname | username | calling-sid | ip | rate-limit | type | comp | state | uptime ----------------+----------------+-------------------+-----------------+-----------------+-------+------+--------+------------ bnd1.1019.1203 | bnd1.1019.1203 | 2c:ab:25:64:90:f8 | x.x.169.163 | 102400/102400 | ipoe | | active | 10:59:14 2-й BRAS Где клиента нет но! show sessions match calling-sid 2c:ab:25:64:90:f8 ifname | username | calling-sid | ip | rate-limit | type | comp | state | uptime ----------------+----------------+-------------------+-----------------+---------------+-------+------+--------+---------- 2-й Брас БАЗА данных

какую часть? в ЛС можно?

А вот как раз пару дней назад, читал я тот топик, только бес толку все равно лезут! 2 BRAS с q-in-q, на 2 BRAS я вижу в db эти самые девайсы которые арендуют по 10~15 ипов с периодами в 40~45 сек, подключенные по факту к 1 BRAS. А другие работают нормально.

на BRAS 3~3.5K сессий PPPoE, traffic sum in/out 4Gbps, packet/sec sum in/out 700k. Падения случаются редко а если и случаются то подхватывают соседние. Правда течь памяти таки существует периодически 1 раз в 2~3 месяца делаю перезапуск accel. С чем это связано не знаю. Раньше snmpd жрал, поборол. mb: Z87M-PLUS cpu: E3-1270 v3 @ 3.50GHz nic: X520

Здравствуйте! Вопрос по теме IPoE accel-ppp! Есть некие устройства такие как китайские NoName раутеры. Так вот они вообще ведут себя не адекватно, работают не по стандарту, то есть ихний dhcp клиент постоянно штормит броадкастами, этим клиентам как то до фени lease-time Это как то можно побороть? Кусок tcpdump! 07:13:43.950200 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 560) 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from e8:03:9a:9c:d9:27 (oui Unknown), length 532, xid 0x7d1f3029, Flags [none] (0x0000) Client-Ethernet-Address e8:03:9a:9c:d9:27 (oui Unknown) Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover Client-ID Option 61, length 7: ether e8:03:9a:9c:d9:27 Vendor-Class Option 60, length 11: "udhcp 0.9.8" Requested-IP Option 50, length 4: x.x.x.x Parameter-Request Option 55, length 11: Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname Domain-Name, RP, BR, TFTP Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft END Option 255, length 0 PAD Option 0, length 0, occurs 247 Затем идет пачка request, через 40-45 секунд все повторяется. Замечен клиент udhcp 0.9.8, все девайсы с этим клиентом вызывают шторм.

cpu: E3-1270 v3 @ 3.50GHz nic: X520 users: 3.5K на BRAS Так как RSS анализирует пакет на 3,4 уровне, то smp_affinity при PPPoE до лампочки, пользуюсь RPS/RFS и XPS. http://syuu.dokukino.com/2013/05/linux-kernel-features-for-high-speed.html

Есть 2 BRAS IPoE q-in-q ip-unnumbered DHCP! Так как DHCPREQUEST происходит по broadcast, то по факту пользователь авторизуется на 1 BRAS, и так же на 2 BRAS я вижу в логах и базе что та же сессия как бы авторизована и для неё арендуется ip адрес с пула 2 BRAS. В итоге получается каша. 1. Возможно использование 2 и более BRAS в одних и тех же VLAN q-in-q? 2. Как избавиться от этой проблемы на уровне accel? 3. Это проблема accel, или нужно ковырять биллинг? Биллинг самописный распределенный: то есть каждый BRAS имеет свой radius с своим mysql и своими пулами.

Вопрос по IPoE accel-ppp! Есть такой момент, допустим нужно часть пользователей мигрировать на другой BRAS, но при shutdown soft после истечении лизы сессия закрывается, есть алгоритм предотвращающий закрытие сессии?

Возможен опрос более одного BRAS в одном флаконе?

У нас распределенный биллинг, много BRAS на основе accel, возможен опрос всех устройств, для поиска того же пользователя и выявление проблем?

Да, спасибо так сработало Думаю что и так правильно было бы. Но пока не передавал доп атрибуты! Спасибо за помощь всем откликнувшимся )

А если используются два пула, один гостевой назовем IPOE-GUEST выдается 172.16.0.0/20! И рабочий IPOE-PUBLIC выдаются публичные IP, как быть в этом случае с gw-ip-address? attr-dhcp-router-ip=атрибут Указывает в каком радиус атрибуте передаётся ип адрес маршрутизатора (актуально только для DHCP). С помощью этого атрибута возможно победить?

А как выдавать GW с этого subnet если используется общий ip-pool для accel, выдаваемый радиус сервером! Допустим общий GW=192.168.254.254 а ip-pool 172.16.0.0/20, Ладно Если прислать атрибут Framed-IP-Netmask=255.255.240.0 может отработает но как быть с GW который заведомо уже находиться в другом сабнете? Или тут такая тема не пройдет? Нужно делать по стандарту?

Здравствуйте! Тип соединения IPoE, ip-unnumbered, авторизация через RADIUS! shared=0 ifcfg=1 mode=L2 start=dhcpv4 Не работают некоторые маршрутизаторы! Такие как: TP-LINK TL-R402 D'LINK DIR-600 Хотя то же старинный D'LINK DI-604 работает нормально! На примере маршрутизатора TL-R402! Вот что происходит: log accel: log router TL-R402: Модель и Версия маршрутизатора: В то же время, если подключить к обычному ISC DHCP Серверу, все ОК. Такое впечатление что не работает ip-unnumbered а точнее не понимает dhcp-client маршрутизатора такую маску! Все прошивки нативные. Может кто сталкивался, или в музей?

Debian Squeeze 6.0.6, ядро 2.6.35.9, accel-ppp 1.6.1 На 1.7.2 после перезагрузки net-snmp, наблюдались падения на 1.6.1 нет.

А производительность при этом не падает, в этом режиме вообще не нужно ни каких манипуляций с портами на коммутаторе, у меня падала поэтому жил на mode=4 (802.3ad) mode=0 (balance-rr) Этот режим используется по-умолчанию, если в настройках не указано другое. balance-rr обеспечивает балансировку нагрузки и отказоустойчивость. В данном режиме пакеты отправляются "по кругу" от первого интерфейса к последнему и сначала. Если выходит из строя один из интерфейсов, пакеты отправляются на остальные оставшиеся.При подключении портов к разным коммутаторам, требует их настройки.

Взяли одну такую карту на тест, на родном ядре под Debian 6.0.6 pppoe не заработал, также по arping не было ответа, может в новых версиях драйвера исправлено, но времени не было на эксперименты, поэтому взяли ET шки.

У меня dmesg |grep -i APIC [ 0.000000] ACPI: APIC 00000000cd12c758 00072 (v03 ALASKA A M I 01072009 AMI 00010013) [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.014452] Setting APIC routing to flat [ 0.014775] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.506800] ACPI: Using IOAPIC for interrupt routing

ip source guard http://xgu.ru/wiki/IP_Source_Guard