[Rover]

А как борется народ с увеличением кол-ва VLAN в сети построенной на ethernet основе? xDSL в режиме бриджей, ADSL, клиенты подключающиеся к свичам напрямую?

 

На каждого клиента (говорим не о домашних пользователях, которых можно и в одном вилане держать, а об конторах) заводить свой отдельный вилан? Представляю я себе конфиги циски, когда там под сотню виланов описано.... :) Есть другие варианты?

[Nag]

Представляю я себе конфиги циски, когда там под сотню виланов описано.... :) Есть другие варианты?

 

Э... MPLS

Впрочем, для киские есть тулза упрощающая прописывание виланов - VTP.

Ее должно хватить в правильной сети...

[Rover]

Тулза хороша, но она в паре с рутером не дружит. Т.е. банально - моя c2650 не видит VTP-домен, организованый на cat2950. Т.е. опять ручками... Насколько я понял cisco.com/search и не поймет.

[serv]

знаю как на D-Link-е все сделатьэ.

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

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

Хотелось бы по точнее задачку рассмоттреть...

[Rover]

Банальный пример: есть две, три, четыре,....сто организации, которые разными схемами (ADSL, напрямую в свичи, xDSL bridge) включены в конечном итоге в одну Ethernet-среду. Если эти организации включить в один вилан, то нет гарантии что их IP-адреса не пересекутся. Заводить на каждого клиента свой вилан?, а если их больше 100,200? Как вариант - уйти от использования бриджей, и ставить только рутеры. Либо рутить циской через транк, только я не представляю себе циску(точнее ее цену), которая будет рутить не 16 (как в другом топике спрашивали) виланов, а с сотню, другую.

[serv]

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

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

Хотя если честно то задача конечно же сложноватая...

[serv]

ну я думаю, что если более глубже изучить данную проблемму то можно решить эту задачу..

[Nag]

serv,

знаю как на D-Link-е все сделатьэ.

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

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

 

Это называются виланы на портах.

Только получится не безопасность и управляемость, а извините, херня полная. :-) Просто из определения виланов на портах... Годится для схемы с рутером и одним коммутатором, и не больше.

 

Rover,

Заводить на каждого клиента свой вилан?, а если их больше 100,200? Как вариант - уйти от использования бриджей, и ставить только рутеры. Либо рутить циской через транк, только я не представляю себе циску(точнее ее цену), которая будет рутить не 16 (как в другом топике спрашивали) виланов, а с сотню, другую.

 

Хм... Надо смотреть схему.

Если тут ДСЛ завязан, то наверно надо рутер использовать. Какие ДСЛАМы? Нормальные совсем не слабо рутить умеют.

Хотя теряюсь без схемы - надо рисовать.

Впрочем, Сиска способная рутить сотню виланов не выглядит совсем монстром - 7200 справится. Хотя от нагрузки это зависит...

В общем, тут надо не с кондачка. ;-)

[Rover]

Тут даже схему представлять почти не нужно. Возьмем простейший вариант - построена разветвленная Ethernet по городу(по району). Помимо квартир она попадает и в офисы контор. Сомневаюсь, что контора будет подключаться с целью получения ресурсов локалки, а следовательно контору нужно выводить в отдельный вилан и либо давать инет по PPPoE(pptp,...) либо рутить через транк на циске. Вот когда таких контор становиться много (ведь сеть покрывает большую часть жилых домов и близлежащих офисов), то и встает вопрос с кол-вом виланов. Хотя я тут подумал, если у меня с сотню, другую корпоративщиков, то и платить они будут не 10-20 у.е., а совершенно другие деньги, которые соответсвенно позволят и железо другое поставить. :)

 

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

[pkozik]

serv,

 

Это называются виланы на портах.  

Только получится не безопасность и управляемость, а извините, херня полная. :-) Просто из определения виланов на портах... Годится для схемы с рутером и одним коммутатором, и не больше.  

 

Э неее, не путай. То что у D-link называется traffic segmentation не есть port-based vlan. Эту фичу можно как угодно сложно настраивать даже в рамках одной 802.1q vlan. При этом настраивай как угодно - 2 порт работает только с 1, 3 только с 1 и 4, а 5 только со вторым и т.д. А ну попробуй такое на чем-нибудь с port-based сделать. Кроме того, 802.1q при этом так-же работает, пожалуйста дроби сеть на сегменты.

[Nag]

Эту фичу можно как угодно сложно настраивать даже в рамках одной 802.1q vlan. При этом настраивай как угодно - 2 порт работает только с 1, 3 только с 1 и 4, а 5 только со вторым и т.д.

 

А разве port-based vlan работают как-то по другому?

То же проиизвольная комбинация портов возможна...

И 802.1й через них может работать - потому как коммутатор ничего про это не знает... Только какой смысл в портовых виланах в центре, если даже на переферии есть 802.1? ;-)

[pkozik]

Traffic segmentation позволяет для _каждого_ из 24 портов задать возможность работы с оставшимися 23 портами. Ну не port-based vlan это! Похоже, но не оно! :)

 

См. пример конфигурации:

 

config traffic_segmentation 1,6-26 forward_list 1-26

config traffic_segmentation 2 forward_list 1,3,5,9-11,13-26

config traffic_segmentation 3 forward_list 1,3,7-26

config traffic_segmentation 4 forward_list 2-4,8-26

config traffic_segmentation 5 forward_list 1,3,5,8-26

 

Теперь цель. Она именно такая как и писал автор темы - много коммерческих организаций, которым локальная сеть не нужна, но сидят на одном коммутаторе. Для нескольких десятков фирм создавать 802.1q vlan накладно - ip адреса как-бы лимитированы (естественно случай с реальной адресацией, а не с серой). Опять-же не всегда, но нужны фирмам реальные адреса. Кроме того разбив сеть на 802.1q vlan приходится ставить маршрутизатор, что все-же хорошо, но именно если это аппаратное решение. В данном-же случае - одна IP сеть, и нет нужды ставить маршрутер, что не всегда возможно.

 

И взаимодействие с 802.1q - port based коммутаторы не позволят тебе кроме пропускания маркированных пакетов что-то сделать, тут-же полноценный 802.1q, с возможностью более детальной настройки под задачу

[Nag]

Traffic segmentation позволяет для _каждого_ из 24 портов задать возможность работы с оставшимися 23 портами. Ну не port-based vlan это! Похоже, но не оно! :)  

 

Хм. Именно это я всегда понимал под port-based vlan :-)

В чем отличие-то? То что можно задать много портов куда отправялется с каждого, а не только один "серверный"? Так последнее будет уже не port-based vlan, а вообще какое-то извращение. :-)

 

Для нескольких десятков фирм создавать 802.1q vlan накладно - ip адреса как-бы лимитированы (естественно случай с реальной адресацией, а не с серой). Опять-же не всегда, но нужны фирмам реальные адреса.

 

Но у port-based vlan, как их не называй, все равно остаются проблемы:

1. Они не работают в разветвленной сети, так как каждый коммутатор знает только про свои виланы. Т.е. вариант фирмы с одним коммутатором. ;-)

2. Они не обеспечивают секьюрность нормальную, так как например входящие бродкасты точно попадают ко всем. :-) Еще, есть данные что для

выхода из такого вилана достаточно руками прописать на компе АРП-таблицу.

Это точно верно для Суриков кажется, не знаю насчет Длиннков.

[pkozik]

Хм. Именно это я всегда понимал под port-based vlan :-)

В чем отличие-то? То что можно задать много портов куда отправялется с каждого, а не только один "серверный"? Так последнее будет уже не port-based vlan, а вообще какое-то извращение. :-)

Про что и речь! Главное отличие - порт может входить во много групп одновренменно. В port-based только в одну.

 

1. Предназначено для подключения _конечного_ абонента, а не для управления на магистрали. Поскольку работает в паре с 802.1q, то тегированные аплинки можно делать как обычно, и каскадировать как угодно.

2. С безопасностью не все так просто. Для того, чтобы настроить статик АРП надо сперва узнать МАСи...

Да и DES-3226S позволяет производить фильтрацию передаваемого трафика. При чем на 2, 3 и 4 уровне.

 

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

[pkozik]

Кстати, еще уточнение про traffic segmenatation. Чтобы было ясно, что это не реализация как у шурика.

 

Нарисую конфигурацию:

config traffic_segmentation 1,6-26 forward_list 1-26

config traffic_segmentation 2-4 forward_list 1

config traffic_segmentation 5 forward_list 6-26

 

Написано буквально следующее:

Пакеты с 1 порта(а так-же 6-26 которые я пропущу), в том числе и широковещательные, можно _передавать_ на все остальные порты с 1 по 26 включительно.

С 2-4 портов передаются пакеты только на 1 порт.

5 _передает_ только на 6-26, но при этом он _принимает_ пакеты с 1 порта, поскольку это так настроено в данном примере.

 

При проверке можно это все четко сниффером проследить.

В данной ситуации думаю ясно, что прописывание arp на машине ничего не даст...

[ASM]

Хотя я тут подумал, если у меня с сотню, другую корпоративщиков, то и платить они будут не 10-20 у.е., а совершенно другие деньги, которые соответсвенно позволят и железо другое поставить. :)

 

Использовать связку роутер + коммутатор с поддержкой VLAN.

[Nag]

pkozik,

При проверке можно это все четко сниффером проследить.  

В данной ситуации думаю ясно, что прописывание arp на машине ничего не даст...

 

Совсем не очевидно.

Вопрос ведь не в способе записи, а в конкретной реализации избранности передачи.

Как я это себе представляю. Матрица коммутации сейчас используется везде с общей шиной, вроде так? При отправки кадра на шину (точнее части кадра, но это не важно) ему назначается тег порта-назначения в соответствии с САМ-таблицей.

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

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

А вот что реализовано в Длинке - не знаю. Но почему-то есть определенные подозрения, что все пошло по пути шурика. Хотя - вполне допускаю иной механизм действия.

 

5 _передает_ только на 6-26, но при этом он _принимает_ пакеты с 1 порта, поскольку это так настроено в данном примере.

 

Допустимость таких комбинации, вообще говоря, не сильно хорошо. Работать-то не будет узел. :-) Впрочем не суть - я так и не понял из записи конфига, почему 5 порт принимает только с 1-го? Вроде 6 ничем не хуже.

И второе - не вижу никаких принципиальных отличий от шурика (на уровне механизма а не способа записи), и не вижу противоречи определению "вилан на портах" - если это буквально вилан на портах. Пусть у шурика что-то кастрированное так называется - это не причина. ;-)))