VRF-Lite: Complete configuration and explanation of behaviors, OSPF and EIGRP demonstration and how they work (or why the don’t work)

To note I used the same color I have previously for IPSec VPN tunnels, however that color is more just one of the few colors not reserved for protocols (as I generally use blue for OSPF, red for RIP, and orange for EIGRP), so this time green is for VRF-Lite.

So I wanted to pull quick from the last lab quickly the two pieces of setup already done on the equipment from the last post:

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)#

Now to demonstrate something, I have removed sub-interface .3 and .4’s IP address, which will later be revisited.

Now as VRF previously described is separating networks with virtual routing instances, the first part of the configuration is to just simply create those instances:

R1(config)#ip vrf VRF2
R1(config-vrf)#?
IP VPN Routing/Forwarding instance configuration commands:
  bgp           Commands pertaining to BGP
  context       Associate SNMP context with this vrf
  default       Set a command to its defaults
  description   VRF specific description
  exit          Exit from VRF configuration mode
  export        VRF export
  import        VRF import
  maximum       Set a limit
  mdt           Backbone Multicast Distribution Tree
  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

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)#

So I left the output from the VRF mode it drops you into, to show the more advanced options not covered in the CCNP ROUTE exam, more geared to non-Lite VRF (however we may see them in the BGP section). Also I highlighted an error from my first configuration derp of the night, and this illustrates a behavior of VRF I wanted to cover first.

Unlike a majority of configurations on Cisco routers, with VRF, it does matter the order in which you enter commands because that may lead to it removing your IP addresses.

This is because the way VRF takes the route out of the “global route table” and into its own, is by removing the IP address literally from the interface (thus removing it from the global route table), making you manually re-enter it (thus putting it into its VRF instances route table). So I am wondering if the error in red will force VRF enabled interfaces to lose their IP address – I will test this quickly after step # 2 in our configuration.

Being that entering VRF on the interfaces is step #2 in configuration, I took the liberty of showing you how it will react to fa0/0.2 when I enter it on an interface with a current IP, as compared to me enabling VRF on the interface and then entering the IP address:

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)#

So as you can see, the order of the commands allowed the IP not to be stripped off .3 and .4, and will now need to be re-entered on .2:

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)#

There we go, now lets delete an instance and see if it strips the ip address off the interface:

R1(config)#no ip vrf VRF4
% IP addresses from all interfaces in VRF VRF4 have been removed
R1(config)#do sh 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          unassigned      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)#

It certainly did, and there are a few things here I want to cover, bullet point style:

• Adding VRF to an interface with an IP, and removing a VRF instance will strip the IP address off any interface running that VRF instance
• Any IP address removed will have to be manually re-entered on that interface
• If the VRF instance was removed, the IP address / network will be back in the route table after manually re-adding, if it was stripped due to adding VRF to an interface, it will no longer be in the global routing table after manual re-entering it
• VRF-Lite configurations, at least in this demonstration, are completely locally significant and downstream routers are completely unaware and will not need special commands when trying to ping R1 or when adding dynamic routing protocols (Only R1 will require them).

So then where do they all go? Good question! They go into their VRF instances routing table, which after adding a route protocol we will see a bit more illustrated:

R1#sh ip route

Gateway of last resort is not set

There be nothing here in the global route table, and that is because the only IP addresses this router knows of are the connected sub-interfaces, and they are now in their own VRF routing instances.

That being said, here is how to see them, with some ? output left in there to see options available for later use in higher level studies (or later in the current course):

R1#show ip route ?

  Hostname or A.B.C.D  Network to display information about or hostname
  bgp                  Border Gateway Protocol (BGP)
  connected            Connected
  dhcp                 Show routes added by DHCP Server or Relay
  eigrp                Enhanced Interior Gateway Routing Protocol (EIGRP)
  isis                 ISO IS-IS
  list                 IP Access list
  mobile               Mobile routes
  odr                  On Demand stub Routes
  ospf                 Open Shortest Path First (OSPF)
  profile              IP routing table profile
  rip                  Routing Information Protocol (RIP)
  static               Static routes
  summary              Summary of all routes
  supernets-only       Show supernet entries only
  track-table          Tracked static table
  update-queue         Queue of RIB updates
  vrf                  Display routes from a VPN Routing/Forwarding instance
  |                    Output modifiers
  <cr>

R1#show ip route vrf ?

  WORD  VPN Routing/Forwarding instance name

R1#show ip route vrf VRF4 ?
  Hostname or A.B.C.D  Network to display information about or hostname
  bgp                  Border Gateway Protocol (BGP)
  connected            Connected
  dhcp                 Show routes added by DHCP Server or Relay
  eigrp                Enhanced Interior Gateway Routing Protocol (EIGRP)
  isis                 ISO IS-IS
  list                 IP Access list
  mobile               Mobile routes
  odr                  On Demand stub Routes
  ospf                 Open Shortest Path First (OSPF)
  profile              IP routing table profile
  rip                  Routing Information Protocol (RIP)
  static               Static routes
  summary              Summary of all routes
  supernets-only       Show supernet entries only
  track-table          Tracked static table
  update-queue         Queue of RIB updates
  |                    Output modifiers
  <cr>

R1#show ip route vrf VRF4

Routing Table: VRF4

Gateway of last resort is not set

     10.0.0.0/24 is subnetted, 1 subnets
C       10.4.4.0 is directly connected, FastEthernet0/0.4
R1#

And there it is, I highlight my commands (and the options I chose) as with that much modifier output from ?, it is hard to see where the actual command is.

Alright, so our router now has 3 of these VRF instances running, and I think at this point we should know our options to view our VRF information that is configured:

R1#show ip vrf
  Name                             Default RD          Interfaces
  VRF2                             <not set>           Fa0/0.2
  VRF3                             <not set>           Fa0/0.3
  VRF4                             <not set>           Fa0/0.4

R1#sh int fa0/0.2
FastEthernet0/0.2 is up, line protocol is up
  Hardware is AmdFE, address is 000e.8475.04e0 (bia 000e.8475.04e0)
  Internet address is 10.2.2.1/24
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation 802.1Q Virtual LAN, Vlan ID  2.
  ARP type: ARPA, ARP Timeout 04:00:00
  Last clearing of “show interface” counters never

HUGE DISCLAIMER TO THE ABOVE OUTPUT : I believe because my WAN routers for the NBMA are running IOS code 12.x it does not show the VRF forwarding instance on my “show int” output but on 15.x IOS code I believe it does.

You can also see the VRF instance in each interfaces output in “sh run” but do not count on that being an available command on exam day.

MOVING RIGHT ALONG.

To ping neighbors that are in a particular VRF instance will fail, because a general ping only tests connectivity in the global route table:

R1#ping 10.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#

For this, we need to add some VRF commands to the ping, to make it use our virtual routing instances route table:

R1#ping ?
  WORD       Ping destination address or hostname
  appletalk  Appletalk echo
  clns       CLNS echo
  decnet     DECnet echo
  ip         IP echo
  ipv6       IPv6 echo
  ipx        Novell/IPX echo
  srb        srb echo
  tag        Tag encapsulated IP echo
  vrf        Select VPN routing instance
  <cr>

R1#ping vrf ?
  WORD  VPN Routing/Forwarding instance name

R1#ping vrf VRF4 ?
  WORD       Ping destination address or hostname
  appletalk  Appletalk echo
  clns       CLNS echo
  decnet     DECnet echo
  ip         IP echo
  ipv6       IPv6 echo
  ipx        Novell/IPX echo
  srb        srb echo
  tag        Tag encapsulated IP echo
  <cr>

R1#ping vrf VRF4 10.4.4.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#

So at this point, it can be noticed that when using VRF, you need to define its instance in basically everything that you do on the router it is configured on, and routing protocols are not immune to this either. So, speaking of which, lets configure us some OSPF first, then we’ll remove it and try EIGRP.

What I like about this demonstration, is that it shows a purpose for both having different locally significant processes for OSPF and VRF. It also shows that when configuring OSPF for VRF, it makes you define the VRF instance ensuring that networks in other VRF instances stay in their own VRF instances:

R1(config)#router ospf 2 ?
  vrf  VPN Routing/Forwarding Instance
  <cr>

R1(config)#router ospf 2 vrf ?
  WORD  VPN Routing/Forwarding Instance (VRF) name

R1(config)#router ospf 2 vrf VRF2 ?
  <cr>

R1(config)#router ospf 2 vrf VRF2
R1(config-router)#network 10.2.2.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#router ospf 3 vrf VRF3
R1(config-router)#network 10.3.3.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#router ospf 4 vrf VRF4
R1(config-router)#network 10.4.4.0 0.0.0.255 area 0
R1(config-router)#exit
R1(config)#

Notice from the ? output, VRF is the only thing proceed “router ospf (process #)” that can be configured, so that extended command is made solely for VRF. So I put in our VRF instances 2 / 3 / 4 in their own OSPF processes 2 / 3 / 4 but made them all be in Area 0 which makes this technically makes this 2 different types of OSPF router:

• A backbone router = Must have at least one interface in Area 0
• An Internal router = Only has OSPF interfaces in a single Area
• Not an ABR (Area Boarder Router) because that must have one interface in Area 0 and another interface in a non-0 Area

Really wanted to stress that it isn’t an ABR, as I thought it was also that, and after double checking my OSPF Fundamentals in a can post the definition does not fit – THIS IS IT IS WHY IT IS GOOD TO CONTINUOUSLY INCORPORATE OLD LESSONS WITH NEW LESSONS TO KEEP THE KNOWLEDGE UP IN THE OL STEEL TRAP ON YOUR SHOULDERS!

Now, in R2, R3, and R4 I will put them in OSPF Process 1 because the process is locally significant only so it will not matter. I will also create a quick loopback on them to make sure we are advertising routes back to R1:

R2(config)#int lo2
R2(config-if)#
*Mar  1 21:20:51.863: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback2, changed state to up
R2(config-if)#ip add 2.2.2.2 255.255.255.0
R2(config-if)#router ospf 1
R2(config-router)#network 10.2.2.0 0.0.0.255 area 0
*Mar  1 21:21:51.777: %OSPF-5-ADJCHG: Process 1, Nbr 10.2.2.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
R2(config-router)#network 2.2.2.0 0.0.0.255 area 2
R2(config-router)#

You can see the adjacency back to R1 form before the loopback network can even be added, I’ll save the output from the other two routers as it is the exact same except their loopbacks will be 3.3.3.0/24 and 4.4.4.0/24.

• One other note, R2 / R3 / R4 are now ABR’s because they have their fa0/0 interface in Area 0 and their loopback interface in Area #, so they are both a Backbone router and a ABR router in OSPF terminology

However from the above output, I wanted to show there are no extended VRF commands on the remote routers from R1 or matching process #’s needed, so lets see how R1 see’s everything:

R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           1   FULL/DR         00:00:33    10.4.4.4        FastEthernet0/0.4
3.3.3.3           1   FULL/DR         00:00:38    10.3.3.3        FastEthernet0/0.3
10.2.2.2          1   FULL/DR         00:00:31    10.2.2.2        FastEthernet0/0.2
R1#

As can be seen, “sh ip ospf nei” shows them whether they are in their own VRF’s or not, they are still OSPF neighbors, however even after a “clear ip ospf proc” on both R1 and R2 it is still showing 10.2.2.2 as it’s RID instead of the highest logical address 2.2.2.2.

So first from R1, lets see if we are getting routes advertised from all 3 neighbors:

R1#show ip route vrf VRF2

Routing Table: VRF2

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
O IA    2.2.2.2 [110/2] via 10.2.2.2, 00:02:39, FastEthernet0/0.2
     10.0.0.0/24 is subnetted, 1 subnets
C       10.2.2.0 is directly connected, FastEthernet0/0.2
R1#show ip route vrf VRF3

Routing Table: VRF3

Gateway of last resort is not set

     3.0.0.0/32 is subnetted, 1 subnets
O IA    3.3.3.3 [110/2] via 10.3.3.3, 00:03:00, FastEthernet0/0.3
     10.0.0.0/24 is subnetted, 1 subnets
C       10.3.3.0 is directly connected, FastEthernet0/0.3
R1#show ip route vrf VRF4

Routing Table: VRF4

Gateway of last resort is not set

     4.0.0.0/32 is subnetted, 1 subnets
O IA    4.4.4.4 [110/2] via 10.4.4.4, 00:03:04, FastEthernet0/0.4
     10.0.0.0/24 is subnetted, 1 subnets
C       10.4.4.0 is directly connected, FastEthernet0/0.4
R1#

After going back to R2 and doing “sh ip route” and confirming 2.2.2.0/24 is in the global route table, and “sh ip proto” shows 10.2.2.2 as the RID, and “sh ip int bri” confirms 10.2.2.2 is NOT on a logical interface I have no idea what’s going on.

I’d normally dig into that a little more, but it’s getting late, and I need to wrap this up, but want to test EIGRP as well so I’m going to quickly change the routing protocol to EIGRP to see if it works the same:

R1(config)#
R1(config)#
R1(config)#router eigrp ?

  <1-65535>  Autonomous system number

R1(config)#router eigrp 200 ?

  <cr>

R1(config-router)#no auto

R1(config-router)#?

Router configuration commands:
  address-family       Enter Address Family command mode
  auto-summary         Enable automatic network number summarization
  bfd                  BFD configuration commands
  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
  eigrp                EIGRP specific commands
  exit                 Exit from routing protocol configuration mode
  help                 Description of the interactive help system
  maximum-paths        Forward packets over multiple paths
  metric               Modify EIGRP routing metrics and parameters
  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
  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
  variance             Control load balancing variance

R1(config-router)#network ?

  A.B.C.D  Network number

R1(config-router)#network 10.2.2.0 0.0.0.255 ?

  <cr>

R1(config-router)#network 10.2.2.0 0.0.0.255
R1(config-router)#exit
R1(config)#router eigrp 300
R1(config-router)#network 10.3.3.0 0.0.0.255
R1(config-router)#exit
R1(config)#router eigrp 400
R1(config-router)#network 10.4.4.0 0.0.0.255
R1(config-router)#exit

I’ve highlight my output again in red, as there is a lot of output here that I want to illustrate mentions ABSOLUTELY NOTHING ABOUT VRF ANYWHERE WITH EIGRP.

So I just put them in their own AS’s, but I am not feeling good about this, as not defining the virtual routing process, I am assuming it is going to try to pull from the global route table. So on the neighbors I will use matching AS numbers (as required to match to form an adjacency with EIGRP neighbors, along with k weights), and lets see if we get some neighbors to form:

R2(config)#router eigrp 200
R2(config-router)#no auto
R2(config-router)#network 10.2.2.0 0.0.0.255
R2(config-router)#network 2.2.2.0 0.0.0.255
R2(config-router)#
ASR#1
[Resuming connection 1 to r1 … ]

R1(config)#do sh ip eigrp nei
IP-EIGRP neighbors for process 200
IP-EIGRP neighbors for process 300
IP-EIGRP neighbors for process 400
R1(config)#

Yeah, it looks like EIGRP is not going to work with VRF instances like OSPF did, I assume BGP will as well be we have yet to get into BGP yet in my studies. So I won’t go on to configure the other routers as we know it’s not going to work.

That concludes VRF-Lite, lots of good information to go with the configurations, now onward to IPv6! 🙂