Main SkyQ causes network loop on switch and disconnects from network. STP loop dection.

[BobbyLovesSky]

Does anyone know if SkyQ is compatible with a large network of managed switches?

The switch with the main SkyQ box works for a few days then it get cut off the network due to STP loop detection.

Example network here is

Several managed switches on the network configured with (R)STP values from 0 at the main core switch connected to the firewall down to 4096, 8192, 12288 for the various connected switches.

All skyQ boxes are conencted via wired and wifi is disabled in the secret menu.

Seems the skyQ system  does somthing funky on the network

[MightyQuinn]

Hi @BobbyLovesSky   That's an easy one to answer. Sky Q does not like managed switches.

[BobbyLovesSky]

Wow OK, so what is the solution? SkyQ just not possible in this situation?

[Chodley]

What do those STP numbers define?

Interesting that they seem to think the Q is acting as a loop cause (which would impky they think it restransmits broadcast packets it should not . It does broadcast a lot of noise. Is it on the latest firmware?

[BobbyLovesSky]

Yep, on latest firmware.

Here is a little drawing showing the RSTP priority settings:

As a bad workaround, I've temprorily disabled STP loop detction on both

1. the SkyQ master port on SWITCH05

2. the port on SWTICH04 links to SWITCH05.

This is needed as the port attached to the SkyQ master on SWITCH05 kept getting disabled due to loop detected.

This is not ideal as after few hours the whole network across all switches from SWITCH01 to SWITCH05  grinds to a halt for 10-15 mins.

What is causing SkyQ to trigger STP loop detection on the skyQ master port? I can't even ping the SkyQ boxes as they have some software firewall running. Have they set up some internal mesh between themselves destroying the network?

[Chodley]

Yeah that network slowdown would cerrainly be a symptom of a broadcast storm

Have you got multiple physical ports between switches for redundancy?

[BobbyLovesSky]

@Chodley I have no redundancy links connected. Just a single CAT6 cable linking each switch as per the diagram.

@bob1234 The master and mini's do not have wifi enabled (checked via the "highlight Settings. Press 001" method).

Have to say this has me utterly baffled

[Chodley]

@BobbyLovesSky Ah. No point having STP then? No loops possible in your topology.

Unless whatever the Q is broadcasting gets rebroadcast back out on the same port it comes in. Hmm.

Does this thread help?

https://helpforum.sky.com/t5/Sky-Q/SkyQ-main-box-loses-Ethernet-on-managed-switch/td-p/3691258

[BobbyLovesSky]

I ran a network packet capture and can see the sky q master box is sending approx 100,000 broadcast pactets to every device on  every switch across the entire network every minute:

Is there a Sky Q support software developer contact I can report this bug to so they can fix this bug? Or perhaps I have a faulty sky q unit?

[BobbyLovesSky]

just to add - this is with STP disabled (otherwise the port get shutdown)

[Chodley]

Yeah it does stuff like that. What firmware version is the Q on as some fixes were done to reduce packet floods.

don't know what port 7a7a is. 31254 or something, probbaly proprietary to Sky?

[BobbyLovesSky]

On latest firmware on the master and mini's. It's actually very interesting the more I look into the wireshark logs. The Sky Q Master Box actually has 2x MAC addresses on the network. MAC#1 is the LAN NIC and the IP is first assigned by DHCP. This seems to be only used for the initial boot up as then that MAC disappears off the network switches. MAC#2 then appears. Looks like a "virtual" MAC but with no IP address assigned. (MAC#1 and MAC#2 and the same except the last digit) This "No IP" MAC#2 is the one responsible for the broadcast storm Another curious thing is the other Sky Q mini boxes are also broadcasting constant ARP's looking for the Sky Q Master by it's IP which doesn't exist once MAC#2 appears. Despite this they play fine. It's all still "working" for now but the network is getting absolutely hammered by the Sky Q master broadcast traffic (the cause of over 95% of the traffic in the wireshark packet capture).

[Chodley]

I've said Sky Q's networking is bonkers before and it bears repeating 😉 suspect that's maybe UDP traffic so it doesn't need a valid IP if it doesn't want anything back (might explain why the switches don't know where it came from so can't decide properly what to do with it) or it decides its own for its mesh and you can't see it. Is there a sender IP on those packets?

[64monks]

Was there any resolution or work-around to this? Ive had to isolate the SkyQ & Minis away from the rest of the network to avoid this issue. The only way I could do it was to hang them off thier own port switch on their own port on the hub.

[BobbyLovesSky]

You have the set up a separate vlan to put all skyq devices in it and disable wifi on all sky boxes. There is no other way and it will never be fixed.