Cisco 300-410: MPLS, VRFs and Layer 3 VPN Services — Study Guide

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

Part of the Cisco CCNP Enterprise 300-410 ENARSI — Study Guide. Practice with verified answers in the Cisco exam hub, or take timed practice tests on ExamRoll.io.

Overview

Multiprotocol Label Switching (MPLS) Layer 3 VPNs separate customer routing into virtual routing and forwarding instances (VRFs) while using a shared provider core for transport. Provider Edge (PE) routers impose and remove label stacks so Provider (P) routers forward purely on labels, preserving scale and isolation. MP-BGP distributes VPN routes (VPNv4/VPNv6) with Route Distinguishers (RDs) to ensure uniqueness and Route Targets (RTs) to control import/export policy. Proper design demands clear separation of customer and provider roles, careful label distribution, and explicit policies for route leaking and shared services. Operations require predictable control-plane states (IGP, LDP/RSVP, MP-BGP) and deterministic data-plane behavior (label stacking, PHP), with rigorous verification and fault isolation across CE–PE–core boundaries.

MPLS Forwarding and Label Distribution

• Label format and stack

  • An MPLS shim header contains a 20-bit label, 3-bit Traffic Class (TC/EXP), 1-bit Bottom of Stack (S), and 8-bit TTL.
  • Packets carry a stack: outer “transport” label for the PE-to-PE LSP and inner “VPN” label identifying the egress PE VRF (or service).
  • Penultimate Hop Popping (PHP) removes the top label at the penultimate P router to reduce egress PE load; explicit-null can be used to retain the top label to preserve QoS/TTL semantics to the egress.

• LDP fundamentals

  • P and PE routers typically run an interior gateway protocol (IGP) to establish reachability and the Label Distribution Protocol (LDP) to map Forwarding Equivalence Classes (FECs) to labels.
  • LDP discovers neighbors via UDP/646 hellos and forms label sessions over TCP/646, providing reliable label signaling. Targeted LDP (tLDP) can build offlink sessions for specific FECs.
  • Label allocation/propagation styles:
    • Independent vs ordered control: a router may allocate labels for a FEC as soon as it knows a route (independent) or only when it has received a label from its next hop (ordered).
    • Liberal vs conservative label retention: keep all received labels or only those from the best next hop, trading memory for convergence agility.
  • LDP router ID defaults to the highest loopback address if present (else highest active interface). Stabilize it (and the transport) to avoid session churn; consider LDP-IGP synchronization to prevent blackholing during convergence.

• P router control-plane scope

  • Core P routers do not carry VPN routes; they only run the underlay (IGP) and label signaling (LDP or RSVP-TE). RSVP-TE may be used instead of, or alongside, LDP to engineer traffic.

• Data-plane path

  • Ingress PE pushes VPN and transport labels; P routers swap only the outer label; penultimate P pops the transport label (unless explicit-null is in use); egress PE pops the VPN label, selects the VRF, and forwards via a normal IP lookup.

• Practical configuration enablers (IOS/IOS XE)

  • On core-facing interfaces: mpls ip
  • Globally: mpls label protocol ldp
  • Verify: show mpls ldp neighbor, show mpls ldp bindings, show mpls forwarding-table

L3VPN Architecture: Roles, VRFs, RDs, RTs, and MP-BGP

• Roles and demarcations

  • CE (Customer Edge): runs a PE-facing protocol (static, eBGP, OSPF, EIGRP) and holds customer routes; unaware of MPLS.
  • PE (Provider Edge): holds per-tenant VRFs, participates in MP-BGP (VPNv4/VPNv6), and imposes/strips labels.
  • P (Provider Core): label-switching only; no VRF state.
  • Customer: administrative owner of CE and tenant routing policies.

• VRFs and address overlap

  • Each tenant gets a VRF (separate RIB/FIB). Overlapping IPv4/IPv6 spaces across tenants are permitted.
  • Route Distinguishers (RDs) make per-VRF routes globally unique by prepending “RD:” to the prefix to form VPNv4/VPNv6 NLRIs; RDs are not a security mechanism and do not control policy.
  • Route Targets (RTs) are BGP extended communities used to tag routes on export and select which routes a VRF imports. RT policy is the authoritative import/export control.

• MP-BGP address families

  • VPNv4: AFI 1, SAFI 128. MP_REACH_NLRI carries next hop and a per-route VPN label. VPNv4 routes are distributed only among PE nodes (and route reflectors).
  • VPNv6 (6VPE): AFI 2, SAFI 128. Enables IPv6 VPNs over an IPv4 MPLS core. BGP next hop may remain IPv4; the PE assigns VPN labels per IPv6 route.
  • Enable extended communities on PE–PE BGP sessions so RTs are carried.

• Simplified configuration pattern (PE)

  • Define VRF and CE attachment:
    • ip vrf CUST-A rd 65000:10 route-target export 65000:10 route-target import 65000:10
    • interface GigabitEthernet0/0 ip vrf forwarding CUST-A ip address 10.0.0.1 255.255.255.252
  • MP-BGP for VPNv4:
    • router bgp 65000 neighbor 192.0.2.2 remote-as 65000 neighbor 192.0.2.2 update-source Loopback0 address-family vpnv4 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended maximum-paths ibgp 2
  • Per-VRF address families:
    • address-family ipv4 vrf CUST-A redistribute connected
    • address-family ipv6 vrf CUST-A redistribute connected
  • For 6VPE:
    • address-family vpnv6 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended

• Verification

  • show ip route vrf CUST-A
  • show bgp vpnv4 vrf CUST-A
  • show bgp vpnv6 vrf CUST-A
  • show bgp vpnv4 all summary

Policy, Route Leaking, Shared Services, and Segmentation

• RT import/export policy

  • Export: tag routes from a VRF with one or more RTs. Import: a VRF imports any route whose RT matches its import list.
  • Fine-grained control is achieved with per-VRF route-maps (export/import maps) that match prefixes and set/manipulate RTs. This limits unintended route spread.

• Route leaking methods

  • RT-based leaking (recommended): define a Shared-Services VRF, export service prefixes with RT SVC, and import RT SVC into selected tenant VRFs. Use export maps on tenants to restrict which tenant routes are exported back to services.
  • Local VRF-to-VRF leaking: on some platforms, static routes can point to interfaces in other VRFs, or BGP can peer between VRFs on the same PE. Use cautiously; this bypasses RT policy and can be harder to audit.
  • Security trade-offs:
    • Overly permissive imports lead to any-to-any reachability and potential lateral movement.
    • Symmetric leaking without filters can create feedback loops or expose management/infra prefixes.
    • Prefer a hub-and-spoke shared services model with explicit allow lists (route-maps) and firewall interlocks.

• Segmented routing concepts and migration

  • Enterprise segmentation starts with VRF-Lite inside campuses and data centers. MPLS L3VPN extends those segments across the WAN without NAT, preserving overlapping IP.
  • Migration approach:
    • Map each on-prem VRF-Lite segment to a provider RT pair.
    • Use CE–PE routing (eBGP is preferred) to exchange per-segment routes deterministically.
    • Introduce a Shared-Services VRF for DNS/AD/Internet egress and import it selectively.
  • Future-ready underlays:
    • LDP- or RSVP-TE-based LSPs are widely deployed. Segment Routing MPLS (SR-MPLS) can replace LDP/RSVP in the underlay while keeping the L3VPN service model identical; only the transport label comes from SR rather than LDP/RSVP.

Operations: Control Plane, Data Plane, Verification, and Fault Isolation

• End-to-end packet flow

  1. CE advertises a prefix to the ingress PE into VRF X.
  2. Ingress PE installs it in VRF X RIB/CEF, tags it with export RTs, creates a VPNv4/v6 NLRI (RD:prefix) and allocates a VPN label.
  3. MP-BGP advertises the route to remote PEs (or via route reflectors), carrying next hop (ingress PE loopback) and the VPN label.
  4. The IGP and LDP/RSVP establish a transport LSP toward the egress PE next hop.
  5. Data plane: ingress PE pushes VPN label (inner) and transport label (outer); P routers swap outer labels; penultimate P pops outer (PHP); egress PE uses the inner label to select VRF and forwards to the egress CE.

• Common failure modes and trade-offs

  • Underlay reachability or LDP down: MP-BGP may remain up, but without a transport LSP the ingress PE cannot push a valid outer label; packets drop. Use LDP-IGP sync to prevent blackholing.
  • Missing VPN label: VPNv4 route present but no label (or label 3 with unexpected semantics) breaks forwarding. Confirm egress PE allocates labels per VRF; check policy that might suppress label advertisement.
  • RT mismatch: routes present in the sending VRF but not imported by the receiver. Verify RTs and that extended communities are exchanged (send-community extended).
  • MTU/fragmentation: label stacks add overhead. Ensure core and PE interfaces support sufficient MPLS MTU to avoid drops; adjust MSS if needed.
  • QoS and PHP: EXP-to-QoS mapping can be lost at egress if the top label is popped. Use explicit-null for QoS transparency on the egress hop.
  • iBGP path selection in VPNv4: without maximum-paths ibgp N, only one path may be used even with ECMP in the core; enable multipath to load-share.

• Verification workflow

  • CE–PE edge: show ip route vrf TENANT, show bgp ipv4 vrf TENANT, or show ospf/eigrp vrf TENANT
  • MP-BGP: show bgp vpnv4 all summary; show bgp vpnv4 vrf TENANT RD:prefix
  • Labels: show mpls ldp neighbor; show mpls ldp bindings; show mpls forwarding-table
  • Data plane: show ip cef vrf TENANT prefix; traceroute mpls ipv4 RD:prefix or to egress PE loopback; validate EXP/TC marking if QoS is in scope
  • Health: consider BFD on CE–PE and PE–PE adjacencies to protect routing sessions.

• Fault isolation across CE, PE, and provider core

  1. Validate CE–PE adjacency and VRF routes exist on the ingress PE.
  2. Confirm the route is exported to VPNv4 with an expected RT and a VPN label present on the egress PE.
  3. Ensure transport LSP exists from ingress to egress PE (LDP/RSVP neighbors and label toward the egress PE loopback).
  4. Test PE–PE reachability using ping/traceroute sourced from the PE loopback; verify ECMP consistency.
  5. On the egress PE, check that the VPN label resolves to the proper VRF and CE interface.
  6. If all control-plane checks pass, capture data-plane counters and verify MTU and QoS behavior.

Practical Problem Scenario

Contoso Manufacturing plans to migrate from a VRF-Lite WAN to a provider MPLS L3VPN while introducing a central Shared-Services VRF for Internet and DNS. Tenants A and B both use 10.10.0.0/16 internally and must remain isolated except for selective access to Shared-Services.

Approach

1. Define VRFs and RT policy on PEs

   • Configuration:
     • ip vrf TENANT-A rd 64512:10 route-target export 64512:10 route-target import 64512:10
     • ip vrf TENANT-B rd 64512:20 route-target export 64512:20 route-target import 64512:20
     • ip vrf SHARED-SVCS rd 64512:100 route-target export 64512:100 route-target import 64512:100
   • Rationale: RDs ensure uniqueness across overlapping 10.10.0.0/16 routes. RTs define segmentation boundaries. A distinct RT for Shared-Services provides a controllable hub.

2. Attach CE interfaces to the correct VRFs and bring up CE–PE routing

   • Configuration example:
     • interface GigabitEthernet0/0 ip vrf forwarding TENANT-A ip address 10.10.0.1 255.255.255.252
     • router bgp 64512 address-family ipv4 vrf TENANT-A neighbor 10.10.0.2 remote-as 65010 neighbor 10.10.0.2 activate
   • Rationale: CE–PE eBGP provides clear policy boundaries and per-tenant control without leaking attributes across tenants.

3. Enable MP-BGP between PEs and propagate RTs and VPN labels

   • Configuration:
     • router bgp 64512 neighbor 192.0.2.2 remote-as 64512 neighbor 192.0.2.2 update-source Loopback0 address-family vpnv4 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended maximum-paths ibgp 2
   • Rationale: VPNv4 advertisement carries both RTs and per-route VPN labels; enabling iBGP multipath prepares for ECMP across multiple RR/PE paths.

4. Build and verify transport LSPs in the core

   • Configuration:
     • mpls label protocol ldp
     • interface Bundle10 ip address 198.51.100.1 255.255.255.0 mpls ip
   • Rationale: LDP creates PE-to-PE LSPs for the outer label. ECMP in IGP plus LDP supports scale and convergence. Verify with show mpls ldp neighbor and show mpls forwarding-table.

5. Implement Shared-Services selective leaking

   • Configuration (on tenants):
     • ip vrf TENANT-A route-target import 64512:100
     • ip vrf TENANT-B route-target import 64512:100
     • ip vrf SHARED-SVCS route-target import 64512:10 route-target import 64512:20 export map SVC-EXPORT-FILTER
     • route-map SVC-EXPORT-FILTER permit 10 match ip address prefix-list SVC-ALLOWED
     • ip prefix-list SVC-ALLOWED permit 203.0.113.0/24
   • Rationale: Tenants import only Shared-Services routes; Shared-Services imports tenant routes but exports back only approved prefixes to prevent tenants from learning each other’s routes through the hub.

6. Validate control/data planes and MTU/QoS

   • Commands:
     • show ip route vrf TENANT-A
     • show bgp vpnv4 vrf TENANT-A 10.10.5.0/24
     • show mpls ldp bindings
     • show mpls forwarding-table
     • ping vrf TENANT-A 203.0.113.10
   • Rationale: Confirms VRF routing, label bindings, and end-to-end reachability. Check interface MTUs to accommodate the label stack and preserve QoS markings; enable explicit-null if the egress needs EXP visibility.

7. Introduce IPv6 VPNs using 6VPE

   • Configuration:
     • address-family vpnv6 neighbor 192.0.2.2 activate neighbor 192.0.2.2 send-community extended
     • address-family ipv6 vrf TENANT-A redistribute connected
   • Rationale: Provides IPv6 segmentation across the same IPv4 MPLS core with per-route VPN labels and the same RT-based policy model.

This staged plan preserves segmentation, enables controlled shared access, scales via label switching in the core, and provides clear verification points for rapid fault isolation.

← Route Redistribution and Policy-Based Routing · All domains · Multicast Routing and Distribution →

Practice these questions → · Timed practice on ExamRoll.io →