This topic is to discuss the following lesson:
Hi Rene
Really liking you new website.
I’m confused about this scenario though. Although I do understand the tunnel is being disabled but when you solve it using offset list to make the route through the tunnel seem worse than through the Fastethernet link, what is the point of being able to reach 1.1.1.1/24 via the fast ethernet link. Does this defeat the object of a tunnel because you are reaching tunnel destination via the fast ethernet link?
i hope i making sense.
Hi Prash,
This scenario is only to demonstrate why recursive routing errors occur. It happens when people advertise the IP addresses that are used for the tunnel interfaces through the tunnel itself. Normally this is just a configuration error that people might make. On the other hand you might encounter it on the CCIE lab exam 
please check this ip entries (3.3.3.3)
What about it?
Thank you boss
great website.
keep on the good work,
really helpful.
Really useful lessons! Thanks.
Your network diagrams are really beautiful. Do you use Visio? If so, what stencils. Care for sharing them?
Hi Rikard,
Thanks and you are welcome. I use Visio and the stencils from visiocafe.com, they make great stuff!
Rene
Hi Rene,
Your post is very informative bro…keep it up!!
Would you please help me understand what you really mean by this rule #1?
(Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.)
What if you used the network connected to R2 as the destination IP? like:
R1(config)#interface tunnel 1
R1(config-if)#tunnel source fa0/0
R1(config-if)#ip address 192.168.13.1 255.255.255.0
R1(config-if)#tunnel destination 192.168.23.3
-
R3(config)#interface tunnel 1
R3(config-if)#tunnel source Fa0/0
R3(config-if)#ip address 192.168.13.3 255.255.255.0
R3(config-if)#tunnel destination 192.168.12.1
Would we still have the same RR issues?
Please give me your comment
Thanks.!
Hi Rene,
Very interesting post and topics.
please woul you give me more details on the 1st rule you listed to fix the issues? (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering)
What if we set the tunnels this way below, would we have the same rr issue?
R1(config)#interface tunnel 1
R1(config-if)#tunnel source fa0/0
R1(config-if)#ip address 192.168.13.1 255.255.255.0
R1(config-if)#tunnel destination 192.168.23.3
-
R3(config)#interface tunnel 1
R3(config-if)#tunnel source Fa0/0
R3(config-if)#ip address 192.168.13.3 255.255.255.0
R3(config-if)#tunnel destination 192.168.12.1
Any comment will be appreciated
Thanks.
Hi Thom,
In my example, R1 and R3 learn about each others tunnel destination IP address through R2 with a hop count of 2.
Once the tunnel is established, they learn about each others destination IP address through the tunnel with a hop count of 1.
Since 1 is a better metric than 2, they remove their entry from the routing table that points to R2 and insert an entry that points to the tunnel interface.
The tunnel now collapses…because we are trying to reach the tunnel destination through the tunnel itself. The same problem will occur if you configure OSPF on the tunnel and advertise the tunnel destination IP addresses in OSPF.
OSPF has a lower (better) administrative distance than RIP, so the RIP entries will be removed and the OSPF entries will be installed…and the tunnel collapses.
In your example, when you use the IP addresses on the physical interfaces you will still have some issues because the hop count to the destination IP address will be 1 through R2 and also 1 through the tunnel.
When RIP has two paths with the same metric, it will do load balancing…
So in short, make sure that you never learn the destination IP address of the tunnel through the tunnel itself
hey Rene,
i got you bro!! it’s correct.
but i’d off adding both the phys interface and the tunnel in my routing protocol and adjust the cost (higher) on the tunnel interface to deal with the issues. i am wrong?
If you increase the metric on the tunnel interface then it will solve your problem since the path through the fastethernet interfaces is better.
Hi Rene, thank you for the excellent post.
And if I’m running OSPF instead of RIP, how could I solve this situation since my tunnel has a lower cost than my physical interfaces?
I tried to filter the tunnel destination address (LSA3) with distribute-list IN on the tunnel interface, but it didn’t work. Any idea?
Thanks!
Hi Alberto,
You can also change the administrative distance for the OSPF routes that you use to reach the tunnel destinations:
Or another simple method, set the OSPF cost on the tunnel interfaces to a very high value…
Rene
Hi Rene, thank you for your answer.
But setting the ospf cost on tunnel to a high value will lead to no use this path. And if I would like to use this path?
I think I’m not able to use OSPF as my IGP and use it on tunnel interface for this reason.
Thanks!
Hi Alberto,
Try changing the AD for the tunnel destinations. If you use OSPF to learn the tunnel destinations the routing table might look like this (simplified):
O 3.3.3.0/24 [110/2] (the normal path to reach the tunnel destination)
Once the tunnel comes up:
O 3.3.3.0/24 [110/1]
Since the cost is 1, the previous route is deleted and we have a recursive routing issue. Administrative Distance is checked before we look at the metric so basically you want your router to look like this:
O 3.3.3.0/24 [100/2] (normal path)
O 3.3.3.0/24 [110/1] (path through tunnel)
Change the AD so the tunnel destination has a lower value. This ensure that when you learn the tunnel destination through the tunnel itself that it won’t be used. You can use the distance command under the OSPF process for this.
Once the tunnel comes up
Hi Rene,
But when we change the AD for the ospf process, all the routes are affected (normal path and path via tunnel). What do you suggest doing? Create another ospf process would be an alternative?
Thanks!
Hi rene . this example very nice … thank you