Cisco 300-415: Gecentraliseerd Beleid en Traffic Engineering — Studiegids
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
Gecentraliseerd beleid in Cisco SD-WAN is het raamwerk waarmee u verkeersgedrag en routeringsintenties kunt programmeren vanaf vSmart-controllers over de gehele fabric. vSmart, dat het overlay-control-plane beheert via OMP, distribueert gecentraliseerd control-beleid (voor OMP-routes en TLOC’s) en data-plane-beleid zoals data, application-aware routing (app-route) en cflowd. Dit beleid vormt de topologie (hub-and-spoke, mesh-restrictie), selecteert paden op basis van applicatieprestaties, stuurt datastromen naar services en segmenteert verkeer per VPN. Omdat beleid zowel de bereikbaarheid van het control-plane als de forwarding van het data-plane kan beïnvloeden, zijn een zorgvuldig ontwerp, preview en gefaseerde implementatie essentieel om storingen te voorkomen.
Typen Gecentraliseerd Beleid en Bouwstenen
Gecentraliseerd control-beleid
- Scope: Control-plane (OMP) tussen WAN Edge-apparaten en vSmart.
- Doel: OMP-routes en TLOC-advertenties filteren/wijzigen, attributen instellen (preference, tag, origin, TLOC) en topologieën bouwen (hub-and-spoke, partial mesh).
- Richting: Inkomend (naar vSmart vanaf WAN Edge) en uitgaand (van vSmart naar WAN Edge).
Gecentraliseerd data-beleid
- Scope: Data-plane-classificatie (L3/L4, velden, app-ID) op de WAN Edge, geïnstalleerd door vSmart.
- Doel: Datastromen toestaan/weigeren, VPN instellen, TLOC instellen, DSCP/markering instellen, policen, mirroren en service-insertion/chaining.
- Richting: Geëvalueerd op de WAN Edge ten opzichte van de service-zijde (LAN) of de tunnel-zijde (WAN), afhankelijk van waar het is geprogrammeerd; ontwerpen richten zich doorgaans op de service-side ingress voor gebruiker-naar-WAN-stromen en de tunnel-side voor retourverkeer als symmetrisch gedrag vereist is.
Application-aware routing (app-route) beleid
- Scope: Data-plane-padselectie op basis van applicatie en SLA (loss, latency, jitter) gemeten door BFD.
- Doel: Verkeer sturen naar voorkeurs-TLOC’s/colors, op probes gebaseerde SLA-klassen definiëren, fallbacks instellen en dynamische traffic engineering uitvoeren per applicatie/familie.
- Belangrijkste gedrag: Evalueert continu de prestaties van het pad; kan van pad wisselen wanneer de SLA verslechtert.
cflowd-beleid
- Scope: Flow-telemetrie (IPFIX/NetFlow-achtig) gegenereerd door WAN Edges.
- Doel: Exporters per VPN in-/uitschakelen, sampling rates, templates en collectors (vManage of extern) definiëren.
- Ontwerp-opmerking: Sampling moet een balans vinden tussen zichtbaarheid en CPU/bandbreedte-overhead; het inschakelen per VPN ondersteunt gesegmenteerde rapportage.
Beleidslijsten zijn herbruikbare match-objecten:
- Site list: Site-ID’s die worden gebruikt om te selecteren waar beleid wordt toegepast en om de herkomst/bestemming van routes te matchen.
- VPN list: VRF’s (VPN’s) die worden gebruikt om de scope van het beleid te segmenteren en regels per segment op te bouwen.
- Prefix list: IP-prefixen om OMP-routes of dataverkeer te matchen.
- Data prefix list: Gespecialiseerd prefix-object voor classificatie van data-beleid.
- TLOC list: Tupels van system-IP, color en encapsulation die worden gebruikt om TLOC-attributen te matchen of in te stellen.
- Color list: Eén of meer transport-colors (bijv. biz-internet, mpls, public-internet) voor targeting/linkaffiniteit.
- Application list: NBAR2-applicaties/groepen om verkeer te classificeren voor app-route- of data-beleid.
- SLA class: Latency-, loss- en jitter-drempelwaarden gekoppeld aan app-route voor prestatiegebaseerde sturing.
Structuur en evaluatie van beleidssequenties:
- Sequenties zijn geordend, de eerste match wint. Elke sequentie heeft:
- Match-condities: Lijsten/velden (site/VPN/prefix/TLOC/color/app, L4-poorten, DSCP, protocol).
- Acties: Accept/deny, attributen instellen (TLOC, VPN, DSCP, preference, tag), service insertion, policen, mirroren.
- Standaardactie: Toegepast als geen enkele sequentie matcht. Gebruikelijke standaardacties zijn ‘accept’ (control/data) om onbedoelde drops te voorkomen; expliciete ‘deny’-standaardacties worden bewust gebruikt en vereisen zorgvuldige validatie.
- Richting:
- De richting van control-beleid is op vSmart (inkomend/uitgaand OMP).
- Data- en app-route-beleid werken op verkeer op de WAN Edge; kies service-side of tunnel-side gedrag dat past bij de datastroom die u wilt beïnvloeden, en zorg voor symmetrie in het retourverkeer wanneer stateful services in het pad aanwezig zijn.
Ontwerp van besturingsvlakbeleid en route-/TLOC-manipulatie
Besturingsbeleid is het gezaghebbende instrument voor het vormgeven van de overlay-topologie, omdat het bepaalt welke OMP-routes en TLOC’s een site kan verzenden of ontvangen:
OMP-route-manipulatie
- Gebruik inkomend besturingsvlakbeleid om routes die van een site zijn geleerd te filteren, te taggen of attributen in te stellen voordat ze de overlay-RIB op vSmart binnenkomen.
- Gebruik uitgaand besturingsvlakbeleid om te beperken welke routes naar specifieke sites worden geadverteerd (bijv. adverteer geen door spokes geleerde prefixes naar andere spokes).
- Veelvoorkomende acties: voorkeur instellen (beïnvloedt het beste OMP-pad), tag instellen (voor latere matching), oorsprong instellen, site-van-oorsprong-beperkingen instellen.
TLOC-manipulatie
- Match op TLOC-attributen (systeem-IP, kleur, encap) om specifieke transporten te filteren of te bevoordelen.
- Acties omvatten het wijzigen van TLOC-voorkeursattributen of -voorkeuren, zodat route-advertenties een voorkeur geven aan een bepaalde kleur (bijv. geef MPLS de voorkeur voor kritieke subnetten).
- Afweging: Te agressieve TLOC-filtering kan sites isoleren als het resterende transport uitvalt. Geef de voorkeur aan het afstemmen van attributen boven een algemene ‘deny’, tenzij u redundante paden hebt.
Topologiepatronen
- Hub-and-spoke: Uitgaand besturingsvlakbeleid van vSmart naar spokes weigert de advertentie van van spokes afkomstige routes naar andere spokes; hubs ontvangen en adverteren alles.
- Mesh-beperking: Vergelijkbaar met hub-and-spoke, maar staat specifieke spoke-naar-spoke-paren toe (bijv. regionale meshes) via uitzonderingen in beleidssequenties.
- Segmentatie: Combineer VPN-lijsten met routefiltering om per-VPN overlays geïsoleerd te houden; adverteer alleen default- of geselecteerde prefixes naar beperkte sites.
Faalmodi en afwegingen:
- Een verkeerd toegepast uitgaand besturingsvlakbeleid met een ‘deny default’ kan kritieke routes intrekken, waardoor sites geïsoleerd raken. Gebruik altijd ‘default accept’ en voeg gerichte ‘denies’ toe, tenzij uw preview de dekking expliciet bevestigt.
- Het op grote schaal wijzigen van OMP-attributen kan route-churn veroorzaken; spreid de implementatie via sitelijsten om een control-plane-schok te verminderen.
- Herschrijvingen van TLOC-attributen kunnen leiden tot asymmetrische forwarding als het terugkerende pad niet op een gelijkwaardige manier wordt beïnvloed; valideer beide richtingen.
Applicatiebewuste routering, service-insertie en segmentatie
Applicatiebewuste routering (AAR) en databeleid leveren samen fijmazige traffic engineering:
AAR en verkeerssturing
- SLA-klassen definiëren acceptabel verlies/latentie/jitter; BFD-probes per TLOC-paar leveren realtime metingen.
- App-route-beleid matcht op applicaties of L3/L4-velden en selecteert voorkeurslijsten voor kleur/TLOC; als de SLA wordt geschonden, wordt een failover uitgevoerd volgens het beleid.
- Ontwerptips:
- Vermijd te strakke SLA-drempels die ‘flapping’ veroorzaken; voeg hysterese toe met behulp van probe-multipliers en redelijke drempels.
- Voor apps die gevoelig zijn voor pakketherschikking, geef de voorkeur aan “verplaatsen bij de volgende nieuwe flow” in plaats van wisselingen midden in een flow, of pin flows vast met ‘consistent hashing’ waar dit wordt ondersteund.
- Wanneer zowel AAR als databeleid TLOC instellen, geef AAR dan voorrang voor padselectie en gebruik databeleid voor service-insertie/markering; vermijd overlappende acties in dezelfde verkeersklasse.
Service-chaining en service-insertie
- De databeleid-actie “service” leidt verkeer door on-premise of colocatie-services (firewall, IDS/IPS, SD-WAN-servicenodes).
- Keten meerdere services in de vereiste volgorde; zorg voor symmetrische insertie voor stateful services op zowel het heen- als het teruggaande pad.
- Afwegingen: Elke service-hop voegt latentie en potentiële faaldomeinen toe. Implementeer health checks en fail-open/closed-gedrag dat consistent is met de beveiligingshouding.
Verkeerssegmentatie
- VPN’s bieden harde segmentatie; gecentraliseerd beleid wordt per-VPN toegepast met behulp van VPN-lijsten.
- Inter-VPN-routering (‘route leaking’) kan worden bereikt met databeleid door “set VPN” te gebruiken voor specifieke flows; beperk dit strikt met prefix/applicatie-matches en audit frequent.
- Voor gedeelde services (bijv. DNS, identiteit), adverteer serviceprefixes vanuit een services-VPN naar consumer-VPN’s met besturingsbeleid in plaats van met brede data-plane-leaks.
Voorbeeld van een app-route-fragment dat SLA-gebaseerde sturing illustreert:
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
!
Operaties: Koppeling, Validatie en Probleemoplossing
Policy-koppeling via vSmart:
- Definieer gecentraliseerde policies in vManage en koppel ze aan site-lijsten en VPN-lijsten. vSmart compileert de policy en distribueert deze naar WAN Edges via beveiligde DTLS/TLS OMP-sessies in VPN 0.
- Wees voorzichtig met het bereik van wijzigingen; één enkele policy-instantie kan honderden sites beïnvloeden. Gebruik site-lijsten om implementaties gefaseerd uit te rollen per regio of functie.
Policy-simulatie, preview en gefaseerde implementatie:
- Preview: Gebruik vóór activering de vManage-preview om de apparaatspecifieke gecompileerde policy te inspecteren (wat elke WAN Edge zal ontvangen). Bevestig de match/action-logica, standaardacties en richtingen.
- Simulatie: Gebruik policy-simulatie om flow-matches en verwachte acties te testen (bijv. welke TLOC een bepaalde app/5-tuple zal gebruiken). Valideer SLA-klasse-toewijzingen en applicatieclassificatie.
- Gefaseerde implementatie:
- Koppel aan een canary-sitelijst (enkele sites).
- Monitor de KPI’s van het control-plane en data-plane (OMP route-aantallen, BFD, app-route hits).
- Breid de site-lijst stapsgewijs uit.
- Versiebeheer en rollback: Bewaar eerdere policy-versies; als onverwacht gedrag wordt gedetecteerd, deactiveer dan de nieuwe policy of rol snel terug naar de vorige versie.
Debuggen van onbedoelde resultaten en prioriteit:
Verificatie van het control-plane
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
!
,
- undefined
Bevestig de aan- of afwezigheid van routes en TLOC’s volgens de policy-intentie.
- undefined
Verifieer de tellers van de control policy en welke sequenties een match hadden.
- Symptoom: Spokes kunnen elkaar niet bereiken na de implementatie → controleer de ‘deny’-regels van de uitgaande control policy naar spokes en de standaardacties.
Verificatie van het data-plane en AAR
undefined
en
- undefined
Valideer de SLA-status en padbeslissingen.
undefined
of equivalent: Bevestig de tellers voor service-insertion en de volgorde van de chain.
undefined
en
- undefined
Verifieer het daadwerkelijke forwarding-pad.
- Symptoom: Onverwachte padwijzigingen/flapping → versoepel de SLA of pas de probe-multipliers aan; zorg ervoor dat een overlappende data policy niet ook een TLOC instelt.
Policy-prioriteit en conflicten
- AAR-beslissingen hebben doorgaans voorrang bij de padselectie; gebruik data policy voornamelijk voor service-insertion, marking en toegangscontrole.
- Overlappende match-criteria tussen policies kunnen ambiguïteit veroorzaken. Houd match-domeinen wederzijds exclusief of introduceer een volgorde en tags om ambiguïteit te voorkomen.
- Een standaard ‘accept’ kan ontbrekende sequenties maskeren; voeg expliciete “observe-only”-tellers (bijv. mirror/police low) of tijdelijke logging toe om matches te valideren voordat ‘denies’ worden afgedwongen.
cflowd-validatie
- undefined
Zorg ervoor dat de exporters per VPN actief zijn en de sampling uitvoeren zoals bedoeld.
- Hoge CPU-belasting na het inschakelen van cflowd → verhoog het sampling-interval of beperk het tot essentiële VPN’s/apps.
Praktisch Probleemscenario
Northwind Traders migreert naar Cisco SD-WAN en moet een hub-and-spoke-topologie afdwingen voor PCI VPN’s, Office 365 naar het beste internetpad sturen en een regionale firewall-service invoegen voor gastverkeer zonder kritieke applicaties te beïnvloeden.
Aanpak:
Bouw policy-lijsten
- Maak site-lijsten: HUBS (datacenters), SPOKES (filialen).
- Maak VPN-lijsten: PCI_VPN, GUEST_VPN, CORP_VPN.
- Maak applicatielijsten: O365, BEST_EFFORT.
- Maak color-lijsten: PRIVATE (mpls), DIA (biz-internet, public-internet). Rationale: Herbruikbare lijsten maken een nauwkeurig bereik en een veilige, gefaseerde uitrol mogelijk; het scheiden van VPN’s ondersteunt segmentatie.
Definieer SLA-klassen
- GOLD: loss 0.5%, latency 100 ms, jitter 20 ms.
- SILVER: loss 1%, latency 150 ms, jitter 30 ms. Rationale: Stem drempelwaarden af op realistische transportprestaties om ‘path flapping’ te voorkomen; strenger voor O365 dan voor best-effort.
Implementeer control policy voor PCI hub-and-spoke
- Inkomend naar vSmart: tag routes die geleerd zijn van SPOKES in de PCI_VPN.
- Uitgaand van vSmart: adverteer naar SPOKES de HUB-routes en defaults; weiger de advertentie van door SPOKE-geïnitieerde PCI-routes naar andere SPOKES; adverteer alles naar HUBS. Rationale: De topologie wordt afgedwongen op het control-plane, wat ervoor zorgt dat spokes elkaar alleen via de hubs leren kennen en de segmentatie in de PCI VPN behouden blijft.
Maak een app-route policy voor O365 en best-effort
- Match O365 in CORP_VPN met GOLD SLA; voorkeurskleur DIA met fallback naar PRIVATE.
- Match BEST_EFFORT met SILVER; voorkeur voor PRIVATE met fallback naar DIA. Rationale: O365 presteert het best via direct internet wanneer aan de SLA wordt voldaan; val indien nodig terug op MPLS. Best-effort kan de voorkeur geven aan MPLS vanwege kosten/policy, terwijl een fallback naar DIA mogelijk blijft.
Voeg een regionale firewall in voor gastverkeer
- Data policy in GUEST_VPN: service-insertion naar de regionale firewall service-chain in zowel de voorwaartse (service-kant naar WAN) als de terugkerende (tunnel naar service) richting.
- Zorg ervoor dat de status van de firewall-service wordt gemonitord; definieer ‘fail-open’ voor de gast-use-case om de beschikbaarheid te behouden. Rationale: Stateful inspectie vereist symmetrische traversal; bidirectionele insertie voorkomt dat sessies wegvallen. De risicotolerantie voor gasten staat ‘fail-open’ toe als de service uitvalt.
Koppel policies via vSmart met een gefaseerde uitrol
- Koppel de control policy aan HUBS en een canary-subset van SPOKES in de PCI_VPN.
- Koppel de app-route en data policies eerst aan een beperkte regio. Rationale: Beperkt de impactradius (‘blast radius’); valideert het policy-gedrag vóór een wereldwijde uitbreiding.
Valideer en monitor
- Bekijk de gecompileerde policies per apparaat in een preview; bevestig de standaardacties.
- Gebruik simulatie om voorbeeld-flows te testen (O365 vanuit een CORP_VPN-filiaal, gast-webverkeer vanuit GUEST_VPN).
- Monitor
undefined
(PCI-bereikbaarheid),
undefined
(O365-pad),
undefined
(tellers van de gast-firewall) en BFD-sessies. Rationale: Bevestigt dat de resultaten van zowel het control- als het data-plane overeenkomen met het ontwerp, en dat de SLA-gestuurde sturing werkt zoals verwacht.
- Uitbreiden en versterken
- Voeg geleidelijk de resterende SPOKES toe aan de koppeling van de control policy.
- Verscherp de gast-policy met rate limits; pas de O365 SLA-drempels aan als pad-oscillaties optreden. Rationale: Iteratief afstemmen vermindert het operationele risico en zorgt voor een stabiele gebruikerservaring.
Deze volgorde scheidt de topologiecontrole (OMP) duidelijk van de sturing en services op het data-plane, gebruikt segmentatie om PCI te beschermen, past SLA-gebaseerde app-routing toe voor prestaties en handhaaft de operationele veiligheid door middel van preview, simulatie en gefaseerde koppeling.
← Data Plane Tunnels · Alle domeinen · Beveiliging →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →