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 <[email protected]>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 ▪ > *[email protected]* <[email protected]> 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 <[email protected]> > > > 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 [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/
