cancel
Showing results for 
Search instead for 
Did you mean: 

Superhub 3 incompatible with TP-Link Deco M5

Jeremy_K
Tuning in

After changing from a Superhub2 to a Superhub 3 my TP-Link Deco system stopped working.  After tests and discussions with TP-Link it appears that the Superhub 3.0 does not correctly pass through the IEEE 1905.1 packets that the Deco system uses for ethernet backhaul.

This would seem to be an unfortunate incompatibility.  Has anyone else found this?  Virgin, please sort out the deficiencies in your hub.

55 REPLIES 55

sophist
Trouble shooter

Ok. So the switch is seeing the mac addresses of all three decos on g11 - this is presumably where the main deco physically connects to the switch?

assuming the other two decos connect to ports g12 and g13 (arbitrary, just for the purpose of this conversation) what is the status of those two ports on the switch - are they reporting as physically up (port status) are they reporting as being in a blocking mode (stp port status)?

G11 is not the main Deco - see below:

Deco / Physical port / CST Port status or RSTP as they are showing the same

Main  43 / Backup-discarding

Slave1 35 / Designated forwarding

Slave 2 11 / Designated forwarding

 

Message from TP link tech support:

"We found that the Netgear switch didn't transfer some important information for the main deco and the satellite unite, which related to the Ethernet backhaul. But we didn't find the reason from the messages we got from Deco. So we are testing in our lab and try to reproduce the issue. But since we don't have the Netgear GS 748T switch, the problem is still under testing. Our R&D department are helping to analyze the problem you met as well. We will try our best to find a solution.I will update the process with you once we find something new. 

At the same time, it is recommended to contact Netgear support to ask them to help analyze the logs of the switch if there is records in the logs. "

sophist
Trouble shooter

so your switch is blocking on hte port that the main deco is connected to and it is doing this automatically, using spanning tree... It will be doing this as it can already see a connection to it via another link.. so in order to prevent a loop, it is blocking one of them..

in terms of physical connections, the connection between the hub and the main deco is a direct cable between the two, right? (i.e. it doesn’t go via the switch).

there’s little / no documentation on deco using spanning tree, but i suspect that it does and does so to prevent network loops when using ethernet backhaul (if you had both ethernet and wireless backhaul active at the same time you would end up with loops in the network).

STP will give different paths different costs.. a 1gb link will have a lower cost than a 100mb link, and therefore be the “preferred” path, so where there are two switches connected together using a 1gb link and a 100mb link, it will favour the 1gb link and put the 100mb link into a blocking state - this would only be unblocked if the 1gb link failed.. i suspect that what’s happening is the wireless backhaul is being given a lower cost than the ethernet link and therefore being favoured as the primary path.. 

without any more info on how the deco uses stp, you’re gonna have to play around with some settings to get this working..

Configure your netgear to be teh STP root bridge.. going on “standards” (which i have to assume teh deco adheres to in the absense of any documentation) all of the devices that participate in STP on your network will have a bridge priority of 32768. When STP is initially set up, all devices participate in an election to promote one device to be the root bridge.. this is then the authority on the network about the best path to take to any given device.  The election promotes the device with hte lowest priority+mac address to be the root.. it’s possible/likely that in your current configuration, this is one of the decos

in order to force the netgear to be the root bridge, you need to give it a lower priority than the decos - give it 4096 or 8192. 

this alone may resolve the problem. if not, you may need to start playing with configuring path costs, but that;s a subsequent activity depending on what happens after you make the switch the root bridge

 

 

 

Yes hub to main Deco is direct ethernet connection

In terms of the STP priority. Is this a setting on the Deco or the GS748Tv5?

sophist
Trouble shooter

on teh switch.

when you make the change, all of the decos will disconnect and an election will occur resulting in the netgear being nominated as the bridge.. it should only take 30 seconds or so for everything to reconverge and connectivity to come back though.. 

Is this the right page. It already has it as 4096

Nikinp_0-1607609264833.png

 

sophist
Trouble shooter

yes - that is the setting you need to change...

what is hte RSTP configuration? (you may need to change both, as we don’t know what teh decos have implemented)

can you find anything in there about what the switch thinks is teh root bridge?  does it think it is the root bridge, or does it see another device is teh root bridge? (it will likely tell you which port it sees teh root bridge on, as well as the MAC address of the device acting as hte bridge)

making it zero will be hte lowest it can be

it’s probably also worth relaying some of this information to tp-link -  tell them that you think it’s an STP issue and try to get some info out of them about how the decos use spanning tree/what their default settings are etc.. (i.e. is it STP or RSTP, what’s the default bridge priority, are the path costs worked out entirely on link speed, or should physical connectivity always result in a lower cost...)

I think this is the page which is about the STP configuration of the netgear, it has a configuration name and then below the designated root looks similar in name.

Nikinp_0-1607610447442.png

also on this page, it has the same identifier as the for all the ports

Nikinp_1-1607610707442.png

 

Does it mean the switch is already the root?

 

 

it’s also worth checking that the link between the main deco and the switch is actually negotiating at 1gb, and not 100mb - you should be able to see it in the port status somewhere,, if it;s negotiating at 100mb, that might explain why the decos are preferring the wireless backhaul, as the connection is faster..