SNMP V3 Not working

[cisco]

Hi,

I have upgraded IOS one 3750 switch stack (two switch in that stack). I have upgraded from advipbase 12.2(25)SEE4 to advipbase 12.2(46)SE. From then SNMP has stopped working. i haven't done any changes on switch except for "boot" variable.Please help

regards

Neo

[Joe Clarke]

Verify all of your SNMP configuration is still present. Check the output of "show snmp user" to make sure your v3 users are still there. What counters are incrementing is "show snmp" when you attempt to poll this stack? How do you have SNMP configured on this stack?

[cisco]

Hi,

Yes configuration is present on the switch.

3750Switch#show snmp user

User name:

Engine ID: 8000000903000017E0119C81

storage-type: nonvolatile active

Authentication Protocol: MD5

Privacy Protocol: None

Group-name:

3750Switch#show snmp

Chassis: CAT1036Z3ZJ

Contact:

Location:

7069 SNMP packets input

0 Bad SNMP version errors

1689 Unknown community name

0 Illegal operation for community name supplied

0 Encoding errors

0 Number of requested variables

0 Number of altered variables

0 Get-request PDUs

0 Get-next PDUs

0 Set-request PDUs

0 Input queue packet drops (Maximum queue size 1000)

7494 SNMP packets output

0 Too big errors (Maximum packet size 1500)

0 No such name errors

0 Bad values errors

0 General errors

0 Response PDUs

2114 Trap PDUs

SNMP global trap: enabled

SNMP logging: enabled

Logging to 172.16.8.X.X, 0/10, 1700 sent, 414 dropped.

SNMP agent enabled

3750Switch#

3750Switch#show snmp

Chassis: CAT1036Z3ZJ

Contact:

Location:

7082 SNMP packets input

0 Bad SNMP version errors

1692 Unknown community name

0 Illegal operation for community name supplied

0 Encoding errors

0 Number of requested variables

0 Number of altered variables

0 Get-request PDUs

0 Get-next PDUs

0 Set-request PDUs

0 Input queue packet drops (Maximum queue size 1000)

7507 SNMP packets output

0 Too big errors (Maximum packet size 1500)

0 No such name errors

0 Bad values errors

0 General errors

0 Response PDUs

2117 Trap PDUs

SNMP global trap: enabled

SNMP logging: enabled

Logging to 172.16.8.X.X, 0/10, 1703 sent, 414 dropped.

SNMP agent enabled

3750Switch#

regards

Neo

[cisco]

Please help on this.

regards

Neo

[Joe Clarke]

Without seeing your SNMP configuration or how you're querying the device, I cannot say for certain what the problem is. However, if you're getting SNMPv3 report packets back from the switch indicating that the credentials are wrong, it could be that the engine ID has changed.

Try removing, and re-adding your SNMPv3 user. See if that fixes it. If not, you will need to open a TAC service request with your "show tech password" so more detailed analysis can be done.

[wbenton-0]

I reported a bug to Cisco quite a while back (approx. 4 years ago) in which the EngineID changed after down/upgrading the IOS.

(See: https://supportforums.cisco.com/thread/171788 )

Changing your Engine ID back to what it was should resolve your problem, however, that requires a reboot.

If you don't want to change your Engine ID, then you'll have to recreate all of your users which were previously created under the OLD EngineID again.

Likewise, there's another "CISCO" Non conformance problem I noticed in the above EngineID:

8000000903000017E0119C81

The top bit set shows that the EngineID confirms to SNMPv3 specifications.

The first 4 octets (less the top bit) are the enterprise.id which is "9" and correct for Cisco Systems.

The 5th octet specifies how the remaining octets are to be interpreted.

0 - reserved, unused

1 - IPv4 Address (4 octets)

2 - IPv6 Address (16 octets)

3 - MAC Address (6 octets) <<- This is what Cisco has specified.

There are others, but I'll omit the rest of the list.

Notice the number of octets after the 03... there are actual 7 octest and not 6 per RFC3411 specifications.

00 00 17 E0 11 9C 81

MAC address    000017
Company    TEKELEC

MAC address    0017E0
Company    Cisco Systems

In other words, there's one too many leading octets which makes the Engine ID non-conformant per RFC3411 specifications and also causes for mistaken identity of a Cisco Systems product as a TEKELEC product!

This should be fixed!

Cheers.