Cheap Interesting Chinese 4x2.5g, 2x10G switch, (but also problems with DACs)

[EasyRhino]

I found this interesting network switch on Amazon, and wanted to share some pics and experiences. But also, I can't get the switch to work at home so if you have any tech support to offer please continue reading! (edit: figured it out, it didn't work when I used twinax DAC in the SFP combined with two out of several RJ45 devices I tried... was worked around by user a fiber optic cable instead of DAC)

Amazon has been listing this switch which is clearly made in the same factory. One brand is "Vimin" and the other is "YuanLey". Here are links:

Amazon.com: VIMIN 6 Port 2.5G Unmanaged Network Switch, 4X 2.5Gbase-T Ports, 2X 10G SFP, 60Gbps Ethernet Switching Capacity, One-Key VLAN, Metal Housing, Fanless, Work for 2.5Gbps NAS, Wireless AP & PC : Electronics

Amazon.com: 6 Port 2.5G Umanaged Ethernet Switch, 4 x 2.5G Base-T Ports, 2 x 10G SFP, Compatible with 100/1000/2500Mbps, Metal Fanless, Desktop/Wall Mount YuanLey 2.5Gbe Network Switch for Wireless AP, NAS, PC : Electronics

It's pretty cheap. The list price is $69 and there are currently coupons for 10% or 15% off. I bought the vimin brand, which the manual lists the manufacturer name as Shenzhen Weiming.

It's an unmanaged, non-POE, switch with, you guessed it, 4x2.5g ports and 2x10G SFP+ ports. It seemed like a perfect match for my basement and hodgepodge of networking needs. I haven't taken it apart but I speculate that it's like the other cheap 8x2.5g and 1x10g ports ( Sodola 8-port 2.5GbE and 1-port 10GbE Switch Review (servethehome.com) ) except sacrificing a block of 2.5g for the 10g....

here are my off the cuff observations:

• It's small
• all the ports and plugs, including power, are on one side
• the power supply is 12v and 1a and a very small USB dealie
• metal case, fanless.
• the lights flash REALLY BRIGHT from inside the case (here is a video
  )
• I didn't do a bandwidth stress test (see problems below), but I was able to get about 1.5gbps from the 2.5g ports and about 4gbps from the 10g ports. (I haven't done a full bandwidth test)
• power draw with 2x SFP+ DACs, and 2x RJ45, just plugged in not max speed use, was about 4.5W. When I changed for a different 12v power adapter it dropped to 4.1W.

So here's my tech support problem:

Once I plug in about 4 or 5 ethernet cables. all of the lights go off and the switch stops working. when I unplug the last cable, the lights flash, it does almost a "reboot" that lasts two seconds, and then starts working again. Different combinations can set it off, but it varies slightly things like:

• 2xRJ45 and 2xSFP+
• 4xRJ45 (but not all the time)
• 3xRJ45 and 1xSFP+
• (edit: was since narrowed down to at least one SFP connection, using a twinax DAC, and one of two different motherboards I was trying)

here are my failed steps to debug or fix the problem:

• got a whole replacement unit from Amazon. has same problems.
• tried changing RJ45 cables.
• tried plugging in different combinations of computers.
• replaced 12V adapter with a different one from my stash.
• thought it was because I had 1xRJ45 and 1x SFP+ coming out of the same computer, my server, so dropped to only one.
• thought it could be one RJ45 that was plugged into another 2.5g switch, which was POE, but it can crash without that one plugged in.
• sent an email to the address on the manual 20 hours ago, no response yet.
• Just now sent an email within the amazon contact seller page.

I hadn't seen a problem like this with a switch before, so i'm pretty stumped.

If people have a good idea for a tech support to try to make it work, or just want any more information that I can provide, lemme know! (edit: problem more or less narrowed down to using copper twinax DACs below)

 

[klui]

Seems pretty nice feature wise.

What is the amperage rating of your own power supply? Use one that is 2A or more and see if that helps.

You may want to get a fan and blow into the vents to see if it's an overheating issue. Maybe take it apart and see if there is any heatsink on the ASIC and if it's installed properly.

If the above don't work then it's probably due to a defect/limitation of the switch ASIC.

 

[oneplane]

Definitely seems like at least the switch ports are all getting reset, but not sure if that's a brownout, a short or a firmware issue. Does it happen when plugging in the cables in any specific order? Does it happen with all cables or only some types?

 

[Dave Corder]

Will these unmanaged switches (and presumably the PoE variants) pass through tagged VLAN traffic? e.g., from a 2.5Gbps AP on one of the 2.5 Gbps ports, with multiple SSIDs, each assigned a different VLAN, and pass through the Ethernet frames with VLAN headers intact out the 10Gbps to another switch (that does have proper VLAN support)?

 

