Overview

This lab demonstrates how to deploy a Centralized Anycast Gateway in an EVPN/VXLAN fabric built with an IPv6 underlay on Arista EOS.

Lab files including Containerlab topology are available on GitHub.

Motivation

This exercise was inspired by a recent series of blog posts on EVPN Centralized Routing with Arista EOS by Ivan Pepelnjak. While studying the topic, I came across an Arista document describing how to implement an EVPN Centralized Anycast Gateway in fabrics using an IPv4 underlay.

In the Arista document, the solution relies on configuring a secondary IPv4 address on the VXLAN source loopback interface, commonly referred to as the VARP VTEP. While assigning a secondary IPv4 address to a loopback interface is straightforward, IPv6 does not provide an equivalent concept. By design, an IPv6 interface can have multiple addresses without requiring a secondary keyword.

Fortunately, Arista EOS provides an alternative mechanism that works with an IPv6 underlay. The command redistribute router-mac virtual-ip next-hop vtep primary under the MAC-VRF allows the gateway IP and virtual router MAC address to be advertised in EVPN Route Type 2 (MAC/IP Advertisement) routes, enabling a centralized anycast gateway design without the need for a dedicated VARP VTEP address.

Lab consists of following devices

• spine1
• spine2
• leaf1
• leaf2
• leaf3
• host1
• host2

Topology

Implementation and Verification

The following is the minimal working configuration for the MAC-VRFs on the spine switches:

router bgp 4200000000
[omitted]
   !
   vlan 10
      rd 100.64.0.1:10
      route-target both 345:100010
      redistribute learned
      redistribute router-mac virtual-ip next-hop vtep primary
   !
   vlan 20
      rd 100.64.0.1:20
      route-target both 345:100020
      redistribute learned
      redistribute router-mac virtual-ip next-hop vtep primary
   !
[omitted]

(Full configuration can be found in the Containerlab folder clab-evpn-centralized-anycast-gateway).

The redistribute router-mac virtual-ip next-hop vtep primary configuration causes the spine switches to originate and advertise EVPN Route Type 2 (MAC/IP Advertisement) routes for the anycast IP address and virtual MAC address into the EVPN control plane:

spine1#sh bgp evpn route-type mac-ip
BGP routing table information for VRF default
Router identifier 100.64.0.1, local AS number 4200000000
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending best path selection
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 100.64.0.5:20 mac-ip 001c.7322.48bb
                                 2002::100:65:0:5      -       100     0       4200000005 i
 * >      RD: 100.64.0.3:10 mac-ip 001c.7352.8199
                                 2002::100:65:0:3      -       100     0       4200000003 i
 * >      RD: 100.64.0.1:10 mac-ip 0a00.cafe.0001 10.10.0.1
                                 -                     -       -       0       i
 * >      RD: 100.64.0.1:20 mac-ip 0a00.cafe.0001 10.20.0.1
                                 -                     -       -       0       i

ARP table output for clarity:

spine1#sh ip arp vrf vrf-01 
Address         Age (sec)  Hardware Addr   Interface
10.10.0.100       0:07:17  001c.7352.8199  Vlan10, Vxlan1
10.20.0.100       0:01:37  001c.7322.48bb  Vlan20, Vxlan1