Cisco EVN (Easy Virtual Network)

In a previous lesson I explained how we can use VRF lite to create multiple virtual routing tables. EVN (Easy Virtual Network) has some “enhancements” to make configuration and management of VRF lite a bit simpler. Let’s take a look at an example topology:

Cisco EVN Example Topology

In the picture above we have two ISP routers and two customers, one called “Blue” and another one called “Red”. The blue and red lines indicate the VRFs that we use.When we use VRF lite we have to configure sub-interfaces for each VRF on the Gigabit3 interfaces of ISP1 and ISP2. Each sub-interface belongs to a different VRF and uses 802.1Q encapsulation to differentiate the different VRFs.

In a previous lesson I explained how we can use VRF lite to create multiple virtual routing tables. EVN (Easy Virtual Network) has some "enhancements" to make configuration and management of VRF lite a bit simpler. Let's take a look at an example topology: In the picture above we have two ISP router



When you have many VRFs it might be a bit annoying to have many sub-interfaces. To simplify the configuration, EVN uses something called a VNET Trunk:

Cisco EVN VNET Trunk

Instead of using sub-interfaces, we define the interfaces between the two ISP routers as a VNET Trunk. EVN will automatically create sub-interfaces for each VRF for us, I’ll show you this in a bit.

EVN is supported on IOS Version 15.2(4)S3 or later or IOS XE. I use a CSR1000v router for this example.

Let’s take a look at the configuration.

Basic EVN Configuration

We’ll use the topology above for the configuration example. I will start with ISP1 and first I will create two VRFs…one for each customer:

ISP1(config)#vrf definition Blue
ISP1(config-vrf)#vnet tag 10
ISP1(config-vrf)#address-family ipv4
ISP1(config)#vrf definition Red
ISP1(config-vrf)#vnet tag 20
ISP1(config-vrf)#address-family ipv4

The vnet tag command is something new. This identifies the vrf and when our VRF traffic crosses the VNET Trunk, it will use this number as the tag for 802.1Q.  Let’s add the interfaces to the correct VRF:

ISP1(config)#interface GigabitEthernet 1
ISP1(config-if)#vrf forwarding Blue
ISP1(config-if)#ip address 192.168.1.254 255.255.255.0
ISP1(config)#interface GigabitEthernet 2
ISP1(config-if)#vrf forwarding Red
ISP1(config-if)#ip address 192.168.2.254 255.255.255.0

This takes care of the interfaces of the ISP1 router, let’s configure the two customer routers that are connected to the ISP1 router as well:

Blue1(config)#interface FastEthernet 0/0
Blue1(config-if)#ip address 192.168.1.1 255.255.255.0
Red1(config)#interface FastEthernet 0/0
Red1(config-if)#ip address 192.168.2.2 255.255.255

This takes care of the VRF configuration. We’ll do something similar on ISP2:

ISP2(config)#vrf definition Blue
ISP2(config-vrf)#vnet tag 10
ISP2(config-vrf)#address-family ipv4
ISP2(config)#vrf definition Red
ISP2(config-vrf)#vnet tag 20
ISP2(config-vrf)#address-family ipv4
ISP2(config)#interface GigabitEthernet 1
ISP2(config-if)#vrf forwarding Blue
ISP2(config-if)#ip address 192.168.3.254 255.255.255.0

ISP2(config)#interface GigabitEthernet 2
ISP2(config-if)#vrf forwarding Red
ISP2(config-if)#ip address 192.168.4.254 255.255.255.0

And the two customer routers on the right side of ISP2:

Blue2(config)#interface FastEthernet 0/0
Blue2(config-if)#ip address 192.168.3.3 255.255.255.0
Red2(config)#interface FastEthernet 0/0
Red2(config-if)#ip address 192.168.4.4 255.255.255.0

The VRF configuration is now finished with the exception of the trunk in between ISP1 and ISP2. It might be a good idea to verify that the VRFs are working before we continue:

ISP1#show vrf 
  Name                             Default RD            Protocols   Interfaces
  Blue                             <not set>             ipv4        Gi1
  Red                              <not set>             ipv4        Gi2

First we check if the VRFs are available and what interfaces are assigned to them. Let’s see if ISP1 can ping router Blue1 and Red1:

ISP1#ping vrf Blue 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
ISP1#ping vrf Red 192.168.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

