API Guide

When you enable IRB for a virtual network/EVI, EVPN operation on each VTEP also advertises the local tenant IP-MAC bindings
learned on the EVPN-enabled virtual networks to all other VTEPs. The local tenant IP-MAC bindings are learned from ARP or
ICMPv6 protocol operation. They advertise as EVPN Type-2 BGP route updates to other VTEPs, each of whom then imports
and installs them as ARP/IPv6 neighbor entries in the dataplane.
To enable efficient traffic forwarding on a VTEP, OS10 supports distributed gateway routing. A distributed gateway allows
multiple VTEPs to act as the gateway router for a tenant subnet. The VTEP that is located nearest to a host acts as its gateway
router.
To enable L3 gateway/IRB functionality for BGP EVPN, configure a VXLAN overlay network and enable routing on a switch:
1. Create a non-default VRF instance for overlay routing. For multi-tenancy, create a VRF instance for each tenant.
2. Configure globally the anycast gateway MAC address used by all VTEPs.
3. Configure a virtual-network interface for each virtual network, (optional) assign it to the tenant VRF, and configure an IP
address. Then enable the interface.
4. Configure an anycast gateway IP address for each virtual network. OS10 supports distributed gateway routing.
EVPN supports different types of IRB routing for tenants, VMs, and servers, that connect to each VTEP:
● Centralized routing: For each tenant subnet, one VTEP is designated as the L3 gateway to perform IRB inter-subnet routing.
All other VTEPs perform L2 bridging.
● Distributed routing: For each tenant subnet, all VTEPs perform L3 gateway routing for the tenant VMs and servers
connected to a VTEP. In a large multi-tenant network, distributed routing allows for more efficient bandwidth use and traffic
forwarding. IRB routing is performed either:
○ Only on an ingress VTEP.
○ On both ingress and egress VTEPs.
Asymmetric IRB routing
In asymmetric IRB routing, IRB routing is performed only on ingress VTEPs. Egress VTEPs perform L2 bridging in the tenant
subnet.
An ingress VTEP directly routes packets to a destination host MAC address in the destination virtual-network VNI. An egress
VTEP only bridges packets to a host by removing the VXLAN header and forwarding a packet to the local Layer 2 domain using
the VNI-to-VLAN mapping.
The ingress VTEP is configured with all destination virtual networks, and has the ARP entries and MAC addresses for all
destination hosts in its hardware tables. Each VTEP learns the host MAC and MAC-to-IP bindings using ARP snooping for local
addresses and type-2 route advertisements from remote VTEPs.
For VXLAN BGP EVPN examples that use asymmetric IRB, see Example: VXLAN with BGP EVPN and Example: VXLAN BGP
EVPN — Multiple AS topology.
BGP EVPN with VLT
OS10 supports BGP EVPN operation between VLT peers that you configure as VTEPs. For more information about
configurations and best practices to set up VLT for VXLAN, see Configure VXLAN — Configure VLT. This information also
applies to BGP EVPN for VXLAN.
Dell EMC recommends configuring iBGP peering for the IPv4 address family between the VTEPs in a VLT pair on a dedicated L3
VLAN that is used when connectivity to the underlay L3 network is lost. It is NOT required to enable the EVPN address family
on the iBGP peering session between the VTEPs in a VLT pair because EVPN peering to the spine switch is performed on
Loopback interfaces.
Both VTEPs in a VLT pair advertise identical EVPN routes, which provides redundancy if one of the VTEP peers fails. To set up
redundant EVPN route advertisement, configure the same EVI, RD, and RT values for each VNI on both VTEPs in a VLT pair,
including:
● In auto-EVI mode, this identical configuration is automatically ensured if the VNID-to-VNI association is the same on both
VTEP peers.
● In manual EVI mode, you must configure the same EVI-to-VNID association on both VTEP peers.
● In manual EVI mode, you must configure the same RD and RT values on both VTEP peers.
In an EVPN configuration, increase the VLT delay-restore timer to allow for BGP EVPN adjacency to establish and for the
remote MAC and neighbor entries to download by EVPN and install in the dataplane. The VLT delay-restore determines the
amount of time the VLT LAGs are kept operationally down at bootup to allow the dataplane to set up and forward traffic,
resulting in minimal traffic loss as the VLT peer node boots up and joins the VLT domain.
930
VXLAN