En este caso de uso, se presenta paso a paso el proceso para implementar una interconexión entre dos sistemas autónomos o proveedores de servicios MPLS con el fin de expandir los servicios VPNs de capa tres (MPLS L3VPN) en las dos infraestructuras.
Esa solución permite extender de forma horizontal la capacidad de una infraestructura MPLS de un proveedor de servicio a través de otro, superando las limitaciones de infraestructura propia para llegar a clientes en algunas zonas geográficas.
En algunos casos, es una necesidad implícita después de la adquisición de un ISP o MSP por otro ISP. Como resultado final, se podrá aprovisionar (servicios VPNs) a varios sitios de un mismo cliente desde las 2 infraestructuras. Los paquetes de datos pasan de un SP a otro, y es una operación totalmente transparente para el cliente final.
Ilustración 1 – Flujo de tráfico cliente extremo a extremo a través de los 2 SPs.
Escenario
Ilustración 2 – Vista general de la infraestructura de SP1 y SP2.
Crear una interconexión entre SP1 y SP2 exclusivamente para servicios VPNs con las siguientes características:
Inter-AS MPLS L3VPN opción B
Enlace primario XPE200 à WPE20 (10.190.190.2/31)
Enlace secundario XPE5 à WPE10 (10.190.190.0/31)
Diseño
Ilustración 3 – Diseño (HLD) de IXC 1 y 2 entre ambos SPs.
Implementación
La opción B del Inter-AS L3VPN se implementa creando una sesión BGP VPNv4 entre los dos Routers de borde (ASBRs) de cada SP.
En Cisco IOS/IOS XR, como mecanismo de ahorro de recursos, por defecto los PEs rechazan las rutas de las VRFs no presentes en el PE, por eso como paso adicional se debe configurar los ASBRs de tal forma que acepten y comparten todas las rutas VPNs recibidas, incluyendo los prefijos de las VRFs que no están configuradas en el ASBR.
Paso 1 - Configuración de las interfaces.
IXC 1 – Enlace primario
X-PE200
interface BDI130
description toSP2__IXC-INTER-AS_MPLS-L3VPN__primario
ip address 10.190.190.2 255.255.255.254
encapsulation dot1Q 130
exitW-PE20
interface GigabitEthernet0/5.130
description toSP1__IXC-INTER-AS_MPLS-L3VPN__primario
encapsulation dot1Q 130
ip address 10.190.190.3 255.255.255.254
exitIXC 2 – Enlace secundario
X-PE5
interface GigabitEthernet0/0/0/10.99
description toSP2__IXC-INTER-AS_MPLS-L3VPN_secundario
ipv4 address 10.190.190.0 255.255.255.254
encapsulation dot1q 99
exit
commitW-PE10
interface GigabitEthernet0/3.99
description toSP1__IXC-INTER-AS_MPLS-L3VPN_secundario
encapsulation dot1Q 99
ip address 10.190.190.1 255.255.255.254
exitPaso 2 - Configuración de la sesión BGP VPNv4.
Como referencia adicional, hay que mencionar que los ASBRs (XPE200, WPE20, XPE5, WPE10) son PEs que inicialmente fueron configurados como “route-reflector-client”, es decir el intercambio de información de enrutamiento a nivel BGP, a dentro del sistema autónomo, se hace por intermedio del route reflector.
Ilustración 4 – intercambio de iBGP updates a dentro del sistema autónomo a través de los route-reflectors.
Para lograr que IXC-1 sea el enlace primario, en los ASBRs de SP1 se configura políticas (Route-map o route-policy) para manipular los atributos de BGP (Local Preference y MED) y así influenciar el tráfico de ida/regreso a través de IXC-1.
Como dicta el algoritmo de mejores rutas de BGP, en caso de tener múltiples caminos válidos para un prefijo, durante el proceso para determinar la mejor ruta, si el empate llega a nivel de comparación de los “local-preference”, la ruta con el LP más alto gana; para el MED (Multi-Exit-Discriminator), la ruta con el MED mas bajo gana.
Vista de las políticas aplicadas a los prefijos entrantes/salientes en SP1.
Ilustración 5 – Vista de las políticas de ruteo aplicadas en XPE200 Y XPE5.
Configuración eBGP VPNv4 IXC 1 – Enlace Primario
X-PE200
route-map L3VPN_INTER_AS_IN permit 10
set local-preference 120
exit
route-map L3VPN_INTER_AS_OUT permit 10
set metric 10
exit
router bgp 64512
no bgp default route-target filter
neighbor 10.190.190.3 remote-as 64516
neighbor 10.190.190.3 password cisco1216
neighbor 10.190.190.3 timers 2 3
address-family vpnv4
neighbor 10.190.190.3 activate
neighbor 10.190.190.3 route-map L3VPN_INTER_AS_IN in
neighbor 10.190.190.3 route-map L3VPN_INTER_AS_OUT out
neighbor 198.18.190.1 next-hop-self W-PE20
router bgp 64516
no bgp default route-target filter
neighbor 10.190.190.2 remote-as 64512
neighbor 10.190.190.2 password cisco1216
address-family vpnv4
neighbor 10.190.190.2 activate
neighbor 10.190.190.2 send-community extended
neighbor 198.18.175.1 next-hop-selfConfiguración eBGP VPNv4 IXC 2 – Enlace Secundario
X-PE5
route-policy L3VPN_INTER_AS_POLICY_IN
set local-preference 110
pass
done
end-policy
commit
route-policy L3VPN_INTER_AS_POLICY_OUT
set med 20
pass
done
end-policy
commit
router bgp 64512
timers bgp 2 3
address-family vpnv4 unicast
retain route-target all
neighbor 10.190.190.1
remote-as 64516
password cisco1216
address-family vpnv4 unicast
route-policy L3VPN_INTER_AS_POLICY_IN in
route-policy L3VPN_INTER_AS_POLICY_OUT out
neighbor 198.18.190.1
remote-as 64512
address-family vpnv4 unicast
next-hop-self
commit
endW-PE10
router bgp 64516
no bgp default route-target filter
neighbor 10.190.190.0 remote-as 64512
neighbor 10.190.190.0 password cisco1216
address-family vpnv4
neighbor 10.190.190.0 activate
neighbor 10.190.190.0 send-community extended
neighbor 198.18.175.1 next-hop-selfEl comando “no bgp default route-target filter” en IOS o “retain route-target all” en IOS-XR, hace que el PE sobrescriba su comportamiento por defecto de rechazar las rutas de las VRFs no presentes en el equipo, ahora en su rol como ASBR es necesario recibir y retener todos los prefijos de todas las VRFs proveniente del Sistema autónomo adyacente.
En IOS, el comando “neighbor IP-address next-hop-self” se utiliza para cambiar el Nexthop de todas las rutas eBGP VPNv4 aprendidas a través de la interconexión. Básicamente es la forma del ASBR de indicar que el mismo será el nexthop de esos prefijos. (IP- address = route-reflector del SP).
En cisco IOS Después de la configuración de la sesión eBGP VPNv4, el PE de manera automática agrega una ruta estática (/32) hacia el vecino eBGP, esa acción permite asociar una etiqueta MPLS al next-hop de la interconexión, y también se agrega el comando “mpls bgp forwarding” en las interfaces de la interconexión para habilitar el reenvío de paquetes etiquetados por BGP en la interfaz.
Verificación
XPE200#show run interface bdi 130
interface BDI130
ip address 10.190.190.2 255.255.255.254
encapsulation dot1Q 130
mpls bgp forwarding
end
XPE200#show ip route | inc 10.190.190.3
C 10.190.190.3/32 is directly connected, BDI130
XPE200#
XPE200#sh mpls forwarding-table | inc 10.190.190.3/32
200027 Pop Label 10.190.190.3/32 0 BD130 10.190.190.3
XPE200#
WPE20#sh run int GigabitEthernet0/5.130
interface GigabitEthernet0/5.130
encapsulation dot1Q 130
ip address 10.190.190.3 255.255.255.254
mpls bgp forwarding
end
WPE20#
WPE20#show ip route | inc 10.190.190.2
C 10.190.190.2/31 is directly connected, GigabitEthernet0/5.130
WPE20#
WPE20#sh mpls forwarding-table | inc 10.190.190.2/32
2025 Pop Label 10.190.190.2/32 0 Gi0/5.130 10.190.190.2
WPE20#
En IOSXR este proceso no es automático, se requiere configurar manualmente la ruta estática y asegurar que hay una política que permita recibir/enviar rutas en la sesión eBGP.
Configuración de la ruta estática y verificación de etiquetas MPLS
XPE5
configure
router static
address-family ipv4 unicast
10.190.190.1/32 GigabitEthernet0/0/0/10.99
commit
RP/0/RP0/CPU0:XPCOR5_temp_PE#sh mpls forwarding | in 10.190.190.1
Tue Oct 1 03:39:08.545 UTC
115030 Pop 10.190.190.1/32 Gi0/0/0/10.99 10.190.190.1 75302594
RP/0/RP0/CPU0:XPCOR5_temp_PE#Paso 3 – Verificación de las sesiones eBGP VPNv4.
Ahora es momento de verificar las sesiones eBGP VPNv4 que acabamos de configurar para intercambiar información de ruteo entre ambos proveedores de servicios MPLS (MSP).
eBGP VPNv4 IXC 1 – Enlace Primario
X-PE200 <---> W-PE20
eBGP VPNv4 IXC 2 – Enlace Secundario
X-PE5 <---> W-PE10
Se observa sesiones “eBGP VPNv4” establecidas e intercambio de prefijos en ambos enlaces, con esa evidencia se confirma una implementación exitosa de eBGP.
Paso 4 - Confirmación del enlace primario
De acuerdo con el diseño, XPE200 debe ser el punto de entrada y salida principal para SP1, y WPE20 para SP2 (tal como se muestra en la siguiente imagen).
Ilustración 6 – Flujo de tráfico en el enlace primario IXC-1 .
Verificación
Desde los route-reflectors de cada SP (X-PRR1, WPRR1) se valida que efectivamente XPE200 y WPE20 (ASBRs) ofrecen la mejor ruta en sus respectivos SPs.
Desde XPRR1 (SP1), gracias al route-map que aplicamos en XPE200 en la sección anterior, se observa que todos los prefijos provenientes del AS 64516 (SP2) tienen un local preference de 120, son registrados como mejores rutas en la tabla de enrutamiento local de BGP del route-reflector, y desde luego son enviados a los demás PEs a dentro del Sistema autónomo.
Se puede observar algo similar en WRR1 (SP2), la única diferencia es que la elección de mejor ruta fue influenciada por la métrica (MED) más baja; por eso, los prefijos aprendidos vía WPE20 teniendo una métrica de 10 fueron elegidos mejores rutas. WPE20 será el siguiente salto para cualquier tráfico (VPN) con destino a SP1.
Paso 5 - Prueba de conectividad extremo a extremo (lado cliente)
En esta sección se aprovisiona un servicio L3VPN de un cliente “Customer A” con sitios conectados a ambos SPs, y así validar el reenvío de trafico entre ambos sistemas autónomos.
Diseño de alto nivel (HLD)
Vista desde la perspectiva del cliente.
Ilustración 7 – Interconexión de sitios remotos a través de un SP, perspectiva cliente.
Vista de los 3 sitios del cliente “CUSTOMER A” desde la perspectiva de los SPs
Ilustración 8 – Interconexión de sitios remotos de un cliente, perspectiva del proveedor de servicio.
Como se puede apreciar en la imagen sitio 1 y 2 están conectados en SP1 (XPE100, YPE110), y sitio 3 está conectado en SP2 (WPE30).
Verificación de los prefijos en cada PE.
XPE100
YPE110
WPE30
En todos los casos, se puede observar que los PEs tienen a los ASBRs de IXC-1 como “Next-hop”. Con esa evidencia, una vez más se comprueba IXC-1 como enlace primario.
Prueba de conectividad entre sitios clientes
Sitio3 <---> Sitio 1 (Inter-AS)
Sitio 3 <---> Sitio 2 (Inter-AS)
Paso 6 - Prueba de Redundancia
El objetivo de esta prueba es validar la conmutación automática y exitosa de trafico a IXC-2 en caso de algún evento o falla de comunicación en IXC1. Es una forma de asegurar una alta disponibilidad de los servicios que dependen de la interconexión.
Ilustración 9 – Conmutación de tráfico a IXC-2 ante algún evento que impacte a IXC-1.
Teniendo un ping corriendo (Sitio 3 <---> Sitio 1), simulamos una falla de comunicación en IXC-1 apagando la interfaz Gi0/5.130 en WPE20 (SP2).
Gi0/5.130
Traceroute antes de apagar la interfaz
Ping durante la prueba
Traceroute después de apagar la interfaz.
Se puede apreciar una conmutación exitosa de IXC-1 a IXC-2, con eso validamos que la interconexión entre ambos SPs está bien protegida, ofrece una alta disponibilidad y garantiza una continuidad de servicio en caso de que falle el enlace primario.
Fin
Kommentarer