SNMP accees after 15.5.4.2-patch1.5 upgrade

[eyeV]

Hi everybody!

I've just upgraded XOS on my x480 switches to 15.5.4.2-patch1.5. After reboot I've noticed difference in config between old and new version.

Old XOS
configure snmpv3 add community XXXX name XXXX user v1v2c_rw
configure snmpv3 add community YYYY name YYYY user v1v2c_ro
configure snmpv3 add target-addr v1v2cNotifyTAddr1 param v1v2cNotifyParam1 ipaddress 172.30.0.6 transport-port 162 tag-list defaultNotify
configure snmpv3 add target-params v1v2cNotifyParam1 user v1v2cNotifyUser1 mp-model snmpv2c sec-model snmpv2c sec-level noauth
disable snmp access snmpv3
disable snmpv3 default-group
disable snmpv3 default-user
configure snmp access-profile mgmt-acl readwrite

New XOS
configure snmpv3 delete mib-view defaultUserView subtree 1.0
configure snmpv3 delete mib-view defaultAdminView subtree 1.0
configure snmpv3 delete mib-view defaultNotifyView subtree 1.0
configure snmpv3 delete community public
configure snmpv3 add community "XXXX" name "XXXX" user "v1v2c_rw"
configure snmpv3 add community "YYYY " name "YYYY " user "v1v2c_ro"
configure snmpv3 add target-addr "v1v2cNotifyTAddr1" param "v1v2cNotifyParam1" ipaddress 172.30.0.6 transport-port 162 tag-list "defaultNotify"
configure snmpv3 add target-params "v1v2cNotifyParam1" user "v1v2cNotifyUser1" mp-model snmpv2c sec-model snmpv2c sec-level noauth
disable snmp access snmpv3
disable snmpv3 default-group
disable snmpv3 default-user
configure snmp access-profile "mgmt-acl" readwriteAs a result I have a lot of error messages in log and I cannot access to certain OIDs throug SNMP.
Login failed through SNMPv1/v2c - bad community name (172.30.0.240)What's wrong? I don't get it.

[Harkanwaljeet_S]

I think we need to open this case again.

I have couple of x460-48t just upgraded to 15.5.4.2patch1-4. Both lost access on SNMP.

After I applied the remedy, the switches are reachable on SNMP but with delayed response which means switches are not able to process snmp polling from NMS.

snmpMaster and snmpSubagent continue to eat CPU. See below output. CPU is 38.7% and major portion is occupied by snmp processes only which was 0 or 1% on earlier revision.

Mem: 417428K used, 604064K free, 0K shrd, 110612K buff, 74888K cached
CPU: 38.7% usr 23.4% sys 0.0% nic 34.5% idle 0.0% io 3.1% irq 0.1% sirq
Load average: 11.23 9.90 9.26 11/213 1925
PID PPID USER STAT RSS %MEM CPU %CPU COMMAND
1462 1 root S 5508 0.5 0 15.8 ./snmpSubagent
1460 1 root S 4556 0.4 1 15.5 ./snmpMaster
1458 1 root S 3088 0.3 0 5.7 ./cfgmgr
1608 1 root S 2568 0.2 0 5.7 ./dot1ag
1452 1 root S < 14636 1.4 1 3.9 ./hal

Question: As this is a known issue now, are we going to fix in coming EXOS releases?

Delayed SNMP response and high CPU is a big concern for us.

Thanks
Harkanwal

[Karthik_Mohando]

This looks like a issue which has already been identified and under investigation.

Here is an article with the solution https://gtacknowledge.extremenetworks.com/articles/Solution/SNMP-communication-lost-after-EXOS-upgra...

[eyeV]

No problem!

[StephenW]

eyeV,

Thanks for providing your solution on the forum, it helps everyone. I have updated the article provided to you earlier to reflect your situation and your EXOS version upgrade.

https://gtacknowledge.extremenetworks.com/articles/Solution/SNMP-communication-lost-after-EXOS-upgra...

-Stephen