Was passiert, wenn ein Consumer-Switch einen Ethernet-Frame mit VLAN-Tag empfängt?

Angenommen, Sie verbinden einen Trunk-Port von einem VLAN-fähigen Netzwerk-Switch über ein Direktkabel mit einem (VLAN-unfähigen) Consumer-Netzwerk-Switch. Jetzt sendet der frühere Switch dem späteren Switch einen 802.1Q-gekennzeichneten Ethernet-Frame. Was soll der spätere Schalter tun? Rahmen fallen lassen? Frame weiterleiten? Undefiniertes Verhalten?

Was ist am wahrscheinlichsten, wenn das Verhalten undefiniert ist?

Edit: Danke für deine Antworten. Zusammenfassend hängt das Verhalten des Consumer-Switches ab von:

Wie es mit Frames 0x8100im EtherType-Feld umgeht ¹
Wie es mit Jumbo-Frames oder Frames mit einer Nutzlast von mehr als 1500 Bytes umgeht

Wikipedia hat ein schönes Diagramm , in dem ein nicht getaggter und ein getaggter Ethernet-Frame verglichen werden:

Es gibt Berichte, dass einige Switches für Endverbraucher VLAN-gekennzeichnete Frames problemlos passieren.

_{¹ oder genauer gesagt, wo ein EtherType-Feld für nicht markierte Frames erwartet wird}

— netvope
quelle

Ich hoffe, Sie fragen nicht in der Hoffnung, den genannten Verbraucherschalter irgendwo in einem Produktionsregal zu verwenden ...

— Mike Pennington

Antworten:

Ich habe das tatsächlich an einem Billigschalter gesehen. Jemand hatte einen Switch zwischen einem Trunk-Port angeschlossen, der ein paar Vlans hatte. Die Frames wurden mit intakter VLAN-Kennzeichnung weitergeleitet. Die anderen Ports an diesem Switch konnten das nicht getaggte VLAN verwenden.

Ein Switch benötigt nur den Quell- / Ziel-Mac, um zu entscheiden, an welche Ports die Frames weitergeleitet werden sollen. Dies ist also nicht allzu überraschend. Ein mit Tags versehener Frame verfügt weiterhin über Quell- und Ziel-Macs an derselben Position im Frame-Header.

Beachten Sie, dass Ethernet tatsächlich viele verschiedene Rahmentypen auf demselben Kabel unterstützt. Es wurde entwickelt, um ziemlich flexibel zu sein, was es kann.

— Zoredache
quelle

Wenn der Switch den für getaggte Frames verwendeten Ether-Typ nicht kennt, verarbeitet er ihn wie einen normalen Ether-Typ. Das funktioniert meistens, kann aber bei komplizierten Setups fehlschlagen, bei denen der Zielport sowohl vom MAC als auch vom Tag abhängt. Wenn Sie beispielsweise eine Bridging-Firewall zwischen zwei getaggten VLANs installieren, kann der Switch ohne VLAN-Unterstützung einige Pakete in die falsche Richtung senden. Ein anderes offensichtliches Problem ist, dass Pakete verworfen werden, weil sie die maximale Größe von nicht getaggten Frames überschreiten.

— Kasperd

In der Regel können zu große Ethernet-Frames verworfen werden. In Gegenwart von Dingen wie Jumbo-Frames sind große Ethernet-Frames schwer zu definieren, es kommt also wirklich darauf an - aber das Verwerfen wird wahrscheinlich das häufigste Verhalten sein.

Bearbeiten: Zur Erläuterung: Die Standard-IEEE 802.3-Ethernet-Frame-Größe beträgt 1518 Bytes. 802.3Q fügt dem Frame 4 Bytes hinzu, sodass die MTU insgesamt 1522 Bytes beträgt, was für einige Switches möglicherweise zu groß ist.

— pfo
quelle

Können Sie erläutern, was große Ethernet-Frames mit 802.1Q-VLAN-Tagging zu tun haben?

— Martijn Heemels

Wollen Sie damit sagen, dass das Tag den Frame zu groß machen würde?

— Shane Madden

@ShaneMadden Einige 802.1q-Implementierungen erhöhen die effektive MTU auf 1522b für getaggte Frames, die von Switches mit nur einer 1500b-MTU verworfen werden.

— sysadmin1138

+1 für sysadmin1138 und +1 für pfo: Einige alte Switches verwerfen getaggte Frames, da 802.1q die Ethernet-MTU erhöht hat.

— Evan Anderson

Durch VLAN-Tagging wird die maximale Frame-Größe um 4 Byte erhöht, sodass sie größer als 1518 Byte ist und per Definition ein "Jumbo" -Frame ist.

— pfo

Der Switch der Consumer-Klasse versucht, die Frame-Ziel-MAC-Adresse weiterzuleiten. Wenn die Ziel-MAC-Adresse nicht in der CAM-Tabelle enthalten ist, wird der Frame aus allen Ports geflutet, mit Ausnahme des Ports, von dem das Paket empfangen wurde.

Ein Switch, der die Cut Through- Weiterleitungsmethode verwendet, leitet den Frame definitiv weiter, da er mit der Weiterleitung beginnt, sobald die Ziel-MAC-Adresse gelesen wurde, auch wenn die Gesamtgröße des Frames größer als die MTU ist, da die Größe nicht berechnet werden kann des Rahmens mit dieser Weiterleitungsmethode.

Ein Switch, der auf der Store And Forward- Technik basiert , wird wahrscheinlich (solange die Frame-Größe <= MTU ist) dasselbe tun, solange der FCS OKAY ist.

Wenn der nicht 802.1Q-fähige Switch Endgeräte miteinander verbindet, empfangen die Geräte den Frame und verwerfen ihn, da sie nicht wissen, wie 802.1Q-Frames (Typ 0x8100) verarbeitet werden.

Ich spekuliere, wenn der Switch der Consumer-Klasse 802.1Q-fähige Switches miteinander verbindet ( der Horror! ), Werden die Frames vom 802.1Q weitergeleitet und verarbeitet, solange sie an den Trunk-Ports empfangen werden.

— dkaragasidis
quelle

Eh. Linux-Endgeräte können problemlos mit getaggten Frames umgehen. Ich habe gesehen, wie sie es getan haben.

— Zan Lynx

@ ZanLynx True. Obwohl Endpunktgeräte nicht werden soll , um Griff getaggten Frames verpassen -Sie den ganzen Punkt von VLANs durch das Konfigurieren von Geräten Endpunktes zu empfangen und 802.1q Frames zu verarbeiten.

— dkaragasidis

FCS = Fast Circuit Switching? Was bestimmt, ob "der FCS in Ordnung ist"?

— Netvope

@netvope: FCS - Frame-Check-Sequenz: en.wikipedia.org/wiki/Frame_check_sequence

— Evan Anderson

@dkaragasidis Es gibt durchaus triftige Gründe, einige Hosts für die Verwendung von getaggten Frames zu konfigurieren. Sie sollten jedoch sicherstellen, dass die VLAN-Kennzeichnung auf Ports deaktiviert ist, die Hosts zugewandt sind, für die Sie keine gekennzeichneten Frames verwenden möchten. Zu den Gründen für die Verwendung von getaggten Frames auf einem Linux-Host gehört einer, der als Router zwischen VLANs oder einem Server fungiert und von Clients in verschiedenen VLANs aus erreichbar sein muss.

— Kasperd