Cisco 300-410: MPLS, VRF's en Layer 3 VPN-services — Studiegids

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Onderdeel van de Cisco CCNP Enterprise 300-410 ENARSI — Studiegids. Oefen met geverifieerde antwoorden in het Cisco-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Multiprotocol Label Switching (MPLS) Layer 3 VPN’s scheiden de klantenrouting in virtuele routing- en forwarding-instanties (VRF’s), terwijl ze een gedeelde provider-core gebruiken voor transport. Provider Edge (PE) routers voegen labelstacks toe en verwijderen deze, zodat Provider (P) routers puur op basis van labels forwarden, wat schaalbaarheid en isolatie waarborgt. MP-BGP distribueert VPN-routes (VPNv4/VPNv6) met Route Distinguishers (RD’s) om uniciteit te garanderen en Route Targets (RT’s) om het import/export-beleid te beheren. Een goed ontwerp vereist een duidelijke scheiding van klant- en providerrollen, zorgvuldige labeldistributie en expliciet beleid voor route-lekkage en gedeelde services. De operatie vereist voorspelbare control-plane-statussen (IGP, LDP/RSVP, MP-BGP) en deterministisch data-plane-gedrag (labelstacking, PHP), met rigoureuze verificatie en foutisolatie over de CE–PE–core-grenzen heen.

MPLS Forwarding en Labeldistributie

Labelformaat en -stack
- Een MPLS shim-header bevat een 20-bit label, 3-bit Traffic Class (TC/EXP), 1-bit Bottom of Stack (S) en een 8-bit TTL.
- Pakketten dragen een stack: een buitenste ’transport’-label voor de PE-naar-PE LSP en een binnenste ‘VPN’-label dat de egress PE VRF (of service) identificeert.
- Penultimate Hop Popping (PHP) verwijdert het bovenste label op de voorlaatste P-router om de belasting op de egress PE te verminderen; explicit-null kan worden gebruikt om het bovenste label te behouden om de QoS/TTL-semantiek naar de egress te bewaren.
LDP-fundamentals
- P- en PE-routers draaien doorgaans een interior gateway protocol (IGP) om bereikbaarheid tot stand te brengen en het Label Distribution Protocol (LDP) om Forwarding Equivalence Classes (FEC’s) aan labels te koppelen.
- LDP ontdekt buren via UDP/646-hello’s en vormt labelsessies over TCP/646, wat zorgt voor betrouwbare labelsignalering. Targeted LDP (tLDP) kan offlink-sessies opbouwen voor specifieke FEC’s.
- Stijlen voor labeltoewijzing/-propagatie:
  - Independent vs. ordered control: een router kan labels toewijzen voor een FEC zodra hij een route kent (independent) of pas nadat hij een label heeft ontvangen van zijn next hop (ordered).
  - Liberal vs. conservative label retention: bewaar alle ontvangen labels of alleen die van de beste next hop, wat een afweging is tussen geheugengebruik en convergentiesnelheid.
- De LDP-router-ID is standaard het hoogste loopback-adres indien aanwezig (anders de hoogste actieve interface). Stabiliseer deze (en het transport) om sessie-churn te voorkomen; overweeg LDP-IGP-synchronisatie om blackholing tijdens convergentie te voorkomen.
Control-plane-scope van de P-router
- Core P-routers dragen geen VPN-routes; ze draaien alleen de underlay (IGP) en labelsignalering (LDP of RSVP-TE). RSVP-TE kan worden gebruikt in plaats van, of naast, LDP voor traffic engineering.
Data-plane-pad
- De ingress PE pusht VPN- en transportlabels; P-routers wisselen alleen het buitenste label; de voorlaatste P-router popt het transportlabel (tenzij explicit-null wordt gebruikt); de egress PE popt het VPN-label, selecteert de VRF en forwardt via een normale IP-lookup.
Praktische configuratie-enablers (IOS/IOS XE)
- Op core-gerichte interfaces:

undefined

Globaal:

undefined

Verifieer:

undefined

L3VPN Architectuur: Rollen, VRF’s, RD’s, RT’s en MP-BGP

Rollen en demarcaties
- CE (Customer Edge): draait een PE-gericht protocol (static, eBGP, OSPF, EIGRP) en bevat klantenroutes; is niet op de hoogte van MPLS.
- PE (Provider Edge): bevat per-tenant VRF’s, neemt deel aan MP-BGP (VPNv4/VPNv6) en voegt labels toe/verwijdert ze.
- P (Provider Core): alleen label-switching; geen VRF-status.
- Klant: administratieve eigenaar van de CE en het tenant-routingbeleid.
VRF’s en adresoverlap
- Elke tenant krijgt een VRF (aparte RIB/FIB). Overlappende IPv4/IPv6-adresruimtes tussen tenants zijn toegestaan.
- Route Distinguishers (RD’s) maken per-VRF-routes wereldwijd uniek door “RD:” aan de prefix toe te voegen om VPNv4/VPNv6 NLRI’s te vormen; RD’s zijn geen beveiligingsmechanisme en beheren geen beleid.
- Route Targets (RT’s) zijn BGP extended communities die worden gebruikt om routes bij export te taggen en te selecteren welke routes een VRF importeert. Het RT-beleid is de gezaghebbende controle voor import/export.
MP-BGP address families
- VPNv4: AFI 1, SAFI 128. MP_REACH_NLRI bevat de next hop en een per-route VPN-label. VPNv4-routes worden alleen gedistribueerd tussen PE-nodes (en route reflectors).
- VPNv6 (6VPE): AFI 2, SAFI 128. Maakt IPv6 VPN’s mogelijk over een IPv4 MPLS-core. De BGP next hop kan IPv4 blijven; de PE wijst VPN-labels toe per IPv6-route.
- Activeer extended communities op PE–PE BGP-sessies zodat RT’s worden meegestuurd.
Vereenvoudigd configuratiepatroon (PE)
- Definieer VRF en CE-koppeling:

undefined

MP-BGP voor VPNv4:

undefined

Per-VRF address families:

undefined

Voor 6VPE:

undefined

Verificatie

undefined

Beleid, Route Leaking, Gedeelde Services en Segmentatie

RT import/export-beleid
- Export: tag routes van een VRF met een of meer RT’s. Import: een VRF importeert elke route waarvan de RT overeenkomt met zijn importlijst.
- Fijmazige controle wordt bereikt met per-VRF route-maps (export/import maps) die prefixes matchen en RT’s instellen/manipuleren. Dit beperkt onbedoelde routeverspreiding.
Methoden voor route leaking
- RT-gebaseerd leaking (aanbevolen): definieer een Shared-Services VRF, exporteer serviceprefixes met RT SVC en importeer RT SVC in geselecteerde tenant-VRF’s. Gebruik export maps op tenants om te beperken welke tenant-routes terug naar de services worden geëxporteerd.
- Lokaal VRF-naar-VRF leaking: op sommige platformen kunnen statische routes verwijzen naar interfaces in andere VRF’s, of kan BGP peeren tussen VRF’s op dezelfde PE. Wees voorzichtig; dit omzeilt het RT-beleid en kan moeilijker te auditen zijn.
- Afwegingen op het gebied van beveiliging:
  - Te permissieve imports leiden tot any-to-any bereikbaarheid en potentiële ’lateral movement’.
  - Symmetrisch leaking zonder filters kan feedback-loops creëren of management/infra-prefixes blootstellen.
  - Geef de voorkeur aan een hub-and-spoke shared services-model met expliciete ‘allow lists’ (route-maps) en firewall-koppelingen.
Concepten en migratie van gesegmenteerde routing
- Enterprise-segmentatie begint met VRF-Lite binnen campussen en datacenters. MPLS L3VPN breidt die segmenten uit over het WAN zonder NAT, waardoor overlappende IP-adressen behouden blijven.
- Migratieaanpak:
  - Map elk on-prem VRF-Lite-segment naar een provider RT-paar.
  - Gebruik CE–PE-routing (eBGP heeft de voorkeur) om routes per segment deterministisch uit te wisselen.
  - Introduceer een Shared-Services VRF voor DNS/AD/Internet-egress en importeer deze selectief.
