Part of an anycast series. This is the high-level summary. For the hands-on NX-OS lab (configs, the RFC 5549 failure, the working EVPN solution) see Anycast Inside an EVPN/VXLAN Fabric with BGP Unnumbered (RFC 5549), and for the deeper protocol treatment see Anycast in EVPN/VXLAN Fabrics: The IPv6 Unnumbered and RFC 5549 Problem.

Why

Anycast services are advertised from multiple hosts into the data center. The same service prefix is originated from several places at once, which gives you multiple next hops for that service — and with it, load balancing, better failover, and scalability.

Solution

For all hosts to receive traffic, the fabric must build ECMP (Equal-Cost Multipath) toward the anycast prefix. Whether that is achievable depends on the fabric type and the protocols you run.

EVPN / VXLAN based

  • Advertise and receive multiple paths on the EVPN address family. Anycast needs not just the best path but the advertisement and reception of multiple paths for the same NLRI.
  • Configure maximum-paths — not only on the L2VPN EVPN address family, but also on the edge unicast address family of the switches where the hosts actually connect.
  • AS-path ignore / relax for best-path calculation, depending on how the hosts use AS numbers.
  • Disambiguate same-leaf Type-5 routes. External routes are carried as EVPN route-type 5. Routes originated from the same leaf look identical once encapsulated into RT-5. Setting the gateway IP to the next hop — the host advertising the prefix — makes them distinct again. But this is exactly why you cannot use RFC 5549 between the switch and the host: the gateway IP must be IPv4, so anycast services and RFC 5549 are mutually exclusive here.
  • Expect additional BGP tuning for eBGP- vs iBGP-based designs; the best-path selection algorithm has to be tuned for the solution.

Routed / IP fabric

These are mostly BGP-based setups. Depending on whether eBGP or iBGP is used, the problems change — and may not be solvable at all.

The core issue is receiving multiple paths from the same neighborship. Spine and leaf form an eBGP session. When a leaf — connected to more than one anycast-advertising host — forwards multiple paths for the same destination, the spine installs only a single path among them.

The leaf side works as expected. It sees all the local origins and advertises them:

Leaf BGP table — four local multipaths for the anycast prefix

Leaf advertising all of those paths to the spine

Leaf BGP configuration

The diversity is lost at the spine. It receives all the leaf’s paths but selects only one of them for multipath, because they all arrive with the same next hop (the leaf itself):

Spine receives all the paths but selects a single one for multipath

Spine BGP table and routing table

Spine BGP configuration

The result: every leaf ends up with at least a single route for the remote next hops of the anycast prefix, but loses the per-host weight, because the spine selects only one route for each leaf’s advertisement.

You can try iBGP, but then you hit eBGP-over-iBGP selection for the edge networks. You can try BGP PIC commands, but these tend toward very complex setups and often require vendor-specific configuration.

Takeaways

  • For anycast inside the fabric, carry the edge networks in a different address family than plain IPv4 unicast — VPNv4 or EVPN — so each origin stays a distinct, resolvable path.
  • A pure IPv4 fabric will not help with anycast services inside the fabric: the spine collapses each leaf’s multiple origins to one next hop and the per-host weight is gone.
  • The one exception is dedicated switches for the anycast service — north-south appliances such as firewalls or external load balancers that are equally connected to multiple switches (same switches, same number of links). That yields ECMP equal to the number of switches, and each switch then does its own ECMP toward the hosts.

The content of this post was created by the author; AI was used for editing and restructuring.