Hot Standby Router Protocol - HSRP

 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.

Bring Your Own Device

BYOD

 As my first article in English, I’d like to discuss about BYOD. BYOD stands for Bring Your Own Device and is considered a phenomenon on these days.  Most probably I will not bring anything new to this subject but I do have experience with BYOD and from the perspective of those who are suffering with this phenomenon.

  As Wireless Network administrator, I saw our wireless demand grow up from about four thousand users daily to about seven thousand users daily in less than two years. And sure enough, we don’t have earned too many users during this time. What happened was that most of our users have duplicated the number of device on their desks.

 The result is destructive from an Administrator point of view. We had to fight against a log of trouble recently, starting with IP exhaustion and going to network performance. Once we don’t have a BYOD well defined strategy yet, it gathering for us a lot of complaint from users.

And the challenge has just begun. Once resolved the IP exhaustion problem adding more DHCP scope on our DHCP server and so Interfaces and AP group on our controllers, we ran into the issue of performance problem. So upgrade is need.

 Don’t matter which strategy your company intend to adopt, it is probably that some kind of expense and work around will be necessary. If the strategy is deny any device besides corporative device, so some work around will be necessary or if the strategy is allow those devices to access the Network so a lot of work must be done.

 Performance, security, maintenance, etc. must be considered. But this not stops here. Once it is allowed that personal devices can access the corporate Network and to be used in corporate activities, how can we establish where Network administrator responsibility began and ends? If a user’s tablet is unable to access the corporate internet or execute a corporate application, how can an Administrator handle this problem once this device is used by the users outside the company? I mean, with others networks configurations and application that may require, for example, proxy to work whilst on the Corporate network it not. 100% sure, users will be changing from an environment to another and will not be aware of changing these configurations.  And going still farther, what about the need for format a device driver full of private files and private apps?  We can be responsible if something went wrong with personal files and software? By giving support on this device will be the Administrator fixing a corporative device problem or a personal device problem? Just to give one example.

 The big players always say that BYOD will bring productivity to corporate environment. Is that true?  I think a lot of things must be considered.

BYOD came and must stay independently how productive it is or how hard to handle. Simply because this is what people expect from technology. People want to be connected anytime, anywhere and BYOD is just a consequence.