Virtual Routing and Forwarding (VRF) Lite is a technology used to achieve routing separation in IP networks without MPLS support. VRF Lite allows multiple virtual routing tables to coexist on a single router, providing logical isolation between different network segments or customers. However, by default, these VRF instances are isolated from each other and the global routing table. To enable communication between VRFs and the global table, route leaking is essential. This report explores the concept of VRF Lite and the significance of route leaking and provides CLI examples to demonstrate the configuration.
Understanding VRF Lite and Route Leaking
VRF Lite vs. Full VRF with MPLS Support:
- VRF Lite refers to VRF functionality without MPLS support, often used on Customer Edge (CE) routers.
- Full VRF with MPLS support is typically implemented on Provider Edge (PE) routers, enabling more advanced overlay capabilities.
Global Routing Table and VRF Lite’s Global Table:
- In VRF Lite, the main or default routing table is referred to as the
global routing table
orDefault VRF
associated with the router itself. - Each VRF has its own separate routing and forwarding table, isolated from other VRFs and the global table.
Importance of Route Leaking:
- Route leaking enables communication between VRFs and the global table, as well as between different VRF instances.
- It allows selective sharing of routes between VRFs to establish connectivity.
Route Leaking Configuration Example (Redistribute Connected)
This section provides a step-by-step CLI configuration example for route leaking between two VRFs (VRF-A and VRF-B) and the global routing table using redistribute connected
.
ip vrf VRF-A rd 100:1 route-target export 100:1 route-target import 100:1 ! ip vrf VRF-B rd 100:2 route-target export 100:2 route-target import 100:2 ! interface GigabitEthernet0/0 ip vrf forwarding VRF-A ip address 10.1.1.1 255.255.255.0 ! interface GigabitEthernet0/1 ip vrf forwarding VRF-B ip address 192.168.10.1 255.255.255.0 ! router bgp 100 address-family ipv4 vrf VRF-A redistribute connected exit-address-family ! address-family ipv4 vrf VRF-B redistribute connected exit-address-family ! route-map LEAK-A-to-B permit 10 match ip address prefix-list LEAK-A-PREFIXES ! route-map LEAK-B-to-A permit 10 match ip address prefix-list LEAK-B-PREFIXES ! ip prefix-list LEAK-A-PREFIXES seq 5 permit 10.1.1.0/24 ip prefix-list LEAK-B-PREFIXES seq 5 permit 192.168.10.0/24 ! router bgp 100 address-family ipv4 vrf VRF-A redistribute connected route-map LEAK-B-to-A exit-address-family ! address-family ipv4 vrf VRF-B redistribute connected route-map LEAK-A-to-B exit-address-family
Differences between “redistribute connected” and “redistribute static”
The configuration example provided uses redistribute connected
for route leaking between VRFs. However, it is also possible to use redistribute static
for this purpose. Here are the differences between the two:
Redistribute Connected:
- Leaks routes for subnets directly connected to VRF interfaces.
- Happens automatically as soon as interfaces are configured in the VRF.
- No need for additional static routes.
- Provides limited control as all connected subnets are leaked.
Redistribute Static:
- Leaks specifically configured static routes pointing to VRF subnets.
- Requires manually adding static routes for VRF networks.
- Offers more flexible control using route-maps to filter leaked routes.
- Can leak routes not directly connected to an interface.
Route Leaking Configuration Example (Redistribute Static)
Here, we provide a CLI configuration example for route leaking using redistribute static
instead of redistribute connected
.
ip route vrf VRF-A 10.1.1.0 255.255.255.0 192.168.1.1 ip route vrf VRF-B 172.16.10.0 255.255.255.0 198.51.100.1 route-map LEAK-VRF-A permit 10 match ip address prefix-list FILTER-VRF-A ! route-map LEAK-VRF-B permit 10 match ip address prefix-list FILTER-VRF-B ip prefix-list FILTER-VRF-A seq 5 permit 10.1.1.0/24 ip prefix-list FILTER-VRF-B seq 5 permit 172.16.10.0/24 router bgp 100 address-family ipv4 vrf VRF-A redistribute static route-map LEAK-VRF-A exit-address-family ! address-family ipv4 vrf VRF-B redistribute static route-map LEAK-VRF-B exit-address-family
One-Way VRF Configuration Example
If you want to allow only VRF-A to access or route through VRF-B, but not vice versa, you can use the following CLI configuration example:
ip vrf VRF-A rd 100:1 route-target export 100:1 route-target import 100:1 ! ip vrf VRF-B rd 100:2 route-target export 100:2 route-target import 100:2 ! interface GigabitEthernet0/0 ip vrf forwarding VRF-A ip address 10.1.1.1 255.255.255.0 ! interface GigabitEthernet0/1 ip vrf forwarding VRF-B ip address 192.168.10.1 255.255.255.0 ! ip prefix-list LEAK-B-PREFIXES seq 5 permit 192.168.10.0/24 ! route-map LEAK-B-to-A permit 10 match ip address prefix-list LEAK-B-PREFIXES ! router bgp 100 address-family ipv4 vrf VRF-A redistribute connected route-map LEAK-B-to-A exit-address-family ! address-family ipv4 vrf VRF-B redistribute connected exit-address-family
Verifying Route Leaking
To ensure the success of route leaking, you can use the following commands to verify the presence of leaked routes:
show ip route vrf VRF-A
: Displays the routing table for VRF-A, showing imported routes from VRF-B.
show ip route vrf VRF-B
: Displays the routing table for VRF-B, showing imported routes from VRF-A.
show ip route
: Shows the global routing table, indicating the presence of leaked routes from both VRF-A and VRF-B.
show ip cef vrf VRF-A
: Shows the CEF table for VRF-A, confirming the presence of VRF-B prefixes.
show ip cef vrf VRF-B
: Shows the CEF table for VRF-B, confirming the presence of VRF-A prefixes.
Conclusion:
VRF Lite provides a powerful way to achieve routing separation, but enabling communication between VRFs and the global table is essential for building interconnected networks. Route leaking, achieved through BGP and route maps, allows selective sharing of routes between VRFs, facilitating seamless communication across isolated network segments. Network engineers can harness the full potential by implementing route leaking best practices.