lunes, 3 de mayo de 2010
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
Saludos Nicolas
Mi nombre es Andres, estoy preparando el examen de certificacion CCNA y la verdad estaba confundido y no sabia como funcionaba el temporizador holddown, su explicacion de los direntes casos fue muy buena, pero tengo una duda, en el caso 2 el update timer manda informacion acerca de la ruta inalcanzable (metrica 16), un update dispado tambien puede enviar esta informacion?
Hola Andrés, debes considerar que el funcionamiento de los timers de RIP puede variar para las distintas versiones de IOS. Para efectos del examen CCNA te recomiendo te apegues lo más que puedas a lo que dicta la teoría.
Respecto a tu pregunta, si entiendo bien quieres saber si un triggered update puede informar acerca de la inalcanzabildad de una ruta?, en vez del update regular como se vió en el ejemplo 2. Bueno, eso es exactamente así, de hecho el router generará estos triggered updates con métrica 16 cada vez deje de recibir un prefijo (luego de transcurrido el holddown timer) o bien se afecte una ruta directamente conectada por ejemplo.
existe un pequeño detalle de la explicacion, el temporizador de purga o flush se comienza a contar desde q la ruta se declaro como invalida, y al parecer en la figura proporcional se comienza a contar desde q no se recibio una actualizacion
La verdad ya no recuerdo el detalle, pero alguien dijo por ahí muy sabiamente; "RIP is not something you use in your network. It is something you put on your gravestone"
simplemente genial