Site 2 Site VPN tunnel dropping.

[spencercook]

Hi,

I have a an issue with a VPN/GRE tunnel.  Our edge router is sending alerts as follows

03/10/2013 10:24 : DUAL-5-NBRCHANGE 3193: Oct 3 09:24:10.080: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.198.141 (Tunnel10) is down: holding time expired

Then the Core router sends

03/10/2013 10:24 : DUAL-5-NBRCHANGE 3919009: Oct 3 09:24:10.152: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.198.142 (Tunnel10) is down: Interface Goodbye received

Then the tunnel comes up again.  We're getting several hundred of these each day.

Core router 2851 ios 12.4

Edge router 1941 ios 15.1

The Core has 8 GRE/VPN tunnels, all configured exactly the same (copy and paste), and only the IP address for each tunnel interface is different.

The Edge is one of 8 same spec/build/config routers, with the exception of IP address for the tuennel interface and LAN IP addressing.

Only 1 of the 8 tunnels has this issue.

Has anyone any ideas?

Thanks.

[hiru_pras]

Hi,

How often the GRE tunnel goes down?

Are the tunnels over the internet?

Did you check the performance of the path and the MTU?

Set keepalive on the GRE tunnel and run debug tunnel keepalive

Regards,

Hiraman

[Hardi Ahmed]

Hi,

first of all you need to check your routing protolcol its the configuration, also the IP address that been assigned from both ends to GRE interfaces and to the real interface.

this issue some times cause by other commponents that participating in creating the tunnel, and some time by the ISPs if you have the interconnection between two routers in two different locations.

I can provide more help if you post the result of (show log) on both routers.

regards,

[Sandeep Choudhary]

HI,

We run EIGRP over GRE/IPSec tunnels to lots of remote routers. We have  seen this EIGRP neighbor instability issue, more at some locations and  less at others. Frequently one side drops the neighbor relationship and  sends a "goodby" to the neighbor. I assume that it has to do with packet  loss dropping some of the EIGRP hello messages. We found that by  increasing the EIGRP timers we reduced the frequency with which we see  the problem (we are using 15 and 45 rather than the default 5 and 15).

** aslo check tunnel interface MTU size:)

or

"If no hellos are received within the hold time, which is 15 seconds  by default on most links, the router informs the neighbor that the  neighbor relationship has been torn down and logs a syslog message."

1. Send a stream of 10000 count, once using 100 byte and once using 1500 byte packets,using extended

ping, to the neighbor's directly connected interface IP address. Are there any packet drops or time

outs?

Does the neighbor respond if you ping the EIGRP multicast address 224.0.0.10?

2.  Perform "debug eigrp packet hello" on both routers to verify that the  neighbors are ending and receiving EIGRP hello packets.

Check the routing table entry to verify the next-hop address is correct for the neighbor.

3.  Other possibilities that can bring the neighbor relationship down are  unidirectional links, uncommon subnet mismatches, mismatched masks,  layer 2 problems, ACL deny statement, etc.

The detailed steps can be found here:

Troubleshooting EIGRP - Neighbor Check

http://www.cisco.com/warp/public/103/trouble_eigrp.html#nc

Regards

Hope it helps

[Vasilii Mikhailovskii]

Hello.

Have you fixed an issue?

03/10/2013 10:24 : DUAL-5-NBRCHANGE 3193: Oct 3 09:24:10.080: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 192.168.198.141 (Tunnel10) is down: holding time expired

Then the Core router sends

03/10/2013 10:24 : DUAL-5-NBRCHANGE 3919009: Oct 3 09:24:10.152: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.198.142 (Tunnel10) is down: Interface Goodbye received

Says that for some reason connectivity became unidirectional: spoke can reach hub, but misses hub's hello.

It could be a result of:

• bandwidth statument missed under interface configuration;
• if using QoS, EIGRP could suffer of improper configuration.

Please provide running configuration for Tunnel10 on both sides.

[spencercook]

Thanks all for your help, but in our organisations true to form ways, Our staff have moved out of that shared building and we've been looking into a fault for users that don't exist.  It's now shut down.