Cisco 200-301: Serviços IP, NAT e Qualidade de Serviço — Guia de estudos

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Faz parte do Cisco CCNA 200-301 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

Os serviços de IP unem as redes e as mantêm observáveis, alcançáveis e previsíveis sob carga. Esta seção aborda a entrega de serviços essenciais (DHCP, DNS, NTP), visibilidade e sinalização (SNMP, syslog, NetFlow, telemetria), tradução de endereços (NAT) e tratamento de tráfego (QoS), e então os conecta à redundância de primeiro salto (first-hop redundancy) e à validação operacional. As escolhas de design enfatizam o comportamento determinístico, o privilégio mínimo e a degradação graciosa durante falhas.

Serviços de IP Essenciais: DHCP, DNS e NTP

DHCP

• Componentes e fluxo: Um cliente usa o DORA (Discover, Offer, Request, Acknowledgment). Os pools do servidor (escopos) definem faixas de endereços, máscaras, gateways (Option 3), DNS (Option 6), temporizadores e opções de fornecedor (por exemplo, Option 150 para TFTP para telefones IP).
• Relay: Quando o servidor não está na sub-rede do cliente, uma interface de Camada 3 retransmite broadcasts usando ip helper-address para enviar a solicitação como unicast para o servidor. O DHCP snooping insere a Option 82 (circuit-id/remote-id) para que o servidor possa tomar decisões com base na localização.
• Escopos e exclusões: Crie pools grandes o suficiente para os clientes esperados mais o crescimento. Reserve endereços estáticos por meio de reservas de MAC ou exclua-os da alocação dinâmica com ip dhcp excluded-address.
• Leases: Equilibre a rotatividade (churn) versus a reutilização de endereços; leases mais curtos aceleram a recuperação, mas aumentam o tráfego DHCP.
• Modos de falha comuns:
  • Relay com helper-address ausente/incorreto, ou ACLs bloqueando UDP 67/68.
  • Nenhum escopo correspondente, pool esgotado ou sub-redes sobrepostas.
  • Opção de gateway padrão incorreta causando falhas de alcançabilidade após a inicialização.
  • Configuração incorreta de confiança (trust) no DHCP snooping descartando respostas do servidor.

• Comandos úteis:

undefined

undefined

• Exemplo mínimo de relay:

undefined

DNS

• Fluxo de resolução: Um stub resolver verifica o cache do host e o arquivo hosts, e então consulta um resolvedor recursivo. O servidor recursivo consulta iterativamente os servidores raiz, TLD e autoritativos, armazena as respostas em cache de acordo com o TTL e retorna uma resposta. As falhas podem ser NXDOMAIN (o nome não existe) ou SERVFAIL (problema na resolução).
• Diretrizes de design: Use resolvedores recursivos redundantes; prefira anycast para localidade e disponibilidade; ajuste os TTLs para equilibrar agilidade e eficiência de cache. Aplique listas de permissão (allowlists) de DNS para segmentos sensíveis.
• Modos de falha comuns:
  • UDP/TCP 53 bloqueado ou assimétrico, tratamento de EDNS quebrado ou problemas de MTU/fragmentação.
  • Domínios de busca (search domains) mal configurados causando resolução de FQDN incorreta.
  • Cache obsoleto/envenenado (poisoned); falha na validação do DNSSEC.
• Configuração básica do dispositivo:

undefined

.

NTP

• A sincronização de tempo permite a correlação (logs, fluxos, segurança) e a medição precisa de atraso/jitter. A hierarquia usa valores de stratum (1 está diretamente conectado a um relógio de referência; 16 não está sincronizado).
• Clientes, servidores e peers formam uma árvore de tempo estável; autentique o NTP com chaves para evitar spoofing.
• IP SLA e jitter: A sincronização de tempo precisa (por exemplo, com NTP) é necessária ao medir o atraso unidirecional (one-way delay) e para garantir cálculos de jitter válidos entre os nós.
• Modos de falha comuns: Servidores inalcançáveis, caminhos/distorção (skew) assimétricos, confusão de fuso horário/horário de verão ou servidores não autenticados aceitos inadvertidamente.

• Comandos úteis:

undefined

undefined

Visibilidade e Controle: SNMP, Syslog, NetFlow e Telemetria

SNMP

• Versões: v2c (baseado em community) vs v3 (autenticação/privacidade). Prefira v3 com authPriv para integridade e confidencialidade.
• Polling vs traps/informs: Faça polling para métricas regulares; envie traps/informs em mudanças de estado. Informs incluem confiabilidade por meio de confirmação (acknowledgment).
• Segurança e escala: Restrinja os gerenciadores por ACLs; limite a taxa (rate-limit) de traps; minimize OIDs custosos; evite os padrões public/community.

Syslog

• Níveis: 0 emergency, 1 alert, 2 critical, 3 error, 4 warning, 5 notice, 6 informational, 7 debugging.
• Habilite timestamps e números de sequência; envie para coletores redundantes; defina facility/nível por recurso para evitar ruído.

• Exemplo:

undefined

undefined

undefined

NetFlow

• Captura metadados de conversação (5-tupla, contadores, timestamps). A v5 é fixa; v9/IPFIX são baseados em templates e extensíveis.
• Design: Exporte para pelo menos dois coletores; use amostragem (sample) conforme necessário para reduzir o uso de CPU; garanta a sincronização de tempo (NTP) para análises precisas.

• Exemplo clássico:

undefined

undefined

undefined

Telemetria orientada a modelos (Model-driven telemetry)

• Streaming baseado em push de dados selecionados modelados em YANG por meio de transportes eficientes (por exemplo, gRPC). Benefícios: menor latência, uso de CPU previsível e melhor escalabilidade do que o polling SNMP periódico.
• Trade-offs: Requer coletores que entendam os modelos; segurança de transporte e QoS para o próprio stream.

Modos de falha e mitigações comuns

• Logging ou polling excessivo causando picos de CPU: ajuste os níveis, agrupe em lote (batch) ou use amostragem (sample).
• Desvio de tempo (Time drift): Corrija o NTP para evitar eventos fora de ordem e má correlação de fluxos (flow stitching).
• Firewall/ACLs bloqueando o plano de gerenciamento: dedique um gerenciamento fora de banda (OOB) ou VRF, e use policiamento do plano de controle (control plane policing).

NAT e Tradução de Endereços

Conceitos

• Terminologia:
  • Inside local: Endereço privado original.
  • Inside global: Endereço traduzido visível externamente.
  • Outside local/global: Endereço do host externo como visto de dentro/fora.
• Tipos:
  • NAT Estático (Static NAT): Mapeamento fixo um-para-um; alcançabilidade de entrada (inbound) estável.
  • NAT Dinâmico (Dynamic NAT): Muitos-para-muitos através de um pool; apenas para saída (outbound) até que uma tradução seja alocada.
  • PAT (overload): Muitos-para-um ou muitos-para-poucos usando portas TCP/UDP; o mais comum para egresso de Internet.

Raciocínio de design e trade-offs

• NAT estático para servidores que precisam de acesso de entrada; PAT para clientes para economizar IPs públicos.
• O NAT quebra a transparência ponta a ponta (end-to-end); alguns protocolos exigem ALGs (FTP, SIP). Prefira o reconhecimento de aplicação (application-awareness) nas bordas ou use protocolos tolerantes à tradução.
• Alta disponibilidade (High availability): O FHRP move o gateway padrão, mas o estado do NAT é por dispositivo; sem NAT com estado (stateful NAT), o failover reinicia os fluxos. Coloque o NAT em firewalls/roteadores de HA que suportem replicação de estado ou direcione o egresso de forma determinística.

Exemplos de configuração

• PAT usando a interface WAN:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

• NAT estático para um servidor:

undefined

Verificação e solução de problemas

undefined

,

undefined

undefined

• Problemas comuns: Falta de ‘inside’/‘outside’ nas interfaces, ausência de rota para o pool, pools sobrepostos, ACL incompatível (mismatch), esgotamento de portas no PAT, roteamento assimétrico por múltiplas saídas ou necessidades de hairpinning não atendidas.

Fundamentos de QoS: Classificação, Marcação, Enfileiramento e Gerenciamento de Congestionamento

Classificação e marcação

• Classifique por ACLs, IP precedence/DSCP, CoS ou NBAR. Marque na borda; preserve as marcações onde houver confiança.
• DSCP e CoS:
  • DSCP EF (46) para o tráfego de voz (bearer); CS3/AF31–AF33 para sinalização; AF41–AF43/CS4 para vídeo interativo.
  • Valores de CoS em troncos 802.1Q exigem mapeamento para DSCP nas fronteiras L3.
• Fronteiras de confiança (Trust boundaries):

  • Confie apenas em dispositivos que podem ser responsabilizados (por exemplo, um telefone IP da Cisco). Em uma porta de acesso com um telefone, use a confiança baseada no dispositivo e preserve as prioridades downstream:

undefined

-

undefined

undefined

undefined

undefined

Enfileiramento e gerenciamento de congestionamento

• CBWFQ: Agendamento ponderado por garantias de largura de banda.
• LLQ: Adiciona uma fila de prioridade estrita (strict-priority) ao CBWFQ para classes sensíveis à latência (voz, vídeo interativo).
• PQ: Prioridade estrita pura; pode privar outro tráfego de recursos (starve) se não for policiado. O LLQ é preferível porque policia o tráfego prioritário por design.
• WRED: Descarte aleatório antecipado para evitar a sincronização global do TCP; não aplique a filas de prioridade.

Policiamento (Policing) e Modelagem (Shaping)

• Policing: Impõe uma taxa descartando/remarcando o excesso; baixo atraso, mas aumenta a perda e o jitter.
• Shaping: Armazena rajadas (bursts) em buffer para se ajustar a uma taxa especificada; adiciona atraso, mas reduz os descartes downstream. Aplique o shaping em links de egresso mais lentos antes de políticas hierárquicas.

• Exemplo de política LLQ:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

Metas para voz e vídeo

• Voz: Atraso unidirecional <150 ms, jitter <30 ms, perda <1%. Use LLQ para o tráfego principal (bearers), proteja a sinalização separadamente.
• Vídeo: Vídeo interativo precisa de controle de largura de banda e jitter; o streaming é mais tolerante a perdas, mas consome muita largura de banda. Considere filas separadas e controle de admissão.

Validação e medição

• Use o IP SLA para gerar tráfego sintético RTP/UDP e medir atraso, jitter e perda; garanta o NTP para precisão de tempo.

undefined

para verificar contadores e descartes por classe.

Resiliência: Impacto do FHRP e Validação Operacional

FHRP

• HSRP/VRRP fornecem um gateway padrão virtual para sobreviver a falhas de primeiro salto (first-hop); o GLBP adiciona balanceamento de carga de gateway.
• Projeto: Ajuste os timers para convergência versus estabilidade; use o rastreamento de objetos (object tracking) para fazer o failover em caso de perda de upstream/WAN, não apenas quando uma interface fica inativa (down).
• Impacto no serviço: Durante o failover, a atualização de ARP e o rehashing podem causar uma breve perda; fluxos em tempo real sem simetria de caminho ou estado de NAT replicado podem ser reiniciados. Mantenha o caminho de egresso consistente para o tráfego prioritário.

Validação operacional e troubleshooting

• DHCP: Confirme os endereços helper e a utilização do pool; faça captura de pacotes para ver o DORA; verifique as tabelas de DHCP snooping.
• DNS: Valide com nslookup/dig; verifique a redundância dos resolvers; inspecione as regras de firewall e o comportamento de MTU/EDNS.
• NAT: Verifique as traduções durante fluxos ativos; garanta rotas para o “inside local” e para o pool; teste o NAT estático de entrada (inbound) a partir do exterior.
• NTP: Garanta um stratum sincronizado e um offset baixo; exija autenticação.
• QoS: Valide a confiança (trust); verifique os contadores de service-policy sob carga realista; execute testes de voz com IP SLA; observe descartes do policer no tráfego prioritário.
• Visibilidade: Confirme o funcionamento do SNMPv3 e a entrega de traps; verifique se os timestamps do syslog estão corretos; alinhe os exportadores NetFlow com os coletores; garanta que os fluxos de telemetria estejam estáveis.

Cenário de Problema Prático

A Acme Manufacturing enfrenta instabilidade intermitente em chamadas de telefone IP e falhas esporádicas de DHCP em uma filial após adicionar um segundo ISP e habilitar o PAT em um novo roteador.

1. Estabilizar o roteamento e a disponibilidade do gateway com FHRP

• Configure o HSRP na SVI da VLAN da filial entre os dois roteadores, defina preempt e prioridades, e rastreie os uplinks da WAN.
• Justificativa: Um gateway padrão virtual oculta o failover do roteador dos endpoints; o rastreamento de objetos (object tracking) afasta o gateway de um roteador que perdeu a alcançabilidade de upstream.

2. Normalizar o comportamento do NAT e prevenir egresso assimétrico

• Coloque o PAT apenas no roteador HSRP ativo; garanta que o standby não anuncie uma rota padrão a menos que esteja ativo, ou implemente PBR para fixar o egresso da VLAN de voz em um único roteador.
• Justificativa: O egresso assimétrico quebra o PAT stateful e os ALGs para SIP/RTP; um egresso consistente mantém as traduções e a estabilidade das chamadas.

3. Corrigir a confiabilidade do relay de DHCP

• Em ambos os gateways SVI, configure ip helper-address para os servidores DHCP centrais; verifique a confiança (trust) do DHCP snooping em direção ao uplink e desconfie (untrust) das portas de acesso; exclua as faixas de IP estático.
• Justificativa: O relay adequado garante que o DORA chegue aos servidores; o snooping previne servidores não autorizados (rogue) ao mesmo tempo que permite respostas do servidor; as exclusões evitam conflitos.

4. Estabelecer tempo preciso e habilitar medição

• Configure clientes NTP em ambos os roteadores com servidores autenticados, verifique o stratum e, em seguida, configure operações udp-jitter do IP SLA em direção ao gerenciador de chamadas da matriz (HQ).
• Justificativa: O tempo preciso é a base para os cálculos de atraso unidirecional (one-way delay) e jitter; o IP SLA valida que o QoS pode suportar voz.

5. Implementar uma política de QoS da borda para a WAN com fronteiras de confiança (trust boundaries)

• Confie (Trust) no CoS nas portas de acesso apenas quando um telefone IP da Cisco for detectado; remarque o DSCP para voz como EF e para sinalização como CS3; aplique LLQ com 10% para voz, largura de banda para vídeo e fair-queue como padrão. Faça o shaping para o CIR do provedor antes de aplicar a política se a interface física for mais rápida que a taxa contratada.
• Justificativa: A confiança (trust) adequada impede que os hosts inflem a prioridade; o LLQ garante baixa latência; o shaping evita descartes downstream na borda do provedor.

6. Aumentar a visibilidade e reforçar a segurança do plano de gerenciamento

• Habilite o SNMPv3 para o NMS, o syslog para coletores redundantes com timestamps e os exportadores NetFlow v9 para a ferramenta de análise; adicione policiamento do plano de controle (control-plane policing) para SNMP e logging.
• Justificativa: A observabilidade confirma melhorias e identifica regressões; o gerenciamento seguro reduz a superfície de ataque enquanto mantém a telemetria.

7. Validar e, em seguida, simular falhas

• Use show policy-map interface para confirmar o incremento dos contadores de tráfego prioritário durante chamadas de teste; observe as linhas de base (baselines) de jitter do IP SLA; execute traceroute e teste o failover forçando uma mudança de estado do HSRP.
• Justificativa: A validação operacional sob carga verifica a intenção do projeto; o failover controlado prova a resiliência e revela quaisquer casos extremos (edge cases) de NAT ou convergência.

← Roteamento Dinâmico e Conectividade IP · Todos os domínios · Projeto e Operações de LAN Wireless →

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