Solved

SNMPv3 Issues


Userlevel 2

Hi All,

I’m getting these SNMPv3 errors on our Extreme Control appliance from random switches;

 SNMP_V3_NOT_IN_TIME_WINDOW(1411) from device: 192.168.64.87 with message: org.snmp4j.asn1.BERInputStream@d5ffd43

 

and

 SNMP_V3_UNKNOWN_SECURITY_NAME(1404) from device: 192.168.231.20 with message: org.snmp4j.asn1.BERInputStream@7688ed06
 

They're talking fine to EMC, no alarms.

 

Any advice on what these errors are caused by please?

 

Thanks

Ian

icon

Best answer by Miguel-Angel RODRIGUEZ-GARCIA 1 October 2020, 11:07

Ian,

That could be a duplicate snmp engineid.

What type of switches are causing this?

You can check the snmp engineid issue with this: https://gtacknowledge.extremenetworks.com/articles/Solution/NAC-loses-contact-with-switch-after-changing-the-SNMPv3-engineid/

Mig

View original

10 replies

Userlevel 4

Hello,

there is a KB-Article on this topic:

https://gtacknowledge.extremenetworks.com/articles/Q_A/000052324
And this for further Troubleshooting: https://gtacknowledge.extremenetworks.com/articles/How_To/NAC-Troubleshooting-Tips-Debug-SNMP-Issues-With-Switches

What XMC/NAC versions are you using? which switches are affected? What firmware?

Userlevel 6
Badge +1

Ian,

That could be a duplicate snmp engineid.

What type of switches are causing this?

You can check the snmp engineid issue with this: https://gtacknowledge.extremenetworks.com/articles/Solution/NAC-loses-contact-with-switch-after-changing-the-SNMPv3-engineid/

Mig

Userlevel 4

That could be a duplicate snmp engineid.

But he says that XMC can communicate fine with the switches. This wouldn’t be possible.

 

Userlevel 2

You are right actually, I have engine id issue which I believe derive from the fact that configs are copied onto switches for ease of configuration and then tweaked.

 

I’ll deal with these first and then let you know if the issues disappear. I'm amending the IDs to match the SW MAC for each switch.

I'm not getting the snmp issues within EMC though, only the NAC appliance.

EMC and NAC are both 8.4.3.24. 

Userlevel 6
Badge +1

You are right actually, I have engine id issue which I believe derive from the fact that configs are copied onto switches for ease of configuration and then tweaked.

 

I’ll deal with these first and then let you know if the issues disappear. I'm amending the IDs to match the SW MAC for each switch.

I'm not getting the snmp issues within EMC though, only the NAC appliance.

EMC and NAC are both 8.4.3.24. 

Ian,

I had a similar issue with Industrial switches Extreme ISW where the engineid as the same default value at first boot. This has to be adapted manually per switch.

Regards,

 

Mig

Userlevel 2

ok looks to have resolved the issue now thankfully. Still have one switch complaining though

 

2020-10-02 14:44:47,097 WARN  [com.enterasys.tesNb.server.snmp.SnmpManager] (DefaultUDPTransportMapping_0.0.0.0/0:) Reinitializing switch SNMP info: 192.168.231.17
2020-10-02 14:44:56,093 WARN  [com.enterasys.tesNb.server.snmp.SnmpManager] (DefaultUDPTransportMapping_0.0.0.0/0:) Received Authentication Failure: SNMP_V3_NOT_IN_TIME_WINDOW(1411) from device: 192.168.231.17 with message: org.snmp4j.asn1.BERInputStream@20ced8e1
2020-10-02 14:44:56,093 WARN  [com.enterasys.tesNb.server.snmp.SnmpManager] (DefaultUDPTransportMapping_0.0.0.0/0:) Removing USM Time and EngineID: 80:00:07:7c:03:00:04:96:*:*:* for: 192.168.231.17
2020-10-02 14:44:56,093 WARN  [com.enterasys.tesNb.server.snmp.SnmpManager] (DefaultUDPTransportMapping_0.0.0.0/0:) Reinitializing switch: 192.168.231.17
 

its an x440-g2-48p-10ge4, running 22.5.1.7.-patch1-3.

Userlevel 6
Badge +1

Ian,

did you cleared the data cache in the NAC Engine?

Mig

Userlevel 2

I haven't no, is this within the linux cli?

Userlevel 6
Badge +1

Here: https://gtacknowledge.extremenetworks.com/articles/Solution/NAC-loses-contact-with-switch-after-changing-the-SNMPv3-engineid/

Mig

Userlevel 2

Lovely ta.

Feature request, reload/clear all button :)

they were all established but some info was unknown so just reloading those.

Reply