In order to understand the use of Front Door VRFs let us use a simple topology as below where we will create a Simple GRE tunnel between R1 and R4.
Network Topology: Use of Front door VRFs
Both R1 and R4 will learn about the tunnel destination address via underlying protocol i.e. OSPF in our case.
Once the tunnels are up/up we will create EIGRP neighborship over the tunnel interfaces between R1 and R4.
Tunnel Configuration of R1:
interface Tunnel10
ip address 9.9.0.1 255.255.255.0
tunnel source 9.9.12.1
tunnel destination 9.9.34.4
end
Tunnel Configuration on R4:
interface Tunnel10
ip address 9.9.0.4 255.255.255.0
tunnel source 9.9.34.4
tunnel destination 9.9.12.1
end
Currently route about tunnel destination 9.9.12.1 & 9.9.34.4 are learnt via OSPF
R1#sh ip route 9.9.34.4
Routing entry for 9.9.34.0/24
Known via “ospf 1”, distance 110, metric 3, type intra area
Last update from 9.9.12.2 on FastEthernet0/0, 00:33:19 ago
Routing Descriptor Blocks:
* 9.9.12.2, from 9.9.34.4, 00:33:19 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
R4#sh ip route 9.9.12.1
Routing entry for 9.9.12.0/24
Known via “ospf 1”, distance 110, metric 3, type intra area
Last update from 9.9.34.3 on FastEthernet0/0, 00:33:33 ago
Routing Descriptor Blocks:
* 9.9.34.3, from 9.9.12.2, 00:33:33 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
Now let us create EIGRP neighbor ship between R1 and R4 and let’s see what happens:
R1#sh runn | s r eigrp
router eigrp 100
network 9.9.0.0 0.0.255.255
passive-interface default
no passive-interface Tunnel10
R4# sh runn | s r eigrp
router eigrp 100
network 9.9.0.0 0.0.255.255
passive-interface default
no passive-interface Tunnel10
Now let’s check the logging on R1 or R4 to see what happened:
Below log shows we built EIGRP neighbor betweenR1 and R4 Tu10 interface.
*Nov 9 14:53:44.559: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 9.9.0.4 (Tunnel10) is up: new adjacency
Here we see the first the EIGRP neighbor ship goes down and then Tu 10 interface goes down due to recursive routing
*Nov 9 14:53:45.095: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel10 – looped chain attempting to stack
*Nov 9 14:53:53.935: %TUN-5-RECURDOWN: Tunnel10 temporarily disabled due to recursive routing
*Nov 9 14:53:53.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to down
*Nov 9 14:53:53.971: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 9.9.0.4 (Tunnel10) is down: interface down
You will continue to see these messages in the logs repeatedly.
The reason is that initially the Tunnel Destination address 9.9.34.4 and 9.9.12.1 were being learnt via OSPF as underlying protocol.
Once we create EIGRP over the Tunnel 10 interface we receive the route in routing table via EIGRP causing the underlying routing for Tunnel 10 via OSPF to fail ad hence taking tunnel down which in turn causes the EIGRP to go down.
Once EIGRP goes down, route for 9.9.34.4 and 9.9.12.1 again is learnt via OSPF and hence we see the Tunnel coming up and also EIGRP neighbor ship but then the whole process keeps on repeating.
R1#sh int tu10
Tunnel10 is up, line protocol is down
Hardware is Tunnel
Internet address is 9.9.0.1/24
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 9.9.12.1, destination 9.9.34.4
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:01:01, output 00:00:54, output hang never
Last clearing of “show interface” counters 00:49:45
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 20
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
79 packets input, 6602 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
177 packets output, 21554 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
R1# sh ip route 9.9.34.4
Routing entry for 9.9.34.0/24
Known via “eigrp 100”, distance 90, metric 26882560, type internal
Redistributing via eigrp 100
Last update from 9.9.0.4 on Tunnel10, 00:00:04 ago
Routing Descriptor Blocks:
* 9.9.0.4, from 9.9.0.4, 00:00:04 ago, via Tunnel10
Route metric is 26882560, traffic share count is 1
Total delay is 50100 microseconds, minimum bandwidth is 100 Kbit
Reliability 255/255, minimum MTU 1476 bytes
Loading 1/255, Hops 1
Tunnel Interface again comes up
*Nov 9 14:54:54.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, changed state to up
Now in order to remedy this situation we can use the Front-Door VRFs on R1 and R4.
Step 1: Create Front Door VRF named FVRF on R1 and R4.
vrf definition FVRF
!
address-family ipv4
exit-address-family
Step 2: Configuring physical interface on R1 and R4 to be VRF aware:
R1#sh runn int fa0/0
Building configuration…
Current configuration : 102 bytes
!
interface FastEthernet0/0
vrf forwarding FVRF
ip address 9.9.12.1 255.255.255.0
duplex full
end
R4#sh runn int fa0/0
Building configuration…
Current configuration : 102 bytes
!
interface FastEthernet0/0
vrf forwarding FVRF
ip address 9.9.34.4 255.255.255.0
duplex full
end
Step 3: Change OSPF to be VRF aware:
R1#sh runn | s r ospf
router ospf 1 vrf FVRF
R4#sh runn | s r ospf
router ospf 1 vrf FVRF
Step4: Bind Tunnel Interface to FVRF.
R1(config)#int tu10
R1(config-if)#tunnel vrf FVRF
R4(config)#int tu10
R4(config-if)#tunnel vrf FVRF
We have not moved the Tunnel interface from Global routing table to VRF routing table, it’s just that we tell Tunnel interface to look for the underlying routing in VRF table rather than in Global routing table a was being done earlier.
Now we see the tunnel remains up and stable and also the EIGRP neighbor ship over the tunnel.
R1#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 9.9.0.4 Tu10 14 00:02:56 144 1470 0 49
R1#sh ip route vrf FVRF 9.9.34.4
Routing Table: FVRF
Routing entry for 9.9.34.0/24
Known via “ospf 1”, distance 110, metric 3, type intra area
Last update from 9.9.12.2 on FastEthernet0/0, 00:07:59 ago
Routing Descriptor Blocks:
* 9.9.12.2, from 9.9.23.3, 00:07:59 ago, via FastEthernet0/0
Route metric is 3, traffic share count is 1
R1#Sh ip route 9.9.34.4
% Subnet not in table
Continue Reading:
GRE vs IPSec: Detailed Comparison
VXLAN vs GRE: Detailed Comparison
ABOUT THE AUTHOR
I am here to share my knowledge and experience in the field of networking with the goal being – “The more you share, the more you learn.”
I am a biotechnologist by qualification and a Network Enthusiast by interest. I developed interest in networking being in the company of a passionate Network Professional, my husband.
I am a strong believer of the fact that “learning is a constant process of discovering yourself.”
– Rashmi Bhardwaj (Author/Editor)
