[c-nsp] Low latency forwarding failure detection

John Kristoff jtk at northwestern.edu
Tue Oct 26 18:14:57 EDT 2004


I've got a situation where something like HSRP seems appropriate for a
redundant default gateway configuration.  However, this application will
want very low latency in finding and using the alternative gateway.
Note, while the hosts have two NICs, they are both on the same subnet
with one interface the default source and sink as long as it has link.
I don't get to change this behavior.

Default HSRP failure detection time however is likely not quick enough
to bring a standby interface up to get traffic moving again.  I see that
HSRP provides for hello and hold times in milliseconds.

I have a few questions for people who may have had a need to get very
low latency recovery of links and routers.  Have you used HSRP to do
this?  On a typical local ethernet (gig) LAN configuration, what sorts
of latencies and packet loss have you seen during a failure event?

I'm cco-familiar with GLBP.  It appears to have essentially the same
timing knobs with the ability to actively load balance traffic.  Is
my assumption that some traffic will not experience any packet loss
if it is not using the failed path correct?  For anyone who has used
this, was the added complexity of this protocol worth it?

As a general question... are people looking at implementing BFD?

  <http://www.ietf.org/html.charters/bfd-charter.html>

Here I'm draft-familiar with what this is and I believe some vendors
have code for it, but I've yet to try it.  I believe the spec is held
up for security and IESG review.  This work looks very useful for some
related applications going forward.  For this crowd, is this deployable
and useful for minimizing forwarding failure time?

This doesn't appear to be on the roadmap for HSRP/GLBP from what I
can tell, but perhaps that would a worthwhile application of BFD?

Are there other things people are doing (besides plain old load sharing)
to get very low latency failover?

John


More information about the cisco-nsp mailing list