[nnm]

на доступе 2950, на районе агрегировать вланы 3550G. Для доступа в инет придёться ставить 7200

А сколько интерфейсов можно завести на 3550 ?

до 1000

Я боюсь, что если на нем завести 1000 L3 интерфейсов и заставить маршрутизировать между ними, то он будет это делать с производительностью Cisco 8xx... :(

[mnemonic]

не суть важно сколько может агрегировать 3550. Если надо поставить 6500 значит поставим 6500. Дело в том как правильно всё организовать чтоб потом не было мучительно больно

[SmokerMan]

А мне кажется что некрасиво столько интерфейсов создавать...

[nnm]

Дело в том как правильно всё организовать чтоб потом не было мучительно больно.

Правильно на мой взгляд сделать так, чтобы весь трафик абонента проходил через BRAS. Конечно это приведет к тому, что BRAS придется купить потолще, чем 72xx. Зато сэкономите на сети доступа т.к. никакой L3 агрегации делать не нужно будет. Ну и более управляемую услугу получите.

А мучительно больно будет в любом случае :(

[kapa]

Дело в том как правильно всё организовать чтоб потом не было мучительно больно.

Правильно на мой взгляд сделать так, чтобы весь трафик абонента проходил через BRAS. Конечно это приведет к тому, что BRAS придется купить потолще, чем 72xx. Зато сэкономите на сети доступа т.к. никакой L3 агрегации делать не нужно будет. Ну и более управляемую услугу получите.

А мучительно больно будет в любом случае :(

Ужас какой.

Зачем?

Экономия сомнительная очень.

Надёжность тоже.

[nnm]

Правильно на мой взгляд сделать так, чтобы весь трафик абонента проходил через BRAS. Конечно это приведет к тому, что BRAS придется купить потолще, чем 72xx. Зато сэкономите на сети доступа т.к. никакой L3 агрегации делать не нужно будет. Ну и более управляемую услугу получите.

А мучительно больно будет в любом случае :(

Зачем?

Чтобы трафиком управлять... :)

Экономия сомнительная очень.

Про экономию в общем случае рассуждать конечно трудно. Но отказ от L3 агрегации позволит например вместо 65xx поставить 3550...

Надёжность тоже.

Почему?

 

[SmokerMan]

А что вы подразумеваете под управлением трафиком в данном случае?..

[mikevlz]

отрезать каждому абоненту столько, сколько заплатил

[kapa]

отрезать каждому абоненту столько, сколько заплатил

локального трафика?

[mikevlz]

в том числе и локального. Он же тоже небесплатен?

Вот есть вариант - дать локал нахаляву. На скорости порта. А инет на безлимитных тарифах - на скорости тарифа.

А есть подход, когда все считается. А если безлимит, то все режется.

Более доходным и наверное менее популярным будет второй подход.

 

[kapa]

в том числе и локального. Он же тоже небесплатен?

Вот есть вариант - дать локал нахаляву. На скорости порта. А инет на безлимитных тарифах - на скорости тарифа.

А есть подход, когда все считается. А если безлимит, то все режется.

Более доходным и наверное менее популярным будет второй подход.

Во-первых, считать и тарифицировать локальный трафик себе дороже может стать.

Во-вторых, можно считать локальный трафик и с 36хх тех же. Пусть не с хирургической точностью, но она для локалки и не нужна.

Зато, не придётся на шлюз ставить 2 железки (горячий резерв) под несколько килобаксов каждая.

[SmokerMan]

А почему бы по sflow не посчитать локальный трафик?.. Точность вполне достаточная...

[Bambuk]

Дело даже не столько в учете, а в эксплуатации и управлении.

Количество точек управления.

В случае если все свитчится тупым L3 свитчем, то абонентов зажимать и ограничивать придется на их портах. Например ACL, чтоб вирусня не резвилась и т.п. Допустим сегодня написали скрипт, который это делает на нескольких тысячах 36хх. А завтра они EOS и на другой модели все по другому, ну или другой вендор откат больше сделал руководству и купили их свитчи. И что, для них по новой писать управлялку? Т.е. потенциально больше количество разнородных точек управления.

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

[SmokerMan]

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

[kapa]

Дело даже не столько в учете, а в эксплуатации и управлении.

Количество точек управления.

В случае если все свитчится тупым L3 свитчем, то абонентов зажимать и ограничивать придется на их портах. Например ACL, чтоб вирусня не резвилась и т.п. Допустим сегодня написали скрипт, который это делает на нескольких тысячах 36хх. А завтра они EOS и на другой модели все по другому, ну или другой вендор откат больше сделал руководству и купили их свитчи. И что, для них по новой писать управлялку? Т.е. потенциально больше количество разнородных точек управления.

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

Тут речь шла про экономию и надёжность.

 

Так вот с такой схемой либо ни о какой экономии речь не идёт - всё будет ооочень дорого. Либо ни о какой надёжности - первый новый резвый вирус положит всем доступ в Инет.

 

[Bambuk]

Дорого - понятие относительное. Например BRAS за $160К на каждые 16К пользователей, учитывая что коммутаторы на доступ и до него можно потупее ставить, это дорого?

[SmokerMan]

Доктор, меня все игнорируют... :-)

[BudushiyISP]

Доктор, меня все игнорируют... :-)

Ваши ответы односложны. Буквально через 1 час консилиум - выдаст мысль свежих идей и умозаключение

 

 

[kapa]

Дорого - понятие относительное. Например BRAS за $160К на каждые 16К пользователей, учитывая что коммутаторы на доступ и до него можно потупее ставить, это дорого?

Ну, если кто-то покупает, то не дорого. :)

 

Но можно значительно дешевле всё организовать.

На 16К пользователей - пусть 16 3612 = 25 тыс долларов и шлюз за 10К - итого 35К$

 

Или 160К$ только за BRAS и вместо 3612 за 1,5К$ ставим что-нибудь за 0,5К$ - 16х0,5=8К$. Итого 168К$

 

Плюс первая схема надёжнее - так как имеем возможность управлять до шлюза - т.е. изолировать внештатные ситуации.

[nnm]

Дорого - понятие относительное. Например BRAS за $160К на каждые 16К пользователей, учитывая что коммутаторы на доступ и до него можно потупее ставить, это дорого?

Ну, если кто-то покупает, то не дорого. :)

 

Но можно значительно дешевле всё организовать.

На 16К пользователей - пусть 16 3612 = 25 тыс долларов и шлюз за 10К - итого 35К$

 

Или 160К$ только за BRAS и вместо 3612 за 1,5К$ ставим что-нибудь за 0,5К$ - 16х0,5=8К$. Итого 168К$

 

Плюс первая схема надёжнее - так как имеем возможность управлять до шлюза - т.е. изолировать внештатные ситуации.

Если я правильно понимаю, Вы предлагаете делать L3 агрегацию в схеме 'VLAN на абонента' на 3612. Я не большой знаток D-Link, но если верить документации, на этих 3612 может быть то-ли 64, то-ли 255 L3 интерфейсов. Это означает, что для того, чтобы сагрегировать 16K абонентов вам нужно будет иметь как минимум 64 3612. Т.е. стоить они будут ~ 100K. И того ваша схема обойдется в 135K. Это кстати при равномерном распределении абонентов по коммутаторам, чего в жизни не встречается :)

Далее есть вопрос с производительностью/масштабируемостью. На чем будет собран шлюз за 10K, какую он будет иметь производительность и что делать?

BRAS за 160K это как-бы уровень Juniper E120 с двумя процами, резервной фабрикой и одной линейной картой. Можно кстати немного удешевить если взять пару RB100, ERX310 или пожертвовать резервированием. Но в результате вы получите коробку, которая умеет 4Gbit/s full duplex. Будет-ли предлагаемый Вами шлюз паритетен с ней по функциям/производительности?

По поводу изоляции нештатных ситуаций - а какие конкретно ситуации имеются ввиду?

[kapa]

Дорого - понятие относительное. Например BRAS за $160К на каждые 16К пользователей, учитывая что коммутаторы на доступ и до него можно потупее ставить, это дорого?

Ну, если кто-то покупает, то не дорого. :)

 

Но можно значительно дешевле всё организовать.

На 16К пользователей - пусть 16 3612 = 25 тыс долларов и шлюз за 10К - итого 35К$

 

Или 160К$ только за BRAS и вместо 3612 за 1,5К$ ставим что-нибудь за 0,5К$ - 16х0,5=8К$. Итого 168К$

 

