Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!rutgers!news-server.csri.toronto.edu!utgpu!cunews!bnrgate!bwdls56!fortinp
From: fortinp@bwdls56.bnr.ca (Pierre Fortin)
Newsgroups: comp.dcom.sys.cisco
Subject: 8.1(14) debug locks up router
Message-ID: <1990Oct15.164223.25730@bnrgate.bnr.ca>
Date: 15 Oct 90 16:42:23 GMT
Sender: news@bnrgate.bnr.ca (USENET News System)
Organization: Bell-Northern Research, Ltd. Ottawa Ontario CANADA
Lines: 66

cisco:  I'm posting this since there is a workaround.

We've just suffered "outages" on a couple of our cisco routers in the past
few days.  This happens when someone turns on debugging on an 8.1(14) 
equipped router.  The routers, for all intents and purposes, were dead 
from the main processor's point of view, but were still processing packets
to some [limited] extent.  Routing updates were so infrequent that routes 
would disappear.
 
The problem:  debug output while requested from a telnet session was 
simultaneously being sent out the _real_ console port at a paltry rate of
9600 bits per second.  I don't know the exact internal workings, but the
end result was certainly visible.  This problem was not apparent on 8.0(9).
 
The solution(?):  there are a couple of commands which will prevent output
to the real console:
   - logging on
   - no logging console

Comment:  While cisco manuals will generally give you *some* answer, they
say _what_ the commands do, but rarely how they _interact_.
 
Question to cisco:  Is the following hierarchical interaction assumption
correct?

Assumptions (in pseudo-code):

    if (log_msg_level > "logging console level")
       && (!"no logging console")
       && ("no logging on") {
          if ("logging buffered")
             buffer_message();
          else
             log_message(console);
    };
    if (log_msg_level > "logging monitor level")
       && ("terminal monitor")
       && ("logging on") {
          log_message(terminal_line);
    };
    if (log_message_level > "logging trap level")
       && ("logging internet-address") {
          log_message(internet_address);
    };
          
I'm sure this is just a part of the real interactions (I've not actually
tested all this in the lab [still at home with broken leg :^( ].  Feel free
to correct and further enlighten your users.  My belief is that by coding:
   logging on
   logging buffered
   logging internet-address
   logging console level
   logging monitor level
   logging trap level
we will be able to debug without fear of locking up the system; retrieve
messages logged prior to our telnet session establishment; log messages 
to a syslog host; eliminate possible processing delays by buffering; ...

Regards,
Pierre
 

Pierre Fortin       Bell-Northern Research     I know, my postings are
Internet Systems    P.O.Box 3511, Stn C        terse and humourless. So?
(613)763-2598       Ottawa, Ontario            RIP: aptly named protocol
fortinp@bnr.ca      Canada    K1Y 4H7          AppleTalk: Adam&Eve's design