Cisco 300-415: Zentralisierte Richtlinien und Traffic Engineering — 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

Zentralisierte Richtlinien in Cisco SD-WAN sind das Framework, das es Ihnen ermöglicht, das Verkehrsverhalten und die Routing-Absicht von vSmart-Controllern aus über die gesamte Fabric zu programmieren. vSmart, der die Overlay-Steuerungsebene über OMP verwaltet, verteilt zentralisierte Steuerungsrichtlinien (für OMP-Routen und TLOCs) und Richtlinien für die Datenebene wie Daten-, anwendungsbezogenes Routing (App-Route) und cflowd. Diese Richtlinien formen die Topologie (Hub-and-Spoke, Mesh-Einschränkung), wählen Pfade basierend auf der Anwendungsleistung aus, leiten Datenflüsse zu Diensten und segmentieren den Verkehr nach VPN. Da Richtlinien sowohl die Erreichbarkeit der Steuerungsebene als auch die Weiterleitung auf der Datenebene verändern können, sind sorgfältiges Design, Vorschau und eine gestaffelte Bereitstellung unerlässlich, um Ausfälle zu vermeiden.

Typen und Bausteine zentralisierter Richtlinien

• Zentralisierte Steuerungsrichtlinie (Centralized control policy)

  • Geltungsbereich: Steuerungsebene (OMP) zwischen WAN-Edge-Geräten und vSmart.
  • Zweck: Filtern/Modifizieren von OMP-Routen und TLOC-Advertisements, Setzen von Attributen (Präferenz, Tag, Ursprung, TLOC) und Aufbau von Topologien (Hub-and-Spoke, Partial Mesh).
  • Richtung: Eingehend (zu vSmart vom WAN Edge) und ausgehend (von vSmart zum WAN Edge).

• Zentralisierte Datenrichtlinie (Centralized data policy)

  • Geltungsbereich: Klassifizierung auf der Datenebene (L3/L4, Felder, App-ID) am WAN Edge, installiert durch vSmart.
  • Zweck: Erlauben/Verweigern von Datenflüssen, Setzen von VPN, Setzen von TLOC, Setzen von DSCP/Markierung, Policing, Spiegelung und Service Insertion/Chaining.
  • Richtung: Wird am WAN Edge relativ zur Dienstseite (LAN) oder Tunnelseite (WAN) ausgewertet, je nachdem, wo sie programmiert ist; Designs zielen typischerweise auf den Ingress auf der Dienstseite für Benutzer-zu-WAN-Flüsse und auf die Tunnelseite für den Rückverkehr, wenn symmetrisches Verhalten erforderlich ist.

• Anwendungsbezogene Routing-Richtlinie (Application-aware routing (app-route) policy)

  • Geltungsbereich: Pfadauswahl auf der Datenebene basierend auf Anwendung und SLA (Verlust, Latenz, Jitter), gemessen durch BFD.
  • Zweck: Leiten des Verkehrs zu bevorzugten TLOCs/Colors, Definieren von sondengestützten SLA-Klassen, Festlegen von Fallbacks und Durchführung von dynamischem Traffic Engineering pro Anwendung/Familie.
  • Schlüsselverhalten: Wertet kontinuierlich die Pfadleistung aus; kann Pfade wechseln, wenn sich das SLA verschlechtert.

• cflowd-Richtlinie

  • Geltungsbereich: Flow-Telemetrie (IPFIX/NetFlow-ähnlich), die von WAN Edges erzeugt wird.
  • Zweck: Aktivieren/Deaktivieren von Exportern pro VPN, Definieren von Abtastraten, Vorlagen und Kollektoren (vManage oder extern).
  • Designhinweis: Das Sampling muss einen Ausgleich zwischen Sichtbarkeit und CPU-/Bandbreiten-Overhead schaffen; die Aktivierung pro VPN unterstützt ein segmentiertes Reporting.

Richtlinienlisten sind wiederverwendbare Abgleichobjekte:

• Site list: Site-IDs, die verwendet werden, um auszuwählen, wo Richtlinien angehängt werden, und um Routenursprungs-/-ziel-Sites abzugleichen.
• VPN list: VRFs (VPNs), die zur Segmentierung des Richtlinienbereichs und zum Erstellen von Regeln pro Segment verwendet werden.
• Prefix list: IP-Präfixe zum Abgleich von OMP-Routen oder Datenverkehr.
• Data prefix list: Spezialisiertes Präfixobjekt für die Klassifizierung von Datenrichtlinien.
• TLOC list: Tupel aus System-IP, Color und Kapselung, die zum Abgleichen oder Setzen von TLOC-Attributen verwendet werden.
• Color list: Eine oder mehrere Transport-Colors (z. B. biz-internet, mpls, public-internet) für Targeting/Link-Affinität.
• Application list: NBAR2-Anwendungen/-Gruppen zur Klassifizierung des Verkehrs für App-Route- oder Datenrichtlinien.
• SLA class: Latenz-, Verlust- und Jitter-Schwellenwerte, die mit App-Route für leistungsbasiertes Steering verknüpft sind.

Struktur und Auswertung von Richtliniensequenzen:

• Sequenzen sind geordnet, der erste Treffer gewinnt. Jede Sequenz hat:
  • Abgleichbedingungen: Listen/Felder (Site/VPN/Präfix/TLOC/Color/App, L4-Ports, DSCP, Protokoll).
  • Aktionen: Akzeptieren/Verweigern, Setzen von Attributen (TLOC, VPN, DSCP, Präferenz, Tag), Service Insertion, Police, Mirror.
• Standardaktion: Wird angewendet, wenn keine Sequenz übereinstimmt. Gängige Standardeinstellungen sind „accept“ (Steuerung/Daten), um unbeabsichtigte Drops zu vermeiden; explizite „deny“-Standardeinstellungen werden bewusst verwendet und erfordern eine sorgfältige Validierung.
• Richtung:
  • Die Richtung der Steuerungsrichtlinie befindet sich bei vSmart (eingehendes/ausgehendes OMP).
  • Daten- und App-Route-Richtlinien wirken auf den Verkehr am WAN Edge; wählen Sie das Verhalten auf der Dienst- oder Tunnelseite, um den zu beeinflussenden Datenfluss anzupassen, und stellen Sie die Symmetrie des Rückverkehrs sicher, wenn stateful Dienste im Pfad liegen.

Design von Control-Plane-Richtlinien und Manipulation von Routen/TLOCs

Control-Richtlinien sind das maßgebliche Werkzeug zur Gestaltung der Overlay-Topologie, da sie bestimmen, welche OMP-Routen und TLOCs ein Standort senden oder empfangen kann:

• Manipulation von OMP-Routen

  • Verwenden Sie eingehende Control-Richtlinien, um Routen, die von einem Standort gelernt werden, zu filtern, zu taggen oder deren Attribute zu setzen, bevor sie in die Overlay-RIB bei vSmart gelangen.
  • Verwenden Sie ausgehende Control-Richtlinien, um zu begrenzen, welche Routen an bestimmte Standorte angekündigt werden (z. B. keine von Spokes gelernten Präfixe an andere Spokes ankündigen).
  • Häufige Aktionen: Präferenz setzen (beeinflusst den besten OMP-Pfad), Tag setzen (für nachfolgendes Matching), Ursprung (Origin) setzen, Einschränkungen für den Ursprungsstandort (Site-of-Origin) festlegen.

• Manipulation von TLOCs

  • Abgleich mit TLOC-Attributen (System-IP, Color, Encap), um bestimmte Transportwege zu filtern oder zu bevorzugen.
  • Zu den Aktionen gehört das Ändern bevorzugter TLOC-Attribute oder Präferenzen, sodass Routenankündigungen eine bestimmte Color bevorzugen (z. B. MPLS für kritische Subnetze bevorzugen).
  • Kompromiss: Eine zu aggressive TLOC-Filterung kann Standorte isolieren, wenn der verbleibende Transportweg ausfällt. Bevorzugen Sie die Anpassung von Attributen gegenüber einer pauschalen Ablehnung (Deny), es sei denn, Sie haben redundante Pfade.

• Topologie-Muster

  • Hub-and-Spoke: Eine ausgehende Control-Richtlinie von vSmart zu den Spokes verhindert die Ankündigung von Routen, die von Spokes stammen, an andere Spokes; Hubs empfangen und kündigen alle an.
  • Mesh-Einschränkung: Ähnlich wie Hub-and-Spoke, erlaubt aber bestimmte Spoke-zu-Spoke-Paare (z. B. regionale Meshes) durch Ausnahmen in den Richtliniensequenzen.
  • Segmentierung: Kombinieren Sie VPN-Listen mit Routenfilterung, um die Overlays pro VPN isoliert zu halten; kündigen Sie nur Standardrouten oder ausgewählte Präfixe an eingeschränkte Standorte an.

Fehlermodi und Kompromisse:

• Eine falsch angewendete ausgehende Control-Richtlinie mit einem standardmäßigen „Deny“ kann kritische Routen zurückziehen und Standorte isolieren. Verwenden Sie immer standardmäßig „Accept“ und fügen Sie gezielte „Denies“ hinzu, es sei denn, Ihre Vorschau bestätigt explizit die Abdeckung.
• Das Ändern von OMP-Attributen in großem Umfang kann zu Route Churn führen; führen Sie die Bereitstellung gestaffelt nach Standortlisten durch, um den Schock für die Control-Plane zu reduzieren.
• Das Umschreiben von TLOC-Attributen kann zu asymmetrischem Forwarding führen, wenn der Rückweg nicht in gleicher Weise beeinflusst wird; validieren Sie beide Richtungen.

Application-Aware Routing, Service Insertion und Segmentierung

Anwendungsorientiertes Routing (AAR) und Data-Richtlinien ermöglichen zusammen ein feingranulares Traffic Engineering:

• AAR und Traffic Steering

  • SLA-Klassen definieren akzeptable Werte für Verlust/Latenz/Jitter; BFD-Probes pro TLOC-Paar liefern Echtzeitmessungen.
  • App-Route-Richtlinien gleichen Anwendungen oder L3/L4-Felder ab und wählen bevorzugte Color/TLOC-Listen aus; bei einer SLA-Verletzung erfolgt ein Failover gemäß der Richtlinie.
  • Design-Tipps:
    • Vermeiden Sie zu enge SLA-Schwellenwerte, die zu „Flapping“ führen; integrieren Sie eine Hysterese durch Sonden-Multiplikatoren und angemessene Schwellenwerte.
    • Für Anwendungen, die empfindlich auf Paket-Umsortierung reagieren, bevorzugen Sie „Wechsel beim nächsten neuen Flow“ anstelle von Wechseln mitten im Flow, oder pinnen Sie Flows mittels Consistent Hashing, wo dies unterstützt wird.
    • Wenn sowohl AAR als auch eine Data-Richtlinie den TLOC festlegen, geben Sie AAR den Vorrang bei der Pfadauswahl und verwenden Sie die Data-Richtlinie für Service Insertion/Markierung; vermeiden Sie überlappende Aktionen in derselben Verkehrsklasse.

• Service Chaining und Service Insertion

  • Die Data-Richtlinien-Aktion „Service“ leitet den Verkehr durch On-Prem- oder Colocation-Dienste (Firewall, IDS/IPS, SD-WAN Service Nodes).
  • Ketten Sie bei Bedarf mehrere Dienste nacheinander (Chain); stellen Sie eine symmetrische Einfügung für zustandsbehaftete (stateful) Dienste sowohl auf dem Hin- als auch auf dem Rückweg sicher.
  • Kompromisse: Jeder Service-Hop fügt Latenz und potenzielle Fehlerdomänen hinzu. Implementieren Sie Health Checks und ein Fail-Open/Closed-Verhalten, das mit der Sicherheitsstrategie (Security Posture) übereinstimmt.

