terça-feira, 17 de janeiro de 2017

Configuração de Link P2P em Bridge no Cisco Aironet

Olá Pessoal,

Tradicionalmente os dispositivos Access Point (AP) são utilizados como concentradores em redes sem fio com o propósito de viabilizar uma célula em seu entorno com área de cobertura para que haja comunicação com múltiplos dispositivos clientes de modo ponto-a-multiponto, motivo pelo qual os APs são equipados com antenas omnidirecionais com largura de feixe de 360° no plano horizontal (azimute). Apesar dessa ser a aplicação mais comum, há casos em que é necessário alterar esse comportamento convencional de modo a configurar dois APs em bridge para viabilizar a comunicação ponto-a-ponto, por exemplo na interligação sem fio à distância entre duas unidades remotas de uma empresa (vide figura). 

Nesses casos são acopladas nos APs antenas externas que tenham menor largura de feixe e com maior ganho (dBi) em uma determinada direção. A escolha da antena direcionada mais adequada vai depender da distância entre as duas unidades remotas, destacando que quanto maior o ganho da antena, maior será seu alcance e menor será a largura do feixe no plano horizontal. Por exemplo, antenas parabólicas são as que têm maior ganho (de 20 a 30 dBi) e podem alcançar vários quilômetros de distância (por volta de 50km), dependendo da obstrução no caminho entre as antenas. 


Obs.: Esteja ciente de que antenas parabólicas de alto ganho não devem ser utilizadas sem que o enlace de radiofrequência tenha sido devidamente projetado para irradiar sinal efetivo (EIRP) dentro dos limites legais do seu domínio regulatório, levando em consideração a potência de transmissão, a perda no cabo e demais componentes e o ganho da antena. Conforme Resolução 506/2008 da Anatel, no Brasil o EIRP máximo permitido na frequência de 2,4GHz é de até 30dBm (1000mW) em cidades com até 500.000 habitantes ou de até 26dBm (400mW) em cidades com mais de 500.000 habitantes. Qualquer enlace que esteja operando acima desses parâmetros deve ser licenciado junto à agência. 

O objetivo deste artigo é listar os passos necessários para configurar dois Aironet da Cisco em modo bridge para que seja possível estabelecer um enlace ponto-a-ponto entre duas unidades remotas, com base no cenário apresentado na figura anterior. Repare que as duas unidades pertencem à mesma sub-rede lógica em camada 3 (rede), o que deixa evidente que a conexão em modo bridge nada mais é do que uma ligação em camada 2 (enlace). É como se os APs fossem switches nas unidades remotas que estivessem interligados através de um cabo. Ocorre que na maioria dos casos não é possível fazer a passagem dos  cabos na via pública e a locação de um link dedicado não é barato (quando há disponibilidade no local), então fazer essa ligação através do meio não-guiado (wireless) acaba sendo uma opção atrativa.

Obs.: Também é possível isolar cada unidade em sua respectiva sub-rede lógica (camada 3). Nesse caso, o link ponto-a-ponto entre os dois APs é configurado como sendo uma sub-rede /30 independente das outras duas sub-redes das unidades remotas, de forma que cada AP terá um dos IPs disponíveis na sub-rede /30. O AP de cada unidade remota será diretamente conectado em um roteador de borda, ao invés de um switch. Se essa estratégia for adotada, é importante ter em mente que nos roteadores de borda deverá ser adicionada uma rota para a sub-rede lógica da outra unidade. 

Abaixo o leitor encontra os comandos necessários para configurar ambos os APs através dá interface de linha de comando (CLI) do IOS. Observe que o AP-A foi definido como root bridge e que o AP-B foi definido como non-root bridge, sendo que o canal do enlace é definido apenas no AP raíz. Assim que o link for efetivamente estabelecido, o LED dos Aironet em ambas as unidades mudará sua cor de verde para azul, indicando que os dois APs estão associados entre si. 

