VXLAN BGP EVPN Configuration

VxLAN BGP EVPN Configuration

Last Updated: Sep 19, 2018 @ 1:21 am (UTC)

Control Plane learning with BGP and EVPN is one of the newer enhancements to VxLAN. Gone are the days where you need to rely on flooding.

There are also extra features that this brings, at least on the Nexus platform. This adds Integrated Routing and Bridging (IRB) which lets the switches route locally, rather than needing an external router. Anycast gateway allows hosts to connect to any switch and still use the same default gateway.

ARP suppression allows a switch to respond to ARP requests locally, further reducing flooding. And finally, head-end replication (AKA ingress replication) adds the option of simpler configuration for BUM traffic handling.

 

 

Before proceeding with the labs in this article, I recommend that you look at the Bridging Configuration article. This covers the core VxLAN concepts, which I’m going to gloss over here.

 

Make sure you understand these concepts!

VXLANFramesAddressesBridging

 


Lab Environment

As with the simpler flood and learn lab, we’re going to use a simple two-switch topology. Yes, spine/leaf may be better in the real world, but this is simpler for learning VxLAN.

The routed link between the switches is the underlay. OSPF is used as the underlay routing protocol.

We’re using IPv4, but IPv6 would follow the same principles.

 

This time, we have two tenants. One tenant has a LAN segment (VNI) that spans the two switches. The other has two VNI’s, which requires routing between. Some of the address space overlaps, so we will see how BGP can keep the tenants separate.

We use MP-BGP in the overlay. Both switches are in AS 65535. Integrated Routing and Bridging (IRB) is used to route between the VNI’s. This also means that we’ll use anycast gateway on both switches.

BUM traffic will be handled by Head End Replication. This is also known as Ingress Replication. This is not as efficient as multicast, but is very simple to configure. Also, we saw multicast used in the flood and learn lab, so we’re trying something different here.

Now that we’re not using multicast, we only need a single loopback interface. This is only used to give the NVE interface an IP, and the BGP source.

 

 

 

Tenant VNI Type VLAN VRF
Tenant-1 900001 L3 101 Tenant-1
Tenant-1 5000 L2 1000
Tenant-1 1005 L2 1001
Tenant-2 900002 L3 102 Tenant-2
Tenant-2 6000 L2 900

 

 


Underlay

The underlay configuration is nearly the same as in the previous lab, so I won’t get into too much detail.

The big difference is that there is only a single loopback interface.

 

Switch-1(config)# feature ospf
Switch-1(config)# system jumbomtu 9216
Switch-1(config)# router ospf 10

Switch-1(config)# interface ethernet 1/49
Switch-1(config-if)# no switchport
Switch-1(config-if)# ip address 10.10.10.1/30
Switch-1(config-if)# ip router ospf 10 area 0
Switch-1(config-if)# no shut

Switch-1(config)# interface loopback 0
Switch-1(config-if)# ip address 1.1.1.1/32
Switch-1(config-if)# ip router ospf 10 area 0

! If vPC is used, a secondary IP is needed on the loopback
! The secondary IP is the same on both vPC peers
Switch-1(config-if)# ip address 1.1.1.100/32 secondary
Switch-2(config)# feature ospf
Switch-2(config)# system jumbomtu 9216
Switch-2(config)# router ospf 10

Switch-2(config)# interface ethernet 1/49
Switch-2(config-if)# no switchport
Switch-2(config-if)# ip address 10.10.10.2/30
Switch-2(config-if)# ip router ospf 10 area 0
Switch-2(config-if)# no shut

Switch-2(config)# interface loopback 0
Switch-2(config-if)# ip address 2.2.2.2/32
Switch-2(config-if)# ip router ospf 10 area 0

 

As a bonus tip, if you want to use vPC, add a secondary IP to the loopback interface. This IP needs to be the same on the pair of vPC switches.

We won’t be using vPC in this lab, but this is a starting point if you need it.

 

 


Overlay

Global Config

We’ll start by enabling features. The two new features here are interface-vlan and nv overlay evpn.

Interface vlan is used to create a virtual interface based on a VLAN. We use this to create the anycast gateway IP for the VNI, and to tie VNI’s to a tenant’s VRF. Don’t worry, it’ll make more sense soon.

Overlay evpn adds the EVPN address family.

 

Switch-1(config)# feature bgp
Switch-1(config)# feature interface-vlan
Switch-1(config)# feature vn-segment-vlan-based
Switch-1(config)# feature nv overlay
Switch-1(config)# nv overlay evpn

 

There is a vMAC address on each switch for the Anycast Gateway. This is the same on each switch. Making this the same on each means that any switch can respond as the default gateway.

As shown below, some versions of NXOS need a routing template to be set. This is used to change the way memory is partitioned for routes. This needs to be set in 7.0(3)I5(1) and earlier. Newer versions take care of this transparently.

 

Switch-1(config)# fabric forwarding anycast-gateway-mac 0000.2222.3333
Switch-1(config)# System routing template-vxlan-scale

 

The NVE interface is the VTEP. There is only one of these per switch. It uses the loopback interface to get its IP address.

We set BGP as the host-reachability protocol, which enables BGP control plane learning. If this isn’t enabled, then we’re using flood and learn.

The BGP instance is configured mostly as normal. Remember that this is iBGP, so in the real world you need to make sure that you have a full mesh or route reflectors.

We enable the L2VPN EVPN address family, which lets MP-BGP carry MAC addresses.

Extended communities are enabled. This is to support carrying route-target information.

 

Switch-1(config)# interface nve 1
Switch-1(config-if-nve)# no shutdown
Switch-1(config-if-nve)# source-interface loopback 0
Switch-1(config-if-nve)# host-reachability protocol bgp

Switch-1(config)# router bgp 65535
Switch-1(config-router)# router-id 1.1.1.1
Switch-1(config-router)# neighbor 2.2.2.2
Switch-1(config-router-neighbor)# remote-as 65535
Switch-1(config-router-neighbor)# update-source loopback 0
Switch-1(config-router-neighbor)# address-family l2vpn evpn
Switch-1(config-router-neighbor-af)# send-community
Switch-1(config-router-neighbor-af)# send-community extended
Switch-2(config)# interface nve 1
Switch-2(config-if-nve)# no shutdown
Switch-2(config-if-nve)# source-interface loopback 0
Switch-2(config-if-nve)# host-reachability protocol bgp

Switch-2(config)# router bgp 65535
Switch-2(config-router)# router-id 2.2.2.2
Switch-2(config-router)# neighbor 1.1.1.1
Switch-2(config-router-neighbor)# remote-as 65535
Switch-2(config-router-neighbor)# update-source loopback 0
Switch-2(config-router-neighbor)# address-family l2vpn evpn
Switch-2(config-router-neighbor-af)# send-community
Switch-2(config-router-neighbor-af)# send-community extended

 

The First Tenant

It’s time to add the first tenant. The configuration here is the same on both switches.

Firstly, we need to create a VRF. This is associated with VNI 900001, making this an L3VNI. The L3VNI defines the tenant within the fabric, and contains L3 routes for the tenant.

A Route Distinguisher is used to keep the VRF unique in the MP-BGP database. Setting the value automatically is the simplest option.

Route Targets are also assigned automatically. Automatic assignment is recommended unless you have a mixed-vendor environment.

 

VRF
Switch-1(config)# vrf context Tenant-1
Switch-1(config-vrf)# vni 900001
Switch-1(config-vrf)# rd auto
Switch-1(config-vrf)# address-family ipv4 unicast
Switch-1(config-vrf-af-ipv4)# route-target both auto
Switch-1(config-vrf-af-ipv4)# route-target both auto evpn

 

The L3VNI needs an SVI to be created on each switch. SVI’s are based on VLAN, so we need to associate VNI 900001 with VLAN 101 first.

The SVI then needs to be created and associated with the tenant’s VRF. The SVI and VRF represent the tenant’s routing boundary.

The ip forward command is added to the SVI. This command enables routing. Technically, it enables the switch to take the decapsulated VxLAN packet, and forward it to the CPU or Supervisor for handling.

In BGP, we need to add the Tenant’s VRF. Inside this, we use the advertise l2vpn evpn command. This enables advertising EVPN routes (MAC addresses) within the tenant.

 

L3VNI
Switch-1(config)# vlan 101
Switch-1(config-vlan)# vn-segment 900001

Switch-1(config)# int vlan 101
Switch-1(config-if)# no shutdown
Switch-1(config-if)# vrf member Tenant-1
Warning: Deleted all L3 config on interface Vlan101
Switch-1(config-if)# ip forward

Switch-1(config)# router bgp 65535
Switch-1(config-router)# vrf Tenant-1
Switch-1(config-router-vrf)# address-family ipv4 unicast
Switch-1(config-router-vrf-af)# advertise l2vpn evpn

 

Now it’s time for the L2VNI’s. These are the more traditional LAN segments.

We start with binding VNI 5000 to VLAN 1000. VNI 5000 then needs to be added to the VTEP. This is also where we enable ARP Suppression, and configure ingress replication. Finally, associate the VNI with the tenant’s L3VNI/VRF to enable IRB.

Each VNI that needs to be routable needs to have an SVI in the tenant’s VRF. This SVI is given the same IP address on each switch, which enables Anycast Gateway.

 

L2VNI
Switch-1(config)# vlan 1000
Switch-1(config-vlan)# vn-segment 5000

Switch-1(config-if)# interface nve1
Switch-1(config-if-nve)# member vni 5000
Switch-1(config-if-nve-vni)# suppress-arp
Switch-1(config-if-nve-vni)# ingress-replication protocol bgp
Switch-1(config-if-nve-vni)# member vni 900001 associate-vrf

Switch-1(config-vlan)# interface vlan 1000
Switch-1(config-if)# no shutdown
Switch-1(config-if)# vrf member Tenant-1
Warning: Deleted all L3 config on interface Vlan1000
Switch-1(config-if)# ip address 192.168.0.1/24
Switch-1(config-if)# fabric forwarding mode anycast-gateway

 

Now we need to enable sharing EVPN routes (MAC addresses). This looks a lot like normal BGP configuration.

In EVPN configuration, each L2VNI needs to have an RD and RT’s assigned. This is because they use a MAC-VRF. In the MP-BGP database, L3 routes and L2 MAC addresses are in separate VRF’s. These values are still set to auto in our case, but are different to the L3VNI’s RD’s and RT’s in MP-BGP.

I know that this might sound a bit confusing. Just remember that you need to advertise L3 information into BGP, as well as separate L2 information. Even though all this is part of the same tenant, L2 and L3 addresses are different, and are treated like they’re different address families.

 

EVPN
Switch-1(config)# evpn
Switch-1(config-evpn)# vni 5000 l2
Switch-1(config-evpn-evi)# rd auto
Switch-1(config-evpn-evi)# route-target import auto
Switch-1(config-evpn-evi)# route-target export auto

 

The host ports are configured as normal access ports. This example is only on Switch-1.

 

Host port
Switch-1(configi)# interface eth 1/1
Switch-1(config-if)# switchport
Switch-1(config-if)# switchport access vlan 1000
Switch-1(config-if)# no shutdown

 

Now let’s add another VNI for this tenant. This is basically the same process that we just went through.

 

A New VNI
Switch-1(config)# vlan 1001
Switch-1(config-vlan)# vn-segment 5005

Switch-1(config)# interface vlan 1001
Switch-1(config-if)# no shutdown
Switch-1(config-if)# vrf member Tenant-1
Warning: Deleted all L3 config on interface Vlan1001
Switch-1(config-if)# ip address 192.168.10.1/24
Switch-1(config-if)# fabric forwarding mode anycast-gateway

Switch-1(config)# interface nve1
Switch-1(config-if-nve)# member vni 5005
Switch-1(config-if-nve-vni)# suppress-arp
Switch-1(config-if-nve-vni)# ingress-replication protocol bgp

