Cisco 300-415: Data-Plane-Tunnel, BFD und anwendungsorientiertes Routing — 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

Cisco SD-WAN trennt die Kontrollebene von der Datenebene und baut ein verschlüsseltes, richtliniengesteuertes Overlay über unterschiedliche Transportwege hinweg auf. Der vSmart-Controller verwaltet die Kontrollebene des Overlays und die Konnektivität der WAN-Edges und verteilt Routen, Sicherheitsschlüssel und Absichten (Intent) über OMP. WAN-Edge-Router bilden sichere IPsec-Tunnel auf der Datenebene zu anderen WAN-Edges, während die Kontrollverbindungen zu vSmart, vBond und vManage standardmäßig DTLS (oder TLS) verwenden. Die Erreichbarkeit und Qualität der Pfade werden kontinuierlich mit BFD gemessen. Diese Daten fließen in die Richtlinien des Application-Aware Routing (AAR) ein, um Anwendungen gemäß den SLA-Klassen (basierend auf Verlust, Latenz, Jitter oder MOS) über die leistungsstärksten Tunnel zu leiten.

Grundlagen des Overlays und der Datenebene

• Kontrollebene versus Datenebene

  • Kontrollebene: WAN-Edges stellen sichere DTLS/TLS-Kontrollverbindungen zu vBond (für NAT-Traversal und Orchestrierung), vSmart (Austausch von Richtlinien und Routen über OMP) und vManage (Verwaltung, Gerätekonfiguration und Zertifikatsspeicherung) her. Im Staging-Zustand bauen Geräte Kontrollverbindungen auf, aber noch keine Datentunnel.
  • Datenebene: WAN-Edges bilden IPsec-Tunnel direkt zu anderen WAN-Edges für den Benutzerverkehr. Die Datenebene ist für die Weiterleitung zuständig und setzt die Traffic-Engineering-Entscheidungen durch, die über die Richtlinien der Kontrollebene übermittelt werden.

• IPsec-Tunnel der Datenebene und TLOCs

  • Ein Transport Locator (TLOC) identifiziert eindeutig eine WAN-Transportanbindung und wird durch das Tupel {system-IP, color, encapsulation} definiert. Die Kapselung ist IPsec oder GRE; in den meisten Bereitstellungen und auf IOS XE SD-WAN (cEdge) wird IPsec verwendet.
  • Farben (Colors) sind semantische Bezeichnungen für Underlay-Typen und NAT-Eigenschaften (z. B. mpls, biz-internet, public-internet, lte, private1–private6). Öffentliche Farben (Public Colors) implizieren typischerweise ein NAT-Traversal mit Unterstützung durch vBond.
  • Tunnel werden zwischen jedem erreichbaren Paar von TLOCs gebildet, sofern sie nicht eingeschränkt sind. Bei zwei Standorten mit je einem WAN-Edge und zwei öffentlichen TLOCs und ohne Restrict-Attribute werden vier IPsec-Tunnel gebildet (Full-Mesh zwischen den Farbpaaren).
  • Die TLOC-Erweiterung (TLOC Extension) ermöglicht es zwei redundanten WAN-Edges an einem Standort, Transportwege über einen Cross-Link gemeinsam zu nutzen, was Transportredundanz ermöglicht, ohne physische Leitungen pro Chassis duplizieren zu müssen.

• Transport- und Service-Labels

  • vSmart verwendet OMP, um Routen und TLOCs zu annoncieren und Labels zuzuweisen, die im Overlay-Header mitgeführt werden. Transport-Labels identifizieren entfernte TLOCs für das Demultiplexing des Verkehrs über das Overlay. Service-Labels identifizieren das Ziel-Service-VPN oder einen verketteten Dienst (Chained Service). Diese Labels sind intern im SD-WAN-Overlay und sind keine MPLS-Underlay-Labels.

• Operative Abwägungen und Fehlermodi

  • Falsch deklarierte Transporte (z. B. die Kennzeichnung von MPLS als public-internet) können zu einer suboptimalen Tunnelbildung oder zu Fehlern beim NAT-Traversal führen.
  • Das restrict-Attribut verhindert ein unerwünschtes Wachstum des Full-Mesh; wird es bei Internet-Farben weggelassen, kann dies zu einer übermäßigen Tunnelskalierung und unnötigem Probing-Overhead führen.
  • Zertifikats- oder Zeitprobleme verhindern die Konnektivität der Kontrollebene (DTLS/TLS). Ohne die Konvergenz der Kontrollebene mit vSmart werden keine Schlüssel für die Datenebene ausgetauscht und es werden keine IPsec-Tunnel gebildet.

BFD-Pfaderreichbarkeit und Qualitätsmessung

• BFD-Betrieb

  • Cisco SD-WAN führt BFD auf jedem Tunnel der Datenebene aus, um eine Erreichbarkeitserkennung und Qualitätsmessung nahezu in Echtzeit zu ermöglichen. BFD verwendet leichtgewichtige, periodische Hellos, um den Up/Down-Zustand (Blackouts) zu erkennen, und aktive Probes, um Latenz, Jitter und Verlust (Brownouts) zu messen.
  • Wichtige Timer und Intervalle
    • Hello-Intervall: üblicherweise 1000 ms (pro Farbe oder global konfigurierbar).
    • Multiplikator: üblicherweise 6 (konfigurierbar), was eine Erkennungszeit von Hello-Intervall × Multiplikator ergibt (z. B. ~6 Sekunden).
    • App-Probe-Intervall für die AAR-Leistungsmessung: typischerweise 1 Sekunde (konfigurierbar), wobei gleitende Durchschnittswerte über ein kurzes Fenster berechnet werden, um kurzzeitige Spitzen zu glätten.
  • BFD-Messwerte
    • Latenz: Round-Trip-Time der Probes auf jedem Tunnel.
    • Jitter: Schwankung der Latenz zwischen den Probes.
    • Verlust: Prozentsatz der nicht zurückgesendeten Probes.
    • MOS: abgeleitet aus Latenz, Jitter und Verlust zur Bewertung der Eignung für Sprachübertragung.

• Umgang mit Brownouts im Vergleich zu Blackouts

  • Blackout: Eine ausgefallene BFD-Sitzung (keine Konnektivität) löst die sofortige Entfernung des Pfades aus dem Forwarding aus. Der Verkehr wird gemäß der Präferenz des nächstverfügbaren Tunnels umgeleitet, ohne auf eine AAR-Auswertung zu warten.
  • Brownout: BFD bleibt aktiv, aber die gemessenen Metriken verletzen die SLA-Schwellenwerte. AAR kann spezifische Anwendungs-Flows auf alternative Tunnel umleiten, die die SLAs erfüllen, auch während der ursprüngliche Tunnel weiterhin anderen Verkehr transportiert.

• Design-Richtlinien und Abwägungen

  • Aggressive Timer beschleunigen das Failover, erhöhen aber den CPU- und Bandbreiten-Overhead, insbesondere in großen Mesh-Netzwerken. Stimmen Sie die Hello- und Probe-Intervalle auf die Skalierung und die Stabilität des Transports ab.
  • Asymmetrische Pfadeigenschaften (z. B. Satellit oder Mobilfunk) erfordern lockerere SLA-Schwellenwerte und potenziell höhere Multiplikatoren, um Flapping zu vermeiden.
  • Für Sprach- und interaktive Anwendungen sollten schnellere App-Probe-Intervalle und die Aktivierung von Hysterese/Hold-Down bevorzugt werden, um Oszillationen bei vorübergehender Überlastung zu reduzieren.

Anwendungsorientiertes Routing: Richtlinien- und SLA-Design

• Anwendungserkennung und -klassifizierung

  • WAN-Edges verwenden DPI (NBAR2 auf IOS XE SD-WAN), um Anwendungen anhand von Signaturen, Protokoll-Heuristiken und, wo verfügbar, Metadaten wie TLS SNI und QUIC ALPN zu klassifizieren. Bei verschlüsseltem Datenverkehr ohne identifizierbare Metadaten greift die Engine auf Flow-Attribute (5-Tupel) und konfigurierte Zuordnungen (Ports, DSCP) zurück.
  • Die Klassifizierung erfolgt typischerweise bei den ersten Paketen und wird zur Gewährleistung der Sitzungskonsistenz zwischengespeichert. Halten Sie die Signaturen aktuell, um die Genauigkeit aufrechtzuerhalten.

