You are here
Home > Topics > Routing

L3VPN: Route Leak

Now that we have covered many examples of L3VPN and for different customer deployments, I think this is a good point where we introduce the concept of Route Leaking.

Notice in our DIAGRAMonly sites that belong to the same customer could reach each other and this is of course the required end result. But let assume for whatever reason we needed to change this behavior, now Customer C needs to reach Customer D and vice versa. This means, all four sites need to have full connectivity among each other. Simply put, we will need to leak Customer C’s VRF routes into Customer D’s VRF route table and vice versa. As always, things will get clearer with configuring this part:

Just to confirm, at this point, I have everything configured as we left it off from the previous examples. R20 can reach R18 but not R17. R19 can reach R17 but not R19 which how it should be the case so far:

Now what I’m going to do is importing what vrf CUSTC100 is exporting into vrf CUSTD100. And importing what vrf CUSTD100 is exporting into vrf CUSTC100. This is done on the PE facing these customers, R8. I highlighted the new commands added here.

R8:
ip vrf CUSTC100
rd 300:30
route-target export 300:30
route-target import 300:30
route-target import 400:40
!
ip vrf CUSTD100
rd 400:40
route-target export 400:40
route-target import 400:40
route-target import 300:30
!

I’ll the the same thing on the other end on R13.

R13:
ip vrf CUSTC222
rd 333:33
route-target export 333:33
route-target import 333:33
route-target import 444:44
!
ip vrf CUSTD222
rd 444:44
route-target export 444:44
route-target import 444:44
route-target import 333:33
!

Now, let’s see how does the VRF routing tables look like on R8:

As expected, both VRF routing tables show all four networks. We should see the same results on R13:

And sure enough, connectivity is now confirmed between both customers:

Leave a Reply

Top