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.  

Voltando ao mundo da Telefonia

 As pessoas que me conhecem a mais tempo certamente pensam em min como um profissional da área de Telefonia. Porque eu estive nessa área por longos 6 anos. De 2001 a 2006 eu apenas trabalhei com essa área. Sabia muito pouco de redes, uma vez que trabalhava com Telefonia convencional. Na verdade iniciei como auxiliar técnico em 2001. O máximo que havia de integração com redes era através dos aplicativos que usavam CTI como tarifadores, mesas operadoras virtuais,etc. Era, em geral ,comunicação ponto-a-ponto com o PABX e algum computador.
. Quando a Telefonia convencional, TDM, começou a mostrar sinais de cançasso, pelo menos na esfera em que eu trabalhava, eu iniciei meus estudos de redes. Seria plausível de minha parte dizer que o fiz por perceber que seria inevitável uma migração do TDM para o IP, e talvez, tenha realmente sido assim,mas a rigor não foi.
 Eu pretendia fazer Engenharia Elétrica e me especializar em Eletrônica afim de trabalhar em algum projeto de PABX, TDM, mas a dificuldade em volta de fazer Engenharia Elétrica me conduziu para o curso de Redes. Eu consegui uma bolsa integral do governo e apostei na área. Por sorte, já nos primeiros dias de aulas eu me encontrei na área correta e me senti muito feliz por ter 'caído' nesse curso.
 Entre 2006 e 2009 eu ainda mantive contato com Telefonia, mas já tive a oportunidade de trabalhar com Voip e, por essa época, conheci Asterisk. Asterisk foi uma grande experiência profissional para min. Eu estava migrando para o mundo TCP/IP.
 Em 2011 com minha vinda para a AT&T, ironicamente uma empresa famosa pelo Telefone, eu entrei definitivamente na área de redes. Inicialmente ainda pensei em migrar para a área de Voz dentro da empresa, mas meu gosto por Redes era grande demais para sair. Os cenários de Redes que me foram apresentados eram, e ainda são, desafios estupendos, me possibilitando atingir um patamar de conhecimento de redes que eu jamais pensaria poder conseguir.
 Eu aprendo sobre redes a cada dia, minha curva de aprendizado está a uma ano e 4 meses numa vertical.
 Porém, para minha grata surpresa, soube que meu time passará a suporta infraestrutura de Voz também.
 Considero isso perfeito!  Estar ao mesmo tempo nas duas áreas, obviamente no caso de Telefonia apenas Telefonia IP, me faz completar um ciclo. Fico feliz por poder aproveitar os conhecimentos adquiridos ao longo de tempos. Ainda que a plataforma em questão seja Cisco, sei que poderei transferir muito de minha experiência.
 A medida que for aprendendo sobre Telefonica Cisco vou poder enriquecer o blog com minhas experiências. Quem sabe após CCNA Wireless não inicio CCNA VOICE. Afinal, Voz sobre Wireless é umas das grandes promessas das duas áreas.

Flavio Miranda.

Ultimo de 2012

 Finda-se 2012. Vamos para nosso último post deste ano.
Em uma breve análise, gostaria de compartilhar aqui algumas considerações sobre esse ano e as espectativas para o ano que vem.
 Eu queria ter  concluído 2012 como CCNA Wireless, mas não posso dizer que falhei. Eu estudei digamos que o suficiente para fazer a prova, mas devido ao término do ano fiscal da empresa, as certificações não estão sendo liberadas, ficando para o próximo ano fiscal. Bancar a prova apenas para ter o título não me pareceu ser interessante, afinal, o conhecimento que adquiri nesses tempos de estudo, tem sido de uma grande importância no meu dia-a-dia e isso é suficiente por hora. Acredito que em janeiro consigo fazer a prova e já poderei partir para novos desafios.

 2012 foi um ano de consolidação  para min. Após uma grande conquista profissional no final de 2011 que foi passar a fazer parte da AT&T, em 2012 consegui consolidar essa conquista. Aprendi muito. Multipliquei meus conhecimentos de redes, cresci como profissional, como pessoa. O feedback da empresa demonstrou que valeu a pena todo meu esforço no decorrer deste ano.

 Para 2013 eu pretendo então concluir o CCNA Wireless e partir com tudo para o CCNP Wireless. A demanda por Wireless no mercado é exponencial e dentro do meu ambiente de trabalho não é diferente.
 Nós administramos uma rede que está demandando grandes mudança para conseguir acompanhar os requerimentos que um ambiente de trabalho exige atualmente. Isso significa enormes desafios para 2013.

Ainda pretendo iniciar uma pós-graduação com ênfase em Wireless. Isso não é uma prioridade, mas estou trabalhando para que isso aconteça.

Enfim, encerro um excepcional ano e acredito estar entrando em outro ainda melhor. Espero continuar compartilhando aqui os conhecimentos que for adquirindo ao logo dos dias sempre baseado na filosofia de aprender e compartilhar.

Desejo a todos que passaram por esse blog uma ano de conquistas em 2013 e espero de alguma forma ter ajudado alguém ao longo do ano que passou.

 Feliz 2013 e nunca se esqueçam : Stay hungry, stay foolish !!

"Stay hungry,stay foolish!!"

"Stay hungry,stay foolish!!"

"Stay hungry,stay foolish!!"

"Stay hungry,stay foolish!!"

"Stay hungry,stay foolish!!"

Busquem o conhecimento mas nunca percam de vista que o conhecimento é sempre um objetivo a ser perseguido, nunca se deixe convercer de que você chegou até ele. Isso se chama soberba, orgulho e significa o fim de sua caminhada.

Grande abraço a todos !!!

Flavio Miranda.

Private Vlans e Isolated Vlans

 Hoje vou falar de um assunto voltado para Routing & Switching mas que é muito interessante. Vamos falar de private Vlans e Isolated Vlans.
Em meu trabalho anterior, prestávamos serviços como provedor de internet, ainda que pequeno, e tínhamos em um dos clientes esse tipo de implementação. Me recordo que usávamos switches Planet configurados através de uma interface web.
 Na AT&T ainda não vi esse tipo de implementação uma vez que nossas atividades estão mais voltadas para administração de data centers.
 A grande vantagem oferecida por esse tipo de implementação é poder usar um range de endereçamento IP para todos os clientes e mantar o controle do domínio de broadcast. Você nem seus clientes precisam ou querem que um cliente tenha aceso a outro e essa solução resolve esse problema.
   Vou usar terminologia Cisco para esse tutorial. Em resumo, precisamos ter uma Vlan dita Primary onde será colocada o default Gateway da rede. Sim, porque você está  usando apenas um range de IP com um gateway que possui uma interface com saída para a Internet e uma interface que atende a rede local. Essa interface fará parte da Vlan primary .
 O conceito de Isolated Vlans é bastante simples. Com essa solução, hosts em uma mesma Vlan, apenas são capazes de se comunicar com o default gateway, não se comunicam nem mesmo com os hosts dentro da mesma Vlan.
 Ou seja, se você tiver um cliente com várias máquinas, é possível colocá-las em uma Vlan do tipo community de forma que todos os hosts tenham comunicação  entre si e com o default gateway. Porém, se voce possui cliente que dispoem de apenas uma máquina, é possível agrupar todos esses clientes dentro de uma Vlan do tipo Isolated. Dessa forma, hosts terão comunicação com o gateway,porém, não terão acesso um ao outro.

 Abaixo, vou mostrar os comandos para a configuração das vlans. Vamos criar uma Vlan 10 como sendo a Vlan onde ficará o default gateway, uma vlan 20 e 30 para uso dos clientes.
Poderemos ver nos comandos comuity e isolated abaixo,  a vlan 20, do tipo community. poderá receber vários hosts e todos terão acesso um ao outro e ao default gateway.Porém, a vlan 30, do tipo isolated, terá hosts apenas com acesso ao default gateway devido ao comando.

Sw1(config)# vlan 10
Sw1(config-vlan)# private-vlan primary
Sw1(config-vlan)# private-vlan association 20,30

 O comando acima seria como o comando : switchport mode trunk allowed vlan add vlan 20,30.


Sw1(config)#
Sw1(config)# vlan 20
Sw1(config-vlan)#private-vlan community

Sw1(config-vlan)#vlan 30
Sw1(config-vlan)#private-vlan isolated

