Por qué dos VLAN necesitan routing para comunicarse
Una VLAN crea un dominio lógico de Capa 2 independiente. Dos hosts en VLAN distintas no comparten el mismo dominio de broadcast aunque estén conectados al mismo switch físico. Para pasar tráfico de una VLAN a otra hace falta una función de Capa 3 que tenga presencia IP en ambas redes y pueda reenviar paquetes entre sus prefijos.
Ese proceso se denomina inter-VLAN routing. No elimina la segmentación: la VLAN sigue separando Capa 2 y el router se convierte en el punto controlado donde pueden aplicarse ACL, políticas y observabilidad. Antes de continuar conviene dominar VLAN y routing IP.
El gateway de cada VLAN
Cada subred asociada a una VLAN necesita normalmente una dirección de gateway. Los hosts comparan el destino con su propio prefijo; si está fuera de la red local, envían el paquete al gateway. Ese gateway puede ser una subinterfaz de router, una SVI de un switch de Capa 3 o una dirección virtual gestionada por un protocolo de redundancia.
La dirección del gateway debe pertenecer al prefijo correcto y estar alcanzable desde la VLAN. Un error típico es crear la VLAN y el trunk pero olvidar que los hosts tienen un gateway incorrecto, o asignar la misma subred a varias interfaces de routing sin un diseño coherente.
Router-on-a-stick y subinterfaces 802.1Q
En un diseño router-on-a-stick un enlace físico entre switch y router transporta varias VLAN mediante 802.1Q. El router crea subinterfaces lógicas, cada una asociada a un VLAN ID y una dirección IP. El switch configura el enlace como trunk y permite las VLAN necesarias. Cisco documenta este patrón como una forma clásica de routing entre VLAN con un router externo.
Es simple y didáctico, pero concentra tráfico de varias VLAN en un único enlace físico y en un único equipo. El trunk debe tener la VLAN nativa y la lista de VLAN permitidas correctamente alineadas. Repasa trunks 802.1Q si hay discrepancias de etiquetado.
SVI en un switch de Capa 3
Un switch multilayer puede crear una Switch Virtual Interface (SVI) por VLAN y realizar el routing internamente. La SVI actúa como interfaz de Capa 3 asociada a esa VLAN y suele ser el gateway de los hosts. Para que funcione, la VLAN debe existir y el equipo debe tener habilitado el forwarding de Capa 3 según su plataforma.
Este modelo evita enviar todo el tráfico inter-VLAN a un router externo y es habitual en distribución o core de campus. No obstante, el diseño sigue necesitando rutas hacia redes remotas, un camino de retorno y políticas de seguridad donde corresponda.
Puertos enrutados y enlaces hacia otros routers
En equipos de Capa 3 también pueden utilizarse puertos físicos en modo routed, sin pertenecer a una VLAN de acceso. Son útiles para enlaces punto a punto hacia routers, firewalls u otros switches L3. No sustituyen las SVI para dar gateway a una VLAN, pero permiten separar claramente enlaces de tránsito de segmentos de usuario.
El diseño puede combinar SVI para VLAN internas y puertos enrutados hacia el upstream. La guía de rutas estáticas y OSPF explican cómo anunciar o alcanzar esos prefijos más allá del switch.
DHCP relay entre VLAN
Los mensajes DHCP iniciales de un cliente se originan sin una configuración IP completa y utilizan broadcast en la red local. Un servidor DHCP situado en otra VLAN no recibe ese broadcast directamente. Por eso el gateway puede actuar como relay, reenviando la solicitud al servidor e indicando de qué red procede para seleccionar el scope correcto.
Si una VLAN obtiene conectividad estática pero los clientes no reciben dirección, revisa relay, reachability al servidor, scope y políticas. La guía de DHCP desarrolla DORA, leases y relay.
ACL y políticas entre VLAN
Que el router conozca dos redes no significa que deba permitir cualquier comunicación entre ellas. El punto de routing es precisamente un lugar apropiado para aplicar políticas: usuarios hacia servidores sólo en puertos necesarios, IoT aislado de administración, invitados únicamente hacia Internet, etc.
Una ACL puede filtrar tráfico básico y un firewall puede añadir estado e inspección más profunda. Diseña primero quién necesita hablar con quién y después traduce esa matriz a reglas. Evita depender únicamente de “estar en otra VLAN” como control de seguridad.
Redundancia del gateway y FHRP
Si una única SVI o router es el gateway de cientos de hosts, su fallo puede aislar la VLAN aunque el resto de la red siga operativo. Protocolos First Hop Redundancy permiten presentar una dirección virtual compartida entre varios equipos y mover la responsabilidad cuando falla el activo.
VRRP y HSRP se estudian en FHRP. Su convergencia también depende de Capa 2, ARP/Neighbor Discovery, tracking de interfaces y de que el camino upstream del nuevo activo sea válido.
Troubleshooting de inter-VLAN routing
Empieza en el host: IP, máscara/prefijo y gateway. Comprueba que puede alcanzar al gateway de su VLAN. Después verifica que la VLAN existe, que el puerto de acceso pertenece a la VLAN correcta y que los trunks transportan esa VLAN. En una SVI, confirma que la interfaz está realmente operativa; en router-on-a-stick, revisa encapsulación y VLAN ID.
Si el gateway responde pero el destino remoto no, inspecciona tabla de routing, ACL, firewall y ruta de retorno. Una captura en ambos lados del punto L3 permite distinguir si el paquete nunca llega, se filtra o sale sin respuesta. La metodología general está en troubleshooting de redes.
Ejemplo de diseño con usuarios, servidores e invitados
Imagina tres VLAN: usuarios 10.10.10.0/24, servidores 10.10.20.0/24 e invitados 10.10.30.0/24. Un switch L3 puede crear una SVI en cada prefijo y actuar como gateway. Después una ACL permite a usuarios acceder a servicios concretos, bloquea invitados hacia redes internas y mantiene gestión separada. Este ejemplo muestra que el objetivo no es “hacer ping entre VLAN”, sino construir un punto L3 donde el tráfico puede controlarse de forma explícita.