Enrutamiento de sucursales MPLS: qué aprende la CE y de quién

Un host de una sucursal abre una conexión con un servidor de otra, y ambas sedes están detrás de la misma VPN MPLS de nivel 3 gestionada. El host solo conoce su propia puerta de enlace predeterminada y nada más, lo cual es correcto. Lo importante es que el borde de cliente local entregue el paquete hacia su borde de proveedor, y que el estado de enrutamiento VPN del proveedor lo lleve a la sucursal que posee el prefijo de destino.

Recorrer un paquete por el camino es la forma más rápida de ver qué parte corresponde al cliente y qué parte pertenece al servicio.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Dónde termina el trabajo de cada salto

La CE-A necesita una ruta para la LAN remota que apunte a su conexión local con el proveedor, no a la dirección WAN de la sucursal remota. Después el proveedor transporta el paquete por su propio núcleo usando el estado de enrutamiento VPN, y la CE-B lo entrega en la LAN de destino. En ningún momento un host necesita entender etiquetas, VRF ni el circuito de internet del otro extremo.

El error que aparece una y otra vez en los tickets es configurar la dirección WAN de la sucursal B como siguiente salto en la sucursal A. Ambas sucursales compraron el mismo servicio, así que parece que deberían ser vecinas. No lo son: un siguiente salto debe ser alcanzable a través del diseño de enrutamiento que realmente tiene, y la CE remota suele estar a muchos saltos de distancia, detrás de equipos que usted no administra. Una ruta estática construida sobre esa suposición aparece como activa y no resuelve a nada, lo que es peor que una ruta ausente porque en la tabla parece correcta.

La RFC 4364 separa el intercambio entre el borde de cliente y el de proveedor de la distribución de rutas VPN que hace el proveedor, y esa es exactamente la frontera de la que trata este manual. El trabajo del cliente es decir a su borde qué puede entregar y aceptar la alcanzabilidad que el servicio ofrece de vuelta.

En qué debe ponerse de acuerdo la entrega

Elija el mecanismo con el proveedor, no a sus espaldas. Las rutas estáticas, BGP o un acuerdo de protocolo de enrutamiento entre la CE y la PE son todos legítimos, y OSPF tiene un modelo MPLS VPN definido para esa entrega. Nada de eso es motivo para construir una adyacencia OSPF entre dos bordes de cliente remotos a través de un núcleo de proveedor no especificado, que es un diseño que el proveedor no ha aceptado y no puede soportar.

Antes de poner en servicio una LAN nueva, anote cuatro cosas: el prefijo, la ruta local siguiente en la CE, el anuncio que el proveedor aceptará y las rutas que el proveedor devolverá. Añada cualquier filtrado, límite de prefijos o restricción entre sedes que imponga el contrato. Una adyacencia sana es un canal para intercambiar información, y no es prueba de que se haya aceptado un prefijo concreto; la sesión puede estar activa mientras su nueva subred está dentro de un filtro.

Después siga la respuesta. La sucursal B necesita una ruta de vuelta a la LAN de origen, y el host del lado receptor necesita su propia puerta de enlace y sus propios permisos de servicio. Una ruta que aparece en la CE-A establece medio viaje de ida y vuelta, y medio viaje es la razón por la que una dirección de una prueba de ping parece sana mientras la aplicación sigue fallando.

Verifique las dos entregas antes de firmar

Reúna el estado de enrutamiento en ambos bordes de cliente, confirme con el proveedor que los prefijos de LAN previstos se aceptaron en la VPN y luego pruebe una aplicación permitida en cada dirección. Las tablas de rutas por sí solas no demuestran que la aplicación funcione, y una prueba de aplicación por sí sola no le dice qué plano de control falló cuando no funciona.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Lea las tres salidas en conjunto. La primera dice qué cree el borde, la segunda dice qué aprendió y de qué vecino, y la tercera dice qué reenviará realmente. La discrepancia entre ellas suele ser un problema de política o de recursión más que un anuncio ausente, y merece resolverse antes de pedir al proveedor que investigue. Lleve esas tres salidas a la llamada con el operador, porque responden a la mayoría de las preguntas que un ingeniero de soporte le haría de otro modo.

Sepa qué no ofrece el servicio

Esto es acceso enrutado de nivel 3. No es un circuito de nivel 2 que extienda difusiones entre oficinas, así que los protocolos de descubrimiento, las aplicaciones dependientes de difusión y las suposiciones de segmento compartido no viajan con él. La impresión, el examen de nombres y cualquier cosa que dependa de un segmento local necesitan su propio diseño.

La separación de VPN tampoco es cifrado. La conmutación de etiquetas mantiene a los clientes separados dentro de la red del proveedor, y no hace confidencial la carga útil si el contrato exige confidencialidad. Donde eso importa, la aplicación o una capa superpuesta debe aportarla.

Por último, mantenga el modelo de servicio escrito junto a la configuración de enrutamiento de la sede. El siguiente ingeniero que añada una subred debería poder leer qué prefijos se anuncian, quién los acepta y cuál es el camino de vuelta esperado: la especificación BGP/MPLS IP VPN es la referencia del modelo que hay detrás de todo esto.