My recent post about Anycast in Segment Routing led to an interesting argument on whether other MPLS transport protocols can do anycast routing.

In that post, I wrote:

…MPLS is not a pure packet switching technology, but has a control plane based on virtual circuit switching. There is always a Label Switch Path (LSP) with one destination.

Looking again at my notes, I realized that I got that idea from preparing the article about TI-LFA last year. Indeed, “virtual circuit switching” applies to RSVP-TE, and how it differs from SR-TE. Of course, this doesn’t apply to BGP-LU, which by the way nicely fits into SR architecture by just adding the BGP Prefix SID optional transitive attribute, which makes MPLS labels global.

Now, what about LDP? A few years ago, when learning SR, I built a lab with LDP and anycast. The routers started complaining about duplicate addresses and I concluded that it was not going to work, but didn’t do any further research.

As it turns out, I was wrong! As Ivan Pepelnjak demonstrated in this article, LDP can work with anycast addressing.

LDP duplicate address

[RFC5036#section-3.5.5] defines the LDP address message. Section 2.7 of the same RFC explains the use case for these:

   Similarly, when the LSR learns a label for a prefix from an LDP peer,
   it must be able to determine whether that peer is currently a next
   hop for the prefix to determine whether it needs to start using the
   newly learned label when forwarding packets that match the prefix.
   To make that decision, the LSR must be able to map an LDP Identifier
   to the peer's addresses to check whether any are a next hop for the
   prefix.

   To enable LSRs to map between a peer LDP Identifier and the peer's
   addresses, LSRs advertise their addresses using LDP Address and
   Withdraw Address messages.

An LDP router advertises local interface addresses so that peers can map label bindings to next hops. Obviously, this applies to physical interfaces which are also used for IGP adjacency, or loopbacks used as IP unnumbered. If LDP detects duplicate IP addresses, it complains about them:

*Dec 14 15:22:20.293: %LCON-3-DUP_ADDR_RCVD: Duplicate Address 24.24.24.24 advertised by peer 4.4.4.4:0 is already bound to 2.2.2.2:0
*Dec 14 15:22:20.293: %LCON-3-LDPID: peer 4.4.4.4:0, LDP Id/Addr mapping problem (rcvd LDP address message, bind failed)


R1#sh mpls ldp neighbor | sec Peer LDP|Addresses      
    Peer LDP Ident: 2.2.2.2:0; Local LDP Ident 1.1.1.1:0
        Addresses bound to peer LDP Ident:
          2.2.2.2         24.24.24.24     10.0.0.2        10.2.2.2        
          10.6.6.2        
    Peer LDP Ident: 4.4.4.4:0; Local LDP Ident 1.1.1.1:0
        Addresses bound to peer LDP Ident:
          4.4.4.4         10.3.3.4        10.4.4.4        
        Duplicate Addresses advertised by peer:
          24.24.24.24 

Since anycast routing is obviously not the use-case LDP authors designed the protocol for, I began to think – what could go wrong?

As it seems, not much really. If we configure an anycast IP on multiple routers’ loopback interfaces, and don’t make any rookie mistakes like using it as router ID or IP unnumbered, in theory there should be no problem in using it for anycast routing (just configure logging discriminator so that your syslog doesn’t get flooded with duplicate address errors).

Just one LDP feature which sort of gets broken with anycast is Remote LFA.

RLFA and anycast

Consider the following topology:

Fig. 1

R2 and R4 share the anycast IP 24.24.24.24/32. All IGP metrics are 10 except the R3-R4 link where the metric is 20. R1 will prefer R2 to forward traffic towards the anycast IP. With per-prefix remote LFA enabled, R1 will calculate that R4 is the PQ node for prefixes advertised by R2, establish a targeted LDP session towards R4 and use it as a backup path.

R1#sh mpls ldp internal routes 2.2.2.2 32    
2.2.2.2/32 (context:0, local label:17)
    1: Et0/0=>10.0.0.2 (remote label:exp-null from 2.2.2.2:0, owners: fwdg)
    2: MP2=>4.4.4.4 (remote label:19 from 4.4.4.4:0, owners: fwdg)

The same holds true for the anycast IP. Since 24.24.24.24/32 is also configured on R4, R4 will advertise explicit null instead of a remote label.

R1#sh mpls ldp internal routes 24.24.24.24 32
24.24.24.24/32 (context:0, local label:18)
    1: Et0/0=>10.0.0.2 (remote label:exp-null from 2.2.2.2:0, owners: fwdg)
    2: MP2=>4.4.4.4 (remote label:exp-null from 4.4.4.4:0, owners: fwdg)

So RLFA works perfectly with anycast?

If I increase the metric on the R3-R4 link to 30 or higher, R1 can’t protect prefixes advertised by R2 from the R1-R2 link failure (there is no PQ router).

Fig. 2

In theory, there shouldn’t be any issue in rerouting traffic towards 24.24.24.24/32 via R4, but this doesn’t happen.

R1#sh mpls ldp internal routes 24.24.24.24 32
24.24.24.24/32 (context:0, local label:18)
    1: Et0/0=>10.0.0.2 (remote label:exp-null from 2.2.2.2:0, owners: fwdg)

Of course, I don’t expect RLFA to provide anycast-aware node protection like TI-LFA does, but it would be nice to provide some protection in the basic scenario like on figure 2.

Other LDP features

I didn’t verify everything, but I don’t expect anycast IP to trigger any problem with LDP-IGP sync, GR, label aggregation and different advertisement/retention modes. Maximally Redundant Trees (MRT) would be interesting to test, probably in some topologies it will run into the same issues as RLFA, unless the implementation is intentionally anycast-aware.

Can LDP replace SR in anycast designs?

Anycast SR designs like Large Scale Interconnect, or Area Segment in IS-IS Proxy rely on the fact the anycast segment is global, and can be used in SR-TE policies. LDP has no power here.¹ But it can work indeed with anycast addressing, as Ivan has proven in his article. Hats off.

Conclusion

While I don’t think LDP anycast designs are very practical, it is beneficial to understand how the protocol works. And I always appreciate when someone points at my mistakes, as this is the way we can learn.

References

1. Anycast in Segment Routing https://routingcraft.net/anycast-in-segment-routing
2. Anycast Works Just Fine with MPLS/LDP https://blog.ipspace.net/2021/11/anycast-mpls.html
3. Topology Dependent LFA https://routingcraft.net/topology-dependent-lfa/
4. LDP Specification https://datatracker.ietf.org/doc/html/rfc5036

Notes

1. ^Long time ago, there was an idea to introduce global labels to LDP, but it was never accepted. See https://datatracker.ietf.org/doc/html/draft-tian-mpls-lsp-source-route-01