Easy Virtual Network (EVN) was a technology Cisco came up with back in the days to make it easier to implement VRFs without the pain of running VRF lite or the complexity of running a full MPLS + BGP network. It was actually a pretty cool technology but never became mainstream. However, as part of this technology, Cisco also made it easier to replicate, or in other words leak, routes between VRFs. You don’t need the rest of EVN to do this and this simplified way of replicating routes have kind of been forgotten by the industry. I thought I would share with you the ease of replicating routes with this feature even without BGP.
We have a straight forward topology like the one below:
The USERS switch is a L2 switch and all the L3 configuration is in the CORE router. We have implemented segmentation in the network so we have a USERS VRF and then we have a SERVICES VRF for shared services such as DNS and DHCP. Because these services are in a separate VRF, we will not have reachability to them from the USERS VRF. This lab will use the following IP addresses:
User – 10.0.0.10
DNS – 172.16.0.10
DHCP – 172.16.0.20
The Core has a very basic configuration for now:
CORE#sh run vrf USERS
Building configuration...
Current configuration : 209 bytes
vrf definition USERS
!
address-family ipv4
exit-address-family
!
!
interface GigabitEthernet2
vrf forwarding USERS
ip address 10.0.0.1 255.255.255.0
negotiation auto
no mop enabled
no mop sysid
!
end
CORE#sh run vrf SERVICES
Building configuration...
Current configuration : 299 bytes
vrf definition SERVICES
!
address-family ipv4
exit-address-family
!
!
interface GigabitEthernet1
vrf forwarding SERVICES
ip address 192.168.0.1 255.255.255.0
ip ospf network point-to-point
ip ospf 1 area 0
negotiation auto
no mop enabled
no mop sysid
!
router ospf 1 vrf SERVICES
!
!
endThe Core is running OSPF towards the SERVICES router to learn the routes for the DHCP server and DNS server. These are really just two loopbacks on the SERVICES router.
The user can reach the CORE but not the servers:
USER:~$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=42 time=3.370 ms
64 bytes from 10.0.0.1: seq=1 ttl=42 time=2.723 ms
64 bytes from 10.0.0.1: seq=2 ttl=42 time=2.962 ms
^C
--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2.723/3.018/3.370 ms
USER:~$ ping 172.16.0.10
PING 172.16.0.10 (172.16.0.10): 56 data bytes
^C
--- 172.16.0.10 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet lossThis is of course expected as the USERS vrf in the CORE does not have any routes for these servers:
CORE#sh ip route vrf USERS
Routing Table: USERS
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet2
L 10.0.0.1/32 is directly connected, GigabitEthernet2We need to get routes from the SERVICES VRF into the USERS VRF. This is where the route-replicate command can help us.
CORE(config)#vrf definition USERS
CORE(config-vrf)#address-family ipv4
CORE(config-vrf-af)#route-replicate from vrf SERVICES unicast ospf 1 Now, let’s take another look at the routing table for VRF USERS:
CORE#show ip route vrf USERS
Routing Table: USERS
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.0.0.0/24 is directly connected, GigabitEthernet2
L 10.0.0.1/32 is directly connected, GigabitEthernet2
172.16.0.0/32 is subnetted, 2 subnets
O + 172.16.0.10
[110/2] via 192.168.0.2 (SERVICES), 00:16:43, GigabitEthernet1
O + 172.16.0.20
[110/2] via 192.168.0.2 (SERVICES), 00:16:26, GigabitEthernet1Notice that we now have routes to 172.16.0.10 and 172.16.0.20 via the VRF SERVICES and the next-hop is 192.168.0.2 which is the IP of the SERVICES router on that interface. The plus sign before the route shows that it is a replicated route. We can also see more details if we check a specific route:
CORE#show ip route vrf USERS 172.16.0.10
Routing Table: USERS
Routing entry for 172.16.0.10/32
Known via "ospf 1", distance 110, metric 2, type intra area,
replicated from topology(SERVICES)
Last update from 192.168.0.2 on GigabitEthernet1, 00:22:00 ago
Routing Descriptor Blocks:
* 192.168.0.2 (SERVICES), from 192.168.0.2, 00:22:00 ago, via GigabitEthernet1
Route metric is 2, traffic share count is 1The other thing that we need to do, and I forgot that at first, is to replicate in the other direction. Otherwise the SERVICES VRF will not have any routes back to the USERS VRF. Let’s configure that:
CORE(config)#vrf definition SERVICES
CORE(config-vrf)#address-family ipv4
CORE(config-vrf-af)#route-replicate from vrf USERS unicast allLet’s see what routes we have now in the VRF:
CORE#show ip route vrf SERVICES
Routing Table: SERVICES
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C + 10.0.0.0/24 is directly connected, GigabitEthernet2
L & 10.0.0.1/32 is directly connected, GigabitEthernet2
172.16.0.0/32 is subnetted, 2 subnets
O 172.16.0.10 [110/2] via 192.168.0.2, 00:24:12, GigabitEthernet1
O 172.16.0.20 [110/2] via 192.168.0.2, 00:23:55, GigabitEthernet1
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/24 is directly connected, GigabitEthernet1
L 192.168.0.1/32 is directly connected, GigabitEthernet1Notice the 10.0.0.0/24 route with a plus sign that says directly connected. We can see more details below:
CORE#show ip route vrf SERVICES 10.0.0.0 255.255.255.0
Routing Table: SERVICES
Routing entry for 10.0.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface),
replicated from topology(USERS)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet2
Route metric is 0, traffic share count is 1That should be all that we need. Hopefully… Can we ping the servers from the user now?
USER:~$ ping 172.16.0.10
PING 172.16.0.10 (172.16.0.10): 56 data bytes
64 bytes from 172.16.0.10: seq=0 ttl=42 time=3.531 ms
64 bytes from 172.16.0.10: seq=1 ttl=42 time=4.678 ms
64 bytes from 172.16.0.10: seq=2 ttl=42 time=4.166 ms
^C
--- 172.16.0.10 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 3.531/4.125/4.678 ms
USER:~$ ping 172.16.0.20
PING 172.16.0.20 (172.16.0.20): 56 data bytes
64 bytes from 172.16.0.20: seq=0 ttl=42 time=3.126 ms
64 bytes from 172.16.0.20: seq=1 ttl=42 time=6.193 ms
64 bytes from 172.16.0.20: seq=2 ttl=42 time=4.053 ms
^C
--- 172.16.0.20 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 3.126/4.457/6.193 msAnd there you have it! We successfully configured route replication, or in another name, route leaking, without having to use BGP! That is pretty powerful. Let me know what you think and see you next time.
Thats so cool! Do you see EVN deployments much in the wild Daniel or is it superseded with the typical MP-BGP deployments?
To be honest I’ve never seen one myself but some people on Twitter mentioned they had used it so it’s not unheard of. Most run VRF lite until it becomes painful and then move onto MPLS + BGP if supported.
Way cool. Iām really glad I happened upon this Blog
Thank you for that.
Thank you for sharing this, a very useful and clear technical demonstration on how to configure this. My thoughts was though on potential use cases for this? Most orgs or networks making use of VRFs are for segmentation purposes. Would it be possible as well to only use the route-replicate command for a single prefix or route advertisement?
Thanks as always for the useful blogs
Hi Nathan!
When you have segmented a network you still need access to other services. Commonly these are services such as DHCP, DNS, network management, Syslog, Active Directory, and so on. You then have to fuse the networks somewhere. This could be a router or perhaps more commonly a firewall.
Some of the designs I have seen are companies that sell some kind of service and have multiple customers coming in on a router. They then need to provide routing towards a shared environment and that’s the perfect scenario for route leaking.
You can filter routes in two ways with the route-replicate command. You can filter from what protocols you want to replicate routes and you can also optionally attach a route-map. Like in the example below:
vrf definition green!
address-family ipv4
route-replicate from vrf blue unicast all route-map blue-map
!
route-map blue-map permit 10
match ip address prefix-list server-prefix
Cool, thank you Daniel!
yes, love to hear your answer on Nathan’s question – Would it be possible as well to only use the route-replicate command for a single prefix or route advertisement? – that would be more practical.
Thans – this is very usefull!
Now if only this worked with global (or if I had the foresight to build everything into VRFs).
It does work with global as well š
Never too late to start doing some more segmentation.