Mostrando postagens com marcador QoS. Mostrar todas as postagens
Mostrando postagens com marcador QoS. 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). 

A 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.

quarta-feira, 2 de abril de 2014

Discussão: QoS e Marco Civil da Internet

Olá Pessoal.

Recentemente surgiu uma discussão bastante interessante no grupo "CCNA Brasil" (do Facebook) a respeito da possibilidade de utilização de técnicas de QoS (Qualidade de Serviços), caso o Marco Civil da Internet seja efetivamente sancionado pela presidente, depois de aprovado no Senado. Um dos colegas entendeu que aquela discussão foi tecnicamente bastante produtiva e que deveria ser publicada para toda a comunidade, por isso estou socializando seu conteúdo aqui no blog.


Deste ponto em diante toda a redação que estiver em itálico/marrom são palavras de outros colegas que estarei transcrevendo nessa postagem. A discussão começou com um colega fazendo o seguinte questionamento:

"Um dos artigos no Marco Civil trata da neutralidade da Internet, que em tese quer dizer que todos os serviços seriam tratados de maneira igualitária. Se o Marco Civil entrar em vigor podemos dizer que QoS é contra a lei? Fiquei confuso..."

Diante desse questionamento minha resposta foi a seguinte:

QoS no contexto da Internet sempre foi uma prática condenável pela Internet Society desde sua concepção e há boas razões para isso. Uma coisa é definir políticas claras de priorização de tráfego no contexto de uma organização que possui sua rede, o que é comum e perfeitamente válido - algo que todas as empresas fazem. Outra coisa seria fazer isso na Internet que não possui dono ou política global. As políticas na Internet são bilaterais, individualizadas. Uma empresa simplesmente define suas políticas e seus usuários seguem, mas quem faria isso na Internet? A abrangência da Internet torna inviável definir essas políticas sem inserir injustiça social... Fique tranquilo que praticar QoS não é ilegal e continuará sendo comum em empresas e ISPs (provedores). O ilegal seria essa prática na CADEIA de ISPs que compõem o ecossistema da Internet com acordos comerciais que não mantenham a isonomia de tráfego fim-a-fim, exceto para serviços de emergência. 

O colega entendeu a resposta e emendou a seguinte pergunta:

"Samuel, entendo sua colocação. Mas acontece que a infraestrutura que as empresas utilizam (onde é normal aplicar QoS) é a mesma que nós usamos. Cito por exemplo um Velox. Uma empresa que contrata um link MPLS da Oi utiliza a mesma infraestrutura (afinal é tudo uma única rede) que o coitado acessando o YouTube para ver um vídeo qualquer." Daí o colega trouxe a redação do Art 5o do Marco Civil que, em síntese, diz que todo o tráfego na Internet deve ser tratado de forma isonômica, ou seja, sem que haja diferenciação/priorização. Por fim ele completou sua fala: "Eu entendo isso como proibição do QoS em meio compartilhado. Posso estar errado e esse texto pode até ser alterado, mas estou filosofando com vocês!".

E a minha resposta foi:

