Cisco 300-415: Quality of Service und Multicast-Dienste — Lernleitfaden

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

Teil des Cisco SD-WAN 300-415 ENSDWI — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Quality of Service (QoS)- und Multicast-Dienste in Cisco SD-WAN sind darauf ausgelegt, das Anwendungserlebnis über verschiedene Transportwege hinweg zu erhalten und gleichzeitig eine skalierbare, richtliniengesteuerte Verteilung von Echtzeit- und Gruppenverkehr zu ermöglichen. QoS gewährleistet Priorisierung, Shaping und eine faire Nutzung der Bandbreite pro Anwendung und pro Overlay-Tunnel; Multicast ermöglicht eine effiziente, richtliniengesteuerte Replikation von Streams für Empfänger über Standorte hinweg. Zusammen setzen sie die Absicht (Sprach-/Videodaten müssen vor Verlust und Jitter geschützt sein; geschäftskritische Anwendungen müssen SLAs erfüllen) in ein konsistentes Verhalten der Datenebene um, das von der SD-WAN-Kontrollebene (vSmart) koordiniert und auf den WAN-Edge-Geräten durchgesetzt wird.

QoS-Architektur, Queues, Scheduling, Shaping, Policing und Bandbreitenzuweisung

QoS in Cisco SD-WAN ist hierarchisch und transportbewusst (transport-aware):

• Klassifizierung: Identifizieren von Flows anhand von Feldern (L3/L4), DSCP, Anwendungssignaturen (NBAR2 auf IOS XE SD-WAN) oder VPN- und Präfix-Kontext.
• Markierung: Setzen oder Beibehalten von DSCP von der Dienstseite (Service Side), Umschreiben je nach WAN-Beschränkungen und Zuordnung zu Ausgangswarteschlangen (Egress Queues) über QoS-Maps.
• Queuing und Scheduling: Egress-Schnittstellen implementieren mehrere Hardware-/Software-Warteschlangen mit einer Low-Latency Queue (LLQ) mit strikter Priorität für Echtzeitverkehr und gewichteten Schedulern (WFQ/WRR/CBWFQ) für andere Klassen.
• Shaping: Glätten des ausgehenden Verkehrs (Egress) auf eine konfigurierte Rate (pro Schnittstelle, pro Sub-Interface oder pro Tunnel), um Provider-Policer zu vermeiden und Bursts abzufangen.
• Policing: Ratenbegrenzung und optionales Neumarkieren oder Verwerfen von nicht konformem Datenverkehr am Eingang (Ingress) oder Ausgang (Egress); wird sparsam eingesetzt, um „Application Brownouts“ zu vermeiden.
• Bandbreitenzuweisung: Reservieren von minimaler Bandbreite (Garantien) pro Klasse und Begrenzen von Maxima, wo es angebracht ist; sicherstellen, dass die LLQ eine enge, explizite Obergrenze (Cap) hat, um die „Starvation“ (Aushungern) anderer Warteschlangen zu verhindern.

Design-Leitlinien und Kompromisse:

• Shaping auf eine sichere Rate unterhalb des effektiven Policers des ISP durchführen. Bei variablen Internetleitungen sind 90–95 % der Nennbandbreite ein praxisnaher Ausgangspunkt; die Feinabstimmung erfolgt anhand der beobachteten Drops und der Latenz unter Last.
• Die Warteschlangentiefe (Pufferung) muss eine Balance zwischen Verzögerung und Verlust herstellen. Die Größe sollte ungefähr einem Bruchteil des Bandbreite-Verzögerungs-Produkts entsprechen; zu klein führt zu Tail Drops, zu groß erhöht die Latenz für niedrigere Klassen.
• Die LLQ nur für kurze Sprach-/Video-Steuerungs-Flows mit konstanter Rate verwenden; keine Videoströme mit hoher Bitrate in die LLQ legen – diese einer gewichteten Warteschlange mit hoher Priorität und einer klaren Bandbreitenobergrenze zuweisen.
• Shaping gegenüber Policing am Ausgang (Egress) bevorzugen. Policer für explizite Ratenverträge oder nicht vertrauenswürdigen Eingang (Ingress) anwenden.
• Auf gemeinsam genutzten physischen Verbindungen, die mehrere Overlays transportieren, Per-Tunnel QoS (PTQ) aktivieren, damit jeder BFD-basierte sichere Tunnel seinen eigenen Scheduler/Shaper erhält. Dies verhindert, dass ein einzelnes, stark ausgelastetes Overlay die Verbindung monopolisiert.
• Transport-spezifische Richtlinien (Color/TLOC-bewusst) ermöglichen unterschiedliche QoS-Maps, Shaper und Klassengarantien pro Underlay (zum Beispiel strengeres Shaping und reduzierter DSCP-Satz im Internet im Vergleich zu reichhaltigeren Klassen bei MPLS).

Per-Tunnel QoS und transport-spezifische Besonderheiten:

• PTQ virtualisiert das Egress-Scheduling pro IPsec/DTLS/TLS-Tunnel, sodass Garantien und Obergrenzen pro Pfad und nicht nur pro Schnittstelle gelten. Dies ist unerlässlich, wenn ein Edge-Gerät mehrere Tunnel über dieselbe Schnittstelle aufbaut (z. B. duale vSmart/vBond-Regionen oder mehrere entfernte Peers).
• Weisen Sie pro Color (biz-internet, mpls, lte) unterschiedliche QoS-Maps zu, um die DSCP-Whitelists der Provider zu berücksichtigen und unerwartetes Neumarkieren zu verhindern (z. B. AF-Klassen auf Breitbandverbindungen in die Standardklasse zusammenfassen).

Klassifizierung und Markierung mit DSCP, QoS-Maps und Congestion Management

Die vertrauenswürdige Klassifizierung beginnt am Service-VPN-Edge:

• Vertrauensgrenzen: Wenn die LAN-Zugriffsdomäne keine QoS-Unterstützung bietet (QoS-unaware), klassifizieren und markieren Sie am WAN Edge anhand der L7-Anwendungs-ID oder L3/L4-Tupel. Wenn das LAN QoS-fähig ist, prüfen und erhalten Sie DSCP-Werte und normalisieren Sie diese auf eine WAN-QoS-Map.
• DSCP-Strategie: EF für interaktive Sprache, AF41/42 für Video, AF31/AF21 für kritische Daten, CS3/AF-Klassen für Signalisierung, CS0/DF für Best Effort und CS1 (oder LE) für Scavenger. Richten Sie sich nach den vom Provider akzeptierten Werten.
• QoS-Map: Ordnen Sie DSCP-Werte den Warteschlangen zu und schreiben Sie sie optional am Ausgang (Egress) um; pflegen Sie eine Eins-zu-eins- oder Viele-zu-eins-Zuordnung, die die Underlay-Limits respektiert.

Kurzes Beispiel für operativ nützliche Überprüfungen:

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

Congestion Management und Dimensionierung der Warteschlangen:

• Beginnen Sie mit einer kleinen, begrenzten LLQ für EF (z. B. 10 % der Shaping-Rate) und setzen Sie Policing innerhalb der LLQ durch, um ein Überlaufen durch falsch markierte Flows zu verhindern.
• Weisen Sie die verbleibende Bandbreite mithilfe von WRR/CBWFQ-Gewichtungen zu, die auf die Geschäftspriorität abgestimmt sind (z. B. 30 % kritische Daten, 20 % Video, 35 % Best Effort, 5 % Scavenger).
• Erwägen Sie die Aktivierung von Early Drop (WRED) für Massendaten-Klassen (Bulk Classes), wenn dies von der Plattform unterstützt wird, um eine globale Synchronisation zu vermeiden; aktivieren Sie Early Drop nicht für die LLQ oder kleine Steuerungs-Warteschlangen.

Fehlermodi, auf die zu achten ist:

• Neumarkierung durch den Carrier führt zum Kollabieren der DSCP-Werte, wodurch Echtzeitverkehr in die Best-Effort-Klasse verschoben wird; das Ergebnis sind Jitter und Paketverluste während Lastspitzen. Überprüfen Sie dies mit Paketmitschnitten und den QoS-Profilen des Providers.
• Falsch dimensionierte Shaper führen zu persistenten Tail Drops; LLQ-Starvation tritt auf, wenn die Warteschlange unbegrenzt ist oder wenn Video die LLQ überflutet.
• Fehlendes PTQ auf einer gemeinsam genutzten Schnittstelle führt dazu, dass „Noisy-Neighbor“-Overlays Bandbreite verbrauchen und kritische Tunnel beeinträchtigen.

Anwendungspriorisierung, Geschäftsabsicht und SLA-Durchsetzung

Cisco SD-WAN drückt die Anwendungsabsicht über eine zentralisierte Richtlinie auf dem vSmart-Controller aus, der die Overlay-Steuerungsebene (Control Plane) verwaltet und Richtlinien an die WAN Edges verteilt. Application-Aware Routing (AAR) leitet den Datenverkehr basierend auf gemessenem Verlust, Latenz und Jitter pro Transport und pro Tunnel mithilfe von BFD. Zur SaaS-Optimierung kann Cloud OnRamp zusätzlich zu den BFD-Metriken zu einem Gateway-Standort auch HTTP-basierten Verlust und Latenz zur Anwendung hin einbeziehen.

Bewährte Methoden:

• Definieren Sie Anwendungslisten und SLA-Klassen nach Geschäftskritikalität:
  • VOICE: EF, Ziel <150 ms One-Way, <30 ms Jitter, <1 % Verlust; nur über Pfade leiten, die diese Schwellenwerte einhalten.
  • VIDEO: AF4x, etwas lockerere Jitter-/Verlust-Anforderungen als bei Voice; Pfade mit hoher Bandbreite und geringem Verlust bevorzugen.
  • CRITICAL DATA: AF3x/AF2x; Verlust und Latenz entsprechend den Anwendungsanforderungen begrenzen.
• Verwenden Sie eine zentralisierte Richtlinie für Application-Aware Routing (AAR), um Pfade zu bevorzugen, die das SLA pro Klasse erfüllen; bei Leistungsabfall auf sekundäre Pfade ausweichen.
• Kombinieren Sie AAR mit Per-Transport-QoS: Ein ausgewählter Pfad muss für die Klasse reservierte Ressourcen haben; andernfalls kann der Datenverkehr zwar das Pfad-SLA erfüllen, aber am Egress dennoch in eine Warteschlange gestellt oder verworfen werden.
• Für SaaS über einen Gateway-Standort, validieren Sie beides:
  • HTTP-Verlust/Latenz zum SaaS-Endpunkt.
  • BFD-Verlust/Latenz zum Gateway-Standort.
• Erzwingen Sie die Beibehaltung von DSCP End-to-End; schreiben Sie Markierungen beim Austritt nur um, wenn die Underlays dies erfordern, und stellen Sie sie wieder her, wenn die Gegenseite ihnen vertraut.

Betriebliche Überprüfungen:

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

Häufige Fallstricke:

• Zu enge SLA-Schwellenwerte verursachen Pfad-Flapping; führen Sie Hysterese- und Hold-Timer ein.
• Fehlende Klassenbandbreite auf dem gewählten Pfad führt zu selbst verursachter Überlastung; gleichen Sie AAR-Entscheidungen mit der Per-Transport-QoS-Kapazität ab.
• Fehlklassifizierung (z. B. Voice wird als Best Effort erkannt) aufgrund verschlüsselter Payloads oder fehlender NBAR-Signaturen; verwenden Sie DSCP-Trust oder explizite L4-Matches als Fallback.

Multicast-Grundlagen und Overlay-Multicast-Design

Multicast über SD-WAN entkoppelt die LAN-Multicast-Steuerungsebene von den Einschränkungen des Underlays:

• Grundlagen:
  • Empfänger signalisieren ihr Interesse mit IGMPv2/v3 an den First-Hop-LAN-Router (die WAN Edge im Service-VPN).
  • PIM Sparse Mode wird im Service-VPN empfohlen; Rendezvous Points (RPs) orchestrieren die anfänglichen Joins.
• Overlay-Steuerungsebene:
  • WAN-Edge-Router erzeugen Multicast-Service-Routen zum vSmart-Controller über OMP.
  • Der vSmart-Controller, der in der Rolle als Multicast-Replikator/RP-Advertiser agiert, verbreitet RP-Informationen über das Overlay und leitet Joins für angeforderte Gruppen an die Quelle oder den PIM-RP weiter, wie in der ursprünglichen PIM-Join-Nachricht spezifiziert.
  • vSmart wählt eine oder mehrere WAN Edges als Data-Plane-Replikatoren aus. Die quellseitige Edge sendet eine einzige Kopie an den Replikator, der diese dann an die empfängerseitigen Edges repliziert, wodurch die Bandbreitennutzung auf beschränkten Verbindungen minimiert wird.
• Datenebene:
  • Die Replikation erfolgt als unicast-verschlüsselte Pakete über die Overlay-Tunnel; die Grenzen des Service-VPNs bleiben erhalten (Multicast ist pro VPN/VRF).
  • Inter-VPN-Multicast ist nicht automatisch; falls erforderlich, verwenden Sie explizites Service-Chaining oder Application-Layer-Gateways.

Designüberlegungen und Kompromisse:

• Platzieren Sie den RP logisch nahe an den Quellen oder zentralen Rechenzentren. Verlassen Sie sich in einem SD-WAN-Overlay darauf, dass vSmart den RP an die Empfänger bekannt gibt, um konsistente Joins sicherzustellen.
• Aktivieren Sie Multicast nur in VPNs, in denen es benötigt wird; halten Sie den Steuerverkehr der Empfänger (IGMP) ratenbegrenzt, um die CPU zu schützen.
• Zentralisieren Sie bei Verbindungen mit geringer Bandbreite die Replikation an einem Hub/Replikator mit ausreichender Kapazität, um eine N×Stream-Replikation auf den Zugangsleitungen zu vermeiden.
• Validieren Sie die MTU, um die Fragmentierung von Streams mit hoher Bitrate zu vermeiden; erwägen Sie, Videoklassen unabhängig von den Warteschlangen der Steuerungsebene zu shapen.

Fehlermodi:

• Das Fehlen eines IGMP-Queriers im LAN führt zu Group-Aging und dem Verlust von Streams; stellen Sie sicher, dass die WAN Edge oder ein LAN-Switch als Querier fungiert.
• Ein RP-Mismatch oder Filterung in der zentralisierten Policy unterbricht Joins; bestätigen Sie die Erreichbarkeit des RP über das gesamte Overlay.
• Übermäßiger Multicast-Steuerverkehr mit kleinen Paketen kann fälschlicherweise als DDoS erkannt werden; wenden Sie Ratenbegrenzung an und überwachen Sie die Steuerwarteschlangen.
• Falsch spezifizierte Service-VPN-Grenzen führen zu Nichtzustellung; Multicast überquert keine VPNs, es sei denn, dies wird explizit so konzipiert.

Grundlagen der Fehlerbehebung:

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

Korrelieren Sie Queue-Drops mit Anwendungs-KPIs; stellen Sie bei Multicast sicher, dass IGMP-Joins an der Edge gesehen werden, OMP-Service-Routen existieren und der gewählte Replikator über einen intakten Tunnel erreichbar ist.

Praktisches Problemszenario

NorthRiver Health betreibt 120 Kliniken mit dualen Transportwegen (MPLS und Internet). Es gibt Beschwerden über abgehackte Sprache, verpixelte Telemedizin-Videos und zeitweise ausfallendes IPTV-Multicast in den Warteräumen.

Vorgehensweise:

1. Vertrauensgrenzen festlegen und Verkehr klassifizieren

• Begründung: Eine genaue Klassifizierung ist die Voraussetzung für die Priorisierung. Behalten Sie DSCP von konformen LAN-Domänen bei; wo dies nicht der Fall ist, klassifizieren Sie nach Anwendung (NBAR2) und L4-Tupeln und mappen Sie Sprache auf EF, Video auf AF41 und kritische EMR auf AF31.

2. Transportspezifische QoS-Maps und Shaper erstellen

• Begründung: MPLS berücksichtigt AF/EF, das Internet oft nicht. Konfigurieren Sie per-Color QoS-Maps: vollständiger Klassensatz auf MPLS; reduzierte Klassen im Internet, wobei EF und AF4 aufrechterhalten werden. Shapen Sie MPLS auf 95 % der CIR und das Internet auf den gemessenen nachhaltigen Durchsatz, um Provider-Policer zu vermeiden.

3. Per-Tunnel-QoS auf gemeinsam genutzten WAN-Schnittstellen aktivieren

• Begründung: Mehrere Overlays teilen sich dieselbe physische Verbindung. PTQ verhindert, dass ein ausgelasteter Site-to-Cloud-Tunnel die Sprach-/Video-Tunnel vom Standort zum Rechenzentrum aushungert, indem per-Tunnel-Scheduler und Mindestbandbreiten zugewiesen werden.

4. LLQ für Sprache reservieren und begrenzen; Video und kritische Daten gewichten

• Begründung: Sprache erfordert eine begrenzte Latenz/Jitter; begrenzen Sie LLQ auf 10 %, um ein Aushungern zu verhindern. Weisen Sie 25–30 % dem AF4-Video mit einem strikten Maximum zu. Weisen Sie 25 % dem AF3-EMR-Verkehr zu, der Rest geht an Best-Effort und Scavenger.

5. Zentralisierte AAR-Policy auf vSmart mit SLA-Klassen implementieren

• Begründung: vSmart verteilt eine zentralisierte Policy, die Sprach-/Video-/EMR-Verkehr auf Pfade leitet, die die SLA-Ziele unter Verwendung von BFD-Verlust/Latenz/Jitter erfüllen. Fügen Sie eine Hysterese hinzu, um Flaps zu verhindern. Für SaaS-EHR-Module über ein Gateway, schließen Sie HTTP-Verlust/Latenz zum SaaS und BFD zum Gateway-Standort mit ein.

6. Overlay-Multicast mit Replikator-Auswahl durch vSmart bereitstellen

• Begründung: Eine effiziente IPTV-Verteilung erfordert eine kontrollierte Replikation. Aktivieren Sie Multicast im IPTV-VPN, konfigurieren Sie PIM-SM und den RP, und lassen Sie vSmart den RP bekannt geben und eine Rechenzentrums-Edge als Replikator auswählen, um die langsamen Leitungen der Kliniken vor N-facher Replikation zu schützen.

7. Validieren und iterieren mit Telemetriedaten

• Begründung: Bestätigen Sie das Verhalten unter Last. Verwenden Sie:
  • show sdwan app-route statistics, um die SLA-Pfadauswahl zu überprüfen.
  • show policy qos-queue / show policy-map interface, um die Warteschlangenauslastung und Drops zu bewerten.
  • show ip igmp groups und show sdwan omp services für Multicast-Joins und Service-Routen. Passen Sie die Shaper-Raten und Warteschlangengewichtungen an, um Tail-Drops bei Sprache/Video zu eliminieren und gleichzeitig eine akzeptable Latenz für kritische Daten aufrechtzuerhalten.

8. Leitplanken und Anomaliebehandlung

• Begründung: Wiederauftreten verhindern und Regressionen erkennen. Wenden Sie Ingress-Policer auf nicht vertrauenswürdigen LAN-Segmenten an, um falsch markierten Verkehr zu drosseln, begrenzen Sie die Rate von IGMP, um die CPU der Steuerungsebene zu schützen, und richten Sie Alarme für AAR-SLA-Verletzungen und Queue-Drop-Zähler ein, um eine proaktive Behebung auszulösen.

Diese Abfolge stellt sicher, dass NorthRiver Health die Geschäftsabsicht in konsistentes, transportbewusstes QoS und zuverlässige Multicast-Zustellung umsetzt. Sprache erhält eine strikte, begrenzte Behandlung; Video und EMR erhalten priorisierte, gewichtete Bandbreite; Pfade werden anhand von Live-SLA-Messungen ausgewählt; und Multicast wird effizient repliziert, ohne die Zweigstellenleitungen zu überlasten.

← Sicherheit · Alle Domänen · Cloud →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →