[taf_321]

По-моему от тарифа может зависить только "limit" (если limit не задается радиусом, то размер брать из конфига, если нет ни того, ни другого, то из системного умолчания).

 

Остальные параметры вполне достаточны статическим объявлением в конфиге.

[xeb]

тогда уж проще сделать чтобы вся строка целиком через радиус передавалась либо из конфига бралась...

[taf_321]

Можно и так.

[srg555]

тогда уж проще сделать чтобы вся строка целиком через радиус передавалась либо из конфига бралась...

 

Да было бы удобнее всего, т.е. в Filter-ID(или в переопределённом конфигурацией аттрибуте) вместо скорости просто передавать всю строку с синтаксисом как у tc(главное, чтобы фича с timerange при этом не пострадала) для шейперов, сложнее, чем tbf и htb+sfq.

 

Думаю, что интерес должен быть к red и sfb. Правда sfb мало где есть из коробоки, так что пользователей этой фичи будет тоже не шибко много, хотя с другой стороны пересбор ядра на брасе не такая уж и редкость. Надеюсь, что это не внесёт проблем с компиляцией из-за отсутсвия модных фич в "старых" версиях api.

Изменено 10 июня, 2012 пользователем srg555

[info83]

.. про дебиан - Linux Deb 2.6.32-5-amd64 #1 SMP.

accel-pptp version 1.3.2

5 дней летели нормально.., а сегодня при количестве сессий РРТР около 200 -

May 24 17:16:02 Deb kernel: [382565.375802] accel-pptpd[10370] general protection ip:403e61 sp:40478a60 error:0

in accel-pptpd[400000+16000]

Случай пока единичный. В kernel.log только одна эта строчка...

Пару дней подряд такая же ошибка

Версия accel-ppp version 1.6.0

[mcym]

Пробую мигрировать с chap-secrets на radius, пока толковой инструкции не нашел

пробую экспериментирую. Есть вопросы.

 

1)Относительно авторизации. Таблица radcheck

Авторизация происходит успешно

Username-a1 User-Password == 123

 

Пользователя отбивает

Username-a1 User-Password == 123

Username-a1 Auth-Type := Reject

 

Соединение не устанавливается

Username-a1 User-Password == 123

Username-a1 Auth-Type := Accept

 

Если в Auth-Type := Ms-Chap то все работает успешно, и авторизация происходит.

 

Как правильно по научному делать Accept , Reject ?

 

2)Кто поделится примером атрибутов для шейпера ?

[xeb]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

т.к. не имею реального железа хочу на gns3 поднять тестовую сеть, кто может подсказать т.к. gns3 эмулировать свитчи не может, какую можно циску/иос для этого приспособить чтобы дхцп релеила и опцию 82 вставляла ? и примерный конфиг циски ?

[s.lobanov]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

т.к. не имею реального железа хочу на gns3 поднять тестовую сеть, кто может подсказать т.к. gns3 эмулировать свитчи не может, какую можно циску/иос для этого приспособить чтобы дхцп релеила и опцию 82 вставляла ? и примерный конфиг циски ?

 

Можно и без свитча обойтись. Для нормального IPOE между между брасом и клиентом должен быть L2(что эмулируется обычным проводом). саму dhcp-option82 можно добавить самим клиентом, вроде dhcpcd или dhclient умеет добавлять произвольную опцию, формат опций должен быть максимально гибко конфигурируем, чтобы не привязываться к одному вендору

 

Примеры дампов с вставленной dhcp option82 могу сделать(только не пишите в icq, она обычно запущена где-то удалённо)

 

vlan-per-user для IPOE тоже было бы интересно(т.е. делать логин из номера влана(ов) или грубо говоря из названия интерфейса), т.к. dhcp option82 не редко убивает cpu свитчей, если кто-то флудит

[xeb]

Можно и без свитча обойтись. Для нормального IPOE между между брасом и клиентом должен быть L2(что эмулируется обычным проводом). саму dhcp-option82 можно добавить самим клиентом, вроде dhcpcd или dhclient умеет добавлять произвольную опцию

мда, действительно ...

 

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

регулярное выражение ?

что-то типа:

[ipoe]

option-format=^(.*)-(.*)$

username=$1-$2

либо для vlan-per-user:

username=$ifname

Изменено 13 июня, 2012 пользователем xeb

[s.lobanov]

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

регулярное выражение ?

что-то типа:

[ipoe]

option-format=^(.*)-(.*)$

username=$1-$2

либо для vlan-per-user:

username=$ifname

 

как-то так(правда должно быть 2 option-format, один для rid, второй для cid). и надо учесть, что иногда в опции есть бинарный мусор, который нужно дропнуть, а иногда это "мусор" и есть полезные данные(ip или mac свитча, не закодированный текстом)

[nuclearcat]

Может проще сделать декодинг опции в юзернейм подгружаемой .so библиотечкой? которая будет парсить конкретных вендоров.

Особенно если там проприетарные бинарные данные.

[s.lobanov]

Может проще сделать декодинг опции в юзернейм подгружаемой .so библиотечкой? которая будет парсить конкретных вендоров.

Особенно если там проприетарные бинарные данные.

 

это ограничит аудиторию, т.е. админы без глубоких навыков программирования не смогут пользоваться. меньше community - хуже качество ПО. можно позаимстовать какие-то идеи из isc dhcpd, его конфигом довольно легко матчится всякая бинарщина(вот тут примеры неплохо подобраны)

[s.lobanov]

Эмуляция dhcp option82 insertion (huawei style - так умеют слать свитчи huawei и такую опцию без проблем конвертирует в логин наиболее популярный huawei bras):

 

Использовать dhclient 3.0.5(в более поздних мажорных версиях спуфинг option82 заблокирован).

 

Конфиг dhclient.conf:

option space opt82;

option opt82.rid code 2 = string;

option opt82.cid code 1 = string;

option opt82-82 code 82 = encapsulate opt82;

send opt82.cid "port01";

send opt82.rid "switchname";

 

Запуск ./dhclient -cf ./dhclient.conf , после этого ваершарком видно наличие option82 (и rid и cid)

 

UPD: приложил дамп на всякий случай

dhcp-opt82-ex.pcap.zip

[nuclearcat]

Может проще сделать декодинг опции в юзернейм подгружаемой .so библиотечкой? которая будет парсить конкретных вендоров.

Особенно если там проприетарные бинарные данные.

 

это ограничит аудиторию, т.е. админы без глубоких навыков программирования не смогут пользоваться. меньше community - хуже качество ПО. можно позаимстовать какие-то идеи из isc dhcpd, его конфигом довольно легко матчится всякая бинарщина(вот тут примеры неплохо подобраны)

Вообще-то делается набор .so -шников для разных железок, и добивается по необходимости, и он же собирается как и весь код по make. Просто в случае добавления новой железки - не надо пересобирать всё.

Т.е. просто потом указать type=huawei к примеру.

Ну дело хозяйское конечно :)

[s.lobanov]

nuclearcat

Фишка в том, что многие свитчи поддерживают несколько режимов(как правило, для разных isp) для rid и cid, а по совокупности получается уже довольно много, т.е. к вашему .so-шнику опять же конфиг нужен. Просто надо придумать как работать с бинарными данными через регулярные выражения и создать функции преобразования данных по типу isp dhcpd

[s.lobanov]

Ещё в догонку по поводу IPv4oE браса. В случае с shared vlan необходимо создавать статический(PERM) arp до создания маршрута /32(arp -i eth0.10 -s 1.1.1.1 00:11:22:33:44:55, это работает не смотря на то, что 1.1.1.1 ещё не привязан к eth1.10) и удалять эту запись после удаления маршрута /32 по окончанию сессии, в противном случае возможен arp-spoofing + лишняя нагрузка.

 

Ну и из общих соображений, должна быть возможна атака ip spoofing(т.е. брать произвольный мак и ip соседей по интерфейсу, слать всякий мусор, urpf тут не должен помочь). это надо проверять, но пока некогда. и как её блокировать линуксом тоже не понятно(т.е. как сделать ip-mac-binding для ip-трафика по arp-таблице?)

[xeb]

pcre вроде может мэтчить бинарные данные:

\xhh character with hex code hh

\x{hhh..} character with hex code hhh..

надо только выяснить насколько это применимо, поэтому предлагаю у кого есть возможность сделать дампы пакетов и скинуть сюда или мне на почту xeb@mail.ru

 

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

 

может какой нибудь скриптовый язык внедрить, lua например ?

Изменено 14 июня, 2012 пользователем xeb

[gibbon]

И не просто lua а lua-jit.

http://luajit.org/luajit.html

[s.lobanov]

des3200 с дефолтными настройками option82 (в remote-id mac свитча, в circuit-id последний байт это номер порта)

3200.zip

[Wingman]

Хеb нет ли мыслей по созданию IPOE на accel-ppp или добавления функции dhcp-relay option 82?

т.к. не имею реального железа хочу на gns3 поднять тестовую сеть, кто может подсказать т.к. gns3 эмулировать свитчи не может, какую можно циску/иос для этого приспособить чтобы дхцп релеила и опцию 82 вставляла ? и примерный конфиг циски ?

 

Можем предоставить удалённый доступ к свитчам (длинк) и паре компов (клиент+сервер) для тестов и разработки =)

Давно и успешно подсели на accel-pppd (огромное за него спасибо!); сейчас сеть потихоньку перетаскиваем на linux_isg, но, поскольку проект дальше не развивается, были бы заинтересованы в развитии этого софта

 

Если пригодится, mailto wingman {эт} ip-home.net, ну или тут в личку

[xeb]

Wingman, спасибо, обязательно воспользуюсь как только будет что тестировать :)

пока надо решить идеологические вопросы, чтобы потом меньше переделывать

[Wingman]

пока надо решить идеологические вопросы, чтобы потом меньше переделывать

Вот кстати, да =)

ipoe-брасу option82 нужен только если авторизация абонентов происходит по dhcp-запросу и при этом, как правило, все абоненты - l2-connected. Так сделано в редбеках, например, и там с этим не всё гладко

 

В целом, имхо, возможно два подхода:

У нас, например, dhcp-сервер - это dhcp-сервер, а ipoe-брас авторизует абонентов по `unknown-source-ip`, т.е. по трафику с неизвестного ip запрашивается радиус, пускать ли его. При этом нет необходимости тянуть L2 до браса и заставлять брас работать dhcp-сервером, достаточно на какой-либо l3-аггрегации направить на него трафик абонентов. За то, чтобы на порту абонента работали только верные ip-адреса, отвечают access-свитчи.

 

Если же рассчитывать на l2-connected юзеров, имхо, нужно сразу и придумывать способ терминировать на коробке множество qinq-вланов из рассчёта влан-на-юзера и какое-то подобие ip unnumbered. Тут уже и сам сервер может выступать dhcp-сервером, и релеить запросы на внешний сервер, как-то вставляя в запрос теги внутреннего влана (субьективно, второе удобнее), при этом авторизовывать юзеров, опять же, либо по dhcp-запросу, либо по unknown-source-ip (опять же, второе субьективно мне кажется удобнее и гибче)

 

У нас сейчас целиком первый подход, но, имея ввиду ipv6, когда-нибуть придётся переходить к vlan-per-user. Пока подходящих брасов не нашли; остаётся надеется или на софт, или на доводку до ума редбеков через годик

 

Опять же, если будут какие-нибуть вопросы по всему этому хозяйству в реальной сети - обращайтесь =)

[s.lobanov]

Если же рассчитывать на l2-connected юзеров, имхо, нужно сразу и придумывать способ терминировать на коробке множество qinq-вланов из рассчёта влан-на-юзера и какое-то подобие ip unnumbered. Тут уже и сам сервер может выступать dhcp-сервером, и релеить запросы на внешний сервер, как-то вставляя в запрос теги внутреннего влана (субьективно, второе удобнее), при этом авторизовывать юзеров, опять же, либо по dhcp-запросу, либо по unknown-source-ip (опять же, второе субьективно мне кажется удобнее и гибче)

 

l2-connected более верно идеалогически и практически, т.к. L3 свитчи мрут от арп-флудов и подобных гадостей.

 

По поводу терминирования именно Q-in-Q, то тут такой вопрос. 4К клиентов на 1G интерфейс(т.е. в сторону linux-браса слать трафик в одном теге) это нормально для типового оператора ШПД крупного города, а вот для 10G 4К клиентов это немножко жирновато, ну разве что использовать один интерфейс и под терминирование сабскрайберов, так и под роутинг "наверх", тогда 4К клиентов на 5G ну ещё более-менее, хотя потребление трафика растёт с каждым днём и скоро 10G на 4К клиентов будет нормально(а может где-то уже прошли этот порог)

 

Q-in-Q интерфейсы создаются без особых проблем на линуксе и работают, вопрос в том тормозят они или нет, надо придумать тесты какие-нибудь и попробовать.

 

В любом случае, проблемы(если они есть) q-in-q и linux никаким боком не касаются control-plane(т.е. subj), обрабатывающего сигнализацию.

 

С точки зрения распределения IP-адресов, у accel-ppp сейчас всё правильно сделано, можно заводить в нём пулы и не передавать ничего из радиуса, передавтать ip или имя пула из радиуса, делать ещё dhcp-relay нет никакого смысла, для этого уже есть radius.

[Wingman]

....4К клиентов на 1G интерфейс(т.е. в сторону linux-браса слать трафик в одном теге) это очень даже с запасом...

С запасом онлайн или всего? Онлайн - не получится, из 4к живых абонентов в пиках онлайн обычно ~половина -> 2к вланов будут простаивать -> таки нужен qinq

 

>> на 1G интерфейс

А на bonding? У нас по 3г+3г под 2г фулдуплекса летает (2in+2out)

10g опять же, да.

 

>> В любом случае, проблемы(если они есть) q-in-q и linux никаким боком не касаются control-plane(т.е. subj), обрабатывающего сигнализацию.

брасу необходимо как-то авторизовывать юзеров, и в случае qinq - видимо, именно по in+out тегам, которые терминируются на самом брасе. Поэтому это всё тоже должно быть учтено в софте

 

>> l2-connected более верно идеалогически и практически, т.к. L3 свитчи мрут от арп-флудов и подобных гадостей.

Да ладно, та же c3750 при shared vlan пророутит куда больше, чем прожуёт комп. Вы же не длинками l3 аггрегируете, надеюсь? =)

 

Абонентские /24, терминящиеся на 3750 и далее дефолт-роутом летящие на isg:

C3750-***#sh vlan | count active
Number of lines which match regexp = 264

[s.lobanov]

....4К клиентов на 1G интерфейс(т.е. в сторону linux-браса слать трафик в одном теге) это очень даже с запасом...

С запасом онлайн или всего? Онлайн - не получится, из 4к живых абонентов в пиках онлайн обычно ~половина -> 2к вланов будут простаивать -> таки нужен qinq

 

>> на 1G интерфейс

А на bonding? У нас по 3г+3г под 2г фулдуплекса летает (2in+2out)

10g опять же, да.

 

 

 

Ну да, чё-то я не учёл онлайн/оффлайн, хотя и 2К онлайн на 1G вообщем-то нормально для шпд, думаю в целом мы друг друга поняли. Нужно придумать тесты Q-in-Q IPv4 termination vs Linux

 

>> В любом случае, проблемы(если они есть) q-in-q и linux никаким боком не касаются control-plane(т.е. subj), обрабатывающего сигнализацию.

брасу необходимо как-то авторизовывать юзеров, и в случае qinq - видимо, именно по in+out тегам, которые терминируются на самом брасе. Поэтому это всё тоже должно быть учтено в софте

 

Да тривиально, Q-in-Q L3-интерфейсы в линуксе можно называть по типу eth3.500.100 , а дальше

username=$ifname

Ну или вырезать eth3, чтоб переключать/балансировать было проще между интерфейсами

 

>> l2-connected более верно идеалогически и практически, т.к. L3 свитчи мрут от арп-флудов и подобных гадостей.

Да ладно, та же c3750 при shared vlan пророутит куда больше, чем прожуёт комп. Вы же не длинками l3 аггрегируете, надеюсь? =)

 

Абонентские /24, терминящиеся на 3750 и далее дефолт-роутом летящие на isg:

C3750-***#sh vlan | count active
Number of lines which match regexp = 264

 

Покажите sh run, думаю будет видно как можно убить ваш свитч/создать деградацию сервиса