Low latency forwarding failure detection
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 <jtk@northwestern.edu> To: cisco-nsp@puck.nether.net 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
--- John Kristoff <jtk@northwestern.edu> 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
participants (2)
-
David Barak
-
John Kristoff