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 Bridging
Starting a new thread specific to my issue. So I woke up this morning to V2.1.3.4 being installed. Not only was my wireless network down but so was my wired network. Started troublshooting and noticed that my OSX network monitor was showing 25-50Mbits of sustained traffic. Fired up tcpdump and saw a TON of arp and other broadcast traffic. Looked at my switchports and they were blowing up. Started disconnecting cables one by one until I got to my Orbi and it stopped. Before today I had made no layer 1 changes to my network.
Did something change in V2.1.3.4 that would cause bridging to operate differently? Maybe something realted to STP to fix the Chromecast issue? Because my current theory is that whatever is different this rev is causing a bad broadcast storm which is murdering the network. Rebooting the Orbi's fixes it - and as long as I don't muck around with it it's stable. But whenever I enable or disable daisy chain the storm seems to happen.
I can telnet, sniff, etc. if someone wants to ask me to look at something else.
24 Replies
And FURRYe38 if you want me to try anything let me know.
OK, just asking. Was a full factory reset performed on both router and Satellites and setup from scratch yet?
Any network switches between the router and satellite?
What is the mfr and model# of the ISP modem your using?
When trying to use Daisy Chain, I presume you physically have the Satellites piggy backing of each other and not wired for back haul ?
I would also try this. Test with the router alone. Turn off all Satellites. Then graduate by adding one Satellite via wireless. Test for issues. Then add another.
Yeah I factory reset the router via the web interface first. Then reset each satellite via the pinhole. Physically resynced each.
Satellite----cat5----Switch----Orbi Router----Wireless Clients /| Satellite----/ | Switch-----VMware Server---Firewall----internet | | Other hardwired stuff (e.g. AppleTV, etc.)Notes: Switches are D-Link DSG-1100-16/24 with default, unmanaged configs. ISP Cat5 goes right into firewall. No modem.
Firewall is a VMware-based Sophos XG appliance. It does DHCP and has not been changed in a long time. Not doing any fancy IPS or any other strange things to internal traffic. It's basically a "dumb" router at this point.
Not sure what you mean by "physically have the Satellites piggy backing of each other" I have both satellites connected to the same ethernet switch so that they can setup the bridge between them -- it was working in the previous firmware. Do I need to directly connect (e.g. via a coupler/barrel connector) each Orbi to make ethernet backhaul work?Thanks!
Edit: tiny edit to better reflect network topo.
You might try changing the configuration to daisy chain the 2nd Satellite off the first one, instead of both connected to the same switch and see if this changes anything. Don't enable Daisy Chain on the router. Just see if adding the 2nd Sat to the back of the 1st Sat does anything different. I would also just as a quick test, take the switch out of the mix and directly connect both to the Orbi router. See if anything seen is different.
I have this similar network configuration. There is 2 unmanaged switched between my 1 satellite and the router. I don't have a 2nd Sat at this time so I can't test this with you.
Is this your switches?
http://us.dlink.com/products/business-solutions/dgs-1100-16/
If so, these are managed switches...
It's possible there are some kind of configuration on your D-Link DGS managed switches that could be causing this.
Were you able to test a fully non managed switch? If so what was the results? What is the Mfr and model# of this non managed switch?
Ok, great info.
Now I wonder if you revert back to prior version of FW, does this still happen? Which FW version had you been using before for reference?
I had the latest version prior to v2.1.3.4 as it automatically upgraded. Whatever that was.
I'm not going to revert back a rev to troubleshoot this more -- this is now NETGEAR's problem. Someone from NETGEAR can easliy figure it out by looking at their source code repo to see if STP was enabled on the bridge interface (br0) prior to 2.1.3.4. I'm (obviously) willing to tinker and help but I think I've done enough. Surely NETGEAR has a testing lab where they can do this in minutes.
My only hope is that this issue somehow floats up from the community message boards to a devloper who knows exactly what I'm talking about here. The fact that an ethernet backhaul loop is trashing customer's networks because STP was seemingly left off is a pretty bad screwup. This type of issue isn't something your front-line support folks are going to be able to effectively troubleshoot. If you are a NETGEAR employee reading this, pop this thread into Slack and ask a dev to take a peek at this.
STP might have been disabled for some other reason that I'm not aware of - I don't have all of NETGEAR's use cases but this sure seems like a bad bug. There is a Reddit thread here: https://www.reddit.com/r/orbi/comments/88zy2y/v2134_and_ethernet_backhaul/ and other people are impacted by this.
I've posted this as well. Hopefully will see something come about.
You might ask them about v2.2.x.x Beta FW. I see one post over on SNB that one user said it resolved this backhaul issue.
Hello Foritus
What firmware version are you on?
DarrenM
