Что происходит, когда потребительский коммутатор получает кадр Ethernet с меткой VLAN?

Предположим, что вы подключаете магистральный порт от сетевого коммутатора с поддержкой VLAN к сетевому коммутатору потребительского уровня (не совместим с VLAN) через прямой кабель. Теперь первый коммутатор отправляет последнему коммутатору кадр Ethernet с меткой 802.1Q. Что должен делать более поздний переключатель? Оставить кадр? Переслать кадр? Неопределенное поведение?

Если поведение не определено, что наиболее вероятно?

Изменить: Спасибо за ваши ответы. Подводя итог, поведение потребительского коммутатора зависит от:

Как он обрабатывает кадры 0x8100в поле EtherType ¹
Как он обрабатывает гигантские кадры или кадры с полезной нагрузкой больше 1500 байт

В Википедии есть хорошая диаграмма, сравнивающая не отмеченный и помеченный кадр Ethernet:

Есть сообщения о том, что некоторые коммутаторы потребительского уровня отлично пропускают кадры с метками VLAN.

_{¹ или более точно, где поле EtherType ожидается для кадров без тегов}

— netvope
источник

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

— Майк Пеннингтон,

Ответы:

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

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

Имейте в виду, что Ethernet фактически поддерживает много разных типов кадров на одном и том же проводе. Это было разработано, чтобы быть довольно гибким о том, что он может сделать.

— Zoredache
источник

Если коммутатор не знает тип Ether, используемый для помеченных кадров, он будет обрабатывать его так, как если бы он был обычным типом Ether. Это в основном будет работать, но может не работать при сложных настройках, когда порт назначения зависит как от MAC, так и от тега. Например, если вы устанавливаете мостовой межсетевой экран между двумя помеченными VLAN, коммутатор без поддержки VLAN может отправлять некоторые пакеты в неправильном направлении. Помимо этого очевидной проблемой, которая может возникнуть, является потеря пакетов, поскольку они превышают максимальный размер нетегированных кадров.

— Касперд

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

редактировать: для уточнения: Стандартный размер кадра Ethernet IEEE 802.3 составляет 1518 байт, 802.3Q добавляет 4 байта к кадру, поэтому общий MTU составляет 1522 байта, что может быть слишком большим для некоторых коммутаторов.

— PFO
источник

Не могли бы вы рассказать, какие большие фреймы Ethernet имеют отношение к тегированию VLAN 802.1Q?

— Мартейн Химельс

Вы говорите, что тег сделает кадр слишком большим?

— Шейн Мэдден

@ShaneMadden Некоторые реализации 802.1q увеличивают эффективный MTU до 1522b для помеченных кадров, который будет сброшен коммутаторами только с 1500b MTU.

— sysadmin1138

+1 для sysadmin1138 и +1 для pfo: некоторые старые коммутаторы будут отбрасывать помеченные кадры, потому что 802.1q увеличил MTU Ethernet.

— Эван Андерсон

Маркировка VLAN увеличивает максимальный размер кадра на 4 байта, поэтому он больше 1518 байтов и по определению является "гигантским" кадром.

— пфо

Коммутатор потребительского класса попытается переадресовать MAC-адрес фрейма-назначения - все, что его волнует. Если MAC-адрес назначения отсутствует в его таблице CAM, он заменит кадр из всех своих портов, кроме того, с которого был получен пакет.

Переключатель , который использует Cut Through метод переадресации, безусловно , вперед кадр, так как он начинает пересылку как только назначения MAC - адрес считывается -Даже если общий размер кадра больше , что MTU -since этом не может рассчитать размер кадра с этим методом пересылки.

Переключатель, основанный на методе Store And Forward , вероятно (при условии, что размер кадра <= MTU) будет делать то же самое, если с FCS все в порядке.

Если 802.1Q-неспособный коммутатор соединяет конечные устройства, устройства получат кадр и отбросят его, поскольку они не «знают», как обрабатывать кадры 802.1Q (тип 0x8100).

Я размышляю, если коммутатор потребительского класса соединяет коммутаторы с поддержкой 802.1Q ( ужас! ), Кадры будут пересылаться и обрабатываться 802.1Q - конечно, так долго, как они принимаются на магистральных портах.

— dkaragasidis
источник

Эх. Конечные устройства Linux отлично справляются с помеченными кадрами. Я видел, как они это делают.

— Zan Lynx

@ZanLynx Правда. Хотя конечные устройства не должны обрабатывать помеченные кадры, вы пропускаете всю точку VLAN, настраивая конечные устройства для приема и обработки кадров 802.1q.

— dkaragasidis

FCS = быстрое переключение каналов? Что определяет, в порядке ли «ФТС»?

— нетвоэп

@netvope: FCS - последовательность проверки фреймов: en.wikipedia.org/wiki/Frame_check_sequence

— Эван Андерсон,

@dkaragasidis Есть совершенно веские причины для настройки некоторых хостов на использование помеченных фреймов. Но лучше убедиться, что тегирование VLAN отключено на портах, обращенных к хостам, для которых вы не хотите использовать тегированные кадры. Причины использования помеченных фреймов на хосте Linux включают роль маршрутизатора между VLAN или сервера, который должен быть доступен для клиентов из разных VLAN.

— Касперд