Switch-1(config)# evpn
Switch-1(config-evpn)# vni 5005 l2
Switch-1(config-evpn-evi)# rd auto
Switch-1(config-evpn-evi)# route-target import auto
Switch-1(config-evpn-evi)# route-target export auto

And finally the host port on Switch-2.

 

Host Port
! This part only on SW-2
Switch-2(config)# interface ethernet 1/1
Switch-2(config-if)# switchport access vlan 1001

The Second Tenant

Now to repeat the process to add the second tenant. This follows the same basic process:

  1. Create VRF
  2. Create L3VNI
  3. Create L2VNI and anycast gateway
  4. Add L2VNI to VTEP
  5. Add L2VNI to EVPN
Tenant-2
Switch-1(config)# vrf context Tenant-2
Switch-1(config-vrf)# vni 900002
Switch-1(config-vrf)# rd auto
Switch-1(config-vrf)# address-family ipv4 unicast
Switch-1(config-vrf-af-ipv4)# route-target both auto
Switch-1(config-vrf-af-ipv4)# route-target both auto evpn

Switch-1(config)# vlan 102
Switch-1(config-vlan)# vn-segment 900002

Switch-1(config)# interface vlan 102
Switch-1(config-if)# no shutdown
Switch-1(config-if)# vrf member Tenant-2
Warning: Deleted all L3 config on interface Vlan102
Switch-1(config-if)# ip forward

Switch-1(config)# vlan 900
Switch-1(config-vlan)# vn-segment 6000

Switch-1(config)# interface vlan 900
Switch-1(config-if)# no shutdown
Switch-1(config-if)# vrf member Tenant-2
Warning: Deleted all L3 config on interface Vlan900
Switch-1(config-if)# ip address 192.168.0.1/24
Switch-1(config-if)# fabric forwarding mode anycast-gateway

Switch-1(config)# interface nve1
Switch-1(config-if-nve)# member vni 900002 associate-vrf
Switch-1(config-if-nve)# member vni 6000
Switch-1(config-if-nve-vni)# suppress-arp
Switch-1(config-if-nve-vni)# ingress-replication protocol bgp

Switch-1(config)# evpn
Switch-1(config-evpn)# vni 6000 l2
Switch-1(config-evpn-evi)# rd auto
Switch-1(config-evpn-evi)# route-target import auto
Switch-1(config-evpn-evi)# route-target export auto

 

And the host ports.

 

Host Ports
Switch-1(config)# interface ethernet 1/2
Switch-1(config-if)# switchport
Switch-1(config-if)# switchport access vlan 900
Switch-1(config-if)# no shutdown

Switch-2(config)# interface ethernet 1/2
Switch-2(config-if)# switchport
Switch-2(config-if)# switchport access vlan 900
Switch-2(config-if)# no shutdown

 

 


Verification

To verify, start by checking that BGP neighbours are forming. This is almost identical to regular BGP.

Remember to check the State/PfxRcd field.

 

Switch-1# show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 1.1.1.1, local AS number 65535
BGP table version is 11, L2VPN EVPN config peers 1, capable peers 1
5 network entries and 5 paths using 952 bytes of memory
BGP attribute entries [4/624], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
2.2.2.2         4 65535      33      36       11    0    0 00:22:09 1
Switch-2# show bgp l2vpn evpn summary
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 2.2.2.2, local AS number 65535
BGP table version is 15, L2VPN EVPN config peers 1, capable peers 1
9 network entries and 9 paths using 1432 bytes of memory
BGP attribute entries [5/780], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4 65535      37      36       15    0    0 00:23:37 3

 

Now, lets look at the NVE peers. This is where we can see the remote VTEPs that have been discovered.

Notice that the LearnType field shows CP, for control plane learning.

 

Switch-1# show nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      2.2.2.2          Up    CP        00:02:32 n/a
Switch-2# show nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      1.1.1.1          Up    CP        00:02:30 286f.7f7d.e3f7

 

Now, see the VNI’s that are associated with the local VTEP.

Look at the Type column. This tells us if this is a layer-2 or layer-3 VNI. If it’s an L2VNI, the associated VLAN comes next. If it’s an L3VNI, the VRF comes next.

L2VNI’s may have an SA flag. This indicates that ARP suppression is enabled.

The Multicast-group column would normally contain the mcast group used for BUM traffic. This is set to UnicastBGP in our case, as we’re using ingress replication.

 

Switch-1# show nve vni
Codes: CP - Control Plane        DP - Data Plane
       UC - Unconfigured         SA - Suppress ARP

Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags
--------- -------- ----------------- ----- ---- ------------------ -----
nve1      5000     UnicastBGP        Up    CP   L2 [1000]          SA
nve1      900001   n/a               Up    CP   L3 [Tenant-1]
Switch-2# show nve vni
Codes: CP - Control Plane        DP - Data Plane
       UC - Unconfigured         SA - Suppress ARP

Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags
--------- -------- ----------------- ----- ---- ------------------ -----
nve1      5000     UnicastBGP        Up    CP   L2 [1000]          SA
nve1      900001   n/a               Up    CP   L3 [Tenant-1]

 

show vxlan is a simple command to show VLAN to VxLAN (VN-Segment) bindings.

 

Switch-1# show vxlan
Vlan            VN-Segment
====            ==========
101             900001
1000            5000
Switch-2# show vxlan
Vlan            VN-Segment
====            ==========
101             900001
1000            5000

 

Now, have a look at layer-2 routing information. As MAC addresses are learned, they are added here.

The first entry in the example below is learned through BGP. The second has been learned on the local switch, on interface eth 1/1.

 

Switch-1# show l2route evpn mac all

Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link
(Dup):Duplicate (Spl):Split (Rcv):Recv (AD):Auto-Delete(D):Del Pending (S):Stale
 (C):Clear
(Ps):Peer Sync (O):Re-Originated

Topology    Mac Address    Prod   Flags         Seq No     Next-Hops
----------- -------------- ------ ------------- ---------- ----------------
1000        74a0.2f8d.8780 BGP    Rcv           0          2.2.2.2
1000        b4b5.2f7b.182a Local  L,            0          Eth1/1
Switch-2# show l2route evpn mac all

Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link
(Dup):Duplicate (Spl):Split (Rcv):Recv (AD):Auto-Delete(D):Del Pending (S):Stale
 (C):Clear
(Ps):Peer Sync (O):Re-Originated

Topology    Mac Address    Prod   Flags         Seq No     Next-Hops
----------- -------------- ------ ------------- ---------- ----------------
101         286f.7f7d.e3f7 VXLAN  Rmac          0          1.1.1.1
1000        74a0.2f8d.8780 Local  L,            0          Eth1/1
1000        b4b5.2f7b.182a BGP    SplRcv        0          1.1.1.1

 

This next command shows the IP to MAC relationship.

 

MAC to IP
Switch-1# show l2route evpn mac-ip all
Flags -(Rmac):Router MAC (Stt):Static (L):Local (R):Remote (V):vPC link
(Dup):Duplicate (Spl):Split (Rcv):Recv(D):Del Pending (S):Stale (C):Clear
(Ps):Peer Sync (Ro):Re-Originated
Topology    Mac Address    Prod   Flags         Seq No     Host IP         Next-
Hops
----------- -------------- ------ ---------- --------------- ---------------
1000        b4b5.2f7b.182a HMM    --            0          192.168.0.10   Local

 

This final command is the big one. This is the BGP database.

There are several entries of note here. Routes are grouped by route distinguisher. This represents the tenant’s VRF.

Each of these entries is type-2 or type-3, meaning L2VNI or L3VNI. The important parts though are the MAC and IP addresses, and the next-hop (remote VTEP).

 

Switch-1# show bgp l2vpn evpn
BGP routing table information for VRF default, address family L2VPN EVPN
BGP table version is 13, local router ID is 1.1.1.1
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-i
njected
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 1.1.1.1:33767    (L2VNI 5000)
*>i[2]:[0]:[0]:[48]:[74a0.2f8d.8780]:[0]:[0.0.0.0]/216
                      2.2.2.2                           100          0 i
