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
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
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.
Bom dia Samuel,
ResponderExcluirTenho uma dúvida, não sei se é primária! mas vamos lá.
Trabalho em um provedor de acesso, e nas interfaces configuradas em nosso backbone, estão configuradas tanto a "service-policy" quanto "rate-limit", por quê?
Grato.
Olá Diego.
ExcluirO rete-limit é mais limitado do que a service-policy e seu uso está restrito exclusivamente a técnicas de restrição de banda e marcação básica. Seu uso é comum em provedores que precisam limitar a taxa de tráfego com base no contrato dos seus clientes, o que é denominado CAR (Commited Access Rate).
Já a service-policy tem uma estrutura totalmente modular baseada em policy-maps que, por sua vez, são compostas de class-maps. Uma class-map identifica um determinado tipo de tráfego e você pode criar estruturas aninhadas de class-maps dentro de uma policy-map, o que oferece muita flexibilidade. Além disso, a service-policy não está restrita apenas à restrição de tráfego, são diversas as técnicas que QoS que você pode utilizar com esse método.
Em síntese, os dois recursos podem ser utilizados para limitar a taxa de tráfego, no entanto a service-policy é mais poderosa e te dá mais flexibilidade porque você pode moldar diferentes classes de tráfego através das class-maps. O fato é que atualmente a service-policy pode fazer tudo que o rate-limit (CAR) faz e mais, por isso o CAR é considerado um recurso legado!
Abraço.
Opa Samuel muito obrigado pela rápida resposta, mas aprofundando o assunto,
ResponderExcluirutilizando o exemplo abaixo, há um tratamento diferenciado para os dados que chegam
em relação aos que saem, correto?
==================================================
interface GigabitEthernetx/x/x.00001
.. dados removidos...
rate-limit input 2048000 384000 768000 conform-action transmit exceed-action drop
service-policy output GOLD_2048K_VPN-IP_ETH_SHAPE
end
===================================================
Abraço.
Exato,
ExcluirRepare que no seu exemplo as políticas estão aplicadas em uma sub-interface lógica e não em toda a interface física - provavelmente é uma sub-interface vinculada a um cliente específico.
O tráfego que de saída está sendo tratado pela policy-map denominada GOLD_2048K_VPN-IP_ETH_SHAPE, provavelmente para fins de marcação e priorização de tráfego com base em classes de serviços do cliente. Para identificar as diferentes classes de serviço, procure pelas class-maps no arquivo de configuração. Já o tráfego de entrada está sofrendo restrição de banda de no máximo 2Mbps (2048000).
Abraço.
Muito obrigado Samuel,
ExcluirRealmente a sub-interface em questão pertence a um cliente.
Com sua ajuda, as coisas estão ficando mais claras para mim.
E novamente seu blog esta de parabéns, estou indicando para vários amigos e colegas de trabalho.
Abraço.
Samuel, acompanho sempre o seu blog e compartilhando seus posts. Mas hoje vim lhe pedir uma ajuda, estou estudando um pouco mais sobre QoS, qual programa posso usar para gerar trafego em um ambiente criado no GNS3, mas com tráfegos específicos como voz, vídeo, etc..? e poder visualizar o tratamento dos dados.. valeu.. abraço !
ResponderExcluirOlá Diego.
ExcluirPara fins de laboratório você poderia utilizar o recurso "IP SLA Monitor" dos equipamentos da Cisco, onde você pode especificar o tipo de tráfego a ser gerado para medir desempenho. Criando vários "geradores de tráfego" você conseguiria reproduzir diferentes classes para testar a aplicação do QoS.
Dê uma olhada no artigo abaixo que eu usei essa estratégia para gerar tráfego multicast ao abordar a configuração de roteamento multicast. Você pode explorar esse recurso para gerar outros tipos de tráfego para seus laboratórios, por ex: tráfego UDP (voz e vídeo).
Protocolo PIM-DM no Roteamento Multicast
Abraço.
Também dê uma olhada nesse link:
ExcluirCisco IOS SLAs Configuration Guide - Release 12.4
Muito obrigado Samuel.. Valeu mesmo !! Vou ver suas indicações e lhe digo como foi o resultado.. Abraço Inté
ExcluirSamuel, é assim que as empresas limitam a banda contratada mesmo quando link pode suportar uma velocidade maior?
ResponderExcluirSim, esse é um método utilizado com frequência para limitar banda. É claro que há outras ferramentas que fazem essa restrição.
ExcluirBoa tarde Samuel, sei que este post é um pouco antigo porém gostaria de uma ajuda em uma questão de limitação de banda.
ResponderExcluirTenho um cliente no meu backbone internet que utiliza uma porta Giga e pra ele foi configurado duas políticas para restrição de 100mb
Policy Map gi1/32-in
Class class-default
set dscp af11
police 100 mbps 256 kbyte conform-action transmit exceed-action drop
SW154#show policy-map gi1/32-out
Policy Map gi1/32-out
Class class-default
set dscp af11
police 100 mbps 256 kbyte conform-action transmit exceed-action drop
interface GigabitEthernet1/32
switchport access vlan 20
switchport mode access
load-interval 30
no cdp enable
spanning-tree portfast
service-policy input gi1/32-in
service-policy output gi1/32-out
Ele está limitado a 100mb de download entretanto o seu upload não passa de 8mbps.
Pode ser algum erro na minha configuração de limitação?
belo post lembrando que tem certos produtos como voz que o buffer(shape) é inviável tem que ter disponível a banda necessária dai entra o esquema do enfileiramento usando marcação de pacotes DSCP etc... abs!
ResponderExcluirBom dia, existe algum método para limitar Download e Upload ?
ResponderExcluirno caso 10mb de Down e 1 de Upload!!