I would appreciate assistance diagnosing a VLAN problem. Now that many homes have Ethernet cables installed from most rooms to a central patch panel, some users find that the patch panel is not a great location for their WiFi router (actually, any WiFi access point). They would rather place the router at a different location. However, with only a single Ethernet cable from the patch panel to that location, they need to find a way to connect both their internet connection (WAN) and also local devices to that router. The obvious solution is, "run more Ethernet cables". This is often impractical. VLAN provides another solution. Use one Ethernet cable to carry both the router to Internet (WAN) traffic and the router to local devices (LAN) traffic. Here is an example: The Internet Host and the customer router are not aware that they are using a VLAN because they are connected to "Port Based" (untagged) VLAN ports. (Port 1 on each Netgear switch.) Likewise, the router LAN port and the local devices are not aware they are using VLAN because they are also connected to "Port Based" (untagged) VLAN ports. However, one port on each switch is an 802.1Q "tagged" VLAN. WAN traffic is tagged for VLAN 1 and every other port is tagged for VLAN 2. IGMP Snooping is disabled on both switches. This solutions works wonderfully. The puzzle comes when a mesh satellite is added to the configuration. Netgear's Orbi line of WiFi systems requires that mesh satellites must be connected to the router LAN port. (They cannot appear to be connected to the WAN port.) As long as the router is configured in 'router mode', a satellite can be connected directly to a router LAN port (location 1) or connected to one of the ports on the GS108Ev3 (location 2). However..... If the Orbi router is put into 'access point mode' (AP), then the mesh satellite will function correctly only when it is connected directly to one of the router LAN ports. If connected to the GS108Ev3, 'wired' connections to the mesh satellite still function, but WiFi connections FAIL. I cannot understand what could be different between 'router mode' and 'AP mode' that would cause this.

Re-think please. The Orbi LAN Port (and the Orbi Satellite port of course) is supposedly carrying two networks: These are [U]ntagged Orbi LAN (also == the PVID) making the every device you connect like connected to this same router LAN keeping a simple flat network, plus the [T]agged 4092 guest network, same for the Orbi Satellite LAN port. All you have to to - regardless of the switch brand or model - is to define that additional VLAN 4092, and make every port [T]agged for the VLAN ID 4092. No worries, in this example, the guest network is on the VLAN 1977, available as [T] on all Swisscom routers available since the last to decades (almost). All you have to do is to change your switch to the advanced 802.1Q mode (this retains the default LAN config for VLAN 1, [U]ntagged, and PVID 1 on each port; then [Add] the VLAN 1977 to the switch. The process can be different based on the WebUI version, on the classic switch Web UI it has to be defined, omn the modern mobile device WebUI it can be done in one step. On my switches, each port is defined as a trunk, for the basic VLAN 1, plus for the guest VLAN 1977 here in these examples, but I'm convinced you can handle the difference.: Very similar when using Netgear Insight ... On the VLAN ID intended, [Select All] and click [Trunk Port] ... In each case, the VLAN 1 remains unchanged, since my home network is pure flat, the ISP router does DHCP for the LAN here, the VLAN 1, ...

schumaku wrote: Port mirroring (aka SPAN ports, which can be local or even remote in a different end if the network!) can be an effective helpers, but often easy hit their limits.. A good collection of reasons is there -> https://www.gigamon.com/resources/resource-library/white-paper/to-tap-or-to-span/ This article is "spot on". Put another way, "the devil is in the details." None of the three methods I described will capture a full out gigabit data stream that is active in both directions: The Throwing Star functions by clamping the connection rate to 100Mbps and using power from the devices being monitored to drive the two 100Mbps taps (one for each direction). So, "keeping up" is not a concern, but the data rate is compromised. The Datacomm captures gigabit in both directions, but outputs only a single gigabit connection to the monitor. So, if the total data in both directions exceeds about 920Mbps, then it will lose packets. Mirroring to a single port suffers from the same issue. If both transmit and receive are constantly over a half gigabit, then it will fall behind. The inexpensive TP-Link switch I used for this exercise allows only one "mirror port". However, the two situations where I needed a tap both fell well under the switch capability: Tapping my 350Mbps ISP feed was "no problem". The total bandwidth was significantly under the switch capacity. For this "wired satellite" experiment, there was very little actual data traffic across the connection, so the switch was easily able to keep up.

Been a fairly long standing issue with a smart/managed switch with Orbi systems. I happened to get help from a user while in a switch beta last year that they helped me get ethernet connected RBS with a smart/managed switch in the middle with a VLAN ID tag of 4092 while the Orbi is in router mode. After testing this out with a few different Orbi systems and a few different NG switches, this VLAN ID seems to work with RBS ethernet connected with the switch in between the Orbi router and the RBS. While on same beta switch project and just another late last year, I had tested Orbi systems in AP mode with these smart managed switches and in both projects the RBS exhibited bad behaviors when ethernet connected to the switch. Both projects collected logs from both Orbi and switch units and both switch project engneers pointed to this being a problem in Orbi FW. Nothing in the switch side was causing the bad RBS behaviors from what both projects told me. Seems that something is specific in the wired backhaul that when a smart managed switch is in the middle and the Orbi system is configured or AP mode, something in Orbi FW isn't quite handling the data flow properly. Again, this is only in AP Mode with Orbi systems and with a smart/managed switch in the mix while RBS are ethernet connected to it. Switches I've tested are GS108T, GS808E, MS105E and GS728TX. Orbi RBS fail to work correctly with any of these in the middle while in AP mode. This Orbi AP mode issue doesn't present itself if non managed switches are in the middle. GS108, GS308, GS110MX and XS505M have been tested extensively. I do have some non NG branded switches, managed and non managed that I should check out. Since testing the NG switches out, I presume that maybe other branded switch may exhibit similar issues so I just haven't tried yet. I've asked NG to take a look into this to see if maybe this could be fixed by NG. No feedback yet. Possible that it may never be fixed and in most cases, for home users at least, a smart managed switch may not be in use with a Orbi system in AP mode. And a work around for this would be to just install a non managed switch in between the RBR and RBS. My 2 cents.

I have reproduced the puzzle using TP-Link managed switches. Same results: In router mode, a satellite connected to the router using an 802.1Q tagged VLAN port behaves normally. In AP mode, a satellite connected to the router using an 802.1Q tagged VLAN fails to support Guest WiFi devices. What I am looking for is an explanation or a suggestion for how to document "what is happening?" My naive understanding of managed switches is: When a packet comes into an untagged port, the switch inserts a 802.1Q Header into the frame with the PVID assigned to that port***: If the packet is sent out a "tagged" port, this Header remains in the frame. (even if it passes through dozens of Ethernet switches on its way through the network). Eventually the packet comes out an untagged port and that Header is removed. i.e. "what goes in, comes back out." *** PVID: * What does "not already addressed (tagged)" mean? Do untagged ports accept tagged packets? What if..... when the Orbi is put into AP mode, it treats the link to the satellite as a tagged VLAN link? Some packets are "tagged" for special treatment. This (somehow?) gets mangled by the managed switch and these frames just disappear. Or, when they come out the other end, both their original 802.1Q Header and the switch 802.1Q Header have beeen stripped and the packet is not recognized as coming from an Orbi unit? Or....maybe..... When in AP mode, the switch puts an 802.1Q Header on some frames and the managed switch (a) replaces them with the PVID or does not put the PVID on them and thus those frames are part of a VLAN that is not defined on the managed switch? Annoys me no end that a knowledgeable Netgear engineer could answer this is five minutes. "No, dummies. THIS is why a managed switch messes up AP mode." (sigh. They are not being paid to talk to customers.) It looks like the way to check out this theory is to snoop on both the router LAN port and the satellite LAN port to record what is "going in" and "coming out" on both ends. This requires more managed switches to mirror those two Ethernet links and two Ethernet adapters to get the data into a computer running Wireshark. Going to be an enormous tangle of cables.

The VLAN config looks about right in the scheme on the initial post. Since you are using some ports as a tagged trunk, I assume this config is not the simple port based one, much more the advanced VLAN config with the appropriate PVID set for each VLAN so untagged frames incoming are sent to the right VLAN. A possible difference in AP mode is that the Orbi WAN and LAN port are bridged, and the Loop Protection will (read: must!) jump in, and close some ports, since the "loop test" frames the switch does send-out are coming back on a different port - some port will be disabled, and the relevant LEDs will flash. Worth disabling the Loop Detection to start with? However: From the IT network professional view, I still can't understand what should make a difference on the Orbi Systems AP mode WAN and LAN port, and why Netgear (and trusted senior community members like CrimpOn and FURRYe38 - hello friends - insist) there seems to be some difference. Reminds me somehow to the NTGR Nighthawk Mesh systems obviously using some other, IEEE standards compliant Mesh protocol - which are also badly fail on any kind of Plus (renamed to == Easy Smart Managed), Smart Managed, Fully Managed switches. Probably again that Layer 2.5 abstraction layer introduced along with IEEE 1905.1 or something proprietary serving a similar purpose? Something similar must apply to the Orbi Guest network (or any Orbi Router <-> Satellite for wireless) on the wire level. Had never been involved in any Orbi or Orbi Pro systems Beta, and have sold off my second hand Orbis due to that poorly documented (or at least rarely explored) behaviour, prohibiting correct interoperability with business class and business standards. This is why I keep my mouth usually shut on the Orbi community 8-)

VLAN Puzzle | NETGEAR Communities

72 Replies

FURRYe38
Guru
Mar 27, 2025
Been a fairly long standing issue with a smart/managed switch with Orbi systems.

I happened to get help from a user while in a switch beta last year that they helped me get ethernet connected RBS with a smart/managed switch in the middle with a VLAN ID tag of 4092 while the Orbi is in router mode. After testing this out with a few different Orbi systems and a few different NG switches, this VLAN ID seems to work with RBS ethernet connected with the switch in between the Orbi router and the RBS. While on same beta switch project and just another late last year, I had tested Orbi systems in AP mode with these smart managed switches and in both projects the RBS exhibited bad behaviors when ethernet connected to the switch. Both projects collected logs from both Orbi and switch units and both switch project engneers pointed to this being a problem in Orbi FW. Nothing in the switch side was causing the bad RBS behaviors from what both projects told me.

Seems that something is specific in the wired backhaul that when a smart managed switch is in the middle and the Orbi system is configured or AP mode, something in Orbi FW isn't quite handling the data flow properly. Again, this is only in AP Mode with Orbi systems and with a smart/managed switch in the mix while RBS are ethernet connected to it.

Switches I've tested are GS108T, GS808E, MS105E and GS728TX. Orbi RBS fail to work correctly with any of these in the middle while in AP mode.

This Orbi AP mode issue doesn't present itself if non managed switches are in the middle. GS108, GS308, GS110MX and XS505M have been tested extensively.

I do have some non NG branded switches, managed and non managed that I should check out. Since testing the NG switches out, I presume that maybe other branded switch may exhibit similar issues so I just haven't tried yet.

I've asked NG to take a look into this to see if maybe this could be fixed by NG. No feedback yet. Possible that it may never be fixed and in most cases, for home users at least, a smart managed switch may not be in use with a Orbi system in AP mode. And a work around for this would be to just install a non managed switch in between the RBR and RBS.

My 2 cents.
- CrimpOn
  Guru
  Mar 27, 2025
  I have reproduced the puzzle using TP-Link managed switches. Same results:
  
  In router mode, a satellite connected to the router using an 802.1Q tagged VLAN port behaves normally.
  
  In AP mode, a satellite connected to the router using an 802.1Q tagged VLAN fails to support Guest WiFi devices.
  
  What I am looking for is an explanation or a suggestion for how to document "what is happening?"
  
  My naive understanding of managed switches is:
  
  When a packet comes into an untagged port, the switch inserts a 802.1Q Header into the frame with the PVID assigned to that port***:
  
  If the packet is sent out a "tagged" port, this Header remains in the frame. (even if it passes through dozens of Ethernet switches on its way through the network).
  
  Eventually the packet comes out an untagged port and that Header is removed.
  
  i.e. "what goes in, comes back out."
  
  *** PVID:
  
  * What does "not already addressed (tagged)" mean? Do untagged ports accept tagged packets?
  
  What if..... when the Orbi is put into AP mode, it treats the link to the satellite as a tagged VLAN link? Some packets are "tagged" for special treatment. This (somehow?) gets mangled by the managed switch and these frames just disappear. Or, when they come out the other end, both their original 802.1Q Header and the switch 802.1Q Header have beeen stripped and the packet is not recognized as coming from an Orbi unit?
  
  Or....maybe..... When in AP mode, the switch puts an 802.1Q Header on some frames and the managed switch (a) replaces them with the PVID or does not put the PVID on them and thus those frames are part of a VLAN that is not defined on the managed switch?
  
  Annoys me no end that a knowledgeable Netgear engineer could answer this is five minutes. "No, dummies. THIS is why a managed switch messes up AP mode." (sigh. They are not being paid to talk to customers.)
  
  It looks like the way to check out this theory is to snoop on both the router LAN port and the satellite LAN port to record what is "going in" and "coming out" on both ends. This requires more managed switches to mirror those two Ethernet links and two Ethernet adapters to get the data into a computer running Wireshark. Going to be an enormous tangle of cables.
  - schumaku
    Guru
    Mar 28, 2025
    The VLAN config looks about right in the scheme on the initial post.
    
    Since you are using some ports as a tagged trunk, I assume this config is not the simple port based one, much more the advanced VLAN config with the appropriate PVID set for each VLAN so untagged frames incoming are sent to the right VLAN.
    
    A possible difference in AP mode is that the Orbi WAN and LAN port are bridged, and the Loop Protection will (read: must!) jump in, and close some ports, since the "loop test" frames the switch does send-out are coming back on a different port - some port will be disabled, and the relevant LEDs will flash.
    
    Worth disabling the Loop Detection to start with?
    
    However: From the IT network professional view, I still can't understand what should make a difference on the Orbi Systems AP mode WAN and LAN port, and why Netgear (and trusted senior community members like CrimpOn and FURRYe38 - hello friends - insist) there seems to be some difference. Reminds me somehow to the NTGR Nighthawk Mesh systems obviously using some other, IEEE standards compliant Mesh protocol - which are also badly fail on any kind of Plus (renamed to == Easy Smart Managed), Smart Managed, Fully Managed switches. Probably again that Layer 2.5 abstraction layer introduced along with IEEE 1905.1 or something proprietary serving a similar purpose?
    
    Something similar must apply to the Orbi Guest network (or any Orbi Router <-> Satellite for wireless) on the wire level.
    
    Had never been involved in any Orbi or Orbi Pro systems Beta, and have sold off my second hand Orbis due to that poorly documented (or at least rarely explored) behaviour, prohibiting correct interoperability with business class and business standards. This is why I keep my mouth usually shut on the Orbi community 8-)
CrimpOn
Guru
Apr 12, 2025
A common situation for people with 'wired' houses is having only a single Ethernet cable from the central patch panel to each room. Placing a simple switch in that location allows many devices to be connected to the network. However, there is one specific application that does not work. Often that central patch panel location is not suitable for a WiFi access point and users would prefer to locate their WiFi router in a different room. This works great as long as the Orbi satellites are connected to the router using the default WiFi connection ('backhaul'). Netgear Orbi routers are designed to expect the ISP connection to appear on their WAN port and any 'wired' satellites on the LAN ports. Thus, connecting a satellite to the router with Ethernet requires another Ethernet cable. This is often inconvenient or very expensive.

One solution is to place one managed switch at the patch panel and another managed switch at the router location. Using 802.1Q VLAN tagging, the single Ethernet cable can carry both the WAN connection and the LAN connection:

In attempting to discover what causes this solution to fail, the following experiment was conducted:

Using a single Netgear GS105Ev2 managed switch, connect a router LAN port to one port and the satellite to a different port. (see below) i.e. do not utilize the 'tagged' VLAN ports for the WAN connection.

With this configuration, everything works except when attempting to connect a device to the Guest WiFi. That fails. The device generates DHCP requests that are visible on Tap2, but those DHCP requests do not appear on Tap 1. They do not get through the managed switch!

The solution is to change from Advanced VLAN to an ordinary Port Based VLAN. i.e. put ports 1 and 5 in VLAN 1 and ports 2,3,4 in VLAN 2. Then, a device connected to the satellite Guest WiFi sends DHCP requests that go trough the managed switch to the router and the device receives a Guest WiFi assignment back from the router.

This "solution", of course, is not a solution at all because it does not account for the WLAN traffic that needs to be separated from the LAN traffic by using an 802.1Q 'tagged' VLAN connection between a pair of switches.

Can anyone suggest how to configure a Netgear managed switch to make this work?

p.s. now that I have invested in multiple Ethernet taps, the next step is to set up the original proposed solution again and monitor "both ends" to see if any packets are being dropped.
- schumaku
  Guru
  Apr 12, 2025
  Dear CrimpOn
  
  The point is that -we- (or at least me...) don't know what fancy tricks and probably undercover standards are affecting the functionality of these Orbi Systems - especially in AP mode. Trial-and-error reverse "engineering" attempts won't bring us much forward.
  
  The point is your post does imply a potential "problem" on these very simple Web-configurable switches (ways off from Netgear Smart Managed or Managed Switches).
  
  The more likely cause is hidden somewhere in the Orbi in AP mode requirement, having the WAN port connected to the router LAN, while the satellites seemingly -must- be connected direct to the Orbi Router LAN.
  
  That much, this is not more than reading in the coffee grounds. Admit, your effort investing in to Ethernet Taps with Wireshark ports is impressing. Have offered my time, experience, and know-how to Netgear on almost any Orbi Beta without success. For my part, I won't invest my money in Orbi Systems - especially because of the lack of Netgear Engineering backing all over here to the customer base.
  
  Happy weekend!
  
  -Kurt.
  - CrimpOn
    Guru
    Apr 12, 2025
    I am resigned to the possibility that Netgear has programmed something into the backhaul communication protocol that fails when put into AP mode. The point of this experiment is to document "what's different" in the data stream between the two modes. The immediate issue is my lack of understanding of 802.1Q VLAN methodology. The original experiment has been side-tracked by the damn managed switches.
    
    Unless the results are incorrect (always a possibility), it appears that:
    
    When the GS105Ev2 is set up as a Port Based VLAN, a broadcast packet that comes in on any port that is part of VLAN 2 goes out every port that is part of VLAN 2. Just what one would expect. The problem is that I need to connect two switches with a "tagged" VLAN connection.
    
    When the switch is set up as an "advanced" 802.1Q VLAN, a broadcast packet that comes in on one port that is labelled as VLAN 2 does not come out the other ports that are labelled VLAN 2. That seems ridiculous. I haven't gotten to the "tagged" port at all.
    
    Looking for next steps:
    
    Hoping someone watching this Netgear forum will offer insights.
    
    Could open a case with Netgear support on the new GS105Ev2. (confidence level not high.)
    
    Could replicate this simple experiment with a TP-Link managed switch.
    
    Is there another forum, perhaps on Reddit, where someone might have experience with 802.1Q VLAN?
FURRYe38
Guru
Apr 18, 2025
Just FYI, I tried the 4093 ID tagged on all ports, as well with 4092, GN still failing for devices attempting to connect at the RBS when ethernet connected to a smart managed switch. Wireless backhaul works fine.

I've just collected debug logs from the Orbi system I've tested and screen captures and data and sent this off to the Orib team for review. Will see if I get any response. I captured working configuration with wireless BH then ethernet BH connected to the switch and devices attempting to connect to the GN there and failing. Hopefully logs will show all this.

I'll update here if I get any feedback.
- schumaku
  Guru
  Apr 18, 2025
  "There ain't nobody here but us chickens."
  
  Not the first (and probably not the last network device or appliance maker reserving (and actively using!) a certain VLAN ID scope. Some have claimed it to be a trade secret, but after similar insights had been published to public forums, they crawled back - officially documenting their designs, and even offer the options to redefine the predefined and reserved VLAN IDs to their customer base.
  
  Unfortunately, Netgear is far away from real-world deployments - not only for Orbi, but also for their smart switches offering these magic AutoXXX VLANs.
  
  What nicely works on the green table with a direct Ethernet link, in a closed environment, or on some PMs desks proofs (following the community here) is simply not ready to deploy in different aspects.
  
  Looking at that magic Orbi Compatibility Table proofs zero interest by Netgear into such questions (and no discussions please). Buy and accept as-is, or leave it. All we want is your hard earned money. And you seriously expect we will be able to find (aka. as reverse engineer) some industry standard config for what should be a simple Ethernet configuration.
  
  To make it even more difficult? Unless I have missed something essential both CrimpOn and FURRYe38 have neither mentioned which Orbi models- To me, it's even more in the dark with AP mode if and how the LAN and the WAN ports are connected on all these experiments.
  
  To make the FURRYe38 reply more complete, please provide some more insight on the switch config from your vague test.
CrimpOn
Guru
Apr 24, 2025
The VLAN Puzzle arose because of an attempt to use a single Ethernet cable to connect an Orbi router to both the Internet source (WAN) and the local network (LAN). The obvious solution is to install a second Ethernet cable, which is not always practical (or inexpensive). A pair of inexpensive Smart switches can create one VLAN for the WAN to ISP traffic and a second VLAN for the LAN to local network traffic, with a "tagged" port on each switch keeping the traffic separated as it passes between the router and the central wiring hub.

This also addresses a problem many users have when they put an Orbi router into "access point" (AP) mode and have only a single cable from the router to the central network location. Orbi routers expect that satellites will be connected either (over WiFi) or to the router LAN ports. Satellites will never be connected to the WAN interface.

Everything works great unless (a) satellites are 'wired' to the router, and (b) the Guest WiFi network is enabled. The puzzle was to determine why the Guest network fails.

It turns out that an Orbi 750 satellite connected to an Orbi 750 router using a "managed" Ethernet switch does not support devices connecting to the Guest WiFi network because Netgear uses two types of Ethernet frames on the same Ethernet ports:

Ordinary Ethernet frames carry communication between the router and satellite and any devices 'wired' to them or connected to the primary WiFi network

Frames tagged with VLAN 4093 carry communication between:

The 5G WiFi ports on the router and satellite, and

Any devices connected to the Guest WiFi network on the satellite.

Generic Smart Switches (i.e. "managed") from Netgear, TP-Link (and probably other companies) support two types of VLAN:

Port Based VLAN. Any frame arriving at a port is "tagged" with the VLAN designated for that port and keeps that tag as long as it is within the smart switch architecture. Using internal MAC address tables, the switch determines which port the frame should be sent out of. If that port is also a Port Based VLAN, then the VLAN tag is stripped from the frame.

802.1Q Tagged VLAN. If a port is "tagged", then the frame is sent out with the VLAN tag intact. It goes to the next switch, and the process repeats.

I used Wireshark and a network tap to capture the traffic between an RBR750 and RBS750. The instant they are physically connected, they begin sending ieee1905 topology notification messages.

https://en.wikipedia.org/wiki/IEEE_1905

Messages from the hardware MAC address of the router LAN port have no VLAN tag.

Messages from the hardware MAC address of the router 5G WiFi port have VLAN Tag 4093.

When the satellite responds with ieee1905 topology information:

Messages with the hardware MAC address of the satellite LAN port have no VLAN tag.

Messages with the hardware MAC address of the satellite 5G WiFi port have VLAN tag 4093.

So, all we need to do is tell this pair of Smart switches:

If a frame comes in from the router/switch LAN port with no VLAN tag, temporarily assign a tag to it (maybe "3") so that it can find it's way to the tagged port leading to the other switch. When it gets to the other switch, find the correct port and output the frame with no tag.

If a frame comes in with VLAN tag 4093, send it to the tagged port to the other switch. When it gets to the other switch, send it to the right port and send it out, keeping the VLAN tag on it.

I can find NO 802.1Q VLAN setting to make this happen.
- schumaku
  Guru
  Apr 24, 2025
  Why on earth yet another new thread? Please merge accordingly!
  
  CrimpOn wrote:
  
  So, all we need to do is tell this pair of Smart switches:
  
  If a frame comes in from the router/switch LAN port with no VLAN tag, temporarily assign a tag to it (maybe "3") so that it can find it's way to the tagged port leading to the other switch. When it gets to the other switch, find the correct port and output the frame with no tag.
  
  If a frame comes in with VLAN tag 4093, send it to the tagged port to the other switch. When it gets to the other switch, send it to the right port and send it out, keeping the VLAN tag on it.
  
  I can find NO 802.1Q VLAN setting to make this happen.
  
  This quoted section only? This is exactly my proposal from before! So I try again...
  
  Simple:
  
  As per your example, define the port where the untagged frames are coming in (the Orbi router facing one, same for the switch2switch connection trunk link) to work on VLAN 3: Make it [U]ntagged and VLAN 3, PVID 3. (the switch will assign these frames into the VLAN 3). Add additional [T]agged ports needed - so this port becomes a trunk, plain Ethernet for VLAN 3, plus all the other VLANs
  
  On the Orbi satellite end same story:
  
  Make it [U]ntagged and VLAN 3, PVID 3. (the switch will assign these frames into the VLAN 3). Add additional [T]agged ports needed - so this port becomes a trunk, plain Ethernet for VLAN 3, plus all the other VLANs
  
  Voila, here is your trunk connection.
  
  When it comes to IEEE1905, only IEEE1905 compliant devices can communicate. IEEE 1905 can establish dedicated control channels and actions, reconfiguring things. This might include the ability to "generate" not only plain Ethernet connections, but also tagged connections.
  - FURRYe38
    Guru
    Apr 24, 2025
    "Simple:
    
    As per your example, define the port where the untagged frames are coming in (the Orbi router facing one, same for the switch2switch connection trunk link) to work on VLAN 3: Make it [U]ntagged and VLAN 3, PVID 3. (the switch will assign these frames into the VLAN 3). Add additional [T]agged ports needed - so this port becomes a trunk, plain Ethernet for VLAN 3, plus all the other VLANs
    
    On the Orbi satellite end same story:
    
    Make it [U]ntagged and VLAN 3, PVID 3. (the switch will assign these frames into the VLAN 3). Add additional [T]agged ports needed - so this port becomes a trunk, plain Ethernet for VLAN 3, plus all the other VLANs"
    
    So with this configuration, I presume this can be all configured on 1 switch in between the RBR and RBS and avoid the use of two switches and the extra LAN cable?
FURRYe38
Guru
May 01, 2025
Ok so got home today and checked the single RBS that was still ethernet connected to the switch with the RBR in AP Mode, GN connected clients still getting internet access. Woo hoo.

So I then connected the 2nd RBS wirelessly first to get it synced to the RBR, after that connected 2nd RBS to same switch as 1st RBS. Waited and waited and waited, RBS failed to switch over to ethernet BH: 🤔

Kinda worried that something on switch was blocking something however I figured, lets try a reboot from the RBRs web page. After system was back online, both RBS showed ethernet BH, Woo Hoo.

Guest Network clients still working behind 1st RBS. Will get something connected to 2nd RBS to test GN. Should be good I hope.

Yes, GN connected clients behind 2nd RBS is working. Woo hoo.
- FURRYe38
  Guru
  May 05, 2025
  CrimpOn Have you tried one managed switch yet with VLAN 4093 with the Orbi 750 series in AP mode?
  - CrimpOn
    Guru
    May 05, 2025
    Yes. Did so this morning.
    
    In AP mode, the RBR750 appears on the primary network with 2 IP addresses:
    
    192.168.1.115, and
    
    192.168.2.1
    
    The RBS750 appears with one IP address:
    
    192.168.1.118
    
    When the Ethernet cable is connected to perform the switch from WiFi backhaul to Ethernet backhaul, VLAN 4093 frames immediately appear.
    
    Connected a Samsung tablet to the Guest WiFi on the satellite. Was assigned IP 192.168.2.2. Does not appear on the primary network Attached Devices (hidden by 750 NAT), but does appear on the 750 Attached Devices. Tablet can browse the web, etc.
    
    Switch configuration is:
    
    VLAN 1 - Ports 1,5 (1 is untagged. 5 is tagged for WAN traffic)
    
    VLAN 2 - Ports 2,3,4,5 untagged
    
    VLAN 4093 - Ports 2,3,4,5 tagged
    
    Works exactly the same as two switches. The key is setting up two VLANs, one not tagged and VLAN 4093 tagged on both the router LAN port and the port leading to the satellite.
FURRYe38
Guru
May 11, 2025
So coming back to this, seems that I have found the VLAN IDs for the Orbi 970 series. 4092 is the main WLAN and IoT networks, and 4091 is the Guest Network.

However for the Orbi BE 970 series is still using the older GN 192.168.2.x subnet while the newer 770 and 870 series systems are using a newer 10.177.177.x subnet which I was now informed by NG that this uses 3890, changed from 4091.

I presume 4091 is same on AX and AXE Orbi systems as well.

And after todays testing in AP Mode, Guest Network is failing when the RBS is ethernet connected to one switch in between with VLAN ID 4091 set.

Wondering if there is a VLAN configuration combination that needs to be set on one switch to make this work right for the older GN using 192.168.2.x with VLAN 4091 using one switch and not two. The newer Orbi systems using 10.177.177x and 3890 is working and resolves the GN failing behind the RBS thats ETH connected in AP mode with one switch. Will see if we can get one switch working with the older GN subnet.