MPLS LDP Label Filtering Example

Lessons Discussion
22

Rene,

MPLS is all new to me, so I’m using your website primarily to learn, but of course, supplementing with other websites. I came across the term FEC (Forwarding Equivalence Class) and after reading about it, it seemed like an important topic to learn in the beginning.

I searched networklessons.com for “Forwarding Equivalence Class” or FEC but didn’t get any results related to MPLS (“fec” had hits, but that’s because it picked up words that had the letters “fec” in them).

Is there a reason the MPLS course doesn’t cover this term?

Thanks,

Buck

23

Hello Buck

Although there are no lessons that include this feature, take a look at this post that further describes it along with further links to relevant Cisco documentation.

I hope this has been helpful!

Laz

24

Loved this explanation, thanks Laz!

1 Like
25

Greeting,

I enabled LDP label filtering on each of the core routers in my network, but how do I disable the filtering? I’ve removed the access-list and the two commands needed to get it going. I’ve already restarted each device, but I still do not see a label for each path show up when I enter “sh mpls forwarding-table”.

Thanks,
Chris

26

Hello Christopher

Remember that when you configure LDP label filtering, you first disable all LDP advertising using the no mpls ldp advertise-labels command, and then you specify which labels will be advertised using an access list and the mpls ldp advertise-labels command.

By the sound of your description, it seems that the no mpls ldp advertise-labels command is still active on your routers. In order to remove this, you must enter:

mpls ldp advertise-labels

This reenables the advertising of the labels. Make sure that this is indeed the case, but let us know if you have any other issues…

I hope this has been helpful!

Laz

27

It this required in real environment, do we use this. By looking into the topic i guess it should be used this might help us for visibility/tracing etc.

28

Hello Wali

Yes, this is something you will typically see in a real environment. Within an MPLS network, an ISP will have some parts of their network where they do not want to share labels, where it is simply not necessary.

I hope this has been helpful!

Laz

29

Hello,

what is the difference between the below 2 commands?

1. mpls ldp label
    allocate global {prefix-list <name> | host-routes}

2. mpls ldp advertise-labels for <ACL for prefix> to <ACL for LDP peer>

From my understanding, they both achieve same result. The first one looks better because it doesn’t even allocate local labels. The second one has the advantage to filter outbound labels to specific LDP peers (rarely used in production environment).

Are there any other advantages/disadvantages of using one or another?

30

Hello Ilias

The mpls ldp label command enables a feature called local label allocation filtering, which selectively allocates local labels for a subset of the prefixes learned from the IGP. The purpose of this command is to keep the size of the local label space low, as well as to limit the number of advertisements to peers. This in turn increases the scalability for especially large networks.

The mpls ldp advertise-labels command does not affect the number of bindings internally on the MPLS router, but simply affects what is advertised. This reduces the number of advertisements to peers, but does not affect the local allocation of labels.

As in the case that you posted, the result may be the same as far as what MPLS neighbors see, but there is a difference as far as how the local router records the remote label bindings.

For more information about local label allocation filtering, take a look at this CIsco documentation:

For more info about the mpls lda advertise-labels command, take a look at this informative Cisco learning network thread:

I hope this has been helpful!

Laz

31

Thanks a lot for explanation

32

I’m doing some config validation for my job and I noticed the globals look quite different from your examples. I’m not sure if it’s because these routers I’m working on are running XR. Just wondering if there’s anywhere on your site that covers this, thanks.

mpls ldp
 log
  neighbor
  nsr
  graceful-restart
  session-protection
 !
 nsr
 graceful-restart
 igp sync delay on-session-up 10
 router-id <router ID>
 session protection
 address-family ipv4
  label
   local
    allocate for host-routes
    advertise
     interface Bundle-Ether13
     interface Bundle-Ether14
     interface TenGigE0/1/1/1
33

Hello Jonathan

In your post, you shared the global default values from your IOS XR implementation. Can you clarify which global configuration parameters in Rene’s lesson you are comparing them with? Rene doesn’t have any of these values in the included configurations. In the configurations you see in the lesson, Rene only posts the commands that are modified. Any default values are not indicated anywhere in the lesson.

Now having said that, yes there are several differences in the default values of the global config for Cisco IOS routers and IOS XR routers. Some of the most important include:

  1. Transport Address:
    • IOS: The highest IP address on the router is used by default.
    • IOS XR: Uses the address of the interface through which the peer is reachable.
  2. LDP Discovery:
    • IOS: LDP is enabled on all interfaces by default when you enable MPLS.
    • IOS XR: You need to specify the interfaces under the LDP configuration.

There may be more differences, but you will have to take a look at Cisco documentation to confirm them. Is there any specific global default config command that you would like to examine further?

I hope this has been helpful!

Laz

34

No, nothing else. I think I figured it out. I just wasn’t sure if any of Rene’s lessons covered the XR configs.

1 Like
36

Hello, everyone.

I understand that there are two types of MPLS label spaces (the uniqueness of MPLS labels).

The per-interface one simply means that labels are unique per interface. Therefore we can do something like this:

Label 10 for prefix 1 out of interface G1/0/1
Label 10 for prefix 2 out of interface G1/0/2.

At this point, we can reuse the same label values as long as we use unique labels per interface. When a router receives a label, it forwards it based off the received interface and the label value.

The per-platform or per-LSR one simply means that one prefix/FEC = 1 label and this label cannot be reused. We have one label per LSR FEC.

So

Label 10 for prefix 1 out of interface G1/0/1
Label 11 for prefix 2 out of interface G1/0/2.

Label 10 will always represent prefix/FEC 1 on the local device and no other prefix/FEC

When a router receives a label, it forwards it based off the label value.

Am I misunderstanding something here?

Thank you!
David

37

Hello David

You have the general concept correct, but the examples should be described in terms of the incoming interface, not the outgoing interface.

An MPLS label is assigned by the downstream LSR to an FEC and advertised to its upstream neighbors. When the downstream router receives the labeled packet, it uses the incoming label, and, depending on the label-space type, possibly the incoming interface, to perform the LFIB lookup.

With a per-interface label space, the label only needs to be unique on a particular incoming interface. Therefore, the router could assign:

  • Label 10 for FEC 1 when received on GigabitEthernet1/0/1
  • Label 10 for FEC 2 when received on GigabitEthernet1/0/2

The same label value can be reused because the router performs the lookup using: Incoming interface + incoming label

With a per-platform label space, the label must be unique across the whole LSR. Therefore, the router might assign:

  • Label 10 for FEC 1
  • Label 11 for FEC 2

The router can then perform the lookup using only: Incoming label

So yes, within that platform label space, local label 10 identifies only one label binding/FEC within that label space.

However, this restriction applies to the router’s local/incoming labels. It does not mean that the same outgoing label value cannot appear multiple times in the LFIB. Outgoing labels are assigned by downstream neighbors, and two different neighbors may independently advertise the same label value for different FECs.

For example, a router could have:

  • FEC 1 → outgoing label 20 through neighbor A
  • FEC 2 → outgoing label 20 through neighbor B

This is not a conflict because the outgoing label is interpreted by the next-hop router, and each next-hop router has its own label space.

Cisco LDP normally uses a per-platform label space, which is indicated by the :0 in an LDP identifier such as:

22.22.22.22:0

Therefore, the key distinction is:

  • Per-interface: incoming interface plus label identifies the forwarding entry.
  • Per-platform: the label alone identifies the forwarding entry.

I hope this has been helpful!

Laz

38

Hello Laz,

Thank you for taking your time to explain this.

Right, these modes of label assignement/generation are only relevant to the local LSR as it can receive the same tag from 50 different neighbors since each LSR generates tags locally and independently.

My idea was that the same local LSR cannot generate the same tag for two separate prefixes, or FECS with per-platform. Therefore it only uses the label value to make forwarding lookups (since it cannot receive a packet with the same label value on two different interfaces). With per-interface, it would also have to use the receiving interface during forwarding lookups.

Is it right to say that per-platform is the standard these days? I haven’t seen per-interface label spaces neither on Cisco, Juniper or Huawei and I feel like it would be a bit more confusing. If each FEC is one label on the local LSR, it makes everything a bit more clear in terms of understanding and troubleshooting.

Thank you Laz!!

David

39

Hello David

Yes, it is indeed the case that in per-platform label space mode, a single LSR cannot generate the same label for two separate FECs. Since each label has one unambiguous forwarding meaning across the platform, the incoming interface is not required as part of the forwarding lookup. The label value alone indexes the LFIB and determines the outgoing action.

This is actually explicitly defined in RFC 3031 in Section 3.14, which talks about the scope and uniqueness of labels. It says

