Aula 18: QoS — Qualidade de Serviço e Priorização de Tráfego

Bem-vindo à Aula 18 do curso Cisco IOS — Do Zero ao Avançado. Hoje mergulharemos em um dos pilares mais negligenciados — e absolutamente vitais — da engenharia de redes moderna: QoS (Quality of Service). Se você já passou pela frustração de uma chamada VoIP entrecortada enquanto um colega baixava uma imagem ISO, ou viu uma transação financeira crítica perder pacotes em um link congestionado, você já experimentou na pele a ausência de políticas de qualidade de serviço. O QoS não é um luxo; em ambientes de produção reais, como os que gerenciamos diariamente em nossos projetos na JRT Technology Solutions, ele é a diferença entre uma rede funcional e uma rede que simplesmente “está no ar”.

Nesta aula, vamos além da teoria superficial. Você aprenderá a projetar, implementar e verificar políticas de QoS no Cisco IOS utilizando o poderoso framework MQC (Modular QoS CLI). Vamos construir as fundações teóricas essenciais — entendendo os modelos Best-Effort, IntServ e DiffServ — e, em seguida, colocaremos a mão na massa com configurações reais de classificação, marcação, policiamento e enfileiramento. Cada comando será explicado linha por linha, e cada saída de terminal será reproduzida exatamente como você verá em seus equipamentos. O foco é a aplicabilidade imediata: ao final desta aula, você será capaz de priorizar tráfego de voz, garantir banda mínima para aplicações críticas e limitar tráfego indesejado, transformando links congestionados em dutos previsíveis e controlados.

Por que o QoS é tão importante? Simples: os roteadores Cisco, por padrão, tratam todos os pacotes como iguais. Quando um link atinge sua capacidade máxima, o algoritmo FIFO (First In, First Out) descarta indiscriminadamente — e o descarte de um pacote de voz ou de uma atualização de banco de dados pode ter consequências desastrosas para o negócio. Com as ferramentas certas de QoS, você define quem passa primeiro, quem espera e quem é descartado quando não há alternativa. É uma mudança de paradigma: de reativo para proativo, de caótico para orquestrado. Em nossos treinamentos na JRT Technology Solutions, costumamos dizer que “largura de banda não gerenciada é largura de banda desperdiçada”.

O conteúdo desta aula é classificado como intermediário. Assumimos que você já possui familiaridade com o IOS, navegação entre modos de configuração, conceitos de roteamento IP e já realizou as aulas anteriores do curso. Se você ainda não domina tópicos como subinterfaces, VLANs ou comandos show básicos, recomendamos revisar as Aulas 12 a 17. Não se preocupe: forneceremos todo o contexto necessário para que até mesmo profissionais em transição de carreira possam acompanhar, mas o ritmo será intenso e voltado para resultados práticos. Ao terminar esta aula, você terá um roteador configurado com políticas de QoS funcionais, testadas e verificadas — um verdadeiro diferencial no seu portfólio técnico.

O que você vai aprender nesta aula

• Compreender profundamente os três modelos de QoS: Best-Effort, IntServ (RSVP) e DiffServ (DSCP)
• Dominar a arquitetura MQC — class-map, policy-map e service-policy — no Cisco IOS
• Configurar classificação de tráfego baseada em ACLs, protocolos e marcações DSCP/CoS
• Aplicar marcação e remarking de pacotes utilizando os campos DSCP e IP Precedence
• Implementar enfileiramento avançado: LLQ (Low Latency Queueing), CBWFQ e filas de prioridade
• Configurar policiamento (policing) e modelagem (shaping) de tráfego para controle de banda
• Prevenir congestionamento com WRED (Weighted Random Early Detection)
• Verificar a eficácia das políticas com comandos show e interpretar as saídas detalhadamente
• Diagnosticar e corrigir os erros mais comuns em ambientes QoS de produção

Pré-requisitos e Ambiente

Para executar todos os laboratórios desta aula sem interrupções, você precisará dos seguintes recursos. Em nossos treinamentos corporativos na JRT Technology Solutions, utilizamos uma combinação de hardware real e ambientes virtualizados, mas para esta aula o GNS3 ou EVE-NG atendem perfeitamente. A lista é enxuta, porém mandatória: cada item foi selecionado para garantir que você alcance os mesmos resultados apresentados aqui. Não pule a verificação de imagem do IOS — versões desatualizadas podem carecer de suporte a comandos essenciais como priority em policy-map ou ao comando dscp em class-map.

1. Cisco IOS versão 15.x ou superior — recomendamos a imagem c7200-adventerprisek9-mz.152-4.M7.bin para roteadores da série 7200 no GNS3. Ela oferece suporte completo ao conjunto MQC e recursos avançados de enfileiramento.
2. Dois roteadores Cisco interconectados via link serial ou FastEthernet — utilizaremos a topologia R1 — R2 com rede 10.0.0.0/30 entre eles.
3. Duas máquinas virtuais ou roteadores simulando hosts — uma para tráfego de voz (192.168.1.10) e outra para dados genéricos (192.168.1.20). No laboratório, utilizaremos loopbacks e testes com ping e iperf.
4. Conhecimento prévio: configuração de IP em interfaces, roteamento estático, ACLs básicas e uso do terminal IOS. Se você concluiu as aulas 12 a 17, já tem tudo o que precisa.
5. Ferramentas de teste: iperf3 (ou iperf) para geração de tráfego e Wireshark para captura e análise de marcações DSCP. Ambos gratuitos e multiplataforma.

Os Fundamentos de QoS: Por que Sua Rede Grita por Priorização

Antes de tocarmos no terminal, precisamos alinhar o entendimento conceitual. QoS não é um recurso mágico que “cria banda” onde não existe — e esse é o equívoco mais comum que encontramos em campo. A JRT Technology Solutions já atendeu inúmeros clientes que acreditavam que bastava instalar um roteador com “QoS ativado” para resolver problemas crônicos de subdimensionamento de link. A realidade é que QoS gerencia a escassez: quando há banda suficiente, todos os pacotes são encaminhados normalmente; quando a demanda excede a oferta — e apenas nesse momento —, as políticas de qualidade de serviço entram em ação para decidir quem sofre primeiro. Essa é a essência do gerenciamento de congestionamento.

No coração do QoS estão três grandes desafios técnicos, frequentemente resumidos na tríade latência, jitter e perda de pacotes. A latência é o tempo total de travessia do pacote; o jitter é a variação estatística dessa latência; e a perda ocorre quando buffers transbordam. Aplicações como VoIP são hipersensíveis: 150 ms de latência unidirecional já degradam a qualidade percebida, e jitter acima de 30 ms sem buffer de compensação (de-jitter buffer) torna a conversa ininteligível. Em contrapartida, uma transferência FTP pode tolerar atrasos e até retransmissões TCP sem que o usuário perceba — o arquivo chegará íntegro, apenas alguns segundos depois. Entender essas diferenças é o que permite criar políticas inteligentes de QoS.

O Cisco IOS opera com um pipeline lógico de processamento de QoS que segue uma ordem rigorosa: classificação → marcação → policiamento → enfileiramento → agendamento. Primeiro, o tráfego é identificado e separado em classes (classificação). Depois, os pacotes recebem marcas — normalmente no campo DSCP do cabeçalho IP — que os acompanharão por toda a rede (marcação). Em seguida, aplicam-se limites de taxa com ações de descarte ou reclassificação para tráfego excedente (policiamento). Os pacotes que passam pelo policiamento são então alocados em filas lógicas (enfileiramento), e um scheduler determina a ordem de transmissão com base nas prioridades configuradas (agendamento). Cada etapa será explorada exaustivamente nesta aula.

Uma metáfora que utilizamos em nossas capacitações na JRT Technology Solutions é a da portaria de um prédio comercial com catracas: todos os visitantes (pacotes) chegam e são classificados (funcionário, entregador, visitante). Funcionários crachá (marcação) passam direto pela catraca expressa (LLQ), entregadores têm catraca exclusiva com raio-X (CBWFQ), e visitantes sem crachá aguardam na fila geral (best-effort). Se o prédio lota, a portaria (policiamento) barra temporariamente novos visitantes, priorizando quem já está dentro. Essa analogia simplifica, mas captura a lógica: QoS é sobre políticas de acesso e prioridade no encaminhamento.

Modelos de QoS no Cisco IOS — Best-Effort, IntServ e DiffServ

O ecossistema de QoS no Cisco IOS suporta três modelos arquiteturais, e é fundamental que você saiba distingui-los para escolher a abordagem correta conforme o caso de uso. O modelo Best-Effort é a ausência de QoS — o padrão de fábrica de qualquer roteador. Nele, não há classificação, marcação ou priorização: a interface transmite pacotes na ordem de chegada (FIFO) e descarta quando o buffer enche (tail drop). É simples, previsível em baixa utilização, mas desastroso para tráfego sensível. Você encontrará Best-Effort em links de backbone superdimensionados onde nunca há congestionamento — um luxo raro na maioria das organizações.

O modelo IntServ (Integrated Services) é baseado no protocolo RSVP (Resource Reservation Protocol). Nele, as aplicações sinalizam à rede suas necessidades de banda e latência antes de iniciarem o fluxo, e os roteadores ao longo do caminho reservam recursos — ou rejeitam a requisição se não houver capacidade. O IntServ oferece garantias fim a fim, mas seu calcanhar de Aquiles é a escalabilidade: cada fluxo exige estado nos roteadores intermediários, o que é inviável no núcleo da Internet ou em backbones de grande porte. No Cisco IOS, o IntServ é configurado via ip rsvp bandwidth e é comumente associado a aplicações legadas ou ambientes MPLS-TE. Nesta aula, focaremos no modelo que realmente domina o mercado atual: DiffServ.

O DiffServ (Differentiated Services) é o padrão de fato para QoS empresarial e de provedores. Em vez de sinalização por fluxo, ele utiliza os 6 bits do campo DSCP (Differentiated Services Code Point) no cabeçalho IP para classificar cada pacote em uma classe de serviço — uma abordagem stateless e altamente escalável. O DiffServ define PHBs (Per-Hop Behaviors) padronizados, como EF (Expedited Forwarding — DSCP 46) para tráfego de baixa latência, AFxy (Assured Forwarding — DSCP 10 a 38) para tráfego com garantia de entrega, e BE (Best-Effort — DSCP 0) para tráfego sem prioridade. O Cisco IOS implementa DiffServ nativamente via MQC, e é justamente nesse modelo que concentraremos nossos laboratórios.

Passo a Passo — Implementando QoS com MQC (Modular QoS CLI)

O MQC é o framework que transforma a teoria do DiffServ em comandos concretos no Cisco IOS. Ele se estrutura em três componentes sequenciais: class-map (o quê classificar), policy-map (o que fazer com cada classe) e service-policy (onde aplicar a política). Essa modularidade permite que você reutilize classes em diferentes políticas e aplique políticas distintas nas direções de entrada (ingress) ou saída (egress) de qualquer interface. Nosso laboratório prático simulará um cenário realista: um link WAN de 2 Mbps entre dois roteadores, onde trafegam simultaneamente chamadas VoIP (RTP), tráfego de gestão (SSH/SNMP) e dados de usuários (HTTP, FTP). O objetivo é garantir que a voz nunca sofra com latência ou descarte, que o tráfego de gestão tenha banda mínima assegurada e que os dados disputem o restante de forma justa, com descarte preventivo via WRED.

1. Acesse o modo EXEC privilegiado e entre no modo de configuração global:

   R1> enable
   R1# configure terminal
   Enter configuration commands, one per line. End with CNTL/Z.
   R1(config)#

