Hi guys, Couple of points:
* certainly IPSLA can be used. However the following needs to weighed: - IPSLA follows the routing table, so if the destination becomes reachable via another path, ISPSLA (outbound) will use that path. Inbound you have some control over by selecting the src-ip. - BFD is really better at doing the lower timer values than IPSLA. Depending on platform this is done in a number of ways. - with BFD, currently the remote peer needs to support BFD as well. That said, with IPSLA the remote peer has to be not filtering ICMP etc - with BFD, multi-hop (unlike IPSLA) is currently not available Wrt static route BFD support in IOS: it is coming. Talk to your sales guys (or send me a unicast) to make sure they properly represent this interest and usecase. Regards, -- Aamer Akhter / [EMAIL PROTECTED] Ent & Commercial Systems, cisco Systems > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:cisco-nsp- > [EMAIL PROTECTED] On Behalf Of Phil Bedard > Sent: Thursday, January 10, 2008 10:41 AM > To: Gert Doering > Cc: cisco-nsp > Subject: Re: [c-nsp] BFD for static routes > > That's really the "killer app" for this so to speak, is in a L2 metro > scenario where you can't propagate the customer link-state back to the > terminating L3 router. Even the lowest end Cisco router runs BGP > these days, so I've used that in the past with private ASs for > customers dual-homed, but that requires more configuration and > monitoring, etc. The other option is GRE tunnels but that isn't a > very good solution imho. BFD seems like a better option to me. It's > supported by Juniper, but Cisco seems to only have support in IOS XR. > > I guess a question to pose to Cisco is what takes more CPU, BFD or IP > SLA? If they are the same, IP SLA (reliable static routes) is > certainly an option. > > Phil > > > On Jan 10, 2008, at 2:21 AM, Gert Doering wrote: > > > Hi, > > > > On Wed, Jan 09, 2008 at 11:14:06PM +0100, Peter Rathlev wrote: > >> I'm a little puzzled here. BFD needs two BFD-speaking routers, > right? > >> It's not enough that one of them can speak BFD, is it? And if a > >> router > >> speaks BFD it probably also speaks some kind of routing protocol > >> semi-fluently. Why not use that option instead? > > > > Because you don't want to speak any routing protocol to customers. > > > > Consider things like customers being connected to your routers by a > > "LAN bridge" from some city carrier. Ethernet on both ends, $funny > > things > > in the middle of it. Depending on the way these boxes work, both > > sides > > might have a link at all times, no matter whether the link actually > > works > > or not. > > > > Given that it's a customer connection, you do not want to do IGP > > routing > > that way, and if it's a low-budget customer, you certainly do not > > want to > > setup BGP routing. So you need some other way to detect "line is > > down, > > move to backup link". > > > > BFD-with-statics would very nicely fill that niche. > > > > (And yes - we used have a lot of those links...) > > > > gert > > -- > > USENET is *not* the non-clickable part of WWW! > > > //www.muc.de/~gert/ > > Gert Doering - Munich, Germany > [EMAIL PROTECTED] > > fax: +49-89-35655025 [EMAIL PROTECTED] > muenchen.de > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
