MAC Learning & Advertisement flow

-

 Here is the step-by-step MAC address learning flow in EVPN-VXLAN using a Route Type-2 advertisement. This process leverages a control-plane approach to exchange MAC reachability information, which greatly improves scalability compared to the traditional data-plane flood-and-learn method of classic VXLAN. 

Topology overview
We will use a simple topology with two hosts, Host A and Host B, residing in the same Layer 2 segment (VLAN 10, VNI 10010) but connected to different leaf switches, Leaf 1 and Leaf 2, respectively. 
Key tables involved:
  • Layer 2 MAC Table (Switching table): This is the familiar table that maps a MAC address to a port. In EVPN, entries can point to either a local access port or the VXLAN Network Virtualization Edge (NVE) interface.
  • L2RIB (Layer 2 Routing Information Base): A specialized table on the VTEP that stores Layer 2 routing and reachability information. It acts as an intermediate database, storing locally learned MACs and BGP-advertised MACs before they are installed into the main MAC table. This is often referred to as the MAC-VRF.
  • BGP RIB (Routing Information Base): The central BGP table where all BGP routes (including EVPN routes) are stored.
  • ARP/ND Suppression Table (Proxy ARP/ND): A table that stores MAC-to-IP bindings for hosts in a given segment. It is populated via local snooping and remote EVPN advertisements, allowing the VTEP to answer ARP requests on behalf of remote hosts without flooding. 
Mac address learning flow (Route Type-2)
Step 1: Local MAC address learning (Leaf 1)
  1. Host A sends a packet: Host A sends a data frame (e.g., an ARP or any traffic) destined for Host B.
  2. Leaf 1 performs data-plane learning: When Leaf 1 receives the frame on its local access port, it inspects the source MAC address of the frame (MAC-A).
  3. Populates the Layer 2 MAC Table: Leaf 1 learns that MAC-A is reachable via its access port (e.g., Ethernet 1/1) and adds this entry to its MAC address table.
  4. Populates the L2RIB (MAC-VRF): Leaf 1 then updates the L2RIB for the corresponding VNI (VNI 10010) with the new MAC-A entry. This entry is marked as locally learned. 
Step 2: Advertising the MAC address (Leaf 1)
  1. Generate a BGP EVPN Route Type-2: Based on the new entry in its L2RIB, Leaf 1's BGP process generates a BGP EVPN Route Type-2 (MAC/IP Advertisement route).
  2. Route content: This route contains crucial information:
    • Route Distinguisher (RD): Uniquely identifies the EVPN instance (EVI).
    • MAC Address (MAC-A): The MAC address of Host A.
    • Ethernet Tag ID: Identifies the specific VLAN (10) within the EVI.
    • Next-Hop: The IP address of Leaf 1's VTEP source interface.
    • Route Target (RT): An extended BGP community that controls which VTEPs receive the route.
    • MPLS Label: The L2 VNI (10010).
  3. Advertise to BGP peers: Leaf 1 sends this Route Type-2 advertisement to its BGP peers, typically a route reflector on the spine switches. 
Step 3: Receiving and importing the route (Leaf 2)
  1. Leaf 2 receives the route: Leaf 2 receives the Route Type-2 advertisement from its BGP peer.
  2. Route Target check: Leaf 2 inspects the Route Target (RT) in the advertisement. If the RT matches one of its configured import RTs for the tenant, the route is accepted. If there is no match, the route is discarded.
  3. Populates the BGP RIB: The accepted Route Type-2 is added to Leaf 2's BGP RIB.
  4. Updates the L2RIB (MAC-VRF): Leaf 2's BGP process extracts the MAC-A, next-hop (VTEP IP of Leaf 1), and VNI (10010) information and adds it to its local L2RIB for that tenant. This entry is marked as remotely learned via BGP. 
Step 4: Installing the MAC address (Leaf 2)
  1. Populates the Layer 2 MAC Table: The new entry in the L2RIB triggers an update to Leaf 2's Layer 2 MAC address table. The entry for MAC-A is added, mapping it to the VXLAN NVE interface, with the next-hop pointing to Leaf 1's VTEP IP.
  2. Traffic lookup: From this point on, if Leaf 2 receives a frame destined for MAC-A, it knows exactly where to send the VXLAN-encapsulated traffic without any flooding. 
Tables involved and lookup process
Stage Table InvolvedLookup Action
Local Learning (Leaf 1)L2 MAC TableLook up incoming frame's source MAC address and learn it via the ingress port.
Local Learning (Leaf 1)L2RIB (MAC-VRF)Insert the locally learned MAC-A with its associated VNI and source interface.
Advertisement (Leaf 1)BGP RIBA BGP process polls the L2RIB and generates a Route Type-2.
Import (Leaf 2)BGP RIBReceive the BGP advertisement and check for matching Route Targets.
Import (Leaf 2)L2RIB (MAC-VRF)Insert the remote MAC-A, its source VTEP IP, and VNI.
Forwarding (Leaf 2)L2 MAC TableA packet destined for MAC-A triggers a lookup, which points to the VXLAN tunnel to Leaf 1.
Forwarding (Leaf 2)Forwarding Table (FIB)Look up Leaf 1's VTEP IP address and use the underlay to route the encapsulated packet.
This control-plane learning model is the cornerstone of EVPN, replacing the inefficient flood-and-learn behavior of pure VXLAN with a scalable, BGP-based, and highly resilient system

Comments

Post a Comment

Popular posts from this blog

gNMI_with_grafana on containerlabs

-
Image
  root@digi-oss:/home/labadmin/mohan/2jan26_grafana# cat sr_lab.clab.yml name: sr_lab topology:   nodes:     sr1 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr1.cfg}     sr2 : {kind: nokia_srlinux, image: ghcr.io/nokia/srlinux:latest, startup-config: sr2.cfg}     # gNMIc Collector     gnmic:       kind: linux       image: ghcr.io/openconfig/gnmic:latest       binds: [gnmic-config.yml:/app/gnmic-config.yml:ro]       cmd: "--config /app/gnmic-config.yml subscribe"     # Prometheus TSDB     prometheus:       kind: linux       image: prom/prometheus:latest       binds: [prometheus.yml:/etc/prometheus/prometheus.yml:ro]       ports: ["9090:9090"]     # Grafana Visualization     grafana:       kind: linux       image: grafa...
Read more

EVPN Route type-1 & type-4 in action

-
Image
 Route Type 1: Ethernet Auto-Discovery (A-D) A Type 1 route is advertised by a PE router on a per-Ethernet Segment Identifier (ESI) basis. It is triggered by the presence of a multihomed connection.  Purpose of Type 1 routes Aliasing:  In an all-active multihoming setup, a Type 1 route informs remote PE routers that an Ethernet segment is reachable via multiple PEs. This allows for load-balancing traffic to the same customer device over multiple paths. Fast convergence (Mass MAC Withdrawal):  If a local link to a multihomed customer device fails, the PE sends a withdrawal message for the Type 1 route. Remote PEs can then withdraw all MAC addresses associated with that Ethernet segment, instead of waiting for individual MAC withdrawals, which speeds up convergence. Split-horizon filtering:   The route carries an ESI label to prevent traffic loops in all-active mode. A PE router won't forward broadcast, unknown unicast, and multicast (BUM) traffic back to its sour...
Read more

BGP EVPN TYPE-1 & TYPE-4 in action

-
  🧠 Quick Recap Before Type-4 When an ESI (Ethernet Segment Identifier) is configured on dual-homed leafs: Each leaf advertises: ✅ Type-1 Per-ESI → ESI discovery & mass withdrawal ✅ Type-1 Per-EVI → VLAN (EVI) participation, per-VLAN control Remote VTEPs use these to know who shares the ESI. Now, to decide which leaf forwards BUM traffic (Broadcast, Unknown, Multicast) for each VLAN, they use Type-4 routes . ⚙️ What is a Type-4 Route? Route Type Name Purpose Type-4 Ethernet Segment Route (ES Route) Used for DF election between PEs sharing the same ESI 🔹 Content of Type-4 Route Each PE advertising a shared ESI sends: EVPN Type-4 Route ----------------- - ESI: 0000:0000:0000:0000:000010 - Originating Router’s IP (VTEP IP) - Route Distinguisher - Next Hop: VTEP IP - Extended Communities: - ES-Import RT (derived from ESI) - DF Algorithm (RFC7432 or RFC8584) 🧭 Putting It Together (Flow of Events) Let’s take this topology again: ...
Read more