Traffic Flow Unicast Forwarding (Bridging)

Traffic Flow Unicast Forwarding (Bridging)

Posted on Jan 09, 2020 (0)

Traffic Flow Unicast Forwarding (Bridging)

This Section explains how unicast traffic forwarding is done in when source and destination are in same subnet. VTEPs V1 and V3 are associated with NVE interfaces with IP addresses and respectively.

Below topology is used for explanation.

When we are running BGP-EVPN , then as soon as local end points are learned  on local switch , the respective MAC address is proactively distributed during BGP updates to all neighboring VTEPs. Following is the information that BGP-EVPN protocol would have.

We can verify this able table information by following ways:

To verify that the MAC address or MAC/IP prefix (Route type 2) has been received, This information is installed in an EVPN instance, which is also called a MAC VRF.

Once the Layer 2 “routing” table has been verified with the appropriate MAC prefixes, our next step is to ensure that similar entries should be present in the MAC address table at the VTEP itself, as shown in below figure

Now Control plane is populated, let take an example that Host A ( connected to VTEP 1 want to communicate with host C connected to VTEP 2 and both host are in same VNI 20001.

As both Host C and Host A belongs to the same IP subnet, Host A tries to resolve the IP-to-MAC mapping of Host C by first looking up its local ARP cache. If this process results in a miss, Host A initiates an ARP request. The broadcast ARP request is forwarded in VLAN 10, and the request enters the ingress VTEP V1. The MAC address of Host A is learned at VTEP V1 via regular MAC learning, and this information is populated over BGP EVPN to the VTEPs V2 and V3, respectively.

Case 1: With ARP Supersession Disabled:

 With ARP suppression disabled for VNI 20001 at VTEP V1, the ARP request from endpoint Host A is handled as BUM traffic, which is further encapsulated with Layer 2 VNI 20001, and then forwarded as a multi destination packet. The multi destination traffic can be replicated with multicast or with ingress replication to all VTEPs joining the same multi destination tree. This occurs by using either a multicast group or the ingress replication distribution list. All the egress VTEPs receive the broadcast packet and decapsulate and forward the ARP request toward their local Ethernet interfaces participating in VNI 20001 and subsequently traffic is sent out of the appropriate member classic Ethernet ports encapsulated with the dot1q tag 10. When Host C receives the ARP request, it responds with an ARP reply (unicast), as shown in below fig:

Case 2: With ARP Supersession Enabled:

If ARP suppression is enabled on VNI 20001, the initial ARP request from Host A for Host C received at VTEP V1 is subjected to ARP snooping. Consequently, in addition to the MAC address, the IP address of Host A is also populated in the BGP EVPN control plane via Route type 2 messages and a unicast ARP response is generated locally by VTEP V1 and returned to endpoint Host A for Host C only if Host C is known by BGP EVPN control plane. This results in early ARP termination. Because the broadcast ARP request never reached Host C and when Host A send data traffic to Host C , Host C will generate the ARP request for Host A which in turn VTEP 3 will reply to ARP request on behalf of Host A.

Data Traffic from Host A to Host C

Host A generates data traffic with a SMAC of 0000.3100.1001 and source IP of The destination MAC 0000.3100.1003 and IP, respectively. Once the packet is received at VTEP V1, a destination lookup is performed, for VNI 20001 and 0000.3100.1003 and if the lookup is hit then the packet is sent to VTEP V3.

Once packet is received on V3, VTEP V3 will decaptulate the packet and is send to corresponding host after seeing the MAC address table.


    You are will be the first.


Please login here to comment.