Entrega de L3VPN: ¿rutas privadas, una ruta por defecto o una tabla completa?

Su circuito está activo, el VRF está configurado y el proveedor hace una pregunta corta que decide el resto del diseño: qué debe recibir el borde del cliente? Tres respuestas son habituales y ninguna se deriva de que exista una pila de etiquetas. Son decisiones de servicio sobre dónde sale el tráfico de la sucursal.

Recorrer la entrega en orden es la forma más barata de acertar. Empieza por lo que ocurre con el tráfico que no coincide con nada, luego anota los prefijos privados y su comportamiento ante fallo, y solo entonces habla de qué tamaño de feed estás dispuesto a transportar.

Empiece por el tráfico que nadie había planificado

Haga una pregunta antes de que aparezca cualquier lista de prefijos: cuando un paquete no coincide con ninguna ruta privada, ¿adónde debe ir? Una sucursal con circuito de internet propio suele mantener una ruta por defecto local, así que el tráfico web ordinario sale por el cortafuegos local y nunca toca al proveedor. En ese diseño la VPN solo transporta los sitios privados remotos, y los prefijos más específicos hacen la selección.

Una sucursal pensada para usar una salida central es el caso opuesto. Allí la ruta por defecto apunta al servicio, y el proveedor o el sitio central posee el reenvío, el retorno y cualquier traducción. Decir "por defecto a la VPN" sin ese propietario produce una sucursal que resuelve nombres y no llega a nada.

Los dos diseños difieren en cómo se ve un fallo de enrutamiento, y por eso adivinar sale caro. Con una ruta por defecto local, una ruta privada perdida envía ese tráfico a internet, donde el cortafuegos lo descarta o, peor, responde algo que usted no pretendía. Con una ruta por defecto central, la misma pérdida elimina por completo el acceso a internet y el ticket llega como "toda la sucursal está caída". Ninguno de los dos fallos es incorrecto por sí mismo, pero solo uno encaja con el servicio que vendió, y una configuración BGP por sí sola no le dirá cuál construyó.

Anote los prefijos privados con su caso de fallo

Enumere los prefijos que la sucursal debe alcanzar e indique cuáles están resumidos. Un agregado un bit demasiado amplio arrastra destinos desconocidos hacia la VPN, lo que solo es correcto si el lado remoto realmente los posee y los reenvía.

Después describa el comportamiento previsto cuando el servicio privado falla. Una ruta de descarte retenida mantiene el tráfico fuera de un camino no autorizado y produce una interrupción limpia y esperada. Una ruta por defecto flotante puede preservar la disponibilidad pasando a un camino de respaldo, pero solo si el camino de respaldo está autorizado a transportar ese tráfico.

Mantenga la disponibilidad y el repliegue permitido como dos requisitos separados en el documento de entrega. Los equipos que los fusionan acaban discutiendo si la sucursal debería haber fallado, en lugar de comprobar si se implementó la política acordada.

Compruebe qué instaló realmente el CE

La intención de la configuración y el estado de reenvío divergen con suficiente frecuencia como para que la verificación pertenezca a la entrega y no a la revisión del incidente. En un borde de cliente IOS-XE los tres comandos de abajo responden tres preguntas distintas: qué se ofreció, qué se aceptó y qué se está usando realmente.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Ejecute los tres el día de la entrega y no un mes después, mientras alguien recuerda todavía lo acordado. La primera salida depende de soft-reconfiguration inbound o de una actualización de rutas almacenada; sin ninguna de las dos, el CE no puede mostrarle qué rechazó. La segunda muestra las rutas aceptadas y las mejores tras la política. La tercera le dice adónde va realmente la ruta por defecto, y es la línea más útil de toda la entrega.

Ejecute las mismas comprobaciones en un segundo CE si el sitio tiene doble conexión. La aceptación asimétrica entre dos bordes es una causa habitual de "funciona desde un servidor y desde el otro no", y es invisible en una diferencia de configuración que parece simétrica.

Qualifique un feed mayor en lugar de darlo por supuesto

A veces el cliente realmente necesita información de rutas de internet dentro del VRF, para enrutamiento por políticas o para una salida central que dirija por prefijo. Eso es un requisito que hay que declarar, acotar y presupuestar, no una ruta por defecto oculta. Viene con memoria para la RIB y la FIB, CPU para las actualizaciones, mantenimiento de filtros y un propietario de la tabla resultante.

Los argumentos de capacidad fallan en ambas direcciones. Una tabla completa no está prohibida dentro de un VRF, y tampoco es gratuita. Igualmente, no puede inferir el coste actual de un recuento antiguo de rutas, y una asignación de etiquetas menor no elimina el coste de almacenar rutas.

La especificación BGP/MPLS IP VPN analiza varias disposiciones de acceso a internet junto al servicio VPN, y no declara obligatoria una tabla completa ni una ruta por defecto para cada cliente, y esa es la sección que merece señalarse cuando aparece una afirmación sobre la "práctica estándar": RFC 4364.

Cierre la entrega registrando el conjunto anunciado, el conjunto recibido y el conjunto seleccionado junto a la política de salida acordada, y probando un destino privado, un destino público previsto y un caso de pérdida de ruta. Un registro firmado de esas tres pruebas resuelve más discusiones que cualquier afirmación sobre lo que hacen la mayoría de las redes.