Mostrando postagens com marcador Policy-Map. Mostrar todas as postagens
Mostrando postagens com marcador Policy-Map. Mostrar todas as postagens

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.

quinta-feira, 3 de janeiro de 2013

Técnicas de Restrição de Banda: Policing x Shaping

Olá Pessoal.

Esse é o primeiro post de 2013, então nada mais interessante do que fazer uma "conexão" com o último post de 2012 que tratava da utilização de técnicas de policing (policiamento) na restrição de banda.

No post anterior utilizamos uma técnica de Class-Based Policing para limitar a taxa do tráfego de saída de uma interface para um determinado usuário. Para fazê-lo foi escrita a seguinte configuração:

01. R1(config)# ip access-list extended Host-Chupim
02. R1(config-ext-nacl)# permit ip any host 192.168.0.109
03. R1(config-ext-nacl)# permit ip host 192.168.0.109 any
04. R1(config-ext-nacl)# exit
05. R1(config)#class-map match-all Chupim
06. R1(config-cmap)#match access-group name Host-Chupim
07. R1(config-cmap)#exit

08. R1(config)#policy-map QoS  
09. R1(config-pmap)#class Chupim
10. R1(config-pmap-c)#police rate 128000 bps
11. R1(config-pmap-c-police)# end

12. R1# configure terminal  
13. R1(config)# int f0/0
14. R1(config-if)# service-policy output QoS

Não vou gastar palavras explicando o significado de cada linha, já que basta observar o post de 29/12/2012 (Policy-Map na Restrição da Taxa de Tráfego) para encontrar os detalhes do cenário. Nós poderíamos ter obtido o "mesmo" resultado utilizando uma técnica comum de QoS denominada Class-Based Shaping. O processo de configuração do shaping é muito similar ao policing, como pode ser visto abaixo. Reparem que a única diferença está na linha destacada em cada configuração.

01. R1(config)# ip access-list extended Host-Chupim
02. R1(config-ext-nacl)# permit ip any host 192.168.0.109
03. R1(config-ext-nacl)# permit ip host 192.168.0.109 any
04. R1(config-ext-nacl)# exit
05. R1(config)#class-map match-all Chupim
06. R1(config-cmap)#match access-group name Host-Chupim
07. R1(config-cmap)#exit

08. R1(config)#policy-map QoS  
09. R1(config-pmap)#class Chupim
10. R1(config-pmap-c)#shape average 128000
11. R1(config-pmap-c-police)# end

12. R1# configure terminal  
13. R1(config)# int f0/0
14. R1(config-if)# service-policy output QoS

Apesar da configuração ser realmente muito similar e o resultado obtido ser aparentemente o mesmo (a princípio), existe uma diferença importante entre esses dois métodos de restrição de banda (policing x shaping) que pode influenciar no desempenho de redes maiores que possuem um fluxo constante de dados. 

A técnica de policing é agressiva no sentido de que TODO tráfego que exceder o limite configurado no comando "police rate X bps" será sumariamente DESCARTADO. Essa técnica pode ser configurada para remarcar os pacotes com menor prioridade, mas a ação padrão é descartar!

Por outro lado, a técnica de shaping é mais elegante e internamente mais complexa para o roteador. O shaping consome mais processamento e memória do equipamento porque todo tráfego de exceder o limite configurado no comando "shape average X" será direcionado para uma fila local (memória) e depois de um intervalo de tempo será feita uma nova tentativa de encaminhamento dos pacotes enfileirados. 

Em redes cujo tráfego oscila bastante entre momentos de pico e outros de pouco consumo de banda, esse método é interessante porque evita o descarte desnecessário dos pacotes, mantendo as aplicações mais estáveis e o comportamento da rede mais suave para o usuário. O gráfico abaixo foi retirado da própria página da Cisco e ilustra muito bem o comportamento da rede através das duas técnicas.




Nos gráficos à esquerda temos a demanda de tráfego que supera o limite imposto. Nos gráficos à direita é possível observar claramente o comportamento REAL do tráfego através de cada uma das técnicas. Através do policing, o tráfego oscila bastante porque nos momentos de pico o usuário fica restrito à banda configurada e em momentos de menor uso a banda remanescente fica ociosa.

