currier@romeo.cs.duke.edu (Bob Currier - DCAC Network Comm. Specialist) (07/11/90)
Does the 8.1 release support bridging of LAT? Is anybody doing it? How is it perfoming for you, if so? And, what about Nadine??? :-) :-) --Bob Currier Network Communications Duke University Durham, N.C. 27706 rdc@bobsun.ac.duke.edu =========================================================================
tsf@noao.edu (Ted Frohling) (07/18/90)
We are using 8.1 on our routers with support for bridging. Yes the bridging software bridges LAT. We haven't seen any problems with 8.1(14) yet. -- Ted Frohling tsf@arizona.edu The University of Arizona 602.621.4834 University Telecommunications Tucson, AZ 85721
tdrake@skister.nswc.navy.mil (Tim Drake - E41) (09/18/90)
I upgraded our cisco box CSC2 that was running 7.0 (15) we
had around 180k free when I checked before upgrading. After
I upgraded and egp got its routes, my box went to ZERO bytes
free. I kept getting a no mem free error of some sort.
I had to undo the upgrade. I was under the impression that the
new software ran from ROM and took less memory. Did I do something
wrong, or will I never be able to upgrade.
One reason I really want to upgrade is the setting of EGP
update timer, and to have all our routers running the same
version.
Tim Drake tdrake@relay.nswc.navy.milfortinp@bwdls56.bnr.ca (Pierre Fortin) (10/15/90)
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 designfortinp@bwdls56.bnr.ca (Pierre Fortin) (10/16/90)
In article <1990Oct15.164223.25730@bnrgate.bnr.ca>, fortinp@bwdls56.bnr.ca (Pierre Fortin) writes: > 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). Hmmm... I just checked the configuration in one of the routers which suffered a disastrous logical fate. The router is setup with "logging on" which is the default. I entered the command and checked the config just to be sure. The manual reads: "The _logging on_ subcommand enables message logging to all destinations except the console." Is there a bug here? Why was the real console outputting debug messages if the manual is correct and the router was defaulting to *not*(?) send output to the real console? 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
fortinp@bwdls56.bnr.ca (Pierre Fortin) (10/16/90)
In article <1990Oct15.171333.28849@bnrgate.bnr.ca>, fortinp@bwdls56.bnr.ca (Pierre Fortin) writes: > Hmmm... I just checked the configuration in one of the routers which suffered > a disastrous logical fate. The router is setup with "logging on" which is > the default. I entered the command and checked the config just to be sure. > The manual reads: "The _logging on_ subcommand enables message logging to all > destinations except the console." > > Is there a bug here? Why was the real console outputting debug messages if > the manual is correct and the router was defaulting to *not*(?) send output > to the real console? Sorry, I should have included this in my previous posting: The "show logging" command reports "Syslog logging: enabled" when "logging on" is set; and "Syslog logging: disabled" when "no logging on" is set. It's nice to know that the messages work :^) Ciao. 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