Error: Syslog Alerts Due to Smarts Polling Wrong Loopback IP

Products

• VMware Smart Assurance

Issue/Introduction

Cisco routers generate security syslog messages when VMware Smart Assurance attempts access via non-designated loopback IPs․  Each device has multiple loopback interfaces, and incorrect syslog alerts trigger when Smarts selects the wrong one․​​​​​‌​‍  This happens even though the correct LOOPBACK address was specified in the seed file when discovered.

SYMPTOMS:

• Routers generate security syslog messages during Smarts polling

• Smarts selects the incorrect loopback interface for monitoring

• False device down alerts occur if the chosen loopback loses routing

CONTEXT: Occurs during SNMP polling and ICMP pings across MPLS Management VPNs․

IMPACT: Generates excessive incorrect security syslog alerts and impacts accurate device monitoring․

Environment

VMware Smart Assurance (Smarts)

The LOOPBACK interface is used for monitoring (either globally or for individual devices).

A․ SET GLOBAL ACCESS FORMAT (OPTIONAL: applies to all devices) 

Path: discovery․conf Command: AccessAddressFormat = "LOOPBACKADDRESS"

EXPECTED: Forces all discovery and polling to use loopback interfaces globally․

or

B․ INFLUENCE TARGETED ACCESS FORMAT (OPTIONAL: target individual devices)

Path: Discovery seed file Command: ADDRESSFORMAT=LOOPBACKADDRESS

Add this parameter to specific entries in the seed file using the preferred management IP as the discovery target․

Cause

1. Cisco routers running MPLS VPN services often carry more than one loopback (e.g., one for the management plane/router-id, others per-VRF for L3VPN service routing
2. The loopback specified in the seed file only controls the initial discovery target․ When AccessAddressFormat=LOOPBACKADDRESS is set, IP Manager collects up to 10 loopback interfaces and rebuilds the access list every discovery cycle․ This is by design as it provides resiliency against single-path failures but prevents strict pinning to a single IP by default․

Resolution

PREREQUISITES:

Please note: The IPExcludeList will avoid creating the IP address in the topology during the discovery phase. The whole intent of collecting all the reachable Ipaddress in the AgentAddresList is to make sure smarts does uses them during the monitoring phase when the primary IP address is not responding for some reason.  
The other criteria is to unmanage the IP address that will disallow them to be part of the AgentAddressList. But the side effect of this will have impact in the RCA computation while deducing the device UNRESPONSIVE / DOWN.  

This solution is applicable if only one LOOPBACK is valid for monitoring the device in Smarts as all other will be removed from monitoring. e.g. if the other loopbacks are VRF-service loopbacks, there is almost certainly zero use for Smarts touching them, which means ipExcludeList fully excluding them (not just from polling, but from the topology model) is not a compromise, it's the correct outcome. 

STEPS:

CONFIGURE IP EXCLUDE LIST

Path: discovery․conf

Add unwanted loopback IP ranges to the ipExcludeList parameter․

EXPECTED: Keeps unwanted loopbacks out of SNMP polling and ICMP ping cycles reliably․ NOTE: This parameter supports wildcard patterns to cover diagnostic or secondary loopback blocks with fewer entries․

Further information on how the IP Exclude List is configured here

VERIFY SUCCESS:

• Smarts utilizes only the correct loopback IP for polling

• Security syslog alerts cease for incorrect loopback access

Additional Information

Benefits of using a loopback to monitor a device instead of an interface ip?

• Not tied to any single physical link. A loopback is a virtual interface that's always "up" as long as the router itself is up — it doesn't go down when a physical port fails, is admin-shut, or gets renumbered. If you monitor via a physical interface IP instead, losing that one link (even if the box is fine and reachable another way) makes it look unreachable.
• Reachable via any surviving path (multi-homed/redundant routing). Since the loopback isn't bound to one interface, the IGP/BGP can route to it over whichever uplink is currently up. A physical-interface IP only has as many paths to it as that interface has — often just one.
• Stable identity independent of topology changes. Loopbacks don't change when interfaces get re-cabled, re-IP'd, or hardware gets swapped. It's the one address on the box that's meant to represent "this device," which is exactly why it's also used as the router-id for OSPF/BGP/MPLS LDP.
• Matches the control-plane address anyway. Since routing protocols already peer off the loopback, using the same address for management/monitoring means one consistent "identity" for the device across NMS, routing, and troubleshooting — rather than an arbitrary interface IP that has no special meaning.
• Management-plane isolation via VRF/VPN. e.g.routing a dedicated MPLS management VPN that only carries the loopback, not the customer-facing/WAN interfaces. That keeps NMS traffic off links carrying customer/production traffic entirely — the physical interfaces literally aren't reachable from the management VPN at all in this design, only the loopback is advertised into it.
• Simplifies security/ACLs. One stable per-device address is trivial to allow-list for SNMP/SSH/etc. Tracking every physical interface IP (which can change) for ACL purposes doesn't scale and is exactly why the router logs a syslog alert the moment something tries to reach it via a non-loopback IP — that's the router's own ACL/security policy flagging out-of-band access attempts.