• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 265
  • Last Modified:

Dynamic routing using static routes


this may seem like a strange question, but i am trying to achieve some kind of dynamic route failover using static routes. The reason I need to do this is because some of our remote sites use Cisco 850 series routers, and don't support EIGRP.

We are the central data centre in a hub and spoke topology. All remoote sites route via the hub. Each site has a single Cisco router and connects back to the core data centre via a secure VPN tunnel over GRE. Actually, we use 2 dedicated routers at the data centre for terminating the remote site VPN tunnels. 1 router routes out over 1 provider cloud, and the other goes out over another. This gives us some redundancy for the remote sites - although they only have 1 router they have 2 VPN tunnels back to the core, if 1 router at the core went down then the other VPN tunnel would take care of the routing. This works well for sites that have EIGRP running on the router.

On sites that don't support EIGRP, i have tried to work around this by configuring a static route pointing back to the data server  network with AD of 1, and a 2nd static route pointing down the 2nd IPSEC GRE tunnel with an AD of 2. It was my understanding that, if there was a problem with the 1st tunnel, then the packets would route out of the 2nd tunnel via the static route with AD of 2.

However, it seems that when using IPSEC GRE tunnels, even if i manually shutdown the tunnel interface on the remote sites, the core site router still sees the GRE tunnel to the remote site as being up, and so does not failover to the 2nd VPN router. Therefore, the remote site sees the local tunnel interface as down, routes via the 2nd tunnel as per the higher AD, but the return packets will not arrive because the routers at the core site do not see a problem on the GRE tunnel and don't failover accordingly.

Has anybody got any suggestions on how this could be improved? Or do we simply need to use a routing protocol to achieve anything dynamic in this situation?

thanks in advance
1 Solution
Don JohnstonInstructorCommented:
The only way your static routes will fail over now is if it is a detectable failure of the physical interface.  Which is but one of many possible failures.

To accomplish what you want without dynamic routes, you'll need to use static routes with SLA.


Have you enabled keepalives on the GRE tunnel?


Router(config)#interface tunnel0
Router(config-if)#keepalive 5 4          

!--- The syntax of this command is keepalive [seconds [retries]].
!--- Keepalives are sent every 5 seconds and 4 retries.
!--- Keepalives must be missed before the tunnel is shut down.
!--- The default values are 10 seconds for the interval and 3 retries.
L-PlateAuthor Commented:
thank you both for your responses. Both options look very good, but i am trying to with the option of GRE tunnel keepalive at the moment.

i have set the keepalives at both ends of the tunnel. however, the router on the remote side of the tunnel sees the tunnel as being down when keepalives are enabled, even though it is not.

my config on the remote tunnel is as follows...

interface Tunnel179
 bandwidth 2048
 ip unnumbered Vlan1
 no ip redirects
 no ip proxy-arp
 ip mtu 1440
 ip virtual-reassembly
 keepalive 5 4
 tunnel source Dialer1
 tunnel destination
 crypto map PORTUGALWH

and for the hub site my tunnel config is as follows...

interface Tunnel178
 bandwidth 2048
 ip unnumbered GigabitEthernet0/0
 no ip redirects
 no ip proxy-arp
 ip mtu 1440
 ip virtual-reassembly
 keepalive 5 4
 tunnel source
 tunnel destination

With the above configuration, the remote site sees it's own tunnel interface 179 as being down (up/down), but the hub site still sees it's own tunnel interface 178 as being up and up. if i manually shutdown the gre tunnel interface on the remote site (int t179), then the hub site does correctly notice this and puts it own interface (t178) in to a down/down state.

so the tunnel keepalive mechanism does seem to be working from the hub, but seems to be some issue on the spoke.

any ideas what this could be?
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.


You have a crypto map at one end but not at the other.

what is the tunnel source address for Dialer 1 - Does it match the tunnel destination at the remote end?

try "debug tunnel keepalive".
L-PlateAuthor Commented:
dialer 1 IP address is don't get me wrong, these ARE fully functional IPSEC GRE tunnels. The reason you don't see the crypto map applied to the tunnel interface at the hub router is because i was told we no longer had to apply the crypto map on each tunnel interface in later IOS versions, that is - we have just applied the crypto map on the physical (outside) interface, and this seems to take care of all the IPSEC GRE tunnels.

i will take some outputs from your debug suggestion and post them back.
L-PlateAuthor Commented:
I have enabled 2 debugs - debug tunnel, and debug tunnel keepalive

these are the outputs i see relevant to the tunnel in question (tunnel is still in up / down state since keepalives enabled on the tunnel)...

277303: Oct  4 11:37:11.473 GMT: Tunnel179: sending keepalive,>62.
28.21.152 (len=24 ttl=255), counter=18840

277304: Oct  4 11:37:11.473 GMT: Tunnel179: GRE/IP encapsulated>21 (linktype=7, len=48)

277337: Oct  4 11:37:16.472 GMT: Tunnel179: sending keepalive,>62.
28.21.152 (len=24 ttl=255), counter=18841

277338: Oct  4 11:37:16.472 GMT: Tunnel179: GRE/IP encapsulated>21 (linktype=7, len=48)

277345: Oct  4 11:37:21.471 GMT: Tunnel179: sending keepalive,>62.
28.21.152 (len=24 ttl=255), counter=18842

277346: Oct  4 11:37:21.471 GMT: Tunnel179: GRE/IP encapsulated>21 (linktype=7, len=48)

Have you done the debug at the other end?
L-PlateAuthor Commented:
if i enable the debug from the hub router, the replys are received...

Oct  5 07:56:50.456: Tunnel178: sending keepalive,> (l
en=24 ttl=255), counter=1
Oct  5 07:56:50.520: Tunnel178: keepalive received,> (
len=24 ttl=245), resetting counter

but for some reason, when same test from the remote side, the replys are not received and the tunnel interface on the remote router is in up/down state

try to ping source
traceroute with source IP

do above test from HUB

and paste it

U have to block the reachability from HUB to spoke ie source to destination IP.
As remote location IP is rechable via secondary link it creates a problem.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now