Uma vez definido a topologia lógica, devemos configurar as portas que farão parte dela.
O comando que coloca a interface do gateway como acessível a todos os hosts é como segue:


Sw1(config)#interface Fa 0/1
Sw1(config-if)# switchport mode private-vlan promiscuos
Sw1(config-if)# switchport private-vlan mapping 10 20,30.

Dessa forma, a porta Fa 0/1 será a interface que terá comunicação com cada host de minha rede local,ou seja, será o default gateway dos mesmos.

 E por último temos o comando abaixo:

Sw1(config)#interface Fa 0/3
Sw1(config-if)# switchport mode private-vlan host
Sw1(config-if)# switchport private-vlan host-association 10 20

Com esses comandos, estamos relacionado a porta Fa 0/3, onde vai estar conectado um host de um dos nossos clientes a vlan 10 e 20.
Percebam  que no comando anterior usamos a palavra promiscuos e agora usamos uma sintax parecida porém com a palavra host.

Basicamente isso é o que temos de comandos. A partir da daí seria apenas repetição desses comandos de acordo com a topologia que foi desenhada.

Vou adicionar um excelente vídeo que mostra como fazer as configurações  e os testes após as configurações:

Boa sorte e aproveitem esse vídeo tutorial muito bom !

iOS 6: Wi-Fi network roaming with 802.11k and 802.11r

 O título do Post foi retirado do site da Apple: http://support.apple.com/kb/HT5535

As informações encontram-se na aba "Support".
Em resumo, se você adquiriu um novíssimo aparelho Apple, como iPhone ou iPad, eles estão rodando o iOS 6, eles já possuem suporte aos não tão novos mas,muito esperados, protocolos 802.11k e 802.11r.
 Apesar de que as pessoas estão mesmo interessadas é no design, funcionalidades e outras frescuras que a Apple tão bem sabe fazer, o suporte a esses protocolos significa uma avanço interessantíssimo . Claro, não se pode querer que usuários tenham consciencia disso.
 Ratificado desde 2008, o protolo 802.11r, ou IEEE 802.11r-2008, já era bastante esperado pelos administradores de infraestrutura Wireless. Principalmente aqueles que já possuem o desafio de propiciar voz e vídeo sobre esse ambiente.
 Já discutimos aqui no blog, mais de uma vez, os desafios relacionados a mobilidade, mesmo sendo as redes Wireless totalmente voltada para mobilidade.
 A Cisco, como de costume, antecipou várias melhorias no intuito de propiciar aos usuários de sua tecnologia uma experiência positiva em relação a mobilidade, mas todos sabemos que as melhorias efetivas precisam vir com padronização e isso apenas entidades como IEEE e Wifi-Aliance pode nos propiciar.
 O problema é que, além da costumeira demora em se elaborar um novo padrão, existe ainda a costumeira demora na adoção desses padrões.
 Nesse caso em questão, a Apple deu um passo a frente e será, com certeza, seguida pelos seus concorrentes.

 Discutindo um pouco o que vem a ser esses protocolos, de uma forma geral eles propiciam duas coisas:
 Primeiro, APs e Clients agora  possuem uma linguagem ao qual podem lançar mão para se comunicarem e trocarem informações sobre o status da rede. Isso é feito através do protocolo 802.11k ou Radio Resource Managment.
  Várias informações serão coletadas e trocadas no intuíto de manter-se up to date com a qualidade da conexão. A medida que a qualidade se degradar, a possibilidade de mobilidade já será posta em curso e ocorrerá de forma rápida e segura.
