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

To check the remote syslog destinations configured on a Cisco Nexus switch, run:

show logging server

The output brings together each server's settings and any transmission problem NX-OS has detected.

Which fields to check

A server entry in the running configuration can still use the wrong VRF, severity threshold, facility, or destination. Use show logging server to inspect these settings together:

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

Review these five output fields, then check the configured source interface separately.

Server status

Cisco documents three server 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.

After a transmission problem clears, the status can change from Temporarily unreachable to No errors found. No errors found reports successful transmission from the switch's perspective. The collector can still filter or discard the message, associate it with the wrong device, or fail to display it.

These states describe configuration or transmission. Verify message handling on the collector separately.

Server severity

Syslog severity levels run from 0 through 7:

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

A lower number means a more severe condition. For a remote server configured with:

notifications

the numeric threshold is:

5

Messages at levels 0 through 5 qualify for forwarding; levels 6 and 7 are excluded. For example:

VSHD-5-VSHD_SYSLOG_CONFIG

The message has severity 5. It qualifies when the remote threshold is notifications.

Server facility

Facility and severity are separate values. NX-OS uses local7 as the default outgoing facility. The 7 in the facility name does not mean severity level 7. For example:

Facility: local7
Severity: notifications

Here, local7 is the outgoing facility and 5 is the severity threshold. Check both values against collector rules, which may filter on facility, severity, or both.

Server VRF

The VRF selects the routing table NX-OS uses to reach the server. Set it with use-vrf:

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

An out-of-band management path may require the management VRF:

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

If the management interface and gateway use that VRF while the syslog server uses the default VRF, NX-OS may look for the destination in the wrong routing table. This is one of the first fields I check when syslog is missing from an NMS.

Server port

Traditional syslog commonly uses UDP port 514. Match the configured destination port to the port on which the collector or NMS expects syslog. A reachable collector can still be listening on a different port.

Source interface

Check the source interface separately in the logging configuration:

show running-config | include logging

An out-of-band design may use:

logging source-interface mgmt0

The source interface, VRF, and route need to match the intended management path.

Configuration text and operational state answer different questions. Our guide to Cisco Nexus ICMP Unreachable: Why the Command Does Not Appear in Running-Config applies that distinction to interface ICMP checks; it does not establish whether syslog messages reached a collector.

What to verify on the collector

The server output describes the switch's configuration and transmission status. On the collector, check:

• 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

Check device association, filters, and message display on the collector, even when the switch reports successful transmission.

Troubleshooting order

I normally check a missing-syslog problem in this 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 case

In a Nexus syslog investigation, I found that the servers used the wrong VRF and that the receiving configuration also needed correction. The case is covered in:

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

For a comparison with SNMP event notifications, see Cisco Nexus SNMP Traps Explained: When They Are Sent and What Happens Next.

Before changing the switch again

Use show logging server to review these fields alongside the separately configured source interface:

Status
Severity
Facility
VRF
Port
Source Interface

If these settings match the network design and logs are still missing, inspect the receiving NMS or collector.

References

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

Related security review: Before removing an apparent local account used by SNMPv3, see Cisco Nexus SNMPv3 User Appears as a CLI Account: Before You Delete It.