Вы находитесь на странице: 1из 20

BGP/MPLS IP VPNs I

Posted by Nicolas | martes, 2 de junio de 2009 | Category: BGP, IPv4, IS-IS, Layer 3 VPNs, MPLS | Dentro de los nuevos tpicos a incluir en la versin 4 del examen de R&S est MPLS (RFC 3031), en particular MPLS/VPN, descrito en el RFC 4364 (deja obsoleto 2547). Es por esto que a continuacin se describir el algunos conceptos bsicos para el set-up de VPNs utilizando esta tecnologa. Se utilizar la topologa de la figura.

Primero que nada se setea el IGP de nuestra red, tomando en consideracin que debemos insertar en la tabla de ruteo una direccin de host (/32) que identifique a cada equipo como se describe en el punto 5 (Forwarding) del RFC 4364. En nuestro caso se utilizar Integrated IS-IS usando la direccin de Loopback 0 seteada en cada equipo. A continuacin la configuracin relevante en uno de los PEs para lo sealado.
hostname PE1 ! ip cef ! interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface Serial1/0 ip address 192.168.0.1 255.255.255.252 ip router isis ! router isis net 49.0001.0010.0100.1001.00 passive-interface Loopback0

Luego se debe setear el protocolo que intercambiar etiquetas entre ambos equipos. En particular se usar LDP (RFC 3036).
interface Serial1/0 mpls label protocol ldp mpls ip

Luego se crea una VPN Routing and Forwarding table, que es distinta de la default forwarding table como describe el punto 3 (VRFs: Multiple Forwarding Tables in Pes) del RFC 4364. Localmente se le asigna un nombre que tiene significancia slo en el PE configurado. Cabe destacar que las VRFs no son una caracterstica propia de MPLS, es decir se pueden configurar

sin la necesidad de implementar esta tecnologa. Una buena referencia al respecto es la escrita por Jeremy Stretch en Intro to VRF lite.
hostname PE1 ! ip vrf Customer rd 1.1.1.1:1234 route-target export 1.1.1.1:1111 route-target import 2.2.2.2:2222 ! hostname PE2 ! ip vrf Customer rd 2.2.2.2:1234 route-target export 2.2.2.2:2222 route-target import 1.1.1.1:1111

Aparecen un par de elementos nuevos, el primero es RD (Route Distinguisher), quin se encarga de acompaar el anuncio de los prefijos entre PEs (seccin 4.1, The VPN-IPv4 Address Family en el RFC 4364), permitiendo el uso independiente de direcciones IP entre VRFs, por ende dos clientes puedan hacer uso de la red 10.0.0.0/8 como ejemplo. El atributo Route Target, permite setear la comunidad extendida de BGP, Route Target (RFC 4360, BGP Extended Communities Attribute) que permite a las VRFs importar y exportar prefijos de acuerdo a sus necesidades, lo que determina las distintas VPNs (seccin 4.3.5, Building VPNs Using Route Targets en el RFC 4364). Por ltimo (en esta primera parte) se setear la sesin BGP vpnv4 (address-family vpnv4) entre ambos PEs, lo cual por el contrario de las IPv4, no est activa por defecto.
hostname PE1 ! router bgp 64512 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 64512 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 exit-address-family ! address-family ipv4 vrf Customer no synchronization exit-address-family !

Un breve chequeo nos verifica que al menos la Nube MPLS ya est lista.
PE2#sh ip bgp vpnv4 all sum BGP router identifier 2.2.2.2, local AS number 64512 BGP table version is 7, main routing table version 7 1 network entries using 141 bytes of memory 1 path entries using 68 bytes of memory 2/1 BGP path/bestpath attribute entries using 152 bytes of memory 1 BGP extended community entries using 24 bytes of memory

0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 385 total bytes of memory BGP activity 3/2 prefixes, 3/2 paths, scan interval 15 secs Neighbor State/PfxRcd 1.1.1.1 PE2# V AS MsgRcvd MsgSent 16 15 TblVer 7 InQ OutQ Up/Down 0 0 00:11:39 0

