Cisco MPLS Configuration on IOS XE

Cisco MPLS configuration on IOS XE: enabling MPLS forwarding, LDP, LDP-IGP sync, VRFs for L3VPN, and MP-BGP between PEs. With a complete PE config example.

Configuring MPLS on Cisco IOS XE breaks down into a few discrete tasks: enabling MPLS forwarding on the right interfaces, configuring LDP, integrating with the IGP for label distribution, and (for L3VPN) layering on VRFs and MP-BGP. This article walks through each task with copy-paste-able configurations.

If you are bringing up your first MPLS router, replicating an existing config in a lab, or troubleshooting a partial deployment, this is the operator's walkthrough.

Prerequisites

Before configuring MPLS:

  1. An IGP must be running between the routers that will participate in MPLS. Loopbacks must be reachable across all PEs and Ps.
  2. Loopback interfaces should be created on every router and used as the IGP/MPLS router-id source. Stable, always-up.
  3. The interfaces that will run MPLS must already have IP addressing and be in the IGP.

This article assumes OSPF is the IGP and Loopback0 is the router-id loopback.

Basic MPLS Forwarding

The minimum config to enable MPLS on an interface:

interface GigabitEthernet0/0/0
 ip address 10.0.12.1 255.255.255.252
 mpls ip
 mpls label protocol ldp

mpls ip enables MPLS forwarding and starts LDP discovery. mpls label protocol ldp selects LDP (the alternative is the legacy TDP, which you almost never want). On modern IOS XE, LDP is the default; this command is for explicitness.

Apply to every router-to-router interface inside the MPLS domain. Customer-facing interfaces (PE-to-CE) typically do not run MPLS.

LDP Configuration

Global LDP settings:

mpls ldp router-id Loopback0 force
mpls ldp sync

force on the router-id command makes it use Loopback0 even if there are other interfaces with higher IPs. Without force, the router-id only changes after a reload, which can cause unexpected behavior.

mpls ldp sync globally enables LDP-IGP synchronization for all OSPF interfaces. Always enable in production - prevents transient drops on link bring-up.

Optional per-interface settings:

interface GigabitEthernet0/0/0
 mpls ip
 mpls ldp sync           ! Per-interface (override global)
 mpls ldp discovery hello interval 5    ! Default 5s; tune lower for faster convergence
 mpls ldp discovery hello holdtime 15

VRF Configuration for L3VPN

Each customer gets a VRF on every PE that serves them.

vrf definition CUSTOMER-A
 description Customer A - VPN service
 rd 65001:1
 address-family ipv4
  route-target export 65001:100
  route-target import 65001:100
 exit-address-family

Place customer-facing interfaces into the VRF:

interface GigabitEthernet0/0/1
 vrf forwarding CUSTOMER-A
 ip address 192.168.1.1 255.255.255.0

Note: vrf forwarding erases any existing IP configuration on the interface. Set the VRF first, then the IP, otherwise you have to retype the IP.

MP-BGP for L3VPN

iBGP between PEs, sourced from loopbacks, with the vpnv4 unicast address family for VPN routes:

router bgp 65001
 ! Generic BGP setup
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast            ! Don't activate per-neighbor by default

 ! Peer with other PE (typically via route reflector at scale)
 neighbor 10.10.10.10 remote-as 65001
 neighbor 10.10.10.10 update-source Loopback0

 ! VPNv4 address family
 address-family vpnv4 unicast
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended  ! Critical for RT propagation
 exit-address-family

 ! Per-VRF address family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  redistribute static
  ! Optional BGP PE-CE
  neighbor 192.168.1.2 remote-as 65100
  neighbor 192.168.1.2 activate
 exit-address-family

Three things to notice. First, send-community extended is mandatory - RTs are extended communities. Second, the address-family ipv4 vrf block configures redistribution and PE-CE peering for that specific VRF. Third, no bgp default ipv4-unicast prevents BGP from auto-activating new neighbors for the global IPv4 table; you have to explicitly activate each per-AF.

Route Reflector Pattern

At scale, full-mesh iBGP between every PE is unmanageable. Route reflectors break the iBGP loop-prevention rule in a controlled way: a route reflector can re-advertise iBGP-learned routes to its clients.

! On the route reflector
router bgp 65001
 address-family vpnv4 unicast
  neighbor 1.1.1.1 activate
  neighbor 1.1.1.1 route-reflector-client
  neighbor 2.2.2.2 activate
  neighbor 2.2.2.2 route-reflector-client
  ...
 exit-address-family

Each PE peers only with the route reflector instead of with every other PE. Two RRs for redundancy. See the BGP cluster pillar for the full RR design pattern.

Authentication

Both LDP and BGP support authentication; enable both in production.

LDP MD5:

mpls ldp neighbor 2.2.2.2 password Cisco123!

BGP MD5:

router bgp 65001
 neighbor 10.10.10.10 password Cisco123!

Both ends must agree on the password. Different passwords for different neighbors are fine.

Verification Sequence

Walk through these commands in order when bringing up a new MPLS deployment:

! IGP working?
show ip route ospf
show ip ospf neighbor

! MPLS interfaces enabled?
show mpls interfaces

! LDP sessions up?
show mpls ldp neighbor

! Labels being assigned?
show mpls ldp bindings

! Forwarding state populated?
show mpls forwarding-table

! For L3VPN: VRF routing table?
show ip route vrf CUSTOMER-A

! VPNv4 routes received?
show bgp vpnv4 unicast all summary

! End-to-end ping/traceroute test from CE
ping vrf CUSTOMER-A 10.0.0.5
traceroute vrf CUSTOMER-A 10.0.0.5

Each step depends on the previous. If show ip ospf neighbor is empty, MPLS will never come up. Walk back to fundamentals if anything is missing.

A Complete PE Configuration

! Hostname and basics
hostname PE1
ip cef
ipv6 cef

! Loopback for router-id
interface Loopback0
 ip address 1.1.1.1 255.255.255.255

! Core-facing interface (MPLS-enabled)
interface GigabitEthernet0/0/0
 description To P1
 ip address 10.0.12.1 255.255.255.252
 mpls ip
 mpls ldp sync

! Customer-facing interface (in VRF)
interface GigabitEthernet0/0/1
 description To CE-CustomerA
 vrf forwarding CUSTOMER-A
 ip address 192.168.1.1 255.255.255.0

! VRF
vrf definition CUSTOMER-A
 rd 65001:1
 address-family ipv4
  route-target export 65001:100
  route-target import 65001:100

! IGP (OSPF for the core)
router ospf 1
 router-id 1.1.1.1
 network 1.1.1.1 0.0.0.0 area 0
 network 10.0.12.0 0.0.0.3 area 0
 passive-interface default
 no passive-interface GigabitEthernet0/0/0

! MPLS
mpls ldp router-id Loopback0 force
mpls ldp sync

! BGP for L3VPN
router bgp 65001
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 no bgp default ipv4-unicast
 neighbor 10.10.10.10 remote-as 65001          ! Other PE
 neighbor 10.10.10.10 update-source Loopback0
 address-family vpnv4 unicast
  neighbor 10.10.10.10 activate
  neighbor 10.10.10.10 send-community extended
 exit-address-family
 address-family ipv4 vrf CUSTOMER-A
  redistribute connected
  neighbor 192.168.1.2 remote-as 65100         ! CE-Customer-A
  neighbor 192.168.1.2 activate
 exit-address-family

This is a complete PE for one customer. Add additional VRFs and BGP address-family blocks per customer.

A Customer Edge Configuration

! Customer's router; runs IP only, no MPLS
hostname CE1-CustomerA

interface GigabitEthernet0/0/0
 description To PE1
 ip address 192.168.1.2 255.255.255.0

interface GigabitEthernet0/0/1
 description Local LAN
 ip address 10.0.0.1 255.255.255.0

! BGP to PE
router bgp 65100
 bgp router-id 192.168.1.2
 neighbor 192.168.1.1 remote-as 65001
 network 10.0.0.0 mask 255.255.255.0

The CE is unaware of MPLS. It speaks BGP (or OSPF/EIGRP/static) with the PE; the PE handles all the L3VPN complexity.

Anti-Patterns

  • Forgetting send-community extended. RTs do not propagate; routes do not import where expected.
  • Skipping LDP-IGP sync. Transient drops on link bring-up.
  • Using physical interface IPs as the router-id. Unstable; can change unexpectedly. Always use a Loopback.
  • Forgetting force on LDP router-id. Router-id only changes after reload, surprising operators during interface changes.
  • Mixing classic ip vrf and modern vrf definition. Both work; standardize on vrf-definition for new deployments.
  • Full-mesh iBGP at scale. Use route reflectors past about 10 PEs.

Summary

Configuring MPLS on Cisco IOS XE is a sequence: IGP first, then MPLS forwarding (mpls ip) on each core-facing interface, then LDP for label distribution, then VRFs for L3VPN, then MP-BGP between PEs. Each piece builds on the previous. The complete PE config fits in one screen.

Master the verification sequence (show mpls interfaces then show mpls ldp neighbor then show mpls forwarding-table then BGP) and you can troubleshoot any deployment by walking back through the dependency chain. Bookmark this article alongside the MPLS cluster pillar and the L3VPN deep-dive.

Read next

© 2025 Ping Labz. All rights reserved.