Cisco 300-410: Qualidade de Serviço e Proteção do Plano de Controle — Guia de estudos

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Faz parte do Cisco CCNP Enterprise 300-410 ENARSI — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A Qualidade de Serviço (QoS) e a Proteção do Plano de Controle (CoPP/CPPr) garantem em conjunto que as aplicações críticas para o negócio e a própria rede permaneçam estáveis sob carga e ataque. O QoS diferencia o tráfego, prioriza fluxos sensíveis ao atraso e gerencia o congestionamento em links escassos. O CoPP/CPPr protege a CPU do roteador e a pilha de gerenciamento contra sobrecarga acidental e eventos maliciosos. Um projeto correto depende de marcação consistente de ponta a ponta, limites de confiança disciplinados, condicionamento apropriado (policiamento/modelagem), filas bem dimensionadas, prevenção proativa de congestionamento, tratamento cuidadoso de túneis/criptografia e validação contínua usando contadores correlacionados com o comportamento da aplicação.

Classificação, Confiança e Marcação de Ponta a Ponta

A classificação e a marcação do tráfego determinam como os pacotes serão enfileirados e potencialmente descartados em cada salto (hop).

• Classificação e correspondência
  • Faça a correspondência com base em access-lists, DSCP/precedência IP, CoS (802.1p), assinaturas de aplicação NBAR ou cabeçalhos internos de túneis (com

undefined

).

• Mantenha o determinismo: faça a correspondência com campos da Camada 3/4 sempre que possível; use o NBAR apenas quando necessário devido às implicações de CPU em algumas plataformas.

• Limites de confiança

  • Defina onde a rede aceita as marcações existentes. Típico: não confie em hosts finais; confie em telefones corporativos e uplinks para domínios de QoS conhecidos.
  • Na borda, remarque o tráfego não confiável para valores DSCP definidos pela política; confie apenas nos dispositivos que você gerencia e autentica.
  • Em portas de switch voltadas para endpoints, remova a confiança (

undefined

) a menos que você verifique explicitamente o tipo de dispositivo.

• Marcação

  • O DSCP (6 bits) é a principal marcação de ponta a ponta em redes IP. A precedência IP (3 bits) é legada e mapeia para os bits superiores do DSCP.
  • O CoS (802.1p, 3 bits) marca frames da Camada 2 em troncos de VLAN; mapeie DSCP↔CoS de forma consistente nos limites L2/L3.
  • Em cores MPLS, a Classe de Tráfego (TC, anteriormente EXP) de 3 bits transporta o QoS; mapeie DSCP para TC na entrada (ingress) e TC de volta para DSCP na saída (egress) para preservar a semântica através do core VPN ou TE.

• Consistência da marcação

  • Reserve EF para o tráfego de voz (bearer, baixo jitter), CS3/AF31/AF32 para sinalização de chamada, AF4x para vídeo interativo, AF2x/AF1x para dados críticos, CS0/BE para melhor esforço (best effort) e CS1 para scavenger.
  • Documente uma política de QoS corporativa única; garanta que os provedores de WAN a respeitem e mapeiem conforme contratado.
  • Evite remarcar no meio do caminho, a menos que esteja traduzindo entre domínios; caso contrário, você corre o risco de inversão de prioridade e complexidade no troubleshooting.

Exemplo (marcação na borda de entrada):

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Modos de falha e trade-offs:

• Confiar na borda errada leva ao abuso de prioridade; fluxos de baixo valor podem privar (starve) as filas críticas.
• Mapeamentos inconsistentes de DSCP↔CoS quebram o QoS nas transições L2/L3.
• O uso excessivo de NBAR em plataformas de software pode elevar o uso da CPU; prefira correspondências estáticas.

Condicionamento, Enfileiramento e Prevenção de Congestionamento

O condicionamento de tráfego modela o tráfego para taxas que a rede pode sustentar e aplica policiamento onde limites rígidos são necessários.

