"logging trap debugging" does not generate debug level messages

[aafkhami]

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

[kagodfrey]

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

[7rbowenii]

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

[kagodfrey]

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.

[a.manosca]

The command "logging trap " limits the logging

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.