EVPN extension to BGP using VXLAN

eos.arista.com/eos-4-18-1f/evpn-vxlan

By Lavanya

Ethernet VPN (EVPN) is an extension of the BGP protocol introducing a new address family:
L2VPN (address family number 25) / EVPN (subsequent address family number 70). It is used
to exchange overlay MAC and IP address reachability information between BGP peers within a
tunnel [1]. In EOS 4.18.1F VXLAN tunnel support was introduced [2]. The available features
are:

Single-homing L2 routes (EVPN type 2 and type 3), with MLAG used as the L2 multi-
homing solution.
Multi-homing L2 routes (EVPN type 1 and type 2) are received and installed, with up to
two all-active remote paths per destination (additional paths are ignored).
Layer 3 IPv4 and IPv6 routes (type 5) are sent, received and installed, using the
interface-less model described in the IETF draft for EVPN IP prefix advertisement [3].

As of 4.20.1F, EOS supports the VLAN-Aware bundle service interface as described in section
6.3 of RFC7432 [1].

By distributing reachability information over a tunnel, EVPN allows network topology changes
to occur without requiring that every device be reconfigured, and allows the network to quickly
respond to changes such as link failure or host mobility.

Contents [hide]

Supported Platforms
Configuration
Activate EVPN
L2 overlay configuration
VLAN-Aware Bundle Service Interface
L3 overlay configuration
VXLAN tunnel configuration
MLAG example
Status
Show commands
Syslog messages
Troubleshooting
No EVPN route advertisement
EVPN routes not received
EVPN MAC/IP or IP prefix routes received, but not present in the MAC or routing
table
Unavailable or unexpected best path
1/16
 Limitations
Resources

Supported Platforms
Beginning with EOS 4.20.5F, DCS-7050X2 also supports this feature. Following is the
complete list of supported platforms:

DCS-7050X*
DCS-7050X2
DCS-7060X*
DCS-7250X
DCS-7300X
DCS-7320X
DCS-7280R
DCS-7500R

For products marked with a *, please see Vxlan Routing for information about configuring
recirculation interfaces.

Configuration

Activate EVPN
In all scenarios, EVPN must be activated and BGP neighbors configured to exchange any
routes.

service routing protocols model multi-agent

router bgp 102
neighbor 10.0.0.3 remote-as 103
neighbor 10.0.0.3 send-community extended
neighbor 10.0.0.4 remote-as 104
neighbor 10.0.0.4 send-community extended
address-family evpn
neighbor 10.0.0.3 activate
neighbor 10.0.0.4 activate

The configuration above sets the local autonomous system number to 102 and configures two
BGP neighbors in the L2VPN/EVPN address family, with ASNs 103 and 104 respectively. It
also enables the multi-agent routing protocol model, which is required for EVPN support.

L2 overlay configuration

2/16
When the EVPN address family is active, distribution of L2 routes over BGP is enabled by
configuring one or more VLANs in the BGP submode. Routes are distributed using the VLAN-
based service interface described in section 6.1 of RFC7432 [1].

router bgp 102

...
vlan 10
rd 10.0.0.2:10
route-target export 102:10
route-target import 103:10
route-target import 104:10
redistribute learned

The route distinguisher (rd) and export route target may be set to any valid route distinguisher
or route target value as described in RFC7432 [1]. A common convention is to use a type 1
route distinguisher <local-ip>:<vlan-id>, and <as-number>:<vlan-id> for the route target.

Each VLAN will typically have one or more import route targets, matching the export route
targets of peer VRFs from which routes should be obtained. In the above example, if the peer
at 10.0.0.2 exports a VLAN with route target 102:10, the routes originating at that peer will be
installed.

Note that the export route target need not be unique to a particular peer. By using a fixed
number (for example, 1) in place of the autonomous system number in the convention above,
it is possible to distribute MAC addresses on VLAN 10 across the whole network automatically
using route-target both 1:10.

VLAN-Aware Bundle Service Interface

A VLAN-Aware bundle MAC-VRF allows multiple L2 domains to be advertised by a single
MAC-VRF. The Ethernet Tag ID (ETID) as described in RFC7432 [1] identifies the L2 domain
corresponding to each route. VLAN-Aware mode can be configured by using the vlan-aware-
bundle BGP submode.

