BGP-EVPN-VXLAN Route leaking

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-Services:

Export RT: 65000:200

Import RT: 65000:200

Routes originating in Tenant A are advertised with RT 65000:100. Routes originating in Shared Services are advertised with RT 65000:200. Since neither VRF imports the other's RT, they remain isolated.

The Route Leaking Configuration (on the Border/Service Leaf)

To allow Tenant A to reach the Shared Services, we configure the Border Leaf to "leak" the specific services prefix (10.0.0.0/24) from the Shared Services VRF into the Tenant A VRF:

1.Configure VRF-Shared-Services to export a specific route with a special "leak" RT.

2.Configure VRF-Tenant-A to import that special "leak" RT.

Example Configuration (Conceptual):

# On the Border/Service Leaf configuration

router vrf VRF-Shared-Services

 export route-target 65000:200

 ! Also export specific routes to the leak RT

 route-target export 65000:999 both map-route 10.0.0.0/24 

router vrf VRF-Tenant-A

 export route-target 65000:100

 import route-target 65000:100

 ! Import the leaked routes

 route-target import 65000:999 both

 

The Communication Flow

When the Border Leaf receives the prefix 10.0.0.0/24 from the Shared Services environment (carrying RT 65000:200), it imports it into VRF-Shared-Services.

Because of the new configuration, the BL then re-advertises the 10.0.0.0/24 prefix into the BGP EVPN control plane again, but this time it attaches the new Export RT 65000:999.

1.Tenant A Host Request: A host in Tenant A wants to reach the DNS server at 10.0.0.10.

2.Tenant A Leaf Receives Update: Leaf 1 (Tenant A VTEP) receives the BGP EVPN update for 10.0.0.0/24 with RT 65000:999.

3.Import Action: Leaf 1 checks its import policies for VRF-Tenant-A and finds that it is configured to import routes with RT 65000:999.

4.RIB Entry: Leaf 1 installs the route 10.0.0.0/24 into VRF-Tenant-A's routing table, pointing the next hop toward the Service Leaf/Border Leaf.

5.Traffic Forwarding: The traffic is now successfully routed through the fabric because the Tenant A VRF now has a valid path to the Shared Services subnet.

shared vrf has to be present on all VTEPs.. or suscriber vrf at borderleaf should be fine ?

In a typical EVPN VXLAN design where you use a central Border Leaf (BL) or Service Leaf for route leaking, the shared services VRF does not need to be present on every single VTEP.

The architecture is typically deployed as follows:

The Optimal Design: Border Leaf/Service Leaf Leak

The most scalable and common design only requires the shared VRF to be present on the VTEPs (Leaf switches) that actually need to host those shared services physically or perform the leaking function:

Service Leaf/Border Leaf VTEPs: Must have the VRF-Shared-Services configured, as this is where the services are physically connected or where the routing decision happens to send traffic North/South.

Tenant Access VTEPs (Edge Leaves): Only need the specific VRF-Tenant-A, VRF-Tenant-B, etc., that they are locally hosting.

How It Works:

Tenant VTEPs learn the Shared Prefix: The Tenant Access VTEPs don't have the entire shared services VRF instance; they just import the specific leaked routes (e.g., 10.0.0.0/24 with RT 65000:999) into their local tenant VRF's RIB.

Next-Hop Points to the Border Leaf: The next-hop for that shared services subnet points to the IP address of the Border Leaf VTEP.

Traffic is Tunneled to the BL: When a tenant device sends traffic, its local VTEP VXLAN tunnels the packet directly to the Border Leaf/Service Leaf VTEP, which then handles the final routing within the actual VRF-Shared-Services.

Why this is better:

Scalability: You don't waste resources (memory, CPU) by configuring numerous VRFs on VTEPs that don't need them.

Simplicity: It simplifies configuration management.

Security: It centralizes the control point for inter-VRF communication at the Border/Service Leaf, making security policies (like firewalls) easier to manage.

In summary: The "subscriber VRF" (the tenant VRF) must be present on the Border Leaf in order to receive the leaked route, but the "shared VRF" only needs to exist where it's needed in the topology—usually just on the Service/Border Leafs.