[blunden]

@EasyRhino Those throughput results for the 2.5G and 10G ports look really low. I would've expected very close to line rate. How were the tests peformed?

 

[EasyRhino]

@EasyRhino Those throughput results for the 2.5G and 10G ports look really low. I would've expected very close to line rate. How were the tests peformed?

It was just internet speed tests and steam file transfer. Not even iperf yet. Because of the power off problem.

Regarding that, the other ac adapter I tried is 3a and didn't help. I also got an initial response through Amazon vendor messaging that basically said that's weird and asked if I could reproduce a specific combination of ports that will shut it down

 

[blunden]

It was just internet speed tests and steam file transfer. Not even iperf yet. Because of the power off problem.

Regarding that, the other ac adapter I tried is 3a and didn't help. I also got an initial response through Amazon vendor messaging that basically said that's weird and asked if I could reproduce a specific combination of ports that will shut it down

I don't see why the problem you describe would prevent you from doing iperf tests between two ports of each type. I was of the impression that it took 3 ports to trigger it?

It will obviously limit you from testing total throughput on all ports though, which would otherwise have been interesting too.

Based on the Amazon reviews, these seem to have issues with quality control. Multiple customers had the switches die within a few weeks or months.

 

[EasyRhino]

I don't see why the problem you describe would prevent you from doing iperf tests between two ports of each type. I was of the impression that it took 3 ports to trigger it?

Hey man, I've just been busy: kids + job + debugging the failures, gimme a break

One other thing I realized on the switch is there's a "VLAN ON/OFOF" switch on the front (edit: I later realized this VLAN button just isolates the RJ45 ports from the SFP ports). I don't normally use VLANs, is there an easy way to test if VLANs are passed?

Regarding the power off trouble shooting, here is what I have:

Success: I had four laptops plugged into the RJ45 ports (3x intel i219-lm and one Realtek). and also 2x SFP+ connections (DACs made by 10gtek and wktelcom), and all of them were activated without a switch crash.

Failure: I have two different desktops, where if I plug in their RJ45, and one of the SFP+ DACs, then it will crash and power off the switch. Again, all it takes it ONE RJ45 and ONE SFP+ to crash it:
The first device is a Windows desktop with a Killer E2600 ethernet gigabit.
second is a vmware esxi desktop with a Intel i219-v chip.

And in the failure case, as soon as I unplug either the offending RJ45 or the SFP+, then the power light comes back on and the activity/connection lights come back on in a few seconds.

Having the VLAN swith flipped on or off makes no difference in the power off problem, I also learned.

So that's my current status.

 

[blunden]

Hey man, I've just been busy: kids + job + debugging the failures, gimme a break

One other thing I realized on the switch is there's a "VLAN ON/OFOF" switch on the front. I don't normally use VLANs, is there an easy way to test if VLANs are passed?

Regarding the power off trouble shooting, here is what I have:

Success: I had four laptops plugged into the RJ45 ports (3x intel i219-lm and one Realtek). and also 2x SFP+ connections (DACs made by 10gtek and wktelcom), and all of them were activated without a switch crash.

Failure: I have two different desktops, where if I plug in their RJ45, and one of the SFP+ DACs, then it will crash and power off the switch. Again, all it takes it ONE RJ45 and ONE SFP+ to crash it:
The first device is a Windows desktop with a Killer E2600 ethernet gigabit.
second is a vmware esxi desktop with a Intel i219-v chip.

And in the failure case, as soon as I unplug either the offending RJ45 or the SFP+, then the power light comes back on and the activity/connection lights come back on in a few seconds.

Having the VLAN swith flipped on or off makes no difference, I also learned.

So that's my current status.

Yeah, being busy with other stuff is a totally valid reason. I simply didn't catch on to the fact that you meant that troubleshooting the power off issue took time away from testing, not that it was a reason why testing somehow wasn't possible. Now that part makes much more sense to me. Sorry if my last post came off unfriendly, it was not my intent.

There's a physical VLAN toggle switch on it? Weird. Seems a bit unusual on an unmanaged switch.

Does the power off issue occur consistently with those two desktops regardless of what else is plugged in, or can you reproduce it without them?

 

[oneplane]

Unmanaged switches don't really exist, they are just switches where they removed the interface to the management plane and load a default pass-everything configuration on startup. It used to be that having vs. not having that stuff on the chips made a significant difference for the manufacturer, but these days it's cheaper to just have 1 SKU and simply have them default to pass-everything unless hooked up to a management system.

Sometimes they make a special ASIC where the physical interface to the management plane is removed as well, but that's mostly just extra effort with little benefit. In the past, people have made 'dumb' switches managed by connecting to the switch chip via I2C, SPI, MDIO, or even serial and writing things like VLAN configuration into the correct registers. Normally the management interface would do that for you and provide a neat and tidy way of doing that, but without that the registers to do it are still there. Example of such a hack: Sprites mods - Dumb to managed switch conversion - Intro

 

[blunden]

Unmanaged switches don't really exist, they are just switches where they removed the interface to the management plane and load a default pass-everything configuration on startup. It used to be that having vs. not having that stuff on the chips made a significant difference for the manufacturer, but these days it's cheaper to just have 1 SKU and simply have them default to pass-everything unless hooked up to a management system.

Sometimes they make a special ASIC where the physical interface to the management plane is removed as well, but that's mostly just extra effort with little benefit. In the past, people have made 'dumb' switches managed by connecting to the switch chip via I2C, SPI, MDIO, or even serial and writing things like VLAN configuration into the correct registers. Normally the management interface would do that for you and provide a neat and tidy way of doing that, but without that the registers to do it are still there. Example of such a hack: Sprites mods - Dumb to managed switch conversion - Intro

Interesting, but that makes sense I guess. The CPU power needed to run the web interface has probably gotten cheap enough to include in the switch chip package that having a single SKU makes more sense financially.

I guess it's simply a way for switch manufacturers to get higher margins at this point. Although, it saves them from having to spend resources on firmware updates, unless those are all developed by the switch IC manufacturers.

 

[ptyork]

So that's my current status.

I saw and bought one of these and THEN saw this post. Sigh. Looking to replace a potentially flaky QNAP QSW-2104-2S (same port config) with this flaky thing.

Wonder if you have any update from the manufacturer or any updates on stability or performance.

Thanks!!!

 

[EasyRhino]

I saw and bought one of these and THEN saw this post. Sigh. Looking to replace a potentially flaky QNAP QSW-2104-2S (same port config) with this flaky thing.

Wonder if you have any update from the manufacturer or any updates on stability or performance.

Oh wow that QNAP is probably the same hardware under the hood!

What kind of problems have you had, and has QNAP support turned up anything?

For mine, I was out of town for a week. The Vimin seller (though amazon messaging). asked if "the electrical devices were grounded". I'm not sure exactly what this means, since the switch itself is ungrounded and uses the barrel power supply. One thing I did do was move an offending RJ45 desktop to a different power outlet (one where a known-working desktop was plugged in) and tried it, and it would still shut down if I had a SFP+ and one of these two RJ45's plugged in at the same time. i'm not sure if there anything else with 'grounding' that I can investigate.

 

[EasyRhino]

So the Vimin inquiry is waiting for "research from the engineering department". I'm honestly hanging on to it out of curiosity more than anything. @ptyork i wonder if your QNAP experiences were the same problem, or different? And of course will be interested to see if your new Vimin unit has the same problems the QNAP did.

 

[oneplane]

This brownout/reset behaviour is pretty strange, especially since it goes away when unplugging. I have had similar issues in the past with some Intel NUCS and HPE switches (the single PSU cheap web managed office ones), I think it's because the switch has an earthed shield on the ethernet side but the NUC isn't earthed via the power supply. You could actually get a slight tingle when you touched the ethernet cable (if using a shielded one) and the NUC on exposed metal like TB2 or USB ports. This was in the NUC 7th or 6th gen era so a while ago.

How this ties in to the resets: it caused the USB bus on the NUC to reset whenever someone unplugged/plugged in any of the NUCs on the network. Added an earth wire to the NUCs themselves, problem solved. We did end up replacing all of them because the generations before and after didn't have the problem, same with the switch.

 

[ptyork]

Oh wow that QNAP is probably the same hardware under the hood!

What kind of problems have you had, and has QNAP support turned up anything?

For me, I was having it lose connectivity with one system (NUC 12th Gen Extreme) via a single Ethernet port. It would work for a minute or two and then just flake out. I had to completely disable the port in the OS and then re-enable it. And then repeat. At first I assumed it was the 6COM 10GBase-T transceiver (which I did return). But it happened with a 2.5G connection. I ran a LONG Cat6e cable direct to a 10G transceiver in my rack and had a solid connection.

I thought maybe that the 6COM transceiver got so hot it baked my QNAP (certainly baked my fingers when I pulled it out). Purchased the Vimin as an inexpensive way to see if it was the switch or perhaps an issue with the connection from switch to rack. And it has been rock solid so far. I do not stress it at all, so I'm not the right person to say if it's good or just functional. And I've not yet bought a replacement 10GBase-T transceiver to test the 10G-NUC connection. But so far so good.