router bgp 102

...
vlan-aware-bundle exampleMacVrf
rd 10.0.0.2:10
vlan 100-199
vlan 200 etid 1234
route-target export 102:10
route-target import 103:10
route-target import 104:10
redistribute learned

Each vlan-aware-bundle MAC-VRF will require an unique name. The user will need to specify
the VLANs to be included in the MAC-VRF. By default, the Ethernet Tag ID for a given VLAN
is the VNI associated locally to that VLAN, unless the Ethernet Tag ID is explicitly set with the
etid option.
3/16
The remaining configuration options for VLAN-based MAC-VRFs also apply to VLAN-Aware
bundle MAC-VRFs.

L3 overlay configuration
Distribution of L3 routes over BGP is enabled by configuring one or more IP VRFs under the
router bgp configuration mode. IP or IPv6 routing must be enabled in the VRF.

router bgp 102

vrf red
rd 10.0.0.2:65001
address-family ipv4
route-target both 102:5001
redistribute connected
redistribute static
address-family ipv6
route-target both 102:5002
redistribute connected
redistribute static
ip routing vrf red
ipv6 unicast-routing vrf red

As with VLANs, each IP VRF must have a unique route distinguisher. The route target and
redistribute directives may be configured either directly under the VRF, or under the IPv4 or
IPv6 address-family.

VXLAN tunnel configuration

In order for EVPN to operate successfully, the VLANs or VRFs must be associated with a
tunneling interface. There is no special EVPN-specific configuration here, but for reference,
here is an example that combines with the configuration in the sections above to produce a
working set of tunnels for L2 traffic and for L3 traffic in the VRF named “red”.

interface Loopback0
ip address 10.80.0.2/32
interface Vxlan1
vxlan source-interface Loopback0
vxlan vlan 10 vni 10010
vxlan vrf red vni 20001

Bear in mind that while routes in EVPN may be imported into any VLAN or VRF, the VLAN or
VRF must be mapped to the same VNI as is used to encapsulate the incoming data packets,
otherwise the hardware tables cannot be programmed and no traffic will flow.

MLAG example

4/16
This is a topology in which MLAG is used on two top of rack routers. The MLAG peers share
the same loopback address, but each runs its own instance of BGP (advertising the same set
of routes as its peer). In this example, although each peer uses a different VLAN, the MAC
addresses sent from each nevertheless reside on the same layer 2 domain because each peer
maps its VLAN to VNI 10000.

As far as BGP in the underlay is concerned, the five devices comprising this network are five
distinct routers in a total of three different autonomous systems. Once the EVPN and IP routes
have been resolved, however, MAC addresses behind the MLAG pairs will be installed with a
VTEP IP address of the shared loopback interface, which is reached by tunneled packets
through ECMP in the routing layer. This is in contrast to EVPN multi-homing, in which every
MAC address has its own set of destination VTEPs and load balancing (“layer 2 ECMP”)
occurs at the switching layer.

Running config for peer1 in AS 200. Ethernet1 is the peer link, Ethernet2 connects to the
router with ASN 100 and Ethernet3 is a host connection.

vlan 200
!
vlan 4094
trunk group peerlink
!
interface Port-Channel200
switchport access vlan 200
mlag 10
!
interface Ethernet1
switchport mode trunk
switchport trunk group peerlink
!
5/16
interface Ethernet2
no switchport
ip address 10.10.0.2/30
!
interface Ethernet3
channel-group 100 mode active
!
interface Loopback0
ip address 10.80.0.2/32
!
interface Vlan4094
no autostate
ip address 10.0.0.1/30
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 200 vni 10000
!
service routing protocols model multi-agent
ip routing
!
mlag configuration
domain-id sample_domain_1
local-interface Vlan4094
peer-address 10.0.0.2
primary-priority 11
peer-link Ethernet1
reload-delay 0
!
router bgp 200
neighbor 10.10.0.1 remote-as 100
neighbor 10.10.0.1 send-community extended
neighbor 10.10.0.1 maximum-routes 12000
redistribute connected
vlan 200
rd 10.10.0.2:200
route-target import 10.80.0.1:100
route-target import 10.80.0.3:300
route-target export 10.80.0.2:200
redistribute learned
address-family evpn
neighbor 10.10.0.2 activate
!
address-family ipv4
neighbor 10.10.0.2 activate
!

Running config for peer2 in AS 200. Again, Ethernet1 is the peer link, Ethernet2 connects to
the router with ASN 100 and Ethernet3 is a host connection. The configuration is very similar to
the peer; the differences are emphasized.

vlan 200
6/16
!
vlan 4094
trunk group peerlink
!
interface Port-Channel200
switchport access vlan 200
mlag 10
!
interface Ethernet1
switchport mode trunk
switchport trunk group peerlink
!
interface Ethernet2
no switchport
ip address 10.10.1.2/30
!
interface Ethernet3
channel-group 100 mode active
!
interface Loopback0
ip address 10.80.0.2/32
!
interface Vlan4094
no autostate
ip address 10.0.0.2/30
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 200 vni 10000
!
service routing protocols model multi-agent
ip routing
!
mlag configuration
domain-id sample_domain_1
local-interface Vlan4094
peer-address 10.0.0.1
primary-priority 12
peer-link Ethernet1
reload-delay 0
!
router bgp 200
neighbor 10.10.1.1 remote-as 100
neighbor 10.10.1.1 send-community extended
neighbor 10.10.1.1 maximum-routes 12000
redistribute connected
vlan 200
rd 10.10.1.2:200
route-target import 10.80.0.1:100
route-target import 10.80.0.3:300
route-target export 10.80.0.2:200
redistribute learned
7/16
 address-family evpn
neighbor 10.10.1.2 activate
!
address-family ipv4
neighbor 10.10.1.2 activate
!

Running config for the standalone router with ASN 300. Ethernet 1 and Ethernet 2 connect to
each of the MLAG peers in AS 200, while Ethernet 3 and Ethernet 4 connect to the MLAG
peers in AS 300. Ethernet 5 is a host connection.

vlan 100
!
interface Ethernet1
no switchport
ip address 10.10.0.1/30
!
interface Ethernet2
no switchport
ip address 10.10.1.1/30
!
interface Ethernet3
no switchport
ip address 10.10.2.1/30
!
interface Ethernet4
no switchport
ip address 10.10.3.1/30
!
interface Ethernet5
switchport access vlan 100
!
interface Loopback0
ip address 10.80.0.1/32
!
interface Vxlan1
vxlan source-interface Loopback0
vxlan udp-port 4789
vxlan vlan 100 vni 10000
!
service routing protocols model multi-agent
ip routing
!
router bgp 100
maximum-paths 2
neighbor 10.10.0.2 remote-as 200
neighbor 10.10.0.2 send-community extended
neighbor 10.10.0.2 maximum-routes 12000
neighbor 10.10.1.2 remote-as 200
neighbor 10.10.1.2 send-community extended
neighbor 10.10.1.2 maximum-routes 12000
neighbor 10.10.2.2 remote-as 300
neighbor 10.10.2.2 send-community extended
8/16
 neighbor 10.10.2.2 maximum-routes 12000
neighbor 10.10.3.2 remote-as 300
neighbor 10.10.3.2 send-community extended
neighbor 10.10.3.2 maximum-routes 12000
redistribute connected
vlan 100
rd 10.10.0.1:100
route-target import 10.80.0.2:200
route-target import 10.80.0.3:300
route-target export 10.80.0.1:100
redistribute learned
address-family evpn
neighbor 10.10.0.2 activate
neighbor 10.10.1.2 activate
neighbor 10.10.2.2 activate
neighbor 10.10.3.2 activate
!
address-family ipv4
neighbor 10.10.0.2 activate
neighbor 10.10.1.2 activate
neighbor 10.10.2.2 activate
neighbor 10.10.3.2 activate
!

Status

Show commands
Show the status of EVPN peers.

Arista#show bgp evpn summary

BGP summary information for VRF default
Router identifier 10.80.0.2, local AS number 65004
Neighbor Status Codes: m – Under maintenance
Neighbor V AS MsgRcvd MsgSent InQ OutQ Up/Down State PfxRcd
PfxAcc
100.255.0.6 4 103 24399 14273 0 0 00:08:49 Estab 1500
1500

