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

During a routine configuration review in a newly assigned network environment, I noticed that syslog messages from a Cisco Nexus switch were not appearing on the NMS.

The switch itself was reachable through the management network, so the basic management path initially appeared to be working. However, when I checked the remote syslog configuration, I found an inconsistency between the management routing path and the VRF used by the syslog servers.

This became the starting point of the troubleshooting process.

Environment

The device was a Cisco Nexus 9000 Series switch using the dedicated management interface for out-of-band management.

Management interface: mgmt0
Management routing: management VRF
Remote syslog transport: UDP 514
Remote syslog severity: notifications
Remote syslog facility: local7

NTP was also configured through the same management interface and management VRF, and NTP communication was working normally.

ntp server <NTP-SERVER-IP> use-vrf management
ntp source-interface mgmt0

Because NTP was already working through the same management path, a general failure of the management interface or management VRF routing was less likely.

Step 1: Check the Remote Syslog Server Configuration

The first command I checked was:

show logging server

The important fields were:

Server status
Server severity
Server facility
Server VRF
Server port

The management gateway was configured through the management VRF, but the NMS syslog servers were configured to use the default VRF.

This did not match the actual management routing design.

The syslog servers were therefore changed to use the management VRF.

The relevant configuration concept is:

logging server <NMS-IP> <severity> use-vrf management

After the change, the NMS servers showed the expected management VRF in the remote logging configuration.

Step 2: Verify the Syslog Source Interface

The source interface was already configured as:

logging source-interface mgmt0

This matched the intended out-of-band management path.

At this point, both the source interface and the VRF used for the NMS servers were aligned with the management network.

Step 3: Verify Reachability Through the Management VRF

The NMS servers were reachable through the management VRF.

A successful reachability test confirmed that the routing path between the switch and the NMS was working.

Because NTP was also operating successfully through mgmt0 and the management VRF, the underlying management network path was considered healthy.

Step 4: Verify the Syslog Severity Level

The remote syslog servers were configured with:

Server Severity: notifications

Syslog severity levels are numbered from 0 to 7:

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

Lower numbers represent higher severity.

When the remote syslog server is configured for severity level 5, messages with severity levels 0 through 5 are eligible for forwarding.

Step 5: Verify a New Qualifying Syslog Event

One common troubleshooting mistake is checking only old syslog messages that were generated before a configuration change.

After the VRF configuration was corrected, a new message was generated:

VSHD-5-VSHD_SYSLOG_CONFIG

The middle value, 5, represents the severity level.

Because the remote server was configured for notifications, this message was eligible to be forwarded to the NMS.

The new event was successfully received by the NMS.

Facility and Severity Are Different

It is important not to confuse the syslog facility with the severity level.

In this configuration:

local7

was the remote syslog facility.

It does not mean severity level 7.

For example:

VSHD-5-VSHD_SYSLOG_CONFIG

has severity level 5, while local7 is a separate facility value used for remote syslog delivery.

Final Result

The troubleshooting process identified two separate issues.

First, the remote syslog servers were configured to use the wrong VRF. They were using the default VRF even though the device management path used the management VRF.

After correcting the syslog server VRF, the switch-side configuration matched the actual network design.

The remaining collection issue was then traced to the receiving side, where the syslog collection target or device association was not configured correctly.

Once the receiving-side configuration was corrected, newly generated syslog messages were successfully collected by the NMS.

Troubleshooting Checklist

Check the configured remote syslog servers.
```
show logging server
```
Verify that each syslog server uses the correct VRF.
Check the configured source interface.
```
show running-config | include logging
```
Verify reachability through the intended VRF.
Confirm that the configured severity includes the messages you expect to receive.
Verify that a new qualifying syslog event is generated after the configuration change.
If the network path and switch-side configuration are correct, check the receiving NMS or syslog collector.

Receiving-Side Checks

If the Nexus configuration appears correct but the NMS still does not display logs, check:

Whether UDP 514 is accepted by the collector
Whether the correct device source IP is registered
Whether facility or severity filters are applied
Whether the device is associated with the correct syslog collector
Whether the NMS is filtering or discarding the received messages

Related Guide

If you want a field-by-field explanation of the show logging server output, including status, severity, facility, VRF, and port, see:

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

Key Takeaway

A remote syslog issue is not always caused by the syslog configuration itself.

In this case, an incorrect VRF configuration was found on the switch, but the final collection issue also involved the receiving side.

The most useful troubleshooting sequence was:

VRF
→ source interface
→ reachability
→ severity
→ new syslog event
→ receiving NMS

Checking each stage separately makes it easier to identify the actual failure point without changing multiple settings at the same time.

References

Cisco Nexus 9000 Series NX-OS System Management Configuration Guide - Configuring System Message Logging

Note: All IP addresses, hostnames, customer information, and site-specific network details have been intentionally omitted or generalized.

Search This Blog

NetOps Field