свич районного узла

[masterovoj]

Исходная. Стандартная наверно схема: по VLAN'у на юзера. Схема на рисунке.

На доме стоят свичи (SWд_...), выходы которых объединяются в районом узле на свич (SW_района), и от районов в ядро, где опять объединяются (SW_ядра).

 

На домах мне вроде понятно. Назначаю каждому «юзерскому» порту его конкретный VLAN, т.е. назначаю порт 1 во VLAN1, порт 2 во VLAN2 и т.д. На выходной порт (например, SWд_1), который уйдёт в район, назначаю все VLAN'ы этого дома (1,2,...10). И на выходе из свича получаю, скажем, 10 тэгированных VLANов. И так на каждом доме подобно. Как я вижу, практически любая железка, умеющая VLAN'ы, будет достаточна. Потому как важны не номера VLANов, а их поддерживаемое количество. На 24 порта, максимум 24 VLAN'а потребуется. Обычно, если в железке заявлены VLAN'ы, то она умеет как минимум 64 штуки, так что это выбор не сужает.

 

На ядре тоже вроде понятно – надо чтобы железка поддерживала количество VLAN'ов не меньше, чем количество VLAN'ов «за этой железкой».

Настраивается, как я понимаю, аналогично. То есть на порт «из района» навешиваются вся куча VLAN'ов этого района (1,2,...1000). Свич тут предполагается мощный, соответственно надо полагать он будет уметь 4096 VLAN'ов, что хватит для тех районов, которые в него сходятся. Если будет больше, будет второй свич.

 

Остаётся вопрос, какая функциональность требуется от районного свича (SW_района)? Исходя из того, что много денег тратить на районный узел по-моему смысла нету. Ведь основная цель мне видится в том, чтобы свести много волокон в одно.

Требуется ли на нём поддержка минимум того количества VLAN'ов, которое приходит со всех домов? Это уже не 64, тут больше 100 придётся закладывать. А это уже не всякая железка, дороже будет, надо специально уточнять (выискивать где-то в доках, сколько VLAN'ов оно умеет).

И ещё. Я в фокусах настройки свичей не шибко силён поэтому вопрос такой. Настраивается ли этот районный свич также как домовые грубо говоря? То есть на порт 1 навешиваются все VLAN'ы первого дома (1,2,...10), на порт 2 – второго (21,22,...30), и т.д. на порт 10 – десятого. И на «выходящий» порт навешиваются вся сотня VLAN'ов района (1,2,...100). Так?

Или тут как-то по-другому делается или другая схема?

 

Видел некое название «транзитные VLAN'ы», духом чую, что это как-то связано с моим вопросом, но понимания нету.

[Nafanya]

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

[Andrеw]

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

В таком случае в ядре вообще можно будет поставить простой L2 свитч.

[IvanI]

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

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

[ems_viking]

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

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

[masterovoj]

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

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

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

О боже... Какой-то ужас вырисовывается. В стиле "казнить нельзя помиловать". Мои полушария уже борятся.

 

Чего делать-то всетаки? В район придётся вбухивать бабки как в замысливаемое вначале ядро, а ядро сделать как "дешовый L2"? Или нуегонах этот "районный узел" и тащить весь пучок от всех домов чем-то вроде 96-волоконника в ядро?

 

Какой путь правильнЕе, если предположить услуги "только интернет" (внутрисетевой трафик неважно)? А если наоборот, закладываться в перспективе гонять мультикастовое IPTV?

[Sonne]

Доступ (дом) L2

Дистрибьюция (Район) L3

Ядро L2

 

На доступе L3 слишком дорого потому что мало абонентов.

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

что при количестве пользователей несколько сотен существенно снизит нагрузку на ядро.

 

Типа такого:

http://www.cisco.com/en/US/netsol/ns340/ns...6.shtml#wp18191

 

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

 

 

[masterovoj]

Доступ (дом) L2

Дистрибьюция (Район) L3

Ядро L2

...

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

что при количестве пользователей несколько сотен существенно снизит нагрузку на ядро.

...

Типа такого:

http://www.cisco.com/en/US/netsol/ns340/ns...6.shtml#wp18191

