What's new

ASUS AC-86U Vlan Utility

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

sroghen

New Around Here
Interesting VLAN Utility on ASUS Router I found while trying to figure out how to create a VLAN Trunk to my managed switch.

Update: Pointed out its already known.....oh well.

admin@RT-AC86U-8A70:/tmp/home/root# vlanctl -h


VLAN Control Utility:

::: Usage:

vlanctl

--if <if_name> Sets the target Interface of a composite vlanctl command to <if_name>.

--rx Sets the direction of a composite vlanctl command to RECEIVE

--tx Sets the direction of a composite vlanctl command to TRANSMIT

--tags <nbr_of_tags> Sets the number of tags of a composite vlanctl command to <nbr_of_tags>

--if-create <real_if_name> <if_index> Creates a new VOPI named <real_if_name>.v<if_index> and attaches it to the real device
<real_if_name>. For instance, if this command were executed for the eth0 real interface and the VOPI interface index were
set to 3, the resulting interface would have been named eth0.v3.

--if-create-name <real_if_name> <vlan_if_name> Creates a new VOPI named <vlan_if_name> and attaches it to the real device

--if-delete <vlan_if_name> Destroy the VOPI named <vlan_if_name>.

--rule-append Inserts a new Tagging Rule as the last rule of the specified Tagging Rule Table. Dependencies: --if, --rx or
--tx, and --tags.

--rule-insert-before <rule-id> Inserts a new Tagging Rule before the Tagging Rule whose identifier matches <rule-id> in the
specified Tagging Rule Table. Dependencies: --if, --rx or --tx, and --tags.

--rule-insert-after <rule-id> Inserts a new Tagging Rule after the Tagging Rule whose identifier matches <rule-id> in the
specified Tagging Rule Table. Dependencies: --if, --rx or --tx, and --tags.

--rule-remove <rule-id> Removes the Tagging Rule that matches <rule-id> from the specified Tagging Rule Table. Dependencies:
--if, --rx or --tx, and --tags.

--rule-remove-all <real_if_name> <vlan_if_name> Removes all the Tagging Rules for the vlan device.

--show-table Lists all Tagging Rules stored in the specified Tagging Rule Table. Dependencies: --if, --rx or --tx, and
--tags.

--default-tpid <tpid> Sets the default TPID value of a tagging rule table to <tpid>. When a table is created, its default
TPID value is set to 0x8100. Dependencies: --if, --rx or --tx, and --tags.

--default-pbits <pbits> Sets the default PBITS value of a tagging rule table to <pbits>. When a table is created, its
default PBITS value is set to 0. Dependencies: --if, --rx or --tx, and --tags.

--default-cfi <cfi> Sets the default CFI value of a tagging rule table to <cfi>. When a table is created, its default CFI
value is set to 0. Dependencies: --if, --rx or --tx, and --tags.

--default-vid <vid> Sets the default VID value of a tagging rule table to <vid>. When a table is created, its default VID
value is set to 1 (as per IEEE 802.1Q). Dependencies: --if, --rx or --tx, and --tags.

--cfg-dscp2pbits <dscp> <pbits> Programs the entry number <dscp> of the DSCP-TO-PBITS translation table of a Real Device to
the value specified by <pbits>. When a tagging rule table is created, the default values of the DSCP-TO-PBITS table are
set by copying the lowest 3 bits of each DSCP value as the PBITS value, for each entry in the table. For instance, the
following entries are programmed by default: DSCP=5:pBITS=5, DSCP=15:pBITS=7, etc. The DSCP-TO-PBITS translation table
has 64 entries. Dependencies: --if.

--show-dscp2pbits Lists the values programmed in the DSCP-TO-PBITS table of the specified Real Device. Dependencies:
--if.

--cfg-tpid <tpid0> <tpid1> <tpid2> <tpid3> Configures the TPID Table entries of a given Real Interface. The configured
TPID values are used to identify VLAN Headers of packets received from and transmitted to the VOPIs created for a given
Real Interface. Four values must always be specified. The default TPID values are 0x8100, 0x8100, 0x8100, and 0x8100.
Dependencies: --if.

--show-tpid Lists the values programmed in the TPID Table of the specified Real Device. Dependencies: --if.

--local-stats <vlan_if_name> Shows the statistics counters maintained for the VOPI named <vlan_if_name>. These counters
are complimentary to the standard counters maintained for the device, which can be read via the Linux ifconfig
command.

--filter-ethertype <ethertype> Match the Ethertype field in the Ethernet Header of incoming frames against <ethertype>.

--filter-pbits <pbits> <tag_nbr> Match the PBITS value of VLAN Header number <tag_nbr> of incoming frames against
<pbits>.

--filter-cfi <cfi> <tag_nbr> Match the CFI bit of VLAN Header number <tag_nbr> of incoming frames against <cfi>.

--filter-vid <vid> <tag_nbr> Match the VID value of VLAN Header number <tag_nbr> of incoming frames against <vid>.

--filter-tag-ethertype <ethertype> <tag_nbr> Match the Ethertype field of the VLAN Header number <tag_nbr> of incoming
frames against <ethertype>.

--filter-dscp <dscp> Match the DSCP value in the IPv4 header of incoming frames against <dscp>.
--filter-rxif <real_if_name> Match the rx VOPI of the transmitting packet against <real-if-name>. This filter can be used to bind a Tagging
Rule to a specific rx VOPI on the TRANSMIT direction. This filter is not applicable for rules in the RECEIVE direction.

--filter-txif <vlan_if_name> Match the transmitting VOPI against <vlan-if-name>. This filter can be used to bind a Tagging
Rule to a specific VOPI on the TRANSMIT direction. This filter is not applicable for rules in the RECEIVE direction.
TRANSMIT rules without this filter will apply to all frames transmitted from all VOPIs attached to the Real Device.
 
Last edited:
--filter-skb-prio <priority> Match the SKB priority of incoming frames against <priority>.

--filter-skb-mark-flowid <flowid> Match the Flow ID subfield of the SKB Mark field against <flowid>. The SKB Mark Flow ID
subfield can be used as a way to correlate packet classification made by other Linux modules (such as ebtables and
iptables) with Tagging Rules. A possible usage for this filter would be to direct packets generated by an application to
a specific port of a real interface (such as a GPON port) based on layer 3 filters. In this example a socket would be
created on a VOPI,IP Tables rules would be created to identify flows and set Flow IDs, and Tagging rules would be
created to match on such Flow IDs and apply treatments, such as setting the destination GEM Port and Queue.

--filter-skb-mark-port <port> Match the Port subfield of the SKB Mark field against <port>. This filter can be used to bind
certain Tagging Rules with a specific Real Interface port (for instance a GPON Port).

--filter-vlan-dev-mac-addr <ignore_if_multicast> Match the recv frame dest MAC addr against the recv virtual interface.
Set <ignore_if_multicast> to 0 to apply filter on all recv frames.
Set <ignore_if_multicast> to 1 to apply filter on unicast frames only.
This filter is not applicable for rules in the TRANSMIT direction.

--pop-tag Remove the outermost VLAN tag. If multiple tags are to be removed, this treatment should be specified for each
VLAN tag to be removed.

--push-tag Add the default VLAN tag of the corresponding Tagging Rule Table as the new outer tag. The default TPID value
will be used as the new Ethertype value in the Ethernet header, the existing Ethertype of the Ethernet Header will be used
as the Tag Ethertype field of the new tag, and the default PBITS, CFI and VID will be used as the TCI of the new tag. If
multiple tags are to be inserted, this treatment must be specified for each VLAN tag to be inserted.

--set-ethertype <ethertype> Set the Ethertype value of the Ethernet Header to <ethertype>.

--set-pbits <pbits> <tag_nbr> Set the PBITS value of the VLAN Header number <tag_nbr> to <pbits>.

--set-cfi <cfi> <tag_nbr> Set the CFI bit of the VLAN Heade number <tag_nbr> to <cfi>.

--set-vid <vid> <tag_nbr> Set the VID of the VLAN Header number <tag_nbr> to <vid>.

--set-tag-ethertype <ethertype> Set the Ethertype field of the VLAN Header number <tag_nbr> to <ethertype>.

--set-dscp <dscp> Set the IPv4 DSCP value of the matching frame to <dscp>.

--copy-pbits <from_tag_nbr> <to_tag_nbr> Copy the PBITS value from VLAN Header number <from_tag_nbr> to VLAN Header number
<to_tag_nbr>.

--copy-cfi <from_tag_nbr> <to_tag_nbr> Copy the CFI value from VLAN Header number <from_tag_nbr> to VLAN Header number
<to_tag_nbr>.

--copy-vid <from_tag_nbr> <to_tag_nbr> Copy the VID value from VLAN Header number <from_tag_nbr> to VLAN Header number
<to_tag_nbr>.

--copy-tag-ethertype <from_tag_nbr> <to_tag_nbr> Copy the Ethertype value from VLAN Header number <from_tag_nbr> to VLAN
Header number <to_tag_nbr>.

--dscp2pbits <tag_nbr> Translate the IPv4 DSCP into a PIBTS value, and write the translated PBITS value in the VLAN Header
number <tag_nbr>. The DSCP-To-PBITS table of the respective Real Device is used for translation.

--set-rxif <vlan_if_name> Forward frames in the RECEIVE direction that match this rule to the VOPI specified in
<vlan_if_name>. If not specified, the frame will be forwarded to a randomly chosen VOPI. Using this treatment in the
TRANSMIT direction has no effect.

--set-if-mode-ont Set real device mode to ONT.

--set-if-mode-rg Set real device mode to RG.

--drop-frame Drop the matching frame.
--set-skb-prio <priority> Set the SKB priority to <priority>.

--set-skb-mark-port <port> Set the Port subfield of the SKB Mark field to <port>. The SKB Mark Port subfield is used by
the Broadcom device drivers to send a frame to a specific port within a Real Interface. For instance, a GPON Real
Interface may have been configured with multiple GEM Ports. When a packet is sent to that interface, the driver uses
the SKB Mark Port subfield as the GEM Port to which the packets will be transmitted.

--set-skb-mark-queue <queue> Set the Queue subfield of the SKB Mark field to <queue>. The SKB Mark Queue subfield is used
by the Broadcom device drivers to determine the queue to which transmit a frame.

--set-skb-mark-flowid <flowid> Set the Flow ID subfield of the SKB Mark field to <flowID>. The SKB Mark Flow ID subfield
can be used as a way to correlate packet classification made by Tagging Rules with other Linux modules (such as
ebtables and iptables).

--rule-type <type> set the type of rule. 0: flow; 1: qos;

--create-flows <rx_vlan_ifname> <tx_vlan_ifname> Setup vlan flows for the path (rx_vlan_ifname->tx_vlan_ifname).

--delete-flows <rx_vlan_ifname> <tx_vlan_ifname> Remove vlan flows for the path (rx_vlan_ifname->tx_vlan_ifname).

admin@RT-AC86U-8A70:/tmp/home/root#
 
As I am playing around on my AC86, a few commands to note,

Code:
#create vlan 40 on eth1
vconfig add eth1 40

#del vlan 40
vconfig rem vlan40

#Activate and add an IP address to vlan40 link, type:
ip addr add 192.168.40.2/24 brd 192.168.1.255 dev vlan40
ip link set dev vlan40 up

#checking whether it is correctly setup
cat /proc/net/vlan/vlan40


vlan40  VID: 40  REORDER_HDR: 1  dev->priv_flags: 4401
         total frames received            9
          total bytes received          933
      Broadcast/Multicast Rcvd            0

      total frames transmitted            0
       total bytes transmitted            0
Device: eth1
INGRESS priority mappings: 0:0  1:0  2:0  3:0  4:0  5:0  6:0 7:0
 EGRESS priority mappings:


#check for whether vlan40 is up
ifconfig


vlan40    Link encap:Ethernet  HWaddr 4C:ED:FB:90:8A:70
          inet addr:192.168.40.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:633 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13904 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:134275 (131.1 KiB)  TX bytes:18965713 (18.0 MiB)
 
Last edited:
As I am playing around on my AC86, a few commands to note,
Code:
#create vlan 40 on eth1
vconfig add eth1 40

#del vlan 40
vconfig rem vlan40

#Activate and add an IP address to vlan40 link, type:
ip addr add 192.168.40.2/24 brd 192.168.1.255 dev vlan40
ip link set dev vlan40 up

<snip>

The method to create a VLAN subnet hasn't changed on the RT-AC86U, but the ability to create a Tagged (Trunk) or un-Tagged switch port has.

So the RT-AC68U's 'robocfg' commands need to be translated to equivalent RT-AC86U 'vlanctl' commands.

Back at the end of January I did attempt to use 'vlanctl' to create a simple basic un-Tagged interface on Switch Port 1 for VLAN10

i.e. Check if VLANs are configured on Port 1
Code:
vlanctl --if eth4 --rx --tags 0 --show-table

[ERROR vlan] bcmVlan_dumpTagRulesByTable,2640: Real Device eth4 has no VLAN Interfaces
[ERROR vlan] vlanIoctl ,843: Failed to dump Rule Table from eth4 (tags=0, dir=0)
After creating VLAN10, it is ONLY receiving data on the Port...but at the moment my aim is to understand (ahem..reverse-engineer:p) the 'vlanctl' utility.
Code:
vlan10    Link encap:Ethernet  HWaddr 40:B0:76:37:61:60
          inet addr:192.168.10.2  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:358 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0
          RX bytes:64999 (63.4 KiB)  TX bytes:0 (0.0)


ping 192.168.10.2

PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: seq=0 ttl=64 time=0.143 ms
64 bytes from 192.168.10.2: seq=1 ttl=64 time=0.063 ms
64 bytes from 192.168.10.2: seq=2 ttl=64 time=0.075 ms

So now a recheck on Port 1 for VLANs
Code:
vlanctl --if eth4 --tx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Tx, nbrOfTags 0, default ACCEPT
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : TX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : DEFAULT
kernel: Filters
kernel:  Rx REALIF       :
kernel:  Tx VLANIF       : vlan10
kernel: Commands
kernel:  00:[NOP, 0x00000000, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 0
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --rx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 0, default DROP
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : vlan10
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x0000000A, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 358
kernel: --------------------------------------------------------------------------------

Success...well sort of:confused:

So for an un-tagged port I think the two 'vlanctl' rules (PUSH_TAG/SET_VID) applied to the VLAN10 Rx may need similar rules for the VLAN Tx, or more than likely I am missing additional rules to include the CPU in the VLAN (as used by the 'robocfg' directives)

NOTE: Apparently there are specific VLAN rule tables similar to 'iptables/ebtables', and it seems that for each VLAN created, there are actually 4 pairs of rule tables:
Code:
vlanctl --if eth4 --tx --tags 3 --show-table
 
kernel: VLAN Rule Table : eth4, Tx, nbrOfTags 3, default ACCEPT
kernel: No entries found
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --rx --tags 3 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 3, default DROP
kernel: No entries found
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --tx --tags 2 --show-table
 
kernel: VLAN Rule Table : eth4, Tx, nbrOfTags 2, default ACCEPT
kernel: No entries found
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --rx --tags 2 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 2, default DROP
kernel: No entries found
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --tx --tags 1 --show-table

kernel: VLAN Rule Table : eth4, Tx, nbrOfTags 1, default ACCEPT
kernel: No entries found
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --rx --tags 1 --show-table
 
kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 1, default DROP
kernel: No entries found
kernel: --------------------------------------------------------------------------------

For a Tagged (Trunk) Port I'm not sure if there is a magic setting, but if you only have a few known downstream VLANs on your managed VLAN capable switch(es) it appears you can simply explicitly add additional VLANs to the same switch port
e.g. Port 1 now hosts two VLANs, VLAN10 and VLAN101
Code:
vlanctl --if eth4 --rx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 0, default DROP
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : vlan10
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x0000000A, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 358
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 1
kernel: Rx VLAN Device : vlan101
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x00000065, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 0
kernel: --------------------------------------------------------------------------------
That's about as far as I got with my brief attempt to port my VLANSwitch.sh script, but it could be that simply setting an NVRAM variable is all that it takes to trigger the complete list of necessary 'vlanctl' (ethctl/ethswctl?) commands?

I will update the thread if/when I can revisit this (time permitting etc.).
 
Last edited:
The method to create a VLAN subnet hasn't changed on the RT-AC86U, but the ability to create a Tagged (Trunk) or un-Tagged switch port has.

So the RT-AC68U's 'robocfg' commands need to be translated to equivalent RT-AC86U 'vlanctl' commands.

Back at the end of January I did attempt to use 'vlanctl' to create a simple basic un-Tagged interface on Switch Port 1 for VLAN10

i.e. Check if VLANs are configured on Port 1
Code:
vlanctl --if eth4 --rx --tags 0 --show-table

[ERROR vlan] bcmVlan_dumpTagRulesByTable,2640: Real Device eth4 has no VLAN Interfaces
[ERROR vlan] vlanIoctl ,843: Failed to dump Rule Table from eth4 (tags=0, dir=0)
After creating VLAN10, it is ONLY receiving data on the Port...but at the moment my aim is to understand (ahem..reverse-engineer:p) the 'vlanctl' utility.
Code:
vlan10    Link encap:Ethernet  HWaddr 40:B0:76:37:61:60
inet addr:192.168.10.2  Bcast:192.168.1.255  Mask:255.255.255.0
UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
RX packets:358 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:64999 (63.4 KiB)  TX bytes:0 (0.0)


ping 192.168.10.2

PING 192.168.10.2 (192.168.10.2): 56 data bytes
64 bytes from 192.168.10.2: seq=0 ttl=64 time=0.143 ms
64 bytes from 192.168.10.2: seq=1 ttl=64 time=0.063 ms
64 bytes from 192.168.10.2: seq=2 ttl=64 time=0.075 ms

So now a recheck on Port 1 for VLANs
Code:
vlanctl --if eth4 --tx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Tx, nbrOfTags 0, default ACCEPT
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : TX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : DEFAULT
kernel: Filters
kernel:  Rx REALIF       :
kernel:  Tx VLANIF       : vlan10
kernel: Commands
kernel:  00:[NOP, 0x00000000, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 0
kernel: --------------------------------------------------------------------------------

vlanctl --if eth4 --rx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 0, default DROP
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : vlan10
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x0000000A, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 358
kernel: --------------------------------------------------------------------------------

Success...well sort of:confused:

So for an un-tagged port I think the two 'vlanctl' rules (PUSH_TAG/SET_VID) applied to the VLAN10 Rx may need similar rules for the VLAN Tx, or more than likely I am missing additional rules to include the CPU in the VLAN (as used by the 'robocfg' directives)

For a Tagged (Trunk) Port I'm not sure if there is a magic setting, but if you only have a few known downstream VLANs on your managed VLAN capable switch(es) it appears you can simply explicitly add additional VLANs to the same switch port
e.g. Port 1 now hosts two VLANs, VLAN10 and VLAN101
Code:
vlanctl --if eth4 --rx --tags 0 --show-table

kernel: VLAN Rule Table : eth4, Rx, nbrOfTags 0, default DROP
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 0
kernel: Rx VLAN Device : vlan10
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x0000000A, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 358
kernel: --------------------------------------------------------------------------------
kernel: ===> eth4 (ONT) : RX, 0 tag(s)
kernel: Tag Rule ID : 1
kernel: Rx VLAN Device : vlan101
kernel: Filters
kernel:  VlanDev MacAddr : No
kernel: Commands
kernel:  00:[PUSH_TAG, 0x00008100, 0x00000001]
kernel:  01:[SET_VID, 0x00000065, 0x00000000]
kernel: Rule Type  : Flow
kernel: Hit Count   : 0
kernel: --------------------------------------------------------------------------------
That's about as far as I got with my brief attempt to port my VLANSwitch.sh script, but it could be that simply setting an NVRAM variable is all that it takes to trigger the complete list of necessary 'vlanctl' (ethctl/ethswctl?) commands?

I will update the thread if/when I can revisit this (time permitting etc.).
Can you share the VlanSwitch.sh
My aim is to create a trunk between my ASUS router and a managed Netgear switch. I only have 2 vlans + native vlan.
 
Can you share the VlanSwitch.sh
My aim is to create a trunk between my ASUS router and a managed Netgear switch. I only have 2 vlans + native vlan.

As I haven't managed to identify the complete sequence of 'vlanctl' commands to successfully configure VLANs on the RT-AC86U, my VLANSwitch.sh script only works for the following non-HND routers

e.g.
RT-N66U|RT-AC56U|RT-AC68U|RT-AC5300|RT-AC66U_B1|RT-AC3200

so sadly is of no use on your RT-AC86U.
 
As I haven't managed to identify the complete sequence of 'vlanctl' commands to successfully configure VLANs on the RT-AC86U, my VLANSwitch.sh script only works for the following non-HND routers

e.g.
RT-N66U|RT-AC56U|RT-AC68U|RT-AC5300|RT-AC66U_B1|RT-AC3200

so sadly is of no use on your RT-AC86U.

Understood.
My apologies if i misunderstood our earlier post, but it sounds like for a trunk port, i only need to create the vlans on the target asus port.
Do i need any additional vlanctl command ?

Update: Just found another post where this is mentioned. I guess for native vlan 1, there is nothing to configure for trunk port, since it is untagged.

# Ethernet port#4 on the router is a trunk for a managed switch with vlan14
vlanctl --mcast --if-create-name eth1 vlan14
vlanctl --if eth1 --rx --tags 0 --set-rxif vlan14 --rule-append
vlanctl --if eth1 --tx --tags 0 --filter-txif vlan14 --rule-append
ifconfig vlan14 allmulti up

# how to delete it
ifconfig vlan14 allmulti down
vlanctl --if-delete vlan14

On theRT-AC86U, Ethernet port#4 is actually called "eth1" in the firmware, so beware the Ethernet ports are numbered backwards.
 
Last edited:
Is there any progress here? I am trying to create VLANS on the AX88U and I am trying not to revert to using an old router and DD-WRT to do it.

My current setup and what I am trying to do:

Current setup:
RT-AX88U router --AIMESH--> RT-AX88U AP ->Wired IOT devices (192.168.1.0/24)
|
GuestWireless ->Wireless IOT devices (isolated on 192.168.2.0/24)

I love the router capabilities and Asusmerlin is the best. I want to keep this setup, but I am having real security concerns and am unable to segment wired IOT units (wireless are under guest isolation and YazFi's script - thanks!). I have a Phillips wired hub and Ring hardwired cameras and other wired IOT units on my LAN, and I want separation.

I have been looking everywhere and reading all the posts about vlanctl being the replacement for robocfg, but I can't find instructions on how to create the following setup:

Desired setup:
RT-AX88U router --AIMESH--> RT-AX88U AP
|
Guest Wireless ->wireless IOT devices
(isolated on 192.168.2.0/24)
+
Wired IOT Devices
(isolated on 192.168.2.0/24)

Given I don't know if there is a way to create VLANs on the AX88U, I am wondering if there is another way to get separation for the MAC addresses on the same subnet so they cannot access the LAN. I have a hunch that using Static Routes may work or iptables might be a solution. I don't have enough technical knowledge to know the best route and there may be some advice out there that I am missing. I know this is an issue lots are trying to figure out, so I hope there is a quick link or easy advice out there. Thanks for bearing with me on this one.

As a final note, I have even considered reverting back to my WRT3200 router and setting up VLANS there and using the AX88Us as access points, as an absolute last resort or purchasing a Ubiquiti Edgerouter 4 to make the VLANS. At that point, I am trying to find a hardware solution to a software problem. Please help. Thanks.
 
Last edited:
If your concern is primarily Ethernet wired devices instead of spending big dollars on another router if you can't get the VLANs working on your router consider purchasing an inexpensive smart switch for US$25-35 which will let you set up multiple VLANs using the switch's GUI. In addition to VLANs these switches also provide some other useful options.
 
Is there any progress here? I am trying to create VLANS on the AX88U and I am trying not to revert to using an old router and DD-WRT to do it.

My current setup and what I am trying to do:

Current setup:
RT-AX88U router --AIMESH--> RT-AX88U AP ->Wired IOT devices (192.168.1.0/24)
|
GuestWireless ->Wireless IOT devices (isolated on 192.168.2.0/24)

I love the router capabilities and Asusmerlin is the best. I want to keep this setup, but I am having real security concerns and am unable to segment wired IOT units (wireless are under guest isolation and YazFi's script - thanks!). I have a Phillips wired hub and Ring hardwired cameras and other wired IOT units on my LAN, and I want separation.

I have been looking everywhere and reading all the posts about vlanctl being the replacement for robocfg, but I can't find instructions on how to create the following setup:

Desired setup:
RT-AX88U router --AIMESH--> RT-AX88U AP
|
Guest Wireless ->wireless IOT devices
(isolated on 192.168.2.0/24)
+
Wired IOT Devices
(isolated on 192.168.2.0/24)

Given I don't know if there is a way to create VLANs on the AX88U, I am wondering if there is another way to get separation for the MAC addresses on the same subnet so they cannot access the LAN. I have a hunch that using Static Routes may work or iptables might be a solution. I don't have enough technical knowledge to know the best route and there may be some advice out there that I am missing. I know this is an issue lots are trying to figure out, so I hope there is a quick link or easy advice out there. Thanks for bearing with me on this one.

As a final note, I have even considered reverting back to my WRT3200 router and setting up VLANS there and using the AX88Us as access points, as an absolute last resort or purchasing a Ubiquiti Edgerouter 4 to make the VLANS. At that point, I am trying to find a hardware solution to a software problem. Please help. Thanks.
Hi,

Please, did you solve it?
I have found this info and ai think maybe it wil be helpfull:
Code:
No robocfg?
The first problem is that robocfg is no more provided on AX88U (Broadcom’s HND platform). An alternative to robocfg on HND platform seems to be vlanctl2. However, after several hours of searching, trying and error, I believe vlanctl can only create tagged VLAN, which unfortunately can’t satisfy my need.

Source:
LAN port isolation (port-based VLAN) on ASUS RT-AX88U with Asuswrt-Merlin 384.16
Approach with Separate Bridge

Good luck!
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top