cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
776
Views
15
Helpful
7
Replies

Logging ???

jorge.s
Level 1
Level 1

Hi,

can someone explain me what are the differences between each logging type?

Console logging

Monitor logging

Buffer logging

Trap logging

I'm a bit confused, but I believe Console is the log's which we may see when connected via console, buffer is the one's which we may see via telnet and show log, and Trap is for Syslog... is that right? but what's then Monitor?

thanks for any help!

Jorge

7 Replies 7

Hi,

If you're speaking about PIX/ASA:

"-To enable the security appliance to display system log messages in console sessions, use the logging console command in global configuration mode

- To enable the security appliance to send system log messages to the log buffer, use the logging buffered command in global configuration mode

- To enable the security appliance to display system log messages in SSH and Telnet sessions, use the logging monitor command in global configuration mode

- To specify which system log messages the security appliance sends to a syslog server, use the logging trap command in global configuration mode."

Reference : http://www.cisco.com/en/US/docs/security/asa/asa72/command/reference/l2_72.html#wp1690864

Best regards,

Massimiliano.

Jorge

Both console logging and monintor logging are location specific. Console logging is seen only on the console. Monitor logging is seen only when using the terminal monitor command on vty ports. Also console logging and monitor logging are real time logs. The messages are displayed as the event happens and the log messages are not retained and can not be retrieved after the fact (after the log message scrolls off the screen it is gone and can not be retrieved).

Buffer logging writes the log messages to a memory buffer on the device and the content of the logging buffer is viewed using the show log command which can be used by any session on the device (console or vty or whatever). The buffer is managed as a wrap around buffer and when it gets full a new message over writes the oldest message in the buffer. The log message in the buffer can be retrieved and viewed as long as it is still in the buffer. So logging buffer is retained longer then the real time logs of console and monitor but does not provide long term storage of logs.

Trap logging sends log messages to a collector on a remote device. Log messages are stored and viewed using facilities of the remote collector. How long the log messages are retained and can be viewed is dependent on the policy implemented on the remote collector.

HTH

Rick

HTH

Rick

Rick:

You just answered the exact same question that I posted on another thread! The part in which you describe logging buffers, etc, was exactly my concern.

Here is the text from my thread:

In the process of troubleshooting, I created ACLs that would trap the HSRP traffic coming into and out of the ethernet interfaces and then logging them. I want to see who is talking to who and how often.

A weird thing, though, a 'sh access-lists" shows that the ACL is hitting up, but when I do a "sh log" to see the particulars, it isnt there.

Example:

R2#sh access-lists

Extended IP access list viewtraffic

permit udp any any eq 1985 log (214 matches)

permit ip any any

R2#

R2#

R2#sh access-lists

Extended IP access list viewtraffic

permit udp any any eq 1985 log (215 matches)

permit ip any any

R2#

R2#

R2#

R2#sh log | in %SEC-6-IPACCESSLOGP: list

R2#

R2#

R2#

After 5 minutes or so, though, I will see 2 entries of HSRP packets being received, and instead of 1 packet, it will be 100 or so, maybe less. Then 2 seconds later I will do a "sh log | in %SEC-6-IPACCESSLOGP: list" (the sh log command gets more specific just to filter out the other messages), but I get no return output that time.

Example:

R1#sh log | in %SEC-6-IPACCESSLOGP: list

Aug 22 14:51:28 UTC: %SEC-6-IPACCESSLOGP: list viewtraffic permitted udp 192.168.2.2(1985) -> 224.0.0.2(1985), 141 packets

Aug 22 14:51:28 UTC: %SEC-6-IPACCESSLOGP: list viewtraffic permitted udp 192.168.2.3(1985) -> 224.0.0.2(1985), 9 packets

R1#

R1#sh log | in %SEC-6-IPACCESSLOGP: list

R1#

Is the log buffer getting filled so fast that the ACL messages are being aged-out after only 2 minutes? I increased the buffer to 16000.

So, now that you answered that question, how can I create an ACL that logs matched traffic and get to see that matched traffic in real time -- as it comes in and is matched?

Thanks

Victor

Victor

I am glad that my response in this thread was helpful to the other thread. If you want to see matched traffic in real time I would think that terminal monitor would show in real time what is going into the log, including your traffic.

Two other thoughts:

- it does sound like the logging buffer was filling very quickly. Increasing the size of the buffer should help. But if that much volume is going into the log buffer it may be awkward to catch the output in terminal monitor.

- I am not clear how exact you will be about real time. The behavior of logging hits from an access list is that the first match is logged immediately, but that further matches are accumulated and reported periodically (I think about every 5 minutes) which accounts for the count of 141 matches in the output that you posted.

HTH

Rick

HTH

Rick

Rick:

Im actually consoled into the device through a 3640 terminal server. So, Im on an async line.

So, what I would like is to be able to see the matched traffic as it matches the list.

For example, I changed my HSRP timers to be less aggressive because it seemed that the buffer was overflowing quickly. I changed the HSRP timers to 60 and 180 seconds. There's no other traffic going back and forthe, by the way, since this is in a lab. Therefore, I thought I should be able to see an entry in the log every 60 seconds, but even that, it seems, is too much for the buffer. I think its the way you said: it'll match the ACL and wait 5 or 6 minutes before extracting it from the buffer and posting it to the log.

What do you think?

Victor

If it is in the lab and not much traffic is going through it, then I wonder why it seems the logging buffer was filling so quickly? Did increasing the size of the logging buffer which you mentioned help?

A personal observation: when setting up routers in lab environments I like giving them even larger buffers for logging than I would do in production.

I do not think that you will see an entry in the log from this every 60 seconds. I think it will be every 5 minutes after the first hit.

HTH

Rick

HTH

Rick

Rick:

I had HSRP debugging on, so I think I was killing the buffer.

So I stopped debugging, increased the buffer, increased the timers to 60 and 180, but I still only saw an entry every 60 seconds.

On another router, I didnt even see an entry every 60 seconds. I a 'sh access-list" showed the ACL was hitting up, but no entry in the log, period...

Thanks

Victor

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco