Interesting.. I'm a mostly juniper shop and I haven't done alot of reading on OER/PIR.
Thanks 2011/12/12 N. Max Pierson <[email protected]> > 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/
