En este laboratorio, revisaremos el proceso de aprovisionamiento de un servicio VPN capa 3 basado en MPLS. Como se ha mencionado en algunos blogs anteriores, una infraestructura de red con MPLS abre un mundo de posibilidades para los proveedores de servicio al tener una infraestructura unificada capaz de entregar diversos tipos de servicio.
Ilustración 1 – Presentación de la Infraestructura de red con MPLS (LLD)
El servicio VPN capa tres (L3VPN) es uno de los servicios más solicitado por los clientes para interconectar diversas entidades remotas, desde oficinas, sucursales, cajeros automáticos, etc. Parte de las características de este servicio, es que el proveedor de servicio participa activamente en el dominio de ruteo del cliente, de hecho, es el principal responsable de compartir la información de ruteo o sea las rutas entre todas las entidades remotas del cliente.
Por cada entidad remota hay un punto de interconexión a nivel IP entre el cliente y el proveedor, "los famosos PE-CE" que generalmente se refieren al enlace entre el Router del Proveedor de servicio (PE o Provider Edge) y el del cliente (CE o Customer Edge) a nivel capa tres.
En cada PE el proveedor asegura la disponibilidad de la información de ruteo del cliente en una tabla de enrutamiento dedicada (VRF); misma información pueda ser enviada a la entidad directamente conectada a través de un protocolo de enrutamiento dinámico usado entre el PE y CE, o en otros casos el CE simplemente puede usar el PE como default gateway para alcanzar otros sitios o entidades de la red del cliente.
A continuación, veremos a detalle un caso muy práctico, donde revisaremos cada pieza que hace posible la interconexión de las oficinas remotas de un mismo cliente a través de la infraestructura de un proveedor de servicio.
Caso de uso
La empresa TEC Consulting Services S.A* contrató un servicio VPN capa tres (L3VPN) para interconectar sus tres oficinas remotas (1HQ y 2 sucursales), ubicadas en tres diferentes regiones del país.
REQUERIMIENTOS BÁSICOS
El proyecto se implementará de acuerdo con los siguientes requerimientos:
Comunicación tipo Full-mesh entre todos los sitios del cliente.
Protocolo de enrutamiento PE-CE: eBGP
ASN del cliente: 65300
PE-CE subred: 10.92.30.0/24
Sitio 1: 10.92.30.0/31
Sitio 2: 10.92.30.2/31
Sitio 3: 10.92.30.4/31
*Aviso legal: Datos ficticios, no representan escenarios reales de clientes con los que estoy trabajando actualmente. Cualquier parecido y/o similitudes con empresas reales son meramente coincidencias, y deben ser considerados como tal.
Diseño de alto nivel (HLD)
De acuerdo con los requerimientos especificados, y después de realizar algunos estudios estratégicos para determinar los PEs donde se configurarán los servicios, se genera un HLD del servicio completo que contrató el cliente.
HLD con mas detalles.
INFRASTRUCTURA
La interacción de diversas tecnologías importantes (MP-BGP, VRF, IGP, Redistribución de rutas, BGP Route-Reflector, etc.) con la infraestructura MPLS, hace posible la implementación y buen funcionamiento de un servicio VPN de capa tres.
Antes de pasar a la resolución del caso de uso presentado, revisamos algunos puntos esenciales.
1- Comunicación entre PEs (Provider Edge o Router de borde del Proveedor de servicio)
a) Arquitectura
En primer lugar, revisaremos el mecanismo de reenvío de información de ruteo del
cliente entre los PEs en distintos puntos de la red.
El único protocolo de enrutamiento capaz de realizar esa tarea es BGP, con su extensión MP-BGP, tiene la capacidad de enviar las rutas aprendidas del cliente de un punto a otro y de forma bidireccional, pero hay un tema, la regla del horizonte divido (Split horizon) de iBGP para evitar bucle de enrutamiento, estipula que una ruta aprendida en una sesión iBGP no podrá ser reenviado a otro vecino del mismo sistema autónomo.
Para lograr que todos los PEs reciben las rutas, se requiere una conexión tipo full-mesh entre todos los PEs donde este configurado el servicio del cliente, así se asegura que la información aprendida en un punto esté disponible en todos los demás sitios del cliente.
Si analizamos la arquitectura full-mesh un poco más a fundo seguramente veremos que al tener una sesión BGP entre todos los PEs eso no ofrece mucha escalabilidad ya que cada vez que se requiera habilitar un sitio nuevo para el mismo cliente a través de un PE nuevo (o simplemente agregar un PE nuevo en la red) se aumentara drásticamente la cantidad de sesiones BGPs entre los PEs, pues así sería muy difícil mantener el full-mesh, por eso nadie lo utiliza realmente, todos optan por utilizar una arquitectura centralizada usando un Route reflector (RR), que básicamente sirve como un tipo de servidor o controlador centralizado donde todos los PEs enviaran sus Updates y el RR a su vez enviara una copia idéntica a todos los demás PEs (configurados como Route Reflector client).
b) Address-family VPNv4
Gracias a su extensión MP-BGP se puede implementar una sesión iBGP totalmente dedicada para la repartición de la información de ruteo de los servicios VPN de los clientes, se llama address familly VPNv4.
Su nombre se debe a que la información de ruteo de los clientes viaja como rutas VPNv4, eso debido a un identificador únicos de 64 bits conocido como Route Distinguisher (RD) agregado a las rutas de cada cliente. Básicamente el RD permite un PE identificar a que cliente pertenece una ruta; bueno al final del día ofrece la posibilidad de tener 2 o más clientes con prefijos idénticos y sin riesgos de causar algún tipo de conflictos, es decir si 2 clientes diferentes utilizan una misma subred, gracias al RD los prefijos se verán totalmente diferentes, y eso permitirá a los PE remotos identificar a que cliente pertenece cada ruta.
En resumen, una ruta VPNv4 es un prefijo de 96 bits, resultado directo de la combinación entre un RD (64 bits) más el prefijo original de un cliente (32 bits), sirve para asegurar que los prefijos enviados por los clientes serán siempre únicos al momento de cruzar la red MPLS y llegar a otro PE, eso habilita la infraestructura MPLS enviar/recibir prefijos idénticos que provienen de clientes distintos.
2- Aislamiento de los prefijos de los clientes
El proveedor de servicio al momento de involucrarse en el ruteo de los clientes se enfrenta al reto de no mezclar los prefijos de diferentes clientes entre sí, y también con sus prefijos internos.
Para superar este reto y lograr un aislamiento completo entre todas las redes que pasan por la infraestructura compartida, se hace uso de VRFs (Virtual Routing Forwarding), cada VRF representa una tabla de enrutamiento virtual dedicada para un cliente, y completamente aislada de la tabla de Ruteo global.
A nivel VRF es donde generalmente se configura el RD (que vimos en la sección anterior) y también Los RTs (Route-Target) que son atributos de BGP, generalmente conocidos como comunidades extendidas (Extended community), en general sirven como etiquetas para marcar las rutas de una VPN (durante la exportación) y filtrar rutas en función de ellas (durante la importación) en el PE local o remoto.
3- Envío y recepción de rutas entre PE-CE
Técnicamente se puede hacer uso de rutas estáticas o de cualquier protocolo de enrutamiento dinámico (RIPv2, OSPF, IS-IS, EIGRP, BGP) para llevar a cabo esa tarea, al final son los requerimientos específicos del diseño de la red del cliente que harán la diferencia al momento de decidir el método o protocolo de enrutamiento que hay que utilizar.
De lado del proveedor de servicio (precisamente desde el PE), independiente del protocolo elegido para el intercambio de rutas con el cliente, uno de los pasos seria agregar una instancia de BGP para la VRF del cliente. Esa instancia podría ser usada como puente para inyectar a dentro de BGP, mediante redistribución, rutas del cliente aprendidas vía IGP o rutas estáticas; o en caso de usar BGP como protocolo de ruteo entre PE - CE, servirá para establecer adyacencias e intercambiar rutas directamente con el CE cliente.
Este paso es muy importante para el reenvío de rutas VPNv4 entre PEs, ya que los prefijos instalados ahí (en la instancia de BGP para la VRF cliente), son los principales predecesores de las rutas VPNv4.
Siempre dicen que "una imagen/ilustración vale más que mil palabras" bueno aquí en la siguiente ilustración se muestra, una vista general del proceso de intercambio de rutas extremo a extremo entre dos entidades remotas (cliente) a través de la infraestructura MPLS de un proveedor de servicio usando un servicio de L3VPN.
Aprovisionamiento del servicio.
Paso 1 – Conectividad iBGP VPNv4
Para empezar con el aprovisionamiento del servicio, lo primero seria configurar las sesiones BGP VPNv4 entre los PEs, en caso de una infraestructura que ya esté en marcha, el primer paso sería validar que la sesión IBGP VPNv4 esté presente en cada PE donde se configurará el servicio del cliente.
A continuación, se muestra la configuración/validación de iBGP VPNv4 en PE201, PE203, PE204; todos configurados para establecer una sesión con el Route Reflector (P7 - 192.168.254.7), ya que la arquitectura esta centralizada.
(La configuración de PE204 es un poco diferente porque es un ASR9K con IOS-XR)
PE201
PE203
PE204
P7-RR (Route-Reflector - IOS XR)
Verificación de la sesión iBGP VPNv4 con el Route Reflector
Una vez confirmada que los PEs tienen conectividad iBGP VPNv4 establecida, pasamos al siguiente paso.
Paso 2 – Configuración de la VRF
Se configura una VRF para aislar la información de ruteo de los clientes en cada PE, y como lo mencionábamos en previa sección, la VRF contara con un RT Y RD ambos con funciones bien específicos.
Asignación de la VRF a la interfaz del cliente ( enlace PE-CE ).
Paso 3 - Configuración de ruteo entre PE y CE (Router de borde del proveedor de servicio y el Router de borde del cliente)
Al completar este último paso, damos por terminado el aprovisionamiento del servicio VPN Capa tres (L3VPN) del cliente TCCS. Del otro lado, el cliente debe tener configurado igual sus interfaces, BGP y publicar a dentro de BGP las rutas que quiere compartir en todos los sitios.
Configuración de BGP en los CEs del cliente en cada sitio
Paso 4 – Validación del servicio.
A) De lado Proveedor.
Desde el PE con el comando show bgp vpnv4 unicast vrf TCCS summary o su versión legacy show ip bgp vpnv4 vrf TCCS summary se puede verificar la sesión BGP entre el PE y el CE cliente.
Se puede confirmar que hay una sesión BGP establecida entre PE – CE, y el PE201 ha aprendido 3 rutas del CE cliente en sitio #1.
Ahora vamos a buscar mas detalles acerca de las rutas aprendidas y ver si coinciden con lo que tenemos en la topología. El comando show bgp vpnv4 unicast vrf TCCS neighbors 10.92.30.0 routes nos permitira ver las rutas aprendidas del vecino, también haremos una prueba de conectividad, con un PING, para ver si los prefijos son alcanzables.
La información coincide con lo que tenemos en el diseño, los prefijos son alcanzables, así que en sitio #1 todo está funcionando de acuerdo con las expectativas.
Último paso, verificamos que el PE201 está recibiendo rutas de los demás sitios a través de los demás PEs (PE203 Y PE204), y de igual manera confirmamos que se esta enviando estas rutas al CE directamente conectado (CE sitio #1 en este caso).
Con el comando show bgp vpnv4 unicast vrf TCCS se puede ver todas las rutas recibidas en el PE201 para la instancia del cliente, en este caso VRF TCCS; y el comando show bgp vpnv4 unicast vrf TCCS neighbors 10.92.30.0 advertised-routes permite ver las rutas que el PE esta enviando a sitio cliente (CE sitio #1 en este caso).
Se puede apreciar que el PE201 recibió 6 prefijos provenientes de los demás sitios (sitio cliente #2 y #3), y envió las 6 rutas al CE directamente conectado (CE sitio #1), así de igual forma se confirma que el intercambio de información de ruteo entre los sitios del cliente, a través de los PEs, sí está ocurriendo.
Haremos lo mismo en los demás sitios.
Sitio #2
Validación
Sesión BGP establecida desde PE203
Rutas aprendidas
Prueba de conectividad
Rutas aprendidas por MP-BGP VPNv4 y rutas enviadas a sitio cliente directamente conectado.
Sitio #3
Validación
Sesión BGP establecida desde PE204
Rutas aprendidas
Prueba de conectividad.
Rutas aprendidas por MP-BGP VPNv4 y rutas enviadas a sitio cliente directamente conectado.
Después de llevar a cabo estas series de pruebas en el PE de cada sitio, podemos confirmar que el servicio está funcionando de acuerdo con el diseño y los requerimientos del cliente. Estas mismas pruebas se pueden repetir en caso de troubleshooting, para detectar posible falla en el servicio entregado.
b) De lado Cliente.
Ahora el cliente deberá poder realizar una prueba de conectividad extremo a extremo para validar la interconectividad entre las oficinas remotas.
El cliente, en este caso TCCS, tiene una vista un poco distinta de la red, hay una abstracción casi total de la infraestructura del proveedor de servicio, una vista similar a la siguiente imagen.
Prueba de conectividad extremo a extremo desde oficina del sitio #1 hacia oficinas de los sitios #2 y #3.
Conclusión
¡Se logró! cliente satisfecho. Se comprobó una conectividad full-mesh entre todas las oficinas remotas de TCCS y vimos la magia del servicio VPN capa 3.
De ahora en adelante, agregar un sitio nuevo a esa red será una tarea bastante sencilla y más fácil aun si se va a configurar en un PE donde ya esta operando el servicio del cliente, basta con configurar la interfaz y eBGP, el sitio nuevo tendrá automáticamente todas las rutas necesarias para unirse a la red privada del cliente y ser operacional. Por eso y más, este servicio sigue siendo el preferido de muchos clientes para interconectar sus sitios remotos.