Назад | Перейти на главную страницу

Есть ли способ передать кадры с тегами VLAN через управляемый коммутатор?

В настоящее время у меня есть управляемый коммутатор (DGS-3120-24SC), настроенный для частных VLAN (вторичные и первичные группы портов). Вторичные порты изолированы друг от друга, и пересылка между ними невозможна. Однако они могут связываться со всеми первичными портами (восходящие каналы). Я бы хотел прозрачно передавать пакеты с тегами VLAN между устройствами, подключенными к первичному и вторичному портам.

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

Казалось бы, что в основном мне нужно VLAN Trunking, но, к сожалению, он не работает вместе с настройкой Private VLAN (изолированные вторичные + случайные порты).

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

Коммутатор поддерживает множество функций, включая теги Q-in-Q, транкинг и т. Д.

Я случайно снова попал на эту страницу, поэтому решил ответить на свой вопрос. Я нашел решение, которое работает уже довольно давно: желаемая функциональность достигается за счет использования функций коммутатора сегментации трафика и транкинга VLAN. Сегментация трафика позволяет разрешить или запретить пересылку трафика между портами (в любой конфигурации), а транкинг VLAN позволяет разрешить тегированным пакетам проходить через коммутатор без изменений. Эти функции можно настраивать довольно гибко, потому что вы можете управлять отдельными портами.

Я никогда не использовал его на практике и могу ошибаться, но похоже, что DLINK позволяет нетегированному порту участвовать в нескольких VLAN - на основе концепции «асимметричной VLAN».

Если это так, порт сервера будет немаркирован, но настроен с IP-псевдонимами для участия в логических подсетях VLAN.

ftp://ftp.dlink.es/FAQs/TS_AV.pdf

В преобладающем дизайне решения, т.е. если последние сведения о коммутаторах не связаны с какой-то новой теории, для изменения идентификатора vlan требуется, чтобы пакет прошел через маршрутизатор L3.

Если ваш клиент и сервер находятся в одной подсети IP, пакет не будет проходить через маршрутизатор L3. Если они также находятся в разных VLAN, они не смогут связаться друг с другом.

Но если они находятся в разных IP-подсетях (L3), дизайн сети обычно также связывает эти подсети с отдельными идентификаторами vlan (L2). Затем нужно разрешить IP-маршрутизацию (то есть L3) помещать пакеты в правильный vlan в процессе маршрутизации. Ваши серверы, которые принимают пакеты с тегами vlan, обычно имеют IP-адрес для каждого идентификатора vlan, который он принимает, каждый из которых принадлежит подсети IP, связанной с соответствующим vlan. Ваши маршрутизаторы будут способствовать доступности клиентов в других vlan ID / подсетях.

Таким образом, маршрутизация - это либо ключ к вашему решению, либо дизайн таков, что vlan, на которые вы смотрите, не «предназначены» для связи. В этом случае вы можете изменить этот дизайн.

Иными словами, коммутаторы vlan добавляют теги vlan на выходе и удаляют их при входе. Вы не меняете эту основную предпосылку и не добавляете ее, если у вас действительно нет продуманного требования к дизайну и решения (см. Ссылку QinQ ниже). Для переключения между идентификаторами vlan вы используете IP-адрес вышележащего протокола, то есть, скорее всего, ваш шлюз по умолчанию (ближайший маршрутизатор).

Если этот ответ не имеет смысла, поищите здесь хорошее обсуждение базовой теории vlan и того, как L2 и L3 взаимодействуют с точки зрения vlan: Как работают VLAN?

Для великолепного обсуждения теории IP-подсетей, то есть перспективы L3, посмотрите здесь: Как работает подсети IPv4?

Если это не то, что вы хотите и по-прежнему хотите использовать QinQ, потому что вы все это знали, прочтите последнюю часть «Проблемы ...» в следующей ссылке. Если у вас не было проблем с их пониманием и у вас уже были ответы на них (я не знаю, поскольку я никогда не делал мосты между поставщиками), выбейте себя: http://en.wikipedia.org/wiki/IEEE_802.1ad