02-11-2003 08:33 AM - edited 03-02-2019 04:59 AM
Hello,
I appreciate if you can help me understand this "logging trap debug" in routers. I have setup a syslog server to collect messages from several devices including routers, switches and PIX firewall. All configurations at syslog server and network devices side are OK and have been tested. I started with "warning" level and found out that was too much of messages from PIX but nothing from routers (except detecting "config t" sessions). So, I changed the level of PIX to "error" (to limit the number of messages) and level of routers to "debug" to see what I can get !!!
Still nothing from routers (even from those with access lists). My understanding from Cisco documentation is that with "logging trap debugging" I should get same messages as if I run "debug" on the router IOS command line. Apparently they are different though. Also, in debug command we have the option to select the area of "debug" command (debug ip, debug isdn, etc) but in "logging trap debugging" there is no such an option.
I summarize my case in two questions:
- Does "logging trap debugging" generate exactly same messages as if you run "debug" at command line in a router?
- When would I get a message in my syslog from a router (other than "config terminal" cases)?
Thanks in advance for your time and help.
Ali
02-11-2003 01:58 PM
Hi
You still need to issue a debug command in order to generate the debug information to trap to your syslog server. Then you will see the same information as you would on the command line.
HTH
Kev
02-11-2003 02:03 PM
a, be very careful with the debug command. If you do not use it conservatively it will eat up your processor and possibly stop routing of traffic. You have a one in 100 chance of killing the debuggin process without rebooting, so make sure that you only debug what you want, not everything. I would look at the logging command for more detail on how to set this up correctly. Again, you can negatively impact your network with the debug command and the only way to get you r router back is to reboot it. I would not do this during a production day. Also, make sure that you save your running config prior to issuing the debugging command just to be safe.
-Bo
02-11-2003 02:14 PM
Indeed. Debugging say ppp negotiation on an 800 series whilst it is attempting an outbound ISDN call would be ok, whilst debugging ip packets on something like a fully loaded 3600 going at full tilt, would almost definately not.
02-11-2003 05:58 PM
The command "logging trap
messages sent to syslog servers to messages at that
level and numerically lower levels. The default is
"informational" (level 6).
For your first question, logging trap debugging should
send debug messages to your server only if you have
enabled debugging on the router.
For the next question, as the default is "informational"
level once you entered the logging trap command without
any option, at least an Informational message should be
sent to the syslog server.
You can also verify this using the "show logging" command
and check for the number of messages logged. You might
also want to use the "summary" option, if available.
Hope this helps.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide