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.



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 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

555 Sign Ups in the last 30 days

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

Forum Replies

  1. Hi Collin,

    That’s right, it’s a little side effect of replicating everything. All routes are replicated from blue/red to green and vice versa.

    To solve this, it’s better to use a route-map to define what should/shouldn’t be replicated:

    ISP1(config-vrf-af)#route-replicate from vrf Green unicast all route-map RED_PREFIXES

    Rene

  2. EVN only knows what tags to use since we configured the tags on the VRFs.

    Also, it basically only does this for us:

    interface GigabitEthernet3.10
     description Subinterface for VNET Blue
     encapsulation dot1Q 10
     vrf forwarding Blue
     ip address 192.168.56.5 255.255.255.0
    

    The sub-interface above was created by EVN. If you don’t want to use EVN, you could configure sub-interfaces like this yourself.

  3. Hopefully, this will be easier. I don’t know what it means when it says please use the “code” button to post configurations.
    ISP1:

    vrf definition Blue
     vnet tag 10
     !
     address-family ipv4
     exit-address-family
    !
    vrf definition Red
     vnet tag 20
     !
     address-family ipv4
     exit-address-family
    !
    interface GigabitEthernet1
     vrf forwarding Blue
     ip address 192.168.1.254 255.255.255.0
     negotiation auto
    !
    interface GigabitEthernet2
     vrf forwarding Red
     ip address 192.168.2.254 255.255.255.0
     negotiation auto
    !
    interface GigabitEthernet3
     vnet trunk
     ip address 192.168.56.
    ... Continue reading in our forum

  4. Hello Don.

    I’m assuming the EVN trunk is working and that you’ve checked the VRF configuration, and you’ve successfully verified that the vnet trunk has been created with the appropriate show and ping commands. I’m also assuming you’ve checked the output from the command show derived-confg and that the subinterfaces Gi3.10 and Gi3.20 are showing up. Check these first to see that the EVN is working correctly before any routing has been configured.

    Looking through your config, I’m not able to find something that stands out as an error. It seems like it should

    ... Continue reading in our forum

  5. Hello Johnson

    The vrf forwarding command can only be used under the interface configuration. You may be referring to the ip vrf forwarding command which can also be implemented in global configuration mode.

    Cisco explains the difference like so:

    In earlier Cisco IOS releases, you created a VRF to be applied only to an IPv4 address family (single-protocol VRF) by entering the ip vrf command. To activate the single-protocol VRF on an interface, you entered the ip vrf forwarding (interface configuration) command.

    You can now define multiple address families und

    ... Continue reading in our forum

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