Show routes sent and received through EVPN.

9/16
Arista#show bgp evpn
BGP routing table information for VRF default
Router identifier 10.80.0.2, local AS number 102
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP
head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
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

Route Distinguisher: 10.0.0.2:10
* > mac-ip e25a.233d.92f3
10.80.0.2 - - 0 i
* > imet 10.80.0.2 10.80.0.2 - - 0 i
Route Distinguisher: 10.0.0.3:10
* > mac-ip 4aae.bc7b.d0db
10.80.0.3 - 100 0 103 i
* > imet 10.80.0.3 10.80.0.3 - 100 0 103 i
Route Distinguisher: 10.0.0.2:65001
* > ip-prefix 1.0.0.0/24
10.80.0.2 - - 0 i
* > ip-prefix 2001:eb8:40::/48
10.80.0.2 - - 0 i
Route Distinguisher: 10.0.0.3:65001
* > ip-prefix 1.1.0.0/24
10.80.0.3 - 100 0 103 i
* > ip-prefix 2001:eb8:41::/48
10.80.0.3 - 100 0 103 i

To show those routes corresponding to only one peer, use show bgp neighbors evpn
advertised-routes or show bgp neighbors evpn received-routes, each of which has a
similar output to show bgp evpn and takes the same filter arguments.

A more detailed view of the MAC/IP route for 4a:ae:bc:7b:d0:db

Arista#show bgp evpn route-type mac-ip 4aae.bc7b.d0db detail

BGP routing table information for VRF default
Router identifier 10.0.0.2, local AS number 102
BGP routing table entry for mac-ip 4aae.bc7b.d0db, Route Distinguisher: 10.0.0.3:10
Paths: 1 available
103
10.80.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, valid, external, best
Extended Community: RT:103:10, TunnelEncap:tunnelTypeVxlan, EvpnMacMobility:0
VNI: 10010 ESI: 0000:0000:0000:0000:0000

A more detailed view of the IP prefix route for 1.1.0.0/24.

10/16
Arista#show bgp evpn route-type ip-prefix 1.1.0.0/24 detail
BGP routing table information for VRF default
Router identifier 10.0.0.2, local AS number 102
BGP routing table entry for ip-prefix 1.1.0.0/24, Route Distinguisher: 10.0.0.3:65001
Paths: 1 available
103
10.80.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, ECMP head, best,
ECMP contributor
Extended Community: RT:103:5001, TunnelEncap:tunnelTypeVxlan,
EvpnRouterMac:44:4c:a8:55:58:b1
VNI: 20001

For an IP prefix (type 5) route, show the BGP table for the VRF containing the imported route.

Arista#show ip bgp 1.1.0.0/24 detail vrf red

BGP routing table information for VRF red
Router identifier 10.0.0.2, local AS number 102
BGP routing table entry for 1.1.0.0/24
Paths: 1 available
103
10.80.0.3 from - (0.0.0.0)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, ECMP head, best,
ECMP contributor
Extended Community: RT:103:5001, TunnelEncap:tunnelTypeVxlan,
EvpnRouterMac:44:4c:a8:55:58:b1

For a MAC/IP (type 2) route, show the L2 input table from BGP. This is resolved with any other
inputs and then sent to the VXLAN MAC address table.

11/16
Arista#show l2rib input bgp mac 4a:ae:bc:7b:d0:db
L2 RIB bgp Input Table
Address Vlan SeqNo MoveTime Pref Type Destination
------- ---- ----- -------- ---- ---- -----------
4a:ae:bc:7b:d0:db 100 1 5338645 16 Vtep 10.80.0.3
Arista#show vxlan address-table
Vxlan Mac Address Table
----------------------------------------------------------------------

VLAN Mac Address Type Prt VTEP Moves Last Move

---- ----------- ---- --- ---- ----- ---------
100 4aae.bc7b.d0db EVPN Vx1 10.80.0.3 1 0:00:05 ago
Total Remote Mac Addresses for this criterion: 1
Arista#show mac address-table
Mac Address Table
------------------------------------------------------------------

Vlan Mac Address Type Ports Moves Last Move

---- ----------- ---- ----- ----- ---------
100 4aae.bc7b.d0db DYNAMIC Vx1 1 0:00:05 ago
Total Mac Addresses for this criterion: 1

