🚀 go-pugleaf

>We've got an AGS+ running Version 8.2(7) which seems to pause every 30 
>seconds.  Seems likely this is RIP updates, but it seems unlikely that 
>the router should do absolutely nothing else for that period.  Is there 
>a simple configuration change that we've overlooked which will make this 
>all better?

We observed exactly this behavior on our (then) AGS/2s when we a)
had 600+ RIP-advertised routes floating around our backbone and b)
had foolishly monkeyed with a CPU scheduler param ... (let me check
my old mail folders) ... ah, the scheduler-interval parameter.

Our problem was fixed by getting rid of the scheduler-interval change,
and, even better, filtering out the huge volume of routes from bothering
our backbone.

Appended is a mail message I sent to cs@cisco.com when I figured out
what I had done wrong ... maybe this is your problem too.

Aaron

Aaron Leonard (AL104), <Leonard@Arizona.EDU>
University of Arizona Network Operations, Tucson AZ 85721
|>   If it ain't broke, break it.

Return-path: <LEONARD@Arizona.edu>
Date: Wed, 21 Aug 1991 12:04 MST
From: Aaron Leonard <LEONARD@Arizona.edu>
Subject: RE: Ability of CSC/2s to handle large RIP updates
To: TLI@CISCO.COM, CS-ROUTING@CISCO.COM, CS@CISCO.COM, LEONARD@Arizona.edu,
 TSF@Arizona.edu
Message-id: <37BB519046A03605@Arizona.edu>
X-VMS-To: tli@cisco.com
X-VMS-Cc: cs-routing@cisco.com, cs@cisco.com, leonard@arizona.edu,
X-VMS-Cc: tsf@arizona.edu

Greetings, Tony:

On 12-Aug-1991, I wrote,

    The University of Arizona has 4 core cisco AGS/2 routers with CSC/2
    processors. Up until recently, they managed to route maximum-size
    packets with few drops (<<.5%) and good latency (less than 1% of
    packets forwarded with > 100ms delay.)

    A week or so ago, however, all four began displaying the 
    following characteristics:

    Packet loss up to 1-3% consistently, around the clock.
    10% of packets forwarded with > 100ms delay, with perhaps
    5% taking > 1000ms.

    What changed a week ago: the number of nets being RIPped
    onto our backbone increased from 90 to 600, due to the
    fact that NSI began RIPping routes to all NSI nets. 

    We have found that the packet dropouts/delays happen on 30-sec.
    cycles (aha!), coincident with either the routing updates
    being issued from the NSI router, or being redistributed by
    our AGS/2s.

Since then, I discovered that the problems is due to user 
misconfiguration (i.e., by myself.)

What I did was this:

When one of our routers was suffering 100% CPU saturation
(due to an as yet unidentified problem), I misguidedly set
the SCHEDULER-INTERVAL param to 500 on our core routers.
When I realized that this was a useless step, I *thought*
I turned off this param.  Unfortunately, I didn't.

Last night I did away with the SCHEDULER-INTERVAL param, and
since then the AGS/2s are back to performing normally, that is,
with less than .5% packet loss.

By the way, thanks for pointing out the access-list approach 
to controlling rip updates.  We'll try it out and see whether 
it causes performance to suffer.

Thanks,

Aaron