As I will not be doing a DEEP Dive or review of VRF-Lite outside of reviewing my own post on its configuration, I figured I would put the highlights of my VRF-Lite post here in terms of configuration. This way we can both get an overview of VRF-Lite, and how it compares to EVN, and how the two compare.
So the initial configuration output you see will be VRF-Lite, I will clearly indicate when we are switching gears into EVN mode, so if you want to skip straight to that it should not be too far down the page!
So to start, this is how VRF-Lite gets configured on a Cisco Router / Switch like ROAS:
R1:
R1(config)#int fa0/0
R1(config-if)#no shut
R1(config-if)#int fa0/0.2
R1(config-subif)#encap dot1q 2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#int fa0/0.3
R1(config-subif)#encap dot1q 3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#encap dot1q 4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#
SW1:
SW1(config)#int fa0/2
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 2
SW1(config-if)#int fa0/3
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 3
SW1(config-if)#int fa0/4
SW1(config-if)#switchport mode access
SW1(config-if)#switchport access vlan 4
SW1(config-if)#
Like I said, exactly like (ROAS) Router on a Stick, then the actual VRF-Lite commands:
R1(config)#ip vrf VRF2
R1(config-vrf)#exit
R1(config)#ip vrf VRG3
R1(config-vrf)#EXIT
R1(config)#no ip vrf VRG3
% IP addresses from all interfaces in VRF VRG3 have been removed
R1(config)#ip vrf VRF3
R1(config-vrf)#exit
R1(config)#ip vrf VRF4
R1(config-vrf)#exit
R1(config)#
As seen I accidentally mis-typed VRF3 so upon deleting it, it shows it is removing all interfaces with it, this is because of how VRF-Lite handles routes for Virtual Route Forwarding.
Let me get one more case in point for VRF-Lite, to explain what is happening:
R1(config)#int fa0/0.2
R1(config-subif)#ip vrf forwarding VRF2
% Interface FastEthernet0/0.2 IP address 10.2.2.1 removed due to enabling VRF VRF2
R1(config-subif)#int fa0/0.3
R1(config-subif)#ip vrf forwarding VRF3
R1(config-subif)#ip add 10.3.3.1 255.255.255.0
R1(config-subif)#int fa0/0.4
R1(config-subif)#ip vrf forwarding VRF4
R1(config-subif)#ip add 10.4.4.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do sh ip int bri
Interface                 IP-Address     OK? Method Status               Protocol
FastEthernet0/0           unassigned     YES NVRAM up                   up
FastEthernet0/0.2         unassigned     YES NVRAM up                   up
FastEthernet0/0.3         10.3.3.1       YES manual up                   up
FastEthernet0/0.4         10.4.4.1       YES manual up                   up
Serial0/0                 unassigned     YES NVRAM administratively down down
FastEthernet0/1           unassigned     YES NVRAM administratively down down
Serial0/1                 unassigned     YES NVRAM administratively down down
R1(config)#
Then I had to re-add the IP address here:
R1(config)#int fa0/0.2
R1(config-subif)#ip add 10.2.2.1 255.255.255.0
R1(config-subif)#exit
R1(config)#do show ip int bri
Interface                 IP-Address     OK? Method Status               Protocol
FastEthernet0/0           unassigned     YES NVRAM up                   up
FastEthernet0/0.2         10.2.2.1       YES manual up                   up
FastEthernet0/0.3         10.3.3.1       YES manual up                   up
FastEthernet0/0.4         10.4.4.1       YES manual up                   up
Serial0/0                 unassigned     YES NVRAM administratively down down
FastEthernet0/1           unassigned     YES NVRAM administratively down down
Serial0/1                 unassigned     YES NVRAM administratively down down
R1(config)#
So a couple of things to note about VRF-Lite from the output above:
- You must sub-interface and configure it to 802.1Q trunk for each instance
- Its method of removing routes from the Global Routing Table and putting the route into its own Virtual Route Forwarding instance is to remove the IP from the interface if the VRF instance is applied to an interface with an existing IP address
- Later on it goes into need to use different routing processes per instance for example “ospf proc 2 vrf VRF2”, “ospf proc 3 vrf VRF3”, etc and enter your network commands into separate processes.
If you do not understand VRF-Lite, I highly recommend giving this post a quick once over to familiarize yourself with what I mean with EIGRP not working and such.
As a disclaimer to that post, I thought VRF could not use EIGRP because at the time I was unfamiliar with the address-family command, so it IS possible to use with EIGRP!
NOW ONTO EASY VPN ROUTING NOW THAT WE UNDERSTAND OUR ROOTS OF VRF-LITE FOR VIRTUAL ROUTING NEEDS!
EVN essentially replaces VRF-Lite, as almost a VRF-Lite-Lite, as even at it’s most simple configuration as seen above it can become cumbersome quickly.
EVN takes path isolation for data, giving it the simplicity of Layer 2 (VLANs), and takes it to Layer 3 (VRF) without needing all the sub-interfaces and such.
Also, we get to learn a new command in the configuration, which I we love new commands and this is one I need to cover big time – “address-family”.
Before configuration, lets look at some of the main fundamentals of EVN:
- No Sub-Interfaces, uses “vnet trunk” command on single Ethernet interface
- Not generally used for WAN, unless in a specialized deployment
- Does not just provide separate data paths, but separation of the Control Plane, the Data Plane, and Services as well – Like network services used by End Users
- It supports services like DHCP, DNS, etc by keeping route in the RIB (Routing Information Base / IP Route table) while keeping them logically separated when traversing the network or being delivered to end users
Here are a few of it’s limitations, and with EVN supports:
- It can be used on any Interface that can use 802.1Q Trunking (Ethernet), which is why I removed the NBMA from the above Topology and instead used Ethernet interfaces
- It supports – Unicast Routing Options: OSPFv2, EIGRP, and Static Routes
- It supports – Multicast Routing Options: PIM, MSDP, and IGMP
One final boring bullet point on the subject, here is what it requires for configuration:
- “vnet trunk” on interface to define it is using EVN
- “vnet tags” essentially replace VLAN tags in 802.1Q, making it a global value
- “address-family” to defines what networks are in your “vnet tag”
OK, I have had it with this theory, lets get to some configurations!
First we will start our configuration with OSPF, which I wouldn’t normally bother posting the output, but however we get a first glimpse at the new “address-family” command in this configuration:
R1(config)#router rip
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#version 2
R1(config-router-af)#no auto
R1(config-router-af)#network 172.12.12.0
R1(config-router-af)#network 172.12.13.0
R1(config-router-af)#?
Router Address Family configuration commands:
 auto-summary           Enable automatic network number summarization
 default                Set a command to its defaults
 default-information    Control distribution of default information
 default-metric         Set metric of redistributed routes
 distance               Define an administrative distance
 distribute-list        Filter networks in routing updates
 exit-address-family    Exit from Address Family configuration mode
 flash-update-threshold Specify flash update threshold in second
 help                   Description of the interactive help system
 input-queue            Specify input queue depth
 maximum-paths          Forward packets over multiple paths
 neighbor               Specify a neighbor router
 network                Enable routing on an IP network
 no                     Negate a command or set its defaults
 offset-list            Add or subtract offset from RIP metrics
 output-delay           Interpacket delay for RIP updates
 passive-interface      Suppress routing updates on an interface
 redistribute           Redistribute information from another routing
                         protocol
 timers                 Adjust routing timers
 traffic-share          How to compute traffic share over alternate paths
 validate-update-source Perform sanity checks against source address of
                         routing updates
 version                Set routing protocol version
R1(config-router-af)#
I used RIP because other routing protocols don’t let you get away with just “address-family ipv4 unicast” as a command with a <cr> there, and I am not opening that can of worms tonight going into multicast options.
Notice that before I did anything, I went from RIP configuration to “address-family” sub-configuration mode before I entered my usual no-auto and ver 2 commands along with my networks.
Now as highlighted in red, it shows that you must use the “exit-address-family” command from this sub-configuration mode to save the settings you configured, and here I will demonstrate you can actually put your “no auto” and “ver 2” in our out of address-family configuration mode:
R1(config)#router rip
R1(config-router)#address-family ipv4 unicast
R1(config-router-af)#no auto
R1(config-router-af)#ver 2
R1(config-router-af)#network 172.12.12.0
R1(config-router-af)#network 172.12.13.0
R1(config-router-af)#exit-address-family
R1(config-router)#exit
R1(config)#exit
R1#
*May 3 05:49:35.339: %SYS-5-CONFIG_I: Configured from console by console
R1#wr
Building configuration…
ASR#2
[Resuming connection 2 to r2 … ]
R2(config)#router rip
R2(config-router)#ver 2
R2(config-router)#no auto
R2(config-router)#address-family ipv4 unicast
R2(config-router-af)#network 172.12.12.0
R2(config-router-af)#exit-address-family
R2(config-router)#exit
R2(config)#exit
R2#wr
Building configuration…
ASR#3
[Resuming connection 3 to r3 … ]
R3#
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#router rip
R3(config-router)#no auto
R3(config-router)#ver 2
R3(config-router)#address-family ipv4 unicast
R3(config-router-af)#network 172.12.12.0
R3(config-router-af)#network 172.12.13.0
R3(config-router-af)#exit-address-family
R3#
R3#sh ip route
Codes: 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
      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
      o – ODR, P – periodic downloaded static route
Gateway of last resort is not set
    3.0.0.0/32 is subnetted, 1 subnets
CÂ Â Â Â Â Â 3.3.3.3 is directly connected, Loopback3
    172.12.0.0/24 is subnetted, 3 subnets
RÂ Â Â Â Â Â 172.12.12.0 [120/1] via 172.12.13.1, 00:00:26, FastEthernet0/0
CÂ Â Â Â Â Â 172.12.13.0 is directly connected, FastEthernet0/0
R3#
So all is well with routing protocols, R3 can see R2 across R1, now we get into the VRF settings of the configuration.
At this point I’ve my IOS code or routers don’t really support “vnet” as an option under VRF Description or on my Ethernet faces (of course), as seen here:
R2(config-vrf)#?
VPN Routing/Forwarding instance configuration commands:
 address-family Enter Address Family command mode
 default        Set a command to its defaults
 description    VRF specific description
 exit           Exit from VRF configuration mode
 no             Negate a command or set its defaults
 rd             Specify Route Distinguisher
 route-target   Specify Target VPN Extended Communities
 vpn            Configure VPN ID as specified in rfc2685
So we do have address-family! Unfortunately from a fairly older protocol (or at least the materials I found are 5+ years old), I am very surprised to find the function missing from my routers even running 15.x IOS.
However I will quickly type out the configurations you will need across all routers to make the EVN configuration work:
- “vrf description (word)” Defines the VRF instance
- R2(config-vrf)# vnet tag 10 – Works as the Layer 3 VLAN Tag type #
- R2(config-vrf)# address-family ipv4
Repeat these 3 commands for each VRF instance, on all routers participating in EVN!
So if you wanted to make “vrf description RED” with a “vnet tag 10”, then a “vrf description BLUE” and “vnet tag 20”, etc. This needs to be configured for every router that will be passing this traffic.
Finally, on the Ethernet interfaces you will need to deploy a single command for it to recognize it is participating in EVN:
“vnet trunk”
That should be issued on all Ethernet interfaces pointing at EVN routers.
With that I have had enough of EVN, I am a bit perplexed my routers are ONLY missing the vnet commands (even on my 15.x IOS router), so I am going to leave it here at knowledge of EVN and a good (and much needed) refresher of VRF-Lite!
I encourage you watch youtube videos such as these to get a full explanation:
The DEVNET GRIND! 