[c-nsp] Routing around errors

[Keegan Holley]

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 <nmaxpierson at gmail.com>

> 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/
>>
>
>