[c-nsp] BFD for static routes

[Aamer Akhter (aakhter)]

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 / aa at cisco.com
Ent & Commercial Systems, cisco Systems

> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] 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
> gert at greenie.muc.de
> > fax: +49-89-35655025                        gert at net.informatik.tu-
> muenchen.de
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/