GRE tunneling with DDR backup through a lossy medium (Wireless-EVDO)

Unanswered Question
Mar 21st, 2007
User Badges:

Hi, I am looking for a method of providing DDR backup support to our hosts currently using EVDO Internet connections. GRE tunneling seems like just the ticket, although I am not dealing with a medium that is either up or down, but that suffers varying degrees of packet loss. I know I can set up a GRE tunnel with keepalives in order to get by with a little or even a lot of packet loss, but my issue here is that there doesn?t seem to be any way to specify how many successive keepalives should be received before restoring the tunnel to an up/up state after having been brought down. For a configuration like this to work, I am thinking I will need the tunnel to remain down until the packet loss subsides rather than just coming up as soon as a keepalive successfully goes round-trip, which will continually happen even during a very lossy period. Is there a way to configure GRE for this, or even another method of providing a reliable, self restoring DDR implementation in this type of environment? Any help is appreciated! Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
bbaley Wed, 03/28/2007 - 06:34
User Badges:

You can configure the keepalive time interval, which is the frequency at which the Cisco IOS software sends messages to itself (Ethernet and Token Ring) or to the other end (serial and tunnel), to ensure that a network interface is alive. The interval is adjustable in 1-second increments down to 1 second. An interface is declared down after three update intervals have passed without receiving a keepalive packet unless the retry value is set higher. Refer URL

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/grekpliv.htm#1025872



cdowdy Wed, 03/28/2007 - 07:11
User Badges:

Thank you for the reply! Yes, I was hoping that this solution would also allow me to specify how many successive keepalives must be received before placing the tunnel back in an up/up state. I believe the default for this is not configurable and is set at only one successful keepalive to restore the tunnel. This will cause my tunnel to keep coming back up, even though packet loss is still severe. If I could only configure it to wait for maybe 5 successive keepalives on maybe 10 second intervals before coming back up, this would be perfect.

Actions

This Discussion