Have you ever looked at the Cisco IOS “show logging” command and wondered what the ‘logging discriminator’ section of the output meant?
Well, wonder no longer. It is the ghostly spectre of the often misunderstood logging discriminator feature, and for the record, it’s a filtering tool to save your sanity!
In this blog post we will explore the following items:
What does a Logging Discriminator do?
A discriminator is a big, fancy word we use in Cisco IOS for a filter that acts on our logs.
So let’s suppose we have some logging messages that continuously (and infuriatingly) appear on the terminal whilst you’re in the middle of doing something important, annoying right? Well, because we’re conscientious network professionals we check out the log to make sure the device isn’t about to fall over and die… and then we banish it with a logging discriminator so we can go back to work uninterrupted!
Another reason we may want to use a logging discriminator might be because a particular message is filling up the buffer. We often use the buffer logs when troubleshooting issues, so if the buffer eats its own tail (runs out of space and overwrites the beginning of the log file) due to one or more attention seeking log(s), then we probably would want to use a discriminator to stop that happening again in future.
Logging Discriminator Locations.
Once a filter has been created, which I’ll show you in a moment, then it needs to be applied to one or more of the following destinations:
- Console = filters the message visibility from the console.
- Monitor = filters the message visibility from the terminal monitor (SSH/Telnet).
- Buffered = prevents the filtered message from being written to the buffer log – found under the “show logging” command.
- Host = prevents the filtered message from being written to a remote syslog server. Can be applied to multiple syslog servers.
5 Reasons to NOT use Logging Discriminators.
When you don’t understand what a logging message means.
It can only be bad news when you permanently filter a logging message that you do not understand, especially if you are too general with your filter configuration.
Take the time to research log messages to ensure they are harmless, and if you do decide to continue, then be as specific as possible with your discriminator configuration. Doing this will prevent legitimately concerning logs from being dropped accidentally.
The best way to find out what an error message means, is to use Cisco resources for your device model and software version. Google “System Message Format Cisco (plus your model number)” and this should get you to where you need to be.
You should find a page that looks similar to this, which is for the Cisco 9400 series switch:
When you could lower the logging trap severity instead.
In many cases you can safely lower the trap severity level to 5 which blocks “Debug” and “Informational” message types. See the section “The Anatomy of a Log Message” for more information on severity levels.
You can lower the trap severity globally on your device using the “logging trap 5” command. This will continue to show logs that are severity 5 and below.
When you are seeing debug logs.
It could be that you are seeing tonnes of debug messages in your logs or on your terminal. As running debugs on production devices long-term is not recommended, if no active troubleshooting is taking place then turn off debugging with the command “undebug all”.
You wish to remove interface up/down messages.
It’s probably much more intuitive for other network administrators if you go with the traditional method of preventing up/down link messages. You can do this by going under an interface (or range of interfaces) and entering the “no logging event link-status” command.
When you could disable terminal monitoring.
Network Engineers and Administrators typically connect to devices through SSH.
Using the syntax “terminal no monitor” command we can get some log message peace and quiet. This will prevent you from seeing all messages printed to the terminal.
To re-enable messages on the terminal use “terminal monitor”.
BE SPECIFIC with your discriminators!
It’s very, very easy to enter a configuration that blocks more that you had bargained for. Test thoroughly in a lab before deploying in a production environment.
The Anatomy of a Log Message.
There are four components that make up a log message in Cisco IOS. There are the facility, severity, mnemonic, and msg-body.
Logging discriminators allow us to focus in on these elements to assist in blocking messages. The diagram below gives an example:
The facility is a reference to that part of the system that has generated the error.
The severity is your DEFCON number, it shows the importance of the log message. The chart below shows the different severity levels ranging from 0 = something major is wrong, to 7 = an admin has requested this output.
0 - Emergency 1 - Alert 2 - Critical 3 - Error 4 - Warning 5 - Notification 6 - Informational 7 - Debugging
The mnemonic gives some additional context to the log message.
The msg-body is fairly self explanatory, it is the bulk of the message that is most descriptive (usually!) about the logging message.
Configuring the Logging Discriminator.
Watch the video tutorial showing how we configure single and multi-parameter message discriminators.
I highly recommend watching the video to see some of the caveats of applying logging discriminators for yourself, however if you’d like to cut to the chase the commands can be found below.
Configure a single parameter logging discriminator.
The goal in this example is to block this specific message from appearing in the buffer log:
To achieve this we first create the filter, DO NOT use quotation marks around your message body, but DO make sure it is an exact match – copy and paste is your friend!
logging discriminator DROP-ME msg-body drops Configured from console by console
Then we apply the filter configuration to the buffer log:
logging buffered discriminator DROP-ME
Configure a multi-parameter logging discriminator.
Messages containing the NOTIFICATION and ADJCHANGE mnemonic are appearing every few seconds. We wish to prevent messages containing these mnemonics from popping up on screen at any time; while still allowing other logs to be displayed.
NOTE: You probably wouldn’t want to do this on a production device.
Due to the way that message discriminators work – see the Caveats section – we can only apply one filter at a time. This means that we must use a logical OR operation to ensure both these mnemonics are dropped. Let’s go through how to do this.
First we create a discriminator called DROPBGP, select the mnemonics option and ensure that we use the drops keyword. Finally we use the pipe symbol (|) which acts as an OR operator.
Ensure that you use the same capitalisation as found in the log message, an DO NOT use spaces around the pipe symbol.
logging discriminator DROPBGP mnemonics drops NOTIFICATION|ADJCHANGE
Next, we apply the logging discriminator in a similar way to a single parameter filter. In this example though, the goal states that we ensure the filtered logs do not pop up on screen at any time, so lets apply to both the console and the monitor.
logging console discriminator DROPBGP logging monitor discriminator DROPBGP
Adding an additional logging discriminator of the same name will overwrite the original.
Yeah, its annoying but you can only have one discriminator of the same name. This means you have to be frugal with your syntax.
Note that it is very easy to accidentally block more than you intended when using logging discriminators, take a look at the video to ensure you understand the consequences of doing so.
The one logging discriminator binding rule.
What makes the fact we can only have one discriminator of the same name issue worse, is that it’s only possible to bind one discriminator to a destination.
For example; the filter “DROPME” is applied to the console. It’s not possible to then also apply “DROPME2” in addition to “DROPME”.
Logging discriminators have an 8 character name limit.
Do you want to name your discriminator something descriptive? Well, good luck with that, you have eight characters to do so but after that your logging discriminator name will be truncated.
Overwriting custom settings.
You should be aware that custom logging settings may get overwritten to default settings when adding or removing discriminators. I’ve come across this very issue myself on devices that have a custom buffer log size set.
Removing Logging Discriminators
There are two ways to remove a message discriminator, and neither is perfect.
The first thing to note is that you cannot remove the message discriminator without first deleting it from any monitoring locations it is applied to. View all of the places that the discriminator is applied by running the “show logging” or “show run | in logging” commands.
Option 1: Negate the command.
no logging console discriminator DROPBGP no logging monitor discriminator DROPBGP no logging buffered discriminator DROPBGP
The issue with this command is that it doesn’t just remove the discriminator, it actually turns off logging altogether for the destination that you run it against. This might not be a problem for you, it would depend on how critical is to your environment.
It is trivial to turn back on, you would use one or more of the following:
logging console logging monitor logging buffered
Option 2: Skip to the end.
Instead of negating the command, simply run the “logging” commands at the end of option 1. This is essentially a shortcut that ensures you don’t miss a beat of logging.
Once you have used one of the options above, you still need to tidy up and remove the discriminator itself using the “no” prefix. To continue our multi-parameter discriminator configuration example, you would run the command below to finally remove all trace of the filter.
no logging discriminator DROPBGP mnemonics drops NOTIFICATION|ADJCHANGE
I hope this blog has been useful in shedding light on an under-documented and seldom used feature in Cisco IOS.
If you enjoyed this post; take a look around, share with a friend or colleague, or check out my YouTube channel – writememTV. See you next time!