- Toekomstbestendige underlays:
  - LDP- of RSVP-TE-gebaseerde LSP’s worden op grote schaal ingezet. Segment Routing MPLS (SR-MPLS) kan LDP/RSVP in de underlay vervangen terwijl het L3VPN-servicemodel identiek blijft; alleen het transportlabel komt van SR in plaats van LDP/RSVP.

Operations: Controleplane, Dataplane, Verificatie en Foutisolatie

End-to-end pakketstroom
1. CE adverteert een prefix naar de ingress PE in VRF X.
2. Ingress PE installeert dit in de VRF X RIB/CEF, tagt het met export RT’s, creëert een VPNv4/v6 NLRI (RD:prefix) en wijst een VPN-label toe.
3. MP-BGP adverteert de route naar externe PE’s (of via route reflectors), met de next hop (ingress PE loopback) en het VPN-label.
4. De IGP en LDP/RSVP bouwen een transport-LSP op richting de egress PE next hop.
5. Dataplane: ingress PE pusht het VPN-label (binnenste) en het transportlabel (buitenste); P-routers swappen de buitenste labels; de voorlaatste P popt het buitenste label (PHP); de egress PE gebruikt het binnenste label om de VRF te selecteren en stuurt het pakket door naar de egress CE.
Veelvoorkomende storingsmodi en afwegingen
- Underlay-bereikbaarheid of LDP down: MP-BGP kan up blijven, maar zonder een transport-LSP kan de ingress PE geen geldig buitenste label pushen; pakketten worden gedropt. Gebruik LDP-IGP-synchronisatie om blackholing te voorkomen.
- Ontbrekend VPN-label: VPNv4-route is aanwezig maar zonder label (of label 3 met onverwachte semantiek) verbreekt de forwarding. Bevestig dat de egress PE labels toewijst per VRF; controleer beleid dat de label-advertentie zou kunnen onderdrukken.
- RT-mismatch: routes zijn aanwezig in de verzendende VRF maar worden niet geïmporteerd door de ontvanger. Verifieer de RT’s en dat extended communities worden uitgewisseld (send-community extended).
- MTU/fragmentatie: label-stacks voegen overhead toe. Zorg ervoor dat core- en PE-interfaces voldoende MPLS MTU ondersteunen om drops te voorkomen; pas MSS aan indien nodig.
- QoS en PHP: EXP-naar-QoS-mapping kan verloren gaan bij de egress als het bovenste label wordt gepopt. Gebruik explicit-null voor QoS-transparantie op de egress-hop.
- iBGP-padselectie in VPNv4: zonder maximum-paths ibgp N wordt mogelijk slechts één pad gebruikt, zelfs met ECMP in de core; activeer multipath voor load-sharing.
Verificatieworkflow
- CE–PE edge:

undefined

, of

undefined

MP-BGP:

undefined

;

undefined

Labels:

undefined

;

undefined

;

undefined

Dataplane:

undefined

;

undefined

of naar de egress PE loopback; valideer EXP/TC-markering als QoS van toepassing is

Gezondheid: overweeg BFD op CE–PE- en PE–PE-adjacencies om routeringssessies te beschermen.
Foutisolatie over de CE, PE en de provider-core
1. Valideer de CE–PE-adjacency en dat VRF-routes bestaan op de ingress PE.
2. Bevestig dat de route wordt geëxporteerd naar VPNv4 met een verwachte RT en dat een VPN-label aanwezig is op de egress PE.
3. Zorg ervoor dat er een transport-LSP bestaat van de ingress- naar de egress-PE (LDP/RSVP-neighbors en label richting de egress PE-loopback).
4. Test de PE–PE-bereikbaarheid met ping/traceroute vanaf de PE-loopback; verifieer de ECMP-consistentie.
5. Controleer op de egress PE of het VPN-label wordt omgezet naar de juiste VRF en CE-interface.
6. Als alle controleplane-controles slagen, verzamel dan dataplane-tellers en verifieer het MTU- en QoS-gedrag.

