martes, 13 de abril de 2010
Doble NAT?
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 número 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 topología completa se puede ver en; Topología, IGP y BGP. Para la referencia de este post se utilizará la siguiente imagen:
Básicamente R5 y R1 tienen una sesión iBGP, sin embargo no es posible alcanzar los prefijos que R1 le anuncia a R5, puesto que R4 no tiene información de cómo 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 TblVer InQ OutQ Up/Down State/PfxRcd
136.85.1.1 4 15 21600 21447 12 0 0 2w0d 6
136.85.56.6 4 6 21452 21453 12 0 0 2w0d 0
R5#
Si en particular se revisa el prefijo 24.24.24.3/32 se verá que se conoce a través de R1 con next-hop 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 señala 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 sería verifican quién 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 cómo 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 solución alternativa que sin embargo no es óptima puesto que sólo corrige el problema para este prefijo en particular, pero de todos modos resuelve el inconveniente enunciado y se explicará a continuación, de manera de mostrar cómo se puede usar NAT de manera extravagante. Para detalles respecto a esta tecnología 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)
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) envía 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 decisión de ruteo según se especifica en NAT Order of Operation, entonces 24.24.24.3 se transformará en 136.85.134.3. R4 sabe cómo rutear paquetes destinados a esta dirección y por lo tanto serán enviados a través 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 conversión 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 cómo alcanzar ese host. Luego el host sólo tiene que responder los mensajes ICMP al origen de los paquetes, cuya dirección 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
:)
lunes, 7 de septiembre de 2009
Etiquetas IGP y VPN II
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
!
jueves, 3 de septiembre de 2009
Etiquetas IGP y VPN I
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 utilizarán fragmentos de la maqueta a continuación.
Como IGP se utilizará OSPF (área 0) y todos los equipos residirán en el sistema autónomo 64512. Cada equipo tendrá configurada una interface Loopback (0) con dirección IP X.X.X.X, con X el número de router.
Además 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á más adelante). Por otra parte se configurará una interface Loopback (1) dentro de la VRF configurada con dirección IP 192.168.0.X.
viernes, 12 de junio de 2009
Una vez que ya se ha comprendido que los DSCP definen el PHB de los paquetes a través de una red IP, corresponde examinar el símil en redes MPLS. El RFC 3270 (MPLS Support of Differentiated Services) explica cómo se lleva a cabo ésto. Básicamente se basa en el campo EXP del header MPLS. Una buena referencia de Cisco es el documento DiffServ Tunneling Modes for MPLS Networks.
El RFC 3032 (MPLS Label Stack Encoding) define el header MPLS como sigue.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | Exp |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits
Exp: Experimental Use, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Sin embargo, recientemente, el RFC 5462 (MPLS Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field) le da un nombre más acorde a su uso al campo EXP, denominándolo TC.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label
| Label | TC |S| TTL | Stack
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Entry
Label: Label Value, 20 bits
TC: Traffic Class field, 3 bits
S: Bottom of Stack, 1 bit
TTL: Time to Live, 8 bits
Por lo que si bien en este post se hablará con respecto al campo EXP, en el futuro se debería hacer referencia al campo TC.
viernes, 5 de junio de 2009
BGP/MPLS IP VPNs II
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
martes, 2 de junio de 2009
BGP/MPLS IP VPNs I
Dentro de los nuevos tópicos a incluir en la versión 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 continuación se describirá el algunos conceptos básicos para el set-up de VPNs utilizando esta tecnología. Se utilizará la topología de la figura.Primero que nada se setea el IGP de nuestra red, tomando en consideración que debemos insertar en la tabla de ruteo una dirección 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 dirección de Loopback 0 seteada en cada equipo. A continuación la configuración relevante en uno de los PEs para lo señalado.
