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 on R2 in VRF1, to ping loopback interface on R3 in VRF2, R1 device will need two routes in both VRF1 and VRF2. On R1, the route to reach in VRF2 is next-hop Similarly, to reach the route in VRF2 will be next-hop next-hop vrf vrf1. VRF2 does not have a route for loopback in VRF2 hence apart from specifying the next-hop address of, 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, next-hop and next-hop 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