Praktisch Probleemscenario

Contoso Manufacturing is van plan om te migreren van een VRF-Lite WAN naar een provider MPLS L3VPN, en tegelijkertijd een centrale Shared-Services VRF voor internet en DNS te introduceren. Tenants A en B gebruiken beide intern 10.10.0.0/16 en moeten geïsoleerd blijven, behalve voor selectieve toegang tot Shared-Services.

Aanpak

Definieer VRF’s en RT-beleid op PE’s
- Configuratie:

undefined

Rationale: RD’s zorgen voor uniciteit bij overlappende 10.10.0.0/16-routes. RT’s definiëren segmentatiegrenzen. Een afzonderlijke RT voor Shared-Services biedt een controleerbare hub.

Koppel CE-interfaces aan de juiste VRF’s en breng CE–PE-routing tot stand
- Configuratievoorbeeld:

undefined

Rationale: CE–PE eBGP biedt duidelijke beleidsgrenzen en controle per tenant zonder dat attributen tussen tenants lekken.

Activeer MP-BGP tussen PE’s en propageer RT’s en VPN-labels
- Configuratie:

undefined

Rationale: VPNv4-advertentie draagt zowel RT’s als per-route VPN-labels; het activeren van iBGP-multipath bereidt voor op ECMP over meerdere RR/PE-paden.

Bouw en verifieer transport-LSP’s in de core
- Configuratie:

undefined

Rationale: LDP creëert PE-naar-PE LSP’s voor het buitenste label. ECMP in IGP plus LDP ondersteunt schaalbaarheid en convergentie. Verifieer met

undefined

Implementeer selectief lekken van Shared-Services
- Configuratie (op tenants):

undefined

Rationale: Tenants importeren alleen Shared-Services-routes; Shared-Services importeert tenant-routes maar exporteert alleen goedgekeurde prefixes terug om te voorkomen dat tenants elkaars routes via de hub leren.

Valideer controle-/dataplanes en MTU/QoS
- Commando’s:

undefined

Rationale: Bevestigt VRF-routing, label-bindings en end-to-end bereikbaarheid. Controleer interface-MTU’s om de label-stack te accommoderen en QoS-markeringen te behouden; activeer explicit-null als de egress EXP-zichtbaarheid nodig heeft.

Introduceer IPv6 VPN’s met behulp van 6VPE
- Configuratie:

undefined

Rationale: Biedt IPv6-segmentatie over dezelfde IPv4 MPLS-core met per-route VPN-labels en hetzelfde op RT gebaseerde beleidsmodel.

Dit stapsgewijze plan behoudt segmentatie, maakt gecontroleerde gedeelde toegang mogelijk, schaalt via label-switching in de core en biedt duidelijke verificatiepunten voor snelle foutisolatie.

← Route-redistributie en beleidsgebaseerd routeren · Alle domeinen · Multicast-routing en distributie →

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 →

Cisco 300-410: MPLS, VRF's en Layer 3 VPN-services — Studiegids

Overzicht

MPLS Forwarding en Labeldistributie

L3VPN Architectuur: Rollen, VRF’s, RD’s, RT’s en MP-BGP

Definieer VRF en CE-koppeling:

MP-BGP voor VPNv4:

Per-VRF address families:

Voor 6VPE:

Verificatie

Beleid, Route Leaking, Gedeelde Services en Segmentatie

Operations: Controleplane, Dataplane, Verificatie en Foutisolatie

Praktisch Probleemscenario

Configuratie:

Configuratievoorbeeld:

Configuratie:

Configuratie:

Configuratie (op tenants):

Commando’s:

Configuratie:

Pass the whole exam — not just this question

Related guides

Eén abonnement. Elk examen.