Switch capabilities of AIMesh Nodes?

[TD99]

Hi all, I'm glad I found this thread, which I've thoroughly read. I've been struggling for a week and need some assistance before I lose my mind.

Based on an article I recently read on Ars Technica detailing the vulnerabilities of Asus routers, I finally upgraded my RT-AX86U Pro (running in AP Mode) from 3.0.0.4_388_24199 to 3.0.0.6.102_34349. Of course doing that changed the way Guest Networks work -- now with VLAN functionality.

• I have two AiMesh nodes: RT-AC86U on 3.0.0.4.386_51967 (latest) and RT-AC68U on 3.0.0.4.386_51733 (latest)..
• All 3 were connected (Ethernet backhaul) via a Netgear unmanaged switch. So I just replaced it yesterday with a TP-Link TL-SG108E to get VLAN support.
• My main WiFi network IP range is 192.168.2.X and my Guest Network (VLAN 52) is 192.168.52.X. All DHCP is handled by my pfSense firewall.

I've tried configuring the TP-Link switch many different ways based on this Asus FAQ and this one too. No luck.

Whenever a wireless IoT device (Amazon Echo, EZVIZ Camera, Kasa Smart Switch, etc.) connects to one of the Asus AiMesh nodes, it gets a 192.168.2.X IP address instead of a 192.168.52.X address. The only way I can force the devices to get the correct IP is to simply cut power to both my Asus nodes so everything connects to the main RT-AX86U router.

Based on this thread, should I assume that my RT-AC86U and RT-AC68U (both on 3.0.0.4) simply are incompatible when it comes to having both a wired backhaul and VLAN support, and therefore I am simply out of luck?

Any advice is much appreciated!

 

[Seth Harman]

Hi all, I'm glad I found this thread, which I've thoroughly read. I've been struggling for a week and need some assistance before I lose my mind.

Based on an article I recently read on Ars Technica detailing the vulnerabilities of Asus routers, I finally upgraded my RT-AX86U Pro (running in AP Mode) from 3.0.0.4_388_24199 to 3.0.0.6.102_34349. Of course doing that changed the way Guest Networks work -- now with VLAN functionality.

• I have two AiMesh nodes: RT-AC86U on 3.0.0.4.386_51967 (latest) and RT-AC68U on 3.0.0.4.386_51733 (latest)..
• All 3 were connected (Ethernet backhaul) via a Netgear unmanaged switch. So I just replaced it yesterday with a TP-Link TL-SG108E to get VLAN support.
• My main WiFi network IP range is 192.168.2.X and my Guest Network (VLAN 52) is 192.168.52.X. All DHCP is handled by my pfSense firewall.

I've tried configuring the TP-Link switch many different ways based on this Asus FAQ and this one too. No luck.

Whenever a wireless IoT device (Amazon Echo, EZVIZ Camera, Kasa Smart Switch, etc.) connects to one of the Asus AiMesh nodes, it gets a 192.168.2.X IP address instead of a 192.168.52.X address. The only way I can force the devices to get the correct IP is to simply cut power to both my Asus nodes so everything connects to the main RT-AX86U router.

Based on this thread, should I assume that my RT-AC86U and RT-AC68U (both on 3.0.0.4) simply are incompatible when it comes to having both a wired backhaul and VLAN support, and therefore I am simply out of luck?

Any advice is much appreciated!

I'm pretty sure all of your AiMesh nodes need to be on some version of 3006 to have native Guest Network support. You could hack an ugly fix by binding all your IoT devices to a single node and then inserting the managed switch into the backhaul for that node and tagging all traffic passing through it as VLAN 52, but then ANYTHING that connects to that node is going to be forced onto VLAN 52.

 

[visortgw]

Hi all, I'm glad I found this thread, which I've thoroughly read. I've been struggling for a week and need some assistance before I lose my mind.

Based on an article I recently read on Ars Technica detailing the vulnerabilities of Asus routers, I finally upgraded my RT-AX86U Pro (running in AP Mode) from 3.0.0.4_388_24199 to 3.0.0.6.102_34349. Of course doing that changed the way Guest Networks work -- now with VLAN functionality.

• I have two AiMesh nodes: RT-AC86U on 3.0.0.4.386_51967 (latest) and RT-AC68U on 3.0.0.4.386_51733 (latest)..
• All 3 were connected (Ethernet backhaul) via a Netgear unmanaged switch. So I just replaced it yesterday with a TP-Link TL-SG108E to get VLAN support.
• My main WiFi network IP range is 192.168.2.X and my Guest Network (VLAN 52) is 192.168.52.X. All DHCP is handled by my pfSense firewall.

I've tried configuring the TP-Link switch many different ways based on this Asus FAQ and this one too. No luck.

Whenever a wireless IoT device (Amazon Echo, EZVIZ Camera, Kasa Smart Switch, etc.) connects to one of the Asus AiMesh nodes, it gets a 192.168.2.X IP address instead of a 192.168.52.X address. The only way I can force the devices to get the correct IP is to simply cut power to both my Asus nodes so everything connects to the main RT-AX86U router.

Based on this thread, should I assume that my RT-AC86U and RT-AC68U (both on 3.0.0.4) simply are incompatible when it comes to having both a wired backhaul and VLAN support, and therefore I am simply out of luck?

Any advice is much appreciated!

I don't believe that you need a managed switch at all. Any unmanaged switch THAT CORRECTLY PASSES VLAN TAGS will work (TP-Link definitely work, but I have no experience with Netgear), or you can factory reset the TL-SG108E to use it as an unmanaged switch. The step that you may have missed is configuring which guest networks are passed to which AiMesh nodes (different from 3004.x firmware). Select Guest Network Pro (or Network), select the IoT networks to be forwarded, select AiMesh from right column, and select desired node(s).

 

[jksmurf]

I don't believe that you need a managed switch at all. Any unmanaged switch THAT CORRECTLY PASSES VLAN TAGS will work (TP-Link definitely work, but I have no experience with Netgear), or you can factory reset the TL-SG108E to use it as an unmanaged switch. The step that you may have missed is configuring which guest networks are passed to which AiMesh nodes (different from 3004.x firmware). Select Guest Network Pro (or Network), select the IoT networks to be forwarded, select AiMesh from right column, and select desired node(s).

Referring to this post, I said:

@bennor asked in this post further up the thread if I’d seen ASUS recommendations on putting a managed switch between Router and Node. So after I bought the little TL-SG105E as a trial, I did exactly that and this is what the spiel above was all about i.e. that it did not work for me, as the Node (apparently) can’t just be on 3006, it must be VLAN-capable (so it begs the question why do you even need the switch, but maybe there’s other reasons you might).

My attempts were all trying to get Ehernet connected devices onto the IoT (VLAN53) LAN via Ethernet ports on the nodes. Per my post this did not work (works ONLY with VLAN capable Nodes).

BUT if you're just trying to get Wifi devices connected to Nodes, note that you need to check the LIMITED Connections that the main Router allows for non 3006 capable nodes i.e. maybe (wild guess) your nodes are not getting those bands to those nodes as another VLAN is hogging the node/band?

 

[Seth Harman]

Whenever a wireless IoT device (Amazon Echo, EZVIZ Camera, Kasa Smart Switch, etc.) connects to one of the Asus AiMesh nodes, it gets a 192.168.2.X IP address instead of a 192.168.52.X address. The only way I can force the devices to get the correct IP is to simply cut power to both my Asus nodes so everything connects to the main RT-AX86U router.

He's talking about wireless clients and he's running 3004 firmware on the nodes which I think we've established at this point from previous threads don't support Guest Network Pro. There's three separate cases we've seen so far across previous threads:

A) AiMesh nodes that don't support Guest Network Pro at all
B) AiMesh nodes that support Guest Network Pro but don't support VLAN tagging on the node Ethernet ports
C) AiMesh nodes that support both

The managed switch is going to come into play if you want to add VLAN tagging to wired clients at the node location in cases A and B. You can also use it to force all traffic going across a node Backhaul onto a specific VLAN. So whether you need the managed switch or not depends on what you're trying to accomplish. But in all cases we've seen so far I think it's pretty clear the node has no chance of supporting Guest Network Pro if it's not running 3006-revision firmware.

 

[jksmurf]

He's talking about wireless clients and he's running 3004 firmware on the nodes which I think we've established at this point from previous threads don't support Guest Network Pro. There's three separate cases we've seen so far across previous threads:

A) AiMesh nodes that don't support Guest Network Pro at all
B) AiMesh nodes that support Guest Network Pro but don't support VLAN tagging on the node Ethernet ports
C) AiMesh nodes that support both

Apologies to come across as picky here, but I’d qualify case (A) with the note that it depends on what you define as “supporting” GNP. Any ASUS Router that is AIMesh capable is a Mesh Node that “supports” GNP insofar as you can add it, within the GNP interface, to your VLANs, subject to limited interfaces per channel per node. See pic in my post above. These are 3004 codebase nodes and work for Wi-Fi clients. I believe the cases we discussed above (at least my specific case) where it did not work, were related to wired clients.

Case (B) are 3006 Codebase nodes but not VLAN capable, per @visortgw list earlier in the thread.

Case (C) are 3006 Codebase nodes that are VLAN capable. This is the holy grail, but alas, none exist with only internal antennas. Think ZenWifi shapes. Meh.

The managed switch is going to come into play if you want to add VLAN tagging to wired clients at the node location in cases A and B. You can also use it to force all traffic going across a node Backhaul onto a specific VLAN.

Again, I’d qualify this as I found (as detailed in this post from earlier in this thread) that the managed switch sitting between a Case (A) node and the primary router did not add tags to clients connected to the Ethernet ports of the node. Maybe this was down to my lack of understanding of setting up the managed switch but I am reasonably confident I did this correctly, to no avail.

What did work was that clients (I used an ESP32) connected to the managed switch, which was then connected to the node, had tags added and I could allocate them to the VLAN I wanted; but again, only with the managed switch before the node.

So whether you need the managed switch or not depends on what you're trying to accomplish. But in all cases we've seen so far I think it's pretty clear the node has no chance of supporting Guest Network Pro if it's not running 3006-revision firmware.

As above, 3004 codebase nodes can be selected to be added within GNP, for Wi-Fi clients, with limitations on interfaces. They are attached to the 3004 codebase node (RT-AX3000) via Wi-Fi and use manually assigned IP addresses in the (via dnsmasq-2.conf.add, see my separate thread how I achieved that, with much help from others). I don’t know if this latter advice would solve the OPs original problem but in theory they should be assigned IoT subnet IPs dynamically if manual assignments are not used.

 

[Seth Harman]

Again, I’d qualify this as I found (as detailed in this post from earlier in this thread) that the managed switch sitting between a Case (A) node and the primary router did not add tags to clients connected to the Ethernet ports of the node. Maybe this was down to my lack of understanding of setting up the managed switch but I am reasonably confident I did this correctly, to no avail.

What did work was that clients (I used an ESP32) connected to the managed switch, which was then connected to the node, had tags added and I could allocate them to the VLAN I wanted; but again, only with the managed switch before the node.

I'd say it's likely due to something not configured correctly on your end. The managed switch can be setup to VLAN tag any traffic coming through the designated port/ports and it doesn't matter if the traffic is coming directly from a device or a device connected to another switch/AP/router first.

As above, 3004 codebase nodes can be selected to be added within GNP, for Wi-Fi clients, with limitations on interfaces. They are attached to the 3004 codebase node (RT-AX3000) via Wi-Fi and use manually assigned IP addresses in the (via dnsmasq-2.conf.add, see my separate thread how I achieved that, with much help from others). I don’t know if this latter advice would solve the OPs original problem but in theory they should be assigned IoT subnet IPs dynamically if manual assignments are not used.

If getting node-connected clients to receive an address from a Guest Network Pro IP block requires you to get into the main router and edit files I'd argue that node does not, in fact, support Guest Network Pro as designed. A fully supported GNP on AiMesh nodes means a wireless client can be configured to connect to the GNP-defined SSID and get an IP from the associated IP block automatically regardless if it's connecting to the main router or any AiMesh nodes. As you can see, the OP is saying any wireless client connecting to a node is NOT getting an IP from the 52.x block when connecting to the GNP-defined SSID. Yes, he may be able to manually assign via MAC either through the method you outlined or manually on the main router itself but it's not working as intended as defined by Asus.

 

[Tech9]

As you can see, the OP is saying any wireless client connecting to a node is NOT getting an IP from the 52.x block when connecting to the GNP-defined SSID.

@TD99 has routers on 3004.386 firmware. @jksmurf has routers on 3004.388 firmware.

 

[jksmurf]

I'd say it's likely due to something not configured correctly on your end. The managed switch can be setup to VLAN tag any traffic coming through the designated port/ports and it doesn't matter if the traffic is coming directly from a device or a device connected to another switch/AP/router first.

I may have erred, but I really don't think so. What you say makes sense but I followed @bennor's advice in his post (to which I referred in mine) to follow the ASUS advice for SDNs, putting a managed switch in between the Node and the Router. I followed that FAQ very closely and tried many settings. I concluded it did noy work (wiht Ethernet clients plugged into the node) unless BOTH Router and Node had FW that supported GNP; not JUST the Router.

I'm no expert on this stuff, I just follow directions and report my findings. I would be very, very happy if someone tried it with a GNP Primary and put a managed Switch in between that and a non-GNP node and got it to work.

"Conditions:
1. Check your device, this FAQ is for ExpertWiFi series or selected models with Guest network pro feature. "

If getting node-connected clients to receive an address from a Guest Network Pro IP block requires you to get into the main router and edit files I'd argue that node does not, in fact, support Guest Network Pro as designed. A fully supported GNP on AiMesh nodes means a wireless client can be configured to connect to the GNP-defined SSID and get an IP from the associated IP block automatically regardless if it's connecting to the main router or any AiMesh nodes. As you can see, the OP is saying any wireless client connecting to a node is NOT getting an IP from the 52.x block when connecting to the GNP-defined SSID. Yes, he may be able to manually assign via MAC either through the method you outlined or manually on the main router itself but it's not working as intended as defined by Asus.

Agree; and it works (per @visortgw feedback) if both Primary and Nodes are on 3006 and support VLANs.

 

[Seth Harman]

It's a very simple thing to plug the Ethernet backhaul from a node into a managed switch port, configure the switch to tag all traffic coming into that port with a particular VLAN tag, and then send that traffic on to the router. I'm not sure what you were originally trying to accomplish but that guide doesn't describe that scenario.

And yes, my point is it would appear the OPs nodes are running 3004 and they do not natively support GNP. It may be possible as suggested to force the relevant MAC addresses into the 52.x IP block at the main router (which would solve the OPs problem if it works) but the way GNP is intended to operate just isn't going to work unless the nodes are replaced with nodes that support 3006.

 

[Tech9]

the way GNP is intended to operate just isn't going to work unless the nodes are replaced with nodes that support 3006

This is exactly the expected behavior for both Guest Network Pro and Network configuration methods in 3006 main routers to 3006 nodes. Anything else is not guaranteed to work, but Asus continues to sell devices with general AiMesh Compatible advertisement without specifying what exactly is compatible. Users have to figure it out themselves.

 

[Seth Harman]

This is exactly the expected behavior for both Guest Network Pro and Network configuration methods in 3006 main routers to 3006 nodes. Anything else is not guaranteed to work, but Asus continues to sell devices with general AiMesh Compatible advertisement without specifying what exactly is compatible. Users have to figure it out themselves.

Yep, which is a hot mess in my opinion. We've fleshed out some general guidelines in various threads about what configuration/hardware you need for GNP and Ethernet-port VLAN tagging at the nodes but Asus really needs to get it together in regards to explaining it all in their marketing materials.

 

[Tech9]

explaining it all in their marketing materials

I don't see it happening because what AiMesh does best is selling more routers to existing customers and AiMesh Compatible marketing fits the plan better. If you know in advance your old routers won't be fully compatible you may want to look at something else.

 

[Seth Harman]

I don't see it happening because what AiMesh does best is selling more routers to existing customers and AiMesh Compatible marketing fits the plan better. If you know in advance your old routers won't be fully compatible you may want to look at something else.

Maybe, but I think what they need to make more clear is general AiMesh compatibility and AiMesh+GNP are two different animals. In fact, I'd argue if they made it clear AiMesh+GNP full compatibility requires a certain hardware/firmware combination it may motivate people to upgrade their hardware if they specifically want that. What's happening instead is even reasonably-technical people are left scratching their heads wondering why it doesn't work like they thought it was supposed to.

 

[Tech9]

what they need to make more clear is general AiMesh compatibility

I'm asking for official AiMesh compatibility table for some time, but all we have available so far is user experience. I know Asus employees stop by SNB Forums and some even have user accounts, used to offer beta firmware. The AiMesh combinations are quite a few and GNP is only one of them. Newer BE-class routers on 3006 >37xxx firmware version don't have GNP anymore (Network), some BE-class on 3006 don't have VLAN support (Smart Home), AX(E)-class on 3006 still use GNP perhaps temporary, 3004.386 for AC-class is EoL with GN1 propagation only, 3004.388 for supported devices is a hit and miss situation, some 3004.388 AX-class got to EoL as well.

 

[Tech9]

even reasonably-technical people are left scratching their heads

Add 3006 branch bugs to the equation...

 

[Seth Harman]

Newer BE-class routers on 3006 >37xxx firmware version don't have GNP anymore (Network)

I saw that, as if there wasn't enough confusion. That being said, isn't "Network" just a renamed GNP?

 

[Tech9]

That being said, isn't "Network" just a renamed GNP?

Since most devices on 3006 are VLAN capable I believe Asus is switching to the more common network setup logic usually found in SMB hardware. You first define a network with its properties and then attach ports and radios to it. The ports and radios can be on another device, not necessarily the one acting as router. This network can serve different purposes, not necessarily for guests. ExpertWiFi UI for example is close to what I have on UniFi. The main issue remains compatibility. With Asus - the same devices and firmware.

 

[jksmurf]

It's a very simple thing to plug the Ethernet backhaul from a node into a managed switch port, configure the switch to tag all traffic coming into that port with a particular VLAN tag, and then send that traffic on to the router. I'm not sure what you were originally trying to accomplish but that guide doesn't describe that scenario.

Not being facetious here, but have you actually tried this (insert a managed switch between primary and nodes and assign tagging) yourself with an AIMesh Node to see what subnet IPs are assigned to devices attached to the Nodes Ethernet Ports, with a 3006/3004 pair?

I would be very happy if I made a mistake with my managed switch trial (using ASUS FAQ) and it indeed worked, as in my remote location I have 3 such nodes and I would love to have a managed switch between them and the router do what VLAN capable, 3006 Nodes can do (as configured in the primary router, see @visortgw example). i.e. the managed switch replicates or mimics that behaviour.

What I was trying to achieve is documented in my original posts, simply that a device connected to a Node’s Ethernet port gets assigned a VLAN tag of (in my case) the IoT (53) Network. I could not get that to work with a 3006 Primary / 3004 Node, with a managed switch between them.

And yes, my point is it would appear the OPs nodes are running 3004 and they do not natively support GNP. It may be possible as suggested to force the relevant MAC addresses into the 52.x IP block at the main router (which would solve the OPs problem if it works) but the way GNP is intended to operate just isn't going to work unless the nodes are replaced with nodes that support 3006.

I would agree on this, although the use of dnsmasq is simply for convenience of assigned names for Wi-Fi clients (it does not work for, nor did I intend it to), Ethernet devices. There is no forcing of subnets here. The dnsmasq-x.conf.add simply replicates the manual assignments facility built in to GNP, but permits more than 32 devices (and does not run out of memory).

 

[Seth Harman]

Not being facetious here, but have you actually tried this (insert a managed switch between primary and nodes and assign tagging) yourself with an AIMesh Node to see what subnet IPs are assigned to devices attached to the Nodes Ethernet Ports, with a 3006/3004 pair?

Yes. But I'm suspecting the disconnect here is you might believe I'm trying to describe a setup where you can connect the node backhaul to one of the ports on a managed switch and have it deal with VLAN tagging for multiple IDs like GNP does and that's not possible. A managed switch configured to VLAN tag by port can only add a single ID onto all traffic coming into a given Ethernet port. So, for example, if you run the backhaul from a node into a managed switch and set that port to VLAN tag ID 52 every single device connecting to that node (wired or wireless) will end up tagged with ID 52 because all traffic going out the backhaul will pass through the managed switch and it will tag all of those packets with the ID you've chosen. In the OPs case he'd have to bind all his IoT clients to that node and tag all the traffic coming out of it and then bind all other wireless clients to another node or the main router (which basically defeats the purpose of AiMesh in the first place even though it would work). If I were the OP I'd convert one of the AiMesh nodes to a regular AP with a different SSID, have all the IoT clients connect to it, then connect the AP backhaul to the managed switch and tag all the traffic with ID 52. Obviously the success of this would depends on whether all the IoT clients can reach that AP with good signal and he doesn't specifically need that node to also support non-IoT clients. In my opinion the real use case for a managed switch is where your nodes support GNP but not Ethernet VLAN tagging and you want to bind wired clients to a specific GNP instance; by plugging those wired clients into the managed switch instead you can accomplish this and it doesn't matter if the managed switch is between the node and the main router or plugs into the node (this is the setup I'm currently using at home because my nodes support GNP but not Ethernet VLAN tagging).