SNMPv3 Discovery Gaps in a Retail Estate
A retail chain has 380 switches, 90 access points, and 25 firewalls spread across 412 stores. XIQ-SE discovery uses one discovery profile with a single SNMPv3 credential configured for SHA-1 authentication and AES-128 privacy, plus an SNMPv2c community string. After the first sweep, 64 devices appear as IP-only entries, 22 devices are in Managed state but show red status icons, and 15 stores appear to share the same management IP address. The stores sit behind ISP routers; UDP 161 is permitted inbound only from the central management VLAN, and the new switches were hardened to SNMPv3 with SHA-256 authentication. Store network engineers report that the devices are reachable by ping from the XIQ-SE server. The project manager wants to add the SHA-256 credential and rerun discovery across the entire 10.0.0.0/8 range tonight.
1. How would you classify the 64 IP-only entries, and what checks would you run for each class?
Read the worked answer
IP-only means XIQ-SE reached the address but could not complete an SNMP session or did not match a device profile. Split the 64 by evidence:
- SNMP credential mismatch. The hardened switches use SHA-256, which is not in the profile. Verify by running an SNMP walk from the XIQ-SE server with the SHA-256 credential against a sample device. Also confirm the SNMPv3 user has the correct security level; authNoPriv will fail against an authPriv-only user.
- Firewall or ACL block. ICMP succeeds but UDP 161 is filtered. The stated rule permits inbound only from the central management VLAN, so check whether the XIQ-SE server's source address is in that VLAN and whether the ISP router permits the return path. Firewall logs and a packet capture on one store will settle it.
- NAT and duplicate management IPs. The 15 stores sharing an IP are almost certainly NATed behind ISP equipment. XIQ-SE cannot uniquely manage devices that present the same address. Those stores need a management tunnel, a unique loopback, or a local collector; rerunning discovery will only create duplicate or conflicting records.
- Wrong VRF or SNMP context. Some firewalls expose SNMP only in a management VRF; the credential is fine but the context is missing.
Do not mix these together as 'discovery failed'. Each class has a different fix and owner.
2. Critique the plan to add a SHA-256 credential and rescan 10.0.0.0/8 tonight. What profile design would you recommend?
Read the worked answer
The credential addition is necessary but the rescan plan is risky and inefficient.
- Credential order matters. XIQ-SE tries credentials in sequence. Put SNMPv3 SHA-256/authPriv first, then SHA-1/authPriv, then SNMPv2c as a last resort, then v1 only if legacy devices require it. If v2c sits first, devices may authenticate with weaker settings and hide the v3 problem.
- Scope the scan. A 10.0.0.0/8 sweep generates enormous ICMP and SNMP traffic, hits addresses that are not network devices, and may trigger IDS alarms across 412 stores. Use store-level management subnets or seed devices from the default gateway and core switch, and schedule per-region windows.
- Separate profiles by region or device class. A single global profile forces one credential set onto devices with different hardening. Create a hardened profile for the new switches, a legacy profile for older stores, and a firewall profile with the correct VRF/context.
- Test before the sweep. Validate each credential against two or three representative devices, confirm the source address seen by the store firewall, and check that the discovery profile's device matching will assign the right driver.
Nightly is fine for a pilot group, not for an estate-wide sweep with an untested credential.
3. What explains the 22 Managed devices with red status, and how is that different from the IP-only problem?
Read the worked answer
These devices passed SNMP discovery, so credentials and reachability at discovery time were good. Red status usually means a later health check failed: ICMP polling, port/interface polling, or an SNMP re-poll after the device was managed.
Common causes:
- The device is reachable from the XIQ-SE server but not from the poller path used for status. Check the device's status reason and last poll time; run ping and an SNMP get from the server to the device's management IP.
- Intermittent WAN or ISP link. A store link that flaps will produce red icons while discovery still succeeds during the up window. Correlate with alarm history and interface flap events.
- Wrong device profile or model. The device was matched to a driver that polls OIDs it does not support, producing partial status. Confirm the model and firmware are recognized.
- Duplicate IP/NAT conflict. One of the 15 NATed stores may have overwritten or conflicted with an existing record, so the managed entry points at the wrong device.
Unlike IP-only, this is not a discovery credential problem; it is a polling, reachability, or modeling problem. Fixing credentials will not clear these 22 icons.