Que se passe-t-il lorsqu'un commutateur grand public reçoit une trame Ethernet marquée VLAN?

Supposons que vous connectez un port de jonction d'un commutateur réseau compatible VLAN à un commutateur réseau de qualité grand public (incapable VLAN) via un câble direct. Maintenant, le premier commutateur envoie au commutateur suivant une trame Ethernet étiquetée 802.1Q. Que doit faire le dernier commutateur? Laisser tomber le cadre? Transférer le cadre? Comportement indéfini?

Si le comportement n'est pas défini, quel est le plus probable?

Edit: Merci pour vos réponses. Pour résumer, le comportement du commutateur consommateur dépend:

Comment il gère les trames avec 0x8100dans le champ EtherType ¹
Comment il gère les trames jumbo ou les trames avec une charge utile supérieure à 1 500 octets

Wikipedia a un joli diagramme comparant une trame Ethernet non balisée et balisée:

Il y a des rapports que certains commutateurs grand public passent très bien les trames marquées VLAN.

_{¹ ou plus précisément, où un champ EtherType est prévu pour les trames non marquées}

— netvope
source

J'espère que vous ne poserez pas la question dans l'espoir d'utiliser ledit commutateur de consommation dans un rack de production quelque part ...

— Mike Pennington

Réponses:

J'ai effectivement vu cela sur un commutateur bon marché. Quelqu'un avait connecté un commutateur entre un port de jonction qui avait quelques vlans. Les trames ont été transmises avec le marquage VLAN intact. Les autres ports de ce commutateur étaient capables d'utiliser le vlan non étiqueté.

Un commutateur n'a besoin que du mac source / destination pour décider vers quels ports transmettre les trames, donc ce n'est pas trop surprenant, une trame balisée a toujours les mac source et de destination, au même emplacement dans l'en-tête de la trame.

Gardez à l'esprit qu'Ethernet prend en charge de nombreux types de trames différents sur le même fil. Il a été conçu pour être assez flexible sur ce qu'il peut faire.

— Zoredache
source

Si le commutateur ne connaît pas le type d'éther utilisé pour les trames marquées, il va le traiter comme s'il s'agissait d'un type d'éther normal. Cela fonctionnera principalement, mais il peut échouer dans des configurations complexes où le port de destination dépend à la fois du MAC et de la balise. Par exemple, si vous installez un pare-feu de pontage entre deux VLAN balisés, le commutateur sans prise en charge de VLAN peut envoyer des paquets dans la mauvaise direction. En dehors de cela, un problème évident qui peut se produire est la perte de paquets car ils dépassent la taille maximale des trames non balisées.

— kasperd

Habituellement, des trames Ethernet trop grandes peuvent être et sont rejetées. En présence de choses comme des trames de taille jumbo, les grandes trames Ethernet sont difficiles à définir, donc cela dépend vraiment - mais la suppression sera probablement le comportement le plus fréquent rencontré.

modifier: Pour élaborer: la taille de trame Ethernet IEEE 802.3 standard est de 1518 octets, 802.3Q ajoute 4 octets à la trame, ce qui donne un MTU total de 1522 octets qui peut être trop grand pour certains commutateurs.

— pfo
source

Pourriez-vous expliquer ce que les grandes trames Ethernet ont à voir avec le balisage VLAN 802.1Q?

— Martijn Heemels

Voulez-vous dire que la balise rendrait le cadre trop grand?

— Shane Madden

@ShaneMadden Certaines implémentations 802.1q font grimper le MTU effectif jusqu'à 1522b pour les trames marquées, qui seront abandonnées par les commutateurs avec seulement un MTU de 1500b.

— sysadmin1138

+1 pour sysadmin1138 et +1 pour pfo: certains anciens commutateurs rejetteront les trames marquées car 802.1q a augmenté la MTU Ethernet.

— Evan Anderson

Le marquage VLAN augmente la taille de trame maximale de 4 octets, il est donc supérieur à 1518 octets et est par définition une trame "jumbo".

— pfo

Le commutateur de classe grand public tentera de transmettre l'adresse MAC de destination de trame, c'est tout ce qui lui importe. Si l'adresse MAC de destination n'est pas dans sa table CAM, elle inondera la trame de tous ses ports, à l'exception de celui à partir duquel le paquet a été reçu.

Un commutateur qui utilise la méthode de transfert Cut Through transmettra définitivement la trame, car il commence la transmission dès que l'adresse MAC de destination est lue - même si la taille totale de la trame est supérieure à la MTU - car il ne peut pas calculer la taille de la trame avec cette méthode de transfert.

Un commutateur basé sur la technique Store And Forward fera probablement (tant que la taille de trame est <= MTU) la même chose, tant que le FCS est OKAY.

Si le commutateur incapable 802.1Q interconnecte les périphériques finaux, les périphériques recevront la trame et la rejeteront, car ils ne "savent" pas comment traiter les trames 802.1Q (type 0x8100).

Je suppose que si le commutateur de classe grand public interconnecte les commutateurs compatibles 802.1Q ( l'horreur! ), Les trames seront transmises et traitées par le 802.1Q aussi longtemps, bien sûr, car elles sont reçues sur les ports de jonction.

— dkaragasidis
source

Eh. Les périphériques d'extrémité Linux gèrent très bien les trames marquées. Je les ai vus le faire.

— Zan Lynx

@ZanLynx True. Bien que les périphériques d'extrémité ne soient pas censés gérer les trames balisées, vous manquez tout le point des VLAN en configurant les périphériques d'extrémité pour recevoir et gérer les trames 802.1q.

— dkaragasidis

FCS = commutation de circuit rapide? Qu'est-ce qui détermine si "le FCS est OK"?

— netvope

@netvope: FCS - Séquence de vérification de trame: en.wikipedia.org/wiki/Frame_check_sequence

— Evan Anderson

@dkaragasidis Il existe des raisons parfaitement valables de configurer certains hôtes pour utiliser des cadres balisés. Mais il vaut mieux s'assurer que le balisage VLAN est désactivé sur les ports face aux hôtes que vous ne souhaitez pas utiliser de trames balisées. Les raisons d'utiliser des trames marquées sur un hôte Linux incluent celle qui agit comme un routeur entre les VLAN ou un serveur qui doivent être accessibles à partir des clients sur différents VLAN.

— kasperd