Troubleshooting Tip: Identify cause of SNMPv3 MAC Trap Error: 'RFC3414 §3.2.7.a Not in time window'

[Hatibi]

Description	This article describes how to check the reason for FortiNAC not acknowledging SNMPv3 MAC notification traps and responding with error: 'received message outside time window' or 'RFC3414 §3.2.7.a Not in time window'.
Scope	FortiNAC, FortiNAC-F, Infrastructure Devices.
Solution	In order to debug and troubleshoot issues with FortiNAC being unable to process SNMPv3 MAC traps follow this article: Technical Tip: FortiNAC is not processing SNMP v3 MAC traps received from switches. The status is 1411, which indicates with SNMPv3_USM_NOT_IN_TIME_WINDOW that the time reference of the devices has drifted by more than 150 seconds. Each device uses two parameters, snmpEngineBoots and snmpEngineTime, which together are checked to define if the message is within a Time window of the current time. These enforce the Replay Protection feature of SNMPv3. The snmpEngineID identifies the snmpd instance of the Device itself and should be a unique value. It is usually built by using the MAC address of the device as a source. When the message is outside of the time window, FortiNAC will log the following messages: org.snmp4j.mp.MPv3 FINE :: 2024-11-04 08:25:27:730 :: #541 :: SNMPv3 header decoded: msgId=1070450467, msgMaxSize=1472, msgFlags=03, secModel=3 org.snmp4j.mp.MPv3 FINE :: 2024-11-04 08:25:27:730 :: #541 :: SNMPv3 header decoded: msgId=454554, msgMaxSize=1472, msgFlags=03, secModel=3 org.snmp4j.security.USM FINE :: 2024-11-04 08:25:27:730 :: #541 :: getUser(engineID=XXXXXXXXXXXX, securityName=FORTINACLAB) org.snmp4j.security.UsmTimeTable FINE :: 2024-11-04 08:25:27:730 :: #541 :: CheckTime: received message outside time window (non authoritative) org.snmp4j.security.USM FINE :: 2024-11-04 08:25:27:730 :: #541 :: RFC3414 §3.2.7.a Not in time window; engineID='XXXXXXXXXXXX', engineBoots=1, engineTime=245346 org.snmp4j.MessageDispatcherImpl INFO :: 2024-11-04 08:25:27:730 :: #541 :: Message from 10.10.10.1/47491 not dispatched, reason: statusInfo=1.3.6.1.6.3.15.1.1.2.0 = 1119, status=1411 As per RFC3414 section §3.2.7 (Processing and incoming SNMP message), one of the following causes may be the reason for the error. If the extracted value of msgAuthoritativeEngineID is the same as the value of snmpEngineID of the processing SNMP engine (meaning this is the authoritative SNMP engine), then if any of the following conditions is true, the message is considered to be outside of the Time Window: The local value of snmpEngineBoots is 2147483647. The value of the msgAuthoritativeEngineBoots field differs from the local value of snmpEngineBoots. The value of the msgAuthoritativeEngineTime field differs from the local notion of snmpEngineTime by more than +/- 150  seconds. If the message is considered to be outside of the Time Window, the usmStatsNotInTimeWindows counter is incremented. It is then necessary to report any error indication (notInTimeWindow) together with the OID, the value of the incremented counter, and the securityLevel of authNoPriv, returned to the calling module. The values of msgAuthoritativeEngineID and msgAuthoritativeEngineTime can be inspected from a packet capture as shown in the following example: Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgAuthoritativeEngineID: XXXXXXXX msgAuthoritativeEngineBoots: 1 msgAuthoritativeEngineTime: 76124947 msgUserName: FORTINACLAB The next step is to verify the values for snmpEngineBoots and snmpEngineTime on both the FortiNAC and the Switch or Infrastructure device that is sending the SNMPv3 MAC trap. Verifications in FortiNAC. In order to query the parameter values from FortiNAC it is required to enable its SNMP Agent feature in System -> Settings -> System Communication -> SNMP. Figure 1. SNMP Configuration in FortiNAC This feature is used when FortiNAC will be monitored through SNMP from an external Monitoring system. In this case, it is enabled only for checking the SNMP parameters through local queries. As seen in Figure 1, the 'Management Hosts' list shows the IP 127.0.0.1, which is the loopback IP for Localhost(FortiNAC itself). This list will be populated with new IPs of monitoring Servers each time an SNMP exchange is successful with FortiNAC. FortiNAC will trust only snmpget requests from Devices that are added as 'Pingable Devices' in the Inventory view. So it will trust only requests from Topology devices it recognizes. After snmpd is enabled, check the snmpEngineBoots and snmpEngineTime values. snmpEngineTime OID = 1.3.6.1.6.3.10.2.1.3 snmpEngineBoots OID = 1.3.6.1.6.3.10.2.1.2.0 Check snmpEngine values for FortiNAC(localhost) in CLI: snmpEngineTime naclab1 # execute enter-shell naclab1:~$ snmpwalk -c NACOS -v1 localhost 1.3.6.1.6.3.10.2.1.3 SNMP-FRAMEWORK-MIB::snmpEngineTime.0 = INTEGER: 264463 seconds naclab1:~$ snmpEngineBoots naclab1:~$ snmpwalk -c NACOS -v1 localhost 1.3.6.1.6.3.10.2.1.2.0 SNMP-FRAMEWORK-MIB::snmpEngineBoots.0 = INTEGER: 94 naclab1:~$ Check snmpEngine values for the Switch from the FortiNAC CLI. Depending on the SNMP version, use one of the following queries: snmpEngineTime snmpwalk -v 3 -u <username> -l <security-level> -a <auth-protocol> -A <auth-password> -x <priv-protocol> -X <priv-password> -r <ip_address> 1.3.6.1.6.3.10.2.1.3 snmpwalk -v2c -c  <communitystring> <ip_address> 1.3.6.1.6.3.10.2.1.3 snmpwalk -v1 -c <communitystring> <ip_address> 1.3.6.1.6.3.10.2.1.3 snmpEngineBoots snmpwalk -v 3 -u <username> -l <security-level> -a <auth-protocol> -A <auth-password> -x <priv-protocol> -X <priv-password> -r <ip_address> 1.3.6.1.6.3.10.2.1.2.0 snmpwalk -v2c -c  <communitystring> <ip_address> 1.3.6.1.6.3.10.2.1.2.0 snmpwalk -v1 -c <communitystring> <ip_address> 1.3.6.1.6.3.10.2.1.2.0 The results collected from FortiNAC and the third-party switch can be compared, in order to understand what is the cause of the timedrift message and which values need adjusting/resetting. In some occasions, Switches might have an SNMPv3 configuration in place, however, this does not mean that the MAC notification trap is an SNMPv3 trap. The conformity can be checked through a Packet capture. Example with Non-SNMPv3 message: Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgID: 7 msgMaxSize: 1472 msgFlags: 03 msgSecurityModel: USM (3) msgAuthoritativeEngineID: 0000000b0000eXXXXXXXXX 0... .... = Engine ID Conformance: RFC1910 (Non-SNMPv3) <--- Engine Enterprise ID: Hewlett-Packard (11) Example with an actual SNMPv3 MAC trap: Simple Network Management Protocol msgVersion: snmpv3 (3) msgGlobalData msgAuthoritativeEngineID: 8000bXXXXXXXXXXXX 1... .... = Engine ID Conformance: RFC3411 (SNMPv3) <--- Engine Enterprise ID: Hewlett Packard Enterprise (47196) Engine ID Format: MAC address (3) The SNMP module will only process the incoming message with SNMPv3 Conformance (b) using anti-replay and other security features. Message in (a), being non-conform to SNMPv3, will not be undergoing the same processing.  Related documentation: Technical Tip: FortiNAC is not processing SNMP v3 MAC traps received from switches Technical Tip: Troubleshooting SNMP communication issues Technical Tip: How to Setup SNMP Between FortiNAC and Network Monitoring Devices Technical Tip: Requesting SNMP trap support in FortiNAC Technical Tip: SNMPv3 agent configurations in old switches like HP2530 Technical Tip: FortiNAC-F, FortiSwitch, FortiLink SNMPv3 MAC Notification Traps