No problem at all, at least we know the VRFs are working on ISP1. Let’s check ISP2 as well:

ISP2#show vrf
  Name                             Default RD            Protocols   Interfaces
  Blue                             <not set>             ipv4        Gi1
  Red                              <not set>             ipv4        Gi2

Let’s ping the Blue2 and Red2 routers, see if they respond:

ISP2#ping vrf Blue 192.168.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms
ISP2#ping vrf Red 192.168.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

We just verified that the VRF configuration on ISP1 and ISP2 is working as expected. Let’s continue with the VNET trunk configuration:

ISP1(config)#interface GigabitEthernet3
ISP1(config-if)#vnet trunk
ISP1(config-if)#ip address 192.168.56.5 255.255.255.0
ISP2(config)#interface GigabitEthernet3
ISP2(config-if)#vnet trunk
ISP2(config-if)#ip address 192.168.56.6 255.255.255.0

That’s all we have to do…use the vnet trunk command to tell the routers that we want to use this interface, that’s it. Behind the scenes is where the “EVN magic” happens. Take a look at the running configuration of one of the ISP routers:

ISP1#show running-config interface GigabitEthernet3
Building configuration...

Current configuration : 103 bytes
!
interface GigabitEthernet3
 vnet trunk
 ip address 192.168.56.5 255.255.255.0
 negotiation auto
end

This is what we just configured, there’s not much on the interface. In reality however this is what the configuration looks like:

ISP1#show derived-config | begin GigabitEthernet3
interface GigabitEthernet3
 vnet trunk
 ip address 192.168.56.5 255.255.255.0
 negotiation auto
!
interface GigabitEthernet3.10
 description Subinterface for VNET Blue
 encapsulation dot1Q 10
 vrf forwarding Blue
 ip address 192.168.56.5 255.255.255.0
!
interface GigabitEthernet3.20
 description Subinterface for VNET Red
 encapsulation dot1Q 20
 vrf forwarding Red
 ip address 192.168.56.5 255.255.255.0

EVN automatically created two sub-interfaces for us for each VRF. You can see that it uses 802.1Q encapsulation and the tag is based on the vnet tag that we configured earlier. Every time you create a new VRF, EVN will automatically create the required sub-interface.

There are a couple of other EVN “tricks” but to show them we’ll have to configure some routing.

Routing Configuration

Let’s configure OSPF within VRF Blue so that Blue1/Blue2 are able to reach each other. We’ll do the same thing for VRF Red so that Red1/Red2 can reach each other. This is what the topology looks like:

Cisco EVN OSPF Example

Let’s configure OSPF for VRF Blue first:

Blue1(config)#router ospf 1 
Blue1(config-router)#network 192.168.1.0 0.0.0.255 area 0
Blue2(config)#router ospf 1
Blue2(config-router)#network 192.168.3.0 0.0.0.255 area 0
ISP1(config)#router ospf 1 vrf Blue
ISP1(config-router)#network 192.168.1.0 0.0.0.255 area 0
ISP1(config-router)#network 192.168.56.0 0.0.0.255 area 0
ISP2(config)#router ospf 1 vrf Blue
ISP2(config-router)#network 192.168.3.0 0.0.0.255 area 0
ISP2(config-router)#network 192.168.56.0 0.0.0.255 area 0

Nothing special here, just regular OSPF. Let’s do the same thing for VRF Red:

Red1(config)#router ospf 1
Red1(config-router)#network 192.168.2.0 0.0.0.255 area 0
Red2(config)#router ospf 1 
Red2(config-router)#network 192.168.4.0 0.0.0.255 area 0
ISP1(config)#router ospf 2 vrf Red
ISP1(config-router)#network 192.168.2.0 0.0.0.255 area 0
ISP1(config-router)#network 192.168.56.0 0.0.0.255 area 0
ISP2(config)#router ospf 2 vrf Red
ISP2(config-router)#network 192.168.4.0 0.0.0.255 area 0
ISP2(config-router)#network 192.168.56.0 0.0.0.255 area 0

That should take care of OSPF. Let’s verify our work:

Blue1#show ip route ospf 

O     192.168.3.0/24 [110/3] via 192.168.1.254, 00:08:43, FastEthernet0/0
O     192.168.56.0/24 [110/2] via 192.168.1.254, 00:08:53, FastEthernet0/0
Blue2#show ip route ospf 

O     192.168.1.0/24 [110/3] via 192.168.3.254, 00:09:16, FastEthernet0/0
O     192.168.56.0/24 [110/2] via 192.168.3.254, 00:09:16, FastEthernet0/0

Blue1 and Blue2 have learned about each others networks and the network in between ISP1 and ISP2. So far so good, let’s check the ISP routers:

ISP1#show ip route vrf Blue ospf

O     192.168.3.0/24 [110/2] via 192.168.56.6, 00:09:40, GigabitEthernet3.10
ISP2#show ip route vrf Blue ospf

O     192.168.1.0/24 [110/2] via 192.168.56.5, 00:10:02, GigabitEthernet3.10

This is looking good, no issues here. You can see the sub-interface of the VNET trunk here. Let’s check OSPF for VRF Red too:

Red1#show ip route ospf 

O     192.168.4.0/24 [110/3] via 192.168.2.254, 00:03:26, FastEthernet0/0
O     192.168.56.0/24 [110/2] via 192.168.2.254, 00:03:36, FastEthernet0/0
Red2#show ip route ospf 

O     192.168.2.0/24 [110/3] via 192.168.4.254, 00:03:47, FastEthernet0/0
O     192.168.56.0/24 [110/2] via 192.168.4.254, 00:04:37, FastEthernet0/0

Looking good, let’s check the ISP routers:

ISP1#show ip route vrf Red ospf

O     192.168.4.0/24 [110/2] via 192.168.56.6, 00:04:23, GigabitEthernet3.20
ISP2#show ip route vrf Red ospf 

O     192.168.2.0/24 [110/2] via 192.168.56.5, 00:04:54, GigabitEthernet3.20

Everything is working as it should. With OSPF up and running we can play with EVN a bit more…

Route Replication (Shared Services)

VRFs are great because they allow us to separate routing information. Sometimes however we have some “shared services” that multiple VRFs could use. For example, maybe customer Blue and Red would like to use some central DNS or DHCP servers. You could have these servers within each VRF but it would be easier if we could share some central servers with multiple VRFs.

Route sharing between VRFs can be done with VRF Lite but it requires the configuration of RDs (Route Distinguishers) and BGP.

EVN supports route replication which “replicates” routes from one VRF to another. It doesn’t require RDs and BGP so the configuration is a bit simpler.

To share some services, we’ll create another VRF that we can use for our shared services. To demonstrate this I will create a new VRF called “Green” on ISP1. Take a look at the picture below:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

501 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. René,

    Congrats for share this excellent explanation!!! I’m from Brazil and I don’t have a good English, but I can understand each word, sentence that you used in this article. I never had understood about this subject, maybe because I really didn’t study it with attention and deeply. I’m a beginner Network Admin and when I saw this article in my feed I started to read it and understand it and I’m amazing how you can teach it like this way.

    But I have a doubt where I can’t see in examples above. Using this topology, if tomorrow for any reason Blue and Red make a

    ... Continue reading in our forum

  2. Hi Azm,

    Let me jump in on Cisco VIRL. I can highly recommend to run it in VMWare ESXi, it’s free and saves you the hassle of messing with network interfaces etc. Although I really like VIRL, I had some issues with updates that went wrong and deploying a new OVA template in ESXi is much easier than reinstalling a physical box.

    Look on eBay for an older server that has plenty of RAM and 2x CPUs or something like that.

    I still use an HP proliant DL360 G7 with 96GB of RAM which is great for Cisco VIRL:

    ... Continue reading in our forum

  3. Hi,
    i’m bulding a lab for a POC and need some advise.

    Topology:

                           --------------------------
                           -                              -
                           -        Firewall        -         
                           -                              - 
                           --------------------------
                                         |         int E0/0 (192.168.2.1/24)
                                         |
                                         |
                            --------------------------
                           |     
    ... Continue reading in our forum

  4. Hello,
    thank you for replying.
    I found a way around. Simillar to this: https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200158-Configure-Route-Leaking-between-Global-a.html
    However this isn’t really a good approach and only a workaround.

    Intial the approach with MP-MGP didn’t come to my attention as wasn’t planning to use BGP in the network.
    What i overlooked is that you don’t need any BGP neighbors !
    I managed to use MP-MGP now, which i ways easiers and my lab is working now.

    Many thanks,
    Oliver

66 more replies! Ask a question or join the discussion by visiting our Community Forum