Jump to content
Калькуляторы

3.2 говно же. будет у вас 3-4 тысячи ppp-интерфейсов и accel начнёт загибаться при создании/удалении ppp-интерфейсов

Share this post


Link to post
Share on other sites

больше интересует 3.19+ - на них грабли начались... ни у кого в продакшне нет?

Share this post


Link to post
Share on other sites

4.8.x более менее застабилизировали, но с sfq могут быть подводные камни.

До 15к pppoe сессий, пашет, accel кстати перестал изредка виснуть на этом ядре (раньше бывало, не мог поймать - почему).

Share this post


Link to post
Share on other sites

ок, значит на досуге проведу экскремент... а что за подводные камни с sfq?

 

//оффтоп, мож кому полезно будет: тут на днях сервачок (пптп+немного ната+роутинг, с FV) подкрашиваться начал, возможно - от флуда, на 3.10.101, с i82576 (igb 5.3.3.2), один раз он просто дуплил с потерями, зашел - увидел ругань на ошибки выделения памяти; похоже, были виноваты слишком накрученные буфера сетевки, т.к. поменяли все железо кроме сетевки - не особо помогло, подрезал с 4096 на 1024 - вроде попустило.

Share this post


Link to post
Share on other sites

ок, значит на досуге проведу экскремент... а что за подводные камни с sfq?

 

В панику ядро оседало при создании-удалении интерфейсов, причину отловить так и не удалось, пришлось вынести sfq отовсюду.

Share this post


Link to post
Share on other sites

хм, по ifdown не было удаления qdisc? у меня такое наблюдалось вроде начиная с 3.14 или 3.18, причем после паники тупо вставали колом sysctl к сетевой подсистеме, сам тазик не крашился. убрал из шейпера деинициализацию по ifdown - вроде попустило, остались в основном грабли с самими pppoe...

Share this post


Link to post
Share on other sites

у меня вообще ifup/ifdown нету, стоит отдельный демон, который следит за новыми интерфейсами и добавляет шейперы, хоть и с задержкой, но зато нет проблем когда несколько тысяч юзеров логинятся в течении минуты.

Share this post


Link to post
Share on other sites

у меня вообще ifup/ifdown нету, стоит отдельный демон, который следит за новыми интерфейсами и добавляет шейперы, хоть и с задержкой, но зато нет проблем когда несколько тысяч юзеров логинятся в течении минуты.

 

а что за демон-то и какие скрипті?

Share this post


Link to post
Share on other sites

написал на C, специфический для моего биллинга.

Старая версия смотрит на время создания файлов /var/run/radacct*, новая смотрит netlink, по ним определяет, что новый юзер залогинился, в биллинге сделал хак - чтобы в /var/run/radacct.pppx откладывался username, демон смотрит юзернейм в radacct (хотя можно и с биллинга по номеру порта и nas ip вытянуть, но зачем грузить его?), по юзернейму с биллинга вытягивает данные по юзеру в нормальном виде (т.к. в радиусе все таки передавать какие-то нестандартные правила - сплошной костылинг) и передает в очередь новые правила на шейперный процесс. Шейперный процесс я часть сделал на libmnl, а часть все таки iproute2/tc (с libmnl лень было разбираться в формате netlink сообщений, как формировать правила для tc filter и т.д.)

Share this post


Link to post
Share on other sites

Лучше бы попросила xeb-а дополить встроенный "shaper" под набор правил, чем бесконечно плодить уродские костыли с ifup/down и ещё хуже с самодельными демонами на C, отслеживающими ppp-интерфейсы и навешивающие на них правила полисинга/шейпинга

 

я как-то попрсил sfq сделать в accel-pppd. xeb сделал и ушёл таким образом от ifup/down

Share this post


Link to post
Share on other sites

У меня демон кроме этого делает кучу других задач - в т.ч. динамический шейпинг в зависимости от загрузки магистральных каналов(CoA усерется обновлять с такой скоростью), fair use policy(траффик считается прямо в демоне, снимается через netlink каждые 30 секунд, чтобы не загружать биллинг промежуточными значениями), статистика по каждому классу траффика в биллинге близко к реалтайму (через redis), детект дубликатов юзеров c учетом долбанных тплинков (они держат две сессии и перебороть это невозможно), и т.д. Я сейчас даже не вспомню все.

Так что про xeb-а не к месту. Не стоит натягивать на accel задачи ему несвойственные.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании?

CCP пробовал отключить

Разные версии accel собирал так же безрезультатно.

 

[2016-11-09 18:00:06.419] recv [PPPoE PADT f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0040]

