With a view to perceive using Entrance Door VRFs allow us to use a easy topology as under the place we are going to create a Easy GRE tunnel between R1 and R4.
Community Topology: Use of Entrance door VRFs
Each R1 and R4 will study in regards to the tunnel vacation spot tackle through underlying protocol i.e. OSPF in our case.
As soon as the tunnels are up/up we are going to create EIGRP neighborship over the tunnel interfaces between R1 and R4.
Tunnel Configuration of R1:
interface Tunnel10
ip tackle 9.9.0.1 255.255.255.0
tunnel supply 9.9.12.1
tunnel vacation spot 9.9.34.4
finish
Tunnel Configuration on R4:
interface Tunnel10
ip tackle 9.9.0.4 255.255.255.0
tunnel supply 9.9.34.4
tunnel vacation spot 9.9.12.1
finish
At present route about tunnel vacation spot 9.9.12.1 & 9.9.34.4 are learnt through OSPF
R1#sh ip route 9.9.34.4
Routing entry for 9.9.34.0/24
Identified through “ospf 1”, distance 110, metric 3, kind intra space
Final replace from 9.9.12.2 on FastEthernet0/0, 00:33:19 in the past
Routing Descriptor Blocks:
* 9.9.12.2, from 9.9.34.4, 00:33:19 in the past, through FastEthernet0/0
Route metric is 3, site visitors share rely is 1
R4#sh ip route 9.9.12.1
Routing entry for 9.9.12.0/24
Identified through “ospf 1”, distance 110, metric 3, kind intra space
Final replace from 9.9.34.3 on FastEthernet0/0, 00:33:33 in the past
Routing Descriptor Blocks:
* 9.9.34.3, from 9.9.12.2, 00:33:33 in the past, through FastEthernet0/0
Route metric is 3, site visitors share rely is 1
Now allow us to create EIGRP neighbor ship between R1 and R4 and let’s see what occurs:
R1#sh runn | s r eigrp
router eigrp 100
community 9.9.0.0 0.0.255.255
passive-interface default
no passive-interface Tunnel10
R4# sh runn | s r eigrp
router eigrp 100
community 9.9.0.0 0.0.255.255
passive-interface default
no passive-interface Tunnel10
Now let’s verify the logging on R1 or R4 to see what occurred:
Under log exhibits we constructed 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
Right here we see the primary the EIGRP neighbor ship goes down after which Tu 10 interface goes down as a result of recursive routing
*Nov 9 14:53:45.095: %ADJ-5-PARENT: Midchain dad or mum upkeep for IP midchain out of Tunnel10 – looped chain trying to stack
*Nov 9 14:53:53.935: %TUN-5-RECURDOWN: Tunnel10 quickly disabled as a result of recursive routing
*Nov 9 14:53:53.935: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, modified 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’ll proceed to see these messages within the logs repeatedly.
The reason being that originally the Tunnel Vacation spot tackle 9.9.34.4 and 9.9.12.1 had been being learnt through OSPF as underlying protocol.
As soon as we create EIGRP over the Tunnel 10 interface we obtain the route in routing desk through EIGRP inflicting the underlying routing for Tunnel 10 through OSPF to fail advert therefore taking tunnel down which in flip causes the EIGRP to go down.
As soon as EIGRP goes down, route for 9.9.34.4 and 9.9.12.1 once more is learnt through OSPF and therefore we see the Tunnel developing and in addition EIGRP neighbor ship however then the entire course of retains on repeating.
R1#sh int tu10
Tunnel10 is up, line protocol is down
{Hardware} is Tunnel
Web tackle 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 supply 9.9.12.1, vacation spot 9.9.34.4
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
Checksumming of packets disabled
Tunnel TTL 255, Quick tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel obtain bandwidth 8000 (kbps)
Final enter 00:01:01, output 00:00:54, output grasp by no means
Final clearing of “present interface” counters 00:49:45
Enter queue: 0/75/0/0 (measurement/max/drops/flushes); Whole output drops: 20
Queueing technique: fifo
Output queue: 0/0 (measurement/max)
5 minute enter fee 0 bits/sec, 0 packets/sec
5 minute output fee 0 bits/sec, 0 packets/sec
79 packets enter, 6602 bytes, 0 no buffer
Acquired 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 enter errors, 0 CRC, 0 body, 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
Identified through “eigrp 100”, distance 90, metric 26882560, kind inner
Redistributing through eigrp 100
Final replace from 9.9.0.4 on Tunnel10, 00:00:04 in the past
Routing Descriptor Blocks:
* 9.9.0.4, from 9.9.0.4, 00:00:04 in the past, through Tunnel10
Route metric is 26882560, site visitors share rely is 1
Whole delay is 50100 microseconds, minimal bandwidth is 100 Kbit
Reliability 255/255, minimal MTU 1476 bytes
Loading 1/255, Hops 1
Tunnel Interface once more comes up
*Nov 9 14:54:54.039: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel10, modified state to up
Now so as to treatment this case we will use the Entrance-Door VRFs on R1 and R4.
Step 1: Create Entrance Door VRF named FVRF on R1 and R4.
vrf definition FVRF
!
address-family ipv4
exit-address-family
Step 2: Configuring bodily interface on R1 and R4 to be VRF conscious:
R1#sh runn int fa0/0
Constructing configuration…
Present configuration : 102 bytes
!
interface FastEthernet0/0
vrf forwarding FVRF
ip tackle 9.9.12.1 255.255.255.0
duplex full
finish
R4#sh runn int fa0/0
Constructing configuration…
Present configuration : 102 bytes
!
interface FastEthernet0/0
vrf forwarding FVRF
ip tackle 9.9.34.4 255.255.255.0
duplex full
finish
Step 3: Change OSPF to be VRF conscious:
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’ve not moved the Tunnel interface from World routing desk to VRF routing desk, it’s simply that we inform Tunnel interface to search for the underlying routing in VRF desk quite than in World routing desk a was being achieved earlier.
Now we see the tunnel stays up and secure and in addition the EIGRP neighbor ship over the tunnel.
R1#sh ip eigrp nei
EIGRP-IPv4 Neighbors for AS(100)
H Tackle Interface Maintain 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 Desk: FVRF
Routing entry for 9.9.34.0/24
Identified through “ospf 1”, distance 110, metric 3, kind intra space
Final replace from 9.9.12.2 on FastEthernet0/0, 00:07:59 in the past
Routing Descriptor Blocks:
* 9.9.12.2, from 9.9.23.3, 00:07:59 in the past, through FastEthernet0/0
Route metric is 3, site visitors share rely is 1
R1#Sh ip route 9.9.34.4