Multicast Mac Address Table

------------------------------------------------------------------

Vlan Mac Address Type Ports

---- ----------- ---- -----
Total Mac Addresses for this criterion: 0

For an IMET (type 3) route, show the L2 flood set input from BGP. The zero address shown
indicates that the flood set applies to broadcast and unknown unicast traffic, other addresses
indicate multicast destinations.

Arista##show l2rib input bgp floodset vlan 100

L2 RIB bgp Input FloodSet:
Vlan Address Type Destination
---- ----------------- ---- -------------
100 00:00:00:00:00:00 All vxlan 10.80.0.3

Show the VRF routing table, containing IP routes that are available within the VRF from all
sources. Prefixes with the B code and a VNI shown are sourced from type 5 EVPN routes
received through BGP.

12/16
Arista#show ip route vrf red 1.1.0.0/24

VRF name: red

Codes: C - connected, S - static, K - kernel,
O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
R - RIP, I L1 - ISIS level 1, I L2 - ISIS level 2,
O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
NG - Nexthop Group Static Route, V - VXLAN Control Service

B I 1.1.0.0/24 [1/0] via VTEP 10.80.0.3 VNI 20001 router-mac 44:4c:a8:55:58:b1

Show command outputs for VLAN-Aware bundle MAC-VRFs will display the ETID value next to
the MAC address. For example, the ETID is 10100 in the following CLI output.

Arista#show bgp evpn

BGP routing table information for VRF default
Router identifier 10.80.0.2, local AS number 102
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - ECMP
head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
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

Route Distinguisher: 10.0.0.2:10
* > mac-ip 10100 e25a.233d.92f3
10.80.0.2 - - 0 i
* > imet 10100 10.80.0.2 10.80.0.2 - - 0 i
Route Distinguisher: 10.0.0.3:10
* > mac-ip 10100 4aae.bc7b.d0db
10.80.0.3 - 100 0 103 i
* > imet 10100 10.80.0.3 10.80.0.3 - 100 0 103 i

Arista#show bgp evpn route-type mac-ip 4aae.bc7b.d0db detail

BGP routing table information for VRF default
Router identifier 10.0.0.2, local AS number 102
BGP routing table entry for mac-ip 10100 4aae.bc7b.d0db, Route Distinguisher:
10.0.0.3:10
Paths: 1 available
103
10.80.0.3 from 10.0.0.3 (10.0.0.3)
Origin IGP, metric -, localpref 100, weight 0, valid, external, best
Extended Community: RT:103:10, TunnelEncap:tunnelTypeVxlan, EvpnMacMobility:0
VNI: 10010 ESI: 0000:0000:0000:0000:0000

Syslog messages

13/16
If a route is received with a tunnel encapsulation extended community whose value is an
unsupported type (anything except VXLAN in EOS 4.18.1F), the route is ignored and the
%EVPN-4-INVALID_TUNNEL_ENCAP syslog is generated.

If a route is received with an invalid IP address (a multicast address, for example) in the NLRI
or nexthop, the route is ignored and the %EVPN-4-INVALID_VTEP_IP syslog is generated.

If a type 5 route is received with an invalid MAC address (a multicast address, for example) in
the router MAC extended community, the route is ignored and the %EVPN-4-
INVALID_VTEP_ROUTER_MAC syslog is generated.

If a type 5 route is received with a non-zero Ethernet Segment ID field in the NLRI, the route is
ignored and the %EVPN-4-NON_ZERO_ESI syslog is generated.

If a type 5 route is received with a non-zero ethernet tag field in the NLRI, the route is ignored
and the %EVPN-4-NON_ZERO_ETID syslog is generated.

If a route of any type except type 1 is received with the reserved MAX_ETID value in the
ethernet tag field, the route is ignored and the %EVPN-4-INVALID_ETID syslog is generated.

If a type 5 route is received with a non-zero gateway address field in the NLRI, the route is
ignored and the %EVPN-4-NON_ZERO_GATEWAY_ADDRESS syslog is generated.

If all-active multi-homing would cause a MAC address to be multi-homed to more destinations

