Добрый день.

Возникла нестандартная задача по вланам. Вкратце это так:

Есть оконечные коммутаторы поключенные к центральному. На каждый порт оконечного коммутатора (кроме подключенного к центральному) привязан свой собственный влан. Весь трафик (уже тегированный 801.2q) идет на центральный, где сводится на один порт, в который включен сервер. Т.о. клиенты не видят друг друга, а только сервер. Схема работает прекрасно.

Но теперь возникла задача сделать так, чтобы некоторые порты оконечных коммутаторов могли видет друг друга, но при этом иметь разные вланы. В силу особенностей построения сети мы не можем:
а) внести все такие порты в один общий влан вместо персональных
б) прописать еще один влан (дополнительный) на эти порты.

Т.е. задача такая - на центральном коммутаторе произвести объединение трафика разных вланов (выборочно).

Вот.

Сейчас у нас стоит в качестве центрального - 3550, но если в нем этого нет, то можем его и заменить на соответствующий (это выходит
все равно дешевле, чем менять оконечные - их очень много)

Спасибо.

Как вариант, "поднимите" мост (bridge) между соответствующими VLAN'ами на сервере.

Этот вариант рассматривается, но как не очень удачный. Не хочется вещать доп. нагрузку на сервер.

Хотелось бы именно с помощью железного решения сделать это.

Вообще, задача сформулирована неясно.
Но если зотите, то вот вам ещё менее удачный вариант: соедините патч-кордом два (находящихся в разных VLAN'ах) порта одного свитча (замыкание VLAN'ов).
Только хоть убей, не понимаю, зачем это надо.

Хм, ну еще раз. На центральный коммутатор приходит уже тэгированный трафик и некоторые вланы нужно объединить, причем эти вланы имеют разные Vlan_ID.

Это-то как раз понятно, и решение тому предложено выше.
Непонятно другое: зачем вообще делить на VLAN'ы, а затем "смешивать"?

Есть существующая работающая схема сети. Так сложилось исторически. Каждый клиент работает только с сервером, но бывает иногда необходимость несколько человек объединить в группу.

В общем похоже простого решения нет ...

Ваша сеть изначально спроектирована на основе неверных принципов.
И как бы ни было больно, рано или поздно её придётся перестраивать. Это решение, конечно, не простое, но на мой взгляд самое правильное.

Чтобы клиенты из разных вланов могли общаться, тем более выборочно существуют маршрутизаторы, в них - acl листы. Это позволяет разрешить определенным лицам из одного влана (одной подсети) видеть определенные машины из другой подсети. Роль маршрутизатора может выполнять как свич 3 уровня, так и любой комп, подключенный к коммутатору (если большая нагрузка, можно использовать транк максимум из 2-х гигабитных портов, современные материнки способны справиться с такой нагрузкой).

Если вам надо разрешить свободное общение всех машин из влана 1 и влана 2 и при этом влан 1 и 2 принципиально ничем не отличаются, (например не требуется объединить вланы 1 и 3, но так, чтобы влан 2 не видел влан 3), то вам проще уничтожить влан 2 вообще и всех посадить на влан 1.

Как Вы можете говорить о неправильности построение сети, не зная принципов на которых она была построена? Это не просто обычная ЛВС на 10 компов. Их несколько сотен с отлаженной схемой авторизации/разделения доступа и прочее. И Вы предлагаете вот так взять и переделать работающую сеть? Бред.

В этой сети изначально нет обмена между рабочими станциями, да оно и не нужно для рабочего процесса. Каждый сотрудник терминируется на сервер (точнее их несколько - там отдельные сервисы). Зато нет никаких проблем с вирусами, или почему по сети идет непонятный трафик и главное - это схема работает не первый год и абслоютно устраивает как руководство, так сотрудников.
Давай-те все таки ближе к теме топика. Если Вы не знаете, как это сделать, то не нужно предлагать изначально неподходящие решения, я ведь четко обрисовал что нужно.
[/b]

Дык мы ведь тоже не "шиком" бриты: у меня также пара "сеток админится" - одна на три сотни "голов", другая - на три тысячи... И тоже знаете, рабочий процесс, сотрудники, разделение доступа, начальство...
Если вы изначально не подумали о возможной необходимости группировки пользователей, то чья в этом вина? Придётся взять на себя ответственность и признать, "так мол и так, накосячили, надо что-то менять". А дальше как водится: разработаете план-график необходимых мероприятий и - ноги_в_руки

А если говорить о бреде в "сеткостроении", то обычно он встречается в такой форме - огромная масса пользователей находится в едином широковещательном сегменте со всеми вытекающими. Вы же описываете полную крайнюю противоположность: каждый пользователь "колбасится" в своём собственном выделенном в отдельный VLAN сегменте!

Извиняйте, но если вам нужно объединить группу пользователей, то либо "сажайте" их в единый VLAN, либо организуйте бриджинг/роутинг между соответствующими VLAN'ами. - Хотя это вы и сами прекрасно знаете.

Других способов мэдицина нэ знает.
И дальнейшее продолжение дискуссии считаю контрпродуктивным.
Удачи.

Вообще-то это флуд ... давайте не будем переделывать мою сеть, вашу сеть или еще какую-то, так как Вы не знаете, что было в ТЗ на построение и какие задачи решает ЛВС. Сейчас есть только необходимость для очень ограниченного круга пользователей сделать указанную фичу и не более... переделывать сеть из 10 юзеров - это неправильно.
А в ТЗ на построение сети, кстати, одним из условий было - полная изолированность рабочего места! Кстати, и строил это не я, но тем не менее с этим подходом согласен.



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

p.s. Достаточно было сказать, то на длинке это сделать нельзя

На коммутаторах D-Link это сделать можно. Перезвоните пожалуйста в офис по телефону 744-00-99 доб.390.

Спасибо. Обязательно перезвоню, правда уже в начале следующей недели.