NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
v2.1.3.4
My Orbi autoupgraded to v.2.1.3.4 this morning and I found tht ethernet backhaul no longer works. Is this expected behavior? Anyone else seeing this?
Just updated to 2.1.3.4 and trying to run ethernet backhaul completely bricks my entire network even after hard resetting everything. What a mess.
Here is how I was able to use ethernet backhaul while using a central switch without bricking my network:
TLDR; 1.) access debug.htm on your wired satellites, 2.) telnet to the satellite, 3.) run "brctl stp br0 1". If you reboot the satellite you will need to re-run it - I've not yet looked into how to make it persistent. The problem is redundant paths from the satellite causes a loop/storm.
Long version:
The problem is that the sattelites act as a layer 2 bridge. One challenge with bridges is that they are suceptable to loops or broadcast storms if there are redundant paths over the bridge: wired backhaul and wireless backhaul. Just like a microphone and a speaker are suceptable to feedback where the sound goes back into the microphone, to the speaker, to the mic, to the speaker, etc. This is what is happening when you plug in the ethernet backhaul.
To fix loops, spanning tree protocol (STP) was invented. When enabled on a bridge, STP can detect if there is a loop, and then force traffic to the best/fastest/"least cost" connection out of the bridge. So rather than traffic going out both the wired and wireless backhauls (creating a loop/storm), it forces it out the LAN port -- which is what you want. This worked fine on the Orbi until v2.1.3.4, when I woke up to 25-50mbits of sustained brodcast traffic, hosing my entire network and causing all kinds of things to reboot constantly.
My theory is that in v2.1.3.4 Netgear removed spanning tree protocol (STP) from satellites. So to re-enable it:
1. Enable telnet on the sattelite (debug.htm)
2. Run: brctl stp br0 1
3. Do this on all ethernet backhaul'd sattelites.
4. Plug in ethernet to LAN port (or note that your network isn't on fire now if it's already plugged in)
An alternative work around is to connect the satellites directly to the router via cat5 and don't use a central switch - that way the broadcast traffic never hits the switch (and thus never hits the broadcast domain for the network).
I'm 99% sure that this is what is happening and I hope that (barring any other issues I'm misssing) Netgear will re-enable STP for satellites. Please give this a try and let me know if it fixes your issue.
Edit: Here is a separate thread that shows my testing: https://community.netgear.com/t5/Orbi/V2-1-3-4-Bridging/m-p/1543720#M27221
I presume this process isn't needed if there isn't any managed switches in the mix which you do have and should mention. We've seen issues with the Orbi system and the use of Managed network switches. Non managed switches dont exhibit this issue. Nor does this issue exist when directly connected to the Orbi router with out any switches being in the mix.
This would be a work around for those using Managed switches. Users with Managed switched should also contect the Mfr of these switches to see if there is any configurations on the switches to help with confiurations and use of Orbi Systems.
I've asked for some review of this from NG support. Will see if anyone responds.
Again, have you tested the Orbi system with a NON Managed switch? What are the results?
I was using an unmanaged Netgear Prosafe switch and was still running into issues
Whats the model # of this switch?
What model Orbi system do you have?
How many Satellites?
What Daisy chain enabled or disabled during testing?
Trying to get the details of these switches that people are using so I can forward this to NG. Hoping that they can figure this out. Any and all info is helpful so they have all they need to work with this.
ppilot212wrote:I was using an unmanaged Netgear Prosafe switch and was still running into issues
