NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Disabling automatic subnet reconfig
I was wondering if there was a way (yet) to disable Orbi’s automatic IP reconfig if it detects a “conflicting” subnet? I understand the spirit of what it’s for, but frankly it’s a bugged feature (yes,...
CrimpOn : Did some final testing and now confident in the conclusion.
What triggers the "reconfiguration" behavior appears to be whenever Orbi detects any other network device on the other side of it's Internet (WAN) port sharing the same subnet. It doesn't matter if there's an actual conflict or not -- simply it's existence. From a consumer support standpoint this is actually a pretty clever mechanism (though I wish they'd give us the option to disable it for various use cases).In my *personal* case - the issue was that I'd put the ports in their respective VLANs (10 for WAN, 20 for LAN) but left VLAN 1 in place. Regular (untagged) traffic was working just fine. My guess is that during a firmware update on those GS108Ev3 switches, it was sending out a broadcast across all configured VLANs, Orbi was seeing that broadcast on the Internet port, hence reconfiguration is triggered. I removed VLAN 1 from all ports and haven't been able to replicate the problem since.
As for your question about the use case for the two switches? This as a method to extend out multiple networks over a single cable. My current configuration looks like this:
VLAN 10 = WAN Traffic
VLAN 20 = LAN Traffic
-----BASEMENT
GS108Ev3 - Port 1: VLAN 10 Tagged, VLAN 20 Tagged
GS108Ev3 - Port 2: VLAN 10 Untagged
GS108Ev3 - Port 3-8: VLAN 20 UntaggedAT&T Gateway LAN plugged in to GS108Ev3 Port 2
UPSTAIRS OFFICE
GS108Ev3 - Port 1: VLAN 10 Tagged, VLAN 20 Tagged
GS108Ev3 - Port 2: VLAN 10 Untagged
GS108Ev3 - Port 3-8: VLAN 20 Untagged
Orbi Internet Port plugged in to GS108Ev3 Port 2
-----
Port 1 is the single physical cable running between the two switches. It will pass all traffic for either VLAN (LAN or WAN side) without either seeing one another as the traffic is "encapsulated" (isolated from each other). Port 2 on each side is where you plug in the WAN side of things. In the basement I have several runs from around the house plugged in to ports 3-8 (LAN). In the Office, I also have a bunch of devices plugged in to 3-8 (LAN). Two separate floors but they'll all end up in the LAN side.The notion that someone shouldn't be using managed switches in a network topology is a silly one, assuming the configuration is correct. In my particular case (and the fix to the original problem I posted about) turns out to simply be "don't let Orbi's Internet port see any traffic with a subnet that matches it's LAN side". Simple enough, makes a lot of sense. Once I understood what was triggering the reconfigurating, finding the root cause was simple.
(Extra thanks to schumaku for the sentence that led to the conclusion -- "Somehow the Orbi system does see any 192.168.x.x network on it's WAN/Internet port.")
"So I reconfigure GW for 172.16.0.0/24. Problem goes away for a bit..." what do you mean for a bit? Is 172 still configured on the GW?
I would remove the switches and the try the Orbi with using 192.168.1.1.
Any IGMP protocols should be disabled...
What FW version are you using?
Has a factory reset and setup from scratch been performed since last update?
FURRYe38 : Rephrased. Yes, the ATT GW is still configured for 172.16.0.0/24. After changing the ATT GW to that subnet, I hadn’t experienced the issue again in a few days. Granted, it’s been less than a week and other threads on this topic suggest the potential of this happening at DHCP lease renewal - but for now it’s been a few days *until* I added the switches last night.
A recommendation of “remove the switches” doesn’t solve the problem nor explain specifically what triggers the behavior (such as why this happened when performing a firmware update on the switches, which are layer 2 devices and don’t even have routing capability).
IGMP Snooping was disabled on the switches this morning as per your advice.
As of last night I am running FW 2.7.2.102. I forget which version I was previously on (though the issue persists with the latest).
No, I have not performed a factory reset since performing the firmware update. Why would this be recommended as it pertains to the issue at hand?
A recommendation of “remove the switches” doesn’t solve the problem nor explain specifically what triggers the behavior (such as why this happened when performing a firmware update on the switches, which are layer 2 devices and don’t even have routing capability).
IGMP Snooping was disabled on the switches this morning as per your advice.
As of last night I am running FW 2.7.2.102. I forget which version I was previously on (though the issue persists with the latest).
No, I have not performed a factory reset since performing the firmware update. Why would this be recommended as it pertains to the issue at hand?
Sometimes lingering code or misconfigurations of the system after newer FW updates are applied can cause problems. Reset is a necessary and normal step to try to see if anything changes. I have seen many issues with updating FW and problems seen. Resets are a step to check this.
I've had my RBR behind other routers before and haven't seen this issue. Though my main host router uses 192.168.0.1, so leaving the .1.1 default on any other router behind the host router, doesn't produce this issue.
Hoping that a reset would be the step that fixes this. Unless someting about 172 used on the GW is somehow causing orbi to use 10.something. I've never used 172. You could try 192.168.0.1 on the GW and see.
- FURRYe38 : *WHICH* subnet is used should be irrelevant as long as there is no conflict. I also confirmed the issue existed both pre and post FW upgrade, so the upgrade wasn’t the cause.
I keep trying to drag the conversation back to the layer 2 switches as that’s the behavior that makes the least sense. They have zero L3 routing capability. A “conflict” with them is impossible unless one tried configuring their IP for the same as the router. The behavior is repeatable when kicking off a firmware update (on the switches). Their factory default IPs are 192.168.0.239 so even if during their upgrades they somehow momentarily defaulted back to that network, it wouldn’t overlap with any existing network. If I don’t understand the specific mechanism that’s causing the behavior, I can’t confidently prevent it from happening again at an arbitrary time.
(I’m a network architect so if you *do* understand what’s happening under the hood, please don’t hold back in explaining!)Ok. Speaking from a troubleshooting perspective, I would remove the switches completely.
I would change the IP address of the GW to either 192.168.0.1 or even try a 10.something address ON the GW.
Factory reset the RBR and setup from scratch. Get the system up and running using the default IP address string. WIth out the switches. I would also change the IP address pool size on the RBR as well, I use .100 to .200. This leaves room for some static IP addressed devices on either side of this pool. Will come back to this and switches later.
Check the system out for any continued changes. I'd be curioius to know if the Orbi still doesn't something after this.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
