Low latency forwarding failure detection

2004-11-04 Thread John Kristoff

Not receiving any response for over a week after posting this query to
cisco-nsp I thought perhaps folks here might have some input.  In my
scenario, Cisco is the likely gear involved, but even if people have
vendor neutral feedback about this I'd be interesting in hearing it.

  From: John Kristoff [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: Low latency forwarding failure detection
  Date: Tue, 26 Oct 2004 17:14:57 -0500
  X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i686-pc-linux-gnu)

  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


Re: Low latency forwarding failure detection

2004-11-04 Thread Fergie (Paul Ferguson)


John,

I'm using GLBP round-robin in a specific scenario with
ip routing as the tracking mechanism, and only in this
one specific segment if the network (OSPF elsewhere), with
EIGRP as the routing protocol between R1, R2, R3, and R4:

-+---FE+-
 | |
R1R2
 | |
T3 T3
 | |
R3R4
 | |
 +FE---+-


GLBP works very well here for us based on EIGRP routing
metrics.

There's a very good GLBP config white paper on CCO.

No sure if this answers your question, or not

- ferg


-- John Kristoff [EMAIL PROTECTED] wrote:

  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?

 
--
Fergie, a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 [EMAIL PROTECTED] or
 [EMAIL PROTECTED]


Re: Low latency forwarding failure detection

2004-11-04 Thread David Barak


--- John Kristoff [EMAIL PROTECTED] wrote:

   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?

I've used GLBP, and I was pleasantly surprised at how
well it worked.  Certain types of failures were
hitless, and non-hitless failures were still pretty
fast.  I'm not sure if it's fast enough for your
application, but I thought it was great.



=
David Barak
-fully RFC 1925 compliant-



__ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com