This chapter introduces monitoring and troubleshooting Cumulus Linux.
Using the Serial Console
The serial console can be a useful tool for debugging issues, especially when you find yourself rebooting the switch often or if you don’t have a reliable network connection.
The default serial console baud rate is 115200, which is the baud rate ONIE uses.
Configuring the Serial Console on ARM Switches
On ARM switches, the U-Boot environment variable
baudrate identifies the baud rate of the serial console. To change the
baudrate variable, use the
You must reboot the switch for the
baudrate change to take effect.
The valid values for
Configuring the Serial Console on x86 Switches
On x86 switches, you configure serial console baud rate by editing
grubcan cause the switch to be inaccessible via the console. Grub changes should be carefully reviewed before implementation.
The valid values for the baud rate are:
To change the serial console baud rate:
/etc/default/grub. The two relevant lines in
/etc/default/grubare as follows; replace the 115200 value with a valid value specified above in the
--speedvariable in the first line and in the
consolevariable in the second line:
After you save your changes to the grub configuration, type the following at the command prompt:
If you plan on accessing your switch's BIOS over the serial console, you need to update the baud rate in the switch BIOS. For more information, see this knowledge base article.
Reboot the switch.
Getting General System Information
Two commands are helpful for getting general information about the switch and the version of Cumulus Linux you are running. These are helpful with system diagnostics and if you need to submit a support request to Cumulus Networks.
For information about the version of Cumulus Linux running on the switch, run
net show version, which displays the contents of
For general information about the switch, run
net show system, which gathers information about the switch from a number of files in the system:
Diagnostics Using cl-support
You can use
cl-support to generate a single export file that contains various details and the configuration from a switch. This is useful for remote debugging and troubleshooting. For more information about
cl-support, read Understanding the cl-support Output File.
You should run
cl-support before you submit a support request to Cumulus Networks as this file helps in the investigation of issues.
Sending Log Files to a syslog Server
Logging on Cumulus Linux is done with rsyslog.
rsyslog provides both local logging to the
syslog file as well as the ability to export logs to an external
syslog server. High precision timestamps are enabled for all
rsyslog log files; here's an example:
There are applications in Cumulus Linux that write directly to a log file without going through
rsyslog. These files are typically located in
All Cumulus Linux rules are stored in separate files in
/etc/rsyslog.d/, which are called at the end of the
GLOBAL DIRECTIVES section of
/etc/rsyslog.conf. As a result, the
RULES section at the end of
rsyslog.conf is ignored because the messages have to be processed by the rules in
/etc/rsyslog.d and then dropped by the last line in
Most logs within Cumulus Linux are sent through
rsyslog, which then writes them to files in the
/var/log directory. There are default rules in the
/etc/rsyslog.d/ directory that define where the logs are written:
|Sets defaults for log messages, include log format and log rate limits.|
|15-crit.conf||Logs crit, alert or emerg log messages to |
|22-linkstate.conf||Logs link state changes for all physical and logical network links to |
|99-syslog.conf||All remaining processes that use |
Log files that are rotated are compressed into an archive. Processes that do not use
rsyslog write to their own log files within the
/var/log directory. For more information on specific log files, see Troubleshooting Log Files.
Enabling Remote syslog
If you need to send other log files — such as
switchd logs — to a
syslog server, do the following:
Create a file in
/etc/rsyslog.d/. Make sure it starts with a number lower than 99 so that it executes before log messages are dropped in, such as
25-switchd.conf. Our example file is called
/etc/rsyslog.d/11-remotesyslog.conf. Add content similar to the following:
This configuration sends log messages to a remote
syslogserver for the following processes:
if $programnameline sends the log files to the
syslogserver. It follows the same syntax as the
/var/log/syslogfile, where @ indicates UDP, 192.168.1.2 is the IP address of the
syslogserver, and 514 is the UDP port.
For TCP-based syslog, use two @@ before the IP address: @@192.168.1.2:514.
syslogover TCP places a burden on the switch to queue packets in the
syslogbuffer. This may cause detrimental effects if the remote
syslogserver becomes unavailable.
The numbering of the files in
/etc/rsyslog.d/dictates how the rules are installed into
rsyslog.d. If you want to remotely log only the messages in
/var/syslog, and not those in
/var/log/switchd.log, for instance, then name the file
98-remotesyslog.conf, since it's lower than the
Writing to syslog with Management VRF Enabled
You can write to syslog with management VRF enabled by applying the following configuration; this configuration is commented out in the
Rate-limiting syslog Messages
If you want to limit the number of
syslog messages that can be written to the
syslog file from individual processes, add the following configuration to
/etc/rsyslog.conf. Adjust the interval and burst values to rate-limit messages to the appropriate levels required by your environment. For more information, read the rsyslog documentation.
Harmless syslog Error: Failed to reset devices.list
The following message gets logged to
/var/log/syslog when you run
systemctl daemon-reload and during system boot:
This message is harmless, and can be ignored. It is logged when
systemd attempts to change cgroup attributes that are read only. The upstream version of systemd has been modified to not log this message by default.
systemctl daemon-reload command is often issued when Debian packages are installed, so the message may be seen multiple times when upgrading packages.
The links below discuss more specific monitoring topics.
- Single User Mode - Boot Recovery
- Resource Diagnostics Using cl-resource-query
- Monitoring System Hardware
- Monitoring Virtual Device Counters
- Buffer Monitoring
- Understanding the cl-support Output File
- Troubleshooting Network Interfaces
- Network Troubleshooting
- SNMP Monitoring
- Monitoring Best Practices