HSRP é um protocolo simples porém muito eficiente e útil. Se sua rede tem alguma redundância para um determinado destino, ele é uma forma muito simples e eficiente de evitar downtime em sua rede.
Existe ainda em muitos ambientes situações em que uma rota estática é usada em casos de redundância. Isso funciona,claro, mas tem o inconveniente de precisar que alguem vá até lá e altere manualmente a rota estática. Durante esse tempo, a rede ficará isolada.
Como vou mostrar nesse Post, HSRP serve para que caminhos redundantes possam permanecer disponíveis e a comutação ocorrerá de forma totalmente transparente e automática para a rede.
Diferente, entretando, de protocolos de roteamento dinâmicos, a idéia do HSRP não é fornecer balanceamento entre links, mas sim, chaveamento automático entre links.
O funcionamento do protocolo é simples. Dispositivos são dividos em grupos. Podemos ter até 16 grupos com 16 membros cada. A Cisco recomenda uma limitação de 256 Interfaces HSRP por dispositivo.
Uma interface pode pertencer a diferentes grupos HSRP da mesma forma que um Grupo HSRP pode ser aplicado a diferentes interfaces.
O conceito do protocolo é : Um VIP é criado. VIP significa Virtual IP. Também é criado um Mac address virtual. Esse VIP irá ser o gateway para sua rede ou host.
A comunicação irá ocorrer com esse VIP, de forma que para a origem, não importa quem realmente está roteando os pacotes.
Dentro de um grupo HRSP irá existir sempre um dispositivo ativo e um standby. Caso o grupo tenha mais de dois dispositivos, os demais ficarão no estado de Init.
Será usado o IP 224.0.0.2 multicast para troca de informação dentro do grupo. São enviado pacotes Hello a cada intervalo pre-definido na configuração.
Olhando no Wireshark, fica assim:
Podemos ver que dois dispositivos fazendo parte do grupo: 172.16.0.101 e 172.16.0.102. O IP de destino é o IP de multicast 224.0.0.2 e a frente podemos ver os estados.
Abaixo segue minha topologia no GNS3:
C1 representa minha máquina física. R4 é um switch layer 2. Depois temos R2 e R3 que são dois roteadores rodando o HSRP. Em seguida temos outro switch layer 2 e um servidor Linux para onde disparamos os testes.
Vamos ver as configurações em R2:
R2#sh stand
FastEthernet0/0 - Group 100
State is Standby
3 state changes, last state change 00:02:06
Virtual IP address is 172.16.0.100
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 5 sec, hold time 15 sec
Next hello sent in 3.744 secs
Preemption enabled
Active router is 172.16.0.102, priority 100 (expires in 13.656 sec)
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Fa0/0-100" (default)
Primeiro é mostrado a Interface onde o HSRP está ativo e o número que dei ao grupo. No caso 100.
Em seguida, é mostrado o estado do serviço. O R2 é o roteador em Standby.
Em seguida é mostrado algumas estatísticas de mudanças e depois o VIP do grupo que é 172.16.0.100. Esse é o gateway do meu PC.
O MAC é definido no padrão 0000.0c07.acXX, sendo XX o número do Grupo em Hexa.
Na sequencia é definido o Hello e o hold time.
Preemption é um parametro usado para determinar um dispositivo como prefencial.
Com esse parâmetro, o dispositivo com a maior prioridade irá sempre ser o Ativo. Caso sua interface fique inoperante e o outro assuma como ativo, logo que a condição da interface voltar ao normal, o dispositivo de maior prioridade voltará a ser o ativo.
Por último, o IOS define um nome para o grupo.
Abaixo as configurações do roteador R3.
R3#sh standby
FastEthernet0/1 - Group 100
State is Active
2 state changes, last state change 00:46:49
Virtual IP address is 172.16.0.100
Active virtual MAC address is 0000.0c07.ac64
Local virtual MAC address is 0000.0c07.ac64 (v1 default)
Hello time 5 sec, hold time 15 sec
Next hello sent in 0.952 secs
Preemption enabled
Active router is local
Standby router is 172.16.0.101, priority 100 (expires in 14.260 sec)
Priority 100 (default 100)
Group name is "hsrp-Fa0/1-100" (default)
Podemos ver que tudo se repete, menos o estado que nesse caso é o Ativo.
Até aqui, porém, vemos que a prioridade é a default 100.
Alterando manualmente a prioridade em R2, podemos ver os comportamentos abaixo:
R2(config-if)#standby 100 priority 200
R2(config-if)#
*Mar 1 00:49:41.467: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Standby -> Active
R2(config-if)#standby 100 priority 95
R2(config-if)#
*Mar 1 00:49:56.571: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Active -> Speak
R2(config-if)#
*Mar 1 00:50:11.571: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Speak -> Standby
R2(config-if)#
Primeiro foi definido uma prioridade alta. Imediatamente o roteador foi para ativo. Em seguida, baixei a prioridade para 95 e ele voltou para Standby.
Caso o parametro preempt não tivesse sido definido, o roteador ficará em ativo até ter problemas em sua interface HRSP. Desta forma, ele ficará no estado Init e quando o problema for resolvido ele voltará como Standby e permanecerá assim. Ele só voltará a ser novamente o ativo se o outro apresentar problemas na interface.
Vamos mostrar agora o protocolo em ação.
Como evidência vemos que nosso ping extendido inicia as 1:08:01,44 e vai de forma ininterrupta até as 1:09:08,23.
Porém, nesse tempo, vamos analise os logs dos roteadores:
Aug 12 01:08:19.247: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 100 state Active -> Init
R3(config-if)#
Aug 12 01:08:21.267: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down
Aug 12 01:08:22.267: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down
Como vemos acima, as 01:08:19 houve chaveamento do HSRP de Acitve para Init e logo em seguida o roteador logou a interface down.
Nesse mesmo tempo, R2 assumiu como ativo:
R2#
Aug 12 01:08:12.467: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Standby -> Active
R2#
Na sequência, a Interface foi reativada:
R3(config-if)#no shut
R3(config-if)#
Aug 12 01:08:32.883: %LINK-3-UPDOWN: Interface FastEthernet0/1, changed state to up
Aug 12 01:08:33.883: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to up
R3(config-if)#
Aug 12 01:08:34.319: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 100 state Listen -> Active
R3(config-if)#
R3 volta ao estavo Active
Em R2 o HRSP voltou para Standby:
Aug 12 01:08:27.551: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Active -> Speak
R2#
Aug 12 01:08:42.547: %HSRP-5-STATECHANGE: FastEthernet0/0 Grp 100 state Speak -> Standby
R2#
Considerando ai alguns segundos de diferença entre o horario em ambos os roteadores e o PC.
Abaixo vemos o ping constante:
C:\Users\fm044m>time
The current time is: 1:08:01,44
Enter the new time:
C:\Users\fm044m>ping 192.168.0.1 -t
Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=12ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=19ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=16ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=15ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=21ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=25ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=24ms TTL=63
Reply from 192.168.0.1: bytes=32 time=18ms TTL=63
Reply from 192.168.0.1: bytes=32 time=18ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=17ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=18ms TTL=63
Reply from 192.168.0.1: bytes=32 time=22ms TTL=63
Reply from 192.168.0.1: bytes=32 time=15ms TTL=63
Reply from 192.168.0.1: bytes=32 time=17ms TTL=63
Reply from 192.168.0.1: bytes=32 time=17ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=15ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=19ms TTL=63
Reply from 192.168.0.1: bytes=32 time=21ms TTL=63
Reply from 192.168.0.1: bytes=32 time=20ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=39ms TTL=63
Reply from 192.168.0.1: bytes=32 time=16ms TTL=63
Reply from 192.168.0.1: bytes=32 time=16ms TTL=63
Reply from 192.168.0.1: bytes=32 time=27ms TTL=63
Reply from 192.168.0.1: bytes=32 time=24ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=12ms TTL=63
Reply from 192.168.0.1: bytes=32 time=13ms TTL=63
Reply from 192.168.0.1: bytes=32 time=17ms TTL=63
Reply from 192.168.0.1: bytes=32 time=18ms TTL=63
Reply from 192.168.0.1: bytes=32 time=16ms TTL=63
Reply from 192.168.0.1: bytes=32 time=14ms TTL=63
Reply from 192.168.0.1: bytes=32 time=19ms TTL=63
Reply from 192.168.0.1: bytes=32 time=18ms TTL=63
Reply from 192.168.0.1: bytes=32 time=15ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=21ms TTL=63
Reply from 192.168.0.1: bytes=32 time=11ms TTL=63
Reply from 192.168.0.1: bytes=32 time=17ms TTL=63
Ping statistics for 192.168.0.1:
Packets: Sent = 61, Received = 61, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 39ms, Average = 16ms
Control-C
^C
C:\Users\fm044m>time
The current time is: 1:09:08,23
Desta forma, comprovamos a eficiência do protocolo da Cisco HSRP. Como já havia informado na introdução do Post, esse protocolo é muito importante em ambiente de redes que requer alta disponibilidade mas que por um motivo ou outro não justifica a implantação de um protocolo de roteamento dinâmico.
No comments:
Post a Comment