• Verkehrssegmentierung

  • VPNs bieten eine harte Segmentierung; zentralisierte Richtlinien werden pro VPN mithilfe von VPN-Listen angewendet.
  • Inter-VPN-Routing (Route Leaking) kann mit einer Data-Richtlinie durch „set VPN“ für bestimmte Flows erreicht werden; schränken Sie dies streng durch Abgleiche von Präfixen/Anwendungen ein und überprüfen Sie es regelmäßig.
  • Für gemeinsam genutzte Dienste (z. B. DNS, Identität) kündigen Sie Dienst-Präfixe von einem Dienste-VPN an die konsumierenden VPNs mittels einer Control-Richtlinie an, anstatt breite Leaks in der Data-Plane zu verwenden.

Beispiel-Snippet einer App-Route zur Veranschaulichung des SLA-basierten Steerings:

app-route-policy CRITICAL-APPS
  sequence 10
    match application-list BUS_APPS
    sla-class GOLD
    preferred-color mpls fallback biz-internet
  !
  sequence 20
    match application-list BEST_EFFORT
    sla-class BRONZE
    preferred-color biz-internet fallback public-internet
  !
  default-action accept
!

Betrieb: Anfügen, Validierung und Fehlerbehebung

Anfügen von Richtlinien über vSmart:

• Definieren Sie zentrale Richtlinien in vManage und fügen Sie sie an Standort- und VPN-Listen an. vSmart kompiliert die Richtlinie und verteilt sie über sichere DTLS/TLS OMP-Sitzungen in VPN 0 an die WAN Edges.
• Planen Sie Änderungen am Geltungsbereich sorgfältig; eine einzelne Richtlinieninstanz kann Hunderte von Standorten betreffen. Verwenden Sie Standortlisten, um Bereitstellungen nach Region oder Funktion gestaffelt durchzuführen.

Richtliniensimulation, Vorschau und gestaffelte Bereitstellung:

• Vorschau: Verwenden Sie vor der Aktivierung die Vorschau in vManage, um die gerätespezifische kompilierte Richtlinie zu überprüfen (was jeder WAN Edge erhalten wird). Bestätigen Sie die Match/Action-Logik, Standardaktionen und Richtungen.
• Simulation: Verwenden Sie die Richtliniensimulation, um Flow-Übereinstimmungen und erwartete Aktionen zu testen (z. B. welchen TLOC eine bestimmte App/ein 5-Tupel verwenden wird). Validieren Sie die Zuordnungen von SLA-Klassen und die Anwendungsklassifizierung.
• Gestaffelte Bereitstellung:
  • 1. An eine Canary-Standortliste (wenige Standorte) anfügen.
  • 2. Überwachen Sie KPIs der Control- und Data-Plane (Anzahl der OMP-Routen, BFD, App-Route-Treffer).
  • 3. Erweitern Sie die Standortliste schrittweise.
• Versionierung und Rollback: Behalten Sie frühere Richtlinienversionen bei; wenn unerwartetes Verhalten festgestellt wird, deaktivieren Sie die neue Richtlinie oder führen Sie umgehend ein Rollback auf die vorherige Version durch.

Fehlerbehebung bei unbeabsichtigten Ergebnissen und Vorrangregeln:

• Verifizierung der Control-Plane

  • show omp tlocs, show omp routes: Bestätigen Sie das Vorhandensein/Fehlen von Routen und TLOCs gemäß der Richtlinienabsicht.
  • show policy received/installed: Überprüfen Sie die Zähler der Control-Policy und welche Sequenzen übereinstimmten.
  • Symptom: Spokes können andere nach der Bereitstellung nicht erreichen → überprüfen Sie die ausgehenden Control-Policy-Deny-Zeilen zu den Spokes und die Standardaktionen.

• Verifizierung der Data-Plane und AAR

  • show app-route stats/flows und show bfd sessions: Validieren Sie den SLA-Status und Pfadentscheidungen.
  • show sdwan policy service-path oder Äquivalent: Bestätigen Sie die Zähler für die Service-Einfügung und die Reihenfolge der Verkettung.
  • show ip route vpn X und traceroute vpn X: Überprüfen Sie den tatsächlichen Weiterleitungspfad.
  • Symptom: Unerwartete Pfadänderungen/Flapping → lockern Sie die SLA oder passen Sie die Probe-Multiplikatoren an; stellen Sie sicher, dass keine überlappende Datenrichtlinie ebenfalls den TLOC festlegt.

• Vorrang von Richtlinien und Konflikte

  • AAR-Entscheidungen haben in der Regel Vorrang bei der Pfadauswahl; verwenden Sie Datenrichtlinien hauptsächlich für Service-Einfügung, Markierung und Zugriffskontrolle.
  • Überlappende Übereinstimmungskriterien über Richtlinien hinweg können zu Mehrdeutigkeiten führen. Halten Sie die Übereinstimmungsdomänen gegenseitig exklusiv oder führen Sie eine Reihenfolge und Tags ein, um Mehrdeutigkeiten zu beseitigen.
  • Ein standardmäßiges Akzeptieren kann fehlende Sequenzen verschleiern; fügen Sie explizite „observe-only“-Zähler (z. B. mirror/police low) oder temporäres Logging hinzu, um Übereinstimmungen zu validieren, bevor Sie Deny-Regeln durchsetzen.

• cflowd-Validierung

  • show cflowd statistics/exporters: Stellen Sie sicher, dass die Exporter pro VPN aktiv sind und wie beabsichtigt sampeln.
  • Hohe CPU-Auslastung nach Aktivierung von cflowd → erhöhen Sie das Sampling-Intervall oder beschränken Sie es auf wesentliche VPNs/Anwendungen.

Praktisches Problemszenario

Northwind Traders migriert zu Cisco SD-WAN und muss eine Hub-and-Spoke-Topologie für PCI-VPNs durchsetzen, Office 365 auf den besten Internetpfad lenken und einen regionalen Firewall-Service für Gast-Traffic einfügen, ohne kritische Anwendungen zu beeinträchtigen.

Vorgehensweise:

1. Richtlinienlisten erstellen

   • Erstellen Sie Standortlisten: HUBS (Rechenzentren), SPOKES (Zweigstellen).
   • Erstellen Sie VPN-Listen: PCI_VPN, GUEST_VPN, CORP_VPN.
   • Erstellen Sie Anwendungslisten: O365, BEST_EFFORT.
   • Erstellen Sie Color-Listen: PRIVATE (mpls), DIA (biz-internet, public-internet). Begründung: Wiederverwendbare Listen ermöglichen einen präzisen Geltungsbereich und einen sicheren, gestaffelten Rollout; die Trennung von VPNs unterstützt die Segmentierung.

2. SLA-Klassen definieren

   • GOLD: Verlust 0,5 %, Latenz 100 ms, Jitter 20 ms.
   • SILVER: Verlust 1 %, Latenz 150 ms, Jitter 30 ms. Begründung: Richten Sie die Schwellenwerte an der realistischen Transportleistung aus, um Pfad-Flapping zu verhindern; strengere Werte für O365 als für Best-Effort.

3. Control-Policy für PCI Hub-and-Spoke implementieren

   • Eingehend zu vSmart: Routen, die von SPOKES im PCI_VPN gelernt werden, mit einem Tag versehen.
   • Ausgehend von vSmart: an SPOKES, HUB-Routen und Standardrouten ankündigen; die Ankündigung von von SPOKE stammenden PCI-Routen an andere SPOKES verweigern; an HUBS, alle ankündigen. Begründung: Die Topologie wird auf der Control-Plane durchgesetzt, wodurch sichergestellt wird, dass Spokes nur über Hubs voneinander lernen und die Segmentierung im PCI-VPN erhalten bleibt.

4. App-Route-Richtlinie für O365 und Best-Effort erstellen

   • Übereinstimmung für O365 im CORP_VPN mit GOLD SLA; bevorzugte Color DIA mit Fallback auf PRIVATE.
   • Übereinstimmung für BEST_EFFORT mit SILVER; bevorzugt PRIVATE mit Fallback auf DIA. Begründung: O365 funktioniert am besten über das direkte Internet, wenn die SLA erfüllt ist; bei Bedarf Fallback auf MPLS. Best-Effort kann MPLS aus Kosten-/Richtliniengründen bevorzugen, während ein DIA-Fallback erlaubt ist.

5. Regionale Firewall für Gast-Traffic einfügen

   • Datenrichtlinie im GUEST_VPN: Service-Einfügung in die regionale Firewall-Service-Kette sowohl in der Hinrichtung (Service-Seite zum WAN) als auch in der Rückrichtung (Tunnel zum Service).
   • Stellen Sie sicher, dass der Zustand des Firewall-Service überwacht wird; definieren Sie für den Gast-Anwendungsfall Fail-Open, um die Verfügbarkeit zu gewährleisten. Begründung: Zustandsbehaftete Inspektion erfordert symmetrisches Traversal; bidirektionale Einfügung vermeidet Sitzungsabbrüche. Die Risikotoleranz für Gäste erlaubt Fail-Open, wenn der Dienst ausfällt.

6. Richtlinien über vSmart mit gestaffeltem Rollout anfügen

   • Fügen Sie die Control-Policy an HUBS und eine Canary-Untergruppe von SPOKES im PCI_VPN an.
   • Fügen Sie App-Route- und Datenrichtlinien zuerst in einer begrenzten Region an. Begründung: Begrenzt den Blast Radius (Schadensradius); validiert das Richtlinienverhalten vor der globalen Ausweitung.

7. Validieren und überwachen

   • Vorschau der kompilierten Richtlinien pro Gerät; Bestätigung der Standardaktionen.
   • Verwenden Sie die Simulation, um beispielhafte Flows zu testen (O365 von einer CORP_VPN-Zweigstelle, Gast-Web-Traffic von GUEST_VPN).
   • Überwachen Sie show omp routes/tlocs (PCI-Erreichbarkeit), show app-route stats (O365-Pfad), show policy service-path (Gast-Firewall-Zähler) und BFD-Sitzungen. Begründung: Bestätigt, dass die Ergebnisse der Control- und Data-Plane dem Design entsprechen und dass die SLA-gesteuerte Weiterleitung wie erwartet funktioniert.

8. Erweitern und härten

   • Fügen Sie schrittweise die verbleibenden SPOKES zur Anfügung der Control-Policy hinzu.
   • Verschärfen Sie die Gast-Richtlinie mit Ratenbegrenzungen; passen Sie die O365-SLA-Schwellenwerte an, wenn Pfadoszillationen auftreten. Begründung: Iteratives Tuning reduziert das Betriebsrisiko und gewährleistet eine stabile Benutzererfahrung.

Diese Abfolge trennt sauber die Topologiesteuerung (OMP) von der Weiterleitung und den Diensten auf der Data-Plane, nutzt Segmentierung zum Schutz von PCI, wendet SLA-basiertes App-Routing für die Leistung an und gewährleistet die Betriebssicherheit durch Vorschau, Simulation und gestaffeltes Anfügen.

← Data-Plane-Tunnel · Alle Domänen · Sicherheit →

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