Todo protocolo de rede foi feito/desenhado para solucionar um problema, do mais complexo ao mais simples.
Antes de falarmos sobre HSRP precisamos entender qual o problema ele vem resolver.
Considere a topologia abaixo, PC01 faz parte da VLAN10, configurado com o IP 192.168.1.1, está conectado ao SW01 (Switch01) e precisa se comunicar ao PC02 que por sua vez está na VLAN20, configurado com o IP 192.168.2.1 e conetado ao SW02 (Switch02). Considerando conceitos básicos de rede sabemos que PC01 não conseguirá se comunicar diretamente ao PC02 (pois estão em subnets diferentes), o tráfego precisará passar pelo Gateway de cada computador. No caso de PC01 o seu gateway é o IP 192.168.1.252 e para o PC02 o seu Gateway é o IP 192.168.2.252, podemos então entender que RT01 é o Gateway ativo de ambas Vlans.
Caso PC01 gere tráfego para o IP 192.168.2.1 (PC02) podemos perceber que há sucesso. Tanto PC01 quanto PC02 conseguem se pingar mutualmente.
Abrindo uma captura de pacotes realizada na interface de rede do RT01 conseguimos confirmar que realmente o tráfego entre os hosts passam por ele.
Tudo certo e funcional, certo?
Sim...mas considere que em ambas Vlans temos mais dezenas de usuários. O que acontece quando acontecer alguma falha no RT01?
Ele sendo o gateway de ambas as redes podemos entender que comunicação entre redes (tanto interna quanto externa) não funcionará, resultado e impacto disso varia, mas podemos considerar que em grande maioria isso se traduz em empresa parada e gerente no seu pescoço para resolução imediata, nada legal...
Uma possível solução seria manualmente mudar o IP de gateway em cada estação, mas considere um cenário onde as localidades são separadas em prédios, ou o número de máquinas ultrapasse dezenas, a ‘solução’ fica impraticável. Outra opção seria no servidor DHCP alterarmos o IP de gateway e pedir para todos usuários reiniciarem suas máquinas ou forçar a solicitação de novo IP em cada estação, se pensarmos friamente essa solução também não é nada prática, não seria melhor já que possuimos dois equipamentos eles serem capazes se assumirem a responsabilidade de gateway em caso de falha do par? É nesse tipo de situação que utilizamos o Hot Standby Redundancy Protocol (HSRP).
HSRP é um protocolo de rede proprietário CISCO, de forma geral podemos dizer que o objetivo do protocolo é fornececer alta disponibilidade de primeiro salto para dispositivos dentro de um segmento de rede.
Para utilizarmos HSRP na rede precisamos de pelo menos dois equipamentos, um responsável por recebimento e encaminhamento de tráfego (Primário) e o outro trabalhando como ‘backup’. O roteador backup assume o tráfego em caso de falha do primário. Em cada segmento, HSRP é configurado na interface do equipamento com vínculo a um grupo (group) que precisa ser compartilhado entre os equipamentos. Alta disponibilidade é alcançada com a criação de um IP virtual (VIP – Virtual IP) e é esse IP que os usuários deverão usar como gateway.
Esse VIP fica atrelado a um endereço MAC virtual que é anunciado apenas pelo roteador primário, é para esse endereço que os dispositivos de rede local encaminharão tráfego.
Os roteadores que fazem parte do grupo HSRP se comunicam periodicamente entre si via Multicast, caso o roteador primário falhe, por consequência a comunicação entre eles falhará e o roteador secundário assumirá automaticamente a função de ‘Master’ (primário) do grupo HSRP. Esse processo é totalmente transparente para os usuários.
Temos duas versões de HSRP, v1 e v2. A tabela abaixo mostra a diferença entre os dois.
Não necessariamente é necessário decorar o endereço MAC de cada versão, mas é importante de maneira geral saber a diferença entre cada um.
Vamos voltar para a nossa topologia e configurar HSRP (para o exemplo iremos utilizar a versão 1) e verificar a sua sincronização.
Antes de iniciamos as configurações vamos ficar de olho no Wireshark para podermos monitorar em tempo real a ‘mágica’ acontecendo.
Como utilizaremos a versão 1 do protocolo o filtro do Wireshark vamos filtrar o endereço 224.0.0.2 (Multicast).
Filtro Wireshark
# ip.addr == 224.0.0.2
A configuração básica de HSRP é bem simples, ela deve ser feita na interface do roteador, no nosso caso a GigabitEthernet0/1.10.
A sintaxe é:
#standby hsrp group number ip hsrp vip ip
Os comandos em negrito se referem a comandos estáticos, enquanto os comandos em itálico se referem as variáveis, no nosso caso as variáveis são:
hsrp group number = 10 (É recomendado utilizar o mesmo grupo HSRP que o número da vlan ou interface, isso facilita na manutenção e entendimento, lembrando que para grupos de número acima de 255 é necessário utilizar HSRPv2)
hsrp vip ip = 192.168.1.254 (Não há uma regra de qual IP a ser utilizado a não ser um endereço livre, mas é importante você seguir um padrão, normalmente é visto a utilização do ultimo IP livre do barramento como VIP).
Após os comandos serem inseridos podemos perceber que recebemos uma mensagem que o roteador local teve seu status do grupo 10 do HSRP alterado de Standby para Active, vamos ver isso no Wireshark.
Assim que o comando standby 10 ip 192.168.1.254 é inserido o roteador envia um anúncio na rede pelo endereço Multicast 224.0.0.2. Esse anúncio é usado para avisar que ele está ‘entrando’ na rede/grupo HSRP.
Na sequência o roteador envia pacotes Hello com o estado ‘Speak’. Nesse momento o roteador está verificando se há outros equipamentos configurados com HSRP no barramento.
Na sequência o roteador avisa a rede que ele é o node Ativo do grupo HSRP e assume o tráfego.
Vamos agora incluir o RT02 no grupo HSRP (os comandos insderidos em R2 são idênticos aos usados em R1)
Olhando o wireshark vemos que logo após inserirmos o comando na interface do RT02 ele envia os mesmos pacotes que o RT01, inicialmente encaminha um pacote Advertise com o status em Passive, em seguida encaminha pacotes Hello com o estado em Speak, diferentemente do RT01, o RT02 não tenta se tornar ativo nesse momento, pois ele está ouvindo os pacotes Hello do RT01 que já é o Ativo.
Ao rodar o comando ‘show standby’ podemos ver mais informações.
De cima para baixo após o comando ‘show standby’ temos as seguintes informações:
Interface e grupo do HSRP, no nosso caso é a interface Gigabitethernet0/1.10 e grupo HSRP 10
Estado operacional do HSRP, no caso é como Active (Saudável)
Qual o IP virtual do grupo, no caso o IP é 192.168.1.254
Endereço MAC virtual, no caso é o 0000.0c07.ac0a (lembre que o virtual mac address segue o esquema 0000.0C07.ACxx, sendo o xx o número do grupo em hexadecimal, no nosso caso o número do grupo é 10 (0A em hexadecimal).
Endereço MAC virtual configurado localmente (é possível mudar o endereço mac do VIP por equipamento)
Dados dos temporizadores, sendo 3 segundos entre cada Hello e holdtime em 10 segundos, esse segundo tempo é o valor que o roteador aguardará sem receber Hello antes de se tornar o roteador Active.
Tempo para o próximo Hello, no exemplo será em 2.272 segundos
Preemption disabled. Preemption é a função do roteador de reassumir o papel de Active após se recuperar de uma falha ou reboot.
Active Router is Local, informação se o roteador é o master/primary do HSRP ou o roteador standby/secundário
Informações do roteador Standby no caso é o 192.168.1.253 (RT03) e a prioridade desse roteador, no caso, 100.
Prioridade local, no caso 100
E nome do grupo HSRP
A saída do comando no RT02 é bem similiar, com mudança apenas nos valores esperados, como dados locais e do estado do HSRP, segue abaixo.
Vamos agora simular uma falha (reboot do RT01) e monitorar a comunicação entre PC01 e PC02. Antes disso vamos verificar o estado do HSRP dos dois grupos (vlans 10 e 20) no RT02:
Podemos perceber que o RT02 está como Standby para os grupos 10 e 20.
Vamos agora reiniciar o RT01.
Se olharmos o RT02, podemos perceber que ele assumiu o passou para o estado Active no grupo HSRP.
Assim que o RT01 volta a operar podemos verificar que a sincronia do grupo HSRP acontece novamente. Como o RT02 estava como Active e o RT01 não possui a função Preempt (tomar a função de Active novamente) configurada o estado do HSRP só vai mudar quando algum evento acontecer no RT02.
O exemplo abaixo mostra tráfego partindo do PC01 para PC02 durante o processo de reboot do RT01, como podermos ver, não houve perda de comunicação entre os hosts, isso mostra que realmente houve chaveamento automático no HSRP.
É importante notar que no exemplo abaixo não houveram perdas de pacotes, mas numa rede em produção pode ser percebido algumas perdas pacotes, o objetivo do protocolo é evitar isso, mas como sabemos, nada é perfeito. Dificilmente o usuário perceberá algo, mas aplicações sensíveis a perdas de pacotes podem sentir um pequeno 'soluço' na rede. Novamente, essa situação vai depender de diversos fatores.
É importante também notar que ao assumir a função de Active no HSRP o RT02 precisa anunciar a rede que ele agora é o ‘dono’ do endereço mac 0000.0c07.ac0a, ele faz isso enviando Gratuituous Arp para a rede. Isso faz com que os switches e demais equipamentos limpem a entrada que antigamente apontava para a interface de rede do RT01 e aponte para a interface do RT02. É essa ação de anúncio que faz a transição ser transparente para os usuários e demais equipamentos, pois os equipamentos continuam mandando os dados para o mesmo IP e endereço MAC, sendo responsabilidade dos Switches o encaminhamento do tráfego para a interface correta.
Para fecharmos o tópico, vamos fazer com que o RT01 reassuma automaticamente o papel de Active após uma falha, no caso iremos ativar a função de Preempt na interface do roteador.
Antes vamos confirmar que RT01 continua como Standby.
Preempt configurado (abaixo), agora deve ser esperado o RT01 assumir o papel de Active no HSRP, certo?
Infelizmente não. Como podemos ver abaixo, o RT02 continua como Active no HSRP. Isso é devido a prioridade do HSRP. Por padrão ao subir um grupo HSRP ele é iniciado com a prioridade (Priority) em 100, mesmo com preempt configurado no RT01 ele não vai tomar o papel de Active do RT02 pois os dois possuem a mesma prioridade.
Para isso vamos fazer que RT01 possua uma prioridade maior que RT02, isso fará que o RT01 assuma o papel de Active não apenas em recuperação de falhas, mas seja o preferido ao papel de master em qualquer situação.
O comando para mudar a prioridade do grupo hsrp é ‘standby hsrp-group-number priority 0-255’
Como podemos ver acima, logo após alterar a prioridade do grupo 10 para 105 o RT01 assumiu a função de Active no HSRP.
Abaixo podemos ver os novos pacotes Hello do RT01 sendo enviados a rede com a nova prioridade de 105 e se anunciando como Active do grupo.
O RT02 não pode fazer nada além de acatar as mensagens e se retirar do papel de Active e mudar seu papel para Standby.
Como pudemos ver, o protocolo HSRP não é complicado em sua essência e resolve grandes problemas que poderiam gerar grandes prejuízos as empresas que não fazem adoção dele ou de qualquer outro procolo de redundância de primeiro salto (First Hop Redundancy Protocol).
Em outro artigo falarei um pouco sobre possíveis problemas que podem ser criados com a utilização de HSRP sem considerar o desenho da rede como um todo e algumas funções avançadas que podem ser utilizadas com o protocolo.
Por enquanto obrigado e espero que eu possa ter ajudado :)