Cisco 300-415: Data Plane Tunnels, BFD en Application-Aware Routing — 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 scheidt de control plane van de data plane en bouwt een versleutelde, beleidsgestuurde overlay over verschillende transports. De vSmart-controller beheert de control plane van de overlay en de connectiviteit van de WAN Edge, en distribueert routes, beveiligingssleutels en intenties via OMP. WAN Edge-routers vormen veilige IPsec data-plane-tunnels naar andere WAN Edges, terwijl controleverbindingen met vSmart, vBond en vManage standaard DTLS (of TLS) gebruiken. De beschikbaarheid en kwaliteit van paden worden continu gemeten met BFD, wat input levert voor Application-Aware Routing (AAR)-beleid om applicaties langs de best presterende tunnels te sturen volgens SLA-klassen gebaseerd op verlies, latency, jitter of MOS.

Basisprincipes van Overlay en Data-Plane

• Control plane versus data plane

  • Control plane: WAN Edges zetten veilige DTLS/TLS-controleverbindingen op met vBond (voor NAT-traversal en orkestratie), vSmart (uitwisseling van beleid en routes via OMP) en vManage (beheer, apparaatconfiguratie en certificaatopslag). In de ‘staging’-status vormen apparaten controleverbindingen, maar zetten ze geen data-tunnels op.
  • Data plane: WAN Edges vormen IPsec-tunnels rechtstreeks naar andere WAN Edges voor gebruikersverkeer. De data plane is verantwoordelijk voor het doorsturen en handhaaft de traffic-engineering-beslissingen die via het control-plane-beleid worden doorgegeven.

• IPsec data-plane-tunnels en TLOCs

  • Een Transport Locator (TLOC) identificeert uniek een WAN-transportkoppeling en wordt gedefinieerd door de tuple {system-IP, color, encapsulation}. Encapsulation is IPsec of GRE; in de meeste implementaties en op IOS XE SD-WAN (cEdge) wordt IPsec gebruikt.
  • Colors zijn semantische labels voor underlay-types en NAT-eigenschappen (bijvoorbeeld mpls, biz-internet, public-internet, lte, private1–private6). Publieke colors impliceren doorgaans NAT-traversal met ondersteuning van vBond.
  • Tunnels worden gevormd tussen elk bereikbaar paar TLOCs, tenzij beperkt door het ‘restrict’-attribuut. Met twee sites, elk met één WAN Edge en twee publieke TLOCs, en zonder ‘restrict’-attributen, worden er vier IPsec-tunnels gevormd (een full mesh tussen de color-paren).
  • TLOC-extensie stelt twee redundante WAN Edges op een site in staat om transports te delen via een cross-link, wat transportredundantie mogelijk maakt zonder fysieke circuits per chassis te dupliceren.

• Transport- en service-labels

  • vSmart gebruikt OMP om routes en TLOCs te adverteren en om labels toe te wijzen die in de overlay-header worden meegedragen. Transport-labels identificeren externe TLOCs voor het demultiplexen van verkeer over de overlay. Service-labels identificeren de doel-service-VPN of een gekoppelde service (‘chained service’). Deze labels zijn intern aan de SD-WAN-overlay en zijn geen MPLS-underlay-labels.

• Operationele afwegingen en faalscenario’s

  • Verkeerd geclassificeerde transports (bijvoorbeeld MPLS markeren als public-internet) kunnen leiden tot suboptimale tunnelvorming of fouten bij NAT-traversal.
  • Het ‘restrict’-attribuut voorkomt ongewenste full-mesh-groei; het weglaten ervan op internet-colors kan leiden tot een buitensporige tunnelschaal en onnodige probing-overhead.
  • Problemen met certificaten of de klok verhinderen connectiviteit met de control plane (DTLS/TLS). Zonder convergentie van de control plane met vSmart worden er geen data-plane-sleutels uitgewisseld en worden er geen IPsec-tunnels gevormd.

BFD-padbeschikbaarheid en kwaliteitsmeting

