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: management VRF
  • 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.

Cisco Nexus syslog path from mgmt0 through the management VRF to the NMS on UDP 514
In this case, remote syslog needed the management VRF to match the mgmt0 routing path.

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.

Syslog severity 5 and facility local7 shown as separate values sent from a Nexus switch to an NMS
A notifications threshold permits severity levels 0 through 5. The local7 facility is a separate value.

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.

Six syslog checks in order: VRF, source interface, reachability, severity, new event, and receiving NMS
Verify the switch settings, generate a new qualifying event, and check the receiving collector.

Troubleshooting checklist

  1. Check the configured remote syslog servers.
    show logging server
  2. Verify that each syslog server uses the correct VRF.
  3. Check the configured source interface.
    show running-config | include logging
  4. Verify reachability through the intended VRF.
  5. Confirm that the configured severity includes the messages you expect to receive.
  6. Verify that a new qualifying syslog event is generated after the configuration change.
  7. 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

Popular posts from this blog

Alteon Sessions Show Established, but HTTPS Authentication Fails Intermittently

Cisco Catalyst 9200L Upgrade: Fixing “Super Package Already Added”

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