than the supported number, the maximum possible number of destinations are chosen and the
%EVPN-4-MAX_L2ECMP_EXCEEDED syslog is generated. Priority is given to destinations
which advertised a type 2 route.

Troubleshooting

No EVPN route advertisement

When configured correctly with at least one peer, L2 EVPN should advertise at least an
Inclusive Multicast Ethernet Tag (type 3) route for each VNI, and L3 EVPN should advertise
connected IP prefixes in the configured VRFs. If this is not the case:

Ensure that the loopback source interface for the VXLAN interface is configured, and
that routing is enabled on the switch.
Check the VXLAN configuration. Make sure that the VLAN to VNI and VRF to VNI
bindings (as necessary) are configured.
Ensure that service routing protocols model multi-agent is configured.
Check that the BGP configuration for the VRF or VLAN is correct. Ensure that the route
distinguisher and export route targets are present, and that at least one neighbor is
active in the EVPN address family.
(L3 only) Ensure that the VRF is enabled, routing is enabled in the VRF and that the
14/16
 desired interfaces are forwarding in the VRF.
(L3 only) Ensure that redistribute connected is specified in the BGP VRF configuration.

If an IMET (type 3) route is advertised for a VNI and the switch is learning MAC addresses
locally on the corresponding VLAN, but is not advertising them, check that redistribute
learned is present in the configuration for the VLAN.

EVPN routes not received

If show bgp evpn does not show the expected EVPN routes:

Check that there is a BGP connection to the peer in the default VRF.
Check that the peer is advertising the expected routes.

EVPN MAC/IP or IP prefix routes received, but not present in

the MAC or routing table
If show bgp evpn indicates that a MAC/IP (type 2) or IP prefix (type 5) route has been installed
but it is not showing up in show l2rib input bgp or show ip bgp vrf <vrf-name> respectively:

Check that the route contains extended communities. If not, ensure that the peer has
enabled send-community extended in its neighbor configuration.
Check that the route target matches the expected import route target.
Check that the ethernet tag ID field in show bgp evpn is not displayed. If non-zero, the
ethernet tag ID will be displayed as part of the route key.
Check that the VNI field in show bgp evpn detail matches the expected VNI for the L2
network or L3 VRF.
(L2 only) If the peer is multi-homing, ensure that the Ethernet Segment Identifier (ESI)
shown in show bgp evpn route-type mac-ip detail is present in an auto-discovery per
ES route from the same peer, and that the A-D per ES route’s route target is imported by
the VLAN. Also ensure that an auto-discovery per EVI route is present with the ethernet
tag ID field set to zero.

Unavailable or unexpected best path

If a route is shown but not valid, check that the nexthop is reachable in the underlay
network.
Note that every peer should have a different route distinguisher for a given VLAN or
VRF, and each EVPN route with a different route distinguisher is considered unique.
Therefore, for example, if there is a MAC mobility event and two VTEPs are advertising
the same MAC address simultaneously, both will appear to be “best” in show bgp evpn.
In this case, the sequence number attached to the route is used to decide which
destination will actually be installed.

15/16
Limitations
In EOS 4.18.1F:

The VLAN bundle service interface (RFC7432 section 6.2 [1]) is not supported.
Originating EVPN multi-homing routes (type 1, type 2 with non-zero ethernet segment) is
not supported. For an equivalent effect, use MLAG.
Layer 2 ECMP groups used in all-active multi-homing have a maximum size of two
destination VTEPs.
Only type 5 routes using the gateway IP address as the overlay index, not the ethernet
segment ID, are supported.
Multi-homing functions for type 5 routes are not supported when using MLAG and
shared anycast VTEP.
No IGP (OSPF, ISIS) support.
No route server functionality.
Some BGP features available in GateD cannot be used in conjunction with EVPN.
Internetworking with CVX is unavailable.
Support in vEOS is unavailable.
DCS-7280R and DCS-7500R support up to 96K MAC addresses.
DCS-7280R and DCS-7500R do not support layer 2 ECMP.

Resources
[1] RFC7432 – BGP MPLS-Based Ethernet VPN
[2] draft-ietf-bess-evpn-overlay – A Network Virtualization Overlay Solution using EVPN
[3] draft-ietf-bess-evpn-prefix-advertisement – IP Prefix Advertisement in EVPN

16/16