4 64512

Corresponde ahora configurar los clientes. Cada CE ser configurado por ahora con una ruta default al PE.

En los PEs se asociar las interfaces correspondientes a la VRF configurada.


PE1#sh run int f2/0 Building configuration... Current configuration : 185 bytes ! interface FastEthernet2/0 ip vrf forwarding Customer ip address 10.0.0.1 255.255.255.252 speed auto duplex auto end PE2#sh run int f2/0 Building configuration... Current configuration : 185 bytes ! interface FastEthernet2/0 ip vrf forwarding Customer ip address 10.0.0.5 255.255.255.252 speed auto duplex auto end

Para hacer visibles ambos extremos, BGP se encargar de anunciar las redes de la VRF entre los PEs gracias a la definicin del RFC 2858 (Multiprotocol Extensions for BGP-4). Esto siempre y cuando las redes sean insertadas en la tabla de BGP. Para esto es necesario redistribuir las redes

existentes, que por ahora son slo directamente conectadas, por lo tanto se utilizar redistribute connected dentro del address-family ipv4 correspondiente.
router bgp 64512 ! address-family ipv4 vrf Customer no synchronization redistribute connected exit-address-family !

Con esto efectivamente se comienza a recibir la red del otro extremo.


PE1#sh ip bgp vpnv4 vrf Customer BGP table version is 5, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 1.1.1.1:1234 (default for vrf Customer) *> 10.0.0.0/30 0.0.0.0 0 32768 ? *>i10.0.0.4/30 2.2.2.2 0 100 0 ?

Ahora se necesita comprobar la conectividad extremo a extremo.


CE1#sh ip rou Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is 10.0.0.1 to network 0.0.0.0 10.0.0.0/30 is subnetted, 1 subnets C 10.0.0.0 is directly connected, FastEthernet0/0 S* 0.0.0.0/0 [1/0] via 10.0.0.1 CE1#ping 10.0.0.6 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.0.6, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 88/116/148 ms CE1#

El siguiente paso ser levantar un protocolo de ruteo. Se utilizar OSPF y se anunciar direcciones de loopback entre los CEs.
CE1#conf t Enter configuration commands, one per line. End with CNTL/Z. CE1(config)#int loop 0 CE1(config-if)#ip add 10.1.1.1 255.255.255.255 CE1(config)#router ospf 1 CE1(config-router)#net 10.0.0.0 0.255.255.255 area 0 CE1(config-router)#passive-interface loop0

CE1(config-router)#^Z CE1# CE2#conf t Enter configuration commands, one per line. End with CNTL/Z. CE2(config)#int loop 0 CE2(config-if)#ip add 10.2.2.2 255.255.255.255 CE2(config-if)#router ospf 1 CE2(config-router)#net 10.0.0.0 0.255.255.255 area 0 CE2(config-router)#passive-interface loop 0 CE2(config-router)#^Z CE2#

Basta con esto?. No, los CEs deben formar vecindades con los PEs que distribuirn los anuncios en BGP.
PE1#conf t Enter configuration commands, one per line. End with CNTL/Z. PE1(config)#router ospf 2 vrf Customer PE1(config-router)#net 10.0.0.0 0.0.0.255 area 0 PE1(config-router)#^Z PE1# PE2#conf t Enter configuration commands, one per line. End with CNTL/Z. PE2(config)#router ospf 3 vrf Customer PE2(config-router)#net 10.0.0.0 0.255.255.255 area 0 PE2(config-router)#^Z PE2#

Notar que los nmeros de proceso de OSPF tienen significancia slo para el router local. Se revisan las vecindades con show ip ospf neighbor.
CE1#sh ip ospf nei Neighbor ID Pri 10.0.0.1 1 FastEthernet0/0 CE1# PE1#sh ip ospf nei Neighbor ID Pri 10.1.1.1 1 FastEthernet2/0 PE1# State FULL/DR Dead Time 00:00:37 Address 10.0.0.2 Interface State FULL/BDR Dead Time 00:00:36 Address 10.0.0.1 Interface

Se revisa la tabla de ruteo de la VRF con show ip route vrf.


PE1#sh ip rou vrf Customer Routing Table: Customer Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.0.0.0/30 is directly connected, FastEthernet2/0 L 10.0.0.1/32 is directly connected, FastEthernet2/0 B 10.0.0.4/30 [200/0] via 2.2.2.2, 00:14:55 O 10.1.1.1/32 [110/2] via 10.0.0.2, 00:03:30, FastEthernet2/0 PE1#

Se comprueba que se est recibiendo la ruta del CE conectado directamente. Para recibir la del otro extremo hay que redistribuir en BGP tal como se hizo para las directamente conectadas.
PE1# conf t Enter configuration commands, one per line. End with CNTL/Z. PE1(config)#router bgp 64512 PE1(config-router)# address-family ipv4 vrf Customer PE1(config-router-af)#redistribute ospf 2 PE1(config-router-af)#end PE1# PE2#conf t Enter configuration commands, one per line. End with CNTL/Z. PE2(config-router)#router bgp 64512 PE2(config-router)#address-family ipv4 vrf Customer PE2(config-router-af)#redistribute ospf 3 PE2(config-router-af)#end PE2#

Se revisa nuevamente la tabla de ruteo de la VRF con show ip route vrf.


PE1#sh ip route vrf Customer Routing Table: Customer Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, + - replicated route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks C 10.0.0.0/30 is directly connected, FastEthernet2/0 L 10.0.0.1/32 is directly connected, FastEthernet2/0 B 10.0.0.4/30 [200/0] via 2.2.2.2, 00:13:25 O 10.1.1.1/32 [110/2] via 10.0.0.2, 00:15:37, FastEthernet2/0 B 10.2.2.2/32 [200/2] via 2.2.2.2, 00:04:25 PE1#

Ahora se prueba conectividad eliminando la ruta default para asegurar que sea la ruta recin aprendida quin encamina los paquetes.
CE1#conf t Enter configuration commands, one per line. End with CNTL/Z. CE1(config)#no ip route 0.0.0.0 0.0.0.0 10.0.0.1 CE1(config)#end

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

Lo anterior es lgico si se hace un seguimiento secuencial de anuncio y redistribucin de las redes. Si bien el PE aprende la ruta por BGP, no se ha distribuido de vuelta en OSPF para que pueda llegar al CE.
PE1#conf t Enter configuration commands, one per line. End with CNTL/Z. PE1(config)#router ospf 2 PE1(config-router)#redistribute bgp 64512 subnets PE1(config-router)#end PE1#

Al observar la tabla de ruteo del CE.


CE1>sh ip rou Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks O E2 10.2.2.2/32 [110/2] via 10.0.0.1, 00:02:10, FastEthernet0/0 C 10.0.0.0/30 is directly connected, FastEthernet0/0 C 10.1.1.1/32 is directly connected, Loopback0 O E2 10.0.0.4/30 [110/1] via 10.0.0.1, 00:02:10, FastEthernet0/0 CE1>

Al probar nuevamente.
CE1>ping 10.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/104/124 ms CE1>

Mucha precaucin hay que tener al redistribuir entre dos protocolos de ruteo en ambos sentido de modo de evitar Loops. Para la implementacin de OSPF en VRFs, automticamente se generan dos medidas de proteccin; Down Bit y Tag Field (Loop Prevention). Zarar Ismail explica muy bien su funcionamiento, por qu exsiten dos tipos y el caso del VRF-Lite en OSPF down bit and domain tag. Area 0 discontinua?. Bsicamente la implementacin de OSPF sobre MPLS agrega un nuevo nivel jeracquico por sobre el rea 0 (backbone) denominada Superbackbone.

PE1#sh ip ospf | i VRF Connected to MPLS VPN Superbackbone, VRF Customer PE1#

