LDP label advertisement control (filtering)

LDP label advertisement control (filtering)

By default LDP allocates and advertises a label for every prefix the IGP knows. What is actually needed is only the /32 loopbacks that BGP uses as next hops. This article explains the three points where you can stop a label, and which router moves to recover a binding once a filter is relaxed, then verifies both on an IOS XR (XRd) lab. For the basics, see What is LDP.

What should be filtered

When MPLS carries a packet, the transport label the ingress PE pushes belongs to the LSP towards the BGP next hop, that is the remote PE’s loopback. The core link subnets are traversed but never become a next hop, so they do not need a label.

LDP still advertises all of them because the specification does not define what to advertise. Section 2.6.3 of RFC 5036 only defines Downstream Unsolicited and Downstream on Demand, that is when to advertise: there is no filtering mechanism in the protocol. What to advertise is local policy, decided per implementation.

There are three reasons to filter: a smaller label table, fewer LDP messages, and no unintended LSPs.

The three control points

A label flows in this order: allocate it in your own LIB, advertise it to the peer, and the peer accepts it. IOS XR can stop it at each of those three points.

Use label allocate to shrink your own label table, label advertise to hide labels from a particular peer, and label remote accept when you cannot rely on the other end being configured.

All three live under label inside address-family ipv4 of mpls ldp, split into local (what you allocate and advertise) and remote (what you accept). The filter takes an IP access list, not a route policy, and the peer is given as an LDP identifier that includes the label space number, such as 3.3.3.3:0.

mpls ldp
 address-family ipv4
  label
   local
    allocate for <access-list>           <- stop before allocation
    advertise
     to <LDP-Id> for <access-list>       <- choose what to send per peer
   remote
    accept
     from <LDP-Id> for <access-list>     <- discard on reception

allocate for also takes the keyword host-routes, which means “/32 only” without writing an access list.

When a filter is relaxed, the router that moves is not the one that filtered

Tightening a filter takes effect immediately at any of the three points. Filtering on the sending side sends Label Withdrawals; filtering on the receiving side discards what is already held, on the spot.

Relaxing it also takes effect, but a different router moves. LDP is Downstream Unsolicited: it advertises once when something changes and never re-sends periodically. Waiting therefore brings nothing back.

The receiver cannot restore a binding it has discarded. It therefore sends a Label Request message (section 3.5.8 of RFC 5036) carrying a Typed Wildcard FEC element (section 3 of RFC 5918), which means “please send every binding of this FEC type again”. Section 4 of RFC 5918 states that receiving such a Label Request is interpreted as a request to send Label Mappings for all FECs of that type.

Whether this request is available at all is decided when the session comes up. Unless both ends exchange the Typed Wildcard FEC Capability (0x050B, section 5 of RFC 5918) in the Initialization message, the request cannot be used, and against a peer that does not support it you have to re-establish the session with clear mpls ldp neighbor to get the bindings back.

Lab topology

A chain with no redundancy. The core (PE1 - P1 - P2 - PE2) runs OSPF and LDP, and CE1 and CE2 attach to the PEs in VRF CUST-A and reach each other over VPNv4.

  CE1 ------ PE1 ------ P1 ------ P2 ------ PE2 ------ CE2
(AS 65101)    |                              |   (AS 65102)
           vrf CUST-A                  vrf CUST-A
              +------ iBGP vpnv4 (Lo0) ------+

The global OSPF knows seven prefixes: four /32 loopbacks and three /24 core links. The PE - CE links live in the VRF, never enter the global OSPF, and so never get a label.

Overview of the verification

Every STEP clears the counters first, then runs ping 192.168.2.1 source 192.168.1.1 count 50 timeout 1 and traceroute from CE1, and collects the show output afterwards.

STEP 0: by default every prefix gets a label

The local bindings on P1. Four /32 loopbacks and three /24 links, all seven with a label.

RP/0/RP0/CPU0:P1#show mpls ldp bindings local
Sun Oct 11 15:59:38.563 UTC

2.2.2.2/32, rev 11
	Local binding: label: 24000
3.3.3.3/32, rev 7
	Local binding: label: ImpNull
4.4.4.4/32, rev 12
	Local binding: label: 24001
5.5.5.5/32, rev 14
	Local binding: label: 24003
10.2.3.0/24, rev 8
	Local binding: label: ImpNull
10.3.4.0/24, rev 9
	Local binding: label: ImpNull
10.4.5.0/24, rev 13
	Local binding: label: 24002

The forwarding table puts a number on the unused /24 label. The counters were cleared before the ping, so these are this STEP’s own values: the label for 10.4.5.0/24 has switched 0 bytes.

RP/0/RP0/CPU0:P1#show mpls forwarding
Sun Oct 11 15:59:39.027 UTC
Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
24000  Pop         2.2.2.2/32         Gi0/0/0/0    10.2.3.2        29883
24001  Pop         4.4.4.4/32         Gi0/0/0/1    10.3.4.4        5750
24002  Pop         10.4.5.0/24        Gi0/0/0/1    10.3.4.4        0
24003  24003       5.5.5.5/32         Gi0/0/0/1    10.3.4.4        29817

STEP 1: stop before allocation (label allocate)

The four core routers get an access list that permits only the /32 loopbacks, plus allocate for.

ipv4 access-list LDP-LOOPBACKS
 10 permit ipv4 host 2.2.2.2 any
 20 permit ipv4 host 3.3.3.3 any
 30 permit ipv4 host 4.4.4.4 any
 40 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   local
    allocate for LDP-LOOPBACKS
   !
  !
 !
!

The LIB drops from seven prefixes to four. Only the label is gone; the route is not.

RP/0/RP0/CPU0:P1#show mpls ldp bindings summary
Sun Oct 11 16:06:11.105 UTC

LIB Summary:
  Total Prefix   : 4
  Revision No    : Current:17, Advertised:17
  Local Bindings : 4
      NULL    : 1 (implicit:1, explicit:0)
      Non-NULL: 3 (lowest:24000, highest:24003)
  Remote Bindings: 8

10.4.5.0/24 is still in the OSPF routing table. Packets towards a prefix without a label are simply forwarded as plain IP, with no label pushed.

RP/0/RP0/CPU0:P1#show route ospf
Sun Oct 11 16:05:56.993 UTC

O    2.2.2.2/32 [110/2] via 10.2.3.2, 00:17:45, GigabitEthernet0/0/0/0
O    4.4.4.4/32 [110/2] via 10.3.4.4, 00:17:42, GigabitEthernet0/0/0/1
O    5.5.5.5/32 [110/3] via 10.3.4.4, 00:17:31, GigabitEthernet0/0/0/1
O    10.4.5.0/24 [110/2] via 10.3.4.4, 00:17:42, GigabitEthernet0/0/0/1

Filtering does not change the forwarding

This is the core of the article. The traceroute from CE1 to CE2 goes through exactly the same label stack as in STEP 0.

RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 6
Sun Oct 11 15:57:23.406 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 9 msec  5 msec
 2  10.2.3.3 [MPLS: Labels 24003/24005 Exp 0] 23 msec  46 msec
 3  10.3.4.4 [MPLS: Labels 24003/24005 Exp 0] 21 msec  17 msec
 4  10.4.5.5 [MPLS: Label 24005 Exp 0] 20 msec  38 msec
 5  10.5.6.6 25 msec  *

RP/0/RP0/CPU0:CE1#traceroute 192.168.2.1 source 192.168.1.1 timeout 1 probe 2 maxttl 6
Sun Oct 11 16:03:53.034 UTC

Type escape sequence to abort.
Tracing the route to 192.168.2.1

 1  10.1.2.2 8 msec  6 msec
 2  10.2.3.3 [MPLS: Labels 24003/24005 Exp 0] 20 msec  16 msec
 3  10.3.4.4 [MPLS: Labels 24003/24005 Exp 0] 16 msec  16 msec
 4  10.4.5.5 [MPLS: Label 24005 Exp 0] 15 msec  27 msec
 5  10.5.6.6 19 msec  *

The two-level stack of transport label 24003 (towards 5.5.5.5/32) and VPN label 24005 is unchanged, and P2 still performs PHP on the transport label.

Cutting the labels by 40% does not drop a single packet.

STEP 2: stop at advertisement (label advertise)

P1 narrows what it sends to PE1 only down to 5.5.5.5/32. Nothing changes towards P2.

ipv4 access-list LDP-PE2-ONLY
 10 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   local
    advertise
     to 2.2.2.2:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

Although both peer with the same P1, PE1 receives one label while P2 still receives four. The Labels column shows it.

RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief
Sun Oct 11 16:10:54.641 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:22:36    1     0     3     0     1      0

RP/0/RP0/CPU0:P2#show mpls ldp neighbor brief
Sun Oct 11 16:12:56.915 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:24:40    1     0     3     0     4      0
5.5.5.5:0          N   N    00:24:28    1     0     2     0     4      0

The moment the configuration is committed, P1 sends three Label Withdrawals to PE1. It is the only label message P1 sends in this STEP’s capture.

$ tshark -r - -Y 'frame.number==8' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step2-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0402,0x0402,0x0402	3.3.3.3,2.2.2.2,4.4.4.4	3,24000,24001

PE1 no longer holds them because P1 stopped sending them.

STEP 5: stop at reception (label remote accept)

This time PE1 narrows what it accepts. P1 has no advertisement filter: the one from STEP 2 was removed in STEP 3.

ipv4 access-list LDP-PE2-ONLY
 10 permit ipv4 host 5.5.5.5 any
!
mpls ldp
 address-family ipv4
  label
   remote
    accept
     from 3.3.3.3:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

Seen from PE1, the result is indistinguishable from STEP 2. The three prefixes that the access list does not permit show No remote bindings.

RP/0/RP0/CPU0:PE1#show mpls ldp bindings
Sun Oct 11 16:30:12.897 UTC

2.2.2.2/32, rev 2
	Local binding: label: ImpNull
	No remote bindings
3.3.3.3/32, rev 7
	Local binding: label: 24000
	No remote bindings
4.4.4.4/32, rev 11
	Local binding: label: 24002
	No remote bindings
5.5.5.5/32, rev 14
	Local binding: label: 24004
	Remote bindings: (1 peers)
	    Peer                Label
	    -----------------   ---------
	    3.3.3.3:0           24003

The difference is on the wire. Right after the filter is committed, PE1 discards what it held and asks for everything to be sent again (the request itself is examined in a later section); P1 answers with all four Label Mappings, and PE1 discards three of them after receiving them.

$ tshark -r - -Y 'frame.number==50' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step5-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4,5.5.5.5	3,24000,24001,24003

The numbers in show are the same, but no bandwidth and no message processing has been saved. If you can change the other end’s configuration, stopping at advertise is the better choice.

Which side moves when a filter is relaxed

As described above, the router that moves depends on the control point. In both cases the prerequisite is that the Typed Wildcard FEC Capability was exchanged when the session came up. The Initialization message carries the 0x050B TLV, and the same message fixes the advertisement discipline as Downstream Unsolicited.

        Common Session Parameters
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: Common Session Parameters (0x500)
            TLV Length: 14
            Parameters
                Session Protocol Version: 1
                Session KeepAlive Time: 180
                0... .... = Session Label Advertisement Discipline: Downstream Unsolicited proposed
                .0.. .... = Session Loop Detection: Loop Detection Disabled
                Session Path Vector Limit: 0
                Session Max PDU Length: 0
                Session Receiver LSR Identifier: 3.3.3.3
                Session Receiver Label Space Identifier: 0
        P2MP Capability Parameter
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: P2MP Capability Parameter (0x508)
            TLV Length: 1
            TLV Value: 80
        MP2MP Capability Parameter
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: MP2MP Capability Parameter (0x509)
            TLV Length: 1
            TLV Value: 80
        Typed Wildcard FEC Capability
            10.. .... = TLV Unknown bits: Unknown TLV, do not Forward (0x2)
            TLV Type: Typed Wildcard FEC Capability (0x50B)

Relax the sending side and the sender re-advertises by itself

The advertise filter added in STEP 2 is removed. The session is not re-established.

mpls ldp
 address-family ipv4
  label
   local
    advertise
     no to 2.2.2.2:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

Right afterwards P1 sends a Label Mapping again for each of the three prefixes it had withdrawn, on its own initiative. PE1 asked for nothing.

$ tshark -r - -Y 'frame.number==8' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step3-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4	3,24000,24001

Relax the receiving side and the receiver asks the peer

The remote accept filter re-applied in STEP 8 is removed, again without re-establishing the session.

mpls ldp
 address-family ipv4
  label
   remote
    accept
     no from 3.3.3.3:0 for LDP-PE2-ONLY
    !
   !
  !
 !
!

PE1 sends a Label Request. tshark cannot dissect this FEC element and prints Error in FEC Element 1, but the message type is Label Request Message (0x401).

    Label Request Message
        0... .... = U bit: Unknown bit not set
        Message Type: Label Request Message (0x401)
        Message Length: 13
        Message ID: 0x00000075
        FEC
            00.. .... = TLV Unknown bits: Known TLV, do not Forward (0x0)
            TLV Type: FEC (0x100)
            TLV Length: 5
            FEC Elements
                Error in FEC Element 1
                    [Expert Info (Error/Protocol): Error in FEC Element 1]
                        [Error in FEC Element 1]
                        [Severity level: Error]
                        [Group: Protocol]

The bytes of the FEC TLV match the format in sections 3 and 6 of RFC 5918: 05 is Typed Wildcard, 02 is Prefix FEC and 02 is the length of the information that follows (one byte each), and 00 01 is the IPv4 address family.

0000  52 54 00 23 17 21 52 54 00 94 4c 69 08 00 45 c0   RT.#.!RT..Li..E.
0010  00 4b bd 7e 00 00 ff 06 f3 64 02 02 02 02 03 03   .K.~.....d......
0020  03 03 02 86 f0 b1 66 ac 48 84 a5 de 10 2b 50 18   ......f.H....+P.
0030  3e ae 81 cf 00 00 00 01 00 1f 02 02 02 02 00 00   >...............
0040  04 01 00 0d 00 00 00 75 01 00 00 05 05 02 02 00   .......u........
0050  01 02 01 00 04 00 00 00 76                        ........v

P1 answers by sending all four Label Mappings again.

$ tshark -r - -Y 'frame.number==49' -T fields -E header=y \
    -e ip.src -e ldp.msg.type -e ldp.msg.tlv.fec.pfval -e ldp.msg.tlv.generic.label \
    < mpls-ldp-filtering-step9-pe1p1.pcap
ip.src	ldp.msg.type	ldp.msg.tlv.fec.pfval	ldp.msg.tlv.generic.label
3.3.3.3	0x0400,0x0400,0x0400,0x0400	3.3.3.3,2.2.2.2,4.4.4.4,5.5.5.5	3,24000,24001,24003

The clear was not needed

STEP 4 and STEP 10 do issue clear mpls ldp neighbor, but in both the labels were already back before the command ran. The STEP 10 record shows Labels ipv4 at four immediately before the clear, with an Up Time of over 41 minutes: the session had never gone down.

RP/0/RP0/CPU0:PE1#show clock

Sun Oct 11 17:01:38.670 UTC
17:01:38.713 UTC Sun Oct 11 2026
RP/0/RP0/CPU0:PE1#show mpls ldp neighbor brief