Так. А тогда DHCP-сервер тоже тащить на районный узел? Ну чтобы клиенту однозначно его IP назначать (исходя из его VLAN'а). Хотя судя по цисиковской схеме, сервера у них в ядре (ну, за ядром чтоли), что-то тут скрыто за текстом...

In addition, intelligent, protocol-aware features of Layer 3 switches will further contain broadcasts such as Dynamic Host Configuration Protocol (DHCP) by converting them into directed unicasts. These protocol-aware features are a function of the Cisco IOS® software, which is common to Cisco Layer 3 switches and routers.

Что это за protocol-aware features, которые function of the Cisco IOS® software? Ведь не только циски L3 бывают и стоят в подобных местах, должны же другие уметь эти protocol-aware features. Это типа "option 82" у них так шифруется что ли?

 

Тогда где эта "option 82" так сказать формируется. Ну кто её создаёт и отправляет - районный свич или домовой?

Если на домах нужны будут свичи с "option 82", то это ж дорого. И как она "проходит" через районный свич?

Значит на районном это должно быть. Тогда вроде понятно, что он номер VLAN'а в эту опцию запихать должен. Я правильно понимаю?

 

И ещё. Изначально я думал, что их всех изолируют по отдельности по VLAN'ам чтобы однозначно IP выдавать конкретному юзеру свой. И чтобы юзера не могли никуда лезьти, не дойдя до ядра. То есть чтобы ни соседу напакостить как-то, ни IP "поюзать" чей-то.

Выходит, нужно как-то резать на каждом VLAN'е все другие IP, кроме юзерского. Точнее исходящие "не ОТ его IP" и входящие "не НА его IP". И это тоже надо на районном свиче делать (резать)?

Районный свич начинает мне казаться каким-то довольно дорогим удовольствием даже на район:

- L3;

- ACL'ы;

- минимум 100, а лучше 256 VLAN'ов;

- Option 82;

- ифейс(ы) 1000X.

 

Так что ли?

Edited September 26, 2008 by masterovoj

[SmokerMan]

Зачем на районном Opt.82?

[Nafanya]

Доступ (дом) L2

Дистрибьюция (Район) L3

Ядро L2

...

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

что при количестве пользователей несколько сотен существенно снизит нагрузку на ядро.

...

Типа такого:

http://www.cisco.com/en/US/netsol/ns340/ns...6.shtml#wp18191

Так. А тогда DHCP-сервер тоже тащить на районный узел? Ну чтобы клиенту однозначно его IP назначать (исходя из его VLAN'а). Хотя судя по цисиковской схеме, сервера у них в ядре (ну, за ядром чтоли), что-то тут скрыто за текстом...

In addition, intelligent, protocol-aware features of Layer 3 switches will further contain broadcasts such as Dynamic Host Configuration Protocol (DHCP) by converting them into directed unicasts. These protocol-aware features are a function of the Cisco IOS® software, which is common to Cisco Layer 3 switches and routers.

Что это за protocol-aware features, которые function of the Cisco IOS® software? Ведь не только циски L3 бывают и стоят в подобных местах, должны же другие уметь эти protocol-aware features. Это типа "option 82" у них так шифруется что ли?

 

Тогда где эта "option 82" так сказать формируется. Ну кто её создаёт и отправляет - районный свич или домовой?

Если на домах нужны будут свичи с "option 82", то это ж дорого. И как она "проходит" через районный свич?

Значит на районном это должно быть. Тогда вроде понятно, что он номер VLAN'а в эту опцию запихать должен. Я правильно понимаю?

opt82 нужен на доступе, агрегирующий коммутатор(районный) должен лишь уметь dhcp relay.

И ещё. Изначально я думал, что их всех изолируют по отдельности по VLAN'ам чтобы однозначно IP выдавать конкретному юзеру свой. И чтобы юзера не могли никуда лезьти, не дойдя до ядра. То есть чтобы ни соседу напакостить как-то, ни IP "поюзать" чей-то.

Вы не поняли всей предлагаемой структуры. Подумайте ещё...

Выходит, нужно как-то резать на каждом VLAN'е все другие IP, кроме юзерского. Точнее исходящие "не ОТ его IP" и входящие "не НА его IP". И это тоже надо на районном свиче делать (резать)?

Зачем?

 

Районный свич начинает мне казаться каким-то довольно дорогим удовольствием даже на район:

- L3;

- ACL'ы;

- минимум 100, а лучше 256 VLAN'ов;

- Option 82;

- ифейс(ы) 1000X.

 

Так что ли?

ну ставьте L3 на 2 района, на 3, хоть на 10. лишь бы портов и производительности хватало :)

 

[SmokerMan]

Зачем dhcp relay на агрегации? :-)

[masterovoj]

Зачем на районном Opt.82?

Зачем dhcp relay на агрегации? :-)

Опять блин "казнить нельзя помиловать" :-)) Ну скажи уже, зачем? И... чтобы нам было понятно, "агрегация" и "район" одно и то же место, один и тот же свич, так да?

[SmokerMan]

Ну по терминологии принятой на форуме - агрегация, у тебя - район.

 

А Opt.82 должна быть на коммутаторе доступа (т.е. непосредственно перед абонентом). Работает она так - при запросе абонентом адреса по DHCP, коммутатор перехватывает запрос, добавляет в него свои данные (в частности номер порта с которого пришел запрос. mac и ip коммутатора, подробнее см. RFC) и *уникастом* передает на dhcp-сервер.

 

Зачем релей на агрегации не знаю, может кто и объяснит...

[masterovoj]

Тогда где эта "option 82" так сказать формируется. Ну кто её создаёт и отправляет - районный свич или домовой?

Если на домах нужны будут свичи с "option 82", то это ж дорого. И как она "проходит" через районный свич?

Значит на районном это должно быть. Тогда вроде понятно, что он номер VLAN'а в эту опцию запихать должен. Я правильно понимаю?

opt82 нужен на доступе, агрегирующий коммутатор(районный) должен лишь уметь dhcp relay.

Теперь понятно. Только от этого стало тока хуже. Хотелось-то ченить дешёвское на дома поставить, типа с shop.nag.ru. Какойнить 3ком 3300 или нортел 450-24, тому подобное. Но option 82 там нету.

 

Возникает мысль... а ну его нафиг это option 82? Не сделать ли такую штуку: завести эту тысячу VLAN'ов на серваке (тыщу vlan интерфейсов) и засадить на каждый VLAN отдельный dhcp, который на нём слушает и выдаёт ему... да, его конкретный IP.

Думается, это будет намного дешевле чем свич с option 82 на каждый дом.

 

И ещё. Изначально я думал, что их всех изолируют по отдельности по VLAN'ам чтобы однозначно IP выдавать конкретному юзеру свой. И чтобы юзера не могли никуда лезьти, не дойдя до ядра. То есть чтобы ни соседу напакостить как-то, ни IP "поюзать" чей-то.

Вы не поняли всей предлагаемой структуры. Подумайте ещё...

Не, я понял, что в цисковской схеме предполагается трафик "внутрирайонный" гонять прямо на районном свиче, не заводя его в ядро. Так? А я пишу что до этого я думал, что гоняет через ядро. Теперь понял, внутрирайонный через ядро не гоняет. Вот вся разница.

 

Выходит, нужно как-то резать на каждом VLAN'е все другие IP, кроме юзерского. Точнее исходящие "не ОТ его IP" и входящие "не НА его IP". И это тоже надо на районном свиче делать (резать)?

Зачем?

А насчёт резать. Ну а как же считать интернет-трафик юзера? Его же явно в ядре считать надо, и согласно IP юзера. Значит, если он назначит себе "соседский" IP, то за трафик насчитается соседу. Так? Следовательно, рэзать надо, так получается.

 

Районный свич начинает мне казаться каким-то довольно дорогим удовольствием даже на район:

- L3;

- ACL'ы;

- минимум 100, а лучше 256 VLAN'ов;

- Option 82;

- ифейс(ы) 1000X.

Так что ли?

ну ставьте L3 на 2 района, на 3, хоть на 10. лишь бы портов и производительности хватало :)

Вот! Вот ты сам по сути сводишь это в схему, про которую я высказался раньше

Или нуегонах этот "районный узел" и тащить весь пучок от всех домов чем-то вроде 96-волоконника в ядро?

то есть этот "L3 на 2 района, на 3, хоть на 10" он и получается ядро. И должно это дело стоять в ядре, в офисе.

А районные "агрегации" получаются неудобная и лишняя штука, которая к тому же сильно удорожает - само денег стоит и требует на домах дорогого железа. Кажется, начинаю понимать зачем нужны железяки типа 4006, 6500 с сотней-другой портов.

Edited September 26, 2008 by masterovoj

[Nafanya]

Думается, это будет намного дешевле чем свич с option 82 на каждый дом, да потом ещё dhcp relay на агрегации.

dhcp relay умеет каждый приличный L3 :)

 

А насчёт резать. Ну а как же считать интернет-трафик юзера? Его же явно в ядре считать надо, и согласно IP юзера. Значит, если он назначит себе "соседский" IP, то за трафик насчитается соседу. Так? Следовательно, рэзать надо, так получается.

не возьмёт, иначе просто ничего не увидит, а сосед даже и не заметит проблем.

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

 

то есть этот "L3 на 2 района, на 3, хоть на 10" он и получается ядро. И должно это дело стоять в ядре, в офисе.

А районные "агрегации" получаются неудобная и лишняя штука, которая к тому же сильно удорожает - само денег стоит и требует на домах дорогого железа. Кажется, начинаю понимать зачем нужны железяки типа 4006, 6500 с сотней-другой портов.

 

ну возможно мы говорим о разных масштабах "районов". Я не представляю как в нашем городе 250-ти тысячнике свести все дома в одну точку :)

Edited September 26, 2008 by Nafanya

[Nafanya]

ну и порыл поиск вообщем. это для вас :) http://forum.nag.ru/forum/index.php?showto...l=isc-dhcp+vlan

[Sonne]

