Hi,
I have a problem relating to GRE connectivity that I just can't pinpoint the cause of.
I have a customer with 3 sites that currently connect in a hub-and-spoke fashion. Site 'H' is the hub site with sites 'A' and 'G' connecting to 'H' via 9.6kbps serial links. The network connections are only used for control systems and therefor high bandwidth is not essential. See diagram 'design1.jpg' below:
'Router-H' is a Cisco 2811 router, while 'Router-G' and 'Router-A' are both Cisco 1841 routers. 'Router-H' is running Advanced IP Services 12.4(22)YB4 and 'Router-G' and 'Router-A' are both running IP Base 12.4(22)YB4. This version of IOS is currently used because it is a requirement to support the HWIC-3G-GSM cards installed in all 3 routers, which will be used as part of a later project.
The network is being migrated away from the serial links to a managed WAN with copper ethernet handoff. The managed WAN is run by a different business unit and does not route RFC1918 addressing through the WAN. As such, we are configuring a set of GRE tunnels in a hub-and-spoke fashion (basically providing the same connectivity the legacy serial links do) between the 3 sites. Again, 'Router-H' is the hub router with 2 GRE tunnels configured to both 'Router-G' and 'Router-A'. See diagram 'design2.jpg' below:
When the GRE tunnels were first configured, they all came up and had IP connectivity running across both tunnels. The problem was experienced a few hours after the tunnels were configured, where they just dropped off and went into a 'down' state for no known reason (we have keepalives configured across both GRE tunnels). For some reason, the tunnels would not re-establish connectivity and return to an 'up' state. In an attempt to re-establish tunnel connectivity, we issued a 'shut' and 'no shut' on the tunnel interfaces at both ends of the tunnels, but with no success. After some fiddling around, we found the only way to restore tunnel connectivity was to basically erase the tunnel configuration at both ends ('no int tunnel 1', 'no int tunnel 2') and then re-apply the configuration. After re-applying the configuration from scratch the tunnels all re-established. However, again, after a few hours the tunnels dropped for no apparent reason and the only way to get them to re-establish was to repeat the process of erasing the tunnel configurations and re-applying. This is continually happening so we have been forced to restore the legacy serial links until we can resolve the GRE connectivity issues.
The GRE configuration is pretty straight forward:
'Router-H' configuration:
interface Loopback0
ip address 134.xxx.zzz.131 255.255.255.255
no ip redirects
no ip unreachables
no ip proxy-arp
!
interface Tunnel1
description Tunnel to Router-A
ip address 10.10.10.1 255.255.255.240
ip mtu 1500
keepalive 10 3
tunnel source Loopback0
tunnel destination 134.xxx.zzz.130
!
interface Tunnel2
description Tunnel to Router-G
ip address 10.10.20.1 255.255.255.240
ip mtu 1500
keepalive 10 3
tunnel source Loopback0
tunnel destination 134.xxx.zzz.129
!
interface FastEthernet0/1
ip address 134.xxx.yy.90 255.255.255.252
duplex auto
speed auto
!
'Router-G' configuration:
interface Loopback0
ip address 134.xxx.zzz.129 255.255.255.255
no ip redirects
no ip unreachables
no ip proxy-arp
!
interface Tunnel1
description Tunnel to Hastings
ip address 10.10.20.2 255.255.255.240
ip mtu 1500
keepalive 10 3
tunnel source Loopback0
tunnel destination 134.xxx.zzz.131
!
interface FastEthernet0/1
ip address 134.xxx.yy.86 255.255.255.252
duplex auto
speed auto
!
'Router-A' configuration:
interface Loopback0
ip address 134.xxx.zzz.130 255.255.255.255
no ip redirects
no ip unreachables
no ip proxy-arp
!
interface Tunnel1
description Tunnel to Hastings
ip address 10.10.10.2 255.255.255.240
ip mtu 1500
keepalive 10 3
tunnel source Loopback0
tunnel destination 134.xxx.zzz.131
!
interface FastEthernet0/1
ip address 134.xxx.yy.82 255.255.255.252
duplex auto
speed auto
!
At one point we thought it was a connectivity issue with the managed WAN but the fact that the GRE tunnels do establish when you first apply the configuration has led us away from this thinking at this stage. Another train of thought is that it is a bug of some sort, but we have tested running GRE tunnels over the serial links on the same hardware and this works fine, so we are not focusing our attention on this train of thought.
Unfortunately we do not have configuration access to the managed WAN but do have access to an Engineer who supports the managed WAN.
Has anyone out there experienced issues like this, or can anyone offer any suggestions/thoughts on where we should look..? All reports from the managed WAN engineer are that there is no access-list filtering in the WAN blocking GRE connectivity. ICMP ping connectivity is also not blocked.
Thanks in advance.