Etiquetas IGP y VPN I

Posted by Nicolas | jueves, 3 de septiembre de 2009 | Category: BGP, IPv4, Layer 3 VPNs, LDP, MPLS, OSPF | A modo de continuar con lo que se vio en BGP/MPLS IP VPNs I y BGP/MPLS IP VPNs II, se ver ahora el papel que cumplen LDP y BGP en el intercambio de las etiquetas MPLS. Se utilizarn fragmentos de la maqueta a continuacin.

Como IGP se utilizar OSPF (rea 0) y todos los equipos residirn en el sistema autnomo 64512. Cada equipo tendr configurada una interface Loopback (0) con direccin IP X.X.X.X, con X el nmero de router. Adems cada equipo tendr configurada la VRF RouterX, con RD (Route Distinguisher) X:X, RT (Route Target) import X:1 y con varios RT export de la forma Y:1 (dependiendo en cada caso como se ver ms adelante). Por otra parte se configurar una interface Loopback (1) dentro de la VRF configurada con direccin IP 192.168.0.X. A continuacin la configuracin relevante de uno de los equipos para tener una idea.
hostname R3 ! ip cef ! ip vrf Router3 rd 3:3 route-target export route-target export route-target import ! mpls label protocol !

5:1 1:1 3:1 ldp

interface Loopback0 ip address 3.3.3.3 255.255.255.255 !

interface Loopback1 ip vrf forwarding Router3 ip address 192.168.0.3 255.255.255.255 ! interface Serial1/0 ip address 172.16.0.1 255.255.255.252 mpls ip ! interface Serial1/1 ip address 10.0.0.2 255.255.255.252 mpls ip ! interface Serial1/2 ip address 10.0.0.10 255.255.255.252 mpls ip ! interface Serial1/3 ip address 10.0.0.17 255.255.255.252 mpls ip ! router ospf 1 log-adjacency-changes passive-interface Loopback0 network 3.3.3.3 0.0.0.0 area 0 network 10.0.0.0 0.0.0.255 area 0 network 172.16.0.0 0.0.0.255 area 0 ! router bgp 64512 no bgp default ipv4-unicast bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 64512 neighbor 1.1.1.1 update-source Loopback0 neighbor 2.2.2.2 remote-as 64512 neighbor 2.2.2.2 update-source Loopback0 neighbor 4.4.4.4 remote-as 64512 neighbor 4.4.4.4 update-source Loopback0 neighbor 5.5.5.5 remote-as 64512 neighbor 5.5.5.5 update-source Loopback0 ! address-family vpnv4 neighbor 1.1.1.1 activate neighbor 1.1.1.1 send-community extended neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 activate neighbor 2.2.2.2 send-community extended neighbor 4.4.4.4 activate neighbor 4.4.4.4 send-community extended neighbor 4.4.4.4 route-reflector-client neighbor 5.5.5.5 activate neighbor 5.5.5.5 send-community extended exit-address-family ! address-family ipv4 vrf Router3 redistribute connected no synchronization exit-address-family ! mpls ldp router-id Loopback0 !

En un primer ejemplo se mostrar cmo es el label path entre R5 y R4 (R5-R3-R4) y cmo se modifican las interfaces para tomar otro camino (R5-R3-R1-R4).

En R5 se evalua si el prefijo ha sido recibido con show ip bgp vpnv4 vrf nombre prefijo. Se puede ver el prefijo accarrea el RT:5:1, por ende es ingresado en la VRF Router5 de ese router. De este comando se puede desprender el label VPN asignado por el PE de destino (que es quien anuncia el prefijo). Otro comando que nos puede revelar esta informacin es show ip bgp vpnv4 vrf nombre labels. Se puede ver como la etiqueta interior del paquete ser 22 en este caso.
R5#sh ip bgp vpnv4 vrf Router5 192.168.0.4 BGP routing table entry for 5:5:192.168.0.4/32, version 13 Paths: (1 available, best #1, table Router5) Not advertised to any peer Local, imported path from 4:4:192.168.0.4/32 4.4.4.4 (metric 129) from 3.3.3.3 (3.3.3.3) Origin incomplete, metric 0, localpref 100, valid, internal, best Extended Community: RT:1:1 RT:3:1 RT:5:1 RT:6:1 Originator: 4.4.4.4, Cluster list: 3.3.3.3 mpls labels in/out nolabel/22 R5# R5#sh ip bgp vpnv4 vrf Router5 labels | i Network|192.168.0.4 Network Next Hop In label/Out label 192.168.0.4/32 4.4.4.4 nolabel/22 R5#

Sin embargo esta etiqueta es slo til en el PE de destino. Para transmitir el paquete a travs de la red se necesita de otra etiqueta (IGP) que permitir realizar el label switching en cada nodo. Estas etiquetas son intercambiadas por los routers a travs de LDP y sus valores son almacenados en la LFIB (Label Forwarding Information Base), que pueden ser consultados con show mpls forwarding-table o bien con show ip cef vrf nombre prefijo detail que entrega el detalle de las etiquetas a ser asingadas para un prefijo en particular. Se ve entonces que la etiqueta IGP tiene como valor 20.
R5#sh ip cef vrf Router5 192.168.0.4 detail 192.168.0.4/32, epoch 0 recursive via 4.4.4.4 label 22 nexthop 172.16.0.1 Serial1/0 label 20 R5#

Por ende el paquete antes de salir de R5 con destino R4 luce as (Encabezado MPLS no proporcional a su tamao real, son 4 bytes con; label 20 bits, Exp 3 bit, Bottom of Stack 1 bit y TTL 8 bits):
Encabezado MPLS ----------------------------------------------------------------|Label = 20 |Exp|S = 0|TTL|Label = 22 |Exp|S = 1|TTL|Paquete IP | ----------------------------------------------------------------Paquete IP ----------------------------------------------------------------|V = 4 | IHL |Type of Service| Total Length | ----------------------------------------------------------------| Identification |Flags| Fragment Offset | ----------------------------------------------------------------| Time to Live | Protocol = 1 | Header Checksum | ----------------------------------------------------------------| SA = 192.168.0.5 |

----------------------------------------------------------------| DA = 192.168.0.4 | ----------------------------------------------------------------| Mensaje ICMP | ----------------------------------------------------------------Mensaje ICMP ----------------------------------------------------------------| Type = 8 | Code = 0 | Checksum | ----------------------------------------------------------------| Identifier | Sequence Number | ----------------------------------------------------------------| Data ... | -----------------------------------------------------------------

Antes de entrar en el detalle del path seguido, se prueba conectividad.


R5#ping vrf Router5 192.168.0.4 source Loop1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds: Packet sent with a source address of 192.168.0.5 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 56/143/340 ms R5#

Si se revisa la LFIB local se ve que la etiqueta 20 est asociada a la Loopback del PE de destino.
R5#sh mpls forwarding-table | i Local|20 Local Outgoing Prefix Bytes Label 20 Pop Label 10.0.0.16/30 0 22 20 4.4.4.4/32 0 R5# Outgoing Se1/0 Se1/0 Next Hop point2point point2point

R3 recibir el paquete con etiqueta 20 y realizar la operacin POP (PHP), es decir la remueve (etiqueta IGP) y deriva el paquete a R4 con slo la etiqueta VPN.
R3#sh mpls forwarding-table | i Local|20 Local Outgoing Prefix Bytes Label 16 Pop Label 5.5.5.5/32 1620 20 Pop Label 4.4.4.4/32 1620 R3# Outgoing Se1/0 Se1/3 Next Hop point2point point2point

Si el enlace entre R3 y R4 cae, esto provocar el correspondiende update de la RIB y por ende LFIB.
R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#int s1/3 R3(config-if)#shut R3(config-if)#^Z R3# *Sep 2 10:45:43.455: %OSPF-5-ADJCHG: Process 1, Nbr 4.4.4.4 on Serial1/3 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 2 10:45:43.671: %LDP-5-NBRCHG: LDP Neighbor 4.4.4.4:0 (3) is DOWN (Interface not operational) *Sep 2 10:45:44.403: %SYS-5-CONFIG_I: Configured from console by console R3# *Sep 2 10:45:45.383: %LINK-5-CHANGED: Interface Serial1/3, changed state to

administratively down R3# *Sep 2 10:45:45.387: %ENTITY_ALARM-6-INFO: ASSERT INFO Se1/3 Physical Port Administrative State Down R3# *Sep 2 10:45:46.383: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/3, changed state to down R3#

Nuevamente se revisa la LFIB de R3 y ahora en vez de POP realiza SWAP, cambiando la etiqueta exterior de 20 a 21, para derivar el paquete a R1.
R3#sh mpls forwarding-table | i Local|20 Local Outgoing Prefix Bytes Label 20 21 4.4.4.4/32 560 R3# Outgoing Se1/1 Next Hop point2point

R1 recibe el paquete con etiqueta 21 y realiza un POP.


R1#sh mpls forwarding-table | i Local|21 Local Outgoing Prefix Bytes Label 21 Pop Label 4.4.4.4/32 1139 R1# Outgoing Se1/1 Next Hop point2point

R4 finalmente recibe el paquete con una nica etiqueta (VPN) con valor 22 que en su LFIB se ve est asciado al prefijo de destino. Cada prefijo vpnv4 tiene asignada una etiqueta MPLS nica (comportamiento default de Cisco IOS).
R4#sh mpls forwarding-table | i Local|22 Local Outgoing Prefix Bytes Label 22 Pop Label 192.168.0.4/32[V] 2000 Outgoing Next Hop aggregate/Router4

En los siguientes post se mostrarn ms ejemplo de la misma topologa. Continuando la lnea 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 configuracin de R1, se quiere probar conectividad a R6 a travs 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 255} - ipv4 data *Sep 2 16:50:03.275: MPLS data R4# *Sep 2 16:50:05.303: MPLS 255} - ipv4 data *Sep 2 16:50:05.307: MPLS data R4#

turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 turbo: Se1/0: rx: Len 112 Stack {16 0 255} {17 0 turbo: Se1/2: tx: Len 108 Stack {17 0 254} - ipv4

Se puede ver cmo 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 16 Pop Label 6.6.6.6/32 756 17 Pop Label 192.168.0.4/32[V] 1000 R4# Outgoing Next Hop Se1/2 point2point aggregate/Router4

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 fcilmente comprobable al revisar los prefijos vpnv4 recibidos tabla BGP.
R6#sh ip bgp vpnv4 all | i Network|192.168.0 Network Next Hop *>i192.168.0.4/32 4.4.4.4 *>i192.168.0.4/32 4.4.4.4 *> 192.168.0.6/32 0.0.0.0 R6# Metric LocPrf Weight Path 0 100 0 ? 0 100 0 ? 0 32768 ?

Esto se soluciona fcilmente 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 cmo 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 data *Sep data *Sep data *Sep data R1#

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

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 slo una (17). Sin embargo ahora R4 recibe de R6 las respuestas con dos etiquetas (IGP = 22 y VPN = 21) y entrega a R1 con slo una (21)
R4# *Sep 2 17:01:59.443: MPLS turbo: 255} - ipv4 data *Sep 2 17:01:59.447: MPLS turbo: data *Sep 2 17:01:59.539: MPLS turbo: 255} - ipv4 data *Sep 2 17:01:59.543: MPLS turbo: 108 Stack {21 0 254} - ipv4 data *Sep 2 17:01:59.647: MPLS turbo: 255} - ipv4 data *Sep 2 17:01:59.651: MPLS turbo: data *Sep 2 17:01:59.671: MPLS turbo: 255} - ipv4 data *Sep 2 17:01:59.675: MPLS turbo: R4# {21 0 254} - ipv4 data Se1/0: rx: Len 112 Stack {16 0 255} {17 0 Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 Se1/2: rx: Len 112 Stack {22 0 255} {21 0 Se1/0: tx: Len Se1/0: rx: Len 112 Stack {16 0 255} {17 0 Se1/2: tx: Len 108 Stack {17 0 254} - ipv4 Se1/2: rx: Len 112 Stack {22 0 255} {21 0 Se1/0: tx: Len 108 Stack

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

Adems de revisar las LFIBs de cada uno de los routers para el path de regreso.
R 6# R6#sh mpls forwarding-table | i Local|22 Local Outgoing Prefix Bytes Label 22 21 10.0.0.0/30 0 24 22 1.1.1.1/32 0 R6# R4#sh mpls forwarding-table | i Local|22 Local Outgoing Prefix Bytes Label 22 Pop Label 1.1.1.1/32 432 R4# R1#sh mpls forwarding-table | i Local|21 Local Outgoing Prefix Bytes Label 21 Pop Label 192.168.0.1/32[V] 800 R1#

Outgoing Se1/0 Se1/0

Next Hop point2point point2point

Outgoing Se1/0

Next Hop point2point

Outgoing Next Hop aggregate/Router1

Doble NAT?

Posted by Nicolas | martes, 13 de abril de 2010 | Category: BGP, Frame Relay, IPv4, Layer 2 Technologies, LDP, MPLS, NAT, Network Security | Primero que nada agradecer a Narbik Kocharians y Dan Shechter por el excelente concurso de Troubleshooting que realizaron hace unas semanas (Troubleshooting Challenge lab)... Gracias a ste gan una copia de sus workbooks Advanced Routing and Switching 2.0 WB y Troubleshooting WB :) ...Ahora a trabajar en ellos para alcanzar la meta! Bueno, uno de los Tickets que me tuvo de cabeza por un buen rato fue el nmero 9. Enunciaba lo siguiente:
Ticket 9 R6 can NOT ping 24.24.24.3. You should fix this problem without configuring BGP or any redistribution.

La topologa completa se puede ver en; Topologa, IGP y BGP. Para la referencia de este post se utilizar la siguiente imagen:

Bsicamente R5 y R1 tienen una sesin iBGP, sin embargo no es posible alcanzar los prefijos que R1 le anuncia a R5, puesto que R4 no tiene informacin de cmo rutear estos destinos. Desde R5 se puede ver se reciben 6 prefijos desde R1 (136.85.1.1).
R5#sh ip bgp sum | b Neighbor Neighbor V AS MsgRcvd MsgSent State/PfxRcd 136.85.1.1 4 15 21600 21447 6 136.85.56.6 4 6 21452 21453 0 R5# TblVer 12 12 InQ OutQ Up/Down 0 0 0 2w0d 0 2w0d

Si en particular se revisa el prefijo 24.24.24.3/32 se ver que se conoce a travs de R1 con nexthop 136.85.241.24, el que R1 resolver recursivamente para determinar que la interface de salida es F0/0...hasta ah, todo bien.

R5#sh ip bgp 24.24.24.3 BGP routing table entry for 24.24.24.3/32, version 11 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to update-groups: 1 24 136.85.241.24 (metric 66) from 136.85.1.1 (136.85.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best R5# R5#sh ip cef 24.24.24.3 24.24.24.3/32 nexthop 136.85.45.44 FastEthernet0/0 R5#

Sin embargo cuando se intenta hacer ping al destino se obtiene un mensaje ICMP que seala que el host es desconocido (Type 3, Code 1).
R5#ping 24.24.24.3 r 2 Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds: U. Success rate is 0 percent (0/2) R5#

Para los que no saben el por qu se ve U.U.U en vez de UUUUU se recomienda leer: Dissecting a U.U.U ping response. Siguiente paso sera verifican quin origina los mensajes de destino no alcanzable.
*Apr 13 17:52:49.241: IP: s=136.85.45.5 (local), d=24.24.24.3 (FastEthernet0/0), len 100, sending *Apr 13 17:52:49.241: ICMP type=8, code=0 ---snip--*Apr 13 17:52:49.245: IP: s=136.85.45.44 (FastEthernet0/0), d=136.85.45.5, len 56, input feature *Apr 13 17:52:49.245: ICMP type=3, code=1

Como era de esperar, R4 (136.85.45.44) no sabe cmo rutear los paquetes con destino a 24.24.24.3.
R4#sh ip rou 24.24.24.3 % Network not in table R4#

Qu se puede hacer en este caso?. Bueno, la respuesta enunciada en Challenge lab - Solution, sugiere que se levante LDP entre R5<>R4 y R4<>R1, lo cual por supuesto funciona.
R5#sh ip cef 24.24.24.3 24.24.24.3/32 nexthop 136.85.45.44 FastEthernet0/0 label 16 R5# R5#ping 24.24.24.3 r 2 Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 24.24.24.24, timeout is 2 seconds:

!! Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms R5#

Sin embargo esto no pas por mi mente en ese momento, si no una solucin alternativa que sin embargo no es ptima puesto que slo corrige el problema para este prefijo en particular, pero de todos modos resuelve el inconveniente enunciado y se explicar a continuacin, de manera de mostrar cmo se puede usar NAT de manera extravagante. Para detalles respecto a esta tecnologa se sugiere revisar alguno o todos los siguientes links:

RFC 1631 How NAT Works (Cisco) Understanding NAT address types (Jeremy Stretch) NAT Order of Operation (Cisco) The Inside and Outside of NAT (Petr Lapukhov)

De vuelta al Ticket en cuestin, lo que se hizo fue utilizar NAT tanto en R4 como R1. La configuracin aplicada fue:
R4#conf t Enter configuration commands, one per line. End with CNTL/Z. R4(config)#int FastEthernet0/0 R4(config-if)#ip nat out R4(config-if)# R4(config-if)#int Serial1/0.14 R4(config-subif)#ip nat in R4(config-subif)# R4(config-subif)#ip nat inside source static 136.85.134.3 24.24.24.3 R4(config)# R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#int Serial1/0.14 R1(config-subif)#ip nat out R1(config-subif)#int f0/0 R1(config-if)#ip nat in R1(config-if)#ip nat inside source static 24.24.24.3 136.85.134.3 R1(config)#

Esto corresponde a lo que se muestra en la siguiente figura:

Entonces cuando R5 (y por ende R6 como se solicita originalmente en el Ticket) enva un paquete destinado a 24.24.24.3 llegar a la interface F0/0 de R4. Ah se aprovechar que el proceso de NAT outside to inside se realiza previo a la decisin de ruteo segn se especifica en NAT Order of Operation, entonces 24.24.24.3 se transformar en 136.85.134.3. R4 sabe cmo rutear paquetes destinados a esta direccin y por lo tanto sern enviados a travs de su interface Serial1/0.14 con destino R1 (DLCI 401).
R4#sh ip rou 136.85.134.3 Routing entry for 136.85.134.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via Serial1/0.14 Route metric is 0, traffic share count is 1 R4# R4#sh frame map interface Serial1/0.14 Serial1/0.14 (up): point-to-point dlci, dlci 401(0x191,0x6410), broadcast status defined, active R4#

Una vez en R1, se repite el proceso de NAT para hacer la conversin inversa. Esta vez se cambia 136.85.134.3 por 24.24.24.3 por ende R1 rutea los paquetes con el destino original de 24.24.24.3 y R1 s sabe cmo alcanzar ese host. Luego el host slo tiene que responder los mensajes ICMP al origen de los paquetes, cuya direccin no fue modificada durante el trayecto.
R5#ping 24.24.24.3 r 2 Type escape sequence to abort. Sending 2, 100-byte ICMP Echos to 24.24.24.3, timeout is 2 seconds: !! Success rate is 100 percent (2/2), round-trip min/avg/max = 56/58/60 ms R5