Trap exploder reports trap receiver error 'SNMP-D-EAGENTUSMWINDOW-Agent REPORT [USM]: Not In Time Window.'

Products

• VMware Smart Assurance

Issue/Introduction

Symptoms:

Smarts Trap processors reports the following trap receiver error:
SNMP-D-EAGENTUSMWINDOW-Agent REPORT [USM]: Not In Time Window.

Environment

Smarts 10.1.X

Cause

SNMP V3 has added security features, one of which is the timestamps in SNMP packets to prevent replay attacks. When the SNMP trap receiver receives the first trap from sm_snmp, it creates an entry in its internal table representing its estimate of the time on the trap sender. The SNMP trap receiver will then compare its estimate with newly received traps (or other SNMP V3 responses) from that agent to verify that the packet is not being replayed.

Using sm_snmp to send the trap means that you execute sm_snmp each time. That means sm_snmp acts as if was just restarted and sets the engine boot time accordingly. To the trap receiver, this looks like an identical packet to the one already received. The trap receiver expects a packet with a timestamp that represents the remote agent having advanced by the time between the first and second traps. So the trap handler reports "Not In Time Window" if you wait longer than the time window (150 seconds) between sending the first and second traps.

If the Smarts Trap receiver log is also reporting *Error!* Mangled value. Then the issue is with the device snmpagent not sending out the proper engine-boot or engine-time values.

OCTET-STRING (0x04), 11 bytes == xxxxxxxxxxxx 
67: usm-authentication-parameters -> 
OCTET-STRING (0x04), 12 bytes == (hex) d4 4e ee 57 5a 4f 0b ba dd c8 fe 2a 
81: usm-privacy-parameters -> 
OCTET-STRING (0x04), 8 bytes == *Error!* Mangled value. 
00091: Remainder of the bad packet follows. 
{ 04, 66, 6a, 8a, eb, c5, 18, b6, d1, 83, a1, 39 ....

Resolution

If the message in the log is limited to SNMP-D-EAGENTUSMWINDOW-Agent REPORT [USM]: Not In Time Window. The Smarts trap receiver is working as designed and will continue to process traps as required. 

In such cases, the issue is with the device snmpagent not sending out the proper engine-boot or engine-time values. The vendor needs to be consulted to resolve the issue with the snmp-agent.
It is recommended that the customer run a packet capture on the device for snmp v3 traffic to provide the vendor with the evidence so they can resolve the issue.

Workaround:

The workaround is to configure the device to send snmp v2 traps and the trap receiver to process the trap from the device as snmp v2.