Cisco 300-415: Qualidade de Serviço e Serviços Multicast — Guia de estudos

By Laurynas Brazys · 13 August 2026 · #cisco #300-415 #certification #exam-prep #study-guide

Faz parte do Cisco SD-WAN 300-415 ENSDWI — 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 Qualidade de Serviço (QoS) e multicast no Cisco SD-WAN são projetados para preservar a experiência da aplicação em diversos transportes, ao mesmo tempo em que permitem a distribuição escalável e orientada por políticas de tráfego de tempo real e de grupo. O QoS garante prioridade, modelagem (shaping) e uso justo da largura de banda por aplicação e por túnel de overlay; o multicast permite a replicação eficiente e controlada por políticas de streams para receptores em diferentes sites. Juntos, eles convertem a intenção (voz/vídeo devem ser protegidos contra perda e jitter; aplicações críticas de negócios devem atender aos SLAs) em um comportamento consistente no plano de dados, coordenado pelo plano de controle do SD-WAN (vSmart) e aplicado nos dispositivos WAN Edge.

Arquitetura de QoS, Filas, Agendamento, Shaping, Policing e Alocação de Largura de Banda

O QoS no Cisco SD-WAN é hierárquico e ciente do transporte:

• Classificação: Identificar fluxos por campos (L3/L4), DSCP, assinaturas de aplicação (NBAR2 no IOS XE SD-WAN), ou contexto de VPN e prefixo.
• Marcação: Definir ou preservar o DSCP do lado do serviço, reescrevê-lo conforme necessário para as restrições da WAN e mapeá-lo para filas de saída através de mapas de QoS.
• Enfileiramento e agendamento: As interfaces de saída implementam múltiplas filas de hardware/software com uma fila de baixa latência e prioridade estrita (LLQ) para tráfego em tempo real e agendadores ponderados (WFQ/WRR/CBWFQ) para outras classes.
• Shaping: Suavizar a saída para uma taxa configurada (por interface, por sub-interface ou por túnel) para evitar os policers da provedora e absorver picos de tráfego (bursts).
• Policing: Limitar a taxa e, opcionalmente, remarcar ou descartar tráfego não conforme na entrada ou na saída; usado com moderação para evitar degradação de performance de aplicações (brownouts).
• Alocação de largura de banda: Reservar largura de banda mínima (garantias) por classe e limitar os máximos quando apropriado; garantir que a LLQ tenha um limite rígido e explícito para evitar a inanição (starvation) de outras filas.

Orientações de design e trade-offs:

• Faça o shaping para uma taxa segura abaixo do policer efetivo do ISP. Para circuitos de Internet variáveis, 90–95% da largura de banda nominal é um ponto de partida prático; ajuste usando os descartes e a latência observados sob carga.
• A profundidade da fila (buffering) deve equilibrar o atraso versus a perda. Dimensione para aproximadamente uma fração do produto largura de banda-atraso; muito pequena induz descartes de cauda (tail drop); muito grande aumenta a latência para as classes inferiores.
• Use a LLQ apenas para fluxos curtos de controle de voz/vídeo com taxa constante; não coloque streams de vídeo de alta taxa de bits na LLQ — atribua-os a uma fila ponderada de alta prioridade com um limite claro de largura de banda.
• Prefira shaping em vez de policing na saída. Aplique policers para contratos de taxa explícitos ou tráfego de entrada não confiável.
• Em links físicos compartilhados que transportam múltiplos overlays, habilite o QoS por túnel (PTQ) para que cada túnel seguro baseado em BFD receba seu próprio agendador/shaper, impedindo que um único overlay ocupado monopolize o link.
• A política específica de transporte (ciente de color/TLOC) permite mapas de QoS, shapers e garantias de classe distintos por underlay (por exemplo, shaping mais rigoroso e um conjunto de DSCP reduzido na Internet em comparação com classes mais ricas no MPLS).

QoS por túnel e especificidades de transporte:

• O PTQ virtualiza o agendamento de saída por túnel IPsec/DTLS/TLS para que as garantias e os limites se apliquem por caminho, não apenas por interface. Isso é essencial quando um Edge forma múltiplos túneis sobre a mesma interface (por exemplo, regiões duplas de vSmart/vBond ou múltiplos peers remotos).
• Atribua mapas de QoS diferentes por color (biz-internet, mpls, lte) para respeitar as listas de permissão (whitelists) de DSCP da provedora e evitar remarcações inesperadas (por exemplo, agrupar as classes AF na classe padrão (default) em links de banda larga).

Classificação e Marcação com DSCP, Mapas de QoS e Gerenciamento de Congestionamento

A classificação confiável começa na borda da VPN de serviço:

• Fronteiras de confiança: Se o domínio de acesso da LAN não for ciente de QoS, classifique e marque no WAN Edge usando o ID da aplicação L7 ou tuplas L3/L4. Se a LAN for capaz de QoS, audite e preserve o DSCP enquanto o normaliza para um mapa de QoS da WAN.
• Estratégia de DSCP: EF para voz interativa, AF41/42 para vídeo, AF31/AF21 para dados críticos, classes CS3/AF para sinalização, CS0/DF para melhor esforço (best effort) e CS1 (ou LE) para scavenger. Alinhe com os valores aceitos pela provedora.
• Mapa de QoS: Mapeie DSCP para fila e, opcionalmente, reescreva na saída; mantenha um mapeamento um-para-um ou muitos-para-um que respeita os limites do underlay.

Exemplo curto de verificações operacionalmente úteis:

show sdwan app-route stats sla-class VOICE
show policy qos-queue   (vEdge)
show policy-map interface <wan-intf>  (IOS XE SD-WAN)

Gerenciamento de congestionamento e dimensionamento de filas:

• Comece com uma LLQ pequena e limitada para EF (por exemplo, 10% da taxa de shaping) e aplique policing dentro da LLQ para evitar sobrecarga por fluxos marcados incorretamente.
• Aloque a largura de banda restante usando pesos WRR/CBWFQ alinhados com a prioridade do negócio (por exemplo, 30% dados críticos, 20% vídeo, 35% melhor esforço, 5% scavenger).
• Considere habilitar o descarte antecipado (WRED) para classes de tráfego em massa (bulk) quando suportado pela plataforma para evitar a sincronização global; não habilite o descarte antecipado na LLQ ou em pequenas filas de controle.

Modos de falha a serem observados:

• A remarcação pela operadora agrupa o DSCP, colocando o tráfego de tempo real na fila de melhor esforço; o resultado é jitter e perda de pacotes durante os picos. Verifique com capturas de pacotes e os perfis de QoS da provedora.
• Shapers mal dimensionados levam a descartes de cauda (tail drops) persistentes; a inanição (starvation) da LLQ ocorre se ela não tiver um limite ou se o tráfego de vídeo inundar a LLQ.
• A falta de PTQ em uma interface compartilhada faz com que overlays “vizinhos barulhentos” (noisy-neighbor) consumam a largura de banda e degradem os túneis críticos.

Priorização de Aplicações, Intenção de Negócio e Aplicação de SLA

O Cisco SD-WAN expressa a intenção da aplicação por meio de uma política centralizada no controlador vSmart, que gerencia o plano de controle do overlay e distribui as políticas para os WAN Edges. O Application-Aware Routing (AAR) direciona o tráfego com base na perda, latência e jitter medidos por transporte e por túnel usando BFD. Para otimização de SaaS, o Cloud OnRamp pode incorporar a perda e a latência baseadas em HTTP para a aplicação, além das métricas de BFD em direção a um site de gateway.

Melhores práticas:

• Defina listas de aplicações e classes de SLA por criticidade de negócio:
  • VOICE: EF, alvo <150 ms em um sentido, <30 ms de jitter, <1% de perda; direcione apenas por caminhos que atendam a esses limites.
  • VIDEO: AF4x, jitter/perda um pouco mais flexíveis que voz; prefira caminhos de alta largura de banda e baixa perda.
  • CRITICAL DATA: AF3x/AF2x; limite a perda e a latência conforme exigido pela aplicação.
• Use a política centralizada para o application-aware routing (AAR) para preferir caminhos que atendam ao SLA por classe; recorra a caminhos secundários quando ocorrer degradação.
• Combine o AAR com QoS por transporte: um caminho selecionado deve ter recursos reservados para a classe; caso contrário, o tráfego pode atender ao SLA do caminho, mas ainda assim ser enfileirado ou descartado na saída (egress).
• Para SaaS via um site de gateway, valide ambos:
  • Perda/latência de HTTP para o endpoint do SaaS.
  • Perda/latência de BFD para o site de gateway.
• Garanta a preservação do DSCP de ponta a ponta; na saída, reescreva apenas onde os underlays exigirem e restaure as marcações se a outra ponta confiar nelas.

Verificações operacionais:

show sdwan app-route statistics
show sdwan bfd sessions
show application traffic-flow   (vManage analytics)

Armadilhas comuns:

• Limites de SLA muito rígidos causam instabilidade de caminho (path flapping); introduza histerese e hold timers.
• A falta de largura de banda para a classe no caminho escolhido leva a congestionamento autoinfligido; alinhe as escolhas do AAR com a capacidade de QoS por transporte.
• Classificação incorreta (ex: voz descoberta como best effort) devido a payloads criptografados ou falta de assinaturas NBAR; use a confiança em DSCP ou correspondências explícitas de L4 como fallback.

Fundamentos de Multicast e Design de Multicast em Overlay

O multicast sobre SD-WAN desacopla o plano de controle de multicast da LAN das restrições do underlay:

• Fundamentos:
  • Os receptores sinalizam interesse com IGMPv2/v3 em direção ao roteador LAN de primeiro salto (o WAN Edge na VPN de serviço).
  • O PIM Sparse Mode é recomendado na VPN de serviço; os rendezvous points (RPs) orquestram as junções iniciais.
• Plano de controle do overlay:
  • Os roteadores WAN Edge originam rotas de serviço multicast para o controlador vSmart via OMP.
  • O controlador vSmart, atuando na função de replicador de multicast/anúncio de RP, propaga as informações do RP através do overlay e encaminha as junções para os grupos solicitados em direção à origem ou ao PIM-RP, conforme especificado na mensagem de junção PIM original.
  • O vSmart seleciona um ou mais WAN Edges como replicadores do plano de dados. O Edge do lado da origem envia uma única cópia para o replicador, que então replica para os Edges receptores, minimizando o uso de largura de banda em links com restrições.
• Plano de dados:
  • A replicação ocorre como pacotes unicast criptografados através dos túneis do overlay; os limites da VPN de serviço são preservados (o multicast é por VPN/VRF).
  • O multicast entre VPNs não é automático; se necessário, use service-chaining explícito ou gateways de camada de aplicação.

Considerações de design e trade-offs:

• Posicione o RP logicamente próximo às origens ou datacenters centrais. Em um overlay SD-WAN, confie no vSmart para anunciar o RP aos receptores, garantindo junções consistentes.
• Habilite o multicast apenas nas VPNs onde for necessário; mantenha o tráfego de controle dos receptores (IGMP) com rate-limit para proteger a CPU.
• Em links de baixa largura de banda, centralize a replicação em um hub/replicador com ampla capacidade para evitar a replicação de N×streams nos circuitos de acesso.
• Valide o MTU para evitar a fragmentação de streams de alta taxa de bits; considere aplicar shaping às classes de vídeo de forma independente das filas do plano de controle.

Modos de falha:

• A ausência de um IGMP querier na LAN leva ao envelhecimento do grupo e à perda do stream; garanta que o WAN Edge ou um switch da LAN atue como querier.
• Incompatibilidade de RP ou filtragem na política centralizada interrompe as junções; confirme a alcançabilidade do RP através do overlay.
• Tráfego de controle multicast excessivo com pacotes pequenos pode ser confundido com DDoS; aplique rate-limit e monitore as filas de controle.
• Limites de VPN de serviço especificados incorretamente causam falha na entrega; o multicast não cruza VPNs a menos que seja projetado explicitamente para isso.

Essenciais para troubleshooting:

show ip igmp groups
show ip pim neighbor / rp mapping
show sdwan omp services
show sdwan multicast status
show interface | include drops

Correlacione as quedas na fila (queue drops) com os KPIs da aplicação; para multicast, garanta que as junções IGMP sejam vistas no Edge, que as rotas de serviço OMP existam e que o replicador escolhido esteja alcançável através de um túnel saudável.

Cenário de Problema Prático

A NorthRiver Health opera 120 clínicas com transportes duplos (MPLS e Internet). As reclamações citam voz entrecortada, vídeo de telemedicina pixelado e multicast de IPTV intermitente nas salas de espera.

Abordagem:

1. Estabelecer limites de confiança e classificar o tráfego

• Justificativa: A classificação precisa é um pré-requisito para a priorização. Preserve o DSCP de domínios LAN compatíveis; onde ausente, classifique por aplicação (NBAR2) e tuplas L4, mapeando voz para EF, vídeo para AF41 e EMR crítico para AF31.

2. Criar mapas de QoS e shapers específicos para cada transporte

• Justificativa: O MPLS honra AF/EF, a Internet geralmente não. Configure mapas de QoS por cor: conjunto completo de classes no MPLS; classes colapsadas na Internet com EF e AF4 preservados. Aplique shaping no MPLS para 95% do CIR e na Internet para a taxa de transferência sustentável medida, a fim de evitar os policers da provedora.

3. Habilitar QoS por túnel em interfaces WAN compartilhadas

• Justificativa: Múltiplos overlays compartilham o mesmo link físico. O PTQ impede que um túnel site-para-nuvem ocupado sufoque os túneis de voz/vídeo site-para-datacenter, alocando agendadores e mínimos por túnel.

4. Reservar e limitar a LLQ para voz; ponderar vídeo e dados críticos

• Justificativa: A voz exige latência/jitter limitados; limite a LLQ em 10% para evitar a privação de outros tráfegos (starvation). Atribua 25–30% ao vídeo AF4 com um máximo estrito. Aloque 25% para o tráfego EMR AF3, e o restante para best effort e scavenger.

5. Implementar política AAR centralizada no vSmart com classes de SLA

• Justificativa: O vSmart distribui uma política centralizada que coloca o tráfego de voz/vídeo/EMR em caminhos que atendem às metas de SLA usando BFD para perda/latência/jitter. Adicione histerese para evitar oscilações (flaps). Para módulos SaaS EHR via gateway, inclua a perda/latência HTTP para o SaaS e o BFD para o site do gateway.

6. Implantar multicast em overlay com seleção de replicador pelo vSmart

• Justificativa: A distribuição eficiente de IPTV requer replicação controlada. Habilite o multicast na VPN de IPTV, configure PIM-SM e o RP, e deixe o vSmart anunciar o RP e selecionar um Edge do datacenter como replicador para proteger os circuitos de baixa velocidade das clínicas da replicação N-way.

7. Validar e iterar com telemetria

• Justificativa: Confirme o comportamento sob carga. Use:
  • show sdwan app-route statistics para verificar a seleção de caminho do SLA.
  • show policy qos-queue / show policy-map interface para avaliar a utilização e as quedas nas filas.
  • show ip igmp groups e show sdwan omp services para junções multicast e rotas de serviço. Ajuste as taxas do shaper e os pesos das filas para eliminar quedas de cauda (tail drops) em voz/vídeo, mantendo uma latência aceitável para dados críticos.

8. Mecanismos de proteção (Guardrails) e tratamento de anomalias

• Justificativa: Prevenir a recorrência e detectar regressões. Aplique policers de entrada (ingress policers) em segmentos LAN não confiáveis para limitar o tráfego mal marcado, aplique rate-limit ao IGMP para proteger a CPU do plano de controle e configure alertas para violações de SLA do AAR e contadores de quedas nas filas para acionar a remediação proativa.

Esta sequência garante que a NorthRiver Health converta a intenção de negócio em um QoS consistente e ciente do transporte, e em uma entrega de multicast confiável. A voz obtém tratamento estrito e limitado; vídeo e EMR recebem largura de banda priorizada e ponderada; os caminhos são selecionados por medições de SLA em tempo real; e o multicast é replicado eficientemente sem sobrecarregar os links das filiais.

← Segurança · Todos os domínios · Integração com Nuvem →

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