- 19/12/2018
- Routing
Teniendo como base lo aprendido en la entrada anterior, en la que desplegamos nuestro primer entorno de laboratorio en EVE-NG, ahora implementaremos una solución básica de MPLS VPN sin Route Reflector, considerando la topología mostrada en la Figura 1.

Figura 1: Topología de MPLS VPN sin Route Reflector
- CE1: 11.11.11.11/32
- PE1: 22.22.22.22/32
- CE2: 33.33.33.33/32
- PE2: 44.44.44.44/32
Asimismo, utilizaremos el protocolo de enrutamiento dinámico IS-IS al interior de la red del proveedor de servicios, tal como se muestra en las siguientes líneas.
hostname CE1
interface loopback 0
ip address 11.11.11.11 255.255.255.255
interface Gi 0/0
ip address 192.168.12.1 255.255.255.0
no shutdown
hostname CE2
interface loopback 0
ip address 22.22.22.22 255.255.255.255
interface Gi 0/0
ip address 192.168.34.4 255.255.255.0
no shutdown
hostname PE1
interface loopback 0
ip address 1.1.1.1 255.255.255.255
interface Gi 0/0
ip address 192.168.12.2 255.255.255.0
no shutdown
interface Gi 0/1
ip address 10.0.23.2 255.255.255.0
ip router isis
no shutdown
router isis
net 49.0001.1111.1111.1111.00
passive-interface Loopback0
is-type level-1
hostname PE2
interface loopback 0
ip address 2.2.2.2 255.255.255.255
interface Gi 0/0
ip address 192.168.34.3 255.255.255.0
no shutdown
interface Gi 0/1
ip address 10.0.23.3 255.255.255.0
ip router isis
no shutdown
router isis
net 49.0001.2222.2222.2222.00
passive-interface Loopback0
is-type level-1
Ahora, podremos verificar la conectividad entre los segmentos directamente conectados, tal como se muestra en las Figuras 2 a la 4.

Figura 2: Verificación de la conectividad entre CE1 y PE1

Figura 3: Verificación de la conectividad entre PE1 y PE2

Figura 4: Verificación de la conectividad entre CE2 y PE2
Como es sabido, el protocolo LDP únicamente debe habilitarse al interior del proveedor de servicios, dado que sólo aquí funciona MPLS y, por lo tanto, sólo en ese segmento de la red se necesita LDP.
mpls ip
mpls label protocol ldp
mpls ldp router-id loopback 0 force
interface Gi 0/1
mpls ip
mpls label protocol ldp
A continuación, verificaremos las sesiones LDP activas en cada router, como se aprecia en las Figuras 5 y 6.

Figura 5: Sesiones LDP activas en PE1

Figura 6: Sesiones LDP activas en PE2
Ya que los PEs son los equipos que intercambian los prefijos VPNv4, la implementación de MP-BGP sólo se realiza en dichos equipos.
router bgp 6147
neighbor 2.2.2.2 remote-as 6147
neighbor 2.2.2.2 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community extended
router bgp 6147
neighbor 1.1.1.1 remote-as 6147
neighbor 1.1.1.1 update-source Loopback0
no auto-summary
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
A continuación, como se aprecia en las Figuras 7 y 8, verificamos las sesiones BGP de la familia de direcciones IPv4

Figura 7: Sesiones BGP IPv4 en PE1

Figura 8: Sesiones BGP IPv4 en PE2
De igual manera, corroboramos las sesiones BGP de la familia de direcciones VPNv4, según se muestra en las Figuras 9 y 10.

Figura 9: Sesiones BGP VPNv4 en PE1

Figura 10: Sesiones BGP VPNv4 en PE2
Para lograr que las VRFs “CLIENTE” pertenezcan a la misma VPN, el Route Target Export de una de las VRF debe coincidir con el Route Target Import de la otra, y viceversa.
! Creación de la VRF
ip vrf CLIENTE
rd 100:1
route-target export 100:1
route-target import 200:1
! Asignación de la VRF
interface Gi 0/0
ip vrf forwarding CLIENTE
ip address 192.168.12.2 255.255.255.0
! Creación de la VRF
ip vrf CLIENTE
rd 200:1
route-target export 200:1
route-target import 100:1
! Asignación de la VRF
interface Gi 0/0
ip vrf forwarding CLIENTE
ip address 192.168.34.3 255.255.255.0
Luego, según se detalla en las Figuras 11 y 12, debemos verificar las VRFs configuradas y su asignación en las interfaces respectivas.

Figura 11: Verificación de la VRF en PE1

Figura 12: Verificación de la VRF en PE2
Recuerde que la configuración debe realizarse en la tabla global en los CEs, mientras que en los PEs debe hacerse en la VRF correspondiente al respectivo cliente.
router bgp 100
neighbor 192.168.12.2 remote-as 6147
network 11.11.11.11 mask 255.255.255.255
no auto-summary
router bgp 6147
address-family ipv4 vrf CLIENTE
neighbor 192.168.12.1 remote-as 100
neighbor 192.168.12.1 activate
router bgp 200
neighbor 192.168.34.3 remote-as 6147
network 22.22.22.22 mask 255.255.255.255
no auto-summary
router bgp 6147
address-family ipv4 vrf CLIENTE
neighbor 192.168.34.4 remote-as 200
neighbor 192.168.34.4 activate
Ahora, en las Figuras 13 a la 16, mostraremos las sesiones BGP formadas en cada equipo, recordando que para el caso de los PEs se debe verificar las sesiones VPNv4.

Figura 13: Sesiones BGP en CE1

Figura 14: Sesiones BGP en PE1

Figura 15: Sesiones BGP en CE2

Figura 16: Sesiones BGP en PE2
Previamente a verificar la conectividad, observamos las tablas de enrutamiento BGP en los CEs., tal como se aprecia en las Figuras 17 y 18.

Figura 17: Tabla de enrutamiento BGP de CE1

Figura 18: Tabla de enrutamiento BGP de CE2
Dado que las redes del otro extremo aparecen en cada CE, ahora evaluamos la conectividad entre las redes de ambos CEs, según se muestra en las Figuras 19 y 20.

Figura 19: Conectividad exitosa entre las redes de CE1 y CE2, vista desde CE1

Figura 20: Conectividad exitosa entre las redes de CE1 y CE2, vista desde CE2
Dado que las pruebas de conectividad fueron exitosas, hemos concluido con esta experiencia. En la siguiente entrada implementaremos MPLS VPN con Route Reflector.
Entradas recientes
- Solución de MPLS VPN sin Route Reflector 19/12/2018
- Despliegue del primer entorno de laboratorio en EVE-NG 12/12/2018
- Carga de imágenes de sistemas operativos en EVE-NG 05/12/2018
- Instalación de EVE-NG en un servidor en la nube 20/11/2018
- Acceso remoto a un servidor en una infraestructura en la nube 24/10/2018