¿Por qué no pueden comunicarse los dispositivos en diferentes VLAN, pero en la misma subred?


22

Tengo una pregunta sobre el cambio. Tengo dos dispositivos conectados a un conmutador con las direcciones IP 192.168.5.20 y 192.168.5.10. Ambos dispositivos tienen el mismo prefijo, / 24. Eso significa que están en la misma subred.

Si divido estos dispositivos en diferentes VLAN (10 y 20) en el conmutador, no se comunicará aunque estén en la misma subred. ¿Por qué pasa eso?


3
Necesita un enrutador para enrutar entre diferentes Vlans. Además, al hacer eso, no puede tener la misma subred IP en esos dos Vlans.

55
Hola Jim Pap y bienvenido ... Es como si conectaras tus dos hosts en dos conmutadores diferentes, uno con la etiqueta "LAN 10" y el otro con la etiqueta "LAN 20". La configuración de VLAN en su conmutador divide su conmutador en múltiples conmutadores virtuales.
jonathanjo

3
Esta pregunta es una especie de tautología. No pueden porque no pueden, por diseño. La creación de VLAN separadas segmenta lógicamente la interconexión de redes conmutada. Ahora necesita usar alguna forma de enrutamiento entre VLAN para que estos dispositivos se comuniquen.
WakeDemons3

1
@Cown no es posible en un enrutador Cisco tener direcciones de la misma subred en diferentes interfaces, pero esto tiene poco que ver con la VLAN en sí misma que no se preocupa por las direcciones IP (y podría usarse con, por ejemplo, IPX / SPX). Y ... Cisco sigue siendo un actor importante pero lejos de ser el único.
JFL

1
@Cown, ¿cómo ayudarían los diferentes VRF? Entonces no se comunicarían de todos modos, y para responder a su pregunta simplemente unir los vlans, tan simple como eso. Bridging ha estado disponible en los enrutadores Cisco desde mucho antes de que tomara mi CCIE y eso fue hace más de 20 años
Matt Douhan

Respuestas:


39

Una de las cosas que hacen las VLAN es tomar un conmutador físico y dividirlos en múltiples conmutadores "virtuales" más pequeños.

Es decir, esta representación física de un conmutador y dos VLAN:

ingrese la descripción de la imagen aquí

Es idéntico en funcionamiento a esta representación lógica de la misma topología:

ingrese la descripción de la imagen aquí

Incluso si las direcciones IP en la segunda imagen estuvieran en la misma subred, notará que no hay un "enlace" entre los dos conmutadores virtuales (es decir, VLAN) y, por lo tanto, no hay manera posible de que los hosts A / B puedan comunicarse con los hosts C /RE.

Para que los hosts en la segunda imagen se comuniquen entre sí, necesitaría algún tipo de dispositivo para facilitar la comunicación de un "interruptor" al otro. El dispositivo que existe para ese propósito es un enrutador ; por lo tanto, se requiere un enrutador para que el tráfico cruce un límite de VLAN:

ingrese la descripción de la imagen aquí

Y debido al funcionamiento del enrutador, cada interfaz de enrutador debe tener su propia subred IP única . Es por eso que cada VLAN requiere tradicionalmente su propia subred IP única, porque si se va a establecer una comunicación entre esas VLAN, se requerirán subredes únicas.


Las imágenes de arriba son de mi blog, puede leer más sobre VLAN como concepto aquí , y sobre Enrutamiento entre VLAN aquí .


2
Trampa para los incautos: no intente dividir un conmutador de esa manera, ENTONCES conecte las VLAN a través de puertos sin etiquetar, a menos que sepa exactamente cómo se configuran las implementaciones STP y CAM en ese conmutador.
rackandboneman

1
@rackandboneman Ese es un buen consejo. Pero, un punto de claridad, las imágenes en mi publicación representan solo un interruptor físico . La "imagen de dos conmutadores" es la representación lógica de un conmutador físico con dos VLAN.
Eddie

2
"cada interfaz de enrutador debe tener su propia subred IP única", que puede ser cierto para algunas implementaciones de enrutador, no es universalmente cierto. Al menos en Linux puede asignar la misma subred a múltiples interfaces, luego usar una combinación de arp proxy y / 32 rutas para hacer que el tráfico fluya entre ellas.
Peter Green

@PeterGreen Siempre existen excepciones. El hecho de que algo se pueda hacer no significa que deba hacerse, ni lo hace relevante para la pregunta en cuestión.
Eddie

