Cisco Nexus Syslog Not Reaching NMS: Troubleshooting VRF, mgmt0, and Severity
During a routine configuration review in a newly assigned environment, I found that a Cisco Nexus switch was reachable over the management network, but its syslog messages were missing from the NMS. The remote syslog servers used a different VRF from the management routing path. Correcting that mismatch was part of the fix; the receiving NMS also needed a configuration correction before collection worked.
Environment
The switch was a Cisco Nexus 9000 Series device using its dedicated interface for out-of-band management.
- Management interface:
mgmt0 - Management routing:
managementVRF - Remote syslog transport: UDP 514
- Remote syslog severity:
notifications - Remote syslog facility:
local7
NTP was working through the same management interface and VRF:
ntp server <NTP-SERVER-IP> use-vrf management
ntp source-interface mgmt0
Working NTP made a general management interface or routing failure less likely.

1. Check the remote syslog servers
I started with:
show logging server
I checked these fields:
- Server status
- Server severity
- Server facility
- Server VRF
- Server port
The management gateway used the management VRF, while the NMS syslog servers used the default VRF. I changed the syslog servers to the management VRF to match the out-of-band routing design. The configuration follows this form:
logging server <NMS-IP> <severity> use-vrf management
The remote logging configuration then showed the expected VRF for the NMS servers.
2. Verify the source interface
The switch already used the intended source interface:
logging source-interface mgmt0
With the server VRF corrected, both settings matched the management network.
3. Check reachability through the management VRF
A reachability test to the NMS servers through the management VRF succeeded. Together with working NTP over mgmt0 in the management VRF, this supported checking the remaining syslog settings and the collector.
4. Check the severity threshold
The remote servers had this threshold:
Server Severity: notifications
Syslog uses eight severity levels:
- 0 - Emergency
- 1 - Alert
- 2 - Critical
- 3 - Error
- 4 - Warning
- 5 - Notification
- 6 - Informational
- 7 - Debugging
Lower numbers indicate more severe events. A threshold of 5 permits messages at levels 0 through 5.
5. Validate with a new event
I checked a new event after the configuration change, so the validation would not depend on messages generated under the old settings. The new message was:
VSHD-5-VSHD_SYSLOG_CONFIG
The middle value, 5, is its severity. That falls within the configured notifications threshold. The NMS received the new event once both the switch VRF and the receiving configuration were corrected, as described below.
Facility and severity
The facility identifies a separate syslog value from the severity threshold. The remote facility in this configuration was:
local7
The 7 in the facility name does not set the severity to 7. The earlier message illustrates the difference:
VSHD-5-VSHD_SYSLOG_CONFIG
Its severity is 5; local7 is the facility used for remote delivery.

What restored collection
Collection required corrections at both ends. The switch had used the default VRF for the servers even though the management path used the management VRF. After that correction, a collection problem remained on the NMS. Its syslog collection target or device association was configured incorrectly. Correcting the receiving configuration allowed the NMS to collect newly generated messages.

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.
Check the receiving NMS
If the switch configuration checks out but logs are still missing, check the collector:
- 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 guides
For the meaning of each show logging server field, including status, severity, facility, VRF, and port, see:
Cisco Nexus show logging server Explained: Status, Severity, Facility, VRF, and Port
For a broader explanation of event-driven SNMP notifications and how an NMS processes them, see Cisco Nexus SNMP Traps Explained: When They Are Sent and What Happens Next.
Troubleshooting order
The checks followed this order:
VRF
→ source interface
→ reachability
→ severity
→ new syslog event
→ receiving NMS
Check each stage separately so that a change and its result can be evaluated before moving to the next setting.
References
IP addresses, hostnames, customer information, and site-specific network details have been omitted or generalized.
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.
Comments
Post a Comment