Cuando una conexión Ethernet lleva más de una VLAN, todas menos una de esas VLAN deben etiquetarse . La etiqueta VLAN conforme a IEEE 802.1Q se coloca en la trama de Ethernet en la ubicación donde normalmente estaría el EtherType de la trama. La primera parte de la etiqueta VLAN es un identificador de protocolo de etiqueta , que es un valor constante de 0x8100. Como resultado, un dispositivo que desconoce las etiquetas IEEE 802.1Q o configurado para no esperarlas verá las tramas etiquetadas y pensará "esto no es ni IPv4, ARP ni IPv6; este Ethertype 0x8100, que es algo completamente diferente y yo no" Creo que no lo entiendo en absoluto. Lo mejor es ignorarlo ".
Un conmutador compatible con VLAN puede filtrar los paquetes que salen a cada puerto por sus etiquetas de VLAN, y opcionalmente puede quitar la etiqueta de VLAN de una VLAN seleccionada en el tráfico saliente desde ese puerto (y agregar recíprocamente la etiqueta de VLAN al tráfico entrante en ese puerto), para que cualquier tráfico de la VLAN seleccionada aparezca como tráfico Ethernet anterior a 802.1Q para el dispositivo conectado a ese puerto en particular. Dicha VLAN seleccionada se conoce como la VLAN nativa para ese puerto.
El estándar 802.1Q permite que un puerto Ethernet admita una única VLAN nativa y cualquier cantidad de VLAN etiquetadas al mismo tiempo, pero entiendo que un puerto pase las tramas Ethernet etiquetadas y sin etiquetar al mismo tiempo es una configuración algo desfavorable: usted ' Deberá recordar que una de las VLAN en un puerto / NIC es diferente de todas las demás y debe configurarse de manera diferente. Propenso a errores.
En la terminología de Cisco, un puerto de conmutador se puede configurar como puerto de acceso o como puerto troncal . Un puerto de acceso solo proporcionará acceso a una única VLAN y las etiquetas de VLAN se quitarán automáticamente del tráfico saliente y se agregarán al tráfico entrante para ese puerto. Un puerto troncal, por otro lado, pasará el tráfico en un conjunto configurable de VLAN, pero todo el tráfico estará etiquetado con VLAN.
Entonces, para su caso de dos dispositivos en dos VLAN diferentes en el mismo conmutador, ambos utilizando direcciones en la misma subred IP. Lo que ocurra dependerá de cómo estén configurados los puertos del conmutador (y las interfaces de red en los dispositivos) con respecto a las VLAN.
1.) Cambie los puertos como puertos de acceso, los dispositivos no son compatibles con VLAN: el puerto del conmutador filtrará el tráfico de la VLAN "opuesta", por lo que los dispositivos nunca verán el tráfico de los demás. Esto plantea la pregunta de si tiene sentido o no pensar en ellos como "estar en el mismo segmento de red".
2.) Cambie los puertos como puertos troncales configurados para pasar ambas VLAN, los dispositivos no son compatibles con VLAN: cada dispositivo pensará "¿Por qué ese otro dispositivo sigue enviándome esas cosas extrañas de Ethertype 0x8100? No hablo eso".
3.) Cambie los puertos como puertos troncales configurados para pasar solo una VLAN cada uno, los dispositivos son conscientes de VLAN: también deberá especificar los números de VLAN en la configuración de red de los dispositivos, pero el resultado final es esencialmente el mismo que en el caso # 1: los dispositivos no verán el tráfico del otro.
4.) Cambie los puertos como puertos troncales configurados para pasar ambas VLAN, dispositivos con reconocimiento de VLAN pero configurados para diferentes VLAN: ahora es la capa de soporte de VLAN en los dispositivos que realizan el filtrado, pero el resultado práctico es el mismo que en los casos # 1 y # 3: el tráfico del dispositivo "opuesto" nunca alcanzará la capa de protocolo IP en la pila de protocolos de red del dispositivo.
5.) Cambie los puertos como puertos troncales configurados para pasar ambas VLAN, dispositivo configurado con reconocimiento de VLAN, ambas VLAN configuradas en el dispositivo. Esto está más allá de lo que pediste. Ahora el dispositivo estará efectivamente presente en ambas VLAN.
Dado que ambas VLAN fingen ser distintas en el nivel de Ethernet, pero utilizan la misma subred IP, lo que suceda dependerá de cómo se haya implementado el enrutamiento IP de los dispositivos. El principal detalle importante será si la pila de IP está diseñada para usar un modelo de host fuerte o un modelo de host débil , y exactamente cómo se ha integrado el concepto de VLAN en el sistema.
Por ejemplo, Linux presentará cualquier VLAN etiquetada configurada como NIC virtuales adicionales, que reflejen el estado del enlace de la NIC física subyacente pero que, de lo contrario, actúen de la forma más independiente posible técnicamente. Por lo tanto, será como si tuviera dos NIC conectadas en dos segmentos de red física separados con subredes IP 100% superpuestas: el sistema podría recibir tráfico entrante perfectamente, pero supondrá que cualquier NIC conectada a la subred IP de destino es buena para hablar cualquier otro host en esa subred IP, y usará cualquier NIC (virtual, específica de VLAN) que ocurra primero en la tabla de enrutamiento ... y, por lo tanto, la configuración podría o no funcionar dependiendo del orden en que las diferentes partes del La configuración de NIC y VLAN se ha inicializado. Necesitarías usar Linux '
El uso de la misma subred IP en dos segmentos distintos es un problema de capa 3, sin importar si la separación de segmentos en la capa 2 es física (= NIC separadas reales) o lógica (= creada con VLAN). Un problema de capa 3 necesitará una solución de capa 3: usar un enrutador o alguna otra caja para simular la NAT de una de las subredes para eliminar la superposición de subred IP sería mucho más elegante que tratar de manejarlo en los dispositivos individuales.
