¿Qué sucede cuando un conmutador de consumidor recibe una trama Ethernet etiquetada con VLAN?

Suponga que conecta un puerto troncal desde un conmutador de red compatible con VLAN a un conmutador de red de grado de consumidor (incapaz de VLAN) a través de un cable directo. Ahora el conmutador anterior envía al conmutador posterior una trama Ethernet etiquetada 802.1Q. ¿Qué debe hacer el cambio posterior? Suelta el marco? ¿Reenviar el marco? Comportamiento indefinido?

Si el comportamiento no está definido, ¿qué es lo más probable?

Editar: gracias por sus respuestas. Para resumir, el comportamiento del cambio de consumidor depende de:

Cómo maneja los marcos 0x8100en el campo EtherType ¹
Cómo maneja tramas gigantes, o tramas con carga útil mayor a 1500 bytes

Wikipedia tiene un buen diagrama que compara una trama Ethernet sin etiquetar y etiquetada:

Hay informes de que algunos conmutadores de nivel de consumidor pasan marcos con etiquetas VLAN muy bien.

_{¹ o más precisamente, donde se espera un campo EtherType para tramas no etiquetadas}

— netvope
fuente

Espero que no preguntes con la esperanza de usar dicho interruptor de consumo en un estante de producción en algún lugar ...

— Mike Pennington

Respuestas:

De hecho, he visto esto en un interruptor barato. Alguien había conectado un interruptor entre un puerto troncal que tenía un par de vlans. Los marcos se enviaron con el etiquetado vlan intacto. Los otros puertos en ese conmutador pudieron usar el vlan sin etiquetar.

Un conmutador solo necesita el mac de origen / destino para decidir a qué puertos reenviar los marcos, por lo que esto no es demasiado sorprendente, un marco etiquetado todavía tiene los equipos de origen y destino, en la misma ubicación en el encabezado del marco.

Tenga en cuenta que Ethernet en realidad admite muchos tipos de trama diferentes en el mismo cable. Fue diseñado para ser bastante flexible sobre lo que puede hacer.

— Zoredache
fuente

Si el conmutador no conoce el tipo de éter utilizado para las tramas etiquetadas, lo procesará como si fuera un tipo de éter normal. Eso funcionará principalmente, pero puede fallar en configuraciones complicadas donde el puerto de destino depende tanto de MAC como de etiqueta. Por ejemplo, si instala un firewall puente entre dos VLAN etiquetadas, el conmutador sin soporte de VLAN podría enviar algunos paquetes en la dirección incorrecta. Aparte de eso, un problema obvio que puede suceder es que los paquetes se descarten porque exceden el tamaño máximo de tramas sin etiquetar.

— kasperd

Por lo general, los marcos de Ethernet demasiado grandes se pueden descartar. En presencia de elementos como los marcos de tamaño jumbo, los marcos de ethernet grandes son difíciles de definir, por lo que realmente depende, pero el descarte será probablemente el comportamiento más frecuente.

editar: Para elaborar: el tamaño de trama Ethernet estándar IEEE 802.3 es de 1518 bytes, 802.3Q agrega 4 bytes a la trama, por lo que tiene una MTU total de 1522 bytes que podría ser demasiado grande para algunos conmutadores.

— pfo
fuente

¿Podría explicar qué tienen que ver los grandes marcos de Ethernet con el etiquetado VLAN 802.1Q?

— Martijn Heemels

¿Estás diciendo que la etiqueta haría que el marco fuera demasiado grande?

— Shane Madden

@ShaneMadden Algunas implementaciones 802.1q aumentan la MTU efectiva hasta 1522b para las tramas etiquetadas, que serán eliminadas por conmutadores con solo una MTU de 1500b.

— sysadmin1138

+1 para sysadmin1138 y +1 para pfo: algunos conmutadores antiguos descartarán las tramas etiquetadas porque 802.1q aumentó la MTU de Ethernet.

— Evan Anderson el

El etiquetado de VLAN aumenta el tamaño máximo de trama en 4 bytes, por lo que es mayor que 1518 bytes y, por definición, es una trama "jumbo".

— pfo

El conmutador de clase de consumidor intentará reenviar la dirección MAC de destino de trama, es todo lo que le importa. Si la dirección MAC de destino no está en su tabla CAM, inundará la trama de todos sus puertos, excepto del que se recibió el paquete.

Un conmutador que utiliza el método de reenvío Cut Through definitivamente reenviará la trama, ya que comienza a reenviarse tan pronto como se lea la dirección MAC de destino, incluso si el tamaño total de la trama es mayor que la MTU, ya que no puede calcular el tamaño del marco con este método de reenvío.

Probablemente, un interruptor basado en la técnica Store And Forward (siempre que el tamaño del cuadro sea <= MTU) hará lo mismo, siempre que el FCS esté BIEN.

Si el conmutador incapaz de 802.1Q interconecta dispositivos finales, los dispositivos recibirán la trama y la descartarán, ya que no "saben" cómo procesar tramas 802.1Q (tipo 0x8100).

Especulo que si el conmutador de clase de consumidor interconecta conmutadores con capacidad 802.1Q (¡ el horror! ), Los marcos serán reenviados y procesados por el 802.1Q, por supuesto, siempre que se reciban en los puertos troncales.

— dkaragasidis
fuente

Eh Los dispositivos de punto final de Linux manejan marcos etiquetados muy bien. Los he visto hacerlo.

— Zan Lynx

@ZanLynx True. Aunque no se supone que los dispositivos de punto final manejen tramas etiquetadas, se pierde todo el punto de las VLAN configurando dispositivos de punto final para recibir y manejar tramas 802.1q.

— dkaragasidis

FCS = cambio rápido de circuito? ¿Qué determina si "el FCS está bien"?

— netvope

@netvope: FCS - Secuencia de verificación de cuadros: en.wikipedia.org/wiki/Frame_check_sequence

— Evan Anderson el

@dkaragasidis Hay razones perfectamente válidas para configurar algunos hosts para usar marcos etiquetados. Pero es mejor asegurarse de que el etiquetado de VLAN esté deshabilitado en los puertos que están frente a hosts en los que no desea usar marcos etiquetados. Las razones para usar marcos etiquetados en un host Linux incluyen uno que actúa como enrutador entre VLAN o un servidor al que se debe poder acceder desde clientes en diferentes VLAN.

— Kasperd