Cisco 300-415: Cisco SD-WAN Fabric-Architektur und Ebenen — 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 ist ein Intent-basiertes Fabric, das aus separaten Komponenten und Ebenen aufgebaut ist, die Management-, Orchestrierungs-, Kontroll- und Datenfunktionen trennen. Die Architektur skaliert von wenigen Zweigstellen bis zu Tausenden, unabhängig vom Underlay-Transport, während eine deterministische Kontrolle und Sicherheit aufrechterhalten wird. Dieser Abschnitt erläutert die Rollen von vManage, vSmart, vBond und WAN Edge, die Ebenen und Protokolle, die sie miteinander verbinden, Plattformoptionen, Adressierung und Segmentierung, Overlay-Topologiemuster, Mandantenfähigkeits- und Gruppierungskonzepte sowie die wichtigsten Design-Abwägungen und Ausfallszenarien, die Sie berücksichtigen müssen.

Fabric-Komponenten und -Ebenen

• WAN Edge: Der Data-Plane-Router in der Zweigstelle, am Campus, in der Colocation oder am Cloud-Edge. Er bildet sichere Datentunnel, führt Richtlinien aus, nutzt BFD zur Überprüfung der Pfadverfügbarkeit, tauscht OMP-Routen mit Controllern aus und leitet Benutzerverkehr weiter.
• vSmart Controller: Das Gehirn der Control-Plane. Er baut die Overlay-Topologie auf und pflegt sie, verteilt Routen- und Richtlinieninformationen über OMP und orchestriert die Konnektivität der WAN Edges sowie die Verteilung von Kryptoschlüsseln, um sicheres IPsec-Peering zwischen den Edges zu ermöglichen.
• vBond Orchestrator: Die erste Anlaufstelle für neue Geräte. Er authentifiziert die Geräteidentität, unterstützt die NAT-Durchquerung und koordiniert die Verbindung jedes WAN Edge zu vSmart. Er unterhält persistente Verbindungen zu vSmart-Controllern und befindet sich typischerweise in einem erreichbaren öffentlichen IP-Adressraum für ein universelles Onboarding.
• vManage: Die Management- und Orchestrierungsebene (NMS). Es stellt Intent-Eingaben, Konfigurationsvorlagen, Image-Management, Telemetrie, Cloud OnRamp-Automatisierung und APIs bereit. vManage ist nicht an der Forwarding Control Plane beteiligt.

Ebenen und Protokolle:

• Management-Ebene: vManage nutzt sichere Kanäle (NETCONF/gRPC über TLS) zur Überwachung und Konfiguration von Geräten und Controllern.
• Orchestrierungsebene: vBond nutzt DTLS/TLS zur Authentifizierung von Geräten, zum Teilen der Erreichbarkeit von Controllern und zur NAT-Durchquerung. Mit Controller-Zertifikaten und ohne konfigurierten alternativen Port lauscht vBond auf UDP/TCP 12346.
• Control-Ebene: vSmart nutzt OMP zum Austausch von Präfixen, TLOCs und Richtlinien mit WAN Edge-Geräten. Kontrollverbindungen verwenden standardmäßig DTLS; TLS wird ebenfalls unterstützt und ist häufig bei strengen Firewalls oder Compliance-Vorgaben erforderlich.
• Data-Ebene: WAN Edge-Geräte bauen IPsec- (oder gegebenenfalls GRE-) Tunnel zwischen TLOCs für den verschlüsselten Transport auf, mit BFD-Probing pro Tunnel für eine Fehlererkennung im Sub-Sekunden-Bereich und anwendungsorientiertes Routing.

Lebenszyklus beim Beitritt:

1. WAN Edge kontaktiert vBond, authentifiziert sich und empfängt Controller-Listen.
2. WAN Edge baut DTLS/TLS-Kontrollsitzungen zu vSmart (und zu vManage für das Management) auf.
3. vSmart verteilt Informationen zu Kryptoschlüsseln; WAN Edge bildet dann IPsec-Tunnel mit anderen WAN Edges, wie es von Richtlinien und Topologie gefordert wird.

Auswirkungen auf die Resilienz:

• Ein Ausfall von vManage beeinträchtigt nur die Konfiguration und die Sichtbarkeit; die Datenweiterleitung wird fortgesetzt.
• Ein Ausfall von vBond beeinträchtigt das Onboarding neuer Geräte; bestehende Geräte sind nicht betroffen.
• Ein Ausfall aller vSmart-Controller isoliert die Control-Plane; Datentunnel bleiben bestehen, aber Routen-/Richtlinienänderungen werden gestoppt, und ein veralteter Kontrollzustand kann den Betrieb im Laufe der Zeit beeinträchtigen.
• BFD-gesteuertes Pfad-Failover und mehrere TLOCs gewährleisten die Kontinuität der Data-Plane bei Ausfällen des Underlays oder des Transports.

Identität, Adressierung und Segmentierung

Identität und Adressierung sind Overlay-zentriert:

• Organization name: Eine Fabric-weite Zeichenfolge, die auf allen Geräten und Controllern übereinstimmen muss; eine Nichtübereinstimmung verhindert die Bildung einer Control-Plane-Adjacency.
• System IP: Ein eindeutiger, Loopback-ähnlicher 32-Bit-Identifikator pro Gerät, der in TLOC-Tupeln und für die Adressierung der Control-Plane verwendet wird. Er ist an keine physische Schnittstelle gebunden.
• Site ID: Ein numerischer Identifikator, der Geräte an einem Standort gruppiert. Standardmäßig bilden Geräte, die dieselbe Site ID teilen, keine direkten Datentunnel, um Hairpins und Schleifen innerhalb eines Standorts zu vermeiden.
• Zertifikate: Geräte und Controller verwenden eine X.509-Identität. Hardware WAN Edges nutzen Secure Device Identity (SUDI) für Zero-Touch-Provisioning; alle Geräte müssen registriert und in vManage autorisiert werden, bevor sie dem Fabric beitreten können.

Wichtige VPNs:

• VPN 0 (Transport): Überträgt die Underlay-Transportkonnektivität und TLOC-Schnittstellen in Richtung MPLS, DIA, Breitband oder LTE. NAT, DHCP, PPPoE und statische/Standardrouten enden hier. TLOC = {System-IP, Color, Encapsulation}, wobei Color den Transport charakterisiert (z. B. mpls, biz-internet, public-internet) und Encapsulation IPsec oder GRE ist.
• VPN 512 (Management): Out-of-Band-Gerätemanagement und Erreichbarkeit der Controller. Bei IOS XE SD-WAN wird dies auf eine Management-VRF abgebildet; bei vEdge ist es explizit VPN 512. Controller und WAN Edges bauen Managementsitzungen über TLS-gesicherte Protokolle auf.
• Service VPNs (1–511 außer 512): Übertragen Benutzerdienste und können OSPF, EIGRP, BGP, statisches Routing oder Bridging ausführen. Richtlinien (zentralisiert und lokalisiert) steuern den Datenverkehr zwischen VPNs und innerhalb eines VPNs (Inter-VPN und Intra-VPN), QoS und die Sicherheit.

Nützliche Basiskonfigurationselemente:

sdwan
 system-ip 10.255.0.11
 site-id 101
 organization-name ACME-Global

Ausfallszenarien, auf die zu achten ist:

• Doppelte System-IPs oder Site IDs erzeugen Kontrollanomalien oder eine unerwünschte Unterdrückung von Tunneln.
• Eine Nichtübereinstimmung des Organization-Name verhindert OMP-Adjacencies.
• Der Ablauf oder Widerruf von Zertifikaten unterbricht das Vertrauen des Controllers oder Geräts.
• Eine falsch platzierte Management-Standardroute in VPN 512 trennt ein Gerät von den Controllern; eine falsch platzierte Transport-Standardroute in VPN 0 isoliert TLOCs.

Plattformen, Bereitstellungsmodelle und Controller-Design

WAN-Edge-Plattformen:

• Cisco IOS XE SD-WAN: Wird auf Plattformen der ISR 4000-Serie und ASR 1000-Serie (sowie der Catalyst 8000-Familie) unterstützt. Bevorzugen Sie IOS XE SD-WAN für eine langfristige Geschwindigkeit bei der Feature-Bereitstellung und für vereinheitlichte Zweigstellendienste.
• vEdge: Frühere Viptela-basierte Hardware-/virtuelle Plattformen, die in vielen Bereitstellungen noch unterstützt werden; die Migrationsplanung sollte Feature-Lücken und Lebenszyklus-Zeitpläne berücksichtigen.
• Virtuelle WAN Edge: Läuft auf Hypervisoren und Servern, einschließlich Cisco UCS und Cisco ENCS 5000-Serie, sowie in Public Clouds (AWS, Azure, GCP). Verwenden Sie Cloud OnRamp, um IaaS-Bereitstellungen zu automatisieren; Voraussetzungen sind das Abonnieren des Cloud-Marketplace-Images (z. B. AWS AMI) und die Vorbereitung einer Gerätevorlage in vManage.

Underlay-Unabhängigkeit und Transportvielfalt:

• Jeder TLOC ist an einen Transport mit einer zugehörigen Farbe (Color) gebunden; Richtlinien können Transporte pro Anwendung, SLA oder Standortrolle bevorzugen, ausgleichen oder ausschließen.
• IPsec ist der Standard über nicht vertrauenswürdige Underlays; GRE kann über privates MPLS verwendet werden, wo Verschlüsselung unnötig oder eingeschränkt ist.
• BFD liefert Liveliness- und SLA-Metriken pro Tunnel (Verlust, Latenz, Jitter), um anwendungsbezogenes Routing (Application-Aware Routing) zu steuern.

Controller-Clustering, Skalierung, Hochverfügbarkeit und Platzierung:

• vManage: Als Cluster mit drei oder mehr Knoten für HA und Ausfallsicherheit bereitstellen; zusammen mit Speicher mit hohem Durchsatz für Telemetrie und Image-Repository platzieren. Häufig sichern.
• vSmart: Mehrere Controller über Fehlerdomänen und geografische Regionen hinweg bereitstellen; alle WAN Edges bauen Kontrollsitzungen zu mehr als einem vSmart auf. vSmart-Instanzen skalieren horizontal; planen Sie N+1-Kapazität, um den Ausfall eines Controllers zu verkraften.
• vBond: Mindestens zwei Orchestratoren im öffentlichen Adressraum (oder mit statischem NAT und konsistentem Port-Mapping) bereitstellen. vBond unterhält permanente Sitzungen zu vSmart und transiente Sitzungen zu WAN Edges während des Onboardings.
• Platzierung: Controller können in Ihren Rechenzentren oder in der Public Cloud gehostet werden. Stellen Sie eine deterministische eingehende Erreichbarkeit aus dem Internet für vBond und ausreichenden Egress für WAN Edges sicher. Wenn Middleboxes Ausnahmen für die TLS-Inspektion erfordern, bevorzugen Sie TLS-Kontrollsitzungen gegenüber DTLS.

Betriebliche Hinweise:

• Der Standardtransport für die Control-Plane ist DTLS; wechseln Sie zu TLS, wenn strenge Firewalls oder Compliance-Domänen durchquert werden, die nur TCP-basierte verschlüsselte Steuerung zulassen. Stellen Sie sicher, dass die entsprechenden Ports durchgängig (End-to-End) erlaubt sind.
• Wenn eine WAN Edge beitritt, baut sie DTLS/TLS zu vSmart und IPsec-Tunnel zu Peer-Edges auf, basierend auf OMP-Erreichbarkeit und Richtlinien. Stellen Sie NAT-Keepalives und UDP-Pinholes auf Breitbandverbindungen sicher, um unbemerkte Tunnelabbrüche zu vermeiden.

Overlay-Topologien, Mandantenfähigkeit und Design-Abwägungen

Topologie-Muster werden durch zentralisierte Control-Policies (Routen- und TLOC-Advertisements) und lokalisierte Data-Policies realisiert:

• Full-Mesh: Geringste Latenz zwischen allen Standorten; exzellente Ausfallsicherheit; höchste Last auf der Control- und Data-Plane-Skala aufgrund vieler IPsec/BFD-Sitzungen.
• Hub-and-Spoke: Einfache Skalierung mit weniger Tunneln; der Hub wird ohne Dual-Hub-Design zu einem Engpass für Bandbreite und Ausfallsicherheit; höhere Pfadlatenz für Spoke-to-Spoke-Verbindungen.
• Regionaler Hub: Gleicht Latenz und Skalierung aus, indem Full-Meshes regional begrenzt und der überregionale Verkehr über Hubs geleitet wird (Backhauling); erfordert eine sorgfältige Policy, um Tromboning zu verhindern.
• Dual-Hub (Aktiv/Aktiv oder Aktiv/Standby): Verbessert die Ausfallsicherheit und kann die Last verteilen; erhöht die Komplexität der Steuerung (ECMP, Tie-Breaking, Schleifenverhinderung) und verbraucht mehr Hub-Ressourcen.

Mandantenfähigkeit und Gruppierung:

• Echte Mandantenfähigkeit: Service-Provider können den Multi-Tenant-Modus auf Controllern aktivieren, um mehrere logische Organisationen mit isolierten Control-Planes, Administratoren und Policies auf demselben Controller-Cluster zu hosten.
• Segmentierung pro Mandant oder Geschäftsbereich: Verwenden Sie Service-VPNs, um die Verkehrstrennung durchzusetzen, bei Bedarf Route-Leaking zu ermöglichen und pro-VPN-Policy/QoS anzuwenden.
• Gerätegruppierung: Verwenden Sie vManage-Gerätegruppen, Standortlisten, VPN-Listen und Präfix-/TLOC-Listen, um Policies, Upgrades und Templates gezielt nach Funktion, Region oder Rolle anzuwenden.

Design-Abwägungen:

• Latenz vs. Policy-Kontrolle: Full-Mesh minimiert die Latenz, erschwert aber die Durchsetzung und Überwachung von Policies; Hub-and-Spoke vereinfacht die Steuerung, erhöht aber die Latenz für Ost-West-Datenflüsse.
• Ausfallsicherheit vs. Betriebsskala: Mehr TLOCs, Transports und Hubs erhöhen die Verfügbarkeit und Pfadauswahl, vervielfachen aber die Anzahl der IPsec/BFD-Sitzungen und die Skalierung der Control-Plane. Nutzen Sie Regionalisierung und Routen-Zusammenfassung (Summarization), um die Größe von OMP und FIB zu begrenzen.
• Underlay-Diversität vs. Kosten: Das Hinzufügen von Breitband und LTE verbessert die Erreichbarkeit und Brownout-Resistenz; Kosten, NAT-Verhalten und variabler Jitter können SLAs erschweren. Verwenden Sie von BFD abgeleitete SLA-Klassen und App-Aware Routing, um sensiblen Datenverkehr zu steuern.
• Reichhaltigkeit zentralisierter Policies vs. Intransparenz bei der Fehlerbehebung: Komplexe Match/Action-Ketten ermöglichen eine granulare Steuerung, können aber die Forwarding-Logik verschleiern. Halten Sie Policies modular, versioniert und gut dokumentiert; testen Sie in einer Staging-Fabric.
• Sicherheit vs. Performance: Obligatorisches IPsec auf allen Transports stärkt die Vertraulichkeit, führt aber zu CPU-Overhead und Überlegungen bezüglich MTU/Fragmentierung. Bevorzugen Sie Hardware-Krypto-Beschleunigung und ein konsistentes MSS/PMTUD-Tuning.

Häufige Fehlermodi und Gegenmaßnahmen:

• Asymmetrische Policy, die den Tunnelaufbau verhindert: Validieren Sie TLOC- und Control-Policies symmetrisch; bestätigen Sie die OMP-TLOC-Routen.
• Ablaufende NAT-Pinholes bei UDP: Bevorzugen Sie die Steuerung über TLS oder konfigurieren Sie NAT-Keepalives; ziehen Sie statisches NAT für Controller in Betracht.
• Fehlverwendung der Site-ID, die zum Kollaps standortinterner Tunnel führt: Stellen Sie eindeutige Site-IDs pro physischem Standort sicher; verwenden Sie BFD-Color-Restrict-Policies für die campusinterne Steuerung, anstatt eine Zusammenlegung von Standorten zu erzwingen.
• Überlastete Hubs (Spoke-Starvation): Überwachen Sie die CPU-/Krypto-Auslastung der Hubs und die Anzahl der BFD-Sitzungen; skalieren Sie Hubs horizontal (Scale-Out) oder führen Sie regionale Hubs ein; verwenden Sie QoS und Policer, um den Control-Traffic zu schützen.

Praktisches Problemszenario

Apex Manufacturing expandiert in AWS und betreibt gleichzeitig 600 globale Niederlassungen über duale Transports (MPLS und DIA). Das Unternehmen muss SD-WAN mit minimaler Latenz zu regionalen Anwendungen in AWS erweitern, die Compliance durch die Verwendung von TLS für die Steuerung aufrechterhalten und die Controller-HA sicherstellen.

1. Platzieren Sie zwei vBond-Orchestratoren im öffentlichen IP-Adressraum und drei vSmart-Controller verteilt auf zwei Clouds.

• Begründung: vBond muss öffentlich erreichbar sein, um das NAT-Traversal zu unterstützen; mehrere vSmart-Instanzen bieten Control-Plane-HA und geografische Nähe. vBond unterhält permanente Sitzungen zu vSmart und transiente Sitzungen zu den WAN Edges, was das Onboarding und die Wiederanbindung beschleunigt.

2. Stellen Sie alle Control-Verbindungen auf TLS um und erlauben Sie TCP 12346 durch die Unternehmens-Firewalls.

• Begründung: Standardmäßiges DTLS kann von strikten Middleboxes blockiert werden. TLS stellt die Erreichbarkeit der Control-Plane durch TCP-Proxys und Inspektionsdomänen sicher, ohne die Verschlüsselung oder Integrität zu beeinträchtigen.

3. Stellen Sie vManage als Drei-Knoten-Cluster in einer zentralen Cloud-Region mit täglichen Backups bereit.

• Begründung: Die Management-Plane muss für Policy-, Image- und Telemetrie-Operationen verfügbar bleiben. Clustering erhält den Zustand und skaliert den API/GUI-Zugriff; Backups schützen vor dem Verlust von Betriebsdaten.

4. Verwenden Sie Cloud OnRamp for IaaS, um virtuelle WAN-Edge-Router in AWS zu instanziieren, einen pro VPC, in an Transit-Gateways angebundenen Subnetzen.

• Begründung: Cloud OnRamp automatisiert das AMI-Abonnement, die Bereitstellung und die Zertifikatsregistrierung. WAN-Edge-Geräte terminieren SD-WAN-TLOCs und kündigen VPC-Routen über OMP an, wodurch Cloud-Workloads mit demselben Policy-Set in die Fabric integriert werden.

5. Weisen Sie System-IPs aus einem reservierten Overlay-Block und eindeutige Site-IDs pro Cloud-Region zu (z. B. 9001–9010) und legen Sie einen konsistenten Organisationsnamen für die gesamte Fabric fest.

• Begründung: Eindeutige System-IPs und Site-IDs verhindern Tunnel-Unterdrückung und Mehrdeutigkeit in der

Alle Domänen · Controller-Onboarding →

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