Що відбувається, коли споживчий комутатор отримує кадр Ethernet з міткою VLAN?

Припустимо, ви підключите магістральний порт від мережевого комутатора, що підтримує VLAN, до мережевого комутатора (недієздатного VLAN) через мережевий комутатор. Тепер колишній комутатор надсилає пізнішому комутатору кадр Ethernet з міткою 802.1Q. Що слід робити пізніше? Скинути кадр? Вперед кадр? Невизначена поведінка?

Якщо поведінка не визначена, що найбільш вірогідне?

Редагувати: Дякую за відповіді. Підсумовуючи, поведінка перемикача споживачів залежить від:

Як обробляються кадри з 0x8100полем EtherType ¹
Як він обробляє джамбо-кадри або кадри з корисним навантаженням більше 1500 байт

У Вікіпедії є хороша діаграма, в якій порівнюється кадр без тегів і тегів Ethernet:

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

_{¹ або точніше, де очікується поле EtherType для нетегірованних кадрів}

— netvope
джерело

Я сподіваюся, що ви не питаєте, сподіваючись десь використати вказаний споживчий перемикач у виробничій стійці ...

— Майк Пеннінгтон

Відповіді:

Я насправді бачив це на перемикачі cheapo. Хтось підключив перемикач між магістральним портом, який мав пару вланів. Кадри були передані непорушним тегом vlan. Інші порти на цьому комутаторі, де можна використовувати без тегів vlan.

Комутатору потрібно лише mac-джерело / місце призначення, щоб вирішити, до яких портів переслати кадри, тому це не надто дивно, але тегований кадр все ще має джерела та призначення маків у тому самому місці в заголовку кадру.

Майте на увазі, що Ethernet насправді підтримує багато різних типів кадрів на одному дроті. Він був розроблений, щоб бути досить гнучким щодо того, що він може зробити.

— Зоредаче
джерело

Якщо комутатор не знає типу ефіру, який використовується для тегів кадрів, він обробляє його так, як якщо б це був звичайний тип ефіру. Це в основному спрацює, але це може вийти з ладу в складних установках, де порт призначення залежить як від MAC, так і від тегу. Наприклад, якщо ви встановите мостичний брандмауер між двома тегами VLAN, комутатор без підтримки VLAN може надіслати деякі пакети в неправильному напрямку. Окрім очевидної проблеми, яка може статися, є скидання пакетів, оскільки вони перевищують максимальний розмір нетазованих кадрів.

— kasperd

Зазвичай надмірно великі Ethernet-кадри можуть бути і відкидаються. За наявності таких речей, як кадри розміру джамбо, великі кадри Ethernet важко визначити, тому це насправді залежить - але відмова буде, мабуть, найбільш частою поведінкою.

редагувати: Для розробки: Стандартний розмір кадру IEEE 802.3 Ethernet становить 1518 байт, 802.3Q додає 4 байти до кадру, тому загальна MTU становить 1522 байти, що може бути занадто великим для деяких комутаторів.

— пфо
джерело

Не могли б ви пояснити, які великі кадри Ethernet стосуються тегів 802.1Q VLAN?

— Martijn Heemels

Ви кажете, що тег зробить кадр занадто великим?

— Шейн Мадден

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

— sysadmin1138

+1 для sysadmin1138 та +1 для pfo: Деякі старі комутатори будуть відкидати теги, оскільки 802,1q збільшив MTU Ethernet.

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

Позначення VLAN збільшує максимальний розмір кадру на 4 байти, тож він перевищує 1518 байт і, за визначенням, є "jumbo" кадром.

— pfo

Комутатор споживчого класу намагатиметься переслати MAC-адресу кадру-визначення, що це лише все, що йому важливо. Якщо MAC-адреса призначення не знаходиться в таблиці CAM, вона перекриє кадр з усіх своїх портів, крім того, з якого отримано пакет.

Перемикач, який використовує метод переадресації " Cut Through" , безумовно, пересилає кадр, оскільки він починає переадресацію, як тільки зчитується MAC-адреса призначення - навіть якщо загальний розмір кадру перевищує MTU - оскільки він не може обчислити розмір кадру за допомогою цього способу переадресації.

Перемикач на основі технології Store And Forward , ймовірно, (поки розмір кадру <= MTU) зробить те саме, доки FCS буде OKAY.

Якщо перемикач 802.1Q, який не працює, з'єднує кінцеві пристрої, пристрої отримають кадр та відкинуть його, оскільки вони не "знають", як обробити кадри 802.1Q (тип 0x8100).

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

— dkaragasidis
джерело

Е-е. Пристрої кінцевої точки Linux обробляють позначені кадри просто чудово. Я бачив, як вони це роблять.

— Зан Лінкс

@ZanLynx Правда. Хоча пристрої кінцевої точки не повинні обробляти позначені кадри, ви пропустите всю точку VLAN, налаштувавши кінцеві пристрої для прийому та обробки кадрів 802.1q.

— dkaragasidis

FCS = швидке перемикання ланцюга? Що визначає, чи "FCS добре"?

— netvope

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

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

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

— kasperd