GRE tunnel unstable

[mcandial1]

Hi! I´m having stability issues with a multipoint GRE arquitecture.

Everything connects fine but after a while everything loses connectivity. I try this by pinging tunnel interfaces. I left it pinging for a while and suddenly they become back online and everything keeps working fine. But then again, after some time of inactivity (a couple of minutes) everything goes down.

I´ve checked show dmvpn and it looks fine, also show ip nrhp detail looks ok.

Here´s the configuration for the hub:

ip dhcp pool LAN hub
network 192.168.10.0 255.255.255.0
default-router 192.168.10.1
dns-server 8.8.8.8 8.8.4.4

interface Loopback0
ip address x.x.x.x 255.255.255.255
ip nat enable

interface Tunnel1
description VPN Light Casa Central
ip address 10.0.7.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication test
ip nhrp map multicast dynamic
ip nhrp network-id 100
ip nhrp holdtime 600
delay 1000
tunnel source x.x.x.x
tunnel mode gre multipoint
tunnel key 100

!
interface Ethernet0
no ip address
!
interface Ethernet0.302
description Prueba
encapsulation dot1Q 301
ip address y.y.y.y 255.255.255.252
ip nat enable

!
interface FastEthernet0
switchport access vlan 4
no ip address
!
interface FastEthernet1
switchport access vlan 3
no ip address

!
interface Vlan3
description public ip
ip address x.x.x.x 255.255.255.252
!
interface Vlan4
description LAN hub
ip address 192.168.10.1 255.255.255.0
ip nat enable

ip nat source list client-list interface Loopback0 overload
ip route 0.0.0.0 0.0.0.0 y.y.y.y
ip route 192.168.11.0 255.255.255.0 10.0.7.2
ip route 192.168.12.0 255.255.255.0 10.0.7.3

And for the spokes (it´s behind a ADSL modem):

ip dhcp pool spoke
network 192.168.12.0 255.255.255.0
default-router 192.168.12.1
dns-server 8.8.8.8 8.8.4.4

interface Tunnel3
ip address 10.0.7.3 255.255.255.0
no ip redirects
ip mtu 1400
ip nat enable
ip nhrp authentication test
ip nhrp map multicast dynamic
ip nhrp map multicast x.x.x.x
ip nhrp map 10.0.7.1 x.x.x.x
ip nhrp network-id 100
ip nhrp holdtime 600
ip nhrp nhs 10.0.7.1
ip virtual-reassembly in
delay 1000
keepalive 60 60
tunnel source Vlan2
tunnel mode gre multipoint
tunnel key 100

!
interface FastEthernet1
description ADSL modem network
switchport access vlan 2
no ip address
!
interface FastEthernet2
description LAN spoke
switchport access vlan 3
no ip address

interface Vlan2
ip address dhcp
ip nat enable
!
interface Vlan3
description LAN
ip address 192.168.12.1 255.255.255.0
ip nat enable

ip nat source list client-list interface Vlan2 overload
ip route 0.0.0.0 0.0.0.0 192.168.1.10
ip route 192.168.0.0 255.255.0.0 10.0.7.1
!
ip access-list standard client-list
permit 192.168.12.0 0.0.0.255

Any ideas? Thanks!

[Philip D'Ath]

Are you using a dynamic routing protocol?  Most of these issues happen when using a dynamic routing protocol, and you advertise the tunnel outside interfaces over the tunnel itself, causing it to flap.

[mcandial1]

No, static routes. Is there a solution for that?

[Philip D'Ath]

What model routers are you using, and what version of IOS?

[mcandial1]

I have 3 routers, 2 888VA for hub & spoke and 1 888

888: 150-1.M5

887: 151-4.M4

Updating IOS is not an option

[mcandial1]

I think I've fixed this with ip sla pinging tunnel interfaces.

But now another issue showed up, I can´t reach a spoke from another spoke. I reach them from hub with no problem, and from each spoke I reach the hub. But I can´t reach spokes.

The odd thing is when I do a show dmvpn

One spoke shows:

Interface: Tunnel2, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
2 x.x.x.x                10.0.7.1 UP 00:40:52 S
                             10.0.7.3 UP 00:00:22 D

The other spoke completes the table ok. 

The strangest thing is that if I reload both spokes the tables switches, the one with both entries now show only one (one ok, one empty) and the other one now has it´s table complete.

Any ideas?

[Philip D'Ath]

Do your spokes have public IPv4 addreses on them?  If not you may not be able to do spoke to spoke communications.

When using DMVPN/iWAN you want to make sure all the routes have public IPv4 addresses on them and are not running through NAT, otherwise you are likely to have lots of problems.

[mcandial1]

They don´t, actually both are NATed, and that´s the whole point why I'm using this. I need to connect sites behind different ISPs modems.

No solutions for this?

[Philip D'Ath]

You are likely to have a lot of support issues with such a configuration.  At least get your head end so it is not behind NAT.

You need to make sure all the ISP modes NAT IP protocol 50, and UDP ports 500 and 4500 through to your DMVPN router.

Also unless you can get up to at least 15.2 for your IOS version everywhere you are highly likely to have issues.

Why can't you replace the ISP supplied router so you can get a public IPv4 address on the outside of the spokes.

Personally, I would not persue the approach you have taken, as I think it is likely to have a lot of ongoing reliably issues and support problems.