Only one Ethernet port on mine and no free PCI slots, so I can't test your scenario.

What kind of cable are you using for your SFP+ connections? RJ-45? Passive DAC? If your 10G connection on the server is SFP+, I think the next logical "debugging" step would be to use a couple of cheap optical transceivers and a short LC-LC patch cable. That would eliminate the electrical path for the second connection entirely.

Though obviously it's costing money and kinda eliminating the cost benefit of this thing.

 

[EasyRhino]

thanks guys, the discussion of 'grounding' and the fiber cable idea let me to a troubleshooting breakthrough. It's the DACs that are messing it up.

The "power off" problem is caused by a combination of the two offending RJ45 machines AND using copper twinax DAC cables. I replaced one cable with a fiber optic cable and transceiver (which I had to purchase), and the power off problem went away. The switch seems to function normally afterwards.

Steps to reproduce the crash:
1) I have two different DACs. one is a wktelcom SFP-H10G-CU1M. the other is a 10Gtek CAB-10GSFP-P2M.

2) I have two different motherboard who's onboard ethernet causes problems
A) a Asus Prime Z270-a with Intel i219-V *this motherboard is missing it's IO shield in the back of the case*.
B) a Dell XPS 8940 desktop with Killer EA2600 ethernet. There is nothing wrong with the Dell that I can see

3) Attach ONE of those motherboards via RJ45, and ONE DAC cable, and the switch will power off.

but when I use fiber, I can use one 10g connection (I only bought one fiber cable) and all four RJ45 connections (three of them 2.5g) and it seems to work.

Unrelated, on that "VLAN" switch on the front. I accidentally had it flipped on and it was breaking my network. Had to turn it off. Here is the info from the sales page:

Easy One-Key VLAN Setup: Utilize the One Key VLAN mode to isolate ports 1-4 while maintaining communication with the SFP ports. This functionality enhances network security, monitors network interruptions, minimizes disruptions, and optimizes port bandwidth utilization.

 

[oneplane]

Looks like their grounding suggestion is based on their own lack of internal power filtering and decoupling in that case But at least, now we know. Ports on a device should neither cause, nor malfunction due to external systems, not just EMI but also just plugged in stuff like cables including DAC and fiber SFP.

 

[EasyRhino]

Okay I got a response pretty quickly from them via Amazon message, TL;DR it doesn't play nice with DACs.

Here it is in its entirety just so I don't mistranslate something:

Thank you so much for your email. We truly appreciate your patience and cooperation in providing valuable troubleshooting information.

After careful examination and consultations with our engineering team, we have identified the root cause of the problem. The issue appears to be related to the integration of the network switch with the POE switch on the mainboard. Unlike the POE switch, the ethernet switch lacks a microcontroller to manage power distribution. As a result, when power is supplied directly to the 2.5G Ethernet ports, it can lead to electrically charged interfaces and, in turn, cause the switch to power off. Additionally, I want to assure you that we take this issue very seriously, and we are implementing measures to prevent similar occurrences in the future. Moving forward, we will be using different mainboards for our network switches and POE switches, ensuring that they are equipped with the necessary microcontrollers and power management systems to avoid such problems.

In light of this, we have come up with a few potential solutions for you:
Upgrading to a 2.5G POE Switch: One feasible solution would be to replace the current switch with a 2.5G POE switch that comes equipped with a microcontroller for proper power management. We are pleased to tell you that a new product, the 2.5G POE switch with similar specifications, is about to be launched in our store. Once it is available, we would like to extend a 50% discount to you for the purchase of this new switch, allowing you to upgrade to a more suitable and reliable solution at a more affordable price.
Continuing with Your Current Solution: As you have discovered, using fiber optic cables and transceivers for the SFP+ connections bypasses the power-off problem. While we understand this may not be the most cost-effective solution due to the additional expenses for the receiver.
Regarding your current setup with the fiber optic cable, we would like to offer a partial compensation to help offset some of the costs incurred for purchasing the transceivers. Kindly provide us with the amount spent on the transceivers, and we will arrange the compensation accordingly.
We genuinely value your satisfaction and are open to any other suggestions or solutions you may have in mind. Our aim is to ensure you have a smooth and efficient networking experience. Please let me know what you think and the solution you prefer.
Once again, we apologize for any inconvenience caused, and we are committed to resolving this matter to your satisfaction. Please feel free to reach out to us with any further questions or concerns.
Thank you for your understanding, and we look forward to hearing back from you soon.
Best regards,
VIMIN

 

[oneplane]

While it does seem a bit rough (I assume parts are translated on their end), it does pretty much confirm everything. It does make sense that the POE version would need transient suppression, power management ICs and decoupling, but the non-POE versions kind-of need that too...