Orbi RBK53 ethernet backhaul issue

[dalnew]

I have upgraded my Orbi router and satellites to the latest firmware (2.1.2.18) and I am seeing some weird behavior with regard to what's shown on the "Connected Satellites" section of the orbi router. Mainly I am seeing one of my satellites refuse to connect using the ethernet backhaul, giving me poor dl/ul performance when connected to that satellite. It is plugged directly into the same switch as all the other satellites and router, and the ethernet cable to the switch is plugged into the leftmost Orbi satellite port (not sure if that matters or not) but for some reason it always connects over 5G. Unfortunately 5G doesn't work well in my house due to the walls and shape of the house, which is why I had ethernet run in the first place.

The second satellite, plugged into the same switch, connects correctly over ethernet backhaul, but displays a really weird IP address, one that shouldn't be possible in my network (my router only assigns IPs from 192.168.0.X). When my phone connects to that satellite performance is excellent and it's IP seems normal (192.168.0.193). Maybe there's just something screwed up with the display in the router page? This must be the case since I can directly connect to that satellite at 192.168.0.177. 

Is there an option to force a satellite onto ethernet or is this just a bug that is causing the satellite to fall back to 5G? I know the ethernet port/switch works fine since I can connect my PC directly to it and get great speeds.

Here's a picture of what my router is showing for the two satellites:

[budy]

If your router is working in AP mode, be sure to connect it to the switch using the first LAN port and not the router port. If your LED ring stays a solid magenta afterwards… this seems to be a bug in the Orbi firmware. I switched the LED ring off, since this cabling is also the way Netgear has stated on their support site on how to connect the satellites via ethernet.

In this setup, either the satellites as well as the devices connected wirelessly to the satellites are displayed correctly on the Orbi's web page.

[dalnew]

So I definitely had the router plugged into the WAN port still even though it was in AP mode. I moved the cable over to the leftmost switch port on the RBR50 and now I'm really getting weird behavior. Internet access from the RBR seems to be working fine, however both satellites now show up as 5G... at least they now both have the correct IP addresses. In addition, any devices connected to those satellites have no internet access and are having issues connecting to local nodes as well.

Let me try resetting everything and starting over to see if that fixes anything.

[dalnew]

So I did a hard power-on reset and then disabled daisy chain topology and one satellite is now up and running on wired but the other is still forcing itself onto 5G. What gives?

Netgear, if you're listening, it would be great if you could have an option to select the backhaul to use. Eg Auto, ethernet, 5g. That was some of us could force a specific satellite onto ethernet when these weird cases crop up and the satellites don't seem to use the faster backhaul.

[webminster]

Throwing out obvious questions, have you verified the cable to that satellite is good, no faults?   Any way to check it or substitute a different cable to make sure? Same for switch port? 

[dalnew]

Yes I know the cable is good and the switch ports are fine. If I connect that cable directly to my PC, instead of the satellite, I get consistent speeds of over 100MB/s. There's no way to switch the cable as it is run through the walls from my top floor down into the basement where the network closet is.

Btw, my router is listing the IPs of all the satellites correctly now and the ManCave orbi that was originally on 5g is now on ethernet backhaul, but the orbi that was on ethernet is now on 5G (at least according to the router page here):

The speeds from the downstairs router are pretty good, so it's not a huge deal, just more of an annoyance that I can't figure out why it says it's on 5G. Obviously when ethernet is available I'd prefer the Orbis to run on that due to latency and reliability concerns. On every AP I'm getting around 450Mb/s+ when I run Speedtest on my phone in the different rooms. The big deal was the ManCave AP. That AP is far enough from the router than when it runs on 5G the speeds are attrocious... around 20Mb/s, which for that room is unnacceptable given that there are 3 computes and a TV that runs a bunch of devices like AppleTV, PS4, etc.

I already disabled daisy chaining, but that doesn't appear to have done anything obvious. Is there a way to tell if the downstairs Orbi is, in fact, running on 5G? Maybe the router is just displaying the info incorrectly and it's actually on ethernet now?

[t_k]

---

wrote:

Yes I know the cable is good and the switch ports are fine. If I connect that cable directly to my PC, instead of the satellite, I get consistent speeds of over 100MB/s. There's no way to switch the cable as it is run through the walls from my top floor down into the basement where the network closet is.

