Como configurar HSRP no Packet Tracer: guia CCNA 2

Quando uma rede tem um único roteador de borda como gateway, esse roteador vira um ponto único de falha: se ele cai, todos os hosts ficam ilhados. O HSRP (Hot Standby Router Protocol) resolve isso fazendo dois ou mais roteadores compartilharem um mesmo IP virtual, de modo que a queda de um seja absorvida pelo outro sem que o usuário perceba. Neste tutorial vamos configurar HSRPv2 no Packet Tracer dentro de uma topologia hierárquica realista — com switch core — e testar o failover na prática.

O que é o HSRP e qual problema ele resolve

O HSRP é um FHRP (First Hop Redundancy Protocol) proprietário da Cisco. A ideia central é simples: vários roteadores formam um grupo e elegem entre si um roteador Active e um Standby. O grupo passa a responder por um IP virtual (o gateway que os PCs usam) e por um MAC virtual associado a ele.

Os roteadores trocam mensagens hello via multicast a cada 3 segundos. Se o Standby parar de receber esses hellos por mais de 10 segundos (o hold time padrão), ele assume o papel de Active, passa a responder pelo mesmo IP e MAC virtuais e o tráfego volta a fluir. Como o gateway que os hosts conhecem nunca muda — nem o IP, nem o MAC — o failover é transparente para os PCs: o cache ARP deles continua válido.

Topologia do laboratório

A filial segue o modelo hierárquico da Cisco. O detalhe importante é que os dois roteadores de borda não se conectam diretamente: todo o tráfego entre eles e os hosts passa por um switch core operando em L2 puro.

        R-FIL-01 (Active)        R-FIL-02 (Standby)
        G0/0 .2/24                G0/0 .3/24
              \                      /
               \                    /
            Gig1/0/24          Gig1/0/23
                  +----------------+
                  |    SW-CORE     |  (Catalyst 3650 em L2 puro)
                  +----------------+
              Gig1/0/1        Gig1/0/2
                  |               |
              SW-FIL-01       SW-FIL-02
                  |               |
               PC-ADM          PC-FIN
              .10/24          .11/24
        gateway: 172.16.100.1 (IP virtual do HSRP)

Por que importa ter um switch core? Como todas as portas ficam na mesma VLAN, existe um único domínio de broadcast entre os dois roteadores e os PCs. É exatamente disso que o HSRP precisa: os roteadores de borda têm que se enxergar na camada 2 para trocar os hellos. Mais adiante esse switch nos dará uma visão privilegiada do que acontece durante o failover.

Endereçamento essencial

Repare que o gateway dos PCs (172.16.100.1) não pertence a nenhum roteador físico. Esse endereço só passa a existir quando o HSRP é configurado.

Pré-requisitos

Antes de partir para o HSRP, garanta que a camada 3 básica já funciona: cada roteador com seus IPs físicos, rota default em direção à matriz/internet, e o switch core com no ip routing (para operar em L2 puro). Confirme que do PC-ADM você consegue pingar o IP físico de R-FIL-01 (172.16.100.2). Se isso funciona, o HSRP é a cereja do bolo.

Configurando o roteador ativo (R-FIL-01)

A configuração do HSRP é feita na interface LAN do roteador (a que enfrenta os hosts). No R-FIL-01:

R-FIL-01> enable
R-FIL-01# configure terminal
R-FIL-01(config)# interface g0/0
R-FIL-01(config-if)# standby version 2
R-FIL-01(config-if)# standby 1 ip 172.16.100.1
R-FIL-01(config-if)# standby 1 priority 120
R-FIL-01(config-if)# standby 1 preempt
R-FIL-01(config-if)# standby 1 name HSRP-LAN-FILIAL
R-FIL-01(config-if)# end
R-FIL-01# write memory

Linha a linha:

Configurando o roteador standby (R-FIL-02)

No R-FIL-02 a configuração é mais enxuta de propósito:

R-FIL-02> enable
R-FIL-02# configure terminal
R-FIL-02(config)# interface g0/0
R-FIL-02(config-if)# standby version 2
R-FIL-02(config-if)# standby 1 ip 172.16.100.1
R-FIL-02(config-if)# standby 1 name HSRP-LAN-FILIAL
R-FIL-02(config-if)# end
R-FIL-02# write memory

Não configuramos prioridade nem preempção aqui. Ele fica com a prioridade padrão (100) e, por ter prioridade menor que o R-FIL-01, assume naturalmente o papel de Standby.

Verificando o HSRP

O comando essencial de verificação é o show standby brief. No R-FIL-01:

R-FIL-01# show standby brief
Interface   Grp  Pri P State    Active        Standby        Virtual IP
Gi0/0       1    120 P Active   local         172.16.100.3   172.16.100.1

No R-FIL-02 a saída espelha o estado oposto: estado Standby, prioridade 100, coluna P vazia e o Active apontando para 172.16.100.2. O que conferir:

• State: um deve estar Active e o outro Standby. Se os dois aparecem como Active, normalmente é porque estão em versões diferentes do HSRP.
• Pri: 120 no Active, 100 no Standby.
• P: preenchido apenas no roteador com preempt configurado.
• Virtual IP: 172.16.100.1 precisa aparecer igual nos dois.

Para ver os detalhes — incluindo o MAC virtual (algo como 0000.0c9f.f001 no HSRPv2 grupo 1) e os timers — use o show standby completo. Guarde esse MAC: ele é o protagonista do próximo teste.

Agora, do PC-ADM, o ping para o gateway virtual 172.16.100.1 deve funcionar — e, com ele, o acesso para fora da LAN também.

Testando o failover na prática

Esse é o teste que prova o valor do HSRP. No PC-ADM, dispare um ping contínuo para um destino externo:

C:\> ping -t 8.8.8.8

Com o ping rodando, simule a falha do roteador Active: clique no R-FIL-01, vá até a aba Physical e desligue o equipamento. De volta ao prompt do PC, você vai ver:

1. Alguns poucos pacotes marcados como Request timed out — tipicamente de 3 a 10, enquanto o Standby percebe a ausência dos hellos.
2. Em poucos segundos, os pings voltam a responder normalmente.

Conferindo no R-FIL-02, ele agora aparece como Active no show standby brief: assumiu o IP virtual e está roteando o tráfego dos PCs.

Ao religar o R-FIL-01, espere cerca de 30 a 40 segundos (boot + link + vizinhança HSRP). Como ele tem prioridade maior e o comando preempt, ele reassume o papel de Active e o R-FIL-02 volta para Standby. Sem o preempt, o R-FIL-01 voltaria apenas como Standby, mesmo tendo prioridade superior — esse é um detalhe que costuma derrubar gente na prova.

Por que o failover é transparente: o MAC virtual no core

Aqui está o ângulo que a topologia com switch core revela. No SW-CORE, filtre a tabela MAC pelo MAC virtual do grupo:

SW-CORE# show mac address-table | include 0c9f
   1    0000.0c9f.f001    DYNAMIC     Gig1/0/24

No estado normal, o MAC virtual é aprendido na Gig1/0/24, a porta conectada ao R-FIL-01 (o Active). Ou seja: quando um PC envia um frame para o MAC virtual, o switch o entrega ao R-FIL-01.

Agora derrube a interface do Active (mais rápido que desligar o roteador inteiro), espere ~15 segundos e olhe de novo:

R-FIL-01(config)# interface g0/0
R-FIL-01(config-if)# shutdown

SW-CORE# show mac address-table | include 0c9f
   1    0000.0c9f.f001    DYNAMIC     Gig1/0/23

O mesmo MAC virtual migrou para a Gig1/0/23 — a porta do R-FIL-02. Quando o Standby assume, ele passa a enviar tráfego usando o MAC virtual; o switch, fazendo seu trabalho normal de L2, reaprende esse MAC na nova porta e atualiza a tabela.

Para os PCs, nada muda: o IP e o MAC do gateway continuam idênticos, o cache ARP segue válido e os pacotes continuam chegando. É exatamente essa abstração — desacoplar o gateway lógico dos roteadores físicos — que torna o HSRP transparente para os hosts.

Resumo dos comandos essenciais

Próximos passos

Com o básico funcionando, vale explorar três evoluções naturais:

1. Autenticação MD5 (standby 1 authentication md5 key-string <chave>) para impedir que um roteador não autorizado entre no grupo.
2. Ajuste de timers (standby 1 timers <hello> <hold>) para reduzir o tempo de failover — sem descer abaixo de 1s de hello e 4s de hold, para não sobrecarregar a CPU.
3. Balanceamento por VLAN: com várias VLANs, alterne qual roteador é Active em cada grupo HSRP, evitando deixar um equipamento ocioso a maior parte do tempo.

Se você chegou até aqui com as saídas batendo, já domina o núcleo do HSRPv2 — o que aparece na prova do CCNA 2 e, mais importante, o que você vai reencontrar em redes hierárquicas no dia a dia.