Page 1 of 3

SNMP oddness

Posted: Sat Nov 14, 2015 3:27 pm
by onlinenw
Hello first post here. This is a strange issue. I got my first Mini a few weeks ago as the product looks perfect for what we need at some locations. It has been working great on 1.3.6 since put into service. I monitor the network with PRTG. I upgraded the switch to 1.3.7 and all was well. after 22 hours PRTG reports that it is getting no SNMP response from the switch. I rebooted the switch, didn't help. I rolled back to 1.3.6, didn't help. Set it back to 1.3.7, turned off SNMP on the switch, turned it back on, added PRTG to the ACL (ACL was not active prior) , nothing helped. Night before last the PRTG server rebooted for updates. When it came back on PRTG was receiving SNMP data like it should have been. At all times during this doing a snmpwalk of the Netonix switch returned the expected data. This morning PRTG is reporting that it can not get a SNMP response from the switch again. I would think that this is a PRTG issue except that we monitor thousands of devices with this PRTG install and have never seen this before. The log in the Netonix does not show anything SNMP related. Any ideas?

Re: SNMP oddness

Posted: Sat Nov 14, 2015 5:17 pm
by Dave
onelinenw

Code: Select all
 after 22 hours PRTG reports that it is getting no SNMP response from the switch


What SNMP query were you doing to the Netonix switch?

Thanks.

Dave

Re: SNMP oddness

Posted: Sun Nov 15, 2015 1:20 pm
by onlinenw
I am polling system uptime and 64 bit port traffic.

Re: SNMP oddness

Posted: Sun Nov 15, 2015 7:58 pm
by onlinenw
And it has for no apparent reason starting responding again, no PRTG reboot this time. The Mini has not rebooted either, uptime is 3 days. There has been no change at all.

Re: SNMP oddness

Posted: Sun Nov 15, 2015 8:34 pm
by Dave
sigh, this sort of issue is a real pain in the %^&....we are setting up a PRTG server & will investigate...Dave

Re: SNMP oddness

Posted: Sun Nov 15, 2015 8:57 pm
by sirhc
onlinenw wrote:And it has for no apparent reason starting responding again, no PRTG reboot this time. The Mini has not rebooted either, uptime is 3 days. There has been no change at all.


Please closely examine the switch log and see if anything is a miss when it stops reporting and when it starts again.

Please try to help us investigate this with information such as it works for X hours then X hours later it starts again.

Re: SNMP oddness

Posted: Sun Nov 15, 2015 11:45 pm
by onlinenw
I added the switch to monitoring on 11-2, it was on 1.3.6 with SNMP working as expected, then 11 days 22 hours later I upgraded to 1.3.7. 22 hours after that it stopped responding. It was unresponsive for 13h59m36s, which was until normal updates restarted the PRTG server. During that time is when I tried rebooting the switch, downgrading FW, Upgrading the FW back, disabling and re-enabling SNMP, and adding our servers to the switch's ACL. After the PRTG reboot it worked normally for 32h46m12s then SNMP was unresponsive for 32h44m18s this time, and then came back by itself today. Is there a specific FW rev that you think I should try for troubleshooting? Here is the switch log, where is the Linux log, the GUI doesn't show it?

Nov 12 15:58:28 syslogd started: BusyBox v1.19.4
Nov 12 16:45:06 UI: Configuration changed by 206.x.x.x
Nov 12 16:45:06 UI: AccessControls: added 'noc'
Nov 12 16:45:06 UI: AccessControls: added 'prtg'
Nov 12 16:45:06 UI: Tarpit_Enable: changed from 'Enabled' to 'Disabled'
Nov 12 16:45:09 admin: adding lan (eth0.400) to firewall zone lan
Nov 12 16:45:10 dropbear[2486]: Running in background
Nov 12 16:50:47 UI: Configuration changed by 206.x.x.x
Nov 12 16:50:47 UI: AccessControls: added 'internal'
Nov 12 16:50:51 admin: adding lan (eth0.400) to firewall zone lan
Nov 14 10:42:11 dropbear[1886]: Child connection from ::ffff:206.x.x.x:35917
Nov 14 10:42:18 dropbear[1886]: password auth succeeded for 'admin' from ::ffff:206.x.x.x:35917
Nov 14 10:46:39 dropbear[1886]: exit after auth (admin): Exited normally
Nov 15 18:45:04 dropbear[2904]: Child connection from ::ffff:206.x.x.x:42517
Nov 15 18:45:12 dropbear[2904]: password auth succeeded for 'admin' from ::ffff:206.x.x.x:42517

Re: SNMP oddness

Posted: Sun Nov 15, 2015 11:53 pm
by Dave
Question: Were any of the switches configurations changed at all before the switch would not respond to the SNMP requests?

Re: SNMP oddness

Posted: Mon Nov 16, 2015 12:04 am
by onlinenw
Do you mean between reboots? I think so, but not for at least 12 hours (maybe 24) any of the times. I have also only rebooted it from the GUI. It is at a far away site without remote power control. It was not rebooted at all during this last episode.

Re: SNMP oddness

Posted: Mon Nov 16, 2015 12:14 am
by Dave
Can you please send me some snap shots of your status page & VLAN page if you are using VLAN's? You can just email me if you like.