AP-A(config)# interface bvi1
AP-A(config-if)# ip address 192.168.0.201 255.255.255.0
AP-A(config-if)# exit
AP-A(config)# ip default-gateway 192.168.0.1
AP-A(config)# dot11 ssid BRIDGE
AP-A(config-ssid)# authentication open
AP-A(config-ssid)# authentication key-management wpa ver 2
AP-A(config-ssid)# wpa-psk ascii PASSWORD
AP-A(config-ssid)# exit
AP-A(config)# interface dot11radio0
AP-A(config-if)# station-role root bridge
AP-A(config-if)# channel 6
AP-A(config-if)# encryption mode ciphers aes-ccm
AP-A(config-if)# ssid BRIDGE
AP-A(config-if)# no shut
AP-A(config-if)# end

AP-B(config)# interface bvi1
AP-B(config-if)# ip address 192.168.0.202 255.255.255.0
AP-B(config-if)# exit
AP-B(config)# ip default-gateway 192.168.0.1
AP-B(config)# dot11 ssid BRIDGE
AP-B(config-ssid)# authentication open
AP-B(config-ssid)# authentication key-management wpa ver 2
AP-B(config-ssid)# wpa-psk ascii PASSWORD
AP-B(config-ssid)# exit
AP-B(config)# interface dot11radio0
AP-B(config-if)# station-role non-root bridge
AP-B(config-if)# encryption mode ciphers aes-ccm
AP-B(config-if)# ssid BRIDGE
AP-B(config-if)# no shut
AP-B(config-if)# end

Façam seus testes...

Samuel.

quarta-feira, 11 de janeiro de 2017

Marcação DSCP e QoS em Roteadores Cisco

Olá Pessoal,

O modelo DiffServ de serviços diferenciados é flexível de acordo com o perfil das aplicações, uma abordagem alinhada com o conceito de nível de serviço (SLA) em que são previamente acordadas as classes de serviços com base em parâmetros como volume de tráfego, disponibilidade e outros que possam assegurar o desempenho adequado dos serviços em execução na infraestrutura de uma rede. O modelo DiffServ é o mais utilizado para implementar QoS porque exige menos dos roteadores do que o modelo IntServ de serviços integrados que requer protocolos inteligentes para que os roteadores possam providenciar a reserva prévia de recursos entre dois pontos (cliente/servidor). 

RFC 2597 e RFC 2598 descrevem, respectivamente, aquilo que é denominado Assured Forwarding (AF) e Expedited Forwarding (EF), ambos mecanismos de classificação de diferentes níveis de tráfego para serviços diferenciados no modelo DiffServ. Existem quatro classes AF que variam de AF1X até AF4X, sendo que o primeiro número é a prioridade da classe. Quanto maior o número de prioridade, então maior é a importância daquele perfil de tráfego no ambiente. O segundo número (representado por X) varia de 1 a 3 e diz respeito à preferência de descarte dos pacotes, sendo que números maiores têm maior probabilidade de serem descartados. Já a classe EF faz referência ao encaminhamento expresso, ou seja, aquele perfil de tráfego que possui baixa tolerência a qualquer tipo de atraso (tradicionalmente o tráfego de voz). A tabela abaixo traz um resumo de todas as combinações possíveis dos códigos das classes AF e EF.

|-----------------------------------------------------------------|
| Descarte | Classe 1 | Classe 2 | Classe 3 | Classe 4 | Expresso |
|-----------------------------------------------------------------|
| Baixo    |   AF11   |   AF21   |   AF31   |   AF41   |          |
| Médio    |   AF12   |   AF22   |   AF32   |   AF42   |    EF    |
| Alto     |   AF13   |   AF23   |   AF33   |   AF43   |          |
|----------|----------|----------|----------|----------|----------|

O modelo DiffServ propõe um sistema de códigos para classificação de tráfego que é denominado DSCP (DiffServ Code Point) e consiste em sobrescrever os primeiros 6 primeiros bits do campo ToS (Type of Service) do cabeçalho IP, Dessa maneira, cada código diz respeito a uma classe de tráfego que pode receber tratamento diferenciado pelo administrador. A figura abaixo traz um resumo de alguns dos principais códigos DSCP, inclusive com o mapeamento das principais classes AF/EF previamente apresentadas e sugestões de associações com aplicações típicas do cotidiano:

