Network management tools such as Syslog and SNMP are very valuable tools to enable you to monitor the health of your network devices if properly configured.
If these tools have been misconfigured, you will not be able to gather the information you need while troubleshooting specific events or be notified of the time and date an event has occurred. Therefore, you need accurate time using a protocol such as NTP.
Syslog Troubleshooting
To verify your Syslog configuration, confirm logging is enabled, and view the Syslog
messages stored in the buffer, you use the command show logging, as shown in the example below.
Example output:
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
No Inactive Message Discriminator.
Console logging: level debugging, 12345 messages logged, xml disabled,
filtering disabled
Monitor logging: level debugging, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 789 messages logged, xml disabled,
filtering disabled
Exception Logging: size (4096 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabledNo active filter modules.
Trap logging: level informational, 67890 message lines logged
Logging to 192.168.1.1 (udp port 514, audit disabled,
link up),
5678 message lines logged,
0 message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabledLog Buffer (4096 bytes):
[time-stamp] %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to up
[time-stamp] %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
[time-stamp] %SYS-5-CONFIG_I: Configured from console by vty0 (192.168.1.2)
…
Interpretation:
Syslog logging: Indicates the status of syslog logging.
Console, Monitor, and Buffer logging: Show the logging levels and number of messages logged for each type.
Exception Logging: Shows the size of the buffer allocated for exception logging.
Trap logging: Indicates the level of trap logging and details about the remote server receiving the log messages.
Log Buffer: Contains the actual log entries with timestamps and message codes.
Each entry in the log provides valuable insight into the events occurring within the network infrastructure, facilitating easier troubleshooting and monitoring of network health. Remember, the output may vary depending on the device and configuration.
When you need to troubleshoot, you need to be sure that Syslog is generating the right type of messages at the right time.
Syslog operation is by default; console, monitor, and buffer logging display messages with a very high level of debugging (7) and lower.
You may also know that logging into a server is disabled by default, but once enabled, all severity levels will be sent to the server. Therefore, in all cases, if you are not receiving the Syslog messages you expect, verify that the correct level is configured.
In the following example, the console and monitor are configured with a level of information, the buffer is configured with a level of debugging, and the trap logging (server) is configured with a level of warnings.
When you log into a server the correct server IP address needs to be specified and the server needs to be reachable.
Also, because Syslog uses UDP port 514, it is very important to make sure that all configured ACLs are disabled or not blocking traffic destined for UDP port 514.
The buffer normally has a default size of 8192 bytes. Once the buffer fills up, the older entries are overwritten by updates if any. Therefore, if you are using the buffer and experiencing a loss of Syslog messages, consider increasing the size of the buffer with the logging buffered size command or sending the messages to a Syslog server instead.
Finally, if you have remotely connected to a device via Telnet or SSH, and no Syslog messages are coming through, it could be because the terminal monitor command has not been issued.
sys logging in the network
How to verify Syslog Configuration
HQ# show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0
overruns, xml disabled, filtering disabled)
No Active Message Discriminator.
Inactive Message Discriminator:
OSPF severity group drops 4
Console logging: level informational, 126 messages logged, xml disabled,
filtering disabled
Monitor logging: level informational, 0 messages logged, xml disabled,
filtering disabled
Buffer logging: level debugging, 162 messages logged, xml disabled,
filtering disabled
Exception Logging: size (8192 bytes)
Count and timestamp logging messages: disabled
Persistent logging: disabled
No active filter modules.
Trap logging: level warnings, 112 message lines logged
Logging to 192.168.1.100 (udp port 514 , audit disabled,
link up),
2 message lines logged,
0message lines rate-limited,
0 message lines dropped-by-MD,
xml disabled, sequence number disabled
filtering disabled
Logging Source-Interface: VRF Name:
Log Buffer (8192 bytes):
May 12 14:54:50.422: %SYS-5-CONFIG_I: Configured from console by console
May 12 14:57:16.070: %OSPFv3-4-ERRRCV: OSPFv3-10-IPv6 Received invalid packet: Bad
Checksum from FE80::C829:FFF:FE50:54, GigabitEthernet4/0
May 12 14:58:20.014: NTP message received from 192.168.1.10 on interface
‘GigabitEthernet4/0’ (10.10.32.2).
May 12 14:58:20.018: NTP Core(DEBUG): ntp_receive: message received
May 12 14:58:20.022: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action
is 3.
May 12 14:58:20.030: NTP message sent to 192.168.1.10, from interface
‘GigabitEthernet2/0’ (10.10.32.2).
May 12 14:59:25.014: NTP message received from 192.168.1.10 on interface
‘GigabitEthernet2/0’ (10.10.32.2).
May 12 14:59:25.018: NTP Core(DEBUG): ntp_receive: message received
May 12 14:59:25.022: NTP Core(DEBUG): ntp_receive: peer is 0x00000000, next action is 3.
May 12 14:59:25.026: NTP message sent to 192.168.1.10, from interface ‘GigabitEthernet2/0’ (10.10.32.2).
As you can see above; displaying and verifying log and debug messages stamped with a time is important for troubleshooting. If no timestamps are included, this could be that there were no service timestamps commands executed.
To configure time stamps, use the service timestamps [ debug | log ] [ datetime | uptime ] command.
The DateTime option will include the date and time the log or debug message occurred. Therefore, make sure you set an accurate calendar and time set. Use NTP for this.
The uptime option provides a time stamp based on the amount of time that has passed since the last reboot.
