Qué es una VRF
Una VRF (Virtual Routing and Forwarding) permite mantener varias tablas de routing lógicamente separadas dentro de un mismo equipo. Dos interfaces pueden pertenecer a VRF diferentes y, aunque utilicen el mismo router físico, sus rutas no se mezclan por defecto. Es una forma de virtualizar el plano de Capa 3.
Esto resulta útil para multi-tenancy, separar redes de gestión, aislar entornos o reutilizar espacios de direcciones que se solapan. La VRF no “crea una VLAN”: VLAN segmenta Capa 2, mientras VRF separa contextos de routing. Ambos mecanismos pueden combinarse.
VRF-lite y VRF sin MPLS
Se suele llamar VRF-lite al uso de VRF localmente, sin construir un servicio MPLS L3VPN. El router mantiene tablas independientes y las interfaces se asignan al contexto correspondiente. Las rutas estáticas o protocolos dinámicos pueden ejecutarse dentro de cada VRF según las capacidades del sistema.
Para una empresa que sólo necesita separar administración, producción y laboratorio en un campus, VRF-lite puede aportar aislamiento lógico sin introducir MPLS. La complejidad aparece al necesitar comunicación controlada entre VRF o transportar esos contextos a través de una infraestructura mayor.
Interfaces y rutas pertenecen a un contexto
Una interfaz L3 se asocia a una VRF y sus redes conectadas aparecen en la tabla de esa VRF. Un comando de ping o traceroute puede necesitar especificar el contexto correcto; consultar únicamente la tabla global puede llevar a concluir erróneamente que “no existe ruta”.
El troubleshooting debe preguntar siempre: ¿en qué VRF se originó el paquete? La misma dirección puede tener significados distintos en contextos diferentes. Esta lógica extiende lo aprendido en tablas de enrutamiento.
Direcciones solapadas entre VRF
Como las tablas están separadas, dos VRF pueden utilizar prefijos IPv4 iguales sin colisionar dentro del router. Esto es útil en proveedores, laboratorios o adquisiciones donde no es viable renumerar de inmediato. Sin embargo, comunicar dos espacios solapados requiere un diseño especial porque una dirección ya no identifica de forma única un destino fuera de su contexto.
El solapamiento tampoco elimina problemas en servicios compartidos, logs o sistemas que no conocen la VRF. Documenta contexto además de dirección IP para evitar ambigüedad operacional.
Route leaking: comunicación controlada entre VRF
Si dos VRF deben intercambiar tráfico, puede configurarse route leaking: importar de forma selectiva rutas de un contexto a otro o utilizar un firewall/router intermedio. La técnica exacta depende de la plataforma. El objetivo debe ser publicar sólo la reachability necesaria, no fusionar accidentalmente las tablas.
Route leaking resuelve reachability, no política de seguridad por sí sola. Si la comunicación debe estar restringida por aplicación o usuario, añade ACL o firewall. La guía de firewalls explica por qué separación de routing y control de acceso son capas distintas.
VRF en MPLS L3VPN: contexto más amplio
RFC 4364 describe BGP/MPLS IP VPN, donde routers PE mantienen VRF por cliente y usan mecanismos adicionales para distinguir rutas y transportarlas por el backbone del proveedor. En ese modelo aparecen conceptos como Route Distinguisher y Route Target. No son requisitos para toda VRF local.
Conviene no equiparar “VRF” con “MPLS”. VRF es el concepto de tablas separadas; MPLS L3VPN es una arquitectura de proveedor que utiliza VRF junto con BGP y MPLS para ofrecer VPN de Capa 3 a escala.
Servicios compartidos, gestión y DNS
Una red puede querer que varias VRF consuman servicios comunes como DNS, NTP, autenticación o monitorización. Hay que diseñar cómo alcanzan esos servicios: route leaking selectivo, interfaces dedicadas, firewall o proxies. También debe decidirse desde qué contexto se originan SNMP, syslog y conexiones de administración.
Los servicios están desarrollados en servicios de red. Al introducir VRF, comprueba que cada daemon o dispositivo soporte seleccionar la tabla/interfaz de origen esperada.
Una VRF no es un firewall
La separación de tablas impide routing directo entre contextos si no se configura un mecanismo de intercambio, pero no aporta inspección stateful, protección de aplicaciones ni una política de identidad. Además, una mala configuración de leaking puede abrir caminos que el diseñador no pretendía.
Trata VRF como una primitive de segmentación de Capa 3. Después aplica controles de seguridad acordes al riesgo. En muchos diseños, el tráfico entre VRF pasa por un firewall precisamente para centralizar política y logging.
Troubleshooting de VRF
Los fallos más confusos aparecen cuando se consulta el contexto equivocado. Verifica asignación de interfaz, dirección, tabla de routing de la VRF, next hop y servicio de origen. Después comprueba si existe leaking intencionado y si las políticas permiten el flujo. Una captura debe hacerse en el punto y contexto adecuados.
- Confirma VRF de interfaz de entrada y salida.
- Consulta rutas dentro de esa VRF, no sólo la tabla global.
- Comprueba reachability del next hop en el mismo contexto.
- Revisa import/export o leaking.
- Valida firewall/ACL en el punto donde se unen contextos.
Ejemplo: usuarios, gestión y laboratorio en VRF separadas
Un campus puede mantener la red de usuarios en la tabla global, una VRF de gestión para interfaces administrativas y una VRF de laboratorio que reutiliza direcciones privadas presentes en otro entorno. El firewall recibe una interfaz de cada contexto y publica únicamente servicios de gestión autorizados. Así, una ruta aprendida en laboratorio no aparece de forma automática en gestión y un solapamiento de direcciones no contamina la tabla global.
Si el equipo de monitorización necesita alcanzar dispositivos de gestión, se diseña un camino concreto en lugar de abrir route leaking general. El ejemplo ilustra la principal ventaja de VRF: el aislamiento de reachability se vuelve explícito y auditable.