Btw, my router is listing the IPs of all the satellites correctly now and the ManCave orbi that was originally on 5g is now on ethernet backhaul, but the orbi that was on ethernet is now on 5G (at least according to the router page here):

The speeds from the downstairs router are pretty good, so it's not a huge deal, just more of an annoyance that I can't figure out why it says it's on 5G. Obviously when ethernet is available I'd prefer the Orbis to run on that due to latency and reliability concerns. On every AP I'm getting around 450Mb/s+ when I run Speedtest on my phone in the different rooms. The big deal was the ManCave AP. That AP is far enough from the router than when it runs on 5G the speeds are attrocious... around 20Mb/s, which for that room is unnacceptable given that there are 3 computes and a TV that runs a bunch of devices like AppleTV, PS4, etc.

I already disabled daisy chaining, but that doesn't appear to have done anything obvious. Is there a way to tell if the downstairs Orbi is, in fact, running on 5G? Maybe the router is just displaying the info incorrectly and it's actually on ethernet now?

---

You probably already figured this out, but you're not missing anything. The ethernet backhaul feature just unreliable. Unfortunately, you are throwing away your time attempting to make it stable.

See this thread where another user spent many hours finding this out the hard way

See this post for my results when I also tried this and had similiar results to you.

I'd hate to see anyone else waste their time working with this half-baked feature.

[budy]

Well… I really don't get why you are posting this comment. I had been using ethernet backhaul since fw 2.0x and it had been only after updating to 2.1.2.18, that I actually needed to perform a factory reset on my satellite, since the UI didn't changed from 5G to wired, when I was able to confirm, that the ethernet backhaul worked nonetheless. So, I removed the cabling from the satellite, performed a factory reset and a new sync. Once that was done, I plugged the cable back in, just the way Netgears docs state. That was, when the LED ring on the router stayed a solid magenta, but the system did work. Moreover, all my wireless devices were noted to be attached to their resp. APs, so I decided to simply turn off the LED ring.

That's it… the system has been up for weeks with no issues at all. So, pittying other people for trying to get their setup right, doesn't seem very appropiate to me.

[t_k]

---

@budywrote:

Well… I really don't get why you are posting this comment. I

---

I can answer that and I'd appreciate it if you actually read this. You are describing the switching issue between wired and wireless backhauls that others (including myself) have run into. The problem in a nutshell is this: the Obri "wired backhaul" solution attempts to "auto-detect" if an ethernet cable plugged into one of the built-in switches provides access to the layer 2 broadcast domain. This is a bad idea since any mistakes here will cause broadcast storms and/or cause the Orbi to jump back and forth between wired or wireless backhauls. Examples of exactly that happening is what I provided in links.

This is provably unreliable and this is almost certainly what is causing the issue you described. Sometimes the impact of this problem is minor ( swapping between 5Ghz or wired backuals is usually just a minor performance hit) and sometimes they are major (broadcast loops, bringing down your network). In any event, they are all caused because of a poorly created feature. Auto-detection for a wired backhaul is a risky choice because it

would have to always work.  What was implemented clearly doesn't, that's what everybody using it is running into. Why else would all these unrelated people be on the forums talking about the same thing? There is no secret club trying to undermine the Orbi, these are end users.

Now, say you just spent hours chasing down that problem, and now you see somebody else posting about it. There's no fix and this new person is about to have to go through the same thing - drudge through a bunch of irrelevant suggestions and fuzzy logic, and then either half convince themselves it works or just give up entirely. You might be inclinded to let this person know to stop pushing on a rope. That's why I posted.

That's it… the system has been up for weeks with no issues at all. So, pittying other people for trying to get their setup right, doesn't seem very appropiate to me.

---

See, now that's where things kinda break down. If it's been up for weeks with no issue at all, why did you post 2 days ago about the issue? It doesn't pass the smell test that you would have had no issues for at least 8 days, then posted about an issue. It seems more likely that you just want state "I've had no issues" in order to drive home a point.

Also, who is being pitted against who here? I certainly want Netgear to be held accountable for poor product development and actively misleading their users in the capability of the system. However, user wise, who exactly is being pitted against each other?

For some reason, you seem to really want to "teach me a thing or two" for trying to save you some time. 

And, just to drive the point home, the efforts of making noise seemed to have worked. Late last night Netgear announced they are moving BACKWARDS on their firmware and did a partial acknowledgement of the issues people are facing

https://community.netgear.com/t5/Orbi/OrbiOS-MR-2-1-issues/m-p/1506307/highlight/true#M23649

[budy]

Ehh… no…, actually. You seem to confuse me with someone else… I do know, that the Orbi's firmware has issues for a significant amount of people here on the forums, but you will have to take into account, that this audience is not the majority of Orbi users. For what it's worth, I have deployed 3 Orbi systems and none of those is experiencing any issues, be it disconnects or reboots or issues with their ethernet backhaul, other than the ones I experienced on my own Orbi system. I also don't want to teach you a lesson or two, but I do find it disturbing, that you chose to try to shy people away to from trying the ethernet backhaul, that's all.

I am also not objecting to makeing yourself heard and spurr Netgear to get their act together and provide us with a reliable firmware for our devices, that are not cheap.

[MillerHouseTX]

I have this exact issue... Please help

[FURRYe38]

https://community.netgear.com/t5/Orbi/Steps-to-reproduce-the-Orbi-backhaul-issues/td-p/1516065/jump-...

---

@MillerHouseTX wrote:
I have this exact issue... Please help

---

[Flash008]

Well, if it helps anyone sleep better…

20 year I.T. nerd who just jumped on the Orbi train. Like many, I wanted Ethernet Backhaul and had problems.

I DO USE CISCO MANAGED SWITCHES!!!!

After a few hours of troubleshooting I found my problem.

FIRST…If you don’t understand STP (Spanning Tree Protocol)…..then go read…I am not teaching STP tonight….It’s too late and I am tired.

I can confirm Orbi (and Orbi Pro) are using STP (NOT RSTP)…What a joke…who doesn’t support Rapid STP today…LOL…I managed to confirm this by changing my STP ID (Prioroty) on my Cisco switch to 61440…AND GUESS WHAT???? My root bridge ID (AKA: MAC) changed to the ORBI ROUTER….This is only possible if Orbi is running STP and has an ID higher or the same ID as my Cisco. I typically use ID=0 for my Cisco….Which would explain the problem.

Orbi wants control of STP…..It’s that simple….And Netgear offers no method to change ANY STP settings in their code….Hence your managed switches with STP will go to WAR with Orbi and make Ethernet backhaul nearly impossible.

STP rules my friends…Highest STP ID WINS! It’s just how STP is designed.

Furthermore. If you have a managed switch with a higher STP ID (Priority), then every time Orbi attempts to change (update) the typology (such as switching from WIFI to Ethernet backhaul)….GUESS WHAT…..Can you say “discarding/blocked state”.

What’s more FUN…is the Satellite that is connected via ethernet now has its port set to discarding….This is forcing the satellite to use its WIFI backhaul and my Cisco switch is “discarding all packets from that Satellite Ethernet port.

So now….My ONLY option is to….DISABLE STP on my satellite port. This will allow a LOOP. BAD!!!!

But I must put my TRUST into Netgears hands….and hope the code is smart enough to send all client MACs down the ethernet port and not the WIFI port…God knows if my switch STP sees MACs coming from both the Sat ethernet port and the main Orbi router ethernet port (which will happen if clients MAC take both paths via the WIFI backhaul….)….well….we network nerds know what happens then….LOOP…DISGARD all packets….or broadcast storm (should you disable STP) and your entire LAN crashes…..

So, my config I am rolling with is….STP enabled on my Cisco (only STP, not RSPT…Orbi doesn’t support RSTP…STUPID)…..

Disable STP on Satellite ports….This allows MACs to take both ethernet and WIFI backhaul paths.

Insure STP is enabled on the Main Orbi router ethernet port. AP mode or Router mode, doesn’t matter. This will protect you from a packet loop crash.

This config will allow your Orbi Sat to ALWAYS be able to communicate with the main Orbi regardless of STP status. After that…its entirely up to the Orbi Sat to establish its ethernet backhaul….a reboot will surely be required as the Orbo code is REALLY STUPID…..My GUESS is the Orbi detects Ethernet during boot and if it can contact the Main Orbi via Ethernet…then it prefers that connection and will switch-off the 5Ghz backhaul which I confirmed by logging into the Sat directly and observing the 5Ghz backhaul DISBALED when using ethernet…

But, if that Ethernet drops and Orbi Sat can’t communicate with the main Orbi (due to STP blocking, power outage or other reasons..)…it rolls back to 5Ghz backhaul and doesn’t seem smart enough to switch back to ethernet….without another reboot. Again…stupid….

Hoped this helped those with managed switches and using Orni with ethernet backhaul.

Surely Netgear could have done this better….

An EASY fix would be for Netgear to allow STP to be DISABLED and let our managed switches handle STP….

And really…RSTP would fix this easily….Why are you not using RSTP?….Do you have any idea how long it takes classic STP to update topology when connections change….REALLY….??????

I spent 10 minutes looking at my RSTP stats…then it hit me….My Orbi ports shows STP….NOT RSTP mode. I tried to force an RSTP migration…But nope…Your Orbi’s kicked by STP mode back to classic….LAME!!!!

[Flash008]

Orbi is using STP ID 32768 (STP Default Priority).

[Flash008]

I decided to write an updated version of the Orbi (and Orbi Pro) STP (Spanning Tree Protocol) instructions. This is for users who have managed switches and trying to use Orbi Ethernet Backhaul. Those with unmanaged switches should not have any problems with Ethernet Backhaul.

1. Orbi uses Classic STP. Do not try to use Rapid STP. Hopefully Netgear will change this in a future update.
2. Orbi uses the default STP Priority (AKA: ID) of 32768. Orbi does not allow any modifications of STP settings. Again, hopefully they will change this in the future, at minimum they should Allow Orbi STP to be disabled for those with managed switches.
3. Your L2 managed switch should have STP Enabled. Again, use Classic STP should you have a choice between STP and RSTP. Orbi is STP only.
4. All switches in you LAN “MUST HAVE” an STP Priority of 32768. Do not change your STP priority or Orbi Ethernet backhaul will not work properly. AKA: It may work, then break and cause other undesired problems.
   1. Using an ID higher priority than Orbi will cause your switch to STP Block/discard the Orbi Satellite ports, forcing the Satellites into WIFI Backhaul mode.
   2. Using a lower priority STP ID will allow Orbi to take STP Root Bridge role and most likely create loops and crash your LAN. Plus, any network nerd who cares about security, stability and visibility DOES NOT want Orbi becoming a root bridge of the LAN.
   3. Using 32768 allows each switch (both Orbi and your switch) to become their individual “root bridge” for STP and prevents Orbi and your switches going to WAR and arguing “who has control”.
5. Your Main Orbi Router (using AP or Router mode) must have STP enabled on its switch port with NO MODIFICATIONS. STP, Auto-Edge, Default Cost, etc, etc…no changes…..
6. ALL ORBI SATELITES USING ETHERNET BACKHAUL MUST HAVE STP ENABLED….BUT….
   1. Edge Mode must be forced “ON”. AKA: Port Fast mode ON. I know some network nerds are thinking…”Why would I force an STP BPDU device to use PortFast mode?”….Simple answer…Orbi is using Classic STP and Auto-Edge (AKA: Learning Mode) will take too long and your Orbi Satellites will give up and switch to WIFI Backhaul. After that…you are screwed and must reboot your satellites…or wait 15-20 minutes for Orbi Satellite to “hopefully” try again. Classic STP is SLOW and your Orbi Satellites will need to wait 20-60 seconds for STP to decide if the connection should be allowed…which is why Rapid STP was created YEARS AGO…..Why Netgear is using Classic…I don’t know.
   2. DO NOT DISABLE STP!!! Doing this will cause a network loop and most likely crash your network. Even though you are forcing the Satellite ports to use PortFast Mode (AKA: Edge Mode Enabled…Not Auto). STP will still serve its basic function and protect against network loops. If you disable STP on the Satellite ports….No protection and Orbi will create a loop.

That’s is. Using this config should allow your Satellites to use Ethernet Backhaul with minimal problems via manages switches. Orbi does take a few minutes to determine what path to use. So don’t expect instant results. Give Orbi 5-10 minutes and check the Satellite connection status.

If Your Orbi is rebooted it “should” go back ed wired mode after a few minutes.

But, without a proper STP configuration as described above….NO CHANCE….Or very unstable results.

Shame on Netgear for not allow STP Enable/Disable. Especially for Orbi Pro.

[NetNoggin]

Flash:

THANK YOU!  Man, I need a cigarette after reading that post (and I don't smoke).

I'm an IT guy myself. For switching I use Cisco at work, and Ubiquiti at home, but I didn't pickup on the STP BS. Now it all makes sense. I was about to take these Orbis back to the store. I've been screwing around with these MFers instead of doing funner things this whole weekend. In my home I've got my Orbis plugged into a PoE, manageable Ubiquiti EdgeSwitch. I wish they supported PoE, but I don't really expect it from consumer products. Anyway, I'll switch RSTP over to STP and set their priority. 

Now I'm wondering if I should plug them into a device that will chop the power from time to time. I suppose I'll take a wait and see approach to that.

[NetNoggin]

OK, my RBK53 Orbis seem to be solid now. I have them in AP mode behind a dedicated router, and plugged into a managed switch to use ethernet backhauls. From Flash008's post (he is The Man) I looked into the STP settings of my managed switch. Though it is RSTP capable, it is in fact already using STP, with a priority of 32768. So that wasn't the problem. The problem was that the ports were set to Auto Edge mode by default. Not good. The Orbis would only sometimes use their ethernet backhaul. I disabled Auto Edge mode, and enabled Admin Edge mode. Reboot everybody, and BAM! the Orbis are happy to use their ethernet backhaul. For the past 24 hours I'm getting solid, stable connections, with good Wi-Fi speeds throughout the sprawling house. That was the whole reason for pulling out Asus Wi-Fi routers that I was running as APs. They were unstable, with mediocre speeds.

I do recommend to "Enable Implicit BEAMFORMING", and "Enable MU-MIMO". I'm not certain about the "Enable Fast Roaming" setting yet.

PS--

I don't believe the pretty lights. They lie. . . . I think. I use the Sync button, per the documentation, and training videos, but the lights are saying the devices aren't synced. Yet, all APs seem to work fine. I've read in some other threads that this could be a bug in the firmware. I'm running V2.1.4.16 at the time of this post.

[FURRYe38]

FYI, It was reported by other users that when using managed switches with Orib systems, IGMP protocols need to be disabled. This helped Orbi systems and managed switch work better:

https://community.netgear.com/t5/Orbi/Orbi-MR-2-1-Update-3-23-18/m-p/1553749/highlight/true#M30673
https://community.netgear.com/t5/Orbi/Using-Router-Configured-as-Access-Point-Cannot-see-Satellites-...
https://community.netgear.com/t5/Orbi/Orbi-Ethernet-Backhaul-with-Managed-Switches/m-p/1613897#M3812...

Sounds like you got yours working good though. IGMP is something to keep in mind.

https://www.smallnetbuilder.com/wireless/wireless-features/33195-wi-fi-roaming-secrets-revealed
https://www.smallnetbuilder.com/wireless/wireless-features/33196-wi-fi-roaming-secrets-revealed-part...
https://www.smallnetbuilder.com/wireless/wireless-features/33197-wi-fi-roaming-secrets-revealed-part...
https://www.smallnetbuilder.com/basics/wireless-basics/33180-how-to-fix-wi-fi-roaming
https://www.smallnetbuilder.com/wireless/wireless-features/33100-why-you-don-t-need-mu-mimo

---

@NetNoggin wrote:

OK, my RBK53 Orbis seem to be solid now. I have them in AP mode behind a dedicated router, and plugged into a managed switch to use ethernet backhauls. From Flash008's post (he is The Man) I looked into the STP settings of my managed switch. Though it is RSTP capable, it is in fact already using STP, with a priority of 32768. So that wasn't the problem. The problem was that the ports were set to Auto Edge mode by default. Not good. The Orbis would only sometimes use their ethernet backhaul. I disabled Auto Edge mode, and enabled Admin Edge mode. Reboot everybody, and BAM! the Orbis are happy to use their ethernet backhaul. For the past 24 hours I'm getting solid, stable connections, with good Wi-Fi speeds throughout the sprawling house. That was the whole reason for pulling out Asus Wi-Fi routers that I was running as APs. They were unstable, with mediocre speeds.

I do recommend to "Enable Implicit BEAMFORMING", and "Enable MU-MIMO". I'm not certain about the "Enable Fast Roaming" setting yet.

PS--

I don't believe the pretty lights. They lie. . . . I think. I use the Sync button, per the documentation, and training videos, but the lights are saying the devices aren't synced. Yet, all APs seem to work fine. I've read in some other threads that this could be a bug in the firmware. I'm running V2.1.4.16 at the time of this post.

---