MPLS & Layer 3 VPNs: Complete Implementation Guide

Multi-Protocol Label Switching (MPLS) Layer 3 VPNs have become the foundation of modern enterprise connectivity and service provider offerings. This comprehensive guide explores the architecture, implementation, and best practices for deploying scalable MPLS L3VPN services.

MPLS L3VPN Architecture Overview

MPLS L3VPNs leverage BGP/MPLS to create isolated routing domains over a shared infrastructure. The architecture consists of three key components:

  • Customer Edge (CE): Customer-owned router connecting to the service provider network
  • Provider Edge (PE): Service provider router maintaining VPN routing tables (VRFs)
  • Provider (P): Core MPLS routers performing label switching without VPN awareness

Key Technologies

L3VPNs combine several technologies:

  1. VRF (Virtual Routing and Forwarding): Isolated routing instances on PE routers
  2. Route Distinguishers (RD): Creates unique VPNv4/VPNv6 addresses
  3. Route Targets (RT): Controls route import/export between VRFs
  4. MP-BGP: Distributes VPN routes with extended community attributes
  5. Label Stack: Two-label MPLS forwarding (transport + VPN labels)

VRF Configuration and Design

Virtual Routing and Forwarding instances maintain separate routing tables, preventing route leakage between customers.

Practical Implementation

Creating a VRF Instance

! Define VRF for Customer A
vrf definition CUSTOMER_A
 rd 65000:100
 !
 address-family ipv4
  route-target export 65000:100
  route-target import 65000:100
 exit-address-family
 !
 address-family ipv6
  route-target export 65000:100
  route-target import 65000:100
 exit-address-family
!

! Apply VRF to customer-facing interface
interface GigabitEthernet0/0/1
 description Customer A Site 1
 vrf forwarding CUSTOMER_A
 ip address 10.10.1.1 255.255.255.252
 negotiation auto
!

Key elements:

  • RD 65000:100: Makes customer routes globally unique
  • RT 65000:100: Controls which PE routers import these routes
  • Dual-stack support: Separate RTs for IPv4 and IPv6

MP-BGP Configuration for VPNv4

Multi-Protocol BGP extends standard BGP to carry VPN routing information with route distinguishers and targets.

router bgp 65000
 bgp router-id 192.168.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 !
 neighbor 192.168.1.2 remote-as 65000
 neighbor 192.168.1.2 update-source Loopback0
 !
 address-family vpnv4
  neighbor 192.168.1.2 activate
  neighbor 192.168.1.2 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf CUSTOMER_A
  redistribute connected
  redistribute static
 exit-address-family
!

Understanding the Label Stack

MPLS L3VPN packets carry two labels:

Label Purpose Allocated By
Transport (Outer) PE-to-PE LSP forwarding LDP, RSVP, or SR
VPN (Inner) VRF identification at egress PE MP-BGP

The outer label is swapped at each P router, while the inner VPN label remains unchanged until reaching the egress PE.

PE-CE Routing Protocols

Static Routing

Simplest option for small sites:

! PE Router
ip route vrf CUSTOMER_A 172.16.0.0 255.255.0.0 10.10.1.2

! CE Router
ip route 0.0.0.0 0.0.0.0 10.10.1.1

OSPF as PE-CE Protocol

OSPF requires special handling to prevent routing loops:

router ospf 100 vrf CUSTOMER_A
 router-id 10.10.1.1
 redistribute bgp 65000 subnets
 network 10.10.1.0 0.0.0.3 area 0
!
router bgp 65000
 address-family ipv4 vrf CUSTOMER_A
  redistribute ospf 100 match internal external 1 external 2
 exit-address-family

Critical: Use capability vrf-lite or sham-links to prevent backdoor routes from being preferred over the MPLS core.

BGP as PE-CE Protocol

Preferred for multi-homed sites and advanced routing control:

router bgp 65000
 address-family ipv4 vrf CUSTOMER_A
  neighbor 10.10.1.2 remote-as 65001
  neighbor 10.10.1.2 activate
  neighbor 10.10.1.2 as-override
  neighbor 10.10.1.2 send-community both
 exit-address-family

The as-override feature prevents AS-path loops when the customer uses the same ASN at multiple sites.

Laboratory Exercise

Verification and Troubleshooting

Check VRF Status

# Display all VRFs
show vrf

# Show VRF routing table
show ip route vrf CUSTOMER_A

# Verify VRF interfaces
show ip vrf interfaces

Validate MP-BGP

# Check VPNv4 BGP table
show bgp vpnv4 unicast all

# Verify specific VRF BGP routes
show bgp vpnv4 unicast vrf CUSTOMER_A

# Display route targets
show bgp vpnv4 unicast vrf CUSTOMER_A 172.16.1.0/24

MPLS Label Verification

# Show VPN labels
show mpls forwarding-table vrf CUSTOMER_A

# Display label bindings
show mpls ldp bindings

# Trace MPLS path
traceroute vrf CUSTOMER_A 172.16.1.1 source 10.10.1.1

Advanced L3VPN Features

Route Targets for Hub-and-Spoke Topologies

Use different import/export RTs to create hub-and-spoke designs:

! Hub Site VRF
vrf definition HUB
 rd 65000:1
 address-family ipv4
  route-target export 65000:1
  route-target import 65000:10
  route-target import 65000:20
 exit-address-family
!

! Spoke Site 1 VRF
vrf definition SPOKE1
 rd 65000:10
 address-family ipv4
  route-target export 65000:10
  route-target import 65000:1
 exit-address-family

This ensures spoke-to-spoke traffic traverses the hub, enabling firewall inspection or traffic monitoring.

Extranet VPNs

Allow controlled route sharing between different VPNs:

vrf definition CUSTOMER_A
 rd 65000:100
 address-family ipv4
  route-target export 65000:100
  route-target import 65000:100
  route-target import 65000:999  ! Import shared services
 exit-address-family
!

vrf definition SHARED_SERVICES
 rd 65000:999
 address-family ipv4
  route-target export 65000:999
  route-target import 65000:100  ! Import from Customer A
  route-target import 65000:200  ! Import from Customer B
 exit-address-family

Carrier Supporting Carrier (CSC)

Enables one service provider to offer MPLS services over another provider’s backbone, creating hierarchical VPNs.

Security Considerations

  • VRF Isolation: Hardware-level separation prevents cross-VPN packet leakage
  • PE-CE Authentication: Use MD5 authentication on BGP/OSPF sessions
  • MPLS TTL Propagation: Disable to hide core topology (no mpls ip propagate-ttl)
  • Control Plane Protection: Rate-limit BGP sessions and filter unneeded routes

Scalability Best Practices

  1. Route Reflectors: Use RRs for VPNv4 route distribution in large networks
  2. RT Constraint: Implement RT filtering to reduce BGP table size
  3. Aggregate Routes: Summarize customer routes where possible
  4. Separate RDs per PE: Use unique RDs even for same VPN for load balancing

Troubleshooting Common Issues

Symptom Possible Cause Resolution
No routes in VRF Missing RT import Verify route-target configuration
Ping fails across VPN No VPN label Check MP-BGP session and label allocation
Route loops with OSPF Missing domain-id or DN bit Configure sham-link or capability vrf-lite
BGP routes not advertised Missing extended community Add send-community extended

Conclusion

MPLS Layer 3 VPNs provide secure, scalable, and flexible enterprise connectivity solutions. By leveraging VRFs, MP-BGP, and MPLS label stacking, service providers can deliver isolated routing domains with QoS guarantees and traffic engineering capabilities.

Mastering L3VPN design patterns—from basic any-to-any topologies to advanced hub-and-spoke and extranet designs—enables network engineers to architect solutions meeting diverse business requirements while maintaining operational efficiency.

Parveen Jindgar

Parveen Jindgar

Engineering Leader

I am an engineering leader with over 20 years of experience working on large-scale packet networks in Service Provider and latency-sensitive environments. My work has centered on end-to-end architectural ownership of backbone and edge infrastructures — spanning platform and vendor selection, routing and control-plane design, and the evolution of networks under real operational and economic constraints. PacketBytes is a personal space where I document the engineering thinking behind these systems — examining architectures, control planes, and design trade-offs as they behave under real traffic, real failures, and real operational pressure, beyond configuration and into intent.

Leave a Reply

Your email address will not be published. Required fields are marked *