Weird behavior with XikeStor 10Gb SFP+ switches

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

dtremit

New Member
Aug 20, 2018
16
10
3
I'm about to take another chance on these switches given @Snoddas1099 's experience with a beefier power supply. (Though I actually ordered from ONTi this time, they look to be identical outside of branding). Just waiting for some surplus Delta PSUs to arrive.

I tried to post this to the recent STH review thread, but I'm not sure my comment got through. Nevertheless, someone in Japan has done a detailed review of these switches using a network analyzer:


It's in Japanese, but machine translate seems to work just fine.

Helpfully he seems to have mirrored the XikeStor docs/firmware downloads here — I say helpfully because the site I mentioned at the top of the thread seems to be offline at the moment.
 
  • Like
Reactions: blunden

preese-sth

New Member
Oct 24, 2024
1
1
3
I'm late the the XikeStor Switch. But I now have one and can empathize with almost all the posts here. While many must have discovered this for themselves, I have stumbled upon one helpful item.

There have been several posts about failure to login via the Web interface with the default or new username and pword. I think I've found the magic solution for this one. On the login screen enter the appropriate username and password and then click the 'Remember account password' box whether you want it to remember them or not (it doesn't seem to anyway). For me this was all that was needed to allow successful login from the web form!

The 8port switch is a little sketchy but mostly works. My case has it working with three spread out RJ45 sfp's and one DAC cable. The load is at 18w and a top temp of 103F.

I'm sure all have discovered and used the hardware reset switch on the front, to the left of the console jack. Hardest part was finding a legacy paper clip to use!
 
  • Like
Reactions: Exhaust8890

dtremit

New Member
Aug 20, 2018
16
10
3
Sadly the newest batch of switches isn't proving any better than the last — in fact they seem worse. One of them powers off immediately whenever I attach any DAC cable, even if said DAC is unconnected at the other end. It's fine with an SFP. Other switch hasn't powered down at all, even when I use the same cables. Have tried swapping power supplies between the two units, with no change in behavior.
 

TimSmall

New Member
Jan 13, 2025
1
2
3
If you're not liking the manufacturer firmware, there is a pull request open to add preliminary support for the SKS8300-8X to OpenWrt now.

"realtek: add support for XikeStor SKS8300-8X" in OpenWrt pull request #17593

i.e. This entirely replaces the manufacturer firmware with the OpenWrt open source router distro (including web UI).

Not all features are supported yet (e.g. link aggregation), but OpenWrt is improving steadily on Realtek chipset switches (various gigabit, and multi-gigabit models are supported including some models from HP, Zyxel, D-Link, TP-Link, Trendnet, Cisco and others). Running OpenWrt instead has various benefits including an up-to-date Linux kernel version (and ssh server) which will consistently receive security updates in the future (in the case of one of my routers for 10 years after the manufacturer dropped support).
 
Last edited:
  • Like
Reactions: blunden and Markess

boanerges57

New Member
Jan 18, 2025
1
0
1
ive got one of these that i use as the backbone of my network. Its doing fine with DACs. They are all cheap sfptek ones from amazon
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
I just bought the XikeStor SKS1200-4GPY2XF-P (unmanaged version with POE) and what was supposed to be a value proposition is now a troubleshooting nightmare. I have one 10Base-T module connecting both switches over 30M. One SFP+ MC fiber going to my Connect-x3 on my NAS on switch1 the other SFP+ on switch2 running the same fiber cable type to my Connect-x3 on my workstation. Everything seems good until I started playing games and noticed random packet loss. Further examination it seems a full-loss of connection over a few seconds randomly. Ping from the workstation to the NAS shows intermittent timeout. Ping from the Workstation to router never shows timeout. Can't seem to ping from my NAS to workstation, but works with all other IP on network.

I'm not sure where to begin troubleshooting this mess.
 
Last edited:

ziggygt

Member
Jul 23, 2019
77
16
8
Look at the web interface and see if changing for optical auto to a setting reflective of your cable length and type. As I said before I had trouble until I set the SFP+ config off the auto setting. I have not seen your issue so I cannot say this will fix it.
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
Look at the web interface and see if changing for optical auto to a setting reflective of your cable length and type. As I said before I had trouble until I set the SFP+ config off the auto setting. I have not seen your issue so I cannot say this will fix it.
Can't unfortunately, it's unmanaged and it doesn't get an DHCP leases off the router.
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
I just bought the XikeStor SKS1200-4GPY2XF-P (unmanaged version with POE) and what was supposed to be a value proposition is now a troubleshooting nightmare. I have one 10Base-T module connecting both switches over 30M. One SFP+ MC fiber going to my Connect-x3 on my NAS on switch1 the other SFP+ on switch2 running the same fiber cable type to my Connect-x3 on my workstation. Everything seems good until I started playing games and noticed random packet loss. Further examination it seems a full-loss of connection over a few seconds randomly. Ping from the workstation to the NAS shows intermittent timeout. Ping from the Workstation to router never shows timeout. Can't seem to ping from my NAS to workstation, but works with all other IP on network.