2. Defina a topologia IP base: Interface GigabitEthernet0/0 voltada para a LAN e Serial0/0 para o link WAN. Aplique os endereços e verifique conectividade básica.

   R1(config)# interface GigabitEthernet0/0
   R1(config-if)# ip address 192.168.1.1 255.255.255.0
   R1(config-if)# no shutdown
   R1(config-if)# exit
   R1(config)# interface Serial0/0
   R1(config-if)# ip address 10.0.0.1 255.255.255.252
   R1(config-if)# clock rate 2000000
   R1(config-if)# no shutdown
   R1(config-if)# exit
   R1(config)# ip route 0.0.0.0 0.0.0.0 Serial0/0

   O comando clock rate 2000000 configura a taxa do clock no lado DCE do link serial para 2 Mbps — valor que forçará congestionamento nos testes. Note que o clock rate só é necessário no roteador que possui o cabo DCE conectado. Em nossos laboratórios na JRT Technology Solutions, sempre validamos a conectividade com ping antes de aplicar QoS.

3. Crie as ACLs que servirão como critérios de classificação:

   R1(config)# access-list 100 permit udp any any range 16384 32767
   R1(config)# access-list 101 permit tcp any any eq 22
   R1(config)# access-list 101 permit udp any any eq 161
   R1(config)# access-list 102 permit ip any any

   A ACL 100 captura tráfego RTP (voz) que, por convenção, utiliza portas UDP no intervalo 16384-32767. A ACL 101 identifica tráfego de gestão (SSH na porta TCP 22 e SNMP na UDP 161). A ACL 102 é um “catch-all” para todo o restante. ACLs são apenas um dos mecanismos de classificação — o MQC também suporta match dscp, match cos, match precedence e match protocol, que exploraremos adiante.

4. Construa os class-maps que darão nomes às classes de tráfego:

   R1(config)# class-map match-all VOZ
   R1(config-cmap)# description Classe para trafego de voz RTP
   R1(config-cmap)# match access-group 100
   R1(config-cmap)# exit
   R1(config)# class-map match-all GESTAO
   R1(config-cmap)# description Classe para trafego de gestao SSH/SNMP
   R1(config-cmap)# match access-group 101
   R1(config-cmap)# exit
   R1(config)# class-map match-any DADOS
   R1(config-cmap)# description Classe para todo o trafego restante
   R1(config-cmap)# match access-group 102
   R1(config-cmap)# exit

   Utilizamos match-all para VOZ e GESTAO porque queremos que todos os critérios (no caso, apenas um) sejam satisfeitos. Para DADOS, usamos match-any para garantir flexibilidade futura. O comando description é opcional, mas extremamente recomendado — em ambientes de produção, documentar cada classe evita confusões e erros de troubleshooting.

5. Crie as classes de filho (child policies) para controle granular dentro da classe DADOS:

   R1(config)# class-map match-all DADOS_PREMIUM
   R1(config-cmap)# match dscp af21
   R1(config-cmap)# exit
   R1(config)# class-map match-all DADOS_BULK
   R1(config-cmap)# match dscp af11
   R1(config-cmap)# exit

   Aqui introduzimos classificação por DSCP. Em uma arquitetura DiffServ real, os pacotes já chegam marcados de switches ou endpoints confiáveis. Utilizaremos marcação AF21 (DSCP 18) para dados premium e AF11 (DSCP 10) para dados bulk. Isso demonstra como a marcação upstream simplifica a classificação nos roteadores intermediários.

6. Monte o policy-map principal que definirá as ações de QoS:

   R1(config)# policy-map QOS_LAB
   R1(config-pmap)# description Politica de QoS para link WAN de 2 Mbps
   R1(config-pmap)# class VOZ
   R1(config-pmap-c)# priority percent 30
   R1(config-pmap-c)# set dscp ef
   R1(config-pmap-c)# exit
   R1(config-pmap)# class GESTAO
   R1(config-pmap-c)# bandwidth percent 10
   R1(config-pmap-c)# set dscp cs2
   R1(config-pmap-c)# random-detect
   R1(config-pmap-c)# exit
   R1(config-pmap)# class DADOS
   R1(config-pmap-c)# bandwidth percent 60
   R1(config-pmap-c)# random-detect
   R1(config-pmap-c)# service-policy DADOS_CHILD
   R1(config-pmap-c)# exit
   R1(config-pmap)# class class-default
   R1(config-pmap-c)# fair-queue
   R1(config-pmap-c)# random-detect
   R1(config-pmap-c)# exit

   Este bloco merece atenção minuciosa. priority percent 30 na classe VOZ cria uma fila LLQ (Low Latency Queueing), que garante 30% da banda (600 kbps) com prioridade absoluta — os pacotes são transmitidos antes de qualquer outra fila. A LLQ possui um policiador implícito: se o tráfego de voz exceder 30%, será descartado para proteger as demais classes. set dscp ef marca (ou remarca) os pacotes com DSCP EF (46), garantindo que o próximo roteador no caminho reconheça a prioridade. A classe GESTAO recebe 10% de banda garantida via bandwidth percent 10 (CBWFQ) e marcação CS2 (DSCP 16). A classe DADOS obtém 60% de banda mínima garantida, com random-detect (WRED) para descarte precoce e prevenção de congestionamento, além de uma política filha aninhada. A classe class-default (implícita, não explicitamente criada) captura qualquer tráfego não classificado e aplica fair-queue (WFQ) com WRED.

7. Construa a política filha DADOS_CHILD para refinamento interno da classe de dados:

   R1(config)# policy-map DADOS_CHILD
   R1(config-pmap)# class DADOS_PREMIUM
   R1(config-pmap-c)# bandwidth percent 70
   R1(config-pmap-c)# random-detect dscp-based
   R1(config-pmap-c)# exit
   R1(config-pmap)# class DADOS_BULK
   R1(config-pmap-c)# bandwidth percent 30
   R1(config-pmap-c)# random-detect dscp-based
   R1(config-pmap-c)# exit

   A política filha divide a banda alocada para DADOS (60% do link) entre premium (70% de 60% = 42% do total) e bulk (30% de 60% = 18% do total). O parâmetro dscp-based no random-detect habilita o WRED com perfis de descarte diferenciados por valor DSCP — pacotes AF21 terão menor probabilidade de descarte que AF11 quando a fila começar a encher. Essa é uma técnica avançada que exploramos rotineiramente na implementação de QoS para clientes corporativos da JRT Technology Solutions.

8. Aplique a política de serviço na interface de saída (egress) do link WAN:

   R1(config)# interface Serial0/0
   R1(config-if)# service-policy output QOS_LAB
   R1(config-if)# exit
   R1(config)# end
   R1#

   Políticas de enfileiramento (queueing) são aplicadas sempre na direção output. A direção input suporta apenas policiamento e marcação, mas não filas — o buffer de transmissão existe apenas no lado de saída da interface. Aplicar service-policy output em Serial0/0 garante que todo o tráfego que deixa R1 em direção a R2 seja submetido à política QOS_LAB. Se você tiver múltiplas interfaces WAN, a política pode ser replicada consistentemente.

Configuração Detalhada — Arquivo de Running-Config Completo com Comentários

Apresentamos abaixo o conteúdo completo da configuração final do roteador R1, extraído via show running-config e anotado linha a linha. Utilizamos este formato exato em nossas documentações de projeto na JRT Technology Solutions para garantir que qualquer engenheiro possa reproduzir o ambiente sem ambiguidade. Estude cada seção com calma — a interação entre class-maps, policy-maps aninhados e service-policies é o coração do QoS no Cisco IOS.

! Configuracao de QoS - Aula 18 - Roteador R1
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
! --- Interfaces de rede ---
interface GigabitEthernet0/0
 ip address 192.168.1.1 255.255.255.0
 no shutdown
!
interface Serial0/0
 ip address 10.0.0.1 255.255.255.252
 clock rate 2000000
 service-policy output QOS_LAB  ! Aplica a politica de QoS no sentido de saida
 no shutdown
!
! --- Roteamento estatico simples ---
ip route 0.0.0.0 0.0.0.0 Serial0/0
!
! --- ACLs para classificacao de trafego ---
access-list 100 permit udp any any range 16384 32767    ! Trafego de voz RTP
access-list 101 permit tcp any any eq 22                ! SSH
access-list 101 permit udp any any eq 161               ! SNMP
access-list 102 permit ip any any                       ! Demais dados
!
! --- Class-maps: definicao das classes de trafego ---
class-map match-all VOZ
 description Classe para trafego de voz RTP
 match access-group 100
