我正在尝试使用引擎时间值模拟snmp v3陷阱。长话短说，我们的陷阱处理器将从任何主机接收第一个snmp v3陷阱，但是任何后续陷阱将重新调整“ 错误！乱码”和“ SNMP-D-EAGENTUSMWINDOW-Agent报告[USM]”：在时间窗口中”。接收v3陷阱的唯一方法是继续重新启动陷阱处理器..
我被告知这是因为陷阱没有有效的Engine-boot或Engine-Time，我一直在使用以下示例来模拟V3陷阱，但是它不包含Engine time，因此我们的陷阱处理器将第一次处理此错误，第二次收到时给出错误...
snmptrap -v 3 -e EngineID -u用户-a SHA -A Auth Pass -x AES -X Pri-Pass -l authpriv -Z 123目标IP：162''.1.3.6.1.4.1.3375.2.4.0 .27 .1.3.6.1.4.1.3375.2.4.1.1 s“失败的登录FreddyFrogAA，身份验证失败”
任何帮助将不胜感激
雷
答案 0 :(得分：0)
当SNMP陷阱接收器从sm_snmp接收到第一个陷阱时，它将在其内部表中创建一个条目，表示其对陷阱发送器的时间估计。 SNMP陷阱接收器随后将其估计值与该代理最近接收到的陷阱（或其他SNMP V3响应）进行比较，以验证是否正在重播数据包。 使用sm_snmp发送陷阱意味着您每次都执行sm_snmp。这意味着sm_snmp的行为就像刚刚重新启动一样，并相应地设置了引擎启动时间。对于陷阱接收器，这看起来与已接收到的包相同。陷阱接收器期望带有时间戳的数据包，该时间戳表示远程代理已在第一陷阱和第二陷阱之间的时间之前进行了处理。因此，如果您等待的时间比发送第一个陷阱和第二个陷阱之间的时间窗口（150秒）更长，则陷阱处理程序将报告“不在时间窗口中”。
解决方案： 如果日志中的消息仅限于SNMP-D-EAGENTUSMWINDOW-Agent REPORT [USM]：不在时间窗口中。陷阱接收器正在按设计工作，并将继续按要求处理陷阱。
如果陷阱接收器日志也报告了错误！值混杂。然后问题出在，设备snmpagent无法发送正确的引擎启动或引擎时间值。需要咨询供应商以解决snmp-agent的问题。 建议客户在设备上为snmp v3流量运行数据包捕获，以向供应商提供证据，以便他们可以解决问题。