*>l[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[0]:[0.0.0.0]/216
                      1.1.1.1                           100      32768 i
*>l[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[32]:[192.168.0.10]/272
                      1.1.1.1                           100      32768 i
*>l[3]:[0]:[32]:[1.1.1.1]/88
                      1.1.1.1                           100      32768 i
*>i[3]:[0]:[32]:[2.2.2.2]/88
                      2.2.2.2                           100          0 i

Route Distinguisher: 2.2.2.2:33767
*>i[2]:[0]:[0]:[48]:[74a0.2f8d.8780]:[0]:[0.0.0.0]/216
                      2.2.2.2                           100          0 i
*>i[3]:[0]:[32]:[2.2.2.2]/88
                      2.2.2.2                           100          0 i
Switch-2# show bgp l2vpn evpn
BGP routing table information for VRF default, address family L2VPN EVPN
BGP table version is 15, local router ID is 2.2.2.2
Status: s-suppressed, x-deleted, S-stale, d-dampened, h-history, *-valid, >-best
Path type: i-internal, e-external, c-confed, l-local, a-aggregate, r-redist, I-i
njected
Origin codes: i - IGP, e - EGP, ? - incomplete, | - multipath, & - backup

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 1.1.1.1:33767
*>i[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[0]:[0.0.0.0]/216
                      1.1.1.1                           100          0 i
*>i[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[32]:[192.168.0.10]/272
                      1.1.1.1                           100          0 i
*>i[3]:[0]:[32]:[1.1.1.1]/88
                      1.1.1.1                           100          0 i

Route Distinguisher: 2.2.2.2:33767    (L2VNI 5000)
*>l[2]:[0]:[0]:[48]:[74a0.2f8d.8780]:[0]:[0.0.0.0]/216
                      2.2.2.2                           100      32768 i
*>i[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[0]:[0.0.0.0]/216
                      1.1.1.1                           100          0 i
*>i[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[32]:[192.168.0.10]/272
                      1.1.1.1                           100          0 i
*>i[3]:[0]:[32]:[1.1.1.1]/88
                      1.1.1.1                           100          0 i
*>l[3]:[0]:[32]:[2.2.2.2]/88
                      2.2.2.2                           100      32768 i

Route Distinguisher: 2.2.2.2:3    (L3VNI 900001)
*>i[2]:[0]:[0]:[48]:[b4b5.2f7b.182a]:[32]:[192.168.0.10]/272
                      1.1.1.1                           100          0 i

References

Network Direction – Home Page

2 Replies to “VXLAN BGP EVPN Configuration

  1. Migrated Comment:

    Nexus 9k possible problems
    Kristof (unverified) 2018-06-07 18:01
    Hi,
    Your design works fine, but there is a problem when you change the layer3 interfaces to SVI interfaces. Everything looks fine in ‘sh l2route evpn mac all’ and in BGP, but SVI interfaces do not pass the traffic.
    Another issue is when you change the iBGP to eBGP. BGP sessions are up, but no prefixes/mac’s are passed from one end to the other.
    Have you met with similar problems? Maybe it is just how cisco implemented in 9k platform.

  2. Migrated Comment:

    Nexus 9k possible problems
    Luke Robertson 2018-06-09 18:47
    I haven’t seen these problems myself.
    For the SVI’s, make sure you are using ‘ip forward’. I think anycast gateway is optional. Try without that, and see if that helps.
    Are you talking about using eBGP in the underlay or overlay? I haven’t done it, but I’m fairly sure eBGP is supported in the underlay, but I’m not sure about the overlay.

    I attended a session at Cisco Live in Melbourne earlier this year that may help. It’s called “Troubleshooting VxLAN BGP EVPN – BRKDCN-3040”. The recording is here:
    https://www.ciscolive.com/global/on-demand-library/?search=vxlan#/session/1507093353793001jMwy

    Let me know how you go

Leave a Reply