Por outro lado, através do shaping o tráfego normalmente fica estável no pico configurado. Isso acontece porque todo o tráfego excessivo ao limite imposto é enfileirado e de tempo em tempo (nos momentos de menor uso da rede) esses pacotes são enviados, consumindo a banda remanescente. Isso é bem interessante, no entanto é importante notar que duas desvantagens desse método são: (i) há um aumento na latência dos pacotes excessivos em virtude da espera na fila e (ii) o equipamento irá consumir mais memória e processamento para gerenciar a fila.

De maneira simples e objetiva, é isso! A diferença entre os métodos está compreendida? Bom, então qual dessas técnicas é a melhor e portanto deve ser utilizada? A respota é: AS DUAS!!! Não existe uma melhor do que a outra, já que cada uma tem sua aplicação específica.

Se no seu ambiente existe uma política impositiva de que o tráfego de uma aplicação ou usuário em uma interface NÃO DEVE EXCEDER um limite X de banda, então a técnica de policing é a ideal. Por outro lado, se no seu ambiente você está passando por alguns momentos de pico na rede e seu objetivo é melhorar o desempenho das aplicações, então a técnica de shaping deve ser ideal para você.

Por fim, tenha em mente aquilo que eu sempre falo em aula para os meus alunos: NENHUMA TÉCNICA DE QoS É SOLUÇÃO MÁGICA PARA REDES SUB-DIMENSIONADAS. Ou seja, se sua rede gera 2X de tráfego e sua infraestrutura está dimensionada para atender apenas X, então em algum momento você terá problemas! O QoS é ideal para priorizar aquelas aplicações mais importantes (como voz) e mesmo para melhorar o desempenho de redes cujo tráfego oscila, no entanto não faz milagre!!! É isso... Espero que tenham gostado do primeiro post do ano.

Abraço.

Samuel.

sábado, 29 de dezembro de 2012

Policy-Map na Restrição da Taxa de Tráfego

Olá Pessoal.

Sabe aquele usuário na empresa que acha que toda a banda de Internet é dele ou que banda é um recurso infinito? Então, por pensar assim ele vive fazendo o download de arquivos pesados, ouvindo rádio, assistindo vídeos, entre outras coisas. Nesse post mostrarei como vocês podem usar técnicas de QoS para restringir a banda desse usuário - o vulgo "chupim"! Vamos utilizar o cenário abaixo para exemplificar o processo de configuração e estamos partindo do princípio de que o endereço do "chupim" é bem conhecido (estático ou dinâmico com lease pré-configurado).



O processo de configuração de QoS em dispositivos Cisco consiste em três etapas básicas: (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 estrada/saída de alguma interface. Esses recursos juntos são poderosos para classificar e marcar diversos tipos de tráfego para fins de QoS. Por exemplo, class-maps podem ser escritas para classificar tráfego de áudio, vídeo, dados, aplicações específicas, etc. Já as policy-maps utilizam a classificação prévia para fazer a marcação dos pacotes, comumente escrevendo os códigos DSCP (6 bits) do campo ToS (8 bits) do cabeçalho IP. 

Nesse exemplo não será feita nenhuma marcação porque nosso objetivo não é priorizar classes distintas de tráfego. Faremos uma classificação bem simples de tráfego de um usuário e então limitaremos a taxa de transmissão para esse nó da rede. Então vamos às configurações:

01. R1(config)# ip access-list extended Host-Chupim
02. R1(config-ext-nacl)# permit ip any host 192.168.0.109
03. R1(config-ext-nacl)# permit ip host 192.168.0.109 any
04. R1(config-ext-nacl)# exit
05. R1(config)#class-map match-all Chupim
06. R1(config-cmap)#match access-group name Host-Chupim
07. R1(config-cmap)#exit

08. R1(config)#policy-map QoS  
09. R1(config-pmap)#class Chupim
10. R1(config-pmap-c)#police rate 128000 bps
11. R1(config-pmap-c-police)# end

12. R1# configure terminal  
13. R1(config)# int f0/0
14. R1(config-if)# service-policy output QoS

Partindo dessa lógica, as linhas de 05 a 07 criam uma class-map associando todo o tráfego originado ou destinado ao usuário "chupim" (linhas de 01 a 03). Nas linhas de 08 a 10 criamos uma policy-map que restringe a banda desse usuário a míseros 128kbps e, por fim, na linha 14 aplicamos nossa policy-map na saída da interface f0/0 do roteador que está conectado na rede local. Tenha cuidado ao fazer isso arbitrariamente na empresa em que você trabalha sem ter o consentimento do seu superior, afinal o "chupim" pode ter a "costa quente"!!! ;-)

Samuel.