I'm not sure where to begin troubleshooting this mess.
So that was an easy troubleshoot after all.

1. For some reason windows 11 firewall disables ICMP echo requests. Easy rule change Windows Defender Firewall with Advanced Security -> Inbound Rules -> Core Networking Diagnostics - ICMP Echo Request (ICMPv4-In) - enable Core Networking Diagnostics - ICMP Echo Request (ICMPv6-In) - enable.
2. Ping now works from NAS to Workstation but still 57% packet loss.
3. Had a spare 10base-t DAC cable and swapped out the fiber SFP+ and everything is fine now.

So either the SFP+ fiber modules are bad or the fiber cable is bad.

Just a matter of return and recheck. The SFP+ modules do run super hot though... good grief.

I wonder if the heat is causing signal degradation with the fiber modules. Has anyone done a fan mod on these things?
 
Last edited:

blunden

Well-Known Member
Nov 29, 2019
906
298
63
3. Had a spare 10base-t DAC cable and swapped out the fiber SFP+ and everything is fine now.

So either the SFP+ fiber modules are bad or the fiber cable is bad.

Just a matter of return and recheck. The SFP+ modules do run super hot though... good grief.
"10GBASE-T DAC" is not a thing as 10GBASE-T means RJ45 (CAT6/6a, etc.), what people commonly call "ethernet cables". It also implies active signal conversion, while Passive DACs are just the same internal serial communication that the switch would normally use internally extended across a longer wire, as far as I know. :)

SFP+ 10GBASE-T (RJ45) transceivers do get very hot as especially the ones rated for 30 meters tend to be out of spec in terms of power consumption. The more modern ones rated for 80 or 100 meters tends to be much better in that regard, but they are hardly cool either. :)

Fiber transceivers can also get quite warm, usually significantly less so. Any chance the ends of your fiber cable got dirty? :)
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
"10GBASE-T DAC" is not a thing as 10GBASE-T means RJ45 (CAT6/6a, etc.), what people commonly call "ethernet cables". It also implies active signal conversion, while Passive DACs are just the same internal serial communication that the switch would normally use internally extended across a longer wire, as far as I know. :)

SFP+ 10GBASE-T (RJ45) transceivers do get very hot as especially the ones rated for 30 meters tend to be out of spec in terms of power consumption. The more modern ones rated for 80 or 100 meters tends to be much better in that regard, but they are hardly cool either. :)

Fiber transceivers can also get quite warm, usually significantly less so. Any chance the ends of your fiber cable got dirty? :)
I made sure to not expose the fiber transceivers before connecting the fiber cables. I don't think the cable is damaged either. The 10gbe dac started exhibiting the same symptoms an hour after I made the reply. I've been using this prior to the setup as a direct connection between the nas and the workstation without any issues. I am wondering if the SFP+ 10GBASE-T transceiver heat is causing this issue since I disconnected it to cool down and things were back to normal until about 45 minutes after where packet loss started to appear again.
 

blunden

Well-Known Member
Nov 29, 2019
906
298
63
I made sure to not expose the fiber transceivers before connecting the fiber cables. I don't think the cable is damaged either. The 10gbe dac started exhibiting the same symptoms an hour after I made the reply. I've been using this prior to the setup as a direct connection between the nas and the workstation without any issues. I am wondering if the SFP+ 10GBASE-T transceiver heat is causing this issue since I disconnected it to cool down and things were back to normal until about 45 minutes after where packet loss started to appear again.
Ok, just making sure. :) It's certainly possible that the transceivers are either damaged or overheating.

With DACs, it's necessary for the switch to apply the proper signal calibration for them to work properly (as you're essentially extending an internal serial bus), especially at more than very short runs. Some switches do this automatically, while some of the cheap Realtek switches don't. I had major problems with a 10 Gbps DAC on my Hasivo switch until I convinced them to release a firmware update that allowed me to select different calibrations (defined in the Realtek SDK). That made it go from unstable enough for it to even link up most of the time, to rock solid 24/7. :) The fact that your DAC worked well for a while suggests that your issue might be different from the one I faced though.
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
Ok, just making sure. :) It's certainly possible that the transceivers are either damaged or overheating.

With DACs, it's necessary for the switch to apply the proper signal calibration for them to work properly (as you're essentially extending an internal serial bus), especially at more than very short runs. Some switches do this automatically, while some of the cheap Realtek switches don't. I had major problems with a 10 Gbps DAC on my Hasivo switch until I convinced them to release a firmware update that allowed me to select different calibrations (defined in the Realtek SDK). That made it go from unstable enough for it to even link up most of the time, to rock solid 24/7. :) The fact that your DAC worked well for a while suggests that your issue might be different from the one I faced though.
That's good to know. I will email their customer support to see what they have to say.
 

Markess

Well-Known Member
May 19, 2018
1,207
829
113
Northern California
@foureight84 , what’s the rating on the power supply that came with your switch? Do you have a way to measure power draw at the plug (kill-a-watt, etc.)

I’ve got the managed, non-POE, version. Which is probably different hardware than yours. But if they skimped on my power supply, they may have skimped on yours?

Mine came with a rather weak 12v/2A/24w power supply. Here’s what I saw as I added clients to the switch:

- Nothing connected: 8W
- Adding in 2xDAC & 1xSFP+ withMM: 12.5w
- Adding in one 10gBASE-T to SFP+ adapter:18.5w (an extra 6w!)

Those were with no traffic to speak of. Once there was moderate traffic, the power draw was up to 23w. But, my power supply was rated for only 24w, and I still had four unused ports.

Doing a little research (sorry, I saved no links and it was a while ago) it appears that my particular unit can handle more power draw, than the supply could provide, so I puta 60w power supply on it and I haven’t had issues once I filled the other ports with a mixture of DACs and short MM fiber runs. Idle is now ~23w and 30-32w at load.

As others have mentioned, these switches are hot in general, and the 10GBASE-T adapters are particularly hot and power hungry on their own. I’ve been thinking of putting a heat sink on the lid of mine, or even a small fan. There’s an air gap between the components and the lid, so it will be inefficient, but I’m thinking it can’t hurt.
 
Last edited:

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
@foureight84 , what’s the rating on the power supply that came with your switch? Do you have a way to measure power draw at the plug (kill-a-watt, etc.)

I’ve got the managed, non-POE, version. Which is probably different hardware than yours. But if they skimped on my power supply, they may have skimped on yours?

Mine came with a rather weak 12v/2A/24w power supply. Here’s what I saw as I added clients to the switch:

- Nothing connected: 8W
- Adding in 2xDAC & 1xSFP+ withMM: 12.5w
- Adding in one 10gBASE-T to SFP+ adapter:18.5w (an extra 6w!)

Those were with no traffic to speak of. Once there was moderate traffic, the power draw was up to 23w. But, my power supply was rated for only 24w, and I still had four unused ports.

Doing a little research (sorry, I saved no links and it was a while ago) it appears that my particular unit can handle more power draw, than the supply could provide, so I puta 60w power supply on it and I haven’t had issues once I filled the other ports with a mixture of DACs and short MM fiber runs. Idle is now ~23w and 30-32w at load.

As others have mentioned, these switches are hot in general, and the 10GBASE-T adapters are particularly hot and power hungry on their own. I’ve been thinking of putting a heat sink on the lid of mine, or even a small fan. There’s an air gap between the components and the lid, so it will be inefficient, but I’m thinking it can’t hurt.
The provided power supply is a Hi-Power-75W-V7.0. The PCB is identical to to the Nicgiga S25-0402P with an incremented revision version. The power supply is the same as well. I will test it as you mentioned to see how much power is being used. Thank you!
 

foureight84

Well-Known Member
Jun 26, 2018
316
279
63
I ended up re-terminating the cable. It was not done properly the first time but I don't think crosstalk was the issue. But I did discover that the cable I have has 23awg so I swapped to using a cat7 connectors. I bought those tools free kits and it was so much easier to work with since the strands are slightly larger. But unfortunately that didn't fix the packet loss / intermittent disconnect issues.

The last thing to do was to try a different switch and I ended up with the Mokerlink POE-2G040210GSM. So far, the connection has been solid and I now have a web ui to look at what's going on. The Mokerlink shows 5.5W consumption with 1 POE AP attached.

I did notice that once in a while, ping response time would take slightly longer than normal.

10 minutes into continuous ping:
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=4ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=15ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time=15ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
Reply from 192.168.1.5: bytes=32 time<1ms TTL=64
 

luckylinux

Active Member
Mar 18, 2012
587
150
43
If you're not liking the manufacturer firmware, there is a pull request open to add preliminary support for the SKS8300-8X to OpenWrt now.

"realtek: add support for XikeStor SKS8300-8X" in OpenWrt pull request #17593

i.e. This entirely replaces the manufacturer firmware with the OpenWrt open source router distro (including web UI).

Not all features are supported yet (e.g. link aggregation), but OpenWrt is improving steadily on Realtek chipset switches (various gigabit, and multi-gigabit models are supported including some models from HP, Zyxel, D-Link, TP-Link, Trendnet, Cisco and others). Running OpenWrt instead has various benefits including an up-to-date Linux kernel version (and ssh server) which will consistently receive security updates in the future (in the case of one of my routers for 10 years after the manufacturer dropped support).
I just went through the Installation on my ONTI ONT-S508CL-8S (pretty much the same as Xikestor SKS8300-8X).

I wrote a small Tutorial Here (Part1) and Here (Part 2) because I couldn't find anything on how to Install it (just bits & pieces when scrolling the Thread Up and Down). Turns out there was a small Installation Instruction buried somewhere in one of the many Commits (I added a link to it as well).
 
  • Like
Reactions: blunden