[xeb]

насчёт q-in-q, кто поднимает все эти вланы ? какие-то кастомные скрипты ? а "некий софт" только должен при появления первого пакета либо дхцп запроса спросить у радиуса пускать его или нет, и если пускать, то с каким ип/шейпером и пр. ?

[taf_321]

Все сходится к тому, что интерфейсы создаваться будут кастомными скриптами.

 

Требования от "некоего софта" вы верно уловили.

[alexaaa]

Все сходится к тому, что интерфейсы создаваться будут кастомными скриптами.

 

Требования от "некоего софта" вы верно уловили.

Создание вланов на каждого абонента на linux машине это будет совсем изврашение, и на сервер лишняя нагрузка.

accel-ppp возможно авторизовать и шейпить абонента, лучьше по ip. А абонентские вланы крутиться будут на центральном коммутаторе. Не реально создать софтину которая заменит сервер+dhcp+коммутатор.

[taf_321]

Объясните мне, чем 1500-2000 влан-интерфейсов хуже 1500-2000 ppp-интерфейсов от PPTP/PPPoE/L2TP?

 

Даже еще круче, за счет того, что не нужна поддержка туннельной инкапсуляции, 1500-2000 интерфейсов будут гораздо веселее крутиться чем ppp

Изменено 7 марта, 2012 пользователем taf_321

[nuclearcat]

Тем, имхо, что это гораздо лучше делается в железе.

[YuryD]

Тем, имхо, что это гораздо лучше делается в железе.

На дорогом железе...

[Lynx10]

Тем, имхо, что это гораздо лучше делается в железе.

да и ппп в железе работает :)

но это не мешает терминировать ппп на тазиках ....

Изменено 7 марта, 2012 пользователем Lynx10

[nuclearcat]

На дорогом железе...

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

[taf_321]

 

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

 

Оно, конечно, да. Но когда возникают странные желания странным образом править доступ уже на БРАСе, а так же странным образом нарезать полосу клиенту в зависимости от того, куда он решил пойти (другой клиент, пиринг внутри с другими провами внутри города, внешний интернет, к какому сервису решил обратиться и etc, etc) сильно подозреваю, что на 3550/3560 это запилить не получится.

 

Тупое терминирование qinq особо и не интересно.

[NiTr0]

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

Средний трафик 1 абона - 500-700 кбит/с (1 активный абон в ЧНН в среднем генерит порядка 1-1.5 мбит, активных где-то до 50% от всех, пользующихся услугой). Если прибавить некоторое кол-во еще не оплативших услугу или временно не пользующихся - кол-во трафика будет еще меньше.

Сколько там 3550 вланов кушает? 1к?

Изменено 7 марта, 2012 пользователем NiTr0

[desperado]

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

писюк подкупает гибкостью. потом на счет "гораздо", я бы поспорил...

[xeb]

а как происходит назначение белых адресов ?

[NiTr0]

Можно натить 1:1 как в lISG, можно напрямую белые выдавать. ИМХО скрестить lISG с DHCP и с управлением маршрутами через интерфейсы (эдакий ip unnumbered) в одной софтине было бы самое то.

[nuclearcat]

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

Средний трафик 1 абона - 500-700 кбит/с (1 активный абон в ЧНН в среднем генерит порядка 1-1.5 мбит, активных где-то до 50% от всех, пользующихся услугой). Если прибавить некоторое кол-во еще не оплативших услугу или временно не пользующихся - кол-во трафика будет еще меньше.

Сколько там 3550 вланов кушает? 1к?

1000 * 1м - уже превышает 1Г аплинка. Если забондим - 2Г. Это если user-per-vlan - то 1к юзеров.

Cisco Catalyst 3550-24 SMI Switch - 24 ports - managed - stackable $168

 

Что там на писюке прожует столько траффика?

 

Хорошо, предположим что-то не Б/У.

WS-C3560V2-24TS-S $1048

24 гиговых порта, т.е. еще локально может пороутить тучу траффика, независимо от PPS.

[NiTr0]

