In a BGP EVPN VXLAN fabric, route leaking is used to selectively allow communication between otherwise isolated Tenant VRFs. This is typically implemented on a Border Leaf (BL) or a dedicated Service Leaf. Here is an example topology explaining how VRF-Tenant-A communicates with VRF-Shared-Services. Example Topology: Route Leaking We have three main components: 1.Leaf 1 & Leaf 2: Host VTEPs where Tenant A's end devices connect (e.g., 10.1.1.0/24). They have VRF-Tenant-A. 2.Service Leaf (SL): A dedicated VTEP where Shared Services (e.g., a DNS server 10.0.0.10) connect. It has VRF-Shared-Services. 3.Border Leaf (BL): Connects the VXLAN fabric to the external world and usually manages the route leaking process. The Configuration and Process The communication is controlled using Route Targets (RTs) within BGP EVPN extended communities. Each VRF has unique Import RTs and Export RTs. Initial State (Isolation) VRF-Tenant-A: Export RT: 65000:100 Import RT: 65000:100 VRF-Shared-Service...

  r1-r2-r3 running ospf.. when link between r1-r2 brought down.. what are the sequence? how long it take to converge, how/when the routes will be removed from RIB, how LSA invalidate propagated to R3 When the link between R1 and R2 is administratively brought down, a precise sequence of events ensures the network converges to a new, loop-free topology. Assuming standard OSPF default timers (40-second Dead timer) and no advanced features like BFD or FRR: Sequence of Events Step Action Router Affected Timeframe 1 Interface Down Detected R1 & R2 Immediate 2 Hello Timers Expire R1, R2, and all neighbors 40 seconds (Default) 3 LSA Flush Generated R1 & R2 (Originators) Immediate upon detection (Step 1 or 2) 4 LSA Invalidation Flood R1, R2 -> R3 Sub-second propagation 5 SPF Recalculation R3, and all routers Milliseconds after flood 6 RIB Update R3, and all routers Milliseconds after SPF Detailed Breakdown 1. Interface Brought Down & RIB Removal (Immediate) R1  and...

 Draining Scenarios A. Draining a Leaf Switch (Most common) 1. Reduce local-pref on EVPN routes 2. Check that MAC/IP routes from this leaf are not being used 3. Ensure all flows use other VTEPs 4. Then safely disconnect leaf from fabric B. Draining a Spine Lower underlay cost ECMP routes move to other spines IP reachability shifts fast (typically <50ms) No EVPN changes required. C. Draining a VTEP for a specific VLAN Withdraw MAC/IP routes for that VLAN Gateway anycast moves traffic to other leaf ⭐ Summary (Very Simple) Draining Level How When Used Underlay Higher metric, OSPF/ISIS/BGP preference Spine/leaf upgrade EVPN Control Plane Lower local-pref for Type-2/5 Leaf maintenance L2/MAC Withdrawal Stop advertising MAC/IP routes Drain specific VLAN/server Anycast Gateway Shift Move SVI or ARP/ND Host/VM migration

Fabric Type BGP + BFD Settings Convergence (Leaf ↔ Spine) Notes Cisco Nexus 9K (NX-OS 10.2) BFD 50/150 ms ~60–80 ms BGP PIC-core enabled Arista 7050X3 (EOS 4.30) BFD 50/150 ms ~40 ms With ECMP and FRR active SONiC + FRR (Tomahawk3) BFD 50/150 ms ~70 ms Depends on SAI FIB update latency Juniper QFX EVPN BFD 10/30 ms ~30 ms Very aggressive tuning Multi-VTEP scale (≥64 VTEPs) BFD 50/150 ms ~100–150 ms RR propagation delay dominates Stage Description Typical Time 1. Failure Detection BFD or link-down event triggers 3–50 ms (depending on BFD interval) 2. Control Plane Reaction BGP withdraw/advertise new paths 10–100 ms 3. Route Reflector Processing (if used) Reflector recomputes and re-advertises EVPN routes 10–50 ms 4. FIB Update (Hardware) ASIC reprograms next-hops, tunnels, MAC/IP bindings 1–10 ms ➡️ Total 30–200 ms typical , depending on tuning   Scenario Failure Detection Total Convergence Comments ...

Inbound path  Neighbor →  IN policy  ->  RIB-IN → best-path-selection→ LOC-RIB → Routing Table Outbound path  LOC-RIB → OUT policy->Update-generation ->  RIB-OUT(per neighbor)  → Neighbor 1.Attributes Optional = may or may not exist Non-Transitive = “don’t carry forward if you don’t understand” Real Example MED (Multi Exit Discriminator) → Optional Non-Transitive If a router doesn’t support MED: It gets removed at that hop (old routers may not support MED,RR) ** origin attributes carried on BGP updates (i,? info) ** MED is compared when routes coming from same AS by default. we can override by 'always compare MED' option iBGP & eBGP what attributes will change R1------ eBGP -------R2-------- iBGP ---------R3 From eBGP → iBGP, R2 sends the following attributes to R3: AS_PATH → unchanged  (note:-if a route originates within AS. then its EMPTY) NEXT_HOP → unchanged (R1’s IP) LOCAL_PREF → added by R2 ORIGIN → carried MED → ...