EVPN VXLAN Anycast Multi-Homing

Following are the prerequisites for egress leaf nodes (such as Leaf1 and Leaf2 in EVPN Anycast MH) to operate in Anycast Multi-Homing (MH) mode:

• Each egress leaf node must be configured with the same loopback IP address (ethernet-segment.anycast-multi-homing.ip-address <ip-address>). This IP address is referred to as the Anycast VTEP. This Anycast VTEP must be advertised in the underlay routing protocol (IS-IS, OSPF, or BGP) to ensure reachability from ingress leaf and spine routers.

  Note: The Anycast VTEP's loopback state is independent of the Ethernet Segment (ES) state. If the loopback goes down, the A-D per ES route is still advertised.
• All egress leaf routers attached to the same ES in Anycast MH mode must use the same Anycast VTEP address.
  Note: If the user wants to bring down the loopback interface when an ES goes down, Event Handling System (EHS) can be used.
• All egress leaf routers connected to the same ES in Anycast MH mode must use the same ingress VNI for each MAC-VRF.
  Note: Asymmetric VNIs are not supported for egress leaf nodes in Anycast MH mode.
• The Anycast VTEP feature requires VXLAN termination on at least two distinct IP addresses: the system IP and a non-system IPv4 address. Egress leaf nodes must support VXLAN termination across multiple loopback interfaces.

When an egress leaf (such as Leaf1 and Leaf2 in EVPN Anycast MH) operates in Anycast MH mode for a specific ES, the following behaviors apply:

• Designated Forwarder (DF) Election and Local Bias behavior are unchanged. However, because A-D per-EVI routes are absent in this mode, the ac-df exclude capability must be configured, which then uses the preference algorithm.
• The advertisement of the Ethernet Segment Identifier (ESI) with EVPN routes remains unchanged.
• The processing and advertisement of BUM (Broadcast, Unknown Unicast, and Multicast) bindings and Inclusive Multicast Ethernet Tag (IMET) routes are not changed. The forwarding procedures for BUM traffic remain unchanged.
• Only the procedures related to the forwarding of unicast traffic to a remote ES are updated.

From a control-plane perspective, an egress leaf working in Anycast MH mode (such as Leaf1 and Leaf2 in EVPN Anycast MH) for a given ES works as follows:

• AD per-EVI routes for Anycast MH ESes are suppressed based on the Anycast MH mode configuration.
  • AD per-EVI routes are suppressed only for MAC-VRFs with VXLAN encapsulation.
  • This applies to nodes sharing ESs by mac-vrfs with vxlan and mpls encap.
• AD per-ES routes for Anycast MH ESes are advertised with the A=1 flag in ESI label extended community (as defined in draft-rabnag-bess-evpn-anycast-aliasing).
  • The anycast-multi-homing flag indicates to remote NVEs that EVPN MAC/IP Advertisement routes with matching Ethernet Segment Identifier are resolved only by A-D per ES routes for the ES. This flag signals to the ingress leaf that no A-D per EVI routes are advertised for the Ethernet Segment. The A flag is bit 2 in the Flags field of the ESI label extended community.

    

  • The BGP tunnel-encapsulation attribute ( per draft-rabnag-bess-evpn-anycast-aliasing) carries the Anycast VTEP; specifically, it is encoded in the BGP Tunnel Encapsulation Attribute Tunnel Egress Endpoint Sub-TLV (code point 6) [RFC9012]. The Tunnel Egress Endpoint Sub-TLV Value Field is shown below.

    

• MAC/IP routes for MACs learned on the ES working in Anycast MH mode are advertised with ESI. The next-hop is either the regular system0.0 IPv4 address or the one determined by network-instance[=mac-vrf].protocols.bgp-evpn.bgp-instance.routes.bridge-table.next-hop <ip-address>

From a data-plane perspective, an egress leaf working in Anycast MH mode (such as Leaf1 and Leaf 2 in EVPN Anycast MH) for a given ES works as follows:

• All VXLAN traffic is sourced from system0.0.
• The Anycast VTEP is never used as a source VTEP.

For EVPN routes advertised with an Anycast VTEP, successful resolution requires both the Network Layer Reachability Information (NLRI) Next Hop and the Anycast VTEP to be reachable. If either of these addresses becomes unreachable, the routes are not installed.

Anycast MH can be applied to non-zero Ethernet Segment Identifier (ESI) EVPN-IFL-HOST routes, as shown in the following figure.

--{ * candidate shared default }--[  ]--
# info with-context system network-instance
    system {
        network-instance {
            protocols {
                evpn {
                    ethernet-segments {
                        bgp-instance 2 {
                            ethernet-segment esi1 {
                                anycast-multi-homing {
                                    ip-address 12.12.12.12
                                }
                            }
                        }
                    }
                }
            }
        }
    }