Data dropping under load, no DHCP

[opalit]

I am having serious problems with a new WS-12-250A, it is dropping data, power is OK, the ubiquiti units are not re-booting.

When at the unit with Laptop plugged in and with a MikroTik 750G plugged in to a POE port, data flow would just stop, I could turn off the POE and plug power in to 750 and it would be fine, similar thing is happening with other ports powering Ubiquiti Airmax radios, the DATA flow just stops, a Ubiquiti unit that is being blocked, does not do it when powered from its POE adapter and data cable plugged in to same port.

Also DHCP client is not working, it will start working then reverts back to static.

I have a lot of angry customers, not a cheap unit.

[sirhc]

Hi,

Need more information to even start to help you.

It is NOT a hardware design flaw as thousands of people are using these switches with no issues so it has to be one of 3 issues listed below:

1) A Defective unit

2) Configuration issue

3) You are running an older firmware and experiencing a bug that was fixed.

To better help you please do the following:

Tell us the firmware version you are running on the switch becuase DHCP client was an issue that was fixed many firmware versions ago.

Post screen grabs of your tabs.

Describe the issue in a little more detail and what testing you have done.

DID YOU CHECK THE SYSTEM LOG, POSSIBLY YOU ARE HAVING FALSE LOOP PROTECTION WHICH WAS RECENTLY FIXED BUT TRY TURNING LOOP PROTECTION OFF UNDER THE DEVICE/CONFIG TAB AND SEE WHAT HAPPENS.

[opalit]

The system log only showed attempts to connect to an NTP server, which it could not do as it only had default IP, DHCP client not working.

It now has static IP in the local range.

Also TX Data and RX Data appear to be the wrong way round, I assume TX data is leaving the port and RX data is entering the port, in which case they are the wrong way round.

Firmware is 1.2.3

Tabs uploaded.

The LAGG and STP tabs are unchanged default so not uploaded them.

I am getting random dropout on ports on port 1,3,5 and 6 which then causes PPPoE connected users to lose connection

I have replaced the switch with a unmanaged switch and no longer have dropout.

[sirhc]

First things first.

We know there is an issue with Loop Protection on v1.2.3 which can cause ports be detect a false loop detection which cause ports to be disabled for 90 seconds.

Please upgrade to v1.2.4.

However "some" people (not many) still have issue with loop detection, we are not sure if it is us or them at this time but if you have an issue DISABLE Loop Protection.

My GUESS is you were getting "FALSE" Loop Protections which would temporarily disable the port drop your PPOE and hen it would come back up and some period of time later another FALSE Loop Protection

FIXES
- Fixed FALSE Loop Detection with Loop Protection across VLANs

KNOWN ISSUES
- Ubiquiti Discovery Protocol is still a little flaky

[opalit]

That might be it, it is about 90 secs, I will upgrade at 4:00 in the morning

Where do I disable loop detection

[sirhc]

That might be it, it is about 90 secs, I will upgrade at 4:00 in the morning

Where do I disable loop detection

You do realize when you upgrade our firmware we leave the poe ports turned on and you only lose 6 pings unless you are doing OSPF or something then about 26 pings.

But I digress, Device/Configuration Tab bottom left side of screen

Our switches Boot and start passing traffic from a cold start in 17 seconds and during a soft reboot only stop traffic for 6 pings +/-

We worked hard on this!!

We could shave a couple seconds off that but we felt we already beat just about all other switches so anything faster is just piling it on - LOL

[sirhc]

9.jpg (195.94 KiB) Viewed 7369 times

[opalit]

Got up at 4:00AM did upgrade, then spotted your post, AH well twas a nice morning, no I did not realise that, only had it a few days needed a POE switch in a hurry, I only checked CPU, throughput and current capability, I have a Toughswitch not good enough for the throughput required.

I had spotted the tick box.

DHCP client still not working, it works with a Microsoft 2010 servers DHCP but not With a MikoTik Routerboard DHCP server with a 1k Ubiquiti bridged pair in between.

Also how do you change the Web port, I do not like using 443 or 80, when I un-ticked use https I could not get back in, I had to ssh in and factory reset.

[sirhc]

I really appreciate any purchase of our WISP switches but I strongly suggest when trying out our switch for the first time set it up and play with it in your LAB or office first to familiarize yourself with the product before putting it into production.

1) Our switch has a Tar Pit security feature on the UI and CLI which means it would take for ever for anyone to crack into it and it logs attempts in the log for you to see who is doing it.

2) Our switches have an access list which you can limit who can even access the UI / CLI interface

3) Of course un-checking the "Eanable" HTTPS check box will disable HTTPS?

There is a command in the CLI to enable the HTTPS (I think, I requested Eric put one in a while ago) so thee should be no reason to factory default it to re-enable HTTPS?

If the switch works with a Windows DHCP server and I am pretty sure Eric tested it against Linux DHCP servers maybe the problem is with the MT router? I can ask Eric to check into this but maybe you could do a little testing and verify it on your end that there is not something else amiss?

I do not recommend playing with a production switch, do you have a backup spare switch to play with?

You can change the HTTPS port but we do not support HTTP at this time.

port.jpg (171.71 KiB) Viewed 7349 times

[opalit]

I have tried 3 MikroTik routers, it is the same with them all, as for playing with it, I could only spend a few minutes with it, before it had to go in place, no choice, my intention was to give it a week or so but circumstances dictated otherwise.

It is running with a static at the moment and it seems to have settled down.

So if it falls over I am in big trouble, I have nothing else in stock at the moment powerful enough to handle the throughput.