[c-nsp] BFD w/ static routes

[Rodney Dunn]

Open a TAC case and have it attached to:

CSCsb48249
Externally found enhancement defect: New (N)
Request for BFD integration with object tracking

It's on the roadmap from what I've been told.

Could you explain the exact topology you want this
for?


Rodney

On Thu, Aug 04, 2005 at 04:07:42PM +0300, Pekka Savola wrote:
> Speaking of which, when will BFD w/ static routes before available on 
> IOS?  JunOS has had it for quite a while now..
> 
> We'd like to provide backup connectivity to customers using this 
> mechanism.
> 
> ---------- Forwarded message ----------
> Date: Thu, 4 Aug 2005 14:32:38 +0200
> From: martin schneidhofer <martin.schneidhofer at gmx.net>
> To: juniper-nsp at puck.nether.net
> Subject: AW: [j-nsp] BFD advice
> 
> hi all,
> 
> are there any experience in BFD operability
> between juniper and cisco equipment -
> especially with ospf ?
> 
> bye,
>  			/martin
> 
> > -----Ursprüngliche Nachricht-----
> > Von: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] Im Auftrag von
> > Lewis, Charles
> > Gesendet: Mittwoch, 3. August 2005 18:50
> > An: George Yalamov; juniper-nsp at puck.nether.net
> > Betreff: RE: [j-nsp] BFD advice
> >
> > We run it pretty extensively.  We've found that the timer
> > itself really shouldn't go much below 75 ms and that a
> > multiplier of four has proven safest (applied over various
> > flavors of Ethernet within 100km or so).
> > When we've tried to run much tighter we've hit situations
> > where ppmd apparently isn't getting enough CPU time and
> > periodic false link failures occur.  In other words, your lab
> > conclusions seem to be consistent with our experiences.
> >
> > There have been rumblings about putting bfd into the PFE -
> > this would probably yield much better detection times and
> > improve stability.  I don't know whether/if this is on any
> > roadmaps, though.
> >
> > I don't know if you plan to run them but there's a pretty
> > significant caveat with BFD on J-series boxes.  Timer values
> > that are fine on our M boxes have proven unstable on the
> > J-series.  Roughly speaking we've found stability around 800
> > ms or so (~200ms x 4).  We've been led to understand that
> > this is a function of how the kernel is prioritizing locally
> > terminating traffic that's specific to the platform.
> > Hopefully this will be addressed soon.
> >
> > CHL
> >
> > -----Original Message-----
> > From: juniper-nsp-bounces at puck.nether.net
> > [mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of
> > George Yalamov
> > Sent: Wednesday, August 03, 2005 11:45 AM
> > To: juniper-nsp at puck.nether.net
> > Subject: [j-nsp] BFD advice
> >
> >
> >
> > Hi all,
> >
> > 	Does any one have real life experance with BFD, tunning
> > timers, measurement of traffic disruption between 2 end
> > points, convergance time
> >
> > in IGP (ISIS for example).
> >
> > I've tested this feature in lab environment with some M
> > boxes, and the minimum time of traffic interruption was 200 -
> > 400ms measured with iperf.
> >
> > Any ideas?
> >
> >
> > regards
> > George
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-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/