En este post se repasarán distintos métodos para filtrar prefijos en OSPFv2 de una área a otra a nivel de los ABR (Area Border Router). Se utilizarán los siguinetes comandos; area range, area filter-list y distribute-list in.


La topología a utilizar en éste y los otros posts de OSPF filter se muestra en la siguiente figura:



1. Evitar la generación de LSA 3 en ABR de origen con area range.

En particular se puede ver cómo R5 inserta en su tabla de ruteo el prefijo 5.5.5.5/32 proveniente de un LSA tipo 3 (summary) generado por R2 (2.2.2.2) para esa área en particular.

R4#sh ip rou 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 5, type inter area
Last update from 192.0.2.1 on Serial0/0, 00:17:45 ago
Routing Descriptor Blocks:
* 192.0.2.1, from 2.2.2.2, 00:17:45 ago, via Serial0/0
Route metric is 5, traffic share count is 1

R4#sh ip ospf data sum 5.5.5.5

      OSPF Router with ID (4.4.4.4) (Process ID 1)

          Summary Net Link States (Area 24)

Routing Bit Set on this LSA
LS age: 1122
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 5.5.5.5 (summary Network Number)
Advertising Router: 2.2.2.2
LS Seq Number: 80000001
Checksum: 0x8E8E
Length: 28
Network Mask: /32
  TOS: 0  Metric: 4

R4#

Si bien es R2 (2.2.2.2) quien genera el LSA tipo 3 para el área 24, cabe señalar que es R5 quien originalmente anuncia el prefijo dentro de un LSA 1 que tiene scope limitado al área local (15). Luego R1 genera un LSA-3 y finalmente R2 lo re-genera.

R5#sh ip ospf data self-originate

      OSPF Router with ID (5.5.5.5) (Process ID 1)

          Router Link States (Area 15)

Link ID         ADV Router      Age         Seq#       Checksum Link count
5.5.5.5         5.5.5.5         1177        0x8000000B 0x00B405 3

Una manera de filtrar la generación del LSA tipo 3 es por ejemplo sumarizar el prefijo en un ABR (R1 en esta caso) y especificar la opción not-advertise.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#area 15 range 5.5.5.5 255.255.255.255 not
R1(config-router)#

R4#sh ip rou 5.5.5.5
% Network not in table

2. Evitar la generación de LSA 3 con filter-list out.