Fonte: Internet (sem especificação de autoria)  
É fato que no primeiro momento parece ser bastante informação teórica para assimilar, então aproveito o cenário simplista da topologia abaixo para exemplificar a configuração prática de alguns desses conceitos, particularmente em relação à marcação de pacotes de uma aplicação qualquer em execução na porta TCP/3050 com o código AF41 (ou DSCP 34) para fins de priorização desse tráfego, além de marcação de um host qualquer com o código AF13 de baixa prioridade.


O objetivo não é discutir cada uma das linhas abaixo com detalhes dos elementos de uma política de QoS, por isso recomendo a leitura do artigo intitulado "Policy-Map na Restrição da Taxa de Tráfego". Apenas vale relembrar que basicamente o processo de configuração de QoS em dispositivos Cisco consiste em três etapas: (i) classificação do tráfego via class-map, (ii) definição da política através de policy-map e (iii) aplicação da policy-map na entrada/saída de alguma interface.

!--- ACL 101 (Referente Tráfego do Host 192.168.0.109 (Host 109)
access-list 101 permit ip host 192.168.0.109 any
access-list 101 permit ip any host 192.168.0.109

!--- ACL 102 (Referente Tráfego do Servidor de Banco de Dados (Firebird)
access-list 102 permit tcp any any eq 3050
access-list 102 permit tcp any eq 3050 any

!--- Classificação do Tráfego da ACL 101 na Class-Map HOST-109
class-map match-all HOST-109
   match access-group 101
   exit

!--- Classificação do Tráfego da ACL 102 na Class-Map FIREBIRD
class-map match-all FIREBIRD
   match access-group 102
   exit

!--- Definição de Políticas na Policy-Map QOS
policy-map QOS
   class HOST-109
      set dscp af13
      police rate 256000 bps
      exit
   class FIREBIRD
      set dscp af41
      end

!--- Aplicação da Policy-Map na Saída da Interface F0/0
interface f0/0
   service-policy output QOS 

Nesse exemplo foram definidas duas class-map, uma vinculada à ACL 101 que faz referência ao host 192.168.0.109 (class-map HOST-109) e outra vinculada à ACL 102 que faz referência à aplicação TCP/3050 (class-map FIREBIRD). Observem que nesse exemplo é realizada apenas a marcação dos pacotes em um roteador isolado, sendo que sua utilização em cenário real também requer a leitura prévia dessa marcação para posterior aplicação de ações/políticas nos demais roteadores intermediários da rede.

Na sequência, a policy-map denominada QOS possui duas políticas, uma relacionada ao host 192.168.0.109 que marca seus pacotes com o código DSCP AF13 (baixa prioridade) e também aplica uma restrição de banda de apenas 256k; e outra relacionada a uma aplicação em execução na porta TCP/3050 que apenas faz a marcação dos seus pacotes com o código DSCP AF41 (alta prioridade) sem aplicar nenhuma outra ação. 

Por fim, o comando "show policy-map" pode ser utilizado para visualizar todas as políticas que foram configuradas em um determinado roteador da rede, lembrando que essas políticas são individuais de cada roteador (distribuídas), ainda que exista um esforço centralizado de definição dessas políticas no ambiente da empresa. Ou seja, é importante estar atento no momento de fazer as configurações das políticas de QoS nos roteadores da infraestrutura porque facilmente a escrita equivocada de regras pode implicar em roteadores contendo políticas contraditórias entre si (ambiguidade).

!---
!--- Visualização de Políticas Previamente Configuradas
!---
R1# show policy-map
  Policy Map QOS
    Class HOST-109
      set dscp af13
      police rate 256000 bps burst 8000 bytes
        conform-action transmit 
        exceed-action drop 
    Class FIREBIRD
      set dscp af41



Façam seus testes...

Samuel.