EVPN-VXLAN Anycast VTEP Multihoming
EVPN-VXLAN anycast VTEP multihoming presents two peers as one egress destination, using ECMP load balancing and rapid link and node failure recovery in fabrics.
In an EVPN-VXLAN multihoming deployment that uses an Ethernet segment identifier (ESI) and link aggregation (ESI-LAG), you can use anycast multihoming to make two multihoming peers appear as a single logical egress node. Each peer advertises EVPN Type 1 Ethernet Auto-Discovery (A-D), Type 2 (MAC/IP), and Type 3 (inclusive multicast) routes with a shared anycast VXLAN tunnel endpoint (VTEP) IP address as the BGP next hop. Remote provider edge (PE) devices load-balance traffic toward the anycast next hop by using underlay equal-cost multipath (ECMP). The multihoming peers maintain fast access-link convergence by using egress link protection (ELP) with a per-peer reroute address for tunnel endpoint selection. If a node fails, convergence follows underlay reachability to the anycast address.
In symmetric integrated routing and bridging (IRB), Type 2 MAC/IP routes use the anycast next hop and an anycast router MAC address. Each peer uses local route-installation rules to prevent programming routes that would resolve to itself through the anycast identity. Ethernet A-D per Ethernet segment (ES) signaling can trigger global repair so that ingress nodes steer directly to the surviving peer after an access-link failure. For broadcast, unknown unicast, and multicast (BUM) traffic, Type 3 inclusive multicast routes use the anycast next hop so ingress nodes send a single replicated copy that can land on either peer. Steady-state and failure-time forwarding is controlled by local-bias filtering and ELP tunnel endpoint selection.
Benefits
-
Makes remote PEs treat the multihoming peers as a single egress destination, which simplifies remote forwarding decisions.
-
Uses underlay ECMP toward a shared anycast VTEP to distribute traffic across available fabric paths.
-
Improves access-link failure handling by using local repair (ELP redirection to the surviving peer), reducing dependence on fabric-wide reconvergence for access-link failures.
-
Improves node-failure recovery by relying on standard underlay reachability updates to the anycast address.
-
Reduces unnecessary ELP tunnel state on remote nodes by suppressing Ethernet A-D per-ES advertisements where protection tunnels are not required.
How Anycast Multihoming Works
When EVPN anycast multihoming is enabled on an ESI-LAG pair, both peers advertise EVPN Type 1, Type 2, and Type 3 routes with the same anycast VTEP IP address as the BGP next hop. Remote PEs resolve a single overlay destination and then use underlay ECMP to load-balance traffic toward that anycast address. This changes the remote forwarding model from selecting between two distinct egress VTEPs to selecting among underlay paths to one logical egress identity, while preserving multihoming protection at the egress pair.
The forwarding model uses two addresses:
-
A shared anycast VTEP address configured on both peers.
-
A unique reroute address per peer used for ELP tunnel endpoint selection.
Type 1 and Type 2 routes use the anycast VTEP as the BGP next hop. The reroute address is carried in the tunnel encapsulation attribute so that peers can build the protection path used for local repair. In symmetric IRB, the anycast router MAC is advertised so that remote PEs use a consistent Layer 3 gateway identity while still reaching either peer through the anycast next hop. To avoid programming routes that resolve back to the local anycast identity, each peer applies a local installation rule to prevent installation of selected host routes learned from its peer.
After an access-link failure on one peer, forwarding continues through local repair. Traffic that arrives at the non-optimal peer because of anycast ECMP is redirected over the ELP protection path to the peer with the customer-edge (CE) facing link still up. You can also use global repair so ingress nodes stop relying on redirection. When the affected peer withdraws Ethernet A-D per-ES signaling, remote PEs update forwarding and steer directly to the remaining peer. When the link returns and signaling is re-advertised, ingress nodes return to the anycast forwarding model.
For BUM traffic, Type 3 inclusive multicast routes use the anycast next hop so ingress nodes send a single replicated copy that lands on either peer. BUM convergence depends on control-plane withdrawals and updates and can vary based on Ethernet segment signaling granularity and control-plane propagation.
Configuration and Verification
This section describes how to configure and verify EVPN anycast multihoming. Configure a shared anycast VTEP identity and router MAC on multihomed nodes, enable anycast behavior on the required ESI-LAGs, and verify the resulting EVPN routes and state.
anycast-multihoming
configuration causes a catastrophic event for the routing instance. Please perform these
configuration changes during a maintenance window to avoid network disruptions.- Configure Anycast Multihoming
- Configure Multihomed Access Interfaces
- Configure Egress Link Protection
- EVPN Anycast Multihoming MLAG Interoperability
- Verify anycast multihoming
Configure Anycast Multihoming
Configure the shared anycast identity on every node in the multihoming pair. Configure an anycast VTEP address, and, for symmetric IRB, configure a shared anycast router MAC.
set protocols evpn anycast-multihoming inet address anycast-ip set protocols evpn anycast-multihoming inet6 address anycast-ipv6 set protocols evpn anycast-multihoming router-mac mac-address
If the anycast address is configured on a non-default loopback unit, specify that unit as the anycast multihoming loopback interface. Configure every applicable EVPN routing instance to use the same loopback unit as its VTEP source interface.
set protocols evpn anycast-multihoming loopback-interface lo0.unit set routing-instances ri-name vtep-source-interface lo0.unit
Port-based designated forwarder (DF) election needs to be configured to achieve BUM traffic convergence improvements.
set interfaces aeX esi df-election-granularity per-esi
Configure Multihomed Access Interfaces
On each multihomed aggregated Ethernet interface, enable all-active multihoming and anycast behavior for the ESI-LAG.
set interfaces aeX esi all-active set interfaces aeX esi anycast
Optionally, configure per-ESI DF-election granularity when you require BUM convergence behavior that uses per-ESI control-plane processing.
set interfaces aeX esi df-election-granularity per-esi
Configure Egress Link Protection
If you use ELP, configure a unique reroute address on each node. The reroute address provides tunnel endpoint selection for ELP. Keep the EVPN loopback selection and VTEP source-interface configuration consistent.
set forwarding-options evpn-vxlan reroute-address unique-reroute-ip
If the anycast and reroute addresses use a non-default loopback unit, explicitly configure that unit under the anycast multihoming hierarchy and use it as the VTEP source interface.
set protocols evpn anycast-multihoming loopback-interface lo0.unit set routing-instances ri-name vtep-source-interface lo0.unit
EVPN Anycast Multihoming MLAG Interoperability
Configure the following statement to enable EVPN anycast multihoming interoperability with remote devices operating in MLAG mode:
set protocols evpn anycast-multihoming mlag-interop-mode
The mlag-interop-mode option is required when inter-operating with a
remote Arista MC-LAG/MLAG device. In this deployment, the local multihoming peers are
Juniper devices operating in ESI-LAG mode. Enabling this option allows seamless
interoperability between Juniper EVPN anycast multihoming and Arista MLAG implementations
without requiring additional interoperability-specific configuration on the remote
devices.
This configuration also provides compatibility when local Juniper multihoming peers use anycast multihoming and need to communicate with remote Juniper nodes operating in ESI-LAG mode while leveraging the software enhancements provided by this feature.
An additional policy configuration must be configured to import the routes from MH peer in interop mode. Without this configuration, the routes from the MH peer are not imported because the received routes have a protocol next hop (PNH) identical to the local anycast IP address.
For example:
set policy-options policy-statement mh_peer_import term 1 from family evpn set policy-options policy-statement mh_peer_import term 1 from next-hop anycast address set policy-options policy-statement mh_peer_import term 1 then community add NO_ADVERTISE set policy-options policy-statement mh_peer_import term 1 then next-hop reroute address set protocols bgp group OVERLAY import mh_peer_import
Verify anycast multihoming
Use the following commands to verify that the EVPN control plane reflects the anycast model.
show route table bgp.evpn.0 show evpn database extensive
In the bgp.evpn.0 routing table, verify the following:
- EVPN Type 1, Type 2, and Type 3 routes use the anycast VTEP address as the PNH.
- EVPN Type 1 and Type 2 routes include the node-specific reroute address in the tunnel-encapsulation attribute when ELP is configured.
- In symmetric IRB deployments, EVPN Type 2 routes include a router-MAC community that matches the configured anycast router MAC.
When ELP is enabled, also verify that the reroute address appears in the EVPN attributes.
Example output for an EVPN Type 1 route with a non-zero ESI.
user@host> show route table bgp.evpn.0 extensive match-prefix 1:1.1.1.11:0::11::FFFF:FFFF/192 bgp.evpn.0: 62 destinations, 103 routes (62 active, 0 holddown, 0 hidden) 1:1.1.1.11:0::11::FFFF:FFFF/192 AD/ESI (1 entry, 1 announced) TSI: Page 0 idx 0, (group overlay type External) Type 1 val 0xa3e8240 (adv_entry) Advertised metrics: Flags: Nexthop Change Nexthop: 10.1.1.1 AS path: [1100] I Communities: target:1:4 target:1:5 encapsulation:vxlan(0x8) esi-label:0x20:all-active:anycast-mh (label 0) >>>> Anycast MH mode Advertise: 00000003 Path 1:1.1.1.11:0::11::FFFF:FFFF Vector len 4. Val: 0 *EVPN Preference: 170 Next hop type: Indirect, Next hop index: 0 Address: 0x7e86794 Next-hop reference count: 45 Kernel Table Id: 0 Protocol next hop: 10.1.1.1 >>>> Anycast IP Indirect next hop: 0x0 - INH Session ID: 0 Indirect next hop: INH non-key opaque: 0x0 INH key opaque: 0x0 State: <Secondary Active Int Ext> Age: 5:13 Validation State: unverified Task: __default_evpn__-evpn Announcement bits (1): 1-BGP_RT_Background AS path: I Communities: target:1:4 target:1:5 encapsulation:vxlan(0x8) esi-label:0x20:all-active: (label 0) >>>> Anycast MH mode Reroute address: 10.2.1.11 >>>> Reroute address carried in BGP tunnel attribute Primary Routing Table: __default_evpn__.evpn.0 Thread: junos-main
Example output for a symmetric IRB EVPN Type 2 route.
user@host> show route table bgp.evpn.0 extensive match-prefix 2:1:410::1040::ec:94:d5:70:23:00::100.0.40.11/304 bgp.evpn.0: 62 destinations, 103 routes (62 active, 0 holddown, 0 hidden) 2:1:410::1040::ec:94:d5:70:23:00::100.0.40.11/304 MAC/IP (1 entry, 1 announced) TSI: Page 0 idx 0, (group overlay type External) Type 1 val 0xa3e7f20 (adv_entry) Advertised metrics: Flags: Nexthop Change Nexthop: 10.1.1.1 AS path: [1100] I Communities: target:1:4 target:100:100 encapsulation:vxlan(0x8) mac-mobility:0x1:sticky (sequence 0) router-mac:00:00:5E:00:53:00 >>>> Router mac Advertise: 00000003 Path 2:1:410::1040::ec:94:d5:70:23:00::100.0.40.11 Vector len 4. Val: 0 *EVPN Preference: 170 Next hop type: Indirect, Next hop index: 0 Address: 0x7e86794 Next-hop reference count: 45 Kernel Table Id: 0 Protocol next hop: 10.1.1.1 >>>> Anycast IP Indirect next hop: 0x0 - INH Session ID: 0 Indirect next hop: INH non-key opaque: 0x0 INH key opaque: 0x0 State: <Secondary Active Int Ext> Age: 9:36 Validation State: unverified Task: blue-evpn Announcement bits (1): 1-BGP_RT_Background AS path: I Communities: target:1:4 target:100:100 encapsulation:vxlan(0x8) mac-mobility:0x1:sticky (sequence 0) router-mac:00:00:5E:00:53:00 >>>> Router mac Route Label: 1040 Route Label: 9200 ESI: 00:00:00:00:00:00:00:00:00:00 Reroute address: 10.2.1.11 >>>> Reroute address Primary Routing Table: blue.evpn.0 Thread: junos-main
Example output for an EVPN Type 3 route.
user@host> show route table bgp.evpn.0 extensive match-prefix 10:1.1.1.11:11::501::10.1.1.1/248 bgp.evpn.0: 152 destinations, 152 routes (152 active, 0 holddown, 0 hidden) 10:1.1.1.11:11::501::10.1.1.1/248 IM (1 entry, 1 announced) TSI: Page 0 idx 0, (group OVERLAY type External) Type 1 val 0x1c1ff460 (adv_entry) Advertised metrics: Nexthop: 10.1.1.1 AS path: [65407] 65401 I Communities: target:1:1 encapsulation:vxlan(0x8) evpn-mcast-flags:0x1:igmp-snooping-enabled PMSI: Flags 0x0: Label 501: Type INGRESS-REPLICATION 10.1.1.1 Advertise: 00000006 Path 10:1.1.1.11:11::501::10.1.1.1 from 1.1.1.11 Vector len 4. Val: 0 *BGP Preference: 170/-101 Route Distinguisher: 1.1.1.11:11 PMSI: Flags 0x0: Label 501: Type INGRESS-REPLICATION 10.1.1.1 >>>> anycast PNH Next hop type: Indirect, Next hop index: 0 Address: 0x7e61c94 Next-hop reference count: 48 Kernel Table Id: 0 Source: 1.1.1.11 Protocol next hop: 10.1.1.1 Indirect next hop: 0x2 no-forward INH Session ID: 0 Indirect next hop: INH non-key opaque: 0x0 INH key opaque: 0x0 State: <Active Ext> Local AS: 65011 Peer AS: 65536 Age: 3d 18:02:18 Metric2: 0 Validation State: unverified Task: BGP_65536_65547.1.1.1.11 Announcement bits (1): 1-BGP_RT_Background AS path: 65536 I Communities: target:1:1 encapsulation:vxlan(0x8) evpn-mcast-flags:0x1:igmp-snooping-enabled Import Accepted Route Label: 501 Localpref: 100 Router ID: 1.1.1.11 Secondary Tables: evpn-vxlan.evpn.0 Thread: junos-main Indirect next hops: 1 Protocol next hop: 10.1.1.1 ResolvState: Resolved Indirect next hop: 0x2 no-forward INH Session ID: 0 Indirect next hop: INH non-key opaque: 0x0 INH key opaque: 0x0 Indirect path forwarding next hops: 2 Next hop type: Router Next hop: 10.11.11.1 via xe-0/0/0.0 Session Id: 0 Next hop: 10.12.11.1 via xe-0/0/1.0 Session Id: 0 10.1.1.1/32 Originating RIB: inet.0 Node path count: 1 Forwarding nexthops: 2 Next hop type: Router Next hop: 10.11.11.1 via xe-0/0/0.0 Session Id: 0 Next hop: 10.12.11.1 via xe-0/0/1.0 Session Id: 0
In the extensive EVPN database output, verify that multiple advertising peers and route distinguishers (RD) map to the same anycast next-hop behavior.
user@host> show evpn database mac-address 00:00:11:11:51:01 Instance: evpn-vxlan VLAN DomainId MAC address Active source Timestamp IP address 501 00:00:11:11:51:01 00:11:12:11:11:11:11:11:11:11 Apr 01 08:14:52 10.0.51.1 user@host> show evpn database mac-address 00:00:11:11:51:01 extensive Instance: evpn-vxlan VN Identifier: 501, MAC address: 00:00:11:11:51:01 State: 0x0 Source: 00:11:12:11:11:11:11:11:11:11, Rank: 1, Status: Active Remote origin: 10.1.1.1 Remote state: <Mac-Only-Adv> Remote route distinguisher: 1.1.1.11:11 Remote route distinguisher: 1.1.1.12:12 Mobility sequence number: 0 (minimum origin address 10.1.1.1) Timestamp: Apr 01 08:14:52.570573 (0x67ec02ec) State: <Remote-To-Local-Adv-Done> Last IPC-Event: add, Last IPC-Status: none, Last IPC-Timestamp: Apr 1 08:14:51.738 2025 MAC advertisement route status: Not created (no local state present) Interconn advertisement route status: DCI route created IP address: 10.0.51.1 Flags: <Symmetric-ADV IRB-Intf-Nexthop reject-remote-host-ip> Last IPC-Event: add, Last IPC-Status: none, Last IPC-Timestamp: Apr 1 08:14:51.739 2025 Remote origin: 10.1.1.1 Remote state: <Sent-to-l2ald Symmetric-Adv> Remote route distinguisher: 1.1.1.11:11 Remote route distinguisher: 1.1.1.12:12 Interconn advertisement route status: DCI route created History db: Time Event Apr 1 08:14:51.735 2025 00:11:12:11:11:11:11:11:11:11 : Remote peer 10.1.1.1 created, fl: 0x4, state: 0x0, chg: 0x80 Apr 1 08:14:51.735 2025 Rmt Add [], RmtPE 10.1.1.1, RD 1.1.1.11:11, ESI 00:11:12:11:11:11:11:11:11:11, label 501, gbptag 0, mob-seq 0 op: 0x100216003 chg: 0x1 Apr 1 08:14:51.737 2025 Rmt Add [], RmtPE 10.1.1.1, RD 1.1.1.11:11, ESI 00:11:12:11:11:11:11:11:11:11, label 501, gbptag 0, mob-seq 0, IPv4: 10.0.51.1 op: 0x1b0044a000 chg: 0x1 Apr 1 08:14:51.738 2025 Updating output state (change flags 0x1 <ESI-Added>) Apr 1 08:14:51.738 2025 Active ESI changing (not assigned -> 00:11:12:11:11:11:11:11:11:11) Apr 1 08:14:52.568 2025 Rmt Add [], RmtPE 10.1.1.1, RD 1.1.1.12:12, ESI 00:11:12:11:11:11:11:11:11:11, label 501, gbptag 0, mob-seq 0 op: 0x100448000 chg: 0x0 Apr 1 08:14:52.571 2025 Rmt Add [Mhapb ], RmtPE 10.1.1.1, RD 1.1.1.12:12, ESI 00:11:12:11:11:11:11:11:11:11, label 501, gbptag 0, mob-seq 0, IPv4: 10.0.51.1 op: 0x290044e000 chg: 0x0 Apr 1 08:14:52.572 2025 00:11:12:11:11:11:11:11:11:11 : 10.0.51.1 Updating output state (change flags 0x24000 <IP-Remote-Com-Change IP-Remote-Symmetric-ADV-CHANGE>)