1000 * 1м - уже превышает 1Г аплинка.

Из 1000 подключенных по тем или иным причинам не пользуются услугой эдак 100-150 чел (кто-то в отпуске, кто-то не оплатил т.к. з/п еще не выдали, кто-то на пару месяцев мотнулся к другому прову, пока бесплатно инет дают с бесплатным подключением). Из 750-800 оплативших в ЧНН будут в онлайне 500-600. Если не меньше. Отсюда и выводы.

А для голого роутинга 1 гбита с головой хватит 1-голового младшего целерона с парой i82574L к примеру... Локальный трафик же у нас намного меньше инет-трафика, хотя в сети не 100 абонов, и не 1000.

[Lynx10]

На дорогом железе...

3550/3560 может прожевать QinQ, в обьеме гораздо большем чем писюк по сравнимой цене.

начнём с того что это не брас! Радиус не умеет, шейпинг гибкий отсутствует и т д.

 

а как происходит назначение белых адресов ?

unnumbered

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

 

Что там на писюке прожует столько траффика?

пачка прожует что угодно - если правильно сбалансировать

Изменено 7 марта, 2012 пользователем Lynx10

[xeb]

Интереснее вариант вынести редактирование cburst из конфига в сторону RADIUS атрибутов, а-ля cisco, там как раз всё очевидно получается и зависит от тарифа. Ну либо как-то доработать в конфиге. А так, как сейчас реализовано - ни куда не годится... Не может cburst быть одинаковым для 512Кбит и для 12288Кбит.

вобщем сделал если cburst=0 в конфиге, то будет работать как раньше, т.е. cburst=burst

 

xeb, заметил незначительный баг:

time-range=1,13:00-01:00
time-range=2,01:00-13:00

атрибуты для входящего шейпа:

lcp:interface-config#1=rate-limit input access-group 1 4096000 256000 256000 conform-action transmit exceed-action drop
lcp:interface-config#1=rate-limit input access-group 2 12288000 768000 768000 conform-action transmit exceed-action drop

Если я будучи в time-range=2,01:00-13:00 даю команду shaper change ppp16 20480, то

root@nas:/etc# tc class show dev ppp16
class htb 1:1 root prio 0 rate 20480Kbit ceil 20480Kbit burst 250Kb cburst 31997b

Обращаю внимание на значение burst - оно из первого time-range=1,13:00-01:00.

Просьба перепроверить.

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

таким образом, если хочется изменить скорость и при этом передать значение burst нужно воспользоваться radius CoA и передать данные в циско формате

[nuclearcat]

1 головый целерон? А если 400 байт average packet size? 625Kpps (in+out)? На _Целероне_?

Боюсь со всеми advanced фичами которые хочется он сложится на сотне Kpps (суммарно две сотни).

 

Итак по пунктам:

1)С аппаратным свитчингом (и рутингом), производительность детерминирована. В случае софтрутеров (FreeBSD, Linux, но т.ч. Cisco ISR и 72xx), производительность может изменяться от количества включенных фич. Я знаю, что включу положенные мне 1K ACL, и у меня по прежнему будeт бегать положенные Kpps и гигабиты. Я не говорю о том, что когда софтрутер скажем включает NAPI, задержка, предел нагрузки и т.п. растут нелинейно.

2)Backplane свитча намного шире, чем шина компьютера. Суммарно из порта в порт можно пророутить 32Гбита, это серьезно.

3)Обьем и энергопотребление. На чердак целерон пихать - гиблое дело, ему требуется все таки побольше и питания, и обслуживания. Если же это узел, тут немного проще, но целерон в стойку уже будет стоить усилий и денег. Усилия впрочем тоже стоят денег. Одно дело когда есть специалист, который это сделает качественно и дешево ценит свой труд, а другое, когда или специалиста нет, или дорого.

 

ИМХО софтрутеры целесообразно на пионернетах до 100-200 Мбит, дальше гибридизация, и еще дальше уже скачкообразно вкладываемся в CAPEX, и дешевле обрабатываем каждого абонента, или боремся с кучей железок и получаем больше OPEX.

 

Скажем для маленького офиса с большими хотелками (логирование доступа и т.п.), отсутствием нормального админа (но наличием эникея, даже из персонала), денег и некритичностью доступа в инет - Microsoft ISA или Untangle.

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

Так же и с провайдерами, все зависит от критичности, хотелок и наличия денег.

 

Вот и я вырос из 300Мбит основного канала, а внутри уже утыкаюсь в гигабит, частенько приезжает высоко-Kpps-ный DDoS, софтрутер будет уже невероятным геммороем и расходом времени, потому тщательно зализываю сеть под аппаратный свитчинг, упрощаю где можно, в итоге сплю спокойно, и со вторым админом справляюсь. Были бы грамотные линупсоиды в Ливане, больше места и надежнее электропитание, может и пилил бы дальше только софтрутеры.

 

Я приверженец эффективных решений, и не пытаюсь остановиться на чем-то определенном. У всего своя ниша. Но такая задача как терминация вланов в большинстве случаев может дешево и эффективно делаться на железе, особенно если учесть, что железо которое умеет вланы, обычно умеет и в какой-то мере ACL-и и другой необходимый функционал, который можно на них сгрузить.

[nuclearcat]

начнём с того что это не брас! Радиус не умеет, шейпинг гибкий отсутствует и т д.

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

В крайнем случае аутентификация (не авторизация!) на свитче, а остальное на ISG, а его уже под Линукс вроде как пытаются запилить.

 

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

Если же каналы дорогие или ограниченные, то конечно, тут нужна гибкость.

 

unnumbered

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

arp_proxy?

все интерфейсы в bridge? но почему-то накладно, медленно делается, может openvswitch более вкусным будет.

 

пачка прожует что угодно - если правильно сбалансировать

Сколько писюков нужно, скажем, чтоб пронатить 19Гиг? И сколько стоит каждый.

[NiTr0]

А если 400 байт average packet size?

Откуда он такой вылезет-то? :) В среднем 800-900 байт.

 

Боюсь со всеми advanced фичами которые хочется он сложится на сотне Kpps (суммарно две сотни).

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

 

Backplane свитча намного шире, чем шина компьютера.

Ценой гибкости.

 

Обьем и энергопотребление. На чердак целерон пихать - гиблое дело, ему требуется все таки побольше и питания, и обслуживания.

Сколько там 3550 жрет? 190Вт? :) Столько же будет потреблять эдак 2x i7-2600k в стойке...

И стояли раньше роутеры в большом кол-ве по чердакам, на заре стройки сети, когда все строилось медью (ибо оптика была еще очень дорого) и резервация медных колец была на L3 (OSPF). Пыхтели себе, жрать особо не просили, аптайм на удачных местах без особых перебоев с электроэнергией до года доходил... И кое-где старые целероны 600МГц жевали себе усердно 200-300 мбит трафика, не жалуясь.

 

ИМХО софтрутеры целесообразно на пионернетах до 100-200 Мбит, дальше гибридизация, и еще дальше уже скачкообразно вкладываемся в CAPEX, и дешевле обрабатываем каждого абонента, или боремся с кучей железок и получаем больше OPEX.

ХЗ, у нас оба бордюра софтовых, тот что на IX смотрит, вообще старичок 2-головый (Phenom II на АМ2 плате), при 700+ мбит в ЧНН в каждую из сторон я не видел на нем загрузку ядер более 30%. Это при достаточно большом кол-ве правил иптейблса. На втором, 6-головом, что в мир смотрит - нагрузка единицы %.

 

Сколько писюков нужно, скажем, чтоб пронатить 19Гиг?

Сколько кисок 3550 пронатит хоть 1 мбит траффика, если они это принципиально не умеют? :) Или понадобился нат - выкидываем старое железо и покупаем новое? :)

А для 19 гиг, думается, 5-6 корок i7 должно хватить...

[Lynx10]

начнём с самого главного - никто о свитчинге на ПК не говорил . говорили о терминации. при чём тут вообще свитчинг не ясно

 

На чердак целерон пихать

а зачем пихать на чердак ? стянуть вланы в центр (или если сеть большая - то в какой-то из больших узлов ) и там поставить на место браса например... МХ80 тоже на чердак пихается для ipoe? или народ терминирует на чердаках - я просто не вкурсе. думал что брасы на чердаках как то - неправильно...

 

arp_proxy?

все интерфейсы в bridge? но почему-то накладно, медленно делается, может openvswitch более вкусным будет.

нет я имел ввиду что-то вроде этого

ip route add unreachable 192.0.2.0/24

vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/32 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101


Или так:

ip route add unreachable 192.0.2.0/24

vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/24 dev eth0.101
ip route del 192.0.2.0/24 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101

 

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

В крайнем случае аутентификация (не авторизация!) на свитче, а остальное на ISG, а его уже под Линукс вроде как пытаются запилить.

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

Если же каналы дорогие или ограниченные, то конечно, тут нужна гибкость.

следуя вашей логике непонятно тогда зачем вообще выпускаются брасы с поддержкой ipoe L2 - со всеми этими радиусами шейпингами coa pod. И называют их именно брасами и они имеют понятное и чёткое назначение. свичи не называют брасами и я нигде не встречал чтобы рекомендировали использовать свич как брас.

 

Сколько писюков нужно, скажем, чтоб пронатить 19Гиг? И сколько стоит каждый.

 

1 при 19Г я сомневаюсь что вы вообще что то будете делать там на свичах и писюках. я думаю должен стоять нормальный брас

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

3 я уже не говорю что не понятно при чём тут нат .... хотя на ПК можна поговоритьи про нат - а вот на свичах можна со старта забыть и нат выносить в сторону на тот же ПК ;) и тогда получается схема: абонент -> L2 свич (dhcp,opt82) -> L3 свич (gateway) -> ПК (nat, можна lISG)-> inet ( есть проблема - похоже что lISG не развивается )

 

1 головый целерон? А если 400 байт average packet size? 625Kpps (in+out)? На _Целероне_?

Боюсь со всеми advanced фичами которые хочется он сложится на сотне Kpps (суммарно две сотни).

блин так вы возьмите ещё i386

понятно что для "взрослых" задач нужны "взрослые" пк

Изменено 7 марта, 2012 пользователем Lynx10

[taf_321]

а как происходит назначение белых адресов ?

 

http://habrahabr.ru/blogs/sysadm/108453/

 

тут пример, как можно сделать аналог ip unnumbered,

 

WS-C3560V2-24TS-S $1048

24 гиговых порта, т.е. еще локально может пороутить тучу траффика, независимо от PPS.

 

А как оно себя будет чувствовать, когда придется рутить много-мнгого трафика между много-много вланов? Где-то тут на форуме попадалась темка, где красоту со скоростью на Л3 свитчах можно наблюдать только без применения межвлановой маршрутизации, в противном случае все становится очень грустно. Кстати, вы же там и были топикстартером :)

[nuclearcat]

Скоро проверю :)

[lan-viper]

xeb, спасибо за cburst=0! С изменением скорости через telnet всё ясно.

 

Скажу своё IMHO по поводу IPoE и непосредственно accel-ppp - не стоит городить комбайны, accel - это отличная реализация нескольких протоколов классического VPN. То, что вы все хотите там мутить с vlan и ip unnumbered - это всё хорошо, но это не имеет никакого отношения к accel-ppp, делайте отдельный программный продукт!

[s.lobanov]

lan-viper

С какой стороны, Вы конечно правы, тунели это тунели, ipoe это ipoe, но если рассматривать с точки зрения isp, то accel это в первую очередь софт-брас, который обрабатывает сигнализацию, взаимодействует с radius, инкаспулирует/декапсулирует и ограничивает скорость. По большому счёту, какая разница что у вас является сигнализацией - всякая ppp-шная(с логином и паролем) служебка или dhcp/arp(с option82 и/или номером(ами) влана)? Принципиальной разницы нет.