Cisco IOS-XR MPLS LDP Configuration Guide - 夜莺博客

Cisco IOS-XR MPLS LDP Configuration Guide

MPLS LDP is still the label distribution protocol running inside most carrier and enterprise MPLS cores, even where segment routing is being introduced at the edge. On Cisco IOS-XR the configuration is short, but the prerequisites are not obvious: LDP builds sessions over an existing IGP, it needs the addresses you distribute to be reachable, and it does nothing at all until MPLS is explicitly enabled on the interface. This guide covers the IOS-XR LDP build from prerequisites through label verification, and the failure modes that produce an empty LFIB.

Prerequisites Before Touching LDP

LDP uses UDP and TCP 646 to discover and maintain sessions with LSR IDs derived from the IGP router ID or a manually configured LSR ID. Before configuring LDP, confirm three things:

  1. An IGP (IS-IS or OSPF) is up and advertising the loopback that will become the LSR ID.
  2. The loopback address is reachable from every other LSR — this is the address carried in the LDP session.
  3. Interfaces that should forward labelled traffic are routed interfaces with an IP address, not switchports.

On an ASR 9000 or NCS platform, this also implies the line card has its MPLS feature set loaded; the presence of an MPLS configuration without a labelled forwarding entry in the LFIB is normally one of the first two conditions failing, not a licensing problem.

Step 1 - Enable MPLS and LDP Globally

RP/0/RSP0/CPU0:PE1# configure
RP/0/RSP0/CPU0:PE1(config)# mpls ldp
RP/0/RSP0/CPU0:PE1(config-ldp)# lsr-id 10.0.0.1
RP/0/RSP0/CPU0:PE1(config-ldp)# address-family ipv4
RP/0/RSP0/CPU0:PE1(config-ldp-af)# discovery transport-address 10.0.0.1
RP/0/RSP0/CPU0:PE1(config-ldp-af)# commit

The LSR ID must be unique in the domain and should be the same as the IGP router ID to keep troubleshooting simple. If a router ID is not configured manually, the highest loopback address is used, which is a common source of the "labels are there but nothing forwards" symptom after a loopback is added.

Step 2 - Enable LDP per Interface

LDP must be enabled on every interface that participates in label distribution, including core links toward each neighbour:

RP/0/RSP0/CPU0:PE1(config)# interface GigabitEthernet0/0/0/1
RP/0/RSP0/CPU0:PE1(config-if)# mpls ip
RP/0/RSP0/CPU0:PE1(config-if)# commit

Repeat for each core interface. Interfaces facing customers usually run IP-only unless the design requires label distribution there. Verify that MPLS is actually operational on the interface with:

RP/0/RSP0/CPU0:PE1# show mpls interfaces

Checking MPLS state per interface

The output must show LDP as enabled with the tunnelling state Yes or Up. An interface showing MPLS enabled but tunnelling No means no LDP adjacency has formed on it.

Step 3 - Tune Session Parameters

Default timers suit stable networks. Where you want faster failure detection, tune the session hold time and the discovery hello parameters:

RP/0/RSP0/CPU0:PE1(config-ldp)# session holdtime 60
RP/0/RSP0/CPU0:PE1(config-ldp-af)# discovery hello holdtime 15
RP/0/RSP0/CPU0:PE1(config-ldp-af)# discovery hello interval 5
RP/0/RSP0/CPU0:PE1(config-ldp-af)# commit

Longer hold times reduce the chance of a session flap during a control-plane blip; shorter ones converge faster. For truly sub-second detection, run BFD for LDP rather than pushing hello timers to their limits — hello-driven detection cannot reliably deliver sub-second reaction without flapping.

Step 4 - Label Allocation and Advertisement Control

By default IOS-XR advertises label bindings for all IGP-learned prefixes. In large domains you usually want to restrict this to loopbacks and infrastructure prefixes so that the LIB does not scale with every customer link:

RP/0/RSP0/CPU0:PE1(config-ldp-af)# label local allocate host-routes-local
RP/0/RSP0/CPU0:PE1(config-ldp-af)# exit
RP/0/RSP0/CPU0:PE1(config-ldp)# exit
RP/0/RSP0/CPU0:PE1(config)# mpls ldp label
RP/0/RSP0/CPU0:PE1(config-ldp-lbl)# allocate global prefix-list LDP-LOOPBACKS
RP/0/RSP0/CPU0:PE1(config-ldp-lbl)# commit

Filtering labels without creating black holes

Filtering labels inconsistently across the domain is a classic cause of black holes, because a neighbouring LSR may expect a binding for a prefix your router has chosen not to advertise. Change label allocation policies one router at a time and verify with the commands below after each change.

Verification: Session, LIB, LFIB

Work through the layers in order — session first, then bindings, then the forwarding table:

RP/0/RSP0/CPU0:PE1# show mpls ldp neighbor
RP/0/RSP0/CPU0:PE1# show mpls ldp neighbor 10.0.0.2 detail
RP/0/RSP0/CPU0:PE1# show mpls ldp discovery
RP/0/RSP0/CPU0:PE1# show mpls ldp bindings
RP/0/RSP0/CPU0:PE1# show mpls ldp bindings 10.0.0.2/32
RP/0/RSP0/CPU0:PE1# show mpls forwarding
RP/0/RSP0/CPU0:PE1# show mpls forwarding labels 16001
RP/0/RSP0/CPU0:PE1# show mpls ldp parameters

Read the outputs like this. show mpls ldp neighbor must show a session in Oper state with the correct LSR ID — a session stuck in OpenSent means TCP 646 is blocked or the transport address is unreachable. show mpls ldp bindings should contain a local binding and a remote binding for every prefix you intend to reach. Only when both exist for a prefix will show mpls forwarding contain a label-swap entry for it.

An empty LFIB with a healthy session almost always means one of: no IGP route for the prefix, label allocation filtered locally, or the incoming label was not advertised by the neighbour. Check all three rather than assuming a hardware fault.

Operational Notes

  • Set the LSR ID (and router ID) manually on every LSR — auto-derived IDs change when loopbacks are added.
  • Enable mpls ip on every core interface in both directions; a one-sided configuration produces a session that never comes up.
  • Prefer BFD over aggressive hello timers for fast failure detection.
  • Apply label allocation filters domain-wide and in the same order, then verify with show mpls forwarding at both ends of each link.
  • Keep the LDP transport address on a stable loopback, never on a physical interface that can be reconfigured.

Related reading: our Cisco MPLS VPN troubleshooting with VRF and BGP, the SR-MPLS versus SRv6 explained guide, and the IOS-XR show tech-support collection and analysis article.

原文链接:https://www.cisco.com/c/en/us/td/docs/iosxr/cisco8000/mpls/24xx/configuration/guide/b-mpls-cg-cisco8000-24xx.html