Rd MUST NOT distribute to Ru bindings of the same label value to two different FECs.

You can see this directly in show mpls forwarding-table output. The table is keyed purely by local label, with no incoming interface column, because one label always means exactly one thing everywhere on that router.

Your statement in parentheses is not quite right. The router can receive packets carrying the same label value on multiple interfaces. In a per-platform label space, that label is simply interpreted identically regardless of which interface received it. But I understand your intended meaning.

Yes, per platform is the standard these days, on Cisco, Juniper, and Huawei alike. The reason you haven’t observed per-interface mode in practice is that it exists specifically to support link-layer label mechanisms like ATM (VPI/VCI) and Frame Relay (DLCI), where the label identifier is constrained by the underlying media and must be unique per interface. Cisco documentation confirms this:

For Cisco platforms, all interface types except LC-ATM use the platform-wide label space.

On Ethernet, PPP, POS, and Serial links, which make up virtually all modern MPLS networks, there is no such constraint, so a single label per FEC is shared platform-wide. Since label-controlled ATM and Frame Relay MPLS cores have been almost entirely replaced by Ethernet-based networks, per-interface label space simply has no practical use case anymore. There’s no configuration knob to toggle it on modern routers because it isn’t needed!

Indeed, one label per FEC, shared across the entire router, is far simpler to understand and troubleshoot, and that’s exactly what you’re seeing in the show mpls ldp bindings output in the lessons. You’re observing the correct behavior, and now you understand why it’s the only approach used today. This is architecture, not vendor preference but a direct consequence of link-layer technology evolution. Great work reasoning through this!

I hope this has been helpful!

Laz

40

Hello Laz.

Thank you!

You pretty much confirmed my thoughts behind this, it’s just a bit hard for me to get used to local, remote labels and per-interface/per-space label assignements.

Therefore it only uses the label value to make forwarding lookups (since it cannot receive a packet with the same label value on two different interfaces).

What I mean’t to say is that it only uses the label to make forwarding lookups because they represent the same FEC, one label does not represent two different FECs as with per interface. :smiley:

Thank you for everything!

David

1 Like
41

Hello, everyone.

When filtering prefixes sent to neighbors, is local label allocation filtering the best practice?

Since mpls ldp advertise-labels only affects outbound updates but the local LSR still keeps the local label bindings. So at this point, is there any use to this command when we can simply filter the prefixes locally on the LSR altogether?

Conditional advertisement is also confusing since we have to disable MPLS LDP label generation altogether. This posses a problem to me when we go to advertise labels to only certain peers. For example, if we implement a filter on R2 towards R1, we are also at the same time not advertising any label bindings towards R3 or R4.

Thank you
David

42

Hello David

You’re absolutely correct. mpls ldp advertise-labels (and mpls ldp neighbor ... labels accept) only filters outbound/inbound advertisements between peers. The local LSR still allocates and maintains the local label binding in its LIB for every prefix, regardless of the filter. So the label exists locally. It’s just not sent to certain neighbors.

In most cases, the better practice is local label allocation filtering using mpls ldp label allocate .... This is the newer, recommended approach because it prevents the LSR from creating the local label binding at all, not just hiding it. So instead of:

Local label allocation filtering is obviously better, as you have suggested in your post because:

  • Memory efficiency — Fewer bindings in the LIB
  • Control-plane “hygiene” — You can preserve IP routing while controlling MPLS independently. With advertise-labels, the prefix stays in the routing table and remains reachable via normal IP forwarding, you’re simply choosing not to build an LSP for that FEC.
  • Per-peer granularity — Using advertise-labels for to , you can advertise a label to some LDP peers and withhold it from others. Plain route filtering can’t do that, it’s all-or-nothing at the routing-protocol level.
  • Cleaner propagation
  • Fewer downstream bindings

There are still times when you would use the advertise-labels filtering, such as if you need per-neighbor granularity: For example, “send labels for these prefixes to Neighbor A, but not Neighbor B”. In this case, outbound advertisement filtering is still the right tool.

But for the typical use case (allocate labels only for PE loopbacks, for example), local label allocation filtering is cleaner, more memory-efficient, and reduces downstream overhead. Cisco’s docs and CCIE-SP labs now recommend mpls ldp label allocate as the primary mechanism.

So you’re right, in most cases, filtering the prefixes locally would be the best way to go.

I hope this has been helpful!

Laz

1 Like