в схеме vlan-per user opt -82 не нужно вобщем, потому что можно на влан давать целую подсеть и потом дальше ее натить в один IP адрес. Так же не требуется никаких секьюрных механизмов типа acl, привязки MAC в свиче. На доступе очень удобно короче, но на агрегацию накладывает требования. Хотя Б/У Cisco Catalyst 3550 легко тянет все эти требования.

 

Зато нужен dhcp-relay, который бродкастовые dhcp запросы от каждого влана преобразует в юникаастовые, которые можно по IP сети в любую точку мира отранслировать. Без этой функции придется на каждый узел агрегации ставить dhcp сервер.

 

Ядро это не железка которая стоит в офисе. Ядро это магистральная сеть, которая связываетя районы в разных частях города.

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

 

6500 4500 с кучей портов люди ставят на агрегацию, типа 100 домов в одну такую коробку.

 

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

[Дятел]

Остаётся вопрос, какая функциональность требуется от районного свича (SW_района)?

В той схеме, которую Вы нарисовали, мы в качестве узла района используем свич с 16 SFP, которые обеспечивают связь с нижележащими свичами, и который умеет 4К VLANов. Работает он в жутко простой конфигурации: все порты в транке, во всех все 4К VLANов.

 

[SmokerMan]

в схеме vlan-per user opt -82 не нужно вобщем, потому что можно на влан давать целую подсеть и потом дальше ее натить в один IP адрес. Так же не требуется никаких секьюрных механизмов типа acl, привязки MAC в свиче. На доступе очень удобно короче, но на агрегацию накладывает требования. Хотя Б/У Cisco Catalyst 3550 легко тянет все эти требования.

Объясните непонятливому... Мы что, на 3550 создадим столько ip интерфейсов, сколько абонентов?...

[Nafanya]

в схеме vlan-per user opt -82 не нужно вобщем, потому что можно на влан давать целую подсеть и потом дальше ее натить в один IP адрес. Так же не требуется никаких секьюрных механизмов типа acl, привязки MAC в свиче. На доступе очень удобно короче, но на агрегацию накладывает требования. Хотя Б/У Cisco Catalyst 3550 легко тянет все эти требования.

Объясните непонятливому... Мы что, на 3550 создадим столько ip интерфейсов, сколько абонентов?...

столько, сколько обслуживает абонентов эта 3550. (вроде 3550 позволяет до 1000svi )

[Andrеw]

можно еще взять ATx900, в нем заявлено 4к интерфейсов

[SmokerMan]

А как их создавать? Скрипт телнетом будет на него ходить?..

[masterovoj]

dhcp relay умеет каждый приличный L3 :)

А насчёт резать. Ну а как же считать интернет-трафик юзера? Его же явно в ядре считать надо, и согласно IP юзера. Значит, если он назначит себе "соседский" IP, то за трафик насчитается соседу. Так? Следовательно, рэзать надо, так получается.

не возьмёт, иначе просто ничего не увидит, а сосед даже и не заметит проблем.

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

Так. Объясните, пожалуйста как реализуется "иначе просто ничего не увидит"? Например, у Пети (10.0.0.1, VLAN1) сделано dhcp (венда). А Вася (VLAN2) прописал у себя статикой адрес соседа Пети (10.0.0.1). Что ему (Васе) мешает работать от имени 10.0.0.1 после этого? Где-то что-то должно как-то понять, что 10.0.0.1 нельзя быть во VLAN2? Что-то же должно его резать где-то?

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

 

Или резать или что-то типа прописывать на L3 все маршруты клиентских IP как-то жёстко только из/в "свой" VLAN, другого не вижу. Мне кажется что нагрузка от нескольких сотен маршрутов (и риск ошибки и сложности поддержки) больше, чем "просто рэзать". Может я не прав, объясните пожалуйста.

 

здесь было редактировано и удалён большой кусок моего бреда

Edited September 27, 2008 by masterovoj

[IvanI]

Если у вас умные свичи на доступе(типа des-3526) и есть голова то нафиг влан на юзверя, ведь можно сразу на порту все разрешить/запретить отфильтровать????

 

Если на доступе свичи кроме тегированых вланов ниче не умеют то влан на юзверя оправдан, юзверские вланы

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

 

п.с. на 3526 прибивается юзер к порту так:

разрешить на порту арп запрс/ответ от мака и ип юзера к ип пространству сегмента

разрешить дхцп запрос от мака юзера и ипа 0.0.0.0

запретить траф на вирусные порты

разрешить траф от ип и мака юзера

запретить все

5 профилей ~ 10 правил на 1 мак и можно оптимизировать

 

[Nafanya]

Если у вас умные свичи на доступе(типа des-3526) и есть голова то нафиг влан на юзверя, ведь можно сразу на порту все разрешить/запретить отфильтровать????

ага, а потом появляются подобные темы, где люди справедливо возмущаются "какого фига?"

http://forum.nag.ru/forum/index.php?showtopic=44962