Meraki

 Uma empresa de nome um tanto esquisito e fundada a apenas 7 anos é comprada pela maior gigante de Redes do mundo, que é a Cisco System, por uma bagatela de 1.2 bilhoes de dollares.
 Fundada por três estudantes do MIT, Meraki conseguiu o que talvez nenhuma empresa tenha conseguido em tão pouco tempo.
 A proposta de seus criadores é fornecer um produto plug-and-play. A principal bandeira da marca é redução de custo com o time de TI e compra de equipamentos.
 Minha visão sobre isso  é de admiração,receio e desconfiança. Admiração porque os números e a trajetória da empresa e produtos são impressionantes. E agora sob a tutela da Cisco, não consigo ver outro futuro a não ser o sucesso.
 Receio porque uma empresa com tanto sucesso e cuja principal bandeira é : Configure você mesmo sua rede caro Cliente, me parece prejudicial a nós profissionais da área. A Cisco com seu IOS que ainda hoje, predominantemente, é configurada em linha de comando, entra na onda de uma empresa com uma proposta bem diferente.
 Desconfiança porque assim eu vejo os serviços em nuvem. Em épocas de descobertas de espionagem desmetida pelos EUA, entregar toda a sua informação aos datacenters de empresas filhas do Tio San, como a Cisco, Google e Facebook parece tornar bem fácil a vida dos americanos.
 Sinceramente, eu acho que dados de usuários comuns não representa um ganho muito importante para ninguem. Mas, a espionagem comercial sim. Casos de empresas americanas que ganharam concorrência publica aqui no Brasil, levanta dúvidas sobre as reais intenções dos americanos, quando dizem que tudo que querem são os terroristas.
 Mas o que tem haver a empresa Meraki e tudo isso acima ? Bem, vamos explicar.
Em uma rede Wireless enterprise a empresa adiquire os APs, Controllers, NCS ISE, Location,etc,etc,. A Cisco sempre foi a empresa das  Boxes.
 Alem de tudo isso, é preciso de uma equipe que saiba implantar e suportar . Em resumo, um bom investimento.
 Comprar apenas um quantidade de APs, conectá-los na rede e gerenciá-los através de uma página web, como quem acessa o Facebook, com uma interface amigável, intuitiva e cheias de recursos é a proposta da empresa Meraki.
   A idéia é extremamente boa e comercialmente excelente. Tem tudo para proliferar e não é átoa que a Cisco entrou com tudo nisso.
 Minhas considerações ficam em duas frentes: Qual o papel do Analista de Suporte, e aqui me refiro a qualquer nível de Analista e qual o real benefício do serviço em núvem.
 Porque ao conhecer a proposta dessa empresa, são essas duas idéias que me vem a cabeça:
   Precisará o profissional de TI  adaptar-se  a uma nova realidade onde cada vez mais pessoas leigas montarão suas próprias redes com a ajuda de plataformas super-inteligentes ?
   Qual será o resultado de uma empresa ficar 100% dependente de recursos alocados na nuvem?
Além do quesito segurança, imagino o qão dependente as empresas ficarão dos provedores de internet.
 Afinal, seguindo essa linha, se uma empresa for iniciar suas atividades numa bela segunda-feira e perceber que não há acesso à Internet, o que a empresa fará ?
 Talvez essa idéia seja oriunda de um profissional brasileiro onde o acesso a infraestrutura de rede é precária. E em nada deve aplicar a um país como EUA,Japão e outros onde conexão full time a Internet não é discutível.
 Em fim, nada podemos fazer contra tendências a não ser tentar se preparar da melhor forma possível. Tentar enxergar possibilidades, desafios e adaptar-se.
  Por hora, me parece que a melhor coisa a fazer é justamente conhecer bem essa nova plataforma. Saber administrá-la e aproveitar o boom que provavelmente ela trará consigo.
 A Cisco já lancou a certificação CMNA (Certified Meraki Network Associate) e mesmo que as certificações represente uma fonte de renda para a próprio Cisco e nem tanto para quem se certifica, é inegável que uma certificação dessas dá um destaque enorme em um currículum.
 Concluindo, Meraki representa os principais conceitos de tecnoliga atuais: Comunicação movel inteligente ,flexível e em núvem.

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.