En este caso se filtra a la salida del área 15.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R1(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#area 15 filter-list prefix no-lsa3 out

R4#sh ip rou 5.5.5.5
% Network not in table

3. Evitar la re-generación de LSA 3 con filter-list in.

En este caso se filtra a la entrada del área 24.

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R2(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R2(config)#router ospf 1
R2(config-router)#area 24 filter-list prefix no-lsa3 in
R2(config-router)#

R4#sh ip rou 5.5.5.5
% Network not in table

4. Filtrar ruta a partir de un LSA 3 con distribute-list in.

Mismo caso que el punto anterior, distinto comando.

R4#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R4(config)#ip prefix-li no-lsa3 deny 5.5.5.5/32
R4(config)#ip prefix-li no-lsa3 permit 0.0.0.0/0 le 32
R4(config)#router ospf 1
R4(config-router)#distribute-l pre no-lsa3 in

R4#sh ip rou 5.5.5.5
% Network not in table

Otro método puede ser a través de una ruta estática en el ABR con mejor distancia administrativa que el prefijo en cuestión. Narbik explica muy bien éste método en el siguiente video: http://www.micronicstraining.com/videos/filtering-ospf-prefixes-section-1.zip.

Link recomendado para entender esto en profundidad: OSPF Route Filtering Demystified.

En los siguientes posts se repasarán distintos métodos para filtrar prefijos en OSPFv2, cada uno con propósitos y alcances distintos. Para comenzar se verán distintos usos del comando distribute-list in para filtrar prefijos dentro de una misma área. Se combinará con prefix-list, access-list, route-map (match ip address, match ip next-hop y match ip route-source)


La topología a utilizar en este y los siguientes posts se muestra en la siguiente figura:


1. Filtrar prefijo Intra Area de la tabla de routeo. Notar que sin embargo seguirá estando en la base de datos de OSPF.

R1#sh ip rou 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "ospf 1", distance 110, metric 2, type intra area
Last update from 192.0.2.194 on Serial0/0, 1d02h ago
Routing Descriptor Blocks:
* 192.0.2.194, from 5.5.5.5, 1d02h ago, via Serial0/0
Route metric is 2, traffic share count is 1

R1#sh ip ospf data | i ^5.5.5.5
5.5.5.5         1.1.1.1         175         0x80000031 0x0038BA
5.5.5.5         5.5.5.5         1724        0x80000047 0x003C41 3
R1#

Se puede ver R1 recibe el prefijo 5.5.5.5/32 de R5 que tiene router-ID 5.5.5.5. Ahora en R1 se configura para filtrar este prefijo, lo que resulta exitoso, sin embargo esto no tendrá efecto sobre la base de datos de OSPF por lo que R1 propagará la ruta al área 0.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#ip prefix-li no-prefix deny 5.5.5.5/32
R1(config)#ip prefix-li no-prefix permit 0.0.0.0/0 le 32
R1(config)#router ospf 1
R1(config-router)#distribute-list prefix no-prefix in
R1(config-router)#

R1#sh ip rou 5.5.5.5
% Network not in table

R1#sh ip ospf data | i ^5.5.5.
5.5.5.5         1.1.1.1         657         0x80000031 0x0038BA
5.5.5.5         5.5.5.5         201         0x80000048 0x003A42 3
R1#

2. Mismo caso pero con access-list en vez de prefix-list.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 1 deny 5.5.5.5 255.255.255.255
R1(config)#access-list 1 permit any
R1(config)#router ospf 1
R1(config-router)#distribute-list 1 in

R1#sh ip rou 5.5.5.5
% Network not in table

3. Mismo caso, pero especificando el prefijo y next-hop.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 1 permit 5.5.5.5
R1(config)#access-list 2 permit 192.0.2.194
R1(config)#
R1(config)#route-map prefix-nexthop deny
R1(config-route-map)# match ip address 1
R1(config-route-map)# match ip next-hop 2
R1(config-route-map)#route-map prefix-nexthop permit
R1(config-route-map)#
R1(config-route-map)#router ospf 1
R1(config-router)#distribute-list route-map prefix-nexthop in
R1(config-router)#^Z
R1#

R1#sh ip rou 5.5.5.5
% Network not in table

4. En vez del next-hop se especifica la fuente del prefijo.

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config-router)#route-map prefix-nexthop deny
R1(config-route-map)#match ip address 1
R1(config-route-map)#match ip route-source 1
R1(config-route-map)#route-map prefix-nexthop permit
R1(config-route-map)#
R1(config-route-map)#router ospf 1
R1(config-router)#distribute-list route-map prefix-nexthop in
R1(config-router)#^Z

Un par de consideraciones:

• Si se incluye la interface en el comando distribute-list in, se considera ésta como interface de sailda para el next-hop y sólo la ruta en ese sentido será considerada.
• Altamente recomendado evitar este tipo de filtrado (Inter Area) ya que puede llevar a blackholing.
  

Se configurará IS-IS a dos routers interconectados como muestra la figura.

R5(config)#int f0/0
R5(config-if)#ip add 192.0.2.5 255.255.255.0
R5(config-if)#no shut
R5(config-if)#
R5(config-if)#router isis
R5(config-router)#net 49.0001.0050.0500.5005.00
R5(config-router)#int f0/0
R5(config-if)#ip router isis
R5(config-if)#

R6(config)#int f0/0
R6(config-if)#ip add 192.0.2.6 255.255.255.0
R6(config-if)#no shut
R6(config-if)#
R6(config-if)#router isis
R6(config-router)#net 49.0001.0060.0600.6006.00
R6(config-router)#int f0/0
R6(config-if)#ip router isis
R6(config-if)#

Luego si en R5 se revisan los adjacencias con show isis neighbors, se verá que en lugar de mostrar la representación de 6 bytes del System ID del router vecino, se muestra en vez -para nuestra comodidad- el hostname.

R5#sh isis nei

System Id      Type Interface   IP Address      State Holdtime Circuit Id
R6             L1   Fa0/0       192.0.2.6       UP    7        R6.01
R6             L2   Fa0/0       192.0.2.6       UP    7        R6.01
R5#

Esto es gracias a que el RFC 2763 definió un nuevo TLV (Dynamic Hostname, type 137) que permite a los routers corriendo IS-IS conocer el hostname asociado a un system ID (Dynamic Hostname Exchange) que luego el RFC 5301 hizo parte del estándar del protocolo.

A continuación se repetirá este procedimiento para OSPF.

R5(config)#int f0/0
R5(config-if)#ip add 192.0.2.5 255.255.255.0
R5(config-if)#no shut
R5(config-if)#
R5(config-if)#router ospf 1
R5(config-router)#int f0/0
R5(config-if)#ip ospf 1 area 0
R5(config-if)#

R6(config)#int f0/0
R6(config-if)#ip add 192.0.2.6 255.255.255.0
R6(config-if)#no shut
R6(config-if)#
R6(config-if)#router ospf 1
R6(config-router)#int f0/0
R6(config-if)#ip ospf 1 area 0
R6(config-if)#

Sin embargo el resultado no es el mismo al ejecuar show ip ospf neighbor, se ve simplemente el router ID, que para este protocolo es de 4 bytes.

R5#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
192.0.2.6         1   FULL/BDR        00:00:37    192.0.2.6       FastEthernet0/0
R5#

Una manera de visualizar el hostname es configurando OSPF para que resuelva a través de DNS. Bueno, además se tendrá que configurar uno de los routers (R6) para que sea el DNS server en el ejemplo con ip dns server, además de configurar los mapeos name/IP con ip host. Por otro lado se le indicará a R5 con ip name-server que debe hacer las consultas de DNS a R6.

R6(config)#ip host R5 192.0.2.5
R6(config)#ip host R6 192.0.2.6
R6(config)#ip dns server

R5(config)#ip name-server 192.0.2.6

Por último se configura OSPF para que resuelva con ip ospf name-lookup. Los routers que no tengan configurado el mapeo de host/IP además necesitarán además configurado ip domain lookup.

R5(config)#ip ospf name-lookup

R5#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
R6                1   FULL/BDR        00:00:31    192.0.2.6       FastEthernet0/0
R5#

Por último añadir que dado que para OSPFv3, en implementaciones nativas de IPv6, el ID de 4 bytes asociado a cada router no será mapeado a direcciones IPv4 en esas redes, por lo que pierde sentido resolver por DNS. Es por eso que el RFC 5642 define un nuevo TLV (Dynamic Hostname) para utilizar en un Opaque LSA (Router Information, type 4), basado en lo definido previamente para IS-IS. Sin embargo aún no está implementado (hasta donde tengo entendido) en Cisco IOS.

Después de leer dos excelentes posts respecto de los timers de RIP, específicamente; How basic are RIP timers? y RIP Timers, uno podrá notar que que si bien aparenta ser un tema sencillo, realmente puede ser muy confuso.

Los timers definidos para RIPv2 RFC 2453 son claros. Además del intervalo de update, están timeout (invalid en routers Cisco) y garbage-collection (flush en routers Cisco), que definen el tiempo que debe transcurrir sin escuchar updates para una detrminada ruta antes de declararla como inválida y el tiempo que debe transcurrir para definitivamente remover la ruta de la tabla de ruteo resectivamente. Sin embargo la implementación de Cisco incluye otros dos timers; holddown y sleep. En particular se pueden encontrar múltiples referencia a holdown, la cuales en muchos casos son contradictoria. Es por eso a continuación se verá seis ejemplo para sacar conclusiones. Se utilizará el diagrama que se muestra a continuación y los output de debugs corresponderán a R3, que está corriendo IOS versión 12.4(23).
Por defecto los timers en router Cisco son; update 30 segundos, invalid 180, hold down 180 y flush 240. Para el escenario en que se trabajará los timers serán seteados a 20, 60, 60 y 180 respectivamente con el comando timers basic. Si se quiere modificar el perídodo de update para una interface en particular se puede utilizar el comando ip rip advertise, como se especifica en la descripción del bug CSCdy77097.

router rip
version 2
 timers basic 20 60 60 180
network 192.0.2.0
network 198.51.100.0
network 203.0.113.0
no auto-summary

Por ende los timer se comportarán como se muestra proporcionalmete en la siguiente figura.


Para los debugs se utilizarán los comandos debug ip routing y debug ip routing. Adicionalmete se revisará la tabla de ruteo y la base de datos de RIP con show ip rip database. Por útimo en R4 se manipularán los anuncios con offset-list y distribute-list out. Para estos propositos se agregan además dos listas de acceso.

R4(config)#access-list 1 deny 192.0.2.44
R4(config)#access-list 1 permit any
R4(config)#access-list 2 permit 192.0.2.44

1) Se recibe update de una ruta con mayor métrica a la actual previo a que Invalid expire.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se observa en R3 se recibe una actualización períodica a las 21:06:09.

May  1 21:06:09.864: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:09.864:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:06:12.145 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:02, FastEthernet0/0

Posteriormente se envía desde R4 la ruta con mayor mayor métrica. Se puede observar en el siguiente update períodico se recibe la ruta con la nueva métrica.

May  1 21:06:29.554: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:29.558:      192.0.2.44/32 via 0.0.0.0 in 11 hops
May  1 21:06:29.558: RT: rip's 192.0.2.44/32 (via 198.51.100.144) metric changed from distance/metric [120/1] to
[120/11]

La ruta aparece inmediatamente después con la nueva métrica en la tabla de ruteo.

R3#sh clock
21:06:30.570 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/11] via 198.51.100.144, 00:00:01, FastEthernet0/0

Se gatilla entonces un triggered update a sus vecinos (menos a través de F0/0 debido a la regla de split horizon).

May  1 21:06:31.558: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (198.51.100.133)
May  1 21:06:31.558: RIP: build flash update entries - suppressing null update

May  1 21:06:31.558: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (203.0.113.133)
May  1 21:06:31.558: RIP: build flash update entries
May  1 21:06:31.558:    192.0.2.44/32 via 0.0.0.0, metric 12, tag 0

Posteriormente se aumenta la métrica nuevamente desde R4.

R4(config-router)#offset-list 2 out 10 f0/0

En el siguiente update períodico se recibe la ruta con la nueva métrica.

May  1 21:06:49.016: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:06:49.016:      192.0.2.44/32 via 0.0.0.0 in 13 hops
May  1 21:06:49.016: RT: rip's 192.0.2.44/32 (via 198.51.100.144) metric changed from distance/metric [120/11] to
[120/13]

Como se puede apreciar la ruta es insertada inmediatamente en la tabla de ruteo, por ende la ruta NO entró nunca en holddown.

R3#sh clock
21:06:50.048 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/13] via 198.51.100.144, 00:00:01, FastEthernet0/0

2) Se recibe update de una ruta con métrica 16 previo a que Invalid expire.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se recibe una actualización períodica a las 21:24:36.

May  1 21:24:36.275: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:24:36.275:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:24:39.563 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:03, FastEthernet0/0

Posteriormente se envía desde R4 la ruta con métrica 16.

R4(config-router)#offset-list 2 out 16 f0/0

En el siguiente update períodico se recibe la ruta con la nueva métrica (16 = inaccessible)

May  1 21:24:53.568: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:24:53.568:      192.0.2.44/32 via 0.0.0.0 in 16 hops  (inaccessible)
May  1 21:24:53.568: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 21:24:53.568: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
21:24:54.516 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

La ruta entra automáticamente en holddown.


3) Se recibe update de una ruta con mayor métrica durante el periodo de holddown proveniente del mismo vecino que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Posteriormente se deja de anuncia por completo la ruta.

R4(config-router)#distribute-list 1 out f0/0

Como se verá a continuación a las 20:20:27 se recibe el último update de 192.0.2.44/32 a través de F0/0.

May  1 20:20:27.159: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:20:27.159:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Aproximadamente 60 segundos después, una vez concluido el Invalid timer la ruta entra en holddown puesto que no se ha recibido nueva información de ésta.

May  1 20:21:34.821: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 20:21:34.821: RT: no routes to 192.0.2.44, entering holddown

R3 envía triggered updates con métrica 16 a sus vecinos.

May  1 20:21:36.821: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/0 (198.51.100.133)
May  1 20:21:36.821: RIP: build flash update entries
May  1 20:21:36.821:    192.0.2.44/32 via 0.0.0.0, metric 16, tag 0

May  1 20:21:36.821: RIP: sending v2 flash update to 224.0.0.9 via FastEthernet0/1 (203.0.113.133)
May  1 20:21:36.821: RIP: build flash update entries
May  1 20:21:36.821:    192.0.2.44/32 via 0.0.0.0, metric 16, tag 0

R3 recibe de la ruta de vuelta desde R6 con métrica 16 (poison reverse).

May  1 20:21:38.825: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 20:21:38.825:      192.0.2.44/32 via 0.0.0.0 in 16 hops  (inaccessible)

A todo esto el timer de holdown a comenzado a contar. A las 20:21:44 ya han pasado 10 segundos desde que la ruta entró en holdown, restarían otros 50 segundos.

R3#sh clock
20:21:44.766 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:17 ago
Hold down timer expires in 50 secs

La ruta aparece como possibly down tamto en la tabla de ruteo como la base de datos de RIP.

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Desde R4 se configura para volver a anunciar la ruta pero con mayor métrica.

R4(config-router)#offset-list 2 out 10 f0/0
R4(config-router)#no distribute-list 1 out f0/0

A las 20:21:45, R3 recibe un anuncio desde el mismo vecino con mayor métrica (11).

May  1 20:21:45.738: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:21:45.742:      192.0.2.44/32 via 0.0.0.0 in 11 hops

Sin embargo la ruta es ignorada.

R3#sh clock
20:21:47.518 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:20 ago
Hold down timer expires in 47 secs

46 segundos después, o sea 106 segundos desde que esto comenzó ya se está a punto de conlcluir el periodo de holddown.

R3#sh clock
20:22:33.570 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:02:06 ago
Hold down timer expires in 1 secs

Una vez fuera de holddown se instalará la nueva ruta con métrica 11, tan pronto el update periodico con esta información se reciba, esto pasa a las 20:22:42.

May  1 20:22:42.482: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 20:22:42.482:      192.0.2.44/32 via 0.0.0.0 in 11 hops
May  1 20:22:42.486: RT: add 192.0.2.44/32 via 198.51.100.144, rip metric [120/11]

Así se puede comprobar en la tabla de ruteo.

R3#sh clock
20:22:45.282 UTC Sat May 1 2010

R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/11] via 198.51.100.144, 00:00:02, FastEthernet0/0

4) Se recibe update de una ruta con mayor métrica durante el periodo de holddown proveniente de un vecino distinto al que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0

Se recibe update periodico.

May  1 22:05:40.276: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 22:05:40.276:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Posteriormente se deja de anuncia por completo la ruta.

R4(config)#router rip
R4(config-router)#distribute-list 1 out f0/0

Aproximadamente 60 segundos después, una vez concluido el Invalid timer la ruta entra en holddown puesto que no se ha recibido nueva información de ésta.

May  1 22:06:45.513: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/1]
May  1 22:06:45.513: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
22:06:48.221 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:07 ago
Hold down timer expires in 57 secs

R3#
R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Una vez que la ruta entra en holddown, R4 anuncia la ruta a través de s0/0/0 de modo que R3 la reciba por F0/1 con una mayor métrica.

R4(config-router)#no distribute-list 1 out serial0/0/0

R4 debe propagar esta info a R5, éste útimo a su vez a R6 para que así finalmente le llegue la nueva ruta a R3. Ésto sucede por primera vez a las 22:07:10.

May  1 22:07:10.815: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:10.819:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Sin embargo R3 ignora esta info como se ve del output de la tabla de ruteo.

R3#sh clock
22:07:11.499 UTC Sat May 1 2010
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:31 ago
Hold down timer expires in 33 secs

Se recibe otro update de la ruta durante el periodo de holddown, que es también ignorado.

May  1 22:07:28.940: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:28.940:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Luego de transcurrido el tiempo de holddown los updates podrán gatillar una actualización de la tabla de ruteo.

May  1 22:07:47.334: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  1 22:07:47.338:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  1 22:07:47.338: RT: 192.0.2.44 came out of holddown
May  1 22:07:47.338: RT: add 192.0.2.44/32 via 203.0.113.166, rip metric [120/3]

5) Se recibe update de una ruta con menor métrica durante el periodo de holddown proveniente del mismo vecino que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4 y se aumenta su métrica hacia R3:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0
R4(config-router)#offset-list 2 out 5 f0/0

Se recibe update períodico.

May  1 21:43:30.583: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:43:30.583:      192.0.2.44/32 via 0.0.0.0 in 6 hops

Se revisa la tabla de ruteo.

R3#sh clock
21:43:34.600 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/6] via 198.51.100.144, 00:00:04, FastEthernet0/0

Se suprime el anuncio para entrar en holddown después de 60 segundos aprox.

R4(config-router)#distribute-list 1 out f0/0

R3 anuncia la ruta ha entrado en holddown.

May  1 21:44:35.405: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/6]
May  1 21:44:35.405: RT: no routes to 192.0.2.44, entering holddown

Se revisa la base de datos de RIP.

R3#sh clock
21:44:38.625 UTC Sat May 1 2010
R3#
R3#sh ip rip database 192.0.2.44 255.255.255.255
192.0.2.44/32 is possibly down

Luego se reestablece el anuncio con una mejor métrica.

