Netonix Forums

Good day... I have an odd issue and I am not sure it is a defective unit or if something funny is going on.

We use this as a POE switch at a remote solar site. Everything seems to work fine but after a few days the switch stops passing any trafic at all but all the radios are still powered on. I can get to all the radios and tell they have Ethernet connectivity but the switch will not respond to the management Vlan nor will it pass any Vlan traffic. The only way to get it to come back is to physically remove power from the unit then restore the power.

This has happened several times. I can not have this as it is a remote location.

Does anyone else have this problem with the switch going brain dead? Is there a watchdog function for the switch itself to reboot if it loses connection?

This unit has a MT sfp to copper transceiver in port 14.

here is the status and Vlan page right after I had to power cycle the unit. I have one other switch so i am going to try that one out to see if it is just a bad switch.





I make the management available from every connection. This way if a link is down I can access the POE from another link. It would not respond on any port.

Do you have a port setup that you can connect to it via laptop BEFORE you power cycle it?

The most important information to see whats going on is the log but this would require you to connect to the switch on site BEFORE rebooting it and try to get to the web UI but if that fails use a console cable and connect to the console port.

The log would be what would help the most here before you reboot.

I have not heard of this occurring to any other user.

Since you are not using all the ports I would setup port 1 or 2 to have direct un-tagged access to the switch UI and when I arrive at the site I would first plug into port 1 or 2 and attempt to access the UI with an IP in the same sub-net as the switch and try to get the LOG.

If that fails there is always the console.

The log will hopefully have the answers we need.

It possible the SFP might be causing an issue if its bad.....totally grasping at straws here.

I supposed you could try a different SFP preferably a different model just to eliminate both the bad sfp and one that might cause incompatibility issues.

Uintadave wrote:This unit has a MT sfp to copper transceiver in port 14...

Since it is copper, why not test without it just to rule it out?

Looking at it the times it did freeze was when the batteries started charging hard. right when the voltage changed quite a bit.

It might also bee the SFP... We have had problems with the MT ones before and pulled them from other locations. I will have that one pulled. and test with a different unit.

It is really odd because all the other switches I have not one has done this. I could always access them.

The only ports the UI would respond to with untagged traffic is ports 12,13,14 and of course there is nothing in port 13 so 12,14

If you try to access the other active port 5-11 you traffic destined to the UI would need to be tagged or the packets would be dropped.

Its hard to envision your network topography as your port descriptions lack hints as to what they are such as Back-haul, AP, Router, and so on.

Would be nice to understand what the topography at this site is.

And as I said the most valuable thing here would be the log.

I tried every port even the untagged ones..

I did not try the console port.

Is there a way to have the log write to something that doesn't get wiped after reboot? some way to get it to write to storage for x amount of mb?

Yea, like Les said and you suggested you had issues with that model before, pull the SFP for grins and giggles, it is a long shot but who knows?