mac address learning on the local interface of a VTEP is flow-based learning. However once the mac addresses are learned locally, they are advertised to BGP peers within the EVI via an EVPN route update. The next hop of the update is set to IP of the advertising VTEP. In the case of EVPN VXLAN the advertised label in the update is the VNI, which identifies the mac-VRF in the case of a VLAN Based service, or the EVI for a VLAN aware bundle service.

The route advertisements are EVPN type-2 routes, which can advertise just the mac address of the host, or optionally the mac and IP address of the host. The format of the type-2 route is illustrated in the figure below, along with the mandatory, and optional extended community attached to the route.

The mac mobility extended community, as discussed in the following section is used during mac moves to update all VTEPs of the new location of the host.

address Resolution Protocol (ARP) suppression can be supported on the remote VTEPs, providing the option to advertise the mac and IP binding in the type-2 route. The mac to IP binding can be learned locally via ARP snooping or DHCP traffic on the VTEP. Once the mac and IP binding has been learned, it is advertised to the remote VTEPs as a type-2 route. This allows remote VTEPs to respond to any ARP requests for the host locally, thus reducing the amount of ARP traffic across the EVI.

Importantly, the optional mac and IP route can be advertised separately from the mac-only type-2 route. This is done so that if the mac and IP route is cleared, i.e. ARP flushed, or the ARP timeout is set to less than the mac timeout, then the mac-only route will still exist.

A common scenario in a data center environment is Virtual machines (VMs) moving between physical servers, for maintenance or performance reasons. This will result in the mac of the VM being learned and advertised by a new VTEP.

To cater to this situation, a sequence number is attached to the new mac advertisement, ensuring an EVI wide refresh of the mac table, with VTEPs updating their forwarding tables to point to the advertising VTEP as the new next-hop for mac address.

When a mac address is learned and advertised for the first time, it is advertised without a sequence number and the receiving VTEP assume the sequence to be zero. On detection of a mac move, such as a mac is learned locally when the same mac route is active via a type-2 advertisement, then the sequence number is incremented by one, and the mac route is advertised to the remote peers. The original advertising VTEP, receives the mac route with a now higher sequence number and withdraws its own local mac route. All other VTEPs flush the original mac route, and update their tables with the new higher sequence number route.

In addition to mac mobility, EVPN defines a protection mechanism to detect and prevent mac routes from flapping between VTEPs, which can occur during network instability or when hosts have been misconfigured with the same (duplicate) mac address.

When advertising a locally learned mac, the VTEP will start a M-second counter (default is 180s), if the VTEP detects N mac moves (default is 5) for the route within the M-second window, it will generate a syslog message and stops sending and processing any further updates for the route.

Broadcast, Unknown unicast and Multicast (BUM) traffic is handled within the EVPN forwarding model using ingress replication. Where the BUM frame is replicated on the ingress VTEP to each of the remote VTEPs in the associated EVI/VNI. The VTEP replication list for the EVI, is dynamically populated based on Type-3 route advertisements (Inclusive Multicast Ethernet Tag Route), where VTEPs advertise type-3 routes for each EVI they are members.

The format of the type-3 route is illustrated below.