Cisco 300-415: Cisco SD-WAN Fabric-architectuur en Planes — Studiegids

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

Onderdeel van de Cisco SD-WAN 300-415 ENSDWI — Studiegids. Oefen met geverifieerde antwoorden in het Cisco-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Cisco SD-WAN is een op intent gebaseerd fabric dat is opgebouwd uit afzonderlijke componenten en planes die beheer-, orkestratie-, controle- en datafuncties scheiden. De architectuur schaalt van enkele tot duizenden vestigingen, onafhankelijk van het onderliggende transport, met behoud van deterministische controle en beveiliging. Deze sectie legt de rollen uit van vManage, vSmart, vBond en WAN Edge; de planes en protocollen die hen onderling verbinden; platformkeuzes; adressering en segmentatie; overlay-topologiepatronen; multitenancy- en groeperingsconcepten; en de belangrijkste ontwerpafwegingen en faalmodi waarmee u rekening moet houden.

Fabric-componenten en -planes

• WAN Edge: De data-plane-router aan de rand van de branch, campus, colocatie of cloud. Het vormt veilige datatunnels, voert beleid uit, gebruikt BFD voor pad-liveliness, wisselt OMP-routes uit met controllers en stuurt gebruikersverkeer door.
• vSmart Controller: Het brein van het control plane. Het bouwt en onderhoudt de overlay-topologie, distribueert route- en beleidsinformatie via OMP, en orkestreert WAN Edge-connectiviteit en de distributie van cryptosleutels om veilige IPsec-peering tussen edges mogelijk te maken.
• vBond Orchestrator: Het eerste contactpunt voor nieuwe apparaten. Het authenticeert de identiteit van apparaten, assisteert bij NAT-traversal en coördineert de verbinding van elke WAN Edge met vSmart. Het onderhoudt persistente verbindingen met vSmart-controllers en bevindt zich doorgaans in een bereikbare publieke IP-ruimte voor universele onboarding.
• vManage: Het management- en orkestratieplane (NMS). Het levert intent-input, configuratietemplates, imagebeheer, telemetrie, Cloud OnRamp-automatisering en API’s. vManage neemt niet deel aan het forwarding control plane.

Planes en protocollen:

• Management plane: vManage gebruikt beveiligde kanalen (NETCONF/gRPC over TLS) om apparaten en controllers te monitoren en configureren.
• Orchestration plane: vBond gebruikt DTLS/TLS om apparaten te authenticeren, de bereikbaarheid van controllers te delen en door NAT te ‘punchen’. Met controllercertificaten en zonder geconfigureerde alternatieve poort, luistert vBond op UDP/TCP 12346.
• Control plane: vSmart gebruikt OMP om prefixes, TLOC’s en beleidsregels uit te wisselen met WAN Edge-apparaten. Controleverbindingen gebruiken standaard DTLS; TLS wordt ook ondersteund en is vaak vereist door strikte firewalls of compliancy-regimes.
• Data plane: WAN Edge-apparaten bouwen IPsec- (of GRE waar van toepassing) tunnels tussen TLOC’s voor versleuteld transport, met BFD-probing per tunnel voor sub-seconde faaldetectie en application-aware routing.

Levenscyclus bij aansluiten:

1. WAN Edge neemt contact op met vBond, authenticeert zich en ontvangt controllerlijsten.
2. WAN Edge zet DTLS/TLS-controlesessies op naar vSmart (en naar vManage voor beheer).
3. vSmart distribueert informatie over cryptosleutels; WAN Edge vormt vervolgens IPsec-tunnels met andere WAN Edges zoals vereist door beleid en topologie.

Implicaties voor resiliency:

