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 notice...
Need to give time to the router or clear broswer caches and refresh for the back haul to appear correctly. I rebooted the router then cleared browser cache, exited the browser then reopened and logged into the routers web page.
Add the 2nd Satellite direct to the router then try daisy chain behind 1st Sat.
I'm wondering if there is a problem with your switches...Do you have an actual non managed switches you can try? Would need to help rule this down to your managed switches or something in FW.
I get what you mean about the cached UI but I've never seen any stale UI/web issues. I tried via an incognito window and same result. Next step is to reboot stuff but right now the family is watching streaming things so I'll bounce the Orbis tomorrow.
I have a small truly unmanaged switch I can try but again, this all started with the firmware update when I was sleeping. I was literally woken up by alerts about stuff being offline.
I have a few ideas of some things I can try (e.g. putting all bridged traffic on a dedicated switch). I'll let you know if I find anything.
Ok, keep us posted. I'm curious about your unmanaged switch results...
Is the Orbi is running in router mode or AP mode?
Orbi is running in AP mode.
So to recap - connecting one satellite directly to the Orbi router's LAN port (not via the switch) solves the bradocast storm/loop issue. If I plug the 2nd satellite into a switch (in an attempt to get ethernet backhaul to work), it results in a serious broadcast storm that hoses my entire network.
So, I enabled telnet on the 2nd satellite and ran:
brctl stp br0 1
This enabled STP on the bridge interface and boom -- fixed. I am hard wired now with wifi off:
~ speedtest Retrieving speedtest.net configuration... Testing from Verizon Fios (x.x.x.x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by XXXXX (XXXXXXX, XX) [12.01 km]: 7.488 ms Testing download speed................................................................................ Download: 706.85 Mbit/s Testing upload speed................................................................................................ Upload: 144.08 Mbit/s
Based on this I REALLY think that this is due to STP being disabled in V2.1.3.4. I'm going to look to see how to make STP persist through reboots and call it a day. Thanks for your help FURRYe38
I would pass this on to NG support as well to make sure they review this:
Thanks for posting your detailed info on this.
packetwerkswrote:Orbi is running in AP mode.
So to recap - connecting one satellite directly to the Orbi router's LAN port (not via the switch) solves the bradocast storm/loop issue. If I plug the 2nd satellite into a switch (in an attempt to get ethernet backhaul to work), it results in a serious broadcast storm that hoses my entire network.
So, I enabled telnet on the 2nd satellite and ran:
brctl stp br0 1
This enabled STP on the bridge interface and boom -- fixed. I am hard wired now with wifi off:
~ speedtest Retrieving speedtest.net configuration... Testing from Verizon Fios (x.x.x.x)... Retrieving speedtest.net server list... Selecting best server based on ping... Hosted by XXXXX (XXXXXXX, XX) [12.01 km]: 7.488 ms Testing download speed................................................................................ Download: 706.85 Mbit/s Testing upload speed................................................................................................ Upload: 144.08 Mbit/s
Based on this I REALLY think that this is due to STP being disabled in V2.1.3.4. I'm going to look to see how to make STP persist through reboots and call it a day. Thanks for your help FURRYe38
I strongly don't think so simply for the fact that the switches have not been touched in over a year -- and it just so happened that the storm happened right after V2.1.3.4 was automatically installed and the fact that implmenting STP (the exact reason STP even exists) addresses this issue. It's not the managed switch doing anything. This is a classic bridge loop problem.
The problem is that the satellite is a bridge that has two paths (wired and wireless backhaul) to the network which introduces the loop. This is a classic application for STP. STP tells the bridge to send the traffic via one path, not both. It does this by evaluating the "cost" (based on port speed) of the paths. This is what my satellite looks like without STP enabled (because it's directly connected to the router (the router has has STP enabled):
root@RBS50:/# brctl showstp br0 br0 bridge id 8000.9c3dcfe58e21 designated root 8000.9c3dcfe58e21 root port 0 path cost 0 max age 20.00 bridge max age 20.00 hello time 2.00 bridge hello time 2.00 forward delay 0.00 bridge forward delay 0.00 ageing time 60.00 hello timer 0.84 tcn timer 0.00 topology change timer 0.00 gc timer 37.93 flags
Note the "root port" as being 0. That's because since STP is off, there is no designation on what port the traffic should go.
Here is 'brctl showstp br0' on my satellite that where I manually enabled STP:
root@RBS50:~# brctl showstp br0 br0 bridge id 8000.9c3dcfe5a281 designated root 8000.9c3dcfe53026 root port 1 path cost 4 max age 20.00 bridge max age 20.00 hello time 2.00 bridge hello time 2.00 forward delay 2.00 bridge forward delay 2.00 ageing time 60.00 hello timer 0.00 tcn timer 0.00 topology change timer 0.00 gc timer 2.68 flags
You'll see that the root port is 1. What is port 1? It's eth1:
eth1 (1) port id 8001 state forwarding designated root 8000.9c3dcfe53036 path cost 4 designated bridge 8000.9c3dcfe53036 message age timer 18.19 designated port 8001 forward delay timer 0.00 designated cost 0 hold timer 0.00 flags
eth1 is the ethernet backhaul connection to my switch. It also has a cost of 4 (the wireless backhaul connection has a cost of 100). So all bridge traffic will ONLY go to port 1 and not via wireless backhaul avoiding the loop/storm. This is STP in action as it should be.
Would still be interested to know if testing exhibits the same problem with a non managed switch.
Ok, just used a Netgear 5 port 10/100/1000M Switch GS605 v2 unmanaged switch and saw the same behavior. Here's what I did:
1. Moved all in-scope ethernet cables to the GS605 switch and saw green link lights on everything.
2. Plugged Macbook into the Orbi satellite and started tcpdump and turned off wireless
3. Rebooted Orbi router, satellite, and waiting for everything to come back up
4. Noticed a spike in traffic (5mbits) and observed a huge amount of broadcast traffic on my Macbook's ethernet. Another server I have with snmp monitoring also saw 5mbits of traffic.
5. Telnet'd into the satellite and ran 'brctl stp br0 1' and saw broadcast traffic back to normal -- which took a while because the network was getting murdered by the flood.
Hope this helps!