|
Home > Archive > CCNA > April 2001 > No log msg when telnetting?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
No log msg when telnetting?
|
|
| creamy_stew 2001-04-26, 9:11 am |
| Just read this on tcpmag:
quote:
While it's good that the router is capable of warning you of impending doom, it's bad that the default behavior of the router isn't to show you these messages unless you're connected via a console cable with the terminal program running at all times. Since most of us don't even use the console port after initial setup (let alone, leave the terminal program running), we need to find a better way to get error messages from the router.
Surely log messages show when you telnet to a router?
Next he shows how to log to a syslog server. He then also says that it might be a problem that the default log level "informational" does not log debug events. Ok, I'm not that experienced, but I have run some debug commands in a small lab environment and even that seemed to choke the routers somewhat. I can't imagine what doing this in a large production environment would do. And to top it off, he seems to suggest we send all that "junk" over the network?
Am I just underestimating the^cisco routers or what?
/creamy | |
|
| quote:
Originally posted by creamy_stew
Surely log messages show when you telnet to a router?
If you remember to issue "terminal monitor" first.
quote:
Next he shows how to log to a syslog server. He then also says that it might be a problem that the default log level "informational" does not log debug events. Ok, I'm not that experienced, but I have run some debug commands in a small lab environment and even that seemed to choke the routers somewhat. I can't imagine what doing this in a large production environment would do. And to top it off, he seems to suggest we send all that "junk" over the network?
Am I just underestimating the^cisco routers or what?
/creamy
I would not log debug messages unless I need to. Logging to a syslog server is good idea however:
- You do not need to have a telnet session to each device running continuously, you will only need one syslog server somewhere.
- You save the device from the trouble of formatting the output
- You can view the log lines from multiple devices interlaced if you need to.
- You can store the messages on disk for later retrieval if you need to research something (a security breach or whatever).
If you select a moderate level of logging, the amount of traffic will not strangle a LAN.
Terje | |
| creamy_stew 2001-04-26, 10:24 am |
| quote:
If you select a moderate level of logging, the amount of traffic will not strangle a LAN.
This is what I'm getting at. What happens when you _do_ enable debugging in a production network. Is it ever done or do you take the router down and do your debug experiments in a controlled environment?
/creamy | |
| Terje 2001-04-26, 11:05 am |
| quote:
Originally posted by creamy_stew
This is what I'm getting at. What happens when you _do_ enable debugging in a production network. Is it ever done or do you take the router down and do your debug experiments in a controlled environment?
/creamy
I am inclined to believe that a low-end router would succumb to CPU overload before it is able to saturate a 10 or 100Mbps LAN. If you test it, let us know!
Generally, debugging is easier in a controlled environment. There are times you simply have to do the debugging in the same environment that the problem occurs. But you would probably only enable debugging messages on one or a selected few routers. Note that a sniffer is sometimes much more convenient than using debugging messages.
Terje | |
| MadChef 2001-04-26, 11:40 am |
| quote:
Originally posted by creamy_stew
This is what I'm getting at. What happens when you _do_ enable debugging in a production network.
MadChef# debug all
<router barfs, rolls over and plays dead>
It all really depends on what you're doing. Doing a "debug isdn event" is unlikely to adversely affect anything this side of an AS5800 and even then it might not be so bad when syslogged.
"debug ip packet" on most any production router is likely to be problematic, which is why you get to use access lists with that command.
You just have to think about the quantity of messages you expect to get from your command and how the router is handling them. Doing a debug and sending the output out the console port might choke a router while the same debug sent to the buffer would be fine.
MadChef | |
| BlueBaron 2001-04-26, 2:22 pm |
| Your best bet for debugging on a production system is to be as specific as absolutely possible. Before you hit <enter> on that command, do a <?> to see if you can drill down any further. Start from there, if you don't get the info you want, back out one step at a time. | |
|
|
| Yankee 2001-04-27, 5:35 am |
| Debugging is a necessary function on a production network, but must be done with care and understanding of what you are asking the router to do. Also be aware of the router's function before initiating any debug command. Meaning if it is a core router think long and hard before messing with it and decide if you can get similar info from a less important neighbor.
For example if you are troubleshooting an EIGRP problem between the core and a remote site you should start at the remote and not the core.
I see no need in logging debug info to a syslog server. Typically only the default router logs are sent to a server because in a large production network it is impossible to visit every router every day, so the syslog server compiles both a longer history of events then the live router's log will hold and it allows an engineer to scan the whole network's logs from a central spot. Debug info is only generated when a tech requests it, so it is being viewed live and the tech can save it if deemed necessary. You want to log the stuff you may not see to the server, not what you generate yourself.
Least that's what we do...
Yankee |
|
|
|
|
Maybe the books Troubleshooting teach this?