• Werking van BFD

  • Cisco SD-WAN voert BFD uit op elke data-plane-tunnel om vrijwel real-time beschikbaarheidsdetectie en kwaliteitsmeting te bieden. BFD gebruikt lichtgewicht periodieke ‘hellos’ om de up/down-status (blackouts) te detecteren en actieve ‘probes’ om latency, jitter en verlies (brownouts) te meten.
  • Belangrijke timers en intervallen
    • Hello-interval: doorgaans 1000 ms (configureerbaar per color of globaal).
    • Multiplier: doorgaans 6 (configureerbaar), wat een detectietijd oplevert van hello-interval × multiplier (bijvoorbeeld ~6 seconden).
    • App-probe-interval voor AAR-prestatiemonsters: doorgaans 1 seconde (configureerbaar), waarbij voortschrijdende gemiddelden worden berekend over een kort venster om tijdelijke pieken af te vlakken.
  • BFD-metingen
    • Latency: round-trip time van probes op elke tunnel.
    • Jitter: variatie in de latency tussen probes.
    • Loss: percentage van probes dat niet wordt geretourneerd.
    • MOS: afgeleid van latency, jitter en verlies voor de geschiktheid voor spraak.

• Afhandeling van brownout versus blackout

  • Blackout: een BFD-sessie die down is (geen connectiviteit) activeert de onmiddellijke verwijdering van het pad uit de forwarding. Verkeer wordt verplaatst volgens de voorkeur van de eerstvolgende beschikbare tunnel, zonder te wachten op AAR-evaluatie.
  • Brownout: BFD blijft up, maar de gemeten waarden overschrijden de SLA-drempels. AAR kan specifieke applicatiestromen naar alternatieve tunnels sturen die wel aan de SLA’s voldoen, zelfs terwijl de oorspronkelijke tunnel ander verkeer blijft verwerken.

• Ontwerprichtlijnen en afwegingen

  • Agressieve timers versnellen failover, maar verhogen de CPU- en bandbreedte-overhead, vooral in grote meshes. Breng de hello- en probe-intervallen in evenwicht met de schaal en de stabiliteit van het transport.
  • Asymmetrische padkenmerken (bijvoorbeeld satelliet of mobiel) vereisen soepelere SLA-drempels en mogelijk hogere multipliers om ‘flapping’ (snel wisselende status) te voorkomen.
  • Voor spraak- en interactieve apps hebben snellere app-probe-intervallen en het inschakelen van hysteresis/hold-down de voorkeur om oscillatie tijdens tijdelijke congestie te verminderen.

Application-Aware Routing: Beleids- en SLA-ontwerp

• Applicatie-identificatie en -classificatie

  • WAN Edges gebruiken DPI (NBAR2 op IOS XE SD-WAN) om applicaties te classificeren op basis van signatures, protocolheuristieken en, waar beschikbaar, metadata zoals TLS SNI en QUIC ALPN. Voor versleuteld verkeer zonder identificeerbare metadata, valt de engine terug op flow-attributen (5-tuple) en geconfigureerde mappings (poorten, DSCP).
  • Classificatie vindt doorgaans plaats op de eerste pakketten en wordt gecachet voor sessieconsistentie. Houd signatures up-to-date om de nauwkeurigheid te behouden.

• SLA-klassen en meetbeleid

  • Definieer SLA-klassen met drempelwaarden voor loss, latency, jitter en optioneel MOS. Elke SLA-klasse verwijst naar een performance-probe-profiel (app-probe) dat het sampling-interval en het smoothing-gedrag van BFD aanstuurt.
  • Typische SLA-voorbeelden:
    • Voice: latency ≤ 150 ms, jitter ≤ 30 ms, loss ≤ 1%, MOS ≥ 4.0.
    • Transactional: latency ≤ 200 ms, loss ≤ 1%.
    • Bulk: geen strikte SLA; geef de voorkeur aan paden met een hogere bandbreedte en lagere kosten.

• Gedrag van padvoorkeur

  • AAR-beleid koppelt applicatielijsten aan SLA-klassen en specificeert een preferred-color en backup-color (of TLOC-lijsten). De beslissingslogica:
    1. Als het voorkeurspad aan de SLA voldoet, wordt het verkeer via het voorkeurspad verzonden.
    2. Als het voorkeurspad de SLA schendt maar het back-uppad wel voldoet, stuur dan naar het back-uppad.
    3. Als geen enkel pad aan de SLA voldoet, gebruik dan het best beschikbare pad op basis van voorkeur of kosten (degrade gracefully).
  • Brownout-sturing is per-flow; bestaande flows kunnen worden verplaatst afhankelijk van het beleid (sturing van nieuwe flows is de standaard; een verplaatsing midden in een flow kan beperkt zijn voor TCP, tenzij session resiliency is ingebouwd).

• Elementen voor beleidsconstructie

  • Bouw app-lijsten (DPI-groepen), SLA-klassen (loss/latency/jitter/MOS) en TLOC-lijsten (colors) in vManage. Maak vervolgens een AAR-beleidssequentie aan die app-list → SLA-class → preferred/backup colors mapt.
  • Combineer met traffic data policies als u DSCP moet instellen, zones moet afdwingen of service chaining moet invoegen vóór AAR-beslissingen.
  • Gebruik control-policy afzonderlijk om de acceptatie/advertentie van routes te beïnvloeden; verwar AAR (data-policy) niet met control-policy. Site-lijsten bepalen het bereik waar AAR van toepassing is.

• Ontwerpoverwegingen

  • Te strikte SLA’s kunnen oscillatie veroorzaken. Introduceer hysteresis of penalty-timers om frequente padwisselingen te voorkomen.
  • Houd rekening met de kosten: plaats mobiele verbindingen met datalimiet (metered cellular paths) alleen als last-resort back-ups; schakel datalimieten (data caps) in waar beschikbaar.
  • Coördineer met QoS: AAR kiest het pad; per-path QoS en queueing moeten nog steeds kritieke klassen beschermen tijdens congestie.

Verificatie en Troubleshooting

• Snelle health checks

  • Control plane:
    • cEdge: show sdwan control connections
    • vEdge: show control connections
  • Data-plane tunnels:
    • cEdge: show sdwan tunnels
    • vEdge: show ipsec outbound-connections / show ipsec inbound-connections
  • BFD-sessies en -kwaliteit:
    • cEdge: show sdwan bfd sessions; show sdwan app-route stats
    • vEdge: show bfd sessions; show app-route stats

• Voorbeeld commando-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

• Waar je op moet letten

  • Tunnelstatus is ‘up’, maar BFD loss/latency/jitter overschrijdt de SLA: brownout—verwacht AAR-sturing. Valideer dat het back-up pad voldoet aan de SLA en dat de policy de juiste app-lijst koppelt.
  • BFD-sessie ‘flapping’: verminder de agressiviteit of onderzoek ‘underlay drops/queuing’; verifieer MTU en fragmentatie (afhandeling van DF-bit) om verlies van probes te voorkomen.
  • Geen tunnels gevormd over een ‘color’: verifieer de semantiek van de ‘color’ (NAT/public/private), de NAT-configuratie van de interface, en dat vBond bereikbaar is voor NAT-traversal. Controleer de tijd en certificaten als er geen control-verbindingen zijn.
  • Onverwachte full-mesh en probe-schaal: pas ‘restrict’ toe op internet-‘colors’ of gebruik TLOC-lijsten om de connectiviteit te beperken.
  • DPI-misclassificatie: update NBAR2-signatures en controleer of er geen conflicterende L4-poort-overrides zijn. Overweeg voor versleutelde apps classificatie op basis van SNI/ALPN of DSCP-markering ‘upstream’.

• Operationele redenering

  • Valideer altijd eerst de control-connectiviteit (vBond voor orkestratie/NAT, vSmart voor OMP/policy, vManage voor configuratie/certificaten). Zonder vSmart worden data-plane-sleutels niet gedistribueerd en wordt er geen IPsec SA gevormd.
  • Correleer AAR-beslissingen met BFD-metingen en SLA-klassen. Als een pad wordt gekozen dat tegen de verwachting in gaat, inspecteer dan de SLA-compliancestatus op het moment van de beslissing, niet alleen de huidige gemiddelden.
  • Vermijd bij dual-DC-ontwerpen dubbele LAN-routes door het overlay-AS op de DC WAN Edges te harmoniseren bij het herdistribueren van OMP↔BGP over een DC-interconnect.

Praktijkscenario

Contoso Health beheert 300 klinieken met dubbele transporten op elke locatie: MPLS (‘mpls color’) en breedband (‘biz-internet color’). Gebruikers melden af en toe een slechte spraakkwaliteit, terwijl data-applicaties prima werken. Het doel is om MPLS te prefereren voor spraak, een failover naar breedband uit te voeren tijdens brownouts, en een snelle blackout-failover zonder oscillatie te garanderen.

1. Valideer de overlay-health en de vorming van de data-plane