• Verlies van vManage beïnvloedt alleen configuratie en zichtbaarheid; data forwarding gaat door.
• Verlies van vBond beïnvloedt de onboarding van nieuwe apparaten; bestaande apparaten worden niet beïnvloed.
• Verlies van alle vSmart-controllers isoleert het control plane; datatunnels blijven bestaan, maar route-/beleidswijzigingen stoppen en een verouderde control state kan de operaties na verloop van tijd verslechteren.
• Door BFD gestuurde pad-failover en meerdere TLOC’s zorgen voor data-plane-continuïteit tijdens storingen in de underlay of het transport.

Identiteit, Adressering en Segmentatie

Identiteit en adressering zijn overlay-centrisch:

• Organization name: Een fabric-brede string die op alle apparaten en controllers moet overeenkomen; een mismatch voorkomt control-plane adjacency.
• System IP: Een unieke, loopback-achtige 32-bits identifier per apparaat die wordt gebruikt in TLOC-tuples en control-plane-adressering. Het is niet gekoppeld aan een fysieke interface.
• Site ID: Een numerieke identifier die apparaten op een locatie groepeert. Standaard vormen apparaten die een site-ID delen geen directe datatunnels om hairpins en loops binnen een site te vermijden.
• Certificates: Apparaten en controllers gebruiken een X.509-identiteit. Hardware WAN Edges maken gebruik van Secure Device Identity (SUDI) voor zero-touch provisioning; alle apparaten moeten worden ingeschreven en geautoriseerd in vManage voordat ze zich bij het fabric kunnen aansluiten.

Belangrijke VPN’s:

• VPN 0 (Transport): Draagt underlay-transportconnectiviteit en TLOC-interfaces richting MPLS, DIA, breedband of LTE. NAT, DHCP, PPPoE en statische/default routes eindigen hier. TLOC = {system IP, color, encapsulation} waarbij color het transport kenmerkt (bijvoorbeeld mpls, biz-internet, public-internet) en encapsulation IPsec of GRE is.
• VPN 512 (Management): Out-of-band apparaatbeheer en controller-bereikbaarheid. Op IOS XE SD-WAN wordt dit gemapt naar een management-VRF; op vEdge is het expliciet VPN 512. Controllers en WAN Edges zetten beheersessies op met behulp van TLS-beveiligde protocollen.
• Service VPN’s (1–511 behalve 512): Dragen gebruikersdiensten en kunnen OSPF, EIGRP, BGP, static routing of bridging draaien. Beleidsregels (gecentraliseerd en gelokaliseerd) sturen inter-VPN- en intra-VPN-stromen, QoS en beveiliging.

Nuttige basisconfiguratie-elementen:

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

Faalmodi om op te letten:

• Dubbele system IP’s of site-ID’s creëren controle-anomalieën of ongewenste tunnelonderdrukking.
• Een mismatch in de organization-name voorkomt OMP-adjacencies.
• Vervallen of ingetrokken certificaten verbreken het vertrouwen van de controller of het apparaat.
• Een verkeerd geplaatste management default route in VPN 512 maakt een apparaat onbereikbaar voor controllers; een verkeerd geplaatste transport default in VPN 0 isoleert TLOC’s.

Platformen, implementatiemodellen en controllerontwerp

WAN Edge-platformen:

• Cisco IOS XE SD-WAN: Ondersteund op ISR 4000 Series en ASR 1000 Series platformen (en de Catalyst 8000-familie). Geef de voorkeur aan IOS XE SD-WAN voor feature-ontwikkeling op de lange termijn en uniforme branch-services.
• vEdge: Eerdere op Viptela gebaseerde hardware/virtuele platformen die nog in veel implementaties worden ondersteund; bij de migratieplanning moet rekening worden gehouden met feature-verschillen en levenscyclus-tijdlijnen.
• Virtual WAN Edge: Draait op hypervisors en servers, waaronder Cisco UCS en de Cisco ENCS 5000 Series, en in public clouds (AWS, Azure, GCP). Gebruik Cloud OnRamp om IaaS-implementaties te automatiseren; vereisten zijn onder meer een abonnement op de cloud marketplace image (bijvoorbeeld AWS AMI) en het voorbereiden van een device template in vManage.

Onderlay-onafhankelijkheid en transportdiversiteit:

• Elke TLOC is gekoppeld aan een transport met een bijbehorende ‘color’; beleid kan transporten bevoordelen, verdelen of uitsluiten per applicatie, SLA of siterol.
• IPsec is de standaard over niet-vertrouwde onderlays; GRE kan worden gebruikt over private MPLS waar encryptie niet nodig of beperkt is.
• BFD levert per tunnel ’liveliness’- en SLA-statistieken (verlies, latency, jitter) om application-aware routing aan te sturen.

Controller-clustering, schaalbaarheid, hoge beschikbaarheid en plaatsing:

• vManage: Implementeer als een cluster van drie of meer nodes voor HA en veerkracht; plaats het samen met high-throughput storage voor telemetrie en de image repository. Maak regelmatig back-ups.
• vSmart: Implementeer meerdere controllers verspreid over ‘fault domains’ en geografische locaties; alle WAN Edges bouwen control-sessies op met meer dan één vSmart. vSmart-instances schalen horizontaal; plan N+1-capaciteit om het verlies van een controller op te vangen.
• vBond: Implementeer ten minste twee orchestrators in de publieke adresruimte (of met statische NAT en consistente port mapping). vBond onderhoudt permanente sessies met vSmart en tijdelijke sessies met WAN Edges tijdens het onboarding-proces.
• Plaatsing: Controllers kunnen worden gehost in uw datacenters of in de public cloud. Zorg voor deterministische inkomende bereikbaarheid vanaf het internet voor vBond en voldoende egress voor de WAN Edges. Als middleboxes uitzonderingen voor TLS-inspectie vereisen, geef dan de voorkeur aan TLS control-sessies boven DTLS.

Operationele opmerkingen:

• Het standaard control-plane transport is DTLS; schakel over naar TLS bij het passeren van strikte firewalls of compliance-domeinen die alleen op TCP gebaseerde versleutelde controle toestaan. Zorg ervoor dat de juiste poorten end-to-end zijn toegestaan.
• Wanneer een WAN Edge toetreedt, bouwt het DTLS/TLS op naar vSmart en IPsec-tunnels naar peer edges op basis van OMP-bereikbaarheid en beleid. Zorg voor NAT-keepalives en UDP-pinholes op breedbandcircuits om te voorkomen dat tunnels stilzwijgend wegvallen.

Overlay-topologieën, multitenancy en ontwerpafwegingen

Topologiepatronen worden gerealiseerd via gecentraliseerd controlebeleid (route- en TLOC-advertenties) en gelokaliseerd databeleid:

• Full mesh: Laagste latentie tussen alle sites; uitstekende veerkracht; hoogste belasting op de schaal van het controle- en datavlak door de vele IPsec/BFD-sessies.
• Hub-and-spoke: Eenvoudige schaalbaarheid met minder tunnels; de hub wordt een knelpunt voor bandbreedte en veerkracht zonder een dual-hub-ontwerp; hogere padlatentie voor spoke-naar-spoke-verkeer.
• Regionale hub: Balanceert latentie en schaalbaarheid door full meshes regionaal te beperken en interregionaal verkeer via hubs te backhaulen; vereist zorgvuldig beleid om ’tromboning’ te voorkomen.
• Dual hub (active/active of active/standby): Verbetert de veerkracht en kan de belasting verdelen; verhoogt de complexiteit van de controle (ECMP, tie-breaking, luspreventie) en verbruikt meer hub-resources.

Multitenancy en groepering:

• Echte multitenancy: Serviceproviders kunnen de multi-tenant-modus op controllers inschakelen om meerdere logische organisaties met geïsoleerde controlevlakken, beheerders en beleidsregels op hetzelfde controllercluster te hosten.
• Segmentatie per tenant of businessunit: Gebruik service-VPN’s om verkeersscheiding af te dwingen, route-leaking waar nodig, en per-VPN beleid/QoS.
• Apparaatgroepering: Gebruik vManage-apparaatgroepen, sitelijsten, VPN-lijsten, prefix-/TLOC-lijsten om beleid, upgrades en templates te richten op basis van functie, regio of rol.

Ontwerpafwegingen:

• Latentie versus beleidscontrole: Full mesh minimaliseert de latentie, maar bemoeilijkt de handhaving en observatie van beleid; hub-and-spoke vereenvoudigt de controle, maar voegt latentie toe voor oost-west-stromen.
• Veerkracht versus operationele schaal: Meer TLOC’s, transports en hubs verhogen de beschikbaarheid en padkeuze, maar vermenigvuldigen de IPsec/BFD-sessies en de schaal van de controle. Gebruik regionalisering en samenvatting om de omvang van OMP en FIB beheersbaar te houden.
• Diversiteit van de underlay versus kosten: Het toevoegen van breedband en LTE verbetert de bereikbaarheid en de weerstand tegen ‘brownouts’; kosten, NAT-gedrag en variabele jitter kunnen SLA’s bemoeilijken. Gebruik van BFD afgeleide SLA-klassen en app-aware routing om gevoelig verkeer te beperken.
• Rijkdom van gecentraliseerd beleid versus ondoorzichtigheid bij troubleshooting: Complexe match/action-ketens bieden granulaire controle, maar kunnen de forwarding-logica onduidelijk maken. Houd beleid modulair, geversioneerd en goed gedocumenteerd; test in een staging-fabric.
• Beveiliging versus prestaties: Verplichte IPsec op alle transports versterkt de vertrouwelijkheid, maar introduceert CPU-overhead en overwegingen met betrekking tot MTU/fragmentatie. Geef de voorkeur aan hardwarematige crypto-acceleratie en consistente afstemming van MSS/PMTUD.

Veelvoorkomende faalmodi en mitigaties:

• Asymmetrisch beleid dat tunnelvorming verhindert: Valideer TLOC- en controlebeleid symmetrisch; bevestig OMP TLOC-routes.
• NAT-pinholes die verlopen op UDP: Geef de voorkeur aan TLS-controle of configureer NAT-keepalives; overweeg statische NAT voor controllers.
• Misbruik van site-ID’s waardoor intra-site tunnels instorten: Zorg voor unieke site-ID’s per fysieke locatie; gebruik BFD color-restrict-beleid voor intra-campus-intentie in plaats van site-samenvoegingen af te dwingen.
• Spoke-starved hubs: Monitor de CPU/crypto en het aantal BFD-sessies van de hub; schaal hubs uit of introduceer regionale hubs; gebruik QoS en policers om controleverkeer te beschermen.

Praktisch probleemscenario

Apex Manufacturing breidt uit naar AWS en beheert tegelijkertijd 600 wereldwijde vestigingen via dual transports (MPLS en DIA). Ze moeten SD-WAN uitbreiden naar AWS met minimale latentie naar regionale applicaties, de compliance handhaven door TLS te gebruiken voor controle, en de HA van de controllers garanderen.

1. Plaats twee vBond-orchestrators in de publieke IP-ruimte en drie vSmart-controllers verspreid over twee clouds.

• Rationale: vBond moet publiek bereikbaar zijn om te assisteren bij NAT-traversal; meerdere vSmart-instanties bieden HA voor het controlevlak en geografische nabijheid. vBond onderhoudt permanente sessies met vSmart en tijdelijke sessies met WAN Edges, wat de onboarding en het opnieuw verbinden versnelt.

2. Converteer alle controleverbindingen naar TLS en sta TCP 12346 toe door de bedrijfsfirewalls.

• Rationale: Standaard DTLS kan worden geblokkeerd door strikte middleboxes. TLS garandeert de bereikbaarheid van het controlevlak via TCP-proxy’s en inspectiedomeinen zonder in te boeten aan encryptie of integriteit.

3. Implementeer vManage als een cluster met drie nodes in een centrale cloudregio met dagelijkse back-ups.

• Rationale: Het beheervlak moet beschikbaar blijven voor beleids-, image- en telemetrie-operaties. Clustering behoudt de status en schaalt de API/GUI-toegang; back-ups beschermen tegen verlies van operationele data.

4. Gebruik Cloud OnRamp for IaaS om virtuele WAN Edge-routers in AWS te instantiëren, één per VPC, in subnets die gekoppeld zijn aan een transit gateway.

• Rationale: Cloud OnRamp automatiseert de AMI-subscription, implementatie en certificaatinschrijving. WAN Edge-apparaten beëindigen SD-WAN TLOC’s en adverteren VPC-routes via OMP, waardoor cloud-workloads in de fabric worden geïntegreerd met dezelfde beleidsset.

5. Wijs systeem-IP’s toe uit een gereserveerd overlay-blok en unieke site-ID’s per cloudregio (bijv. 9001–9010), en stel een consistente organisatienaam in voor de hele fabric.

• Rationale: Unieke systeem-IP’s en site-ID’s voorkomen tunnelonderdrukking en ambiguïteit in het controlevlak. Een uniforme organisatienaam is verplicht voor OMP-adjacencies en certificaatvertrouwen.

6. Configureer VPN 0 voor dual transports in AWS edges (public-internet en, indien beschikbaar, Direct Connect via een private color) en schakel BFD in met SLA-klassen voor app-aware routing.

• Rationale: Diversiteit in transport verbetert de bereikbaarheid en weerstand tegen ‘brownouts’. BFD levert statistieken over verlies/latentie/jitter om applicatieverkeer naar de best presterende TLOC te sturen volgens de SLA.

7. Stel VPN 512 alleen bloot aan beheersubnetten en beperk de routering naar controllers via expliciete statische routes en ACL’s.

• Rationale: Minimaliseert het aanvalsoppervlak op het beheervlak en voorkomt route-leaks die apparaten kunnen isoleren of controller-services te veel kunnen blootstellen.

8. Implementeer een regionale hub-topologie waarbij AWS edges als hubs fungeren voor hun respectievelijke regio’s, met dual on-prem hubs per continent voor failover, en schakel directe internetpaden van spoke-naar-spoke in voor latentiegevoelig verkeer.

• Rationale: Regionale hubs lokaliseren stromen om de latentie te verminderen en de schaal van de controle te beperken; dual hubs bieden redundantie. Gecontroleerde directe spoke-naar-spoke-tunnels behouden een lage latentie voor real-time apps zonder de hubs te overbelasten.

9. Pas gecentraliseerd controlebeleid toe om branch-routes samen te vatten bij regionale hubs, TLOC-advertenties te beperken tot de beoogde regio’s, en segmentatie af te dwingen met service-VPN’s voor productie-, OT- en gastverkeer.

• Rationale: Samenvatting vermindert OMP-route-churn en geheugengebruik. Beperkte TLOC-advertenties voorkomen onbedoelde interregionale tunnelvorming. Op VPN gebaseerde segmentatie handhaaft compliance-grenzen met expliciete route-leaking alleen waar nodig.

10. Monitor de gezondheid van BFD en het controlevlak; stel alarmering in voor het verlies van een vSmart of vBond en zorg voor N+1-capaciteit.

• Rationale: Vroege detectie van degradatie van de controle voorkomt wijdverspreide instabiliteit. N+1 zorgt ervoor dat de fabric een controllerstoring kan doorstaan zonder sessie-uitval, wat zowel de convergentie van het controlevlak als de veerkracht van het datavlak beschermt.

Alle domeinen · Controller Onboarding →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →