home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / dcom / sys / cisco / 1228 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  3.6 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!eff!sol.ctr.columbia.edu!destroyer!ncar!noao!arizona!arizona.edu!telcom.arizona.edu!leonard
  2. From: leonard@telcom.arizona.edu (Aaron Leonard)
  3. Newsgroups: comp.dcom.sys.cisco
  4. Subject: Re: AGS+ pauses for 800ms every 30 seconds
  5. Message-ID: <1992Sep3.084740.3656@arizona.edu>
  6. Date: 3 Sep 92 15:47:37 GMT
  7. References: <184ee4INNimp@moe.ksu.ksu.edu>
  8. Reply-To: Leonard@Arizona.EDU
  9. Distribution: world,local
  10. Organization: University of Arizona Telecommunications
  11. Lines: 82
  12. Nntp-Posting-Host: bugs.telcom.arizona.edu
  13.  
  14. >We've got an AGS+ running Version 8.2(7) which seems to pause every 30 
  15. >seconds.  Seems likely this is RIP updates, but it seems unlikely that 
  16. >the router should do absolutely nothing else for that period.  Is there 
  17. >a simple configuration change that we've overlooked which will make this 
  18. >all better?
  19.  
  20. We observed exactly this behavior on our (then) AGS/2s when we a)
  21. had 600+ RIP-advertised routes floating around our backbone and b)
  22. had foolishly monkeyed with a CPU scheduler param ... (let me check
  23. my old mail folders) ... ah, the scheduler-interval parameter.
  24.  
  25. Our problem was fixed by getting rid of the scheduler-interval change,
  26. and, even better, filtering out the huge volume of routes from bothering
  27. our backbone.
  28.  
  29. Appended is a mail message I sent to cs@cisco.com when I figured out
  30. what I had done wrong ... maybe this is your problem too.
  31.  
  32. Aaron
  33.  
  34. Aaron Leonard (AL104), <Leonard@Arizona.EDU>
  35. University of Arizona Network Operations, Tucson AZ 85721
  36. |>   If it ain't broke, break it.
  37.  
  38. Return-path: <LEONARD@Arizona.edu>
  39. Date: Wed, 21 Aug 1991 12:04 MST
  40. From: Aaron Leonard <LEONARD@Arizona.edu>
  41. Subject: RE: Ability of CSC/2s to handle large RIP updates
  42. To: TLI@CISCO.COM, CS-ROUTING@CISCO.COM, CS@CISCO.COM, LEONARD@Arizona.edu,
  43.  TSF@Arizona.edu
  44. Message-id: <37BB519046A03605@Arizona.edu>
  45. X-VMS-To: tli@cisco.com
  46. X-VMS-Cc: cs-routing@cisco.com, cs@cisco.com, leonard@arizona.edu,
  47. X-VMS-Cc: tsf@arizona.edu
  48.  
  49. Greetings, Tony:
  50.  
  51. On 12-Aug-1991, I wrote,
  52.  
  53.     The University of Arizona has 4 core cisco AGS/2 routers with CSC/2
  54.     processors. Up until recently, they managed to route maximum-size
  55.     packets with few drops (<<.5%) and good latency (less than 1% of
  56.     packets forwarded with > 100ms delay.)
  57.  
  58.     A week or so ago, however, all four began displaying the 
  59.     following characteristics:
  60.  
  61.     Packet loss up to 1-3% consistently, around the clock.
  62.     10% of packets forwarded with > 100ms delay, with perhaps
  63.     5% taking > 1000ms.
  64.  
  65.     What changed a week ago: the number of nets being RIPped
  66.     onto our backbone increased from 90 to 600, due to the
  67.     fact that NSI began RIPping routes to all NSI nets. 
  68.  
  69.     We have found that the packet dropouts/delays happen on 30-sec.
  70.     cycles (aha!), coincident with either the routing updates
  71.     being issued from the NSI router, or being redistributed by
  72.     our AGS/2s.
  73.  
  74. Since then, I discovered that the problems is due to user 
  75. misconfiguration (i.e., by myself.)
  76.  
  77. What I did was this:
  78.  
  79. When one of our routers was suffering 100% CPU saturation
  80. (due to an as yet unidentified problem), I misguidedly set
  81. the SCHEDULER-INTERVAL param to 500 on our core routers.
  82. When I realized that this was a useless step, I *thought*
  83. I turned off this param.  Unfortunately, I didn't.
  84.  
  85. Last night I did away with the SCHEDULER-INTERVAL param, and
  86. since then the AGS/2s are back to performing normally, that is,
  87. with less than .5% packet loss.
  88.  
  89. By the way, thanks for pointing out the access-list approach 
  90. to controlling rip updates.  We'll try it out and see whether 
  91. it causes performance to suffer.
  92.  
  93. Thanks,
  94.  
  95. Aaron
  96.