cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Ask the Expert- SD-WAN

508
Views
0
Helpful
33
Replies
Highlighted
Beginner

GRE tunnel issue

I am experiencing a strange problem with GRE tunnels we are using to connect a remote site. There are two routers, RT1 & RT2, using HSRP & each router has its own GRE tunnel connected over the internet to a router in our network hub. I am running EIGRP over the tunnels. The problem occurs when the tunnels go down due to an internet outage, when it comes back up everything is ok except i cannot ping an NMS server at our hub, i can ping devices in the same subnet as the server but not the server. I then need to shut down the inside interfaces to switch HSRP over to router 2, which can ping the server. If the tunnels go down again then router 2 cannot ping the server as with router 1. I have noticed that after roughly 4 hours the routers are able to ping the server again. I have checked the routing tables after each outage & all the correct routes are there. The only traffic going over the active tunnel when it goes down is to & from the server so i am not sure if this has anything to do with it.

I am puzzled as to why this is happening, has anyone out there seen this issue before?

33 REPLIES 33
Advocate

Re: GRE tunnel issue

1) - what is the delay/bm metrics for the tunnels used?

2) - try reducing ther EIGRP hello and dead timers on the tunnels to say 1 hello 3 dead

3) - which is the primary and which is the secondary?

4) - you may have an EIGRP mis-match and asymentric route.

5) - have you tried using tunnel keepalives?

HTH>

Beginner

Re: GRE tunnel issue

Hi Andrew

Firstly, thanks for the quick reply.

1, I set the delay on the tunnel interface connecting to RT2 at our hub to 500050 so the tunnel to RT1 is prefered at 500000, i think thats what you are asking?

2, I'll look at that & give it a try but to be honest EIGRP seems to be working well with fast convergence when the tunnels come back up.

3, Rt1 is primary & RT2 secondary.

4, I have looked at the routing tables & all looks ok.

5, The tunnels are using keepalives.

Graeme

Advocate

Re: GRE tunnel issue

Graeme,

OK - have you made sure the delay is the SAME at both ends of the tunnel?

Can you supply the output from both devices:-

show ip eigrp int

show ip eigrp nei

show ip eigrp top

show ip route eigrp

?

Beginner

Re: GRE tunnel issue

The delay was only changed at the hub side, RT2 is still using the default.

I have attached the output you asked for so a short explanation of what is what is required:

Hub

Tunnel 2 to RT1 172.20.20.13

Tunnel 3 to RT2 172.20.20.17

RT1

Tunnel 0 to Hub 172.20.20.14

int Vlan 12 to RT2 10.10.9.2

int Vlan 190 to RT2 192.168.10.34

The server is in subnet 192.168.0.16/29

Graeme

Advocate

Re: GRE tunnel issue

Graeme,

From rt1 the route to 192.168.0.16 is via tunnel 0?

I would have thought that you would want a direct path back to the hub?

Beginner

Re: GRE tunnel issue

Hi Andrew

We are using a dedicated router inside our hub to terminate multiple VPN's & route the traffic from there.

Graeme

Advocate

Re: GRE tunnel issue

OK - so from rt1 I see no feasible sucessor for the route to 192.168.0.16 from anywhere else other than tunnel0 that goes to the hub.

Can you supply the same outputs from rt2 ??

Beginner

Re: GRE tunnel issue

Andrew

I have attached the RT2 configs.

Graeme

Advocate

Re: GRE tunnel issue

Graeme,

From looking at what you have sent I see 2 issues:-

1) Both router 1 and router 2 have the same cost to 192.168.0.16 in the eigrp table

2) Router 2 does not see the route from router 1 as a feasbile sucessor - as I am assuming that router 1 is the hsrp master, and router 2 is the standby.

what bandwidth have you configured for tun0 on rt1 and tun0 on rt2? what delay is configured on these tunnels

Ideally what you want is for tunnel 0 on rt1 to be the primary. The tunnel 0 on rt2 as the secondary with a feasbile sucessor seen from rt1. Rt1 is the hsrp master - with rt2 as the standby, so if the tunnel 0 in rt1 goes down, rt2 will distribute the route from tunnel 0 into rt1 as rt1 is the hsrp master. If rt1 goes down completly - all routes a valid.

Beginner

Re: GRE tunnel issue

Hi Andrew

Yes, RT1 is active & RT2 is the standby. I haven't configured the bandwidth on the tunnels for routers 1 & 2 only increased the delay on tunnel 3 at the hub which points to RT2 thus traffic prefers the route to RT1. I had though that load balancing traffic from the hub may have caused this issue but it still remains.

I will be back at my desk on Monday, as i am on a trip for the next 3 days so i will increase the delay at the tunnel interface on RT2 then & see what happens. If you have any other ideas to try i will have a look at these also.

Thanks for the replies.

Graeme

Advocate

Re: GRE tunnel issue

Graeme,

OK - in the hub tunnel 3 configure:-

delay 1000000

on rt2 tunnel 0

delay 1000000

HTH>

Beginner

Re: GRE tunnel issue

Hi Andrew

I have added the config on both ends of the tunnel & now i can ping the server when the tunnel comes back up. When the tunnel is down on router 1 i still cannot ping the server even though there are routes via router 2. I had increased the delay on one of the vlan interfaces on both routers but still i cannot ping the server. This is not a problem though as router 2 has taken over but i wuold like to understand why this config change worked a far as the tunnel interface is concerned.

Advocate

Re: GRE tunnel issue

OK cool, we have one issue fixed. Can you post the output of:-

show ip route

show ip route static

show ip eigrp int

show ip eigrp top

from all 3 devices?

Beginner

Re: GRE tunnel issue

Hi Andrew

The issue still remains, when i arrived this morning the tunnel had come back up 1 hour previously, can ping everything else but not the server. When i tested yesterday i shut the tunnel interface, in reality when the tunnel goes down, for what ever reason, the tunnel interface will always be up so this was probably not an accurate test. I have attached the configs you requested.