SNMP targets were configured on a new Data Domain during bring-up, and the NMS console has received nothing yet. What closes the loop on SNMP during basic testing?
Select an answer to reveal the explanation.
Short Explanation
A configured SNMP target is a hope, not a fact - and a silent console proves nothing either way. Fire the test trap the box can send on demand and watch it appear on the manager. If you can't see it arrive, it isn't configured, it's wished for.
Full Explanation
Traps are one-way messages pushed from the appliance to a configured manager, so end-to-end proof has to be a delivery observation, not a configuration review. A built-in test trap exercises every element at once: the correct protocol version (v2c community string or v3 user and authentication settings), the destination address and UDP port 162, and any firewall between them. Seeing the trap timestamped on the NMS is the receipt that completes the line item. Verifying the service is enabled inspects only the sender half; SNMP can be perfectly enabled while targeting a wrong address or a blocked port, and it ignores the manager side entirely where most silent drops live. Lowering the severity threshold is a trap for production: it may flood the console with noise, and if the path is broken the flood will be just as silent as the silence was, so the test substitutes volume for evidence. Waiting days for a natural alert leaves the monitoring path unproven through the riskiest window - the first days of service - and may never produce an alert at all. Exam caveat: version three with a wrong authentication digest drops silently at the manager, which is precisely the failure a forced test trap surfaces. Operational check: a test trap initiated from the appliance and visible in the NMS event list with matching timestamps, attached to the acceptance record.