home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / dcom / sys / cisco / 1242 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  1.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!hobbes.ksu.ksu.edu!bav
  2. From: bav@hobbes.ksu.ksu.edu (Brick Verser)
  3. Newsgroups: comp.dcom.sys.cisco
  4. Subject: Re: AGS+ pauses for 800ms every 30 seconds
  5. Date: 7 Sep 1992 10:32:13 GMT
  6. Organization: Kansas State University
  7. Lines: 24
  8. Distribution: world
  9. Message-ID: <18fb3dINNrre@moe.ksu.ksu.edu>
  10. References: <184ee4INNimp@moe.ksu.ksu.edu>
  11. NNTP-Posting-Host: hobbes.ksu.ksu.edu
  12.  
  13. bav@hobbes.ksu.ksu.edu (Brick Verser) writes:
  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. I had a pleasant exchange with a very helpful Cisco person and we did a
  21. little digging.  Basically, the Ciscos sometimes do this.  If there
  22. are lots of of routes and large numbers of interfaces to which the routes 
  23. must be broadcast, then it can take a while to update things after a
  24. new RIP update comes along.  We have 24 Ethernet ports in this router 
  25. and were receiving over 300 nets in the RIP updates.  That does indeed 
  26. cause the router to be busy for a while.  And it seems that we've been 
  27. suffering from some wild route flapping; in 5 weeks of uptime there have 
  28. been over 50,000 routing updates--that's over one a minute and explains
  29. why this was happening so regularly.
  30.  
  31. So it is a known problem with no immediate direct solution.  Our
  32. solution is simple and pleasant; turn off advertising all these
  33. routes.  We don't need 'em known, and I had been thinking about 
  34. turning them off anyway just to reduce overhead.  So I'm happy now.
  35.  
  36. --Brick
  37.