Service Manual

Route Leaking VRFs
Static routes can be used to redistribute routes between non-default to default/non-default VRF and vice-versa.
You can congure route leaking between two VRFs using the following command: ip route vrf x.x.x.x s.s.s.s
nh.nh.nh.nh vrf default.
This command indicates that packets that are destined to x.x.x.x/s.s.s.s are reachable through nh.nh.nh.nh in the default
VRF table. Meaning, the routes to x.x.x.x/s.s.s.s are leaked from the default VRF routing table into the non-default VRF
routing table.
The following example illustrates how route leaking between two VRFs can be performed:
interface GigabitEthernet 1/9
ip vrf forwarding VRF1
ip address 120.0.0.1/24
interface GigabitEthernet 1/10
ip vrf forwarding VRF2
ip address 140.0.0.1/24
ip route vrf VRF1 20.0.0.0/16 140.0.0.2 vrf VRF2
ip route vrf VRF2 40.0.0.0/16 120.0.0.2 vrf VRF1
Dynamic Route Leaking
Route Leaking is a powerful feature that enables communication between isolated (virtual) routing domains by segregating and
sharing a set of services such as VOIP, Video, and so on that are available on one routing domain with other virtual domains. Inter-
VRF Route Leaking enables a VRF to leak or export routes that are present in its RTM to one or more VRFs.
Previous FTOS releases support static route leaking, which enables route leaking through static commands. Dynamic Route Leaking,
introduced in the 9.7(0.0) release, enables a source VRF to share both its connected routes as well as dynamically learnt routes from
various protocols, such as ISIS, OSPF, BGP, and so on, with other default or non-default VRFs.
You can also leak global routes to be made available to VRFs. As the global RTM usually contains a large pool of routes, when the
destination VRF imports global routes, these routes will be duplicated into the VRF's RTM. As a result, it is mandatory to use route-
maps to lter out leaked routes while sharing global routes with VRFs.
Conguring Route Leaking without Filtering Criteria
You can use the ip route-export tag command to export all the IPv4 routes corresponding to a source VRF. For leaking IPv6
routes, use the ipv6 route-export tag command. This action exposes source VRF's routes (IPv4 or IPv6 depending on the
command that you use) to various other VRFs. The destinations or target VRFs then import these IPv4 or IPv6 routes using the ip
route-import tag or the ipv6 route-import tag command respectively.
NOTE: In Dell Networking OS, you can congure at most one route-export per VRF as only one set of routes can be
exposed for leaking. However, you can congure multiple route-import targets because a VRF can accept routes from
multiple VRFs.
After the target VRF learns routes that are leaked by the source VRF, the source VRF in turn can leak the export target
corresponding to the destination VRFs that have imported its routes. The source VRF learns the export target corresponding to the
destinations VRF using the ip route-import tag or ipv6 route-import tag command. This mechanism enables reverse
communication between destination VRF and the source VRF.
If the target VRF contains the same prex (either sourced or Leaked route from some other VRF), then the Leak for that particular
prex will fail and an error-log will be thrown. Manual intervention is required to clear the unneeded prexes. The source route will
take priority over the leaked route and the leaked route is deleted.
Consider a scenario where you have created four VRF tables VRF-red, VRF-blue, VRF-Green, and VRF-shared. The VRF-shared
table belongs to a particular service that should be made available only to VRF-Red and VRF-Blue but not VRF-Green. For this
Virtual Routing and Forwarding (VRF)
859