Cisco Nexus show logging server Explained: Status, Severity, Facility, VRF, and Port

When troubleshooting remote syslog on a Cisco Nexus switch, one of the most useful commands is:

show logging server

The command provides a quick view of how each remote syslog server is configured and whether the switch has detected any transmission problem.

This article explains the main fields you should check and how to interpret them during troubleshooting.

Why show logging server Is Useful

A remote syslog configuration can look correct in the running configuration while still using the wrong VRF, severity level, facility, or destination.

The show logging server command makes these values easier to verify in one place.

The most useful fields are:

• Server status
• Server severity
• Server facility
• Server VRF
• Server port

Server Status

Cisco NX-OS can display different states for a configured remote syslog server.

Cisco documents the following states:

• Configured - The syslog server configuration was accepted.
• No errors found - Syslog transmission to the remote server has succeeded.
• Temporarily unreachable - NX-OS detected a transmission problem and continues probing the destination.

If the problem is later resolved, the status can change from Temporarily unreachable to No errors found.

However, No errors found does not necessarily mean that the NMS is displaying the message correctly. It confirms successful transmission from the switch perspective, but the receiving server can still filter, discard, or incorrectly associate the message.

Server Severity

Syslog severity levels range from 0 through 7.

• 0 - Emergency
• 1 - Alert
• 2 - Critical
• 3 - Error
• 4 - Warning
• 5 - Notification
• 6 - Informational
• 7 - Debugging

A lower number represents a more severe condition.

For example, if a remote syslog server is configured for:

notifications

or severity level:

5

messages with severity levels 0 through 5 are eligible to be forwarded.

Severity levels 6 and 7 would not be included.

Example

A message such as:

VSHD-5-VSHD_SYSLOG_CONFIG

contains severity level 5.

If the remote server is configured for notifications, this message is within the configured severity range.

Server Facility

Facility and severity are separate values.

Cisco NX-OS uses local7 as the default outgoing syslog facility.

This does not mean severity level 7.

For example:

Facility: local7
Severity: notifications

means that the outgoing messages use the local7 facility while severity level 5 is used as the filtering threshold.

This distinction is important because some syslog collectors apply rules based on facility, severity, or both.

Server VRF

The VRF determines which routing table NX-OS uses to reach the remote syslog server.

Cisco NX-OS supports selecting a VRF with the use-vrf keyword.

logging server <SYSLOG-IP> <SEVERITY> use-vrf <VRF-NAME>

For an out-of-band management design, the syslog server may need to use the management VRF.

For example:

logging server <SYSLOG-IP> 5 use-vrf management

If the management interface and gateway use the management VRF but the syslog server uses the default VRF, the switch may attempt to reach the destination through the wrong routing table.

This is one of the first fields I check when syslog is not reaching an NMS.

Server Port

Traditional syslog commonly uses UDP port 514.

When checking the output, confirm that the configured port matches the port expected by the receiving syslog server or NMS.

A correct route and VRF will not help if the collector is listening on a different port.

Source Interface

The source interface is another important part of remote syslog troubleshooting.

You can check the logging-related running configuration with:

show running-config | include logging

In an out-of-band management design, you may see:

logging source-interface mgmt0

The source interface, selected VRF, and routing path should all match the intended management design.

What show logging server Can and Cannot Tell You

The command is useful, but it does not prove that the NMS is displaying or processing the message correctly.

It can help verify:

• Which syslog servers are configured
• Which VRF is used
• The severity threshold
• The outgoing facility
• The destination port
• Whether NX-OS has detected a transmission problem

It cannot confirm:

• Whether the NMS associated the source IP with the correct device
• Whether the collector filtered the message
• Whether a facility or severity filter dropped the message
• Whether the application displayed the received syslog correctly

Practical Troubleshooting Order

When remote syslog is not working, I normally verify the following in order:

1. Run show logging server.
2. Confirm the correct syslog server IP or hostname.
3. Check the VRF.
4. Check the source interface.
5. Verify reachability through the intended VRF.
6. Check the severity threshold.
7. Confirm that a new qualifying syslog message has been generated.
8. If the switch side is correct, check the receiving NMS or collector.

Related Troubleshooting Example

I recently used this exact process while troubleshooting a Cisco Nexus switch where syslog messages were not appearing on the NMS.

The remote syslog servers were initially using the wrong VRF, and the receiving side also required correction.

You can read the complete troubleshooting process here:

Cisco Nexus Syslog Not Reaching NMS: VRF, Source Interface, and Severity Troubleshooting

Key Takeaway

The show logging server command is more useful than simply checking whether a syslog server IP exists in the configuration.

During troubleshooting, focus on:

Status
Severity
Facility
VRF
Port
Source Interface

If all of these values match the actual network design, but logs still do not appear on the NMS, the next step should be to verify the receiving side rather than repeatedly changing the switch configuration.

References

• Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 10.6(x) - System Message Logging