• Rationale: Bevestig de voorvereisten. Gebruik ‘show sdwan control connections’ om te verzekeren dat DTLS/TLS naar vSmart/vBond/vManage stabiel is en ‘show sdwan tunnels’ om de volledige MPLS- en breedband-tunnelmesh te verifiëren. Als tunnels over ‘biz-internet’ ontbreken, controleer dan de ‘color’-toewijzing en NAT; vBond moet bereikbaar zijn in de publieke ruimte om te assisteren bij NAT-traversal.

2. Kalibreer BFD- en probe-timers

• Rationale: Stel BFD hello in op 1000 ms, multiplier 6 voor een gebalanceerde ’liveness’-detectie (~6 s) en een redelijke schaal. Configureer het app-probe-interval op 1 s voor tijdige brownout-detectie. Overdreven agressieve timers kunnen CPU-overhead en ‘flapping’ veroorzaken; te ontspannen timers belemmeren de responsiviteit voor spraakverkeer.

3. Definieer SLA-klassen

• Rationale: Maak een SLA-klasse ‘Voice-SLA’ met latency ≤ 150 ms, jitter ≤ 30 ms, loss ≤ 1%, MOS ≥ 4.0. Maak een ‘Data-SLA’ met latency ≤ 200 ms, loss ≤ 1%. Deze drempelwaarden weerspiegelen de gevoeligheid van spraakverkeer en de typische WAN-prestaties; MOS consolideert de gebruikerservaring over meerdere metrieken.

4. Bouw applicatielijsten

• Rationale: Gebruik DPI (NBAR2) om ‘App-List-Voice’ te definiëren voor SIP/RTP/Teams/Zoom-media en ‘App-List-Data’ voor transactionele apps. Neem TLS SNI/QUIC ALPN-patronen op voor moderne spraak-/videoplatforms. Waar classificatie onzeker is, val terug op DSCP EF/AF41-markeringen die aan de LAN-edge worden afgedwongen.

5. Construeer AAR-policy

• Rationale: Koppel ‘App-List-Voice’ aan ‘Voice-SLA’ met ‘preferred-color mpls’ en ‘backup-color biz-internet’. Koppel ‘App-List-Data’ aan ‘Data-SLA’ met ‘preferred-color biz-internet’ en ‘backup-color mpls’ om MPLS-bandbreedte te behouden. Dit zorgt ervoor dat spraakverkeer MPLS gebruikt wanneer de verbinding gezond is en alleen overschakelt naar breedband tijdens brownouts of blackouts, terwijl dataverkeer de voorkeur geeft aan het kosteneffectieve internet.

6. Voeg hysteresis en hold-down toe

• Rationale: Configureer een ‘revert timer’ zodat spraakverkeer pas terugkeert naar MPLS na aanhoudende SLA-compliance (bijvoorbeeld 30–60 s). Dit voorkomt oscillatie tijdens tijdelijke jitter-pieken. Pas op een vergelijkbare manier een ‘penalty’ of ‘dampening’ toe op breedband als het herhaaldelijk de SLA schendt binnen een kort tijdsbestek.

7. Coördineer QoS en MTU

• Rationale: Zorg er op beide transporten voor dat EF-queueing en -shaping zijn afgestemd op de circuit-snelheden. Een mismatch kan de jitter/loss die door BFD-probes en spraak-RTP wordt waargenomen, verhogen. Valideer de path MTU en schakel DF uit waar fragmentatie onvermijdelijk is, om te voorkomen dat probe-drops worden aangezien voor packet loss.

8. Verifieer en itereer

• Rationale: Gebruik ‘show sdwan app-route stats sla-class Voice-SLA’ om de SLA pass/fail per tunnel te bevestigen. Observeer live flows met ‘show sdwan app-route statistics flows’ om te verzekeren dat spraakverkeer naar MPLS wordt gestuurd en alleen naar breedband overschakelt wanneer MPLS de SLA schendt. Veroorzaak tijdens tests opzettelijk congestie op MPLS om het brownout-gedrag te valideren en meet vervolgens de ‘reversion timing’.

Door deze stappen te volgen, zorgt Contoso Health ervoor dat BFD snelle blackout-detectie biedt, AAR reageert op brownouts met behulp van precieze SLA-klassen, en DPI spraakapplicaties nauwkeurig classificeert. De combinatie levert voorspelbare spraakkwaliteit, efficiënt gebruik van transporten en controleerbaar failover-gedrag over de gehele SD-WAN fabric.

← WAN Edge-configuratie en Templatebeheer · Alle domeinen · Gecentraliseerd Beleid en Traffic Engineering →

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