R4(config-router)#no offset-list 2 out 5 f0/0
R4(config-router)#no distribute-list 1 out f0/0

A las 21:45:00 se escucha por primera vez nuevamente la ruta.

May  1 21:45:00.511: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:00.511:      192.0.2.44/32 via 0.0.0.0 in 1 hops

Sin embargo la ruta es ignorada como se aprecia en la tabla de ruteo donde sigue como possibly down.

R3#sh clock
21:45:03.699 UTC Sat May 1 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:33 ago
Hold down timer expires in 31 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Una vez concluido el holddown timer la ruta podrá ser insertada en la tabla de ruteo una vez se reciba.

May  1 21:45:19.872: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:19.872:      192.0.2.44/32 via 0.0.0.0 in 1 hops

May  1 21:45:37.366: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  1 21:45:37.366:      192.0.2.44/32 via 0.0.0.0 in 1 hops
May  1 21:45:37.366: RT: 192.0.2.44 came out of holddown
May  1 21:45:37.370: RT: add 192.0.2.44/32 via 198.51.100.144, rip metric [120/1]

R3#sh clock
21:45:37.698 UTC Sat May 1 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/1] via 198.51.100.144, 00:00:00, FastEthernet0/0

6) Se recibe update de una ruta con menor métrica durante el periodo de holddown proveniente de un vecino distinto al que anunciaba la ruta originalmente.

Como paso preliminar se filtra el anuncio de la ruta de interés (192.0.2.44/32) por una de las interfaces de R4 y se aumenta su métrica hacia R3:

R4(config)#router rip
R4(config-router)#distribute-list 1 out s0/0/0
R4(config-router)#offset-list 2 out 10 f0/0

Se recibe update periodico.

May  2 20:57:57.220: RIP: received v2 update from 198.51.100.144 on FastEthernet0/0
May  2 20:57:57.220:      192.0.2.44/32 via 0.0.0.0 in 11 hops

Se suprime el anuncio.

R4(config)#router rip
R4(config-router)#distribute-list 1 out f0/0

Aproximadamente 60 segundos después la ruta entra en holddown.

May  2 20:59:02.601: RT: delete route to 192.0.2.44 via 198.51.100.144, rip metric [120/11]
May  2 20:59:02.601: RT: no routes to 192.0.2.44, entering holddown

R3#sh clock
20:59:04.221 UTC Sun May 2 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:07 ago
Hold down timer expires in 58 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Una vez que la ruta entra en holddown, R4 anuncia la ruta a través de s0/0/0 de modo que R3 la reciba por F0/1 con una menor métrica.

R4(config-router)#no distribute-list 1 out serial0/0/0

A las 20:59:14 se recibe por primera vez.

May  2 20:59:14.342: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:14.342:      192.0.2.44/32 via 0.0.0.0 in 3 hops

Pero una vez más se puede observar que durante el holddown no se acepta ninguna info. respecto la ruta indiferente cuál sea su métrica.

R3#sh clock
20:59:15.614 UTC Sun May 2 2010
R3#
R3#sh ip route 192.0.2.44
Routing entry for 192.0.2.44/32
Known via "rip", distance 120, metric 4294967295 (inaccessible)
Redistributing via rip
Last update from 198.51.100.144 on FastEthernet0/0, 00:01:18 ago
Hold down timer expires in 46 secs

R3#sh ip route | i 192.0.2.44
R       192.0.2.44/32 is possibly down,

Sólo cuando haya concluido el holddown se podrá actualizar la ruta

May  2 20:59:29.023: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:29.023:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  2 20:59:48.497: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 20:59:48.497:      192.0.2.44/32 via 0.0.0.0 in 3 hops

May  2 21:00:07.631: RIP: received v2 update from 203.0.113.166 on FastEthernet0/1
May  2 21:00:07.631:      192.0.2.44/32 via 0.0.0.0 in 3 hops
May  2 21:00:07.631: RT: 192.0.2.44 came out of holddown
May  2 21:00:07.631: RT: add 192.0.2.44/32 via 203.0.113.166, rip metric [120/3]

R3#sh clock
21:00:09.135 UTC Sun May 2 2010
R3#
R3#sh ip route | i 192.0.2.44
R       192.0.2.44 [120/3] via 203.0.113.166, 00:00:01, FastEthernet0/1

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)

De vuelta al Ticket en cuestión, lo que se hizo fue utilizar NAT tanto en R4 como R1. La configuración 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) 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

:)