Understanding Use of Front door VRFs

Rashmi Bhardwaj | Blog,Config & Troubleshoot,Protocol,Routing & Switching
Advertisements

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.

Advertisements

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

Advertisements

Leave a Comment

Your email address will not be published. Required fields are marked *

Shopping Cart
Select your currency
INR Indian rupee
Scroll to Top