Segundo, a autenticação no momento do roam passa a ser gerenciada de forma muito mais eficaz através do protocolo 802.11r.
 A linha de evolução diz que saímos de uma rede sem autenticção e/ou uma autenticação deficiente,porém, representava um cenário muito propício para mobilidade. Dois pacotes para autenticação, dois para associação e pronto, podíamos trocar dados com o Distribution System. Quando a vulnerabilidade se tornou crítica, métodos de autenticação mais eficientes foram desenvolvidos e a mobilidade ficou profundamente prejudicada.
  Em uma infraestrutura Enterpreise com um RADIUS situado em algum lugar na WAN, o processo de autenticação pode levar de 600ms ou mais. Para aplicações sensíveis ao tempo como voz, isso é um ambiente extremanete inapropriado.
 Medidas de contorno como as desenvolvidas pela Cisco possibilitaram o avanços da tecnologia mesmo em um mundo sem padronização, agora era possível realizar roam com apenas 50 ms, o que já propicia a existência de aplicações sensíveis ao tempo.Porém, existiam os problemas de compatibilidade.
 Mesmos programas como CCX, não são capazes de criar um ambiente realmente homogêneo. Sempre irá existir aquele fabricante que não irá aderir aos lideres de mercados em relação a essas iniciativas, mas irão fabricar e vender produtos incompatíveis, se tornando um pesadelo para aqueles que adminstram as infraestruturas.
  Quando produtos começam a surgir com protocolos padronizados, as coisas tornam-se fáceis. Equipamentos, independente de qual frabricantes, possuem uma linguagem em comun, podendo comunicar  sem maiores problemas.
  Porém, ainda teremos que aguardar algum tempo até que isso se torne realidade de fato. Como poderemos ver abaixo, redes já implementadas muito provavelmente terão de sofrer upgrades para comportar esses novos protocolos.

(Controller) >show wlan 1


WLAN Identifier.................................. 1
Profile Name.....................................XXX-WPA2
Network Name (SSID).............................. XXX
Status........................................... Enabled
MAC Filtering.................................... Disabled
Broadcast SSID................................... Enabled
AAA Policy Override.............................. Disabled
Network Admission Control

  NAC-State...................................... Disabled
  Quarantine VLAN................................ 0
Number of Active Clients......................... 0
Exclusionlist Timeout............................ 60 seconds
Session Timeout.................................. 28800 seconds
CHD per WLAN..................................... Enabled
Webauth DHCP exclusion........................... Disabled
Interface........................................ default-non-usable
WLAN ACL......................................... unconfigured
DHCP Server...................................... Default
DHCP Address Assignment Required................. Enabled

--More or (q)uit current module or <ctrl-z> to abort
Quality of Service............................... Silver (best effort)
Scan Defer Priority.............................. 5,6
Scan Defer Time.................................. 100 milliseconds
WMM.............................................. Allowed
Media Stream Multicast-direct.................... Disabled
CCX - AironetIe Support.......................... Enabled
CCX - Gratuitous ProbeResponse (GPR)............. Disabled
CCX - Diagnostics Channel Capability............. Disabled
Dot11-Phone Mode (7920).......................... Disabled
Wired Protocol................................... None
IPv6 Support..................................... Disabled
Peer-to-Peer Blocking Action..................... Disabled
Radio Policy..................................... All
DTIM period for 802.11a radio.................... 1
DTIM period for 802.11b radio.................... 1
Radius Servers
   Authentication................................ x.x.x.x
   Authentication................................ x.x.x.x
   Authentication................................ x.x.x.x
   Accounting.................................... Global Servers
   Dynamic Interface............................. Disabled
Local EAP Authentication......................... Disabled
Security



   802.11 Authentication:........................ Open System
   Static WEP Keys............................... Disabled
   802.1X........................................ Disabled
   Wi-Fi Protected Access (WPA/WPA2)............. Enabled
      WPA (SSN IE)............................... Disabled
      WPA2 (RSN IE).............................. Enabled
         TKIP Cipher............................. Disabled
         AES Cipher.............................. Enabled
                                                               Auth Key Management
         802.1x.................................. Enabled
         PSK..................................... Disabled
         CCKM.................................... Disabled
         FT(802.11r)............................. Disabled
         FT-PSK(802.11r)......................... Disabled


controller>config wlan security wpa akm ?

802.1x         Configures 802.1x support
cckm           Configures CCKM support
psk            Configures PSK support
ft             Configures 802.11r fast transition 802.1x support


Esses comandos foram retirados de equipamentos em produção e tiveram os hostnames alterados por questão de privacidade.
 O fato é que podemos verificar que não há suporte para esses novos protocolos.
Entretanto, isso é apenas uma questão de tempo e quem acaba por apressar ou retardar esse processo são os fabricantes. Pelo que tudo indica, vamos entrar na era da mobilidade de fato em ambientes Wireless.