!
class-map match-all GESTAO
 description Classe para trafego de gestao SSH/SNMP
 match access-group 101
!
class-map match-any DADOS
 description Classe para todo o trafego restante
 match access-group 102
!
class-map match-all DADOS_PREMIUM
 match dscp af21
!
class-map match-all DADOS_BULK
 match dscp af11
!
! --- Policy-map filho (child) para subdivisao da classe DADOS ---
policy-map DADOS_CHILD
 class DADOS_PREMIUM
  bandwidth percent 70
  random-detect dscp-based
 class DADOS_BULK
  bandwidth percent 30
  random-detect dscp-based
!
! --- Policy-map principal (parent) ---
policy-map QOS_LAB
 description Politica de QoS para link WAN de 2 Mbps
 class VOZ
  priority percent 30           ! LLQ – 600 kbps com prioridade absoluta
  set dscp ef                   ! Marca com DSCP EF (46)
 class GESTAO
  bandwidth percent 10          ! CBWFQ – 200 kbps garantidos
  set dscp cs2                  ! Marca com DSCP CS2 (16)
  random-detect                 ! WRED ativado
 class DADOS
  bandwidth percent 60          ! CBWFQ – 1200 kbps garantidos
  random-detect                 ! WRED ativado
  service-policy DADOS_CHILD    ! Politica aninhada para subclasses
 class class-default
  fair-queue                    ! WFQ para trafego nao classificado
  random-detect                 ! WRED ativado
!
end

Verificando a Instalação / Testando a Configuração

Nenhuma implementação de QoS está completa sem uma bateria de testes de verificação. Em campo, frequentemente encontramos políticas que “existem na configuração” mas não surtem efeito — seja por aplicação na interface errada, direção incorreta ou class-maps que não batem com o tráfego real. Nesta seção, executaremos comandos de diagnóstico que mostrarão exatamente como sua política está operando e se os pacotes estão sendo classificados e priorizados conforme o planejado. Execute cada comando no seu ambiente e compare as saídas com as apresentadas abaixo.

Começaremos inspecionando a política aplicada à interface com show policy-map interface. Este comando é o “canivete suíço” da verificação de QoS: ele exibe contadores de pacotes e bytes por classe, taxas de descarte, estado das filas e, quando ativado, estatísticas de WRED. Em seguida, utilizaremos show class-map e show policy-map para validar a estrutura sem a necessidade de tráfego real. Por fim, geraremos tráfego controlado com extensões de ping e analisaremos os contadores para confirmar a classificação.

R1# show policy-map interface Serial0/0
  Service-policy output: QOS_LAB

    Class-map: VOZ (match-all)
      1523 packets, 304600 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 100
      Priority: 30% (600 kbps), burst bytes 15000, b/w exceed drops: 0
      QoS Set
        dscp ef
          Marker statistics: Disabled

    Class-map: GESTAO (match-all)
      847 packets, 123456 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 101
      Bandwidth: 10% (200 kbps)
      QoS Set
        dscp cs2
          Marker statistics: Disabled
      random-detect:
        Exp-weight-constant: 9 (1/512)
        Mean queue depth: 0 packets
        Class     Random drop       Tail drop      Minimum        Maximum     Mark
                        pkts/bytes      pkts/bytes   threshold      threshold  prob
        dscp cs2           0/0               0/0         24             40  1/10

    Class-map: DADOS (match-any)
      5201 packets, 8123456 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
      Bandwidth: 60% (1200 kbps)
      random-detect:
        Service-policy: DADOS_CHILD
          Class-map: DADOS_PREMIUM (match-all)
            0 packets, 0 bytes
            5 minute offered rate 0 bps, drop rate 0 bps
            Match: dscp af21 (18)
            Bandwidth: 70% (840 kbps)
            random-detect dscp-based:
          Class-map: DADOS_BULK (match-all)
            0 packets, 0 bytes
            5 minute offered rate 0 bps, drop rate 0 bps
            Match: dscp af11 (10)
            Bandwidth: 30% (360 kbps)
            random-detect dscp-based:

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: any
      Flow Based Fair Queueing
      Maximum Number of Hashed Queues 256
      random-detect:

