GRE Tunnel Recursive Routing Error


(Rene Molenaar) #5

What about it? :slight_smile:


(system) #6

Thank you boss


(system) #7

great website.
keep on the good work,
really helpful.


(system) #8

Really useful lessons! Thanks.

Your network diagrams are really beautiful. Do you use Visio? If so, what stencils. Care for sharing them?


(Rene Molenaar) #9

Hi Rikard,

Thanks and you are welcome. I use Visio and the stencils from visiocafe.com, they make great stuff!

Rene


(system) #10

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.!


(system) #11

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.


(Rene Molenaar) #12

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 :slight_smile:


(system) #13

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?


(Rene Molenaar) #14

If you increase the metric on the tunnel interface then it will solve your problem since the path through the fastethernet interfaces is better.


(system) #15

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!


(Rene Molenaar) #16

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


(system) #17

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!


(Rene Molenaar) #18

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


(system) #19

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!


(system) #20

Hi rene . this example very nice … thank you


(Rizwan H) #21

Thanks Rene

I like the way you teach, you are my mentor since CCNP :wink:


(Rene Molenaar) #22

Thanks Rizwan!


(Eng_ A) #23

Hello Rene,
Its Ammar, just registered again :slight_smile: The topic is excellent and thank you for the great explanation.

Ammar,
CCIE R&S ( written)


(Rene Molenaar) #24

Thanks Ammar!