Плюс первая схема надёжнее - так как имеем возможность управлять до шлюза - т.е. изолировать внештатные ситуации.

Если я правильно понимаю, Вы предлагаете делать L3 агрегацию в схеме 'VLAN на абонента' на 3612. Я не большой знаток D-Link, но если верить документации, на этих 3612 может быть то-ли 64, то-ли 255 L3 интерфейсов. Это означает, что для того, чтобы сагрегировать 16K абонентов вам нужно будет иметь как минимум 64 3612. Т.е. стоить они будут ~ 100K. И того ваша схема обойдется в 135K.

Интересная у Вас арифметика. Откуда 35? 100+10=110К$.

 

Про Д-линк:

Погорячился с 3612, но даже так экономия вышла около 58К$.

Ну да можно подобрать что-нибудь бюджетнее и удобнее.

Например DES-6500 или что ещё.

Не вдавался глубоко в подробности, но пусть она умеет 4К виланов. Итого 5 штук таких по 4К$ = 20К$. Плюс 10 за шлюз - итого 30К$ против 168. Тоже неплохо.

 

Далее есть вопрос с производительностью/масштабируемостью. На чем будет собран шлюз за 10K, какую он будет иметь производительность и что делать?

BRAS за 160K это как-бы уровень Juniper E120 с двумя процами, резервной фабрикой и одной линейной картой. Можно кстати немного удешевить если взять пару RB100, ERX310 или пожертвовать резервированием. Но в результате вы получите коробку, которая умеет 4Gbit/s full duplex. Будет-ли предлагаемый Вами шлюз паритетен с ней по функциям/производительности?

По поводу изоляции нештатных ситуаций - а какие конкретно ситуации имеются ввиду?

Шлюза будет аж два из 4ёх компов. По одному бриджу - для шейпинга и по 1 роутеру. Производительность каждого не на много меньше гигабита.

Если нужно больше - просто докупаются ещё пара компов за 5К$.

 

 

 

[nnm]

Интересная у Вас арифметика. Откуда 35? 100+10=110К$.

Да, здесь я облажался :( Приношу свои извинения.

 

Про Д-линк:

Погорячился с 3612, но даже так экономия вышла около 58К$.

Ну да можно подобрать что-нибудь бюджетнее и удобнее.

Например DES-6500 или что ещё.

Не вдавался глубоко в подробности, но пусть она умеет 4К виланов. Итого 5 штук таких по 4К$ = 20К$. Плюс 10 за шлюз - итого 30К$ против 168. Тоже неплохо.

Да, DES-6500 скорее всего умеет рутинг между 4K VLAN. Но там есть другие проблемы. Он, если верить доступной на сайте документации, не умеет ограничивать скорость транзитного трафика. Т.е. ограничивать локальный трафик не получится, что на мой взгляд не есть хорошо. Далее. Какие карты Вы в него поставите? Подозреваю, что 12-ти портовку с SFP. Тогда на 5K вы купите скорее всего шасси и три такие карты. Получите 48 GE портов для подключения доступа и Uplink. Только есть один нюанс - эта 12-ти портовка поддерживает 100 access rule на порт. Т.е. всего для фильтрации абонентского трафика у вас будет меньше 4,8K access-rule. В среднем по 1,2 rule на абонента. В результате:

 

- Ограничить скорость трафика не можете (внутри сети полный бардак, каждый льет сколько хочет)

- По той-же причине надежно защититься от флудов на ваши шлюзы тоже не можете.

- Превентивно блокировать подозрительный трафик не можете - не хватает access rule на всех.

- Единственное, что можете, это после обнаружения флуда, атаки, etc нарисовать при помощи access rule какой-то не сильно сложный фильтр для конкретного абонента, который 'делает нам плохо'. Только его еще найти надо будет... Т.е. работаете в режиме пожарной команды.

 

Я-бы не назвал это 'управлением трафика до шлюза'.

 

Я все-таки предлагаю не считать деньги по таким 'сырым' дизайнам. Еще и потому, что считать сколько будет стоить агрегация + сервис само по себе бессмысленно. Нужно считать сеть в комплексе. И поверьте мне, что большую часть общего бюджета съедает доступ И на этом фоне разница, которую получаем мы, будет смотреться очень скромно. И разница эта отобьется очень быстро за счет упрощения эксплуатации...

[SmokerMan]

Если я правильно понимаю, Вы предлагаете делать L3 агрегацию в схеме 'VLAN на абонента' на 3612. Я не большой знаток D-Link, но если верить документации, на этих 3612 может быть то-ли 64, то-ли 255 L3 интерфейсов. Это означает, что для того, чтобы сагрегировать 16K абонентов вам нужно будет иметь как минимум 64 3612.

А для чего создавать интерфейс на каждого абонента?.. /32 или proxy_arp помогут...

[kapa]

Да, DES-6500 скорее всего умеет рутинг между 4K VLAN. Но там есть другие проблемы. Он, если верить доступной на сайте документации, не умеет ограничивать скорость транзитного трафика. Т.е. ограничивать локальный трафик не получится, что на мой взгляд не есть хорошо.

А зачем?

Это в предложенной вами схеме нужно ограничивать локальный трафик, а в моей - он никак не влияет на предоставление доступа в Интернет. Пусть себе крутится и радует абонентов.

 

Да, DES-6500 скорее всего умеет рутинг между 4K VLAN. Но там есть другие проблемы. Он, если верить доступной на сайте документации, не умеет ограничивать скорость транзитного трафика. Т.е. ограничивать локальный трафик не получится, что на мой взгляд не есть хорошо. Далее. Какие карты Вы в него поставите? Подозреваю, что 12-ти портовку с SFP. Тогда на 5K вы купите скорее всего шасси и три такие карты. Получите 48 GE портов для подключения доступа и Uplink. Только есть один нюанс - эта 12-ти портовка поддерживает 100 access rule на порт. Т.е. всего для фильтрации абонентского трафика у вас будет меньше 4,8K access-rule. В среднем по 1,2 rule на абонента.

Ну что вы привязались к конкретным моделям оборудования? Я примерно прикидывал.

Если у неё нет возможности делать 1 ACL на диапазон портов, то я куплю следующее поколение, которое умеет и обойдётся оно на 15-20% дороже. Что всё равно сильно дела не меняет при сравнении конечной суммы моей модели и вашей.

 

- Ограничить скорость трафика не можете (внутри сети полный бардак, каждый льет сколько хочет)

- По той-же причине надежно защититься от флудов на ваши шлюзы тоже не можете.

- Превентивно блокировать подозрительный трафик не можете - не хватает access rule на всех.

- Единственное, что можете, это после обнаружения флуда, атаки, etc нарисовать при помощи access rule какой-то не сильно сложный фильтр для конкретного абонента, который 'делает нам плохо'. Только его еще найти надо будет... Т.е. работаете в режиме пожарной команды.

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

 

[derini]

бр....как всегда народ не думает про умное слово "opex" - посчитайте во что обойдётся эскплуатация вашей схемы с кучей длинков и поймёте что она выгодна пока сеть маленькая, а с нормальным оборудованием аля erx310/e120 и единой точкой предоставления услуги при увеличении количества абонентов "opex" не растут, а вот с длинками или чем то другим ой-ой....

 

терь собсно по поводу сабжа - схема vlan per user есть идеологически правильная, ибо резко повышает секурити, вопрос по поводу как ея конфигурить - на днях собсно представители из джунипера активно продвигали идею о статической конфигурации вланов на всём оборудовании "ниже" браса и терминировать их на брасе, а собсно автоизацию и настройки раздавать через pppoe - по их мнению такая схема наиболее проста в обслуживании и, в принципе, я с ними даже согласный в ентом вопросе, кроме того такая схема резко упрощает сбор статистики и снимает все вопросы по поводу блокировок/разблокировок абонента

 

вопрос по поводу отслеживания атак и прочая и прочая:

1) во первых схема vlan per user большую часть таких проблем решает сам по себе

2) не смешивайте мух с котлетами - firewall и idp не есть функция узлов доступа (будь то dslam, обычный l2 коммутатор или что-то ещё) или точек дистрибуции услуг, для этого делаются отдельные серьёзные и не очень решения

3) приличную часть решения таких поблем можно по первости возложить прямо на тот же erx310/e120 пока не дорастёте до большого idp - ибо в части policy и всякой фильтрации железки тоже очень могучие, по крайней мере таких иерархических структур которые мона городить на джунипере ещё поискать надо где в принципе можно сделать

Изменено 23 октября, 2008 пользователем derini