29

El objetivo de LAN virtual es crear LAN de capa 2 separadas en un solo dispositivo físico.

Es como construir una pared blindada y a prueba de sonido en una habitación para crear 2 habitaciones. Las personas en cada mitad de la habitación ya no pueden comunicarse con las personas en la otra mitad de la habitación anterior.

Por lo tanto, tiene dos hosts en dos redes L2 distintas sin nada que les permita comunicarse.

Tenga en cuenta que en la mayoría de los casos no tiene sentido usar la misma subred en dos VLAN diferentes. El caso estándar es asociar una red IP con una VLAN.


Me cuesta pensar en cualquier caso en el que tenga sentido usar la misma subred en dos VLAN diferentes. Imagina que eres un enrutador y obtienes un paquete destinado a 192.168.5.15. ¿Qué VLAN es esa?
Monty Harder

@MontyHarder depende. ¿De qué red (virtual o no) proviene?
Deduplicador

1
@Dupuplicator No estoy seguro de por qué importa cuál es la IP de origen del paquete. ¿Cómo sabe qué VLAN es una IP si está usando el mismo rango de IP para dos o más VLAN? Simplemente no tiene sentido.
Monty Harder

@MontyHarder Tengo el caso: tengo interconexiones con proveedores que usan el mismo direccionamiento y se realizan en los mismos conmutadores. Como hablo con ambos (a través de diferentes enrutadores) y no se hablan entre sí, eso está bien.
JFL

@MontyHarder En realidad, es muy común tener la misma subred en muchas LAN diferentes (y, por lo tanto, VLAN). Las direcciones privadas RFC1918 se reutilizan en millones de LAN. Es muy posible que tenga varias redes NAT separadas en la misma VLAN. Esto probablemente ocurre hasta la saciedad en entornos de alojamiento. Pero esas redes se consideran de hecho completamente independientes.
jcaron

5

Subredes IP agrupan lógicamente hosts: los hosts dentro de la misma subred usan su conexión de capa 2 para comunicarse directamente entre sí. Hablar con hosts en otra subred requiere el uso de una puerta de enlace / enrutador.

VLAN físicamente agrupan hosts: los hosts dentro de la misma VLAN / dominio de difusión / segmento L2 pueden comunicarse entre sí directamente. Los hosts en diferentes VLAN no pueden. (No me golpees, físicamente el grupo no es realmente correcto, pero marca mi punto).

Entonces, cuando dos hosts están en la misma subred IP pero en diferentes VLAN / dominios de transmisión / redes L2 no pueden comunicarse: el host de origen asume el destino dentro de su red L2 local y, por lo tanto, intenta ARPAR la dirección de destino (o NDP resolver para IPv6).

ARP funciona enviando una solicitud como difusión a la red L2 local y el host con la dirección IP solicitada responde con su dirección MAC. Como el host de destino está afuera la red local, nunca escucha la solicitud ARP y ARP falla.

Incluso si la fuente de alguna manera conociera la dirección MAC del destino y construyera una trama dirigida a esa MAC, nunca llegaría al destino ya que aún está fuera de la red L2. Los MAC externos a la red local L2 no tienen sentido ni utilidad.


3

Complementario a las respuestas existentes, que cubren la pregunta desde un punto de vista de diseño y teoría ...

En lugar de preguntar " ¿por qué no se comunican? ", Preguntemos " qué sucede cuando intentan comunicarse?"

Primero, ¿qué significa configurar una VLAN en un conmutador? En nuestro ejemplo, hay algunos sockets configurados como VLAN 10 y algunos configurados como VLAN 20. La definición de VLAN es que solo se conectan sockets en la misma VLAN. Lo que eso significa es que una trama recibida en un puerto en una VLAN determinada solo se envía a los puertos de la misma VLAN.

  10  10  20  20  10  20       VLAN of port
   1   2   3   4   5   6       Port number
===+===+===+===+===+===+===
   |   |   |   |   |   |
   A   B   C   D   E   F       Hosts

En este diagrama tenemos seis hosts, los puertos 1, 2, 5 están en la VLAN 10, los puertos 3, 4, 6 están en la VLAN 20.

Suponga que el host A está configurado estáticamente como 192.168.5.10/24 y F está configurado estáticamente como 192.168.5.20/24, a partir de la pregunta. Suponga que B a E tienen otras direcciones de configuración estáticas (no importa cuáles sean).

Si A pings 192.168.5.20, determina que está en el mismo / 24, por lo que lo primero que sucede es una solicitud ARP: QUIÉN TIENE 192.168.5.20, enviado como una transmisión de Ethernet.

El conmutador recibe la transmisión en el puerto 1. Esta es la VLAN 10, por lo que envía la transmisión desde los puertos 2 y 5, los otros puertos en la VLAN 10. Los hosts B y E reciben la solicitud ARP y la ignoran, ya que no es su dirección.

Eso es.

No habrá respuesta ARP; Lo siguiente que sucederá será un tiempo de espera en A, seguido de las repetidas solicitudes ARP posteriores, hasta que la aplicación se dé por vencida.

Un host conectado a otra cosa que no sea un puerto VLAN 10 no verá nada, sea cual sea su dirección IP. Obviamente, esto incluye F, que es 192.168.5.20.


1

Espero que comprenda bien el enmascaramiento de subred. Cuando tiene VLAN separadas, debe tener un rango de direcciones IP único con subredes. No es esencial.

VLAN es una LAN separada, pero es una LAN virtual. Además, LAN virtual para separar redes en el mismo conmutador. Se creará un dominio de difusión separado en su conmutador. Pero cuando crea LAN virtuales con la misma ip, es inútil.

Además de eso, debe configurar el enrutamiento Intervlan en su conmutador.


2
No, no es imposible tener varias VLAN con la misma subred. Es inusual y algo desanimado, pero es totalmente posible.
JFL

@JFL Es cierto, es posible, ya sea usando VRF o alguna otra forma de separador, pero aún no he visto ningún caso de uso para esto. Por favor iluminame.

@JFL mismo problema para mí también. Acabo de intentarlo en el trazador de paquetes de Cisco, con enrutamiento intervlan. No sé si hay un problema con el rastreador de paquetes de Cisco. No es trabajo Estoy de acuerdo con cown. Es posible en VRF.
infra

1
@Cown No dije que era una buena idea ni que era posible hacer que se comunicaran entre sí (pero aún así es posible con NAT). Pero tengo algunos casos de uso. Por ejemplo, tengo interconexión con proveedores que pasan por algunas redes RFC1918 superpuestas. Esos están conectados a los mismos conmutadores en diferentes VLAN y no se comunican entre sí.
JFL

@JFL Lo siento, no veo cómo se compara con la pregunta inicial. Sí, es posible usar direcciones IP superpuestas para enlaces o usar NAT, pero simplemente no creo que refleje un escenario de la vida real.

1

Considere lo que sucede cuando tiene una LAN en casa y una computadora con IP 192.168.2.1. Su amigo en el camino también tiene una LAN en su casa y una computadora con IP 192.168.2.2. Están en la misma subred, entonces, ¿por qué no pueden hablar entre ellos?

En tal ejemplo, la causa es diferente de lo que está preguntando.

Pero una VLAN logra el mismo resultado: segmenta una red en la segunda capa.

Mi punto es que podemos ver fácilmente que el hecho de que "las direcciones IP están en la misma subred" no es suficiente para determinar si los paquetes pueden enrutarse entre ellos. La topología subyacente también tiene un papel que desempeñar.

Llevando esto a su extremo, en la capa más baja necesita algo de material físico (bueno, está bien, o aire: D) para transportar los datos. Sus computadoras pueden estar en la misma casa en la misma subred pero no estar físicamente conectadas (o tener un enlace inalámbrico) y entonces no esperaría que los paquetes se enruten.


0

El objetivo de las VLAN es tener una segmentación de red. También podría lograr lo mismo (dejando de lado algunas advertencias) utilizando subredes. Como su subred se divide en 2 VLAN diferentes, sus dispositivos no pueden comunicarse en la red L2. Puede configurar la interfaz IRB en el conmutador para permitir la comunicación entre las VLAN. Alternativamente, puede enrutar el tráfico a través de un firewall y permitir la comunicación selectiva entre las VLAN. Idealmente, debe diseñar su red para que tenga subredes diferentes para cada una de las VLAN y luego Firewall el tráfico entre las VLAN. Espero que esto ayude.


1
Nonononono no utiliza IRB en esta situación ... el problema es que el conmutador nunca debería haberse configurado con dos vlans en la misma subred. La mejor respuesta es poner todos los hosts en una subred en la misma vlan.
Mike Pennington

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.