Um link de longa distância dedicado, por exemplo um MPLS (WAN), não é a Internet, por mais que eventualmente use a Internet por baixo para conectar unidades remotas ou mesmo que tenha por objetivo prover acesso à Internet. A empresa está pagando por aquele pedaço dedicado de banda que é garantido por SLA e pode utilizá-lo como bem entender, praticando qualquer forma de QoS - aquele espaço é somente dela (não deveria prejudicar o restante dos usuários). Quando pensamos nos links convencionais (não dedicados), ninguém que faz parte dessa cadeia que envolve os diversos ISP`s possui um pedaço dedicado da Internet (modelo best-effort) e é por isso que a gente diz que a conexão fim-a-fim tem que ser tratada de forma igual. É isso que explica, por exemplo, o motivo de um link dedicado de 2Mbps ter desempenho melhor do que o link convencional (compartilhado) de 25Mbps da sua casa, já que nesse caso a latência é menor no link dedicado. 

A chamada "discussão filosófica", por sinal muito produtiva, continuou e o colega fez uma pergunta bastante oportuna para enriquecer a discussão:

"Eu entendo perfeitamente a diferença, Samuel. Mas por mais que esse link dedicado seja fim-a-fim, ele continua utilizando uma infraestrutura compartilhada e minha "filosofação" é referente ao QoS desses equipamentos. Se em algum momento um equipamento de core recebe um pacote do Joãozinho tentando ver um vídeo do YouTube e também um pacote da empresa XYZ do seu link dedicado, em tese, o pacote da empresa XYZ receberia um tratamento diferenciado. O problema aqui é que as estruturas são compartilhadas e não dedicadas."

Resposta: Concordo com o colega que essa infraestrutura é compartilhada em todos os provedores, mas os serviços providos são diferentes. Reparem, então, que estamos falando de modalidades de conectividade, não de conteúdo. A rede de telecomunicações é uma coisa, por sua vez a Internet é outra coisa que utiliza a capilaridade destas redes de telecom para ter abrangência mundial. O Marco Civil regulamenta a Internet, não as redes de telecomunicações. Por isso reforço que o link de longa distância dedicado não é a Internet. A operadora interessada em comercializar conectividade dedicada (WAN) e também Internet pode fazê-lo sem problema nenhum, desde que sua rede esteja suficientemente dimensionada para que uma modalidade não interfira na outra - essa separação é lógica nos equipamentos, não física. Por isso que digo que o uso do link dedicado não deveria interferir no uso do link convencional da Internet. A competição na Internet deve ocorrer entre os usuários comuns dessa rede, ou seja, quanto mais usuários forem pendurados nessa rede compartilhada, pior o desempenho. Se a operadora não investe em sua infraestrutura na ânsia de vender mais e mais conectividade, o que sabemos que acontece, esse é outro problema e compete à fiscalização da Anatel. As coisas estão fortemente relacionadas, mas são diferentes. 

A discussão cessou neste ponto e entendo que o mais importante dessa conversa é ter em mente que se uma operadora vende conexão dedicada, então ela deve provisionar os recursos necessários para não interferir em outras modalidades de serviços oferecidos (o que é algo natural do ponto de vista de marketing). Elas não podem inserir um novo serviço às custas de prejudicar outro já existente... A Internet convencional que o usuário contrata é um serviço comumente comercializado. 

Obs.: Aproveito para registrar um agradecimento especial aos colegas Rafael Bianco Nacif e Carlos Augusto que participaram da discussão e sugeriram/permitiram sua publicação no blog.

Abraço.

Samuel.

sexta-feira, 14 de fevereiro de 2014

Bloqueio de Sites e Nomes FQDN via ACL/NBAR

Olá Pessoal.

Esse artigo apresenta a solução para um problema comum nas empresas que é o bloqueio de determinados sites na Internet. A maioria das empresas utiliza um proxy para esse fim, o que é recomendado e torna as coisas bem mais fáceis. No entanto, nem sempre esse equipamento está disponível e pode ser interessante utilizar o próprio roteador de borda, responsável por prover acesso à Internet, para realizar esse serviço de filtragem, afinal todo roteador de borda é um firewall natural. 

A princípio a escrita de ACLs no roteador de borda para bloquear um determinado site através do seu endereço IP de destino é realmente bastante simples, mas acontece que muitas vezes é necessário escrever regras dessa natureza informando como destino os nomes de domínio FQDN (fully qualified domain name), por exemplo www.labcisco.com.br.

Até então o problema parece continuar bastante simples, afinal basta substituir o endereço de destino pelo nome FQDN e tudo deve funcionar, não é? Não, nem sempre é simples assim... Os sites de serviços providos por grandes empresas, a exemplo da Google e Facebook (e vários outros) não possuem apenas um único endereço de destino, sendo acessíveis através de vários endereços para assegurar a disponibilidade em caso de falha.

Ao utilizar nomes de domínio na escrita de uma ACL, será realizado o processo de resolução de nomes apenas para o primeiro endereço válido e não para todos os endereços possíveis. Ou seja, caso o administrador queira bloquear o YouTube por completo, então seria necessário bloquear todos os endereços vinculados com o domínio youtube.com. 

Uma solução para fazer isso seria levantar previamente todos os endereços IP correspondentes ao site que deve ser bloqueado e, posteriormente, escrever regras para cada um desses destinos. O problema dessa solução é que esses endereços não são estáticos e por isso é comum eles mudarem ao longo do tempo, o que torna o trabalho de bloqueio a sites bastante complicado.

Para resolver esse problema esse artigo apresentará um recurso denominado NBAR (Network Based Application Recognition) que será utilizado em conjunto com as ACLs tradicionais. O NBAR é uma ferramenta para implementar QoS que é suportada em todos os equipamentos mais recentes, viabilizando a classificação do tráfego da rede em categorias baseadas nos protocolos e outros parâmetros. O cenário desse laboratório é ilustrado na figura abaixo.


Implementar QoS requer a configuração de (1) classes de tráfego via class-map, (2) de políticas a serem aplicadas nessas classes via policy-map e (3) a inserção das políticas nas interfaces de rede via service-policy. Então utilizaremos class-map, policy-map e service-policy para classificar/marcar todo o tráfego destinado para youtube.com e, na sequência, utilizaremos ACLs para bloquear esse tráfego previamente marcado com a codificação DSCP (Differentiated Services Code Point) comumente utilizada para fins de QoS. Nosso objetivo nesse artigo não é aprofundar a discussão sobre QoS e nem entrar em detalhes da codificação DSCP.

Os comandos necessários para classificar o tráfego e bloqueá-lo são:

!---- Parte 1: Class-Map p/ Identificar o Site
01. Router(config)# class-map match-any Classe-YouTube
02. Router(config-cmap)# match protocol http url "*youtube.com*"
03. Router(config-cmap)# exit

!---- Parte 2: Policy-Map p/ Marcar a Classe de Tráfego
04. Router(config)# policy-map Politica-YouTube
05. Router(config-pmap)# class Classe-YouTube
06. Router(config-pmap-p)# set ip dscp 1
07. Router(config-pmap-p)# exit
08. Router(config-pmap)# exit

!---- Parte 3: Service-Policy p/ Aplicar a Marcação na Rede Local
09. Router(config)# interface f0/0
10. Router(config-if)# description "Rede Local"
11. Router(config-if)# service-policy input Politica-YouTube
12. Router(config-if)# exit

!--- Parte 4: ACL p/ Bloquear o Tráfego Marcado
13. Router(config)# ip access-list extended NegaYouTube
14. Router(config-acl-ext)# deny ip any any dscp 1
15. Router(config-acl-ext)# permit ip any any
16. Router(config-acl-ext)# exit

!--- Parte 5: Aplicação da ACL na Saída p/ Internet
17. Router(config)# interface f0/1
18. Router(config-if)# description "Internet"
19. Router(config-if)# ip access-group NegaYouTube out
20. Router(config-if)# exit

Observem na primeira parte que foi criada uma class-map para classificar todo tráfego HTTP com a URL desejada, processo realizado através da inspeção dos pacotes. Na segunda parte escrevemos uma policy-map que aplica o código DSCP=1 para todo perfil de tráfego identificado na class-map anterior. A codificação DSCP tem alguns códigos padronizados, então optamos pelo código 1 porque provavelmente esse código não estará associado com nenhuma aplicação. Na terceira parte aplicamos a política de marcação dos pacotes em todo tráfego entrante na interface do roteador que está conectada na rede interna (gateway da rede interna). Por fim é configurada uma ACL que nega acesso a todo pacote que tenha o campo DSCP=1, cabendo destacar que essa regra deve ser aplicada no sentido sainte da interface conectada à Internet.

Uma observação importante é que essa solução funciona muito bem para tráfego HTTP (80) porque o NBAR consegue fazer a inspeção do cabeçalho dos pacotes, no entanto é impossível fazer a leitura de conteúdo cifrado via HTTPS (443). Por isso o NBAR não irá funcionar para serviços que somente operam através do HTTPS. Nesse caso o jeito é fazer uso das vantagens de um proxy...

Abraço.

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.