• SLA-Klassen und Messrichtlinien

  • Definieren Sie SLA-Klassen mit Schwellenwerten für Verlust (Loss), Latenz (Latency), Jitter und optional MOS. Jede SLA-Klasse referenziert ein Performance-Probe-Profil (app-probe), das das Abtastintervall und das Glättungsverhalten von BFD steuert.
  • Typische SLA-Beispiele:
    • Voice: Latenz ≤ 150 ms, Jitter ≤ 30 ms, Verlust ≤ 1 %, MOS ≥ 4.0.
    • Transaktional: Latenz ≤ 200 ms, Verlust ≤ 1 %.
    • Bulk: kein striktes SLA; Pfade mit höherer Bandbreite und geringeren Kosten werden bevorzugt.

• Pfadpräferenzverhalten

  • Eine AAR-Richtlinie verknüpft Anwendungslisten mit SLA-Klassen und legt eine bevorzugte Farbe (preferred-color) und eine Backup-Farbe (backup-color) (oder TLOC-Listen) fest. Die Entscheidungslogik:
    1. Wenn der bevorzugte Pfad das SLA erfüllt, wird der Datenverkehr über den bevorzugten Pfad gesendet.
    2. Wenn der bevorzugte Pfad das SLA verletzt, der Backup-Pfad es aber erfüllt, wird der Datenverkehr auf den Backup-Pfad gelenkt.
    3. Wenn kein Pfad das SLA erfüllt, wird der beste verfügbare Pfad nach Präferenz oder Kosten verwendet (graceful degradation).
  • Das Brownout-Steering erfolgt pro Flow; bestehende Flows können je nach Richtlinie verschoben werden (Standard ist das Steuern neuer Flows; eine Verschiebung mitten im Flow kann für TCP eingeschränkt sein, es sei denn, es ist eine Sitzungsresilienz vorgesehen).

• Elemente zur Richtlinienerstellung

  • Erstellen Sie in vManage Anwendungslisten (DPI-Gruppen), SLA-Klassen (Verlust/Latenz/Jitter/MOS) und TLOC-Listen (Farben). Erstellen Sie dann eine AAR-Richtliniensequenz, die eine Zuordnung von Anwendungsliste → SLA-Klasse → bevorzugte/Backup-Farben vornimmt.
  • Kombinieren Sie dies mit Traffic-Data-Policies, wenn Sie DSCP setzen, Zonen erzwingen oder Service Chaining vor den AAR-Entscheidungen einfügen müssen.
  • Verwenden Sie Control-Policies separat, um die Annahme/Verbreitung von Routen zu beeinflussen; vermischen Sie AAR (Data-Policy) nicht mit Control-Policies. Standortlisten (Site lists) definieren den Geltungsbereich, in dem AAR angewendet wird.

• Design-Abwägungen

  • Übermäßig strikte SLAs können zu Oszillationen führen. Führen Sie eine Hysterese oder Penalty-Timer ein, um häufige Pfadwechsel zu vermeiden.
  • Berücksichtigen Sie die Kosten: Platzieren Sie getaktete Mobilfunkpfade (metered cellular paths) nur als letzte Backup-Option; aktivieren Sie Datenlimits (data caps), wo verfügbar.
  • Stimmen Sie sich mit QoS ab: AAR wählt den Pfad aus; QoS und Queueing pro Pfad müssen weiterhin kritische Klassen bei Überlastung schützen.

Verifizierung und Fehlerbehebung

• Schnelle Systemdiagnosen

  • Control-Plane:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Data-Plane-Tunnel:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • BFD-Sitzungen und -Qualität:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Beispiel-Befehls-Snippets

  show sdwan tunnels
  show sdwan bfd sessions
  show sdwan app-route stats sla-class <name>
  show sdwan app-route statistics flows
  show sdwan omp tlocs

  show control connections
  show omp routes | include <prefix>
  show ipsec sa detail

• Worauf zu achten ist

  • Tunnelstatus ist „up“, aber BFD-Verlust/Latenz/Jitter überschreitet das SLA: Brownout – AAR-Steuerung ist zu erwarten. Validieren Sie, dass der Backup-Pfad das SLA erfüllt und die Richtlinie die korrekte App-Liste bindet.
  • BFD-Sitzung ist instabil (flapping): Reduzieren Sie die Aggressivität oder untersuchen Sie Drops/Queuing im Underlay; überprüfen Sie MTU und Fragmentierung (Umgang mit dem DF-Bit), um den Verlust von Probes zu vermeiden.
  • Keine Tunnel über einen Color gebildet: Überprüfen Sie die Semantik des Colors (NAT/öffentlich/privat), die NAT-Konfiguration des Interfaces und ob vBond für das NAT-Traversal erreichbar ist. Bestätigen Sie Zeit und Zertifikate, falls keine Control-Verbindungen vorhanden sind.
  • Unerwartetes Full-Mesh und hohe Anzahl an Probes: Wenden Sie „restrict“ auf Internet-Colors an oder verwenden Sie TLOC-Listen, um den Konnektivitätsbereich einzuschränken.
  • DPI-Fehlklassifizierung: Aktualisieren Sie die NBAR2-Signaturen und stellen Sie sicher, dass keine widersprüchlichen L4-Port-Überschreibungen vorhanden sind. Ziehen Sie für verschlüsselte Apps eine Klassifizierung auf Basis von SNI/ALPN oder ein DSCP-Marking Upstream in Betracht.

• Operative Überlegungen

  • Validieren Sie immer zuerst die Control-Konnektivität (vBond für Orchestrierung/NAT, vSmart für OMP/Policy, vManage für Konfiguration/Zertifikate). Ohne vSmart werden keine Data-Plane-Schlüssel verteilt und es wird keine IPsec SA gebildet.
  • Korrelieren Sie AAR-Entscheidungen mit BFD-Messungen und SLA-Klassen. Wenn ein Pfad entgegen der Erwartung ausgewählt wird, überprüfen Sie den SLA-Konformitätsstatus zum Zeitpunkt der Entscheidung, nicht nur die aktuellen Durchschnittswerte.
  • Vermeiden Sie bei Dual-DC-Designs doppelte LAN-Routen, indem Sie das Overlay-AS auf den DC WAN Edges harmonisieren, wenn OMP↔BGP über einen DC-Interconnect umverteilt wird.

Praktisches Problemszenario

Contoso Health betreibt 300 Kliniken mit dualen Transportwegen an jedem Standort: MPLS (Color „mpls“) und Breitband (Color „biz-internet“). Benutzer melden zeitweise schlechte Sprachqualität, während Datenanwendungen einwandfrei funktionieren. Das Ziel ist, MPLS für Sprache zu bevorzugen, bei Brownouts auf Breitband auszuweichen und ein schnelles Failover bei Blackouts ohne Oszillation sicherzustellen.

1. Overlay-Zustand und Data-Plane-Aufbau validieren

• Begründung: Bestätigen Sie die Voraussetzungen. Verwenden Sie show sdwan control connections, um sicherzustellen, dass DTLS/TLS zu vSmart/vBond/vManage stabil ist, und show sdwan tunnels, um das vollständige Tunnel-Mesh über MPLS und Breitband zu verifizieren. Wenn Tunnel über „biz-internet“ fehlen, überprüfen Sie die Color-Zuweisung und NAT; vBond muss im öffentlichen Raum erreichbar sein, um das NAT-Traversal zu unterstützen.

2. BFD- und Probe-Timer kalibrieren

• Begründung: Setzen Sie das BFD-Hello-Intervall auf 1000 ms und den Multiplikator auf 6 für eine ausgewogene Liveness-Erkennung (~6 s) und eine angemessene Skalierung. Konfigurieren Sie das App-Probe-Intervall auf 1 s für eine zeitnahe Brownout-Erkennung. Übermäßig aggressive Timer können zu CPU-Overhead und Flapping führen; zu lockere Einstellungen beeinträchtigen die Reaktionsfähigkeit für Sprachanwendungen.

