[Wingman]

...хотя и 2К онлайн на 1G вообщем-то нормально для шпд...

Оно может "навскидку" и нормально, но абсолютно немасштабируемо и неудобно: получается, что строгий набор вланов строго приколочен гвоздями к одному шлюзу... А если в одном доме два свитча, на одном закончатся первые 4к вланов, на втором начнутся вторые 4к - протягивать их к разному железу? Жутко неудобно

 

Нужно придумать тесты Q-in-Q IPv4 termination vs Linux

Где-то тут читал, что поднятие большой кучи интерфейсов обычными ifconfig/iproute занимает тьму времени, позже поищу темку и сам потестирую...

+ ещё нужно придумать что-то вроде ip unnumbered + софт должен прописывать маршрут на нужный влан при выдаче ипа

Кстати, l4-редирект тоже сразу предусмотреть нужно =)

 

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

username=$ifname

!!! Блин, точно =)

 

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

Единственное, что приходит в голову - перенагрузка от ARP input при арп-флуде, но это решается умным акцесом

[s.lobanov]

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

 

IPv4oE vlan-per-user работает относительно просто(терминология - upstream - от абонента к серверу, ds - наооборот):

1. Делаются преднастройки до запуска демона

sysctl net.ipv4.conf.all.proxy_arp=1 (недостаток ipoe "by design" по сравнению с pppoe)

sysctl net.ipv4.conf.default.rp_filter=1

ip route add blackhole 1.1.1.0/24

ifconfig dummy0 1.1.1.1 netmask 255.255.255.255 broadcast 0.0.0.0

 

vconfig add eth0 100 (абонентский интрефейс №1)

ifconfig eth0.100 up

vconfig add eth0 101 (---- №2)

ifconfig eth0.101 up

 

2. При запуске демона, на все абонентские интрфейсы, указанные в конфиге вешается us policy 4Кбита/с(для dhcp-сигнализации хватит за глаза)

 

3. При получении dhcp discover, отправляется auth запрос в radius(логин формируется из имени интерфейса), выдаётся offer в соответствии с тем, что вернул радиус.

 

4. После получения dhcp request в radius отправляется acct start, создаётся статическая arp-запись(см. выше), затем маршрут /32(ip route add 1.1.1.X/32 dev eth0.Y src 1.1.1.1), далее навешивается ds и us ограничители скорости по тарифу, аналогично тому, как это делается для ppp-интерфейсов

 

5. при завершении сессии(получение dhcp release или неполучение кипаливных dhcp request(фактически, замена ppp lcp)), удаляем маршрут /32, arp-запись, меняем us policy на 4К, ds убираем

 

Для shared vlan похоже(главное отличие в навенивании шейперов) и ещё немного продумать защиту от spoofing-атаки

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

[s.lobanov]

Где-то тут читал, что поднятие большой кучи интерфейсов обычными ifconfig/iproute занимает тьму времени, позже поищу темку и сам потестирую...

+ ещё нужно придумать что-то вроде ip unnumbered + софт должен прописывать маршрут на нужный влан при выдаче ипа

Кстати, l4-редирект тоже сразу предусмотреть нужно =)

 

По поводу большого кол-ва интерфейсов это я поднял тему, но там ничего по существу нет, кроме того, что на linux 3.5-rc1 ситуация значительно лучше.

 

Про L4-редирект(точнее, его хитрую замену) у меня есть неплохая идея, скоро опишу.

 

 

Единственное, что приходит в голову - перенагрузка от ARP input при арп-флуде, но это решается умным акцесом

 

Ну вот начинается, storm-control и т.п... А потом выясняем, что arp и юникастный бывает и ой как печально становится, если L3-свитч его трапит на CPU... Тут же вспоминается простой способ убить некоторые hw-брасы, терминирующие ppp-тунели - зафлудить его PADT-фреймами

[Wingman]

Ну вот начинается, storm-control и т.п... А потом выясняем, что arp и юникастный бывает и ой как печально становится, если L3-свитч его трапит на CPU... Тут же вспоминается простой способ убить некоторые hw-брасы - зафлудить его PADT-фреймами

Всё же, имхо, в НЕ vlan-per-user схеме это совсем не повод всех юзеров заводить по l2 на брас. Хотя бы потому, что в ШПД немала доля локального трафика, который софт-брасу нафиг не нужен.

[s.lobanov]

Ну вот начинается, storm-control и т.п... А потом выясняем, что arp и юникастный бывает и ой как печально становится, если L3-свитч его трапит на CPU... Тут же вспоминается простой способ убить некоторые hw-брасы - зафлудить его PADT-фреймами

Всё же, имхо, в НЕ vlan-per-user схеме это совсем не повод всех юзеров заводить по l2 на брас. Хотя бы потому, что в ШПД немала доля локального трафика, который софт-брасу нафиг не нужен.

 

В деревнях, где беда с аплинками может быть, а по крупному городу какому-нибудь у вас есть конкретная статистика, что-то XX% трафика идёт в обход браса? Единственное неудобство гонять локальный трафик через брас это необходимость усложнения шейперов(выделение направлений), если это предусмотрено тарифными планами.

[xeb]

IPv4oE vlan-per-user работает относительно просто

ну с этим понятно, это наиболее простой режим

 

Для shared vlan похоже(главное отличие в навешнивании шейперов) и ещё немного продумать защиту от spoofing-атаки

могу предложить модуль ядра который будет создавать псевдо-интерфейсы на который "как обычно" будут навешиваться шейперы и он-же будет осуществлять ip-mac binding

 

У нас, например, dhcp-сервер - это dhcp-сервер, а ipoe-брас авторизует абонентов по `unknown-source-ip`, т.е. по трафику с неизвестного ip запрашивается радиус, пускать ли его.

тут без модуля ядра не обойтись

[Wingman]

В деревнях, где беда с аплинками может быть, а по крупному городу какому-нибудь у вас есть конкретная статистика, что-то XX% трафика идёт в обход браса? Единственное неудобство гонять локальный трафик через брас это необходимость усложнения шейперов(выделение направлений), если это предусмотрено тарифными планами.

Как минимум ретрекер гоняет вполне себе немало трафика по локалке

 

 

тут без модуля ядра не обойтись

Ну, в общем-то, да =)

[nuclearcat]

У нас, например, dhcp-сервер - это dhcp-сервер, а ipoe-брас авторизует абонентов по `unknown-source-ip`, т.е. по трафику с неизвестного ip запрашивается радиус, пускать ли его.

тут без модуля ядра не обойтись

А если через ipset + NFQUEUE?

Кто разрешен - в ipset, а тех кого нет - в nfqueue.

[s.lobanov]

В деревнях, где беда с аплинками может быть, а по крупному городу какому-нибудь у вас есть конкретная статистика, что-то XX% трафика идёт в обход браса? Единственное неудобство гонять локальный трафик через брас это необходимость усложнения шейперов(выделение направлений), если это предусмотрено тарифными планами.

Как минимум ретрекер гоняет вполне себе немало трафика по локалке

 

дайте конкретику в %%

[Wingman]

дайте конкретику в %%

По трафику не знаю, не собираем; по статистике ретрекера в данный момент что-то качают внутри сети 1673 юзера (~10% от общего онлайна)

т.е. 1673 торрента, юзеров м.б. несколько меньше =)

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

[s.lobanov]

Wingman

Да хоть 100500 юзеров, это ни о чём разговор

[Wingman]

Wingman

Да хоть 100500 юзеров, это ни о чём разговор

Хе, ну если 1-2к лишних торентов, не грузящих софтверный брас - фигня, тогда да

[s.lobanov]

Wingman

Да хоть 100500 юзеров, это ни о чём разговор

Хе, ну если 1-2к лишних торентов, не грузящих софтверный брас - фигня, тогда да

 

Дело ваше, но если речь идёт о <10% трафика/pps, то игра не стоит свеч

 

Про L4-редирект. Можно ввести специальный аттрибут, подобие vrf (в стандратных аттрибутах ничего подходящего нет :( . Если он равен 0, то ничего дополнительно не происходит, если же не 0(например X), то добавляется правило в rpdb типа такого ip rule add iif pppY lookup table X(или ip rule add from IP/32 lookup table X), а в таблице X делаем nexthop в сторону веб-сервера, а на самом сервере уже делаем DNAT в prerouting. Такая схема позволит не выделять отдельный ip pool для должников/гостей и не сбрасывать сессию после оплаты задолжности(если реализовать установку/удаление такого правила через CoA).

Для блокировки межабонентского трафика внутри сервера(должники<->нормальные пользователи), можно ip rule 0(правило маршрутизации локального трафика) перенести в конец(требуется ядро >=2.6.33)

[nuclearcat]

VRF? В линуксе еще есть setns(), это более полноценный аналог. Более того, там можно свой набор iptables.

[s.lobanov]

nuclearcat

Для задачи редиректа должников/гостей хватает ip rule

[NiTr0]

Единственное неудобство гонять локальный трафик через брас это необходимость усложнения шейперов(выделение направлений), если это предусмотрено тарифными планами.

Не такое уж и серьезное усложнение будет... Входящий - банально классифицируется по меткам (которые расставлены в зависимости от источника трафла), исходящий - вешается на каждый интерфейс исходящий.

К слову, локальный трафик составляет менее 10% от внешнего для сети в несколько тысяч абонов...

[Alex/AT]

К слову, локальный трафик составляет менее 10% от внешнего для сети в несколько тысяч абонов...

У нас цифра более жестокая - почти половина трафика. И это при "широких" тарифах.

Процентов 10 явно яндексы, гуглотубы и вконтактики, ибо выделены всё в тот же локальный сервис, и обсчитываются вместе с внутренним трафом. Но и до них было процентов так 40.

Больше всего в часы пик заметны торренты.

Изменено 15 июня, 2012 пользователем Alex/AT

[aerounit]

Внезапно появился 1.7.0.

 

]# cmake [-DBUILD_DRIVER=TRUE] [-DKDIR=/usr/src/kernels/2.6.18-308.8.2.el5-i686] [-DCMAKE_INSTALL_PREFIX=/usr/local][-DCMAKE_BUILD_TYPE=Release] [-DLOG_PGSQL=FALSE] [-DSHAPER=TRUE] [-DRADIUS=TRUE] [-DNETSNMP=TRUE] ..
CMake Error at accel-pppd/triton/CMakeLists.txt:26 (MESSAGE):
 Your system is too old and is not supported by accel-ppp, sorry...


-- Configuring incomplete, errors occurred!

 

 

CentOS 6 обновил до последнего, но получается таки чего-то нехватает?

[xeb]

на центос вроде собиралось, если они чего не сломали ...

[aerounit]

Ошибочка у меня вышла. Дистрибутив скорее всего реально очень старый - 5.8. Это причина, да?

[xeb]

 

Requirements

• modern linux distribution
• kernel-2.6.25 or later
• cmake-2.6 or later

[info83]

Из 3-х серверов 1 обновил до 1.7.0 версии.

Надеюсь пропадут проблемы типа Jun 17 19:08:15 nas45 kernel: [1762741.669413] accel-pppd[4133] general protection ip:7f933bc4d8f3 sp:7f9335f7b668 error:0 in libtriton.so[7f933bc47000+9000]

[s.lobanov]

info83

Для того, чтобы подобные проблемы пропадали, надо собирать с дебагом, ловить корку и делать багрепорт - мне помогало.

[info83]

info83

Для того, чтобы подобные проблемы пропадали, надо собирать с дебагом, ловить корку и делать багрепорт - мне помогало.

Проблемы пропали кстати :), замесал что оно вылезает при длинном имене "пользователя" - типа user="///////////%%%{dghdfART^^^^^^^^^^^^^^^^^^^^^^^^&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&@$%^66666666666666666666666666666666666666666666666666666666666666666666ertydfgh" и т.д.

[-Ars-]

замесал что оно вылезает при длинном имене "пользователя" - типа user="/

Наверняка чудо случилось :-р