Solved: GRE Tunnel Not Working

visitor68 · ‎04-21-2009

Hi, Im trying to set up a GRE tunnel in a lab and Im getting a recursive routing issue.

What I would like to accomplish is to have 2 routers establish a GRE tunnel between them, create an eigrp neighbor relationship, and begin exchanging routes.

As it is, each router has no neighbors because each is connected to a switch with nothing but statics to facilitate the creation of the tunnel. So, the expectation is that the tunnel will come up, negotiate an eigrp neighborship and exchange routes...

Not working...:-(

Here are the configs. Can someone tell me where exactly Im going wrong?

L3 SWITCH

interface Loopback1

ip address 1.1.1.3 255.255.255.255

!

interface Loopback2

ip address 2.2.2.3 255.255.255.255

!

interface Loopback3

ip address 3.3.3.3 255.255.255.255

!

interface Loopback4

ip address 4.4.4.3 255.255.255.255

!

interface Tunnel1

description GRE TUNNEL TO ROUTER 1

ip address 50.50.50.1 255.255.255.0

tunnel source 20.20.20.1

tunnel destination 1.1.1.1

interface FastEthernet0/22

description ROUTED CROSSLINK TO SWITCH 1

no switchport

ip address 20.20.20.1 255.255.255.252

router eigrp 10

network 1.1.1.3 0.0.0.0

network 2.2.2.3 0.0.0.0

network 3.3.3.3 0.0.0.0

network 4.4.4.3 0.0.0.0

network 20.20.20.1 0.0.0.0

network 50.50.50.1 0.0.0.0

network 172.16.14.3 0.0.0.0

network 172.16.15.3 0.0.0.0

no auto-summary

eigrp log-neighbor-changes

!

ip classless

ip route 0.0.0.0 0.0.0.0 20.20.20.2

ip route 1.1.1.1 255.255.255.255 20.20.20.2

============================================================

ROUTER

interface Loopback0

ip address 1.1.1.1 255.255.255.255

ip virtual-reassembly

!

interface Loopback1

ip address 5.5.5.5 255.255.255.255

!

interface Loopback2

ip address 6.6.6.6 255.255.255.255

!

interface Loopback3

ip address 7.7.7.7 255.255.255.255

!

interface Loopback4

ip address 8.8.8.8 255.255.255.255

!

interface Tunnel1

ip address 50.50.50.2 255.255.255.0

tunnel source 1.1.1.1

tunnel destination 20.20.20.1

!

interface FastEthernet0/0

ip address 10.0.0.1 255.255.255.252

ip accounting output-packets

ip nat outside

ip virtual-reassembly

speed 100

full-duplex

!

router eigrp 10

network 1.0.0.0

network 5.0.0.0

network 6.0.0.0

network 7.0.0.0

network 8.0.0.0

network 10.0.0.1 0.0.0.0

network 50.50.50.2 0.0.0.0

no auto-summary

!

no ip http server

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 10.0.0.2

!

02:27:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

02:27:18: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 50.50.50.1 (Tunnel1) is up: new adjacency

02:27:27: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing

02:27:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

02:27:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 50.50.50.1 (Tunnel1) is down: interface down

02:28:28: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

02:28:28: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 50.50.50.1 (Tunnel1) is up: new adjacency

02:28:37: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing

Edison Ortiz · ‎04-21-2009

That's correct.

20.20.20.0/30 shouldn't be in the EIGRP routing process since it's used as the tunnel source for the L3 switch.

With that said, you shouldn't use a loopback that is advertised by EIGRP as a source or destination in the tunnel - I recommend using the egress interfaces on both devices and don't advertise these interfaces in EIGRP.

__

Edison.

View solution in original post

Edison Ortiz · ‎04-21-2009

A router can't learn the tunnel destination IP address via the tunnel hence the recursive problem.

You need to modify your config as follow:

L3 Switch

interface Tunnel1

description GRE TUNNEL TO ROUTER 1

ip address 50.50.50.1 255.255.255.0

tunnel source 20.20.20.1

tunnel destination 10.0.0.1

router eigrp 10

no network 20.20.20.1 0.0.0.0

ROUTER

interface Tunnel1

ip address 50.50.50.2 255.255.255.0

tunnel source 10.0.0.1

tunnel destination 20.20.20.1

router eigrp 10

no network 10.0.0.1 0.0.0.0

HTH,

__

Edison.

!

visitor68 · ‎04-21-2009

Hi, Edison:

Hope you;re having a good day.

Thank you for that quick response.

before you responded, however, I made some changes after I refreshed my memory a little better on what exactly is meant by recursive tunnel routing.

What I did on the L3 switch was to stop advertising/running eigrp on the 20.20.20.0 network.

On the router, I created a static route to the tunnel destination, but I probably didnt have to do that because I already had a default route.

I think the one command that really fixed it was on the L3 switch, in which I stopped advertising the 20.20.20.0 network because that included the tunnel destination.

Your thoughts?

Thanks

Edison Ortiz · ‎04-21-2009

That's correct.

20.20.20.0/30 shouldn't be in the EIGRP routing process since it's used as the tunnel source for the L3 switch.

With that said, you shouldn't use a loopback that is advertised by EIGRP as a source or destination in the tunnel - I recommend using the egress interfaces on both devices and don't advertise these interfaces in EIGRP.

__

Edison.

visitor68 · ‎04-21-2009

Very well, sir.

Thank you.

visitor68 · ‎04-22-2009

Edison:

Without keepalives configured on the tunnel interfaces, and without using a dynamic routing protocol (just statics), what keeps a tunnel interface "up"?

I did have eigrp configured between tunnel endpoints yesterday, but I removed it and am just using static routes to destination networks that point to the tunnel:

ip route 5.5.5.5 255.255.255.255 tunnel1

I also disabled keepalives.

Yet the tunnel stays up forever.

Why?

Thanks

Edison Ortiz · ‎04-22-2009

A GRE tunnel will come up as long as the source interface of the tunnel is up and the destination IP in the routing table.

The keepalive feature enables the ability to bring down the tunnel if the far end is unreachable. The destination IP can be in the routing table (static, for instance) and at the same time be unreachable.

For more information, please take a moment to read this document:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008040a17c.shtml

HTH,

__

Edison.

visitor68 · ‎04-22-2009

Hi, Edison:

I appreciate the answer.

Im pretty familiar with the keepalive system and the documentation was easy to find. I actually read that document already.

"A GRE tunnel will come up as long as the source interface of the tunnel is up and the destination IP in the routing table."

This is the part I didnt know about. And I cant seem to find a document that discusses this point.

Do you know of one?

Thanks

visitor68 · ‎04-22-2009

OK, nevermind.

I did a copy and paste of that statement and I got a hit on Google.

Its a Cisco document on keepalives, but different from the one you posted.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml

Thanks!

Edison Ortiz · ‎04-22-2009

No, that part I tested in the Lab.

__

Edison.

pszczola1 · ‎04-22-2009

Hello,

If I can add something to this discussion. I had recently the same issue. I couldn't remove my tunnel source address from eigrp, since it was a ingress interface of my router facing LAN. I was able to solve the recursive routing problem, by adding the static route to the tunnel destination on each of the routers.

This document is quite good.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml