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.

Leaked routes once configured on a device can be distributed to neighboring devices through either BGP or OSPF. If a leaked route is a BGP route then it will be dynamically replicated from source to destination VRF by BGP. If the route to be leaked is a non-BGP route, then that route first needs to be redistributed into BGP before it can be leaked to the destination VRF.

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

Directly connected subnets or hosts are not allowed to be leaked from one VRF into another. In Figure 1, for example, subnet 40.92.0.0/24 in VRF 2 cannot be leaked into VRF 1 on R1.
On R3 switch, all routes in VRF2 can be leaked into VRF1 by configuring route leaking on R1 except the subnets directly connected with R1, for example in this case, subnet 40.92.0.0/24 cannot be leaked into VRF1.
Overlapping addresses in two VRFs are not allowed when enabling route leaking between these two VRFs. It is thus strongly recommended to use non-overlapping addresses in different VRFs before implementing route leaking.
VRF route leaking doesn't work in case of VXLAN routing. The routes cannot be leaked to a VRF corresponding to an VXLAN instance.
The configuration of route leaking by importing BGP IPv4 routes from one user-defined VRF into another user-defined VRF, for example:

set protocols bgp vrf vrf1 local-as 1
set protocols bgp vrf vrf1 ipv4-unicast import vrf vrf2
set protocols bgp vrf vrf2 local-as 2
This will cause configuration from PICOS CLI is not consistent with FRR configuration. Specifically, FRR will add "set protocols bgp local-as 1" (local as number is same as the value in vrf1) to its configuration automatically, which is not in PICOS CLI. From version 4.4.0, if "set protocols bgp local-as 1" is not configured, the above configurations are not allowed.

Browser not supported