Имеется сабжевая железка, порты которой погрупированны по VLANам. За каждым портом находится порядка пары сотен клиентов. У каждого VLANа сетка класса /23. Но практически на половине портов есть по 1-4 клиентов с "белыми" АйПи, сетки класса /29. При этом на одном и том же порту могут быть клиенты из разных "белых" подсетей.

Сейчас вся эта схема реализуется при помощи дополнительного коммутатора, на котором применяется сегментация трафика для портов. Хочется все это несколько упростить и сделать одну "белую" сетку класса /27 или даже /26.

Для этого попробовал создать отдельный VLAN для такой сетки, поднял на сервере интерфейс с нужным VID, привязал один и тот же клиентский порт к разным VLAN как untaged. Но не тут-то было. Броадкасты с интерфейса в сеть уходят, но ответов от клиентов не получаю ес-но, так как у порта PVID другого ВЛАНа.

Вопрос: что можете подсказать по реализации такой ассиметричной сети и каков смысл вообще включать порт как нетэгирумый в несколько VLAN.

На устройствах L3 ассиметричные VLAN-ы вообще не применимы и не поддерживаются. Там всё реализуется при помощи маршрутизации + ACL для ограничения доступа между VLAN-ами.

Я догадывался, а вы только подтвердили мои догадки. Но остается 2-я часть вопроса: каков вообще смысл включать порт как нетэгируемый в несколько VLAN?

Смысл только в одном если у вас серверная сетевуха не поддерживает 802.1q. http://www.dlink.ru/technical/files/asy ... 20vlan.pdf

Бррр... Постом выше вы написали, что схема "а ля ассиметричные VLANы" на L3 не поддерживаются. Здесь же вы приводите полностью перпендикулярный пример.

Ведь именно эта схема и не работает - проверено, так как PVID у порта всегда один, а значит MAC сетевухи будет только в одном VLAN-е. Т.е. пакеты броадкастовые к ней будут приходить со всех VLAN-ов, а вот от неё - только в тот, к которой привязан её порт в коммутаторе.

Я Вам привёл общий пример по поводу Assymetric VLAN. Вы же спросили как это работает и зачем вообще.

К вопросу зачем вообще ......... .
Вообще-то очень удобная схема, жаль сейчас она всё меньше и меньше поддерживается.

Мы применяли, когда надо было чтобы группы пользователей друг друга не видели, а сервера видели все. (и всё это без маршрутизации ACL и т.д.).

схема проста:
серверный порт пинадлежит всем VLANам (например 1 , 2,3,4) PVID=4,
порты группы 1 принадлежит VLANам 1 и 4 PVID=1
порты группы 2 принадлежит VLANам 2 и 4 PVID=2
и т.д.

т.о. пакет от станции гр.1 попадает в VLAN1 и его слышат только согрупники и сервер. Всё, что отвечает сервер - попадает в 4-й VLAN и это слышат все, включая гр.1, а если это UNICAST ответ, то только соответствующая станция. С таблицами FDB тоже всё в порядке получается (лень аргументировать- поверте.)

На одиночном свитче именно так. А если у Вас группа свитчей и магистрали тегированные во всех VLAN-ах? Вот в этом случае если на каждом порту который untagged в нескольких VLAN-ах не прописать статически в каждом VLAN-е MAC-адреса хоста то трафик при определённых условиях может попадать из VLAN-а в VLAN. Тоже поверьте тестировали и не раз. Подчёркиваю на L3 свитче это вообще не нужно.

Согласен, проблемы есть. Поэтому и схема эта ушла в прошлое, правда не очень понял причем тут тегированные магистрали?
Как я понимаю основная проблема в том, что раньше свичи вели единую FDB на все VLANы (т.е mac;port;vlan) и свич "знал" на каком порту находится MAC получателя и просто сравнивал принадлежит ли порт нужному VLANу. Если да, то Forwad, если нет - drop. Сейчас же свичи в основном ведут отдельную FDB для каждого VLANa и соотв. например в VLANe 4 (см. пример в постах выше) свич "не знает" и главное никогда не узнает где находится МАС получателя и соответственно будет флудить все UNICAST пакеты во все порты 4-го VLANа. Поэтому тут нужны Static MAC, а это для сети больше 1-го свича уже мало жизненно.

А относительно "в L3 свичах это вообще не нужно" предлагаю заменить “вообще” на “почти” потому как не ясно что делать с IPX,APPLETALK и т.д. ? (Кстати мы IPX юзаем весьма и весьма).

Ну а зачем эта схема (untag порт в нескольких VLAN ах) оставлена сейчас – думаю, в том числе и для всяких экзотических штучек с не IP протоколами, например такая экзотика как IPX трапы от устройств в нескольких невзаимосвязанных VLANах.

А что вам мешает в этом случае применять протокол 802.1v Protocol-Based VLAN?

А как при этом сделать чтобы одна группа по ipx не видела другую?

Это уже сложнее. Если на доступе то в принципе Traffic Segmentation должен помочь.

Вот именно эта схема у меня и не получается. А нужно. Пока подготовил порт на свиче для экспериментов, теперь нужно часа 2 свободного времени. Но в рамка форума этот вопрос не "лечится" (имеется в виду время)

Описываю проблему еще раз:

На 1 порту 2 клиента, с адресами соответственно 10.0.168.1 и 198.160.40.66. На 23 порту (находится в одном VLAN-е с портом 1) поднят шлюз 10.0.168.254. А на 24 порту тоже шлюз, но для другого клиента - 198.160.40.65 (сетка 198.160.40.64/29), но VLAN там другой и завести его в один и тот же VLAN с 1 и 23 портом - не могу по причине того, что эти "белые" адреса с этой сетки разбросаны и по другим VLAN-ам тоже. Как заехали в такое болото - лучше не спрашивайте, вопрос стоит как можно выехать из этого болота с меньшими потерями.

Перезвоните пожалуйста в офис по телефону 744-00-99 доб.390.

А код города 044 или +7-495?