R1# show class-map
 Class Map match-all VOZ (id 1)
   Description: Classe para trafego de voz RTP
   Match access-group 100

 Class Map match-all GESTAO (id 2)
   Description: Classe para trafego de gestao SSH/SNMP
   Match access-group 101

 Class Map match-any DADOS (id 3)
   Description: Classe para todo o trafego restante
   Match access-group 102

 Class Map match-all DADOS_PREMIUM (id 4)
   Match dscp af21 (18)

 Class Map match-all DADOS_BULK (id 5)
   Match dscp af11 (10)

 Class Map match-all class-default (id 0)
   Match any

Para gerar tráfego de teste e ver os contadores se movimentarem, utilize o ping com as opções size, repeat e timeout, ou, preferencialmente, uma ferramenta como iperf3. No exemplo abaixo, disparamos tráfego IP com tamanho de pacote próximo ao de quadros de voz e observamos a classe VOZ incrementar. Lembre-se de que o ping por padrão utiliza ICMP, que não é capturado pela ACL 100 — você precisará simular tráfego UDP nas portas corretas. Em nossos treinamentos na JRT Technology Solutions, utilizamos scripts Python simples que injetam pacotes UDP com payload de voz, mas para simplificar, podemos testar a classe GESTAO via SSH.

R1# telnet 192.168.1.10 22 /source-interface GigabitEthernet0/0
! Apos algumas tentativas de conexao, verifique novamente os contadores:
R1# show policy-map interface Serial0/0 | section GESTAO
    Class-map: GESTAO (match-all)
      912 packets, 133456 bytes
      5 minute offered rate 2000 bps, drop rate 0 bps

Outro comando poderoso e frequentemente subutilizado é o show interfaces queueing, que revela a estratégia de enfileiramento atualmente ativa em cada interface. Com a política aplicada, você verá que a interface Serial0/0 não está mais em FIFO, mas sim utilizando uma lógica complexa de filas múltiplas com prioridades e bandas garantidas. Essa transição é a prova definitiva de que seu QoS está no controle.

R1# show interfaces Serial0/0 queueing
Interface Serial0/0 queueing strategy: priority, bandwidth, fair-queue
  Total output drops per queue:
    Queue 1 (VOZ): 0
    Queue 2 (GESTAO): 0
    Queue 3 (DADOS): 0
    Queue 4 (class-default): 0

Erros Comuns e Como Resolver

Implementar QoS no Cisco IOS é como calibrar um instrumento de precisão: pequenos desalinhos produzem grandes distorções. Nesta seção, destilamos os quatro erros mais frequentes que encontramos em campo — inclusive em clientes que nos procuraram na JRT Technology Solutions após tentativas frustradas de configuração autônoma. Para cada erro, você terá o sintoma exato, a causa raiz e a solução completa, pronta para ser aplicada imediatamente. Mantenha esta seção como referência de troubleshooting rápido.

• Erro 1: Política aplicada, mas nenhum pacote é classificado (contadores zerados).

  Sintoma: Ao executar show policy-map interface, todos os contadores de classe permanecem em zero, mesmo com tráfego fluindo pela interface. Causa provável: As ACLs de classificação não correspondem ao tráfego real — seja por endereços IP incorretos, portas erradas ou máscaras invertidas. Outro motivo comum é a aplicação da política na direção errada (input em vez de output). Solução: Utilize show access-lists para verificar se os hits nas ACLs estão aumentando. Se não estiverem, revise as regras. Gere tráfego de teste que coincida exatamente com a ACL (ex.: iperf -u -c <destino> -p 16500). Verifique também a direção da política — para queueing, deve ser sempre output.

• Erro 2: “Priority queue not allowed with bandwidth statement” ou erro similar ao aplicar o policy-map.

  Sintoma: O IOS rejeita sua configuração com mensagens conflitantes sobre comandos incompatíveis. Causa provável: Você misturou comandos de alocação de banda que são mutuamente exclusivos em uma mesma policy-map sem respeitar a hierarquia correta. Por exemplo, priority e bandwidth não podem coexistir em uma política plana sem uma política filha. Solução: Sempre isole a classe que receberá priority em uma política separada ou garanta que as demais classes usem bandwidth, nunca priority em múltiplas classes no mesmo nível. Se precisar de múltiplas filas de prioridade, utilize uma política hierárquica (parent-child).

• Erro 3: Voz entrecortada mesmo com LLQ configurada — jitter e perda de pacotes na classe de voz.

  Sintoma: Os contadores mostram pacotes na classe VOZ, mas ainda há drops na fila de prioridade ou latência excessiva. Causa provável: O tráfego de voz real está excedendo o percentual alocado para priority. A LLQ possui um policiador implícito que descarta impiedosamente o excedente. Se seu pico de voz ultrapassa 30% do link, os pacotes excedentes são dropados, causando falhas na comunicação. Solução: Monitore a taxa de oferta (offered rate) na classe VOZ com show policy-map interface em horários de pico. Se estiver consistentemente no limite, aumente o percentual alocado para priority (ex.: priority percent 40) ou reavalie o codec de voz utilizado (G.711 vs G.729). Em nossos projetos na JRT Technology Solutions, sempre dimensionamos a LLQ com 20% de folga sobre o pico teórico de voz.

• Erro 4: WRED não está descartando pacotes preventivamente e ocorrem tail-drops em rajada.

  Sintoma: Apesar de random-detect estar configurado, você observa tail-drops nas filas durante congestionamento, sem drops de WRED. Causa provável: Os limiares mínimo e máximo do WRED podem estar mal dimensionados para o tamanho de buffer da interface, fazendo com que a fila atinja o limite máximo antes que o algoritmo comece a descartar. Além disso, WRED padrão (sem dscp-based) trata todos os pacotes igualmente, o que pode não ser adequado para cenários com múltiplas classes de serviço. Solução: Ajuste os limiares com o comando random-detect precedence <prec> <min> <max> <prob> dentro do policy-map, com base no tamanho médio da fila da interface. Habilite random-detect dscp-based para perfis diferenciados. Utilize show policy-map interface para comparar “random drop” versus “tail drop”.

Boas Práticas e Dicas Avançadas

O sucesso de uma implementação de QoS não se mede apenas pela ausência de erros de configuração, mas pela aderência a um conjunto de boas práticas que tornam a política sustentável, escalável e compreensível para toda a equipe. Em nossa consultoria na JRT Technology Solutions, insistimos em três pilares: documentação, consistência e monitoramento contínuo. Documente cada class-map e policy-map com description significativas — o engenheiro do plantão noturno agradecerá. Mantenha consistência nas marcações DSCP ao longo de toda a rede; se um switch marca DSCP AF31 na borda, seu roteador central deve reconhecer e confiar nessa marca, ou reclassificar explicitamente. E monitore proativamente os contadores de QoS via SNMP ou NetFlow — políticas que funcionam hoje podem se tornar ineficazes amanhã com a mudança do perfil de tráfego.

Uma técnica avançada que merece menção é o hierarchical QoS (HQoS), onde uma política pai define limites agregados para um conjunto de clientes e políticas filhas individuais refinam a distribuição dentro de cada cliente. O HQoS é amplamente utilizado em cenários de provedores de serviço e grandes empresas, e o Cisco IOS o suporta até três níveis de aninhamento. Outra dica valiosa: utilize AutoQoS — um recurso do IOS que gera automaticamente configurações de QoS baseadas em melhores práticas da Cisco para cenários típicos de VoIP — como ponto de partida. O comando auto qos voip trust na interface de uplink pode economizar horas de configuração manual. No entanto, recomendamos fortemente que você ajuste o template gerado pelo AutoQoS com base no perfil real de tráfego da sua organização.

Para ambientes de missão crítica, considere implementar NBAR (Network-Based Application Recognition) como mecanismo de classificação complementar às ACLs. O NBAR permite classificar tráfego por assinatura de aplicação — por exemplo, match protocol rtp