VRF Route Leaking Configuration

Generally speaking, multiple VRFs maintain separate routing tables that are independent of each other. But there are scenarios where a specific destination is only reachable from a specific VRF. For example, a DHCP server in one VRF can only be accessible to hosts in that VRF. If clients in other VRFs want to access this DHCP server, we need to have a mechanism where we can have a route in one VRF for which the destination next-hop address is located in a different VRF. 

                                                                   Figure 1. VRF Route Leaking Example

As shown in Figure 1, if hosts attached to R1 in VRF1 wants to access resources located in VRF2 and accessible through R3, we will need to enable route leaking between VRF1 and VRF2. From the topology above, R1 has two interfaces, one each in VRF1 and VRF2. For resources in VRF2 to be accessible to hosts in VRF1, routes in VRF2 needs to be leaked into VRF1. 

PICOS 4.1.1 version supports static route leaking only. Which means that we are using the static routing module of PICOS to configure a route leak statically.

Route leaking can be used to reach directly connected hosts in the source VRF as well as reach remote destinations accessible through the source VRF. In Figure 1, the leak will be configured on R1. For the loopback interface 1.1.1.1 on R2 in VRF1, to ping loopback interface 3.3.3.3 on R3 in VRF2, R1 device will need two routes in both VRF1 and VRF2. On R1, the route to reach 3.3.3.3 in VRF2 is 3.3.3.3/32 next-hop 40.92.0.1. Similarly, to reach 1.1.1.1 the route in VRF2 will be 1.1.1.1 next-hop 40.91.0.2 next-hop vrf vrf1. VRF2 does not have a route for loopback 1.1.1.1 in VRF2 hence apart from specifying the next-hop address of 40.91.0.1, the route must also specify the next-hop VRF which in this case is VRF1. Similarly, there are also two routes in VRF1. The two routes in VRF1 on R1 are, 1.1.1.1/32 next-hop 40.91.0.1 and 3.3.3.3/32 next-hop 40.92.0.1 next-hop vrf vrf2.

In PICOS, there is no restriction on leaking routes to and from the default VRF. Routes can be leaked from the default VRF into any user defined VRF and vice versa.

Route Leaking Limitation

• Overlapping addresses in two VRFs is not allowed when enabling route leaking between these two VRFs. It is thus strongly recommended to use non-overlapping addresses in different VRFs.
• Dynamic route leaking using BGP to dynamically distribute leak routes between different VRFs is not yet supported.

• Static Route Leaking Example