[2016-11-09 18:00:09.433] recv [PPPoE PADI f4:6d:04:f8:5c:c1 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 10000000000000001e000000>]

[2016-11-09 18:00:09.433] send [PPPoE PADO 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e1fd5668357cffb26> <Host-Uniq 10000000000000001e000000>]

[2016-11-09 18:00:09.433] recv [PPPoE PADR f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0000 <Service-Name > <Host-Uniq 10000000000000001f000000> <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e1fd5668357cffb26>]

[2016-11-09 18:00:09.433] send [PPPoE PADS 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0001 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 10000000000000001f000000>]

[2016-11-09 18:00:09.434] ppp0: : connect: ppp0 <--> pppoe(f4:6d:04:f8:5c:c1)

[2016-11-09 18:00:09.434] ppp0: a4c8ec8f7d90bf63: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>]

[2016-11-09 18:00:09.444] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfReq id=0 <mru 1480> <magic 1c317f65> <pcomp> <accomp> < d 3 6 >]

[2016-11-09 18:00:09.444] ppp0: a4c8ec8f7d90bf63: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3 6 >]

[2016-11-09 18:00:09.445] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfReq id=1 <mru 1480> <magic 1c317f65>]

[2016-11-09 18:00:09.445] ppp0: a4c8ec8f7d90bf63: send [LCP ConfAck id=1 ]

[2016-11-09 18:00:12.434] ppp0: a4c8ec8f7d90bf63: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>]

[2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>]

[2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: send [MSCHAP-v2 Challenge id=1 <beeffb6a1bac5849ef31da702026cb5b>]

[2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=2 <MSRASV5.20>]

[2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=3 <MSRAS-0-ASUS1600-PC>]

[2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=4 <▒▒rވL▒▒bV▒▒>]

[2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: recv [MSCHAP-v2 Response id=1 <a7b29c2cfdb324e5b40ab54ff9cff3a>, <983ac88ec0281ebd55f7f1d27a1318c415b2f72015be>, F=0, name=test]

[2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: send [MSCHAP-v2 Success id=1 "S=54394B05B22BA850462B2287EED24A7D6E854FD2 M=Authentication succeeded"]

[2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfReq id=1 <addr 192.168.100.1>]

[2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: test: authentication succeeded

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [CCP ConfReq id=5 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [CCP ConfReq id=1 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [CCP ConfAck id=5]

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfNak id=6 <addr 10.0.10.2>]

[2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfAck id=1 <addr 192.168.100.1>]

[2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: recv [CCP ConfAck id=1 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfReq id=7 <addr 10.0.10.2> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]

[2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfAck id=7]

[2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-up started (pid 21139)

[2016-11-09 18:00:12.538] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-up finished (0)

[2016-11-09 18:00:22.320] ppp0: a4c8ec8f7d90bf63: recv [LCP TermReq id=8]

[2016-11-09 18:00:22.320] ppp0: a4c8ec8f7d90bf63: send [LCP TermAck id=8]

[2016-11-09 18:00:22.347] recv [PPPoE PADT f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0001]

[2016-11-09 18:00:22.348] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-down started (pid 21146)

[2016-11-09 18:00:22.352] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-down finished (0)

[2016-11-09 18:00:22.352] send [PPPoE PADT 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0001 <AC-Name accel-ppp> <Service-Name >]

[2016-11-09 18:00:22.352] ppp0: a4c8ec8f7d90bf63: disconnected

[2016-11-09 18:00:24.565] recv [PPPoE PADI f4:6d:04:f8:5c:c1 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 110000000000000020000000>]

[2016-11-09 18:00:24.565] send [PPPoE PADO 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e805b7e5f9c9c648e> <Host-Uniq 110000000000000020000000>]

[2016-11-09 18:00:24.565] recv [PPPoE PADR f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0000 <Service-Name > <Host-Uniq 110000000000000021000000> <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e805b7e5f9c9c648e>]

[2016-11-09 18:00:24.565] send [PPPoE PADS 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0040 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 110000000000000021000000>]

[2016-11-09 18:00:24.565] ppp0: : connect: ppp0 <--> pppoe(f4:6d:04:f8:5c:c1)

[2016-11-09 18:00:24.566] ppp0: a4c8ec8f7d90bf64: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>]

[2016-11-09 18:00:24.583] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfReq id=0 <mru 1480> <magic 5d3842fa> <pcomp> <accomp> < d 3 6 >]

[2016-11-09 18:00:24.583] ppp0: a4c8ec8f7d90bf64: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3 6 >]

[2016-11-09 18:00:24.584] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfReq id=1 <mru 1480> <magic 5d3842fa>]

[2016-11-09 18:00:24.584] ppp0: a4c8ec8f7d90bf64: send [LCP ConfAck id=1 ]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: send [MSCHAP-v2 Challenge id=1 <f3278e9f159a89a832b8bf2cb6afbdca>]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=2 <MSRASV5.20>]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=3 <MSRAS-0-ASUS1600-PC>]

[2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=4 <▒KM▒/<B▒̾▒▒▒e▒>]

[2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: recv [MSCHAP-v2 Response id=1 <889cbd7b42686988abd88fa0ffc1f9>, <c8e0e02448aa142866d78a498bf47e374f1d618c62c5af3>, F=0, name=test]

[2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: send [MSCHAP-v2 Success id=1 "S=2AF52F2ED52836F3A2B50F6E078D7336E126BD92 M=Authentication succeeded"]

[2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfReq id=1 <addr 192.168.100.1>]

[2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: test: authentication succeeded

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [CCP ConfReq id=5 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [CCP ConfReq id=1 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [CCP ConfAck id=5]

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfNak id=6 <addr 10.0.10.2>]

[2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfAck id=1 <addr 192.168.100.1>]

[2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: recv [CCP ConfAck id=1 <mppe -H -M -S -L -D -C>]

[2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfReq id=7 <addr 10.0.10.2> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>]

[2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfAck id=7]

[2016-11-09 18:00:27.574] ppp0: a4c8ec8f7d90bf64: pppd_compat: ip-up started (pid 21152)

[2016-11-09 18:00:27.671] ppp0: a4c8ec8f7d90bf64: pppd_compat: ip-up finished (0)

Share this post


Link to post
Share on other sites

3.2 говно же. будет у вас 3-4 тысячи ppp-интерфейсов и accel начнёт загибаться при создании/удалении ppp-интерфейсов

 

Интерфейсов > 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

Edited by nsa2006

Share this post


Link to post
Share on other sites

nsa2006

c unit-кешем понятно... просто поначалу этот unit cache как-то странно работал. если сейчас он работает ок, то хорошо

Share this post


Link to post
Share on other sites

Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании?

CCP пробовал отключить

Разные версии accel собирал так же безрезультатно.

Из комита https://sourceforge.net/p/accel-ppp/code/ci/d2cb39985cd33f5678cad3e68b69cca51894bd58/

ppp: discard packets with invalid id before passing it to fsm

 

ppp: default fsm timeout increased to 3 sec.

ppp: accept LCP TermReq/TermAck packets in terminating phase

Share this post


Link to post
Share on other sites

Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании?

Есть такое дело, где то я читал что можно timeout где то в конфигурации подсунуть минимальный 1 сек, не идеал конечно но всё же быстрее.

Вот нашёл!

https://accel-ppp.org/forum/viewtopic.php?t=639

На тиках довольно быстрее подключает конечно, вроде как меньше секунды, но у тиков другие болезни.

 

И ревущий пингвин, подключается быстро.

Edited by nsa2006

Share this post


Link to post
Share on other sites

проблема тут оказалось даже не в таймаутах, а в частых переотправках LCP пакетов.

 

[LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

я изменил в акселе количество попыток на большее, но не нравится сама ситуация с будто битыми пакетами GRE.

 

вывод логов я тоже изменил

[2016-11-12 18:34:33.801] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.802] eth3: 5fb5a404ff288410: fsm timeout 49. Restarting...

[2016-11-12 18:34:33.802] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.803] eth3: 5fb5a404ff288410: fsm timeout 48. Restarting...

[2016-11-12 18:34:33.803] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.804] eth3: 5fb5a404ff288410: fsm timeout 47. Restarting...

[2016-11-12 18:34:33.804] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.805] eth3: 5fb5a404ff288410: fsm timeout 46. Restarting...

[2016-11-12 18:34:33.805] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: fsm timeout 45. Restarting...

[2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: fsm timeout 44. Restarting...

[2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.807] eth3: 5fb5a404ff288410: fsm timeout 43. Restarting...

[2016-11-12 18:34:33.807] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.808] eth3: 5fb5a404ff288410: fsm timeout 42. Restarting...

[2016-11-12 18:34:33.808] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.809] eth3: 5fb5a404ff288410: fsm timeout 41. Restarting...

[2016-11-12 18:34:33.809] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.810] eth3: 5fb5a404ff288410: fsm timeout 40. Restarting...

[2016-11-12 18:34:33.810] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.811] eth3: 5fb5a404ff288410: fsm timeout 39. Restarting...

[2016-11-12 18:34:33.811] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.812] eth3: 5fb5a404ff288410: fsm timeout 38. Restarting...

[2016-11-12 18:34:33.812] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>]

[2016-11-12 18:34:33.813] eth3: 5fb5a404ff288410: fsm timeout 37. Restarting...

 

примерно так валит

 

иногда с 1й попытки, иногда с 15й

 

Linux billing 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

Edited by Sanchezz

Share this post


Link to post
Share on other sites

иногда с 1й попытки, иногда с 15й

Покажите ppp секцию, попробую у себя на стенде.

Share this post


Link to post
Share on other sites

Добавил возможность указания нескольких service-name, плюс опционально можно изменить логику сервера, чтобы решения о подключении к service-name принимал клиент, а сервер принимал всех даже при указанном service-name.

Если xeb добавит, у себя протестил :)

Прошу взглянуть, если есть очевидные ошибки

https://github.com/xebd/accel-ppp/pull/7

Share this post


Link to post
Share on other sites

Добавил возможность указания нескольких service-name, плюс опционально можно изменить логику сервера, чтобы решения о подключении к service-name принимал клиент, а сервер принимал всех даже при указанном service-name.

Если xeb добавит, у себя протестил :)

Прошу взглянуть, если есть очевидные ошибки

https://github.com/xebd/accel-ppp/pull/7

 

It is possible to specify multiple service names now (as in most pppoe daemons), old options are backward compatible.

Also new accel-ppp verifying if service-name specified, it should strictly match on PADI and PADR packets, while old version doesn't do that. It is usual ISP scenario, where some clients has service-name specified, and some are "default". Without this patch default without service-name wont be able to connect.

 

If service-name specified still will answer with service names, but accepts any service name in PADR request. Useful

+for scenarios, where selection of PPPoE done by client, based on service names in PADO.

 

Я извиняюсь, разве старые версии не ведут себя так же ? У меня на 30cff41b56be0d4c3e407e8aa4de5b289eef2ab0 указано #service-name= и подключаются и с пустым SN и с вписанным значением.

 

А если указать конкретное SN на AC, то других по идее дропает.

 

[2015-11-26 16:24:28]:  info: recv [PPPoE PADI d0:27:88:6e:48:36 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name test>]
[2015-11-26 16:24:28]:  warn: pppoe: discarding PADI packet (Service-Name mismatch)

Edited by hsvt

Share this post


Link to post
Share on other sites

На стандартном pppoe сервере даже если указаны service-name - то как минимум с пустым(длина 0, т.е. не указан) на клиенте - все равно пускает. На последних accel - нет.

Share this post


Link to post
Share on other sites

Вот уже долгое время в голове крутится вопрос, на который я не могу найти ответ =)

Используется такое: accel-ppp, radius, Q-in-Q, DHCPv4, OSPF.

На lo вешаю ip

root@debian:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet 192.168.1.1/32 scope global lo
      valid_lft forever preferred_lft forever
   inet 192.168.2.1/32 scope global lo
      valid_lft forever preferred_lft forever
   inet 10.0.0.1/32 scope global lo
      valid_lft forever preferred_lft forever

Я предполагаю, что производители некоторых клиентских маршрутизаторов устанавливают значение arp_ignore в 1 и поэтому клиентские маршрутизаторы на хотят отвечать на

 

03:27:23.393145 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28

 

Информация по arp_ignore.

arp_ignore - INTEGER
Define different modes for sending replies in response to
received ARP requests that resolve local target IP addresses:
0 - (default): reply for any local target IP address, configured
on any interface
1 - reply only if the target IP address is local address
configured on the incoming interface
2 - reply only if the target IP address is local address
configured on the incoming interface and both with the
sender's IP address are part from same subnet on this interface
3 - do not reply for local addresses configured with scope host,
only resolutions for global and link addresses are replied
4-7 - reserved
8 - do not reply for all local addresses

The max value from conf/{all,interface}/arp_ignore is used
when ARP request is received on the {interface}

 

Еще есть параметр arp_announce с которым игрался целый день, но так и не достиг желаемого результата, а именно

03:27:23.393145 ARP, Request who-has 10.0.0.50 tell 10.0.0.1, length 28

Есть мысли по этому поводу, буду благодарен за любой пинок в правильном направлении.

Share this post


Link to post
Share on other sites

Dimka88

Не используйте адреса /32, и не будет проблемы. Не нужно изобретать костыли там, где они не нужны.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now