Olá pessoal,
Em nosso Curso CCNA Online, bem como no Curso CCNA Presencial, sempre recebemos perguntas de alunos sobre como funciona o timers nos protocolos de vetor de distância, como o RIP. Então em nosso artigo de hoje veremos um pouco sobre esse tema.
Então vamos lá…dentro da configuração do RIP podemos alterar os temporizadores do protocolo com o comando “timers basic“, veja a sintaxe abaixo:
conf t router rip timers basic 5 15 100 180timers basica [update] [invalid] [holddown] [flush]
Podemos editar os seguintes temporizadores. Resumidamente segue a explicação de cada um.
update
Taxa com que os updates das rotas são enviados. O padrão é 30 segundos.
invalid
Intervalo de tempo em segundos após o qual uma rota será considerada inválida. Se durante o período [invalid] o roteador não receber nenhuma atualização a rota será considerada inválida. Então a rota é marcada como inacessível e anunciada para os vizinhos como inalcançável (unreachable). O valor padrão do invalid são 180 segundos.
holddown
Intervalo de tempo em segundos no qual informações sobre um melhor caminho não são consideradas. Uma rota entrará em holddown quando for recebido um update dizendo que a rota está inalcançável (unreachable). A rota é marcada como inacessível e anunciada como inalcançável (unreachable). Quando o holddown acabar, as rotas recebidas por outras fontes serão consideradas e a rota deixa de ser inalcançável (unreachable).
flush
Quantidade de tempo em segundos que deve se passar para que uma rota seja removida da tabela de roteamento. Esse intervalo é medido a partir do recebimento do último update sobre essa rota. O valor padrão do flush são 240 segundos.
Pois bem, essa é a teoria…agora nesse ponto é que muitos falam – “poxa vida, embaralhou tudo na minha cabeça….”. Então vamos ver alguns exemplos e tentar verificar o comportamento do roteador durante esses períodos de tempo. Para tal utilizaremos a topologia mostrada na figura abaixo.
Verificando o Flush Timer
Estamos com a topologia conforme mostrada. Vamos focar em R1. Atualmente estamos recebendo a rota para a rede 10.0.0.0 via serial 0/2. Observe a tabela de rotas abaixo. Vamos também habilitar os debug mostrados para podermos visualizar as mensagens trocadas.
R1#
sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 [120/2] via 192.168.40.2, 00:00:04, Serial0/2
R 192.168.50.0/24 [120/1] via 192.168.40.2, 00:00:04, Serial0/2
R1#
R1#
R1#debug ip routing
IP routing debugging is on
R1#debug ip rip
RIP protocol debugging is on
R1#
R1#
*Mar 1 03:57:30.739: RIP: received v1 update from 192.168.40.2 on Serial0/2
*Mar 1 03:57:30.739: 10.0.0.0 in 2 hops
*Mar 1 03:57:30.743: 192.168.50.0 in 1 hops
R1#
Reparem acima que recebemos um update de R4 anunciando a rota 10.0.0.0 as 03:57:30. Nesse momento vamos fazer R4 parar de anunciar essa rota. Em R4 colocamos a interface s0/0 como passiva no RIP.
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#router rip
R4(config-roteador)#passive-interface s0/0
R4(config-roteador)#
R4#
Voltamos para R1 e vamos verificar o andamento das mensagens e a tabela de rotas. Reparem que na tabela de rotas mostra que a última atualização dessa rota veio a 00:01:17, o que está compatível com os tempos mostrados no debug.
*Mar 1 03:58:41.603: RIP: build update entries
*Mar 1 03:58:41.603: network 192.168.20.0 metric 1
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 [120/2] via 192.168.40.2, 00:01:17, Serial0/2
R 192.168.50.0/24 [120/1] via 192.168.40.2, 00:01:17, Serial0/2
R1#
*Mar 1 03:58:55.159: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.20.1)
*Mar 1 03:58:55.159: RIP: build update entries
Lembrem-se que configuramos os timers do RIP como “timers basic 15 90 90 120“, logo o invalid está em 90s, então 90s após o último update a rota deverá ser classificada como unreachable e entrar em holddown. Se tudo correr bem isso deverá ocorrer por volta de 03:59:00. Vamos continuar observando as mensagens do debug.
R1#
*Mar 1 03:59:09.359: RT: delete route to 10.0.0.0 via 192.168.40.2, rip metric [120/2]
*Mar 1 03:59:09.359: RT: no routes to 10.0.0.0, entering holddown
*Mar 1 03:59:09.363: RT: delete route to 192.168.50.0 via 192.168.40.2, rip metric [120/1]
*Mar 1 03:59:09.367: RT: no routes to 192.168.50.0, entering holddown
*Mar 1 03:59:09.367: RIP: sending v1 update to 255.255.255.255 via Serial0/0 (192.168.20.1)
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 is possibly down, routing via 192.168.40.2, Serial0/2
R 192.168.50.0/24 is possibly down, routing via 192.168.40.2, Serial0/2
R1#
Vejam que no tempo 03:59:09 a rota 10.0.0.0 entrou em holddown…até agora tudo perfeito. Agora queremos observar o comportamento do flush e ver quando a rota sairá da tabela de roteamento. De acordo com nossa configuração deverá ser 120s após o último update (timers basic 15 90 90 120). Como o último update veio 57:30 o flush deverá ocorrer nos 59:30. Para não perder o costume, vamos continuar observando o debug…
R1#
*Mar 1 03:59:37.343: RT: delete network route to 10.0.0.0
*Mar 1 03:59:37.343: RT: NET-RED 10.0.0.0/8
*Mar 1 03:59:37.347: RT: NET-RED queued, Queue size 1
*Mar 1 03:59:37.347: RT: delete network route to 192.168.50.0
*Mar 1 03:59:37.351: RT: NET-RED 192.168.50.0/24
*Mar 1 03:59:37.351: RT: NET-RED queued, Queue size 2
R1#
Perfeito!!! Dentro do previsto a rota foi deletada. Perceba que agora essa rota não está mais na tabela de rotas.
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R1#un all
All possible debugging has been turned off
R1#
Detalhe: observe que o timer holddown foi configurado para 90s (timers basic 15 90 90 120), mas como o flush foi configurado para 120, a rota ficará em holddown por apensa 30 segundos. Isso porque o holddown começou a contar 90s após o último update (invalid) e o flush será 120s após o último update, logo ficará em holddown apenas 30s.
Verificando o Comportamento do Holddown Timer
Nesse exemplo vamos tentar ilustrar o comportamento do roteador quando a rota está em holddown. De acordo com a teoria depois do tempo de invalid a rota vai entrar em holddown (vimos isso funcionar no exemplo anterior). Também é dito que quando em holddown o roteador não vai considerar anúncios com métrica melhor para essa rota, até que o holddown (ou flush) expire.
No exemplo anterior fizemos o flush expirar em 120s, ou seja, 30s após entrar em holddown. Quando o flush expira, a rota é deletada da tabela de rotas e após isso, se chegar um novo anúncio de rota, esse novo anúncio será considerado e a rota colocada na tabela de roteamento.
Agora nesse exemplo, vamos aumentar o tempo de flush para deixar o holddown rodar até os 90s programado e ver o que acontece com a rota em holddown. Começaremos novamente do início, com o R1 tendo rota para 10.0.0.0 via R4. Vamos primeiro alterar os timers do RIP em todos os roteadores, abaixo o exemplo do R1.
R1(config)#router rip
R1(config-roteador)#timers basic 15 90 90 240
R1(config-roteador)#exit
R1(config)#exit
R1#
Vamos novamente habilitar os debugs e verificar nossa tabela de rotas.
R1#debug ip routing
IP routing debugging is on
R1#debug ip rip
RIP protocol debugging is on
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 [120/2] via 192.168.40.2, 00:00:08, Serial0/2
R 192.168.50.0/24 [120/1] via 192.168.40.2, 00:00:08, Serial0/2
R1#
Como antes, vamos colocar a rota em holddown. Em R4 fazemos o passive-interface e verificamos as mensagens do debug em R1.
R4#
R4(config)#router rip
R4(config-roteador)#passive-interface s0/0
R4#R1#
*Mar 1 00:18:15.315: RIP: received v1 update from 192.168.40.2 on Serial0/2
*Mar 1 00:18:15.319: 10.0.0.0 in 2 hops
*Mar 1 00:18:15.319: 192.168.50.0 in 1 hops
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 [120/2] via 192.168.40.2, 00:00:31, Serial0/2
R 192.168.50.0/24 [120/1] via 192.168.40.2, 00:00:31, Serial0/2
R1#
O último update vindo de R4 foi em 18:15, 90s após deverá entrar em holddown.
*Mar 1 00:19:35.151: RIP: build update entries
*Mar 1 00:19:35.151: network 192.168.20.0 metric 1
R1#
*Mar 1 00:19:49.911: RT: delete route to 10.0.0.0 via 192.168.40.2, rip metric [120/2]
*Mar 1 00:19:49.911: RT: no routes to 10.0.0.0, entering holddown
*Mar 1 00:19:49.915: RT: delete route to 192.168.50.0 via 192.168.40.2, rip metric [120/1]
*Mar 1 00:19:49.919: RT: no routes to 192.168.50.0, entering holddown
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 is possibly down, routing via 192.168.40.2, Serial0/2
R 192.168.50.0/24 is possibly down, routing via 192.168.40.2, Serial0/2
R1#
Até agora tudo normal, vamos então fazer R2 passar a anunciar uma rota para 10.0.0.0 com métrica melhor e verificar o que ocorre em R1.
R2#
R2(config)#router rip
R2(config-roteador)#no passive-interface s0/0
R2#R1#
*Mar 1 00:20:12.287: RIP: received v1 update from 192.168.20.2 on Serial0/0
*Mar 1 00:20:12.291: 10.0.0.0 in 1 hops
*Mar 1 00:20:12.291: 192.168.50.0 in 16 hops (inaccessible)
*Mar 1 00:20:44.103: network 192.168.50.0 metric 16
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 is possibly down, routing via 192.168.40.2, Serial0/2
R 192.168.50.0/24 is possibly down, routing via 192.168.40.2, Serial0/2
R1#
R1#
Perceba acima que em 20:12 R1 começou a receber updates de R2 anunciando a rede 10.0.0.0. Mas como essa rota em R1 está em holddown ele deverá esperar o tempo de holddown e só após isso considerar a rota vinda de R2. O holddown foi configurado para 90s, logo aproximadamente em 21:20 o timer expira. Vamos ver…
R1#
*Mar 1 00:21:23.023: RIP: received v1 update from 192.168.20.2 on Serial0/0
*Mar 1 00:21:23.027: 10.0.0.0 in 1 hops
*Mar 1 00:21:23.027: RT: 10.0.0.0 came out of holddown
*Mar 1 00:21:23.027: RT: add 10.0.0.0/8 via 192.168.20.2, rip metric [120/1]
*Mar 1 00:21:23.031: RT: NET-RED 10.0.0.0/8
*Mar 1 00:21:23.031: RT: NET-RED queued, Queue size 1
*Mar 1 00:21:23.035: 192.168.50.0 in 16 hops (inaccessible)
*Mar 1 00:21:23.035: RT: 192.168.50.0 came out of holddown
R1#
Note que agora a rota não foi deletada como no exemplo anterior. O holddown expirou e o R1 passou a aceitar o anúncio da rota vindo de R2 e adicionou a informação na tabela de rotas.
R1#
R1#sh ip route
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, 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 routeGateway of last resort is not set
C 192.168.40.0/24 is directly connected, Serial0/2
C 192.168.20.0/24 is directly connected, Serial0/0
R 10.0.0.0/8 [120/1] via 192.168.20.2, 00:00:04, Serial0/0
R 192.168.50.0/24 is possibly down, routing via 192.168.40.2, Serial0/2
R1#
Bem pessoal, espero que o artigo tenha ajudado com o entendimento dos timers do RIP. Não esqueçam praticar e realizar os testes por si mesmo. A dica aqui é praticar, praticar, praticar…Por isso, montem suas topologias e divirtam-se. Se preferirem utilizem nosso lab-remoto e teste em equipamentos reais.
Lembrem-se também que toda regra tem suas exceções. Comportamentos diferentes podem ocorrer quando o poison-reverse e split-horizon atuarem. Diferentes versões de IOS também podem variar seu comportamento.
E se você quer aprender mais sobre roteadores e switches Cisco venha estudar conosco. Nosso Curso CCNA Online cobre toda a matéria do CCNA e você ainda terá a sua disposição diversos recursos para melhorar o seu aprendizado. Simulados onlines, práticas em simuladores, fóruns de discussão e instrutores certificados para tirar suas dúvidas online.
