[c-nsp] Routing around errors

[N. Max Pierson]

We're using OER/PfR to achieve this and it works quite well. You can have
routing changes on a wealth of triggers from latency increases to
errors counting up on interfaces. PfR can be configured with a lot of logic
built in so that you don't accidentally blackhole traffic. You can even go
as far as using EEM and PfR, but I would lab this up in either case you
make sure you get the desired effect.

Regards,
Max

On Mon, Dec 12, 2011 at 11:27 AM, Keegan Holley
<keegan.holley at sungard.com>wrote:

> I've always been nervous about automating something like, but to each his
> own.  There are a few different solution that poll specifically with
> performance in mind.  You should also be able to set the generic pollers to
> trap based on threshold.  From there I'd just let a lowly human decide what
> to do.  My concerns with automation have been things like: How do we make
> sure the secondary path is clean and has enough bw to handle the load? How
> do we move things back once the issue is gone?  How do we prevent
> automation from disabling both links if the secondary is down or unusable?
>  Granted I haven't done a wealth of research  on tools that would do this,
> but usually a good NOC will be able to figure something like this out and
> fix it in 15-20 minutes.  Automation may take a while to implement and
> perfect (even if it's purchased) only to save me 20 minutes of dropped
> packets.  YMMV though.
>
> Keegan Holley ▪ Network Architect  ▪ SunGard Availability Services ▪ 401
> North Broad St. Philadelphia, PA 19108 ▪ (215) 446-1242 ▪
> *keegan.holley at sungard.com* <keegan.holley at sungard.com> Keeping People and
> Information Connected® ▪ *http://www.availability.sungard.com/
> * <http://availability.sungard.com/> *Think before you print*
>
> CONFIDENTIALITY:  This e-mail (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited.  If you received this e-mail in error,
> please notify the sender and delete this e-mail from your system.
>
>
>
>
> 2011/12/9 Geoffrey Pendery <geoff at pendery.net>
>
> > We've seen an old nuisance issue becoming more prevalent lately - at
> > dual-homed sites one of the circuits will run errors, but not bad
> > enough to drop the routing protocol neighbor (OSPF in our case).
> >
> > So a site with one good circuit and one error-heavy circuit will
> > continue to route traffic over the circuit with errors.  I'm curious
> > what solutions are prevalent out there, anybody want to weigh in?
> >
> > Tune the hellos tight enough in the hopes of dropping the neighbors?
> > PfR/OER?
> > Alerts from monitoring system followed by manual intervention?
> > EEM scripts checking the counters?
> >
> >
> > Thanks,
> > Geoff
> > _______________________________________________
> > 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/
>