lunes, 7 de septiembre de 2009

Etiquetas IGP y VPN II

Posted by Nicolas | lunes, 7 de septiembre de 2009 | Category: , , |

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#

En total 3 comentarios:

  1. nice explanation.

    regards
    shivlu jain
    http://shivlu.blogspot.com


Leave a Reply