I am currently setting up auditing on my router, but I want to do it correctly and safely since I do not want to overwhelm anything that could cause my router to fail, and therefore, customers go down and which could potentially be very serious in my circumstance.
In any event, I want to enable logging on all severity levels. I do not have a syslog server connected to my router, and I do not keep a standalone connected to my router 24/7; I guess I am logging on to the device the old fashion way until I receive services that will allow me to remotely connect to my router. Since my services and the tools I have are limited, I generally console in to the router to conduct any configuration changes necessary for troublshooting.
So daily, I am required to audit my device and store everything on file; I want all output to send to my buffer without overwhelming my device. After typing in the show memory free command, I see I have the following free space.
Processor : 1846163716
I have to review set to audit the majority of all logging levels..
My question, what will be a safe size to allocate all logging levels by exercising caution with the amount of free memory provided? I know my math, but I don't want to utilize all of my free space.
If you use "logging buffered ##### informational" (severity level 6) it will include the other type of log events (levels 5 through 0) that you listed above.
Regarding the memory, if you're logging in daily to extract and clear the log, you can allocate a reasonable amount (say 25% of free memory or even less) and then see if the buffer fills up that allocation. If you are getting more than the allocated 25% used by the logging, I'd say you very likely have a problem whose root cause should be addressed to remedy the number of log messages being generated. If that's not possible, then I'd say you have a good justification for an external syslog server.
Are you saying "logging buffered informational will give me better results or enough of what I need to audit instead of "logging buffered ####### debugging" ?
For the memory-
Over time yesterday after posting this discussion, I did find as you mentioned in your response that a reasonable(safe) amount to allocate is 25%... After typing the #"dir" command, I received 64229376, so I multiplied of course by .25 and I got 16057344.
# logging buffered 16057344 informational
** that was the easy part :-) , but after typing
# default logging queue-limit
# sh run
the configuration had a statement "no logging queue-limit", So according to a Cisco support document I found, "by default logging queue-limit does queue messages as well", but after doing a sh run command, I see the statement displayed as "no logging queue-limit", so I said.. ok... what is a safe queue-limit size? Is it 100? ---Just making sure.
Also, how do I know if I am getting more than 25% allocated. I was afraid to apply the logging buffered ### informational command without setting the logging queue-limit to avoid any conflicts with the router. I did give it a test run, and within 3 minutes, I received over 80 messages.... I thinking. .that's going to consume a lot of paper to be stored... I am still searching if there would be a easier way to filter all of the levels.
so ... I guess.. my biggest test run is to find out how many messages(hours worth) can it store with the amount of memory allocated to be buffered. Unfortunately, it's Friday, so I guess I'll wait till Monday morning to give it a test run; then Tuesday, I'll extract the show logging command the next morning at the same time I kicked off the logging. Or.. may I ask, do you have any other suggestions? I am pushing to get funds so this place can have a syslog server; otherwise, this sure feels like I am going back to the stone age! lol!
Also, if the buffer fills up, will begin dropping packets one by one begining with the oldest?
You're right.. Sorry... you're right.. lol I setted the buffered size to a number adequate to the amount of free memory(15% to be safe).. but I am still getting alot of dropped packets.. I checked my AcLS to ensure I wasn't logging permit statements; I had a few; so therefore, I removed the "log" statements after each permit statements. I a had a few by the way. In any event, because of the missed packets, I set the rate-limited to 50 except emergency. I guess I'll know how many packets were dropped or recorded from the time it was set till tomorrow morning. But I have a feeling with the amount of memory available and what was allocated, I don't think I'll get at least 12 hours worth of audit logs. I can see all of the packets denied. I can verify all logged messaged associated with ips in my block list and Bogon list; but I can't idenfity the severity levels. Sorry to sound unprepared or uneducated, but this is my first time to set up auditing on a router as oppossed to viewing it on a syslog server. I guess to sum it all up base on what I had mentioned earlier, after applying the show logging command, how can you dictate and identify each severity after typing a show logging command? Thanks for taking time! Cameron
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...