Continuando la línea del post anterior (Etiquetas IGP y VPN I), se verá la importancia de setear correctamente los RT de acuerdo a la conectividad deseada para las distintas VPNs.


Dado el siguiente extracto de la configuración de R1, se quiere probar conectividad a R6 a través de R4.

hostname R1
!
ip vrf Router1
rd 1:1
route-target export 3:1
route-target export 5:1
route-target import 1:1
!
interface Loopback1
ip vrf forwarding Router1
ip address 192.168.0.1 255.255.255.255
!

Primero que nada se revisa se esté recibiendo en R1 correctamente el prefijo correspondiente a R6 y si tiene las etiquetas de IGP y VPN asignadas.

R1#sh ip cef vrf Router1 192.168.0.6 det
192.168.0.6/32, epoch 0
recursive via 6.6.6.6 label 17
nexthop 10.0.0.6 Serial1/1 label 16
R1#

Se ve todo en orden, sin embargo la prueba conectividad falla.

R1#ping vrf Router1 192.168.0.6 r 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
..
Success rate is 0 percent (0/2)

R1#

En R4 se hace un debug de los paquetes MPLS con debug mpls packets.

R4#debug mpls packet
Packet debugging is on
R4#
*Sep  2 16:50:03.271: MPLS turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 255} - ipv4 data
*Sep  2 16:50:03.275: MPLS turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 data
R4#
*Sep  2 16:50:05.303: MPLS turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 255} - ipv4 data
*Sep  2 16:50:05.307: MPLS turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 data
R4#

Se puede ver cómo se reciben (rx) los paquetes con dos etiquetas; IGP = 16 y VPN = 17. De la LFIB se desprende que el paquete será derivado (tx) con una única etiqueta (17) a R6 (se realiza el POP de la etiqueta 16).

R4#sh mpls forwarding-table | i Local|16
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
16     Pop Label     6.6.6.6/32        756           Se1/2      point2point
17     Pop Label     192.168.0.4/32[V] 1000          aggregate/Router4       
R4#

Ahora se verá que R6 recibe correctamente estos paquetes con esta única etiqueta (17), la cual está asociada a al prefijo 192.168.0.6 de la VRF Router6.

R6(config)#access-list 100 permit icmp any any
R6(config)#^Z

R6#
*Sep  2 16:49:29.935: %SYS-5-CONFIG_I: Configured from console by consoledebug ip pach
R6#debug ip packet 100
IP packet debugging is on for access list 100
R6#
*Sep  2 16:49:44.963: MPLS turbo: Se1/0: rx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 16:49:44.967: MPLS les: Se1/0: rx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 16:49:44.971: IP: tableid=1, s=192.168.0.1 (Serial1/0), d=192.168.0.6 (Loopback1), routed via RIB
*Sep  2 16:49:44.975: IP: s=192.168.0.1 (Serial1/0), d=192.168.0.6, len 100, rcvd 4
*Sep  2 16:49:44.979: IP: s=192.168.0.1 (Serial1/0), d=192.168.0.6, len 100, stop process pak for forus packet
*Sep  2 16:49:44.983: IP: s=192.168.0.6 (local), d=192.168.0.1, len 100, unroutable
*Sep  2 16:49:46.947: MPLS turbo: Se1/0: rx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 16:49:46.947: MPLS les: Se1/0: rx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 16:49:46.955: IP: tableid=1, s=192.168.0.1 (Serial1/0), d=192.168.0.6 (Loopback1), routed via RIB
*Sep  2 16:49:46.955: IP: s=192.168.0.1 (Serial1/0), d=192.168.0.6, len 100, rcvd 4
*Sep  2 16:49:46.959: IP: s=192.168.0.1 (Serial1/0), d=192.168.0.6, len 100, stop process pak for forus packet
*Sep  2 16:49:46.963: IP: s=192.168.0.6 (local), d=192.168.0.1, len 100, unroutable
R6#

Si bien se recibe el paquete IP de manera correcta, al generar la respuesta (Echo Reply) el destino (origen de los paquetes recibidos) no se encuentra en la RIB, por ende el paquete no puede ser ruteado, entonces R4 nunca recibirá las respuestas. Esto es fácilmente comprobable al revisar los prefijos vpnv4 recibidos tabla BGP.

R6#sh ip bgp vpnv4 all | i Network|192.168.0

Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.0.4/32   4.4.4.4                  0    100      0 ?
*>i192.168.0.4/32   4.4.4.4                  0    100      0 ?
*> 192.168.0.6/32   0.0.0.0                  0         32768 ?
R6#

Esto se soluciona fácilmente exportando la ruta en R1.

R1#conf t                    
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip vrf Router1   
R1(config-vrf)#route-target export 6:1
R1(config-vrf)#^Z
R1#
R1#
*Sep  2 16:58:15.259: %SYS-5-CONFIG_I: Configured from console by console
R1#

Luego se prueba nuevamente y se ve cómo se reciben (rx) correctamente las respuetas que viene encapsuladas con una única etiqueta (21).

R1#ping vrf Router1 192.168.0.6 r 2

Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 192.168.0.6, timeout is 2 seconds:
!!
Success rate is 100 percent (2/2), round-trip min/avg/max = 128/140/152 ms

R1#
*Sep  2 17:01:59.559: MPLS turbo: Se1/1: rx: Len 108 Stack {21 0 254} - ipv4 data
*Sep  2 17:01:59.563: MPLS les: Se1/1: rx: Len 108 Stack {21 0 254} - ipv4 data
*Sep  2 17:01:59.695: MPLS turbo: Se1/1: rx: Len 108 Stack {21 0 254} - ipv4 data
*Sep  2 17:01:59.695: MPLS les: Se1/1: rx: Len 108 Stack {21 0 254} - ipv4 data
R1#

Tal como se vio con anterioridad en R4 los paquetes provenientes de R1 tienen dos etiquetas (IGP = 16 y VPN = 17) y se entregan a R6 con sólo una (17). Sin embargo ahora R4 recibe de R6 las respuestas con dos etiquetas (IGP = 22 y VPN = 21) y entrega a R1 con sólo una (21)

R4#
*Sep  2 17:01:59.443: MPLS turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 255} - ipv4 data
*Sep  2 17:01:59.447: MPLS turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 17:01:59.539: MPLS turbo: Se1/2: rx: Len 112 Stack {22 0 255} {21 0 255} - ipv4 data
*Sep  2 17:01:59.543: MPLS turbo: Se1/0: tx: Len
108 Stack {21 0 254} - ipv4 data
*Sep  2 17:01:59.647: MPLS turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 255} - ipv4 data
*Sep  2 17:01:59.651: MPLS turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 data
*Sep  2 17:01:59.671: MPLS turbo: Se1/2: rx: Len 112 Stack {22 0 255} {21 0 255} - ipv4 data
*Sep  2 17:01:59.675: MPLS turbo: Se1/0: tx: Len 108 Stack
R4# {21 0 254} - ipv4 data

Por ende el path completo es el que se muestra en la figura:


Se puede comprobar en R6 las etiquetas con que se generó el Echo Reply.

R6#sh ip cef vrf Router6 192.168.0.1
192.168.0.1/32
nexthop 172.16.0.5 Serial1/0 label 22 21
R6#sh ip cef vrf Router6 192.168.0.1 det
192.168.0.1/32, epoch 0
recursive via 1.1.1.1 label 21
nexthop 172.16.0.5 Serial1/0 label 22

Además de revisar las LFIBs de cada uno de los routers para el path de regreso.

R6#
R6#sh mpls forwarding-table | i Local|22
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
22     21            10.0.0.0/30       0             Se1/0      point2point
24     22            1.1.1.1/32        0             Se1/0      point2point
R6#

R4#sh mpls forwarding-table | i Local|22
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
22     Pop Label     1.1.1.1/32        432           Se1/0      point2point
R4#

R1#sh mpls forwarding-table | i Local|21
Local  Outgoing      Prefix            Bytes Label   Outgoing   Next Hop
21     Pop Label     192.168.0.1/32[V] 800           aggregate/Router1       
R1#