We could see “Not in time windows counter” increasing on multiple ACX7K devices due to which UIM discovery fails randomly.
show snmp statistics
Sep 25 12:45:07
SNMP statistics:
Input:
Packets: 9826, Bad versions: 0, Bad community names: 0,
Bad community uses: 0, ASN parse errors: 0,
Too bigs: 0, No such names: 0, Bad values: 0,
Read onlys: 0, General errors: 0,
Total request varbinds: 141978, Total set varbinds: 0,
Get requests: 9689, Get nexts: 0, Set requests: 0,
Get responses: 0, Traps: 0,
Silent drops: 0, Proxy drops: 0, Commit pending drops: 0,
Throttle drops: 0, Duplicate request drops: 0
V3 Input:
Unknown security models: 0, Invalid messages: 0
Unknown pdu handlers: 0, Unavailable contexts: 0
Unknown contexts: 0, Unsupported security levels: 0
Not in time windows: 123, Unknown user names: 0 <<<<<
Unknown engine ids: 14, Wrong digests: 0, Decryption errors: 0
Output:
Packets: 9689, Too bigs: 0, No such names: 0,
Bad values: 0, General errors: 0,
Get requests: 0, Get nexts: 0, Set requests: 0,
Get responses: 9689, Traps: 0
Performance:
Average response time(ms): 5.13
Number of requests dispatched to subagents in last:
1 minute:1, 5 minutes:692, 15 minutes:2077
Number of responses dispatched to NMS in last:
We observed that the discovery of same router happen some times & do not happen most of other time.
We collected the pcaps from device & for working node per pcap, we can see msgAuthoritativeEngineTime from UIM is 0.
The ACX sends a 7 digit value in report & in get-next-req packet, UIM uses this msgAuthoritativeEngineTime from ACX.
But in non-working node per pcap, we can see a higher msgAuthoritativeEngineTime from UIM.
The ACX sends a lower value in report & this get tagged as usmStatsNotInTimeWindows at UIM.
Non-Working:
msgAuthoritativeEngineTime ≠ 0 > means UIM is telling ACX this is the value to be used.
ACX rejects it since its high & shares its value. UIM must be rejecting this with usmStatsNotInTimeWindows
UIM send msgAuthoritativeEngineTime=5746772
ACX replies msgAuthoritativeEngineTime=3069510
Working:
msgAuthoritativeEngineTime = 0 > means UIM is asking ACX to share the engine time.
ACX shares this & UIM uses it from next packet onwards.
UIM send msgAuthoritativeEngineTime=0
ACX replies msgAuthoritativeEngineTime=3069918
Fro Junos router:
We had checked the available pcaps & we can see UIM is sending msgAuthoritativeEngineTime=0 every time for discovery.
Hence we do not observe the non discovery for Junos devices.
Oracle UIM team analysed our observations & found that they are using msgAuthoritativeEngineID is same for ACX7K devices, which has value of 80000a4c0100000000.
From EVO box:
show snmp v3 | grep “engine ID”
Local engine ID: 80 00 0a 4c 01 00 00 00 00
Engine ID: local
We can see that all devices in output are having Engine ID mapped to "local".
But the "Local engine ID" is flagged to same default value "80 00 0a 4c 01 00 00 00 00", for all devices.
This is due to missing config for snmp engine-id in config & no active management interface.
https://www.juniper.net/documentation/us/en/software/junos/network-mgmt/topics/topic-map/configure-the-local-engine-id.html
From Doc:
For the engine ID, we recommend using the primary IP address of the device if the device has multiple routing engines and has the primary IP address configured. Alternatively, you can use the MAC address of the management port if the device has only one Routing Engine.
set snmp engine-id <>
use-default-ip-address Use default IP address for the engine ID
use-mac-address Uses management interface MAC Address for the engine ID
Issue was resolved after adding engine-id with use-mac-address option in all EVO devices.
For the behaviour of SNMP v3 engine ID, with management interface down, pls refer below KB.
https://supportportal.juniper.net/s/article/EVO-SNMP-V3-Engine-ID-when-management-interface-is-disabled-or-down