[c-nsp] BFD for monitoring? (was BFD expectations)

Arvind .cisconsp arvindc.cisconsp at gmail.com
Thu Sep 23 10:06:20 EDT 2010


I think ethernet OAM would be a better bet for this specific use case. Esp
if you are on SXI.

http://www.cisco.com/en/US/prod/collateral/routers/ps368/prod_white_paper0900aecd804a0266.html
<http://www.cisco.com/en/US/prod/collateral/routers/ps368/prod_white_paper0900aecd804a0266.html>

On Thu, Sep 23, 2010 at 8:29 AM, Jeff Bacon <bacon at walleyesoftware.com>wrote:

> > Message: 1
> > Date: Wed, 22 Sep 2010 19:19:57 -0400
> > From: Chris Evans <chrisccnpspam2 at gmail.com>
> > To: Phil Mayers <p.mayers at imperial.ac.uk>
> > Cc: cisco-nsp at puck.nether.net
> > Subject: Re: [c-nsp] BFD expectations
> > Message-ID:
> >       <AANLkTim5OLaoyYnscw1ErSdTQ9Tg71ZRRKuOZu6Vv1Ry at mail.gmail.com
> > >
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Phil you bring up a great point. Until sxi bfd code was crap on the
> 6500..
> > We have done exstensive testing at the ECATS lab. We concluded that
> 450ms is
> > a good number on this platform with its centralized architecture. We
> tested
> > this with approx 35 peers and had no issues under heavy CPU load.
>
> This might seem a little silly, but would it be reasonable to use BFD,
> say in conjunction with EEM, as a form of link-monitoring mechanism?
>
> I have 6500s which only have a handful of links, so presumably I could
> push the timer down down to say 200-300ms. I've been looking for a
> cheapish
> way to do link state monitoring (I need to know when there's a blip,
> even
> a very momentary one) - somewhere down the road I'd like to put in
> Accedian boxes and really get the big picture, in a smaller scale I'm
> considering nuttcp between boxes at each node to push streams around and
> look for retransmits, but BFD could work too. I don't want to actually
> act
> on anything - that requires human intervention, and too often it is just
> a
> subsecond blip for which a down-and-reconverge is inappropriate, but if
> I know it happened, that information can be passed up to the app team
> and they can say "oh ok" and not do a ton of digging.
>
> Is this an unreasonable approach? All the boxes are sup7203Bs with DFCs,
> SXH7, and we're talking about gig metro-E links, mostly dedicated-path
> but a few MPLS/VPLS-pseudowires.
>
> Thanks,
> -bacon
>
>
> _______________________________________________
> 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/
>


More information about the cisco-nsp mailing list