• Policiamento vs. modelagem (shaping)

  • O policiamento (policing) impõe uma taxa usando token buckets; o excesso é descartado ou opcionalmente remarcado. Ele preserva a capacidade do link, mas aumenta a perda e pode acionar o recuo do TCP (TCP backoff) e novas tentativas da aplicação.
  • A modelagem (shaping) armazena em buffer e libera pacotes a uma taxa alvo (normalmente para um CIR da operadora), suavizando rajadas (bursts) e reduzindo descartes downstream; isso adiciona atraso e jitter proporcionais à profundidade da fila.

• Parâmetros de rajada (burst)

  • Policers de taxa única e dois parâmetros usam a taxa de informação comprometida (CIR) com rajada comprometida (Bc) e, opcionalmente, Be (rajada em excesso).
  • Um Bc muito pequeno em relação ao RTT e MTU causa descartes no nível de fragmentação e throughput ineficaz; dimensione o Bc para pelo menos 1–2 vezes o produto largura de banda-atraso para shaping, e vários MTUs para policing.

• CBWFQ e LLQ

  • O Class-Based Weighted Fair Queuing (CBWFQ) garante uma largura de banda mínima para as classes. Configure a largura de banda em kbps ou percentual sob o comando de shape.
  • A Fila de Baixa Latência (LLQ) adiciona serviço de prioridade estrita a uma classe (

undefined

), policiada na taxa configurada para evitar privação (starvation). Apenas o tráfego de voz/vídeo em tempo real (bearer) deve estar na LLQ.

• Os limites de fila (

undefined

) definem o máximo de pacotes em buffer por classe; um valor muito alto aumenta a latência, um valor muito baixo aumenta os descartes. Equilibre com a tolerância da aplicação.

• WRED vs. tail drop
  • O descarte no final da fila (tail drop) descarta pacotes somente quando as filas estão cheias; isso pode causar sincronização global de TCP e grandes oscilações.
  • O Weighted Random Early Detection (WRED) inicia descartes probabilísticos antes que a fila esteja cheia; o WRED baseado em DSCP permite que classes de maior prioridade tolerem filas mais profundas com menor probabilidade de descarte antecipado.
  • O WRED beneficia fluxos TCP; para tráfego predominantemente UDP (voz), ele adiciona perda sem o benefício do recuo (backoff). Não habilite o WRED na LLQ.

Exemplo (shaping pai com CBWFQ/LLQ e WRED filho):

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Pontos chave do projeto:

• Sempre aplique o shaping para o menor gargalo downstream que você controla; deixe seu enfileiramento decidir, não o mecanismo de descarte do provedor.
• Dimensione a LLQ com base no codec e no volume de chamadas; inclua de 5 a 10% de overhead para cabeçalhos e variabilidade do VAD.
• Habilite o WRED apenas onde fluxos TCP multiplexados dominam; ajuste os pesos de forma conservadora para evitar descartes prematuros.

QoS em Túneis e Links WAN

Túneis e criptografia ocultam os cabeçalhos internos e alteram o MTU, afetando a classificação e a fragmentação.

• GRE/DMVPN e IPsec

  • Sem um tratamento especial, a classificação enxerga apenas os cabeçalhos externos. Use qos pre-classify nas interfaces de túnel para que o dispositivo classifique com base na 5-tupla e no DSCP internos antes do encapsulamento/criptografia.
  • Preserve ou copie o DSCP para o cabeçalho externo para manter o comportamento de QoS da rede durante o trânsito.
  • Ajuste o MTU e o MSS para evitar fragmentação e falhas de PMTUD; para IPsec, a fragmentação pós-criptografia (fragmentation after-encryption) pode ser necessária em certas plataformas e operadoras.

• QoS por túnel e design hierárquico

  • Em mGRE/DMVPN, aplique QoS hierárquico (shape por túnel e, em seguida, LLQ/CBWFQ por classe) para garantir o compartilhamento justo entre os spokes.
  • Quando os circuitos da provedora impõem um CIR com policers rigorosos, aplique o shaping no valor do CIR ou um pouco abaixo para evitar os tail drops da provedora.

Exemplo (QoS em túnel hub/spoke de DMVPN): interface Tunnel30 ip address 10.0.30.1 255.255.255.0 tunnel mode gre multipoint qos pre-classify ip mtu 1400 ip tcp adjust-mss 1360 service-policy output PM-WAN-PARENT ! crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac crypto ipsec profile DMVPN-PROFILE set transform-set TS ! ! Dependente da plataforma: crypto ipsec fragmentation after-encryption

Erros comuns e mitigações:

• A falta do qos pre-classify faz com que todo o tráfego caia na class-default após a criptografia, prejudicando os fluxos de tempo real.
• Um MTU/MSS incorreto causa blackholing de segmentos grandes e desempenho errático das aplicações; valide o path MTU de ponta a ponta.
• Aplicar políticas complexas em line rate em túneis de software pode sobrecarregar a CPU; prefira o hardware offload onde estiver disponível.

Proteção do Control-Plane (CoPP/CPPr) e Validação Operacional

O CoPP protege a CPU do roteador classificando e limitando a taxa (rate-limiting) do tráfego de controle e gerenciamento no caminho do control-plane. O CPPr adiciona uma granularidade mais fina usando subinterfaces de host, transit e CEF-exception.

• Fundamentos do CoPP

  • Anexe as políticas ao control-plane, não às interfaces de dados.
  • Os tipos de correspondência (match) comumente suportados são ip dscp, ip precedence e access-group. Não use a palavra-chave log nas entradas de ACL referenciadas pelo CoPP.
  • Separe os protocolos de roteamento críticos (BGP, OSPF, RSVP/LDP quando aplicável) do gerenciamento de melhor esforço (best-effort) (HTTP) e do tráfego de controle em massa (exportações de NetFlow para a CPU em casos de exceção). Forneça CIRs generosos para os protocolos críticos.

• Detalhes do CPPr

  • control-plane host governa o tráfego terminado no roteador (ex: SSH, SNMP, sessões de roteamento).
  • control-plane transit lida com o tráfego de exceção desviado (punted) do hardware (ex: TTL excedido, MTU excedido).
  • control-plane cef-exception gerencia os desvios (punts) relacionados ao CEF.
  • Aplique políticas diferentes por subinterface para evitar danos colaterais quando uma classe se comporta mal.

• Exemplo de CoPP com exclusões e anexação correta:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

! Garanta que a política esteja no control-plane, e não nas interfaces de dados:

undefined

undefined

Notas:

• Limitar a taxa (rate-limiting) do BGP de forma muito agressiva pode causar a perda de keepalives, reinicializações de sessão e instabilidade de rotas (route churn). Se for necessário aplicar police, defina um CIR suficiente e considere exceed-action transmit para evitar descartes durante picos de tráfego.

• Isente fontes de gerenciamento confiáveis específicas usando deny na ACL antes do permit; aplique a ACL como um match na classe relevante.

• Complementos do management-plane

  • O IPv6 RA Guard bloqueia Router Advertisements maliciosos (rogue) em portas L2, mas não pode proteger quando o RA é tunelado; aplique a proteção nos endpoints do túnel ou use autenticação quando possível.
  • O IPv6 Source Guard usa a tabela de binding para permitir apenas endereços de origem válidos; ele descarta o tráfego de fontes IPv6 desconhecidas/não alocadas em portas de acesso, reduzindo o tráfego de exceção que consome CPU.
  • O hardening do dispositivo (desabilitar serviços não utilizados, usar ACLs nas vty, limitar as comunidades SNMP) reduz a exposição do control-plane.

• Validação e contadores

  • Use

undefined

e

undefined

para verificar a contagem de pacotes, descartes e ações de police. Execute primeiro o

undefined

quando surgirem sintomas de sobrecarga de CPU (ex: SSH lento, SNMP intermitente).

• Em plataformas com encaminhamento por hardware, correlacione com

undefined

ou contadores de ASIC equivalentes para descartes de WRED/tail drops.

• Para filas, verifique a profundidade das filas (queue depths), descartes de tail/WRED e o policiamento da fila de prioridade usando

undefined

e

undefined

.

• Procure por sintomas na aplicação:
  • Jitter na voz, perda de pacotes ou áudio entrecortado sugerem que a LLQ está muito pequena ou que a fronteira de confiança (trust boundary) está incorreta.
  • SSH lento ou com desconexões, mas com pings normais, pode indicar que o CoPP está aplicando policing no tráfego de gerenciamento.
  • SNMP intermitente se correlaciona com descartes na classe de gerenciamento ou desvios (punts) de exceção do CEF excedendo os limites.
  • A queda abrupta da taxa de transferência (throughput) do TCP sob carga com o aumento de descartes WRED é esperada; com apenas tail drop, procure por fluxos sincronizados em padrão dente de serra (sawtooth).

Cenário de Problema Prático

A Acme Engineering opera uma rede DMVPN com um único hub sobre banda larga da Internet com IPsec+mGRE. Os usuários relatam VoIP entrecortado para a matriz (HQ), coletas SNMP intermitentes dos roteadores das filiais e SSH lento ou com desconexões para o hub durante os horários de pico.

1. Estabelecer fronteiras de confiança (trust boundaries) e remarcar na borda

• Justificativa: Telefones e uplinks confiáveis são os únicos dispositivos autorizados a definir EF/CS3; todo o outro tráfego de acesso é remarcado para BE. Isso impede o abuso de prioridade que poderia privar as classes de tempo real de recursos.

2. Implementar QoS hierárquico no túnel DMVPN

• Justificativa: Aplicar um shaper pai ao túnel na taxa medida do provedor (ex: 20 Mbps) para evitar o policing upstream. Sob a política pai, use LLQ para voz EF, classes de largura de banda para vídeo e dados críticos, WRED para classes dominadas por TCP e fair-queue para o padrão. Isso localiza o gerenciamento de congestionamento antes que a operadora descarte os pacotes.

3. Habilitar qos pre-classify e ajustar MTU/MSS

• Justificativa: qos pre-classify garante que a política corresponda ao IP/porta/DSCP internos antes do encapsulamento GRE/IPsec.

undefined

e

undefined

evitam fragmentação/blackholing devido ao overhead do encapsulamento. A fragmentação pós-criptografia (after-encryption fragmentation) é configurada para se adaptar ao comportamento do provedor.

4. Remover o CoPP aplicado na interface e anexá-lo ao control-plane

• Justificativa: O CoPP deve proteger a CPU independentemente da interface de entrada. Desvincule qualquer service-policy de entrada das interfaces físicas e aplique a PM-COPP ao control-plane para governar centralmente o tráfego desviado (punted) e o terminado no host.

5. Criar classes de CoPP distintas com CIRs seguros; isentar fontes confiáveis

• Justificativa: Coloque o BGP em sua própria classe com um CIR suficiente para keepalives e rajadas (bursts); configure conform/exceed transmit para evitar reinicializações de sessão. Aplique police em HTTP/HTTPS com taxas baixas para limitar o gerenciamento web para a CPU. Para exceções de Telnet/SSH, negue os IPs de gerenciamento confiáveis na ACL para que a política não limite a taxa deles, enquanto ainda controla todas as outras fontes.

6. Validar e iterar com base em contadores e sintomas

• Justificativa: Use

undefined

para confirmar que os descartes de gerenciamento estão alinhados com os problemas observados de SSH/SNMP; ajuste os CIRs até que os descartes cessem. Use

undefined

para verificar a utilização da LLQ e garantir que não ocorra policing por estouro de prioridade sob volume normal de chamadas. Monitore os descartes de WRED e tail drops nas classes críticas; se a qualidade da voz permanecer ruim sem descartes na LLQ, aumente ligeiramente a porcentagem da LLQ; se ocorrerem descartes, dimensione a LLQ e o shaper pai com mais precisão para o codec e a largura de banda.

Ao impor uma fronteira de confiança correta, aplicar shaping antes do gargalo, classificar pré-encapsulamento e proteger o control-plane com políticas CoPP/CPPr devidamente dimensionadas, a Acme Engineering restaura a qualidade da voz e estabiliza o acesso de gerenciamento sem sacrificar a taxa de transferência (throughput) geral.

← Roteamento e Distribuição Multicast · Todos os domínios · VPN →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →