Logging
Network issues are hard to troubleshoot and investigate if the device contains no information. For instance, if an OSPF adjacency goes down and no correlating alert exists, determining when the problem happened and what caused the problem is difficult. For these reasons, logging is important. All Cisco routers and switches support logging functionality. Logging capabilities are also available for specific features and protocols. For example, logging can be enabled for BGP session state changes or OSPF adjacency state changes.
Table 2-3 lists the various logging levels that can be configured.
Table 2-3 Logging Levels
Level Number |
Level Name |
0 |
Emergency |
1 |
Alert |
2 |
Critical |
3 |
Errors |
4 |
Warnings |
5 |
Notifications |
6 |
Informational |
7 |
Debugging |
When the higher value is set, all the lower logging levels are enabled by default. If the logging level is set to 5 (Notifications), for example, all events falling under the category from 0 to 5 (Emergency to Notifications) are logged. For troubleshooting purpose, setting the logging level to 7 (Debugging) is good practice.
Multiple logging options are available on Cisco devices:
Console logging
Buffered logging
Logging to syslog server
Console logging is important when the device is experiencing crashes or a high CPU condition and access to the terminal session via Telnet or Secure Shell (SSH) is not available. However, having console logging enabled when running debugs is not a good practice because some debug outputs are chatty and can flood the device console. As a best practice, console logging should always be disabled when running debugs. Example 2-28 illustrates how to enable console logging on Nexus platforms.
Example 2-28 Configuring Console Logging
NX-1(config)# logging console ? <CR> <0-7> 0-emerg;1-alert;2-crit;3-err;4-warn;5-notif;6-inform;7-debug NX-1(config)# logging console 6
NX-OS not only provides robust logging, but it also is persistent across reloads. All the buffered logging is present in the /var/log/external/ directory. To view the internal directories, use the command show system internal flash. This command lists all the internal directories that are part of the flash along with their utilization. The buffered log messages are viewed using the command show logging log.
Example 2-29 displays the directories present in the flash and the contents of the /var/log/external/ directory. If the show logging log command does not display output or the logging gets stopped, check the /var/log/ directory to ensure that space is available for that directory.
Example 2-29 Internal Flash Directories
NX-1# show system internal flash
Mount-on 1K-blocks Used Available Use% Filesystem
/ 409600 69476 340124 17 /dev/root
/proc 0 0 0 0 proc
/sys 0 0 0 0 none
/debugfs 0 0 0 0 nodev
/cgroup 0 0 0 0 vdccontrol
/isan 716800 519548 197252 73 none
/etc 5120 1632 3488 32 none
/nxos/tmp 20480 1536 18944 8 none
/var/log 51200 108 51092 1 none
/var/home 5120 0 5120 0 none
/var/tmp 307200 460 306740 1 none
/var/sysmgr 1048576 144 1048432 1 none
/var/sysmgr/ftp 409600 80 409520 1 none
/dev/shm 1048576 353832 694744 34 none
/volatile 204800 0 204800 0 none
/debug 2048 28 2020 2 none
/dev/mqueue 0 0 0 0 none
/mnt/cfg/0 325029 12351 295897 5 /dev/sda5
/mnt/cfg/1 325029 12349 295899 5 /dev/sda6
/mnt/cdrom 350 350 0 100 /dev/scd0
/var/sysmgr/startup-cfg 40960 4192 36768 11 none
/dev/pts 0 0 0 0 devpts
/mnt/pss 325061 8898 299380 3 /dev/sda3
/bootflash 3134728 202048 2773444 7 /dev/sda4
/smack 0 0 0 0 smackfs
NX-1# show system internal dir /var/log/external/
./ 240
../ 300
libfipf.5834 0
l2fm_ut.txt 774
plcmgr.dbg 21
snmp_log 180
libfipf.3884 0
libfipf.3855 0
syslogd_ha_debug 11221
messages 25153
startupdebug 3710
dmesg@ 31
The logging level is also defined for various NX-OS components so that the user can control logging for chatty components or disable certain logging messages for less chatty or less important components. This is achieved by setting the logging level of the component using the command logging level component-name level. Example 2-30 demonstrates setting the logging level of the ARP and Ethpm components to 3 to reduce unwanted log messages.
Example 2-30 NX-OS Component Logging Level
NX-1(config)# logging level arp 3 NX-1(config)# logging level ethpm 3
The most persistent form of logging is to use a syslog server to log all the device logs. A syslog server is anything from a text file to a custom application that actively stores device logging information in a database.
Example 2-31 illustrates the syslog logging configuration. Before configuring syslog-based logging on NX-OS, the command logging timestamp [microseconds | milliseconds | seconds] must be enabled for the logging messages so that all log messages have time stamps. This helps when investigating the log messages. Generally, management interfaces are configured with a management VRF. In such cases, the syslog host must be specified using the logging server ip-address use-vrf vrf-name command on NX-OS so that the router knows from which VRF routing table the server is reachable. If the VRF option is not specified, the system does a lookup in default VRF (the global routing table).
Example 2-31 Syslog Logging Configuration
NX-1(config)# logging timestamp milliseconds NX-1(config)# logging server 10.1.1.100 7 use-vrf management
Debug Logfiles
NX-OS provides the user with an option to redirect debug output to a file. This is useful when running debugs and segregating debug outputs from regular log messages. Use the debug logfile file-name size size command. Example 2-32 demonstrates using the debug logfile command to capture debugs in a logfile. In this example, a debug logfile named bgp_dbg is created with a size of 10000 bytes. The size of the logfile ranges from 4096 bytes to 4194304 bytes. All the debugs that are enabled are logged under the logfile. To filter the debug output further to capture more precise debug output, use the debug-filter option. In the following example, a BGP update debug is enabled and the update debug logs are filtered for neighbor 10.12.1.2 in a VRF context VPN_A.
Example 2-32 Capturing Debug in a Logfile on NX-OS
NX-1# debug logfile bgp_dbg size 100000 NX-1# debug ip bgp updates NX-1# debug-filter bgp neighbor 10.12.1.2 NX-1# debug-filter bgp vrf VPN_A
The NX-OS software creates the logfile in the log: file system root directory, so all the created logfiles are viewed using dir log:. After the debug logfile is created, the respective debugs are enabled and all the debug outputs are redirected to the debug logfile. To view the contents of the logfile, use the show debug logfile file-name command.
Accounting Log
During troubleshooting, it is important to identify the trigger of the problem, which could be normal show command or a configuration change. For such issues, examining all the configuration and show commands during the time of the problem provides vital information.
NX-OS logs all this information into the accounting logfile, which is readily available to the users. Using the command show accounting log, users capture all the commands executed and configured on the system, along with the time stamp and user information. The accounting logs are persistent across reloads. By default, the accounting logs capture only the configuration commands. To allow the capture of show commands along with configuration commands, configure the command terminal log-all. Example 2-33 displays the output of the accounting log, highlighting the various configuration changes made on the device.
Example 2-33 Accounting Log
NX-1# show accounting log Sun Apr 2 01:09:02 2017:type=update:id=vsh.12412:user=admin:cmd=configure terminal ; version 6.0(2)U6(9) (SUCCESS) Sun Apr 2 01:09:03 2017:type=update:id=vsh.12412:user=admin:cmd=interface-vlan enable Sun Apr 2 01:09:03 2017:type=update:id=vsh.12412:user=admin:cmd=configure terminal ; feature interface-vlan (SUCCESS) Sun Apr 2 01:09:38 2017:type=update:id=vsh.12963:user=admin:cmd=configure terminal ; control-plane (SUCCESS) Sun Apr 2 01:09:38 2017:type=update:id=vsh.12963:user=admin:cmd=configure terminal ; control-plane ; service-policy input copp-system-policy (SUCCESS ) Sun Apr 2 01:09:38 2017:type=update:id=vsh.12963:user=admin:cmd=configure terminal ; hardware profile tcam region arpacl 128 (SUCCESS) Sun Apr 2 01:09:38 2017:type=update:id=vsh.12963:user=admin:cmd=configure terminal ; hardware profile tcam region ifacl 256 (SUCCESS) Sun Apr 2 01:09:38 2017:type=update:id=vsh.12963:user=admin:cmd=configure terminal ; ip ftp source-interface mgmt0 (SUCCESS) ! Output omitted for brevity
Event-History
NX-OS provides continuous logging for all events that occur in the system for both hardware and software components as event-history logs. The event-history logs are VDC local and are maintained on a per-component basis. These logs reduce the need for running debugs in a live production environment and are useful for investigating a service outage even after the services are restored. The event-history logs are captured in the background for each component and do not have any impact on CPU utilization to perform this task.
The event-history log size is configurable to three sizes:
Large
Medium
Small
The event-history logs are viewed from the CLI of each component. For instance, the event-history is viewed for all ARP events using the command show ip arp internal event-history event. Example 2-34 displays the event-history logs for ARP and shows how to modify the event-history size. Disable the event-history logs by using the disabled keyword while defining the size of the event-history. Disabling event-history is not a recommended practice, however, because it reduces the chances of root causing a problem and understanding the sequence of events that occurred.
Example 2-34 ARP Event-History Logs and Buffer Size
NX-1# show ip arp internal event-history event
1) Event:E_DEBUG, length:143, at 449547 usecs after Mon May 29 11:11:38 2017
[116] [4201]: Adj info: iod: 2, phy-iod: 2, ip: 172.16.1.11, mac: fa16.3ee2.
b6d3, type: 0, sync: FALSE, suppress-mode: ARP Suppression Disabled
2) Event:E_DEBUG, length:193, at 449514 usecs after Mon May 29 11:11:38 2017
[116] [4201]: Entry added to ARP pt, added to AM for 172.16.1.11, fa16.3ee2.
b6d3, state 2 on interface mgmt0, physical interface mgmt0, ismct 0. R
earp (interval: 0, count: 0), TTL: 1500 seconds
3) Event:E_DEBUG, length:79, at 449432 usecs after Mon May 29 11:11:38 2017
[116] [4201]: arp_add_adj: Updating MAC on interface mgmt0, phy-interface mgmt0
! Output omitted for brevity
NX-1(config)# ip arp event-history event size ?
disabled Disabled
*Default value is small
large Large buffer
medium Medium buffer
small Small buffer
NX-1(config)# ip arp event-history event size large