Sun Oct 11 17:01:38.811 UTC

Peer               GR  NSR  Up Time     Discovery   Addresses     Labels
                                        ipv4  ipv6  ipv4  ipv6  ipv4   ipv6
-----------------  --  ---  ----------  ----------  ----------  ------------
3.3.3.3:0          N   N    00:41:22    1     0     3     0     4      0

RP/0/RP0/CPU0:PE1#clear mpls ldp neighbor 3.3.3.3

Sun Oct 11 17:01:38.950 UTC
RP/0/RP0/CPU0:PE1#show clock

Sun Oct 11 17:01:39.064 UTC
17:01:39.162 UTC Sun Oct 11 2026

STEP 11: remove everything and return to the start

With every access list and filter removed, the LIB is back to seven prefixes.

RP/0/RP0/CPU0:P1#show mpls ldp bindings summary
Sun Oct 11 17:14:00.432 UTC

LIB Summary:
  Total Prefix   : 7
  Revision No    : Current:32, Advertised:32
  Local Bindings : 7
      NULL    : 3 (implicit:3, explicit:0)
      Non-NULL: 4 (lowest:24000, highest:24003)
  Remote Bindings: 14

The running-config of the final STEP is identical to STEP 0 on all six routers, compared down to the number of occurrences of each line in the collected data.

Design notes

• Filter by the BGP next hops. Besides the PE loopbacks, include any address other PEs refer to, for a route reflector or an inter-AS link. Miss one and only the LSP towards that PE fails to come up, leaving the VPN broken in one direction
• allocate really does shrink the LIB. Total Prefix in show mpls ldp bindings summary goes down as well. Only the label is gone; the route is not. Packets towards a filtered prefix are forwarded as plain IP with no label pushed
• Filtering on the receiving side leaves the LDP messages on the wire. To save bandwidth and message processing, stop at advertise on the sending side
• Check the peer’s implementation before relaxing a filter. Against a device that does not support the Typed Wildcard FEC (RFC 5918), the receiving side cannot request what it discarded, and you have to re-establish the session with clear mpls ldp neighbor

Verification configs and show output

For every STEP, the following kinds of output were collected from all six routers, one file per router. The verification config is the ..._run.txt (the final state is the one from the last STEP).

STEP 0: Initial state

STEP 1: label allocate filters to /32 only (four core routers)

STEP 2: label advertise filters what P1 sends to PE1

STEP 3: Remove the filter on the sending side (no clear)

STEP 4: Re-establish the session with clear mpls ldp neighbor

STEP 5: label remote accept filters what PE1 accepts

STEP 6: Remove everything

STEP 7: Re-apply label allocate (four core routers)

STEP 8: Re-apply label remote accept (PE1)

STEP 9: Remove the filter on the receiving side (no clear)

STEP 10: Re-establish the session with clear mpls ldp neighbor

STEP 11: Remove everything (final state)

Packet captures were taken per STEP on two links.

References

The verification was carried out on XRd 26.1.1 (Cisco Modeling Labs).

• What Is MPLS
• MPLS Labels and the Label Stack
• MPLS Label Operations (push / swap / pop) and PHP
• MPLS TTL Processing and MTU
• What Is LDP
• LDP Label Distribution Modes and Label Spaces
• LDP-IGP Synchronization and LDP Session Protection
• LDP label advertisement control (filtering)
• LDP session authentication (TCP MD5)
• MPLS OAM (LSP ping and LSP traceroute)
• What Is MPLS TE (RSVP-TE)
• MPLS TE CSPF and Path Constraints (Bandwidth, Affinity, TE Metric)
• Steering Traffic into MPLS TE Tunnels
• MPLS TE Fast Reroute (Link and Node Protection)
• MPLS TE Fast Reroute (Auto-Tunnel Backup and SRLG)
• MPLS QoS (EXP and Uniform / Pipe / Short-Pipe)
• MPLS QoS Rate Control and Queuing (policer / shaper / priority)