3. SLA-Klassen definieren

• Begründung: Erstellen Sie eine SLA-Klasse Voice-SLA mit einer Latenz ≤ 150 ms, Jitter ≤ 30 ms, Verlust ≤ 1 % und MOS ≥ 4.0. Erstellen Sie eine Data-SLA mit einer Latenz ≤ 200 ms und einem Verlust ≤ 1 %. Diese Schwellenwerte spiegeln die Empfindlichkeit von Sprache und die typische WAN-Performance wider; der MOS-Wert fasst die Benutzererfahrung über mehrere Metriken hinweg zusammen.

4. Anwendungslisten erstellen

• Begründung: Verwenden Sie DPI (NBAR2), um eine App-List-Voice für SIP/RTP/Teams/Zoom-Medien und eine App-List-Data für transaktionale Anwendungen zu definieren. Fügen Sie TLS SNI/QUIC ALPN-Muster für moderne Sprach-/Videoplattformen hinzu. Wo die Klassifizierung unsicher ist, greifen Sie auf DSCP EF/AF41-Markierungen zurück, die am LAN-Edge durchgesetzt werden.

5. AAR-Richtlinie erstellen

• Begründung: Weisen Sie App-List-Voice der Voice-SLA mit preferred-color mpls und backup-color biz-internet zu. Weisen Sie App-List-Data der Data-SLA mit preferred-color biz-internet und backup-color mpls zu, um die MPLS-Bandbreite zu schonen. Dies stellt sicher, dass Sprache bei gutem Zustand MPLS nutzt und nur bei Brownouts oder Blackouts auf Breitband wechselt, während Daten das kostengünstigere Internet bevorzugen.

6. Hysterese und Hold-Down hinzufügen

• Begründung: Konfigurieren Sie einen Revert-Timer, damit der Sprachverkehr erst nach anhaltender SLA-Konformität (z. B. 30–60 s) zu MPLS zurückkehrt. Dies vermeidet Oszillationen bei vorübergehenden Jitter-Spitzen. Wenden Sie in ähnlicher Weise eine Penalty oder Dämpfung auf den Breitbandanschluss an, wenn dieser wiederholt innerhalb eines kurzen Zeitfensters das SLA verletzt.

7. QoS und MTU koordinieren

• Begründung: Stellen Sie auf beiden Transportwegen sicher, dass EF-Queuing und Shaping auf die Leitungsraten abgestimmt sind. Eine Nichtübereinstimmung kann den von BFD-Probes und Sprach-RTP gemessenen Jitter/Verlust erhöhen. Validieren Sie die Path MTU und deaktivieren Sie das DF-Bit, wo Fragmentierung unvermeidlich ist, um Probe-Drops zu verhindern, die fälschlicherweise als Verlust interpretiert werden.

8. Überprüfen und iterieren

• Begründung: Verwenden Sie show sdwan app-route stats sla-class Voice-SLA, um den SLA-Erfolg/Misserfolg pro Tunnel zu bestätigen. Beobachten Sie Live-Flows mit show sdwan app-route statistics flows, um sicherzustellen, dass der Sprachverkehr auf MPLS geleitet wird und nur dann auf Breitband wechselt, wenn MPLS das SLA verletzt. Überlasten Sie während der Tests absichtlich die MPLS-Leitung, um das Brownout-Verhalten zu validieren, und messen Sie anschließend das Timing für die Rückkehr zum primären Pfad.

Durch Befolgen dieser Schritte stellt Contoso Health sicher, dass BFD eine schnelle Blackout-Erkennung bietet, AAR mithilfe präziser SLA-Klassen auf Brownouts reagiert und DPI Sprachanwendungen genau klassifiziert. Diese Kombination führt zu einer vorhersagbaren Sprachqualität, einer effizienten Nutzung der Transportwege und einem steuerbaren Failover-Verhalten im gesamten SD-WAN-Fabric.

← WAN-Edge-Konfiguration und Template-Management · Alle Domänen · Zentralisierte Richtlinien und Traffic Engineering →

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