My recent VLAN fiasco

paradigmatic · Thu Mar 20, 2025 9:58 am

I attempted adding VLANs to a perfectly working network, centered on a RB5009 router. My goal is to add two additional "zones" as DMZ and for testing non-trusted devices (cheap wifi IoT gadgets).

I tried following the guides and reading the mikrotik doc and produced the config below. If I set vlan_filtering=yes the network becomes unreliable AND I am not able to access the internet. If I set vlan_filtering=no, the network is just unreliable but the outside world works well. By unreliable I mean: weird time-outs, connection fail randomly, some certificates are no more accessible, etc.

Here is the config (expunged from static DHCP leases and static DNS entries:

# 2025-03-19 11:39:56 by RouterOS 7.17.2
# software id = THI6-PU2R
#
# model = RB5009UPr+S+
# serial number = HG909SZ149B
/interface bridge
add admin-mac=D4:01:C3:5E:BC:A3 auto-mac=no comment=defconf name=bridge \
    port-cost-mode=short protocol-mode=none
/interface ethernet
set [ find default-name=ether2 ] l2mtu=1500 poe-out=off
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface vlan
add interface=bridge mtu=1496 name=BASE vlan-id=10
add interface=bridge mtu=1496 name=DMZ vlan-id=42
add interface=bridge mtu=1496 name=JAIL vlan-id=66
/interface list
add name=WAN
add name=LAN
/ip pool
add name=BASE_POOL ranges=10.9.9.100-10.9.9.254
add name=DMZ_POOL ranges=10.9.42.2-10.9.42.254
add name=JAIL_POOL ranges=10.9.66.2-10.9.66.254
/ip dhcp-server
add address-pool=BASE_POOL interface=BASE lease-time=1d name=BASE_DHCP
add address-pool=DMZ_POOL interface=DMZ name=DMZ_DHCP
add address-pool=JAIL_POOL interface=JAIL name=JAIL_DHCP
/interface bridge port
add bridge=bridge interface=ether1 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether2 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether3 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether4 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether5 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge interface=ether6 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether7 internal-path-cost=10 path-cost=10 pvid=42
add bridge=bridge frame-types=admit-only-untagged-and-priority-tagged \
    interface=ether8 internal-path-cost=10 path-cost=10 pvid=42
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface bridge vlan
add bridge=bridge comment=Base tagged=bridge,ether1,ether6 untagged=\
    ether2,ether3,ether4,ether5 vlan-ids=10
add bridge=bridge comment=DMZ tagged=bridge,ether1,ether6 untagged=\
    ether7,ether8 vlan-ids=42
add bridge=bridge comment=Jail tagged=bridge,ether1 vlan-ids=66
/interface list member
add interface=bridge list=LAN
add interface=sfp-sfpplus1 list=WAN
add interface=wireguard1 list=LAN
add interface=BASE list=LAN
/interface wireguard peers
add allowed-address=10.10.10.2/32 comment="XYZ" interface=\
    wireguard1 name=XYZ public-key=\
    "XYZ"
/ip address
add address=10.9.8.1/22 interface=bridge network=10.9.8.0
add address=10.10.10.1/24 comment=VPN interface=wireguard1 network=10.10.10.0
add address=10.9.8.1/22 interface=BASE network=10.9.8.0
add address=10.9.40.1/22 interface=DMZ network=10.9.40.0
add address=10.9.64.1/22 interface=JAIL network=10.9.64.0
/ip dhcp-client
add interface=sfp-sfpplus1
/ip dhcp-server network
add address=10.9.8.0/22 dns-server=10.9.8.1 gateway=10.9.8.1
add address=10.9.40.0/22 dns-server=10.9.40.1 gateway=10.9.40.1
add address=10.9.64.0/22 dns-server=10.9.64.1 gateway=10.9.64.1
/ip dns
set allow-remote-requests=yes cache-size=20480KiB
/ip dns adlist
add ssl-verify=no url=\
    https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Accept incoming wireguard" dst-port=\
    13231 protocol=udp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=accept chain=forward comment=\
    "Accept all wireguard incoming traffic" disabled=yes in-interface=\
    wireguard1 src-address=10.9.8.224/27
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment=VOIP dst-port=5060 in-interface-list=\
    WAN protocol=tcp to-addresses=10.9.11.3 to-ports=5060
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip smb shares
set [ find default=yes ] directory=pub
/ipv6 address
add address=::1 from-pool=general-pool6 interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=sfp-sfpplus1 pool-name=general-pool6 \
    request=prefix use-peer-dns=no
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/ipv6 nd
set [ find default=yes ] interface=bridge ra-interval=20s-1m
/system clock
set time-zone-name=Europe/Zurich
/system leds
set 0 leds=user-led type=off
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

What did I do wrong ? What could I improve ? Still new at RouterOS, so any criticism/help would be welcome. Thanks

NathanA · Thu Mar 20, 2025 10:11 am

You've got the right idea, and are very close.

Don't manually set "untagged" ports on your bridge VLANs. When you set a bridge port member PVID, it automatically/dynamically gets added as "untagged". Manually setting "untagged" just lets you force a VLAN to egress a port without tags even if it isn't the PVID for that port, and 99% of the time is the wrong choice for majority of people and use-cases.
Definitely don't set a bridge port PVID to also be the same as one of the tagged VLANs you want to trunk on that port! I'm sure this would result in undefined (and likely very bad) behavior. You did this twice: ether1 and ether6 are trunk ports, and you included VLAN 10 in the "tagged" list, but ALSO set VLAN 10 as the PVID for ports 1 and 6. Don't! Just leave PVID at 1, or at the VERY least make it an ID that you are NOT trying to trunk through that same port (use a junk VLAN-ID, though if you do that then you should also tag that junk/throwaway VLAN on 'bridge' as well, so that you can actually talk to the CPU/RouterOS/management over a port that has that set as PVID).

In short / in summary, the basic rule of thumb is: for any given port, a tagged VLAN should only be set by adding that port as "tagged" under Bridge > VLANs, but the one and only UNtagged VLAN for any given port should only be set by manipulating the PVID for that port under Bridge > Ports.

Also as an aside, there is absolutely no reason to set the MTU of your VLANs to 1496. Don't do that, either. The L2MTU of the ethernet interfaces can more than handle the additional 4 bytes for the VLAN tag / ethertype prefixed to each tagged frame.

paradigmatic · Thu Mar 20, 2025 10:45 am

In short / in summary, the basic rule of thumb is: for any given port, a tagged VLAN should only be set by adding that port as "tagged" under Bridge > VLANs, but the one and only UNtagged VLAN for any given port should only be set by manipulating the PVID for that port under Bridge > Ports.t

Thanks for your quick and clear answer ! I will correct my config and give it a try as soon as possible.

Also as an aside, there is absolutely no reason to set the MTU of your VLANs to 1496. Don't do that, either. The L2MTU of the ethernet interfaces can more than handle the additional 4 bytes for the VLAN tag / ethertype prefixed to each tagged frame.

I am pretty sure, I did not manually set those MTU. Is it possible that the value was adapted by RouterOS ? Should I explicitely set an MTU of 1500 ?

mkx · Thu Mar 20, 2025 1:19 pm

Also as an aside, there is absolutely no reason to set the MTU of your VLANs to 1496. Don't do that, either. The L2MTU of the ethernet interfaces can more than handle the additional 4 bytes for the VLAN tag / ethertype prefixed to each tagged frame.

I am pretty sure, I did not manually set those MTU. Is it possible that the value was adapted by RouterOS ? Should I explicitely set an MTU of 1500 ?

This is the source of your problem:

/interface ethernet
set [ find default-name=ether2 ] l2mtu=1500 poe-out=off

Unless there are very specific needs, it should not be necessary ever to change l2mtu settings on any of ports/interfaces.

anav · Thu Mar 20, 2025 1:34 pm

Well either you did monkey with the MTUs, and have forgotten OR someone else configured the router.

paradigmatic · Thu Mar 20, 2025 11:18 pm

This is the source of your problem:

/interface ethernet
set [ find default-name=ether2 ] l2mtu=1500 poe-out=off
Unless there are very specific needs, it should not be necessary ever to change l2mtu settings on any of ports/interfaces.

Indeed, I did some experiments on changing an MTU value and I forgot to remove the setting. I was not suspecting it could have such an influence on other ports and other settings. Thank you for spotting it.

mkx · Fri Mar 21, 2025 8:38 am

I was not suspecting it could have such an influence on other ports and other settings.

The chain of dependencies goes like this: L3MTU has to be lower than L2MTU with maximum possible size (L2MTU - additional L2 overhead). With plain ethernet, there's no additional L2 overhead and with standard IP MTU of 1500 bytes (which includes L3 headers), setting L2MTU to 1500 works.
If you add VLANs which introduce additional L2 overhead of 4 bytes (802.1Q header) things change. If you want to maintain L3MTU at 1500 bytes, then L2MTU has to increase by at least 4 bytes to 1504. If it's not increased, then L3MTU gets decreased to maximum possible value, in your (flawed) case that's 1500-4=1496 bytes.

Next: in bridged/switched environment all collaborating devices have to use same L3 MTU ... so that largest packets can be received by any device. If your bridged port is capable of supporting L3MTU of 1496, then bridge interface (the interface which allows ROS to communicate with devices in same IP subnet) can only have as big L3MTU. And ROS does set it automatically (as it should).

As I wrote in my previous post: one should mess with MTU values unless the need for it is clear and obvious. And that's true for both L2MTU and L3MTU. Further more, switch chips use available memory (most often part of ASIC itself, so it's not expandable) in certain optimally-sized chunks and size of those chunks differ between different switch chips. So it's generally best to leave setting at factory-default as long as it's large enough to support required L3MTU (even if it seems too big, like 1598 for plain VLANs with L3MTU of 1500).

paradigmatic · Mon Mar 24, 2025 2:01 pm

I corrected my config as suggested by NathanA and mkx (copied below), but I am still experiencing a lot of issues: some internet adresses are not reachable anymore. The effect seems to be random. For example google search is still accessible, but not the mikrotik forum.

I dont think is is a DNS issue. When pinging around, the DNS resolution is correct but all packet are lost. When forcing IPv6 the issues are worst.

I tried using a machine directly connected to a trunk port (since I still admit untagged packets) and most issues did not appear. Could it be a firewall problem ?

In the config I noticed something weird (at least for a beginner as myself). The bridge and the vlan BASE have the same IP. Is this expected ?

What step should I take to isolate the cause of the problem (instead of just whining in this nice forum) ?

# 2025-03-24 12:28:51 by RouterOS 7.17.2
#
# model = RB5009UPr+S+
/interface bridge
add admin-mac=D4:01:C3:5E:BC:A3 auto-mac=no comment=defconf name=bridge \
    port-cost-mode=short vlan-filtering=yes
/interface ethernet
set [ find default-name=ether2 ] poe-out=off
/interface wireguard
add comment="Roadwarrior VPN to LAN" listen-port=13231 mtu=1420 name=\
    wireguard1
/interface vlan
add interface=bridge name=BASE vlan-id=10
add interface=bridge name=DMZ vlan-id=42
add interface=bridge name=JAIL vlan-id=66
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip pool
add name=BASE_POOL ranges=10.9.9.100-10.9.9.254
add name=DMZ_POOL ranges=10.9.42.2-10.9.42.254
add name=JAIL_POOL ranges=10.9.66.2-10.9.66.254
/ip dhcp-server
add address-pool=BASE_POOL interface=BASE lease-time=1d name=LAN_DHCP
add address-pool=DMZ_POOL interface=DMZ name=DMZ_DHCP
add address-pool=JAIL_POOL interface=JAIL name=JAIL_DHCP
/interface bridge port
add bridge=bridge interface=ether1 internal-path-cost=10 path-cost=10
add bridge=bridge interface=ether2 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge interface=ether3 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge interface=ether4 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge interface=ether5 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge interface=ether6 internal-path-cost=10 path-cost=10
add bridge=bridge interface=ether7 internal-path-cost=10 path-cost=10 pvid=42
add bridge=bridge interface=ether8 internal-path-cost=10 path-cost=10 pvid=42
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1,ether6 vlan-ids=10
add bridge=bridge tagged=bridge,ether1,ether6 vlan-ids=42
add bridge=bridge tagged=bridge,ether1 vlan-ids=66
/interface list member
add interface=bridge list=LAN
add interface=sfp-sfpplus1 list=WAN
add interface=wireguard1 list=LAN
add interface=BASE list=LAN
/interface ovpn-server server
add mac-address=FE:78:80:A8:78:03 name=ovpn-server1
/interface wireguard peers
add allowed-address=10.10.10.2/32  interface=\
    wireguard1 name=XYZ public-key=XYZ
/ip address
add address=10.9.8.1/22 interface=bridge network=10.9.8.0
add address=10.10.10.1/24 comment=VPN interface=wireguard1 network=10.10.10.0
add address=10.9.8.1/22 interface=BASE network=10.9.8.0
add address=10.9.40.1/22 interface=DMZ network=10.9.40.0
add address=10.9.64.1/22 interface=JAIL network=10.9.64.0
/ip dhcp-client
add interface=sfp-sfpplus1
/ip dhcp-server lease
add address=10.9.8.2 comment=WifiAP mac-address=XYZ server=LAN_DHCP
# Other static leases removed
/ip dhcp-server network
add address=10.9.8.0/22 dns-server=10.9.8.1 gateway=10.9.8.1
add address=10.9.40.0/22 dns-server=10.9.40.1 gateway=10.9.40.1
add address=10.9.64.0/22 dns-server=10.9.64.1 gateway=10.9.64.1
/ip dns
set allow-remote-requests=yes cache-size=20480KiB
/ip dns adlist
add ssl-verify=no url=\
    https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
/ip firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
    "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Accept incoming wireguard" dst-port=\
    13231 protocol=udp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
    in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
    ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
    ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
    connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
    "defconf: accept established,related, untracked" connection-state=\
    established,related,untracked
add action=accept chain=forward comment=\
    "Accept all wireguard incoming traffic" disabled=yes in-interface=\
    wireguard1 src-address=10.9.8.224/27
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
    connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
    ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat comment=VOIP dst-port=5060 in-interface-list=\
    WAN protocol=tcp to-addresses=10.9.11.3 to-ports=5060
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip smb shares
set [ find default=yes ] directory=pub
/ipv6 address
add address=::1 from-pool=general-pool6 interface=bridge
/ipv6 dhcp-client
add add-default-route=yes interface=sfp-sfpplus1 pool-name=general-pool6 \
    request=prefix use-peer-dns=no
/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
/ipv6 firewall filter
add action=accept chain=input comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
    invalid
add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=input comment="defconf: accept UDP traceroute" port=\
    33434-33534 protocol=udp
add action=accept chain=input comment=\
    "defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\
    udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \
    protocol=udp
add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=input comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=input comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
add action=accept chain=forward comment=\
    "defconf: accept established,related,untracked" connection-state=\
    established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
    connection-state=invalid
add action=drop chain=forward comment=\
    "defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment=\
    "defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \
    hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\
    icmpv6
add action=accept chain=forward comment="defconf: accept HIP" protocol=139
add action=accept chain=forward comment="defconf: accept IKE" dst-port=\
    500,4500 protocol=udp
add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\
    ipsec-ah
add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\
    ipsec-esp
add action=accept chain=forward comment=\
    "defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec
add action=drop chain=forward comment=\
    "defconf: drop everything else not coming from LAN" in-interface-list=\
    !LAN
/ipv6 nd
set [ find default=yes ] interface=bridge ra-interval=20s-1m
/system clock
set time-zone-name=Europe/Zurich
/system leds
set 0 leds=user-led type=off
/system note
set show-at-login=no
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN

erlinden · Mon Mar 24, 2025 2:22 pm

In a VLAN world your bridge shouldn't have an IP Address.

Also, bridge shouldn't be part of an interface list:

/interface list member
add interface=bridge list=LAN

You use both IPv4 and IPv6, you might want to check how non-working (as well as working websites) resolve.

Update:
Thanks for clarifying my statement, @sindy! I tried to be as @anav as possible

sindy · Mon Mar 24, 2025 3:17 pm

In a VLAN world your bridge shouldn't have an IP Address.

Since there are /interface/bridge/port rows with the default value of pvid (1) and bridge-the-port also has pvid set to the default value 1, there is nothing wrong about having an IP address attached to bridge-the-router-interface directly. If you wanted to use bridge (the port) as a 100% trunk one (i.e. not a hybrid one), you would have to set ingress-filtering to yes (the default in ROS 7.x) and frame-types to admit-only-vlan-tagged (the default is admit-all), and attach an /interface/vlan for VLAN 1 to bridge-the-router-interface. Or instead replace VLAN ID 1 by some other one everywhere except bridge-the-port's pvid and attach an /interface/vlan for that other VLAN ID to bridge-the-router-interface.

paradigmatic · Tue Mar 25, 2025 11:38 am

@sindy @erlinden I thought I were starting to understand, but I am lost again

I am not sure about the difference between a purely trunk bridge-the-port or an hybrid bridge-the-port. Why would I chose one configuration over the other ?

In my case, I am willing to remove the bridge IP address, to keep only the VLAN one. But I am not sure about the order of config modification I should perform to avoid locking myself out... (again)

What is the simpler action I could take, to get something working ?

lurker888 · Tue Mar 25, 2025 12:16 pm

@sindy @erlinden I thought I were starting to understand, but I am lost again

I am not sure about the difference between a purely trunk bridge-the-port or an hybrid bridge-the-port. Why would I chose one configuration over the other ?

I am not sindy or erlinden but...

You should realize that the switching/bridging and the routing parts of the configuration are done separately. The bridge as an interface is simply the CPU facing port of the switch/bridge. Other than that the Linux guys decided to overload the name of the bridge with this port (which you just have to learn to accept), there is no additional magic going on. (Ok, there are some edge cases, but probably those will not bite you just yet.)

Therefore it is totally fine to configure the bridge interface (as a bridge port itself) to be either an access port, a trunk port or hybrid.

I usually configure it as purely trunk. That is, set ingress filtering to yes, allow-only-vlan-tagged and add vlans to the bridge interface. And this is what I will suggest to you as well. (This is actually the config that most managed switches with easier to use config interfaces do implicitly.)

In my case, I am willing to remove the bridge IP address, to keep only the VLAN one. But I am not sure about the order of config modification I should perform to avoid locking myself out... (again)

The usual suggestion is to remove a port from the bridge and enable whatever access you need from that port. This allows you to configure all things bridge-related without locking yourself out, even is you mess up any part of your configuration. After you have configured everything to your liking - and verified it -, what you do with that port (leave it as-is, or use it as part of your bridge) is totally up to you.

What is the simpler action I could take, to get something working ?

I think that having a well understood and later easily extendable configuration is more important than doing it as quickly as possible

Bridges and the associated VLAN behavior is not that complicated, and once it "clicks" it will seem quite natural going forward. However to gain such understanding you have to suffer a bit.

sindy · Tue Mar 25, 2025 12:38 pm

Sorry for blurring the picture for you, my response was mainly triggered by @erlinden as I am kind of tired of everyone treating VLAN 1 as black magic that has to be avoided by all means, hence that approach spreads as a meme (in the meaning of a "human software" virus, not the funny picture with a caption), becoming a self-fulfilling prophecy. There is no magic - it's just that many vendors think it is a good idea not to show default values in the configuration export unless you explicitly ask for them to be shown, so VLAN ID 1, being the default value for pvid on all switch ports probably for all vendors, stays out of the mind map until you start thinking about VLANs as a whole. And once you start, "hidden" easily transforms into "missing".

Otherwise, @lurker888 has said it all.

paradigmatic · Tue Mar 25, 2025 6:05 pm

Many thanks to all. I managed to get every VLANs and the IPv4 stack running. The instability came from the fact I started with a working config and tried to modified, introducing contradictions (and several node with the same IP address). I finished by implementing all your advices in freshly reset router. Still struggling to get the IPv6 stack running, but that will be my next challenge.

lurker888 · Tue Mar 25, 2025 7:28 pm

If you don't mind me hijacking the thread a bit about vlan 1. I fully agree with @sindy, that "don't use vlan 1" has become somewhat of a meme on this forum, and I also agree that memes in and of themselves are often not very useful.

However this does have some basis in reality. In most switches that are VLAN aware all packets are internally VLAN tagged, and in fact this is exactly how bridges with VLAN filtering enabled work in Mikrotiks as well. That means that if you want to handle bridging between untagged ports, you have to assign a VLAN to them internally (possibly with only access ports attached). It is customary to reserve vlan 1 for this purpose. (I believe this comes from the first Catalyst switches, which basically defined what we mean by managed switches today.)

On Mikrotiks any vlan id can be used for this purpose, but on many switches, especially the so-called smart (or easy smart, etc.) switches vlan 1 is sort of hard coded, so if you have to interoperate with these, vlan 1 should be handled with care. As a bonus, many of them do not differentiate vlan 1 tagged and untagged traffic correctly.

mkx · Tue Mar 25, 2025 8:53 pm

As a bonus, many of them do not differentiate vlan 1 tagged and untagged traffic correctly.

Something like this:

/interface/bridge
add name=bridge vlan-filtering=yes frame-types=admit-all  pvid=1 
/interface/bridge/port
add bridge=bridge interface=ether1 frame-types=admit-all pvid=1
add bridge=bridge interface=ether2 frame-types=admit-all pvid=1
/interface/bridge/vlan
add bridge=bridge untagged=bridge,ether1,ether2 vlan-ids=1

So when a frame, tagged with VID=1, ingresses through a bridge port (e.g. ether1), it's admitted due to frame-types setting (and setting of ingress filtering doesn't matter because ether1 is member of VLAN 1). And on egress (e.g. through ether2) VLAN header gets stripped because ether2 is set as untagged member of VLAN 1 ... making the frame untagged.
And same happens in the opposite direction.

Oh wait ... apart from vlan-filtering=yes setting on bridge that's actually default setup of ROS devices. So while an, e.g., CRS with default config won't mess with VID 1 (because it won't process VLAN headers), it'll mess with VID 1 if vlan-filtering is enabled and the rest of configuration is not adjusted to care about tagged frames with VID 1.

Don't get me wrong, VLAN ID 1 is as valid VID as any other (in range 2-4094) ... but as explained many times before, there's just too much of (hidden) default config floating around that has big potential to screw the unexpecting one. So it's better to avoid VID 1 ... because there are 4093 other VIDs to choose from.

NathanA · Tue Mar 25, 2025 9:37 pm

but on many switches [...] vlan 1 is sort of hard coded [for this purpose], so if you have to interoperate with these, vlan 1 should be handled with care.

Perhaps this is what you are getting at, but most of these aforementioned switches will reserve VID 1 as an "untagged" VLAN, and likely will either not accept (or egress) tags on a trunk port with VID=1 (because it won't allow you to configure that as a valid trunk tagged ID to begin with), and/or receiving a packet tagged with VID=1 on a trunk port may result in undefined (possibly bad) behavior. The only real "interoperational" consideration you should need to make, therefore, is simply don't utilize VID of 1 in any of your switches for anything other than the common untagged VLAN that exists between trunk ports.

And on MTs specifically, because VID 1 is by default attached (untagged) to the CPU-facing switch port, best practice is to leave it as PVID for any trunk port, if only so that when you %#@#$ something up and forgot to set Safe Mode, you don't have to worry about whether you happened to remember to trunk whatever your trunk port(s)' PVIDs are to the CPU or not, allowing you to MAC-Winbox back in to fix your mistake.

lurker888 · Tue Mar 25, 2025 10:43 pm

Perhaps this is what you are getting at, but most of these aforementioned switches will reserve VID 1 as an "untagged" VLAN, and likely will either not accept (or egress) tags on a trunk port with VID=1 (because it won't allow you to configure that as a valid trunk tagged ID to begin with), and/or receiving a packet tagged with VID=1 on a trunk port may result in undefined (possibly bad) behavior. The only real "interoperational" consideration you should need to make, therefore, is simply don't utilize VID of 1 in any of your switches for anything other than the common untagged VLAN that exists between trunk ports.

You have stated exactly the interoperability concern I was talking about

sindy · Tue Mar 25, 2025 11:15 pm

That means that if you want to handle bridging between untagged ports, you have to assign a VLAN to them internally (possibly with only access ports attached). It is customary to reserve vlan 1 for this purpose.

How is it "reserved"? Or, how is "bridging between access ports to VLAN XYZ" different from "bridging between untagged ports"? What would be the purpose of a managed switch if you could not make an "untagged port" (= access one) a member of whatever VLAN you want?

NathanA · Tue Mar 25, 2025 11:26 pm

How is it "reserved"? Or, how is "bridging between access ports to VLAN XYZ" different from "bridging between untagged ports"? What would be the purpose of a managed switch if you could not make an "untagged port" (= access one) a member of whatever VLAN you want?

I was a little confused by the wording, too, because of course you can set any access port to be a member of whatever VLAN-ID you want. But I think all he was possibly trying to communicate was that on not a few managed switches, it's simply impossible to get it to tag anything from VLAN-ID 1 on egress, or to accept any packets tagged with VLAN-ID 1 on ingress. So VID 1 is effectively only able to be used on such switches either as the default access port VLAN, or as the untagged VLAN on a trunk port. That being the case, if you are going to include such switches in your mix, you might as well just treat VLAN 1 across all of your switches as "THE untagged VLAN on trunk ports", for the sake of consistency.

lurker888 · Tue Mar 25, 2025 11:35 pm

How is it "reserved"? Or, how is "bridging between access ports to VLAN XYZ" different from "bridging between untagged ports"? What would be the purpose of a managed switch if you could not make an "untagged port" (= access one) a member of whatever VLAN you want?

Well... exactly. The way you bridge two untagged ports on a bridge with VLAN filtering enabled, and on managed switches in general, is to make them an access port to the same VLAN. You are completely right that this can be VLAN 1, 101, 1001 or whatever. That VLAN is then - is a sense - reserved, in that it cannot be used for another purpose (obviously.)

And on Mikrotiks it really doesn't matter which VLAN you use for this. However some other brands of managed switches - as @NathanA has pointed out - won't let you e.g. trunk VLAN 1 (tagged). In their minds VLAN 1 *is* special. And don't even get started on establishing a hybrid port with them that has *both* untagged traffic and a VLAN 1 as tagged. It may be a fault or misunderstanding on the other vendors' part (I think it is) but it's sufficiently common to provide a reason to avoid its use external to your device. Especially if one has the misfortune of using some of the not-exactly-managed (smart, easy smart, etc.) switches.

I think this came about with CISCO calling it the "native" VLAN, and mindless - sometimes even incorrect - copying of their model.

anav · Wed Mar 26, 2025 4:19 pm

Thanks Nathan, that is the practical answer and enough technical description I was looking for to continue a general approach to all configs. Very often there is a mix of different vendor switches involved downstream from an MT router. Luckily, thus far I have not needed a config that required vlan1 be used for any data etc, and thus never used a bridge setting with any other vlan set (besides the default) and frame types limited. There are probably edge cases that do, but will cross that bridge ( yuck yuck ) when I get to it.

Buckeye · Thu Mar 27, 2025 5:10 am

I agree there is a lot of technical dogma being spread without any explanations or evidence.

There are good interoperability reasons not to use tagged vlan 1 in a trunk, for example read Tagged VLAN 1 In a Trunk Is a Really Bad Idea in Ivan Pepelnjak's ip space blog. Daniel Dib also has some interesting posts in his Daniels Networking Blog (primarily Cisco focused) concerning vlan 1. Is VLAN 1 Special in Cisco Networks?, Some History on VLAN 1 in Cisco Switches, and some related post about untagged vlans Why Do We Have Native VLANs? (Mikrotik traslation "Why do we have hybrid trunk links") which has some real meat. A related issue of mismatched untagged vlans, e.g. consider what happens when an access port for vlan 10 on one switch is connected to an access port for vlan 20 on a second switch. As far as I know, these are not detected in ROS. Detecting Mismatched Native VLANs

Interesting read I found when searching for technical dogma The Dangerous Dogmas of Software Engineering

Amm0 · Thu Mar 27, 2025 6:24 am

I agree there is a lot of technical dogma being spread without any explanations or evidence.

Yup. I'd just add on routers with a default configuration, enabling vlan-filtering=yes is complete safe to do at the START in RouterOS 7.16+. While, typical advice is to set vlan-filtering=yes last. I'm not sure that the best advice anymore. Since default use VLAN 1, that actually why enabling vlan-filtering=yes at start is safe.

i.e. If set vlan-filtering=yes first, it's both "safe", and allows a "more gradual" adding of VLANs (i.e. without the make-or-break moment with vlan-filtering=yes coming at end). And leaving the default 192.168.88.1 from default, means it can be used as a "temporary management port". When done and happy with any new VLANs added, you can then just make sure 1 is not tagged on anything but the bridge. You can use one port dedicated as "bridge management port" (with pvid=1 frame-type=allow-only-untagged) so it get a 192.168.88.x, or just remove all the configuration on the bridge interface and use dedicated mgmt port. My main grip is that I think it better to START with vlan-filtering=yes as it will result in LESS drama while learning, since you add each VLAN step-by-step.

NathanA · Thu Mar 27, 2025 8:21 am

I'd just add on routers with a default configuration, enabling vlan-filtering=yes is complete safe to do at the START in RouterOS 7.16+. While, typical advice is to set vlan-filtering=yes last. I'm not sure that the best advice anymore. Since default use VLAN 1, that actually why enabling vlan-filtering=yes at start is safe.

I'm not aware of anything that has changed in RouterOS since the new bridge interface with VLAN filtering was introduced in (I think?) 6.41 up through 7.18 that makes setting vlan-filtering=yes on the bridge any more or less safe on any particular version. So I'm not entirely clear what the reference to "7.16+" is about.

That said, I nearly always make my very first act upon taking any MikroTik device out of the box for the first time to issue "/system/reset-configuration no-defaults=yes", and start from a complete blank slate. So maybe you are talking about some part(s) of the out-of-the-box config that might somehow make enabling vlan-filtering at the start "unsafe" on particular versions?

I believe that as long as the interface that you are talking to the MikroTik on has its own PVID configured to be whatever you have set the PVID to be for the bridge as a whole, it should be safe to enable vlan-filtering. That is to say, if you are connected to the device on ether5, then if you "/interface/bridge/set [find name=bridge1] pvid=30", also do "/interface/bridge/port/set [find interface=ether5] pvid=30", at which point "/interface/bridge/set [find name=bridge1] vlan-filtering=yes" should be safe, because then PVID of the port you're connected to matches the PVID of the CPU-facing switch port. Since the default if not touched is always pvid=1 in all cases, I think the only time it wouldn't be safe would be if you happened to be talking to it over a port you are configuring to be an access port on a different VLAN, or a hybrid trunk port with a different native VLAN...

Naturally, as long as you Ctrl-X first, you can save yourself a lot of headaches regardless.

CGGXANNX · Thu Mar 27, 2025 8:45 am

I'm not aware of anything that has changed in RouterOS since the new bridge interface with VLAN filtering was introduced in (I think?) 6.41 up through 7.18 that makes setting vlan-filtering=yes on the bridge any more or less safe on any particular version. So I'm not entirely clear what the reference to "7.16+" is about.

Since 7.16 we have this:

*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;

That removes the risk of forgetting to add the bridge CPU port to the "tagged" list of VLANs (which in older versions means no L3 access to the router through those VLANs). In fact, now if all you need are VLANs with access ports you don't need to bother to manually maintain the /interface bridge vlan table anymore. Just add /interface vlan entries and change PVID of the ports.

mkx · Thu Mar 27, 2025 10:05 am

Since 7.16 we have this:

*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;

That removes the risk of forgetting to add the bridge CPU port to the "tagged" list of VLANs (which in older versions means no L3 access to the router through those VLANs).

This is true. But doesn't change the fact that it's completely safe to enable vlan-filtering on bridge after default setup (on SoHo devices) and before chaning anything regarding VLANs. Default setup of bridge and (by default) attached interfaces is safe to enable vlan-filtering ... but, as I wrote in my previous post, has potential to break network if other devices are set up to use VLAN 1 as tagged. This doesn't mean that default setup is unsafe, it only underlines the sensibility of rule "don't use VLAN ID 1 as tagged". Yes, when changing L2 setup of device, any errors can mean locking out of device (and that includes MAC conections), so enabling safe mode before doing anything is a very sane thing to do.

NathanA · Thu Mar 27, 2025 10:16 am

Since 7.16 we have this:

*) bridge - added dynamic tagged entry when VLAN interface is created on vlan-filtering bridge;

That removes the risk of forgetting to add the bridge CPU port to the "tagged" list of VLANs (which in older versions means no L3 access to the router through those VLANs). In fact, now if all you need are VLANs with access ports you don't need to bother to manually maintain the /interface bridge vlan table anymore. Just add /interface vlan entries and change PVID of the ports.

I have never needed to manually maintain /interface/bridge/vlan table for access ports, ever. I literally just change 'pvid=' per bridge member in /interface/bridge/port, and ROS has always created [D]ynamic entries for those VLANs in the table you reference if they don't exist, and if the VLAN is already defined (so that I can add it to some trunk ports), ROS adds the access ports with pvid=<that_VLAN> to the read-only "current-untagged" port list for that VLAN-ID. This is true going all the way back to ROS 6.4x.

What I take this changelog entry to mean is, on 7.16 or newer, if you create an /interface/vlan interface with a bridge as the parent interface, it will simply also add your bridge as a tagged member under /interface/bridge/vlan of whatever VLAN-ID you set in your vlanX interface. Sounds like a nice convenience, but I don't see what this does to help people to avoid locking themselves out of their router management. The opposite presumably isn't true, meaning ROS will not automatically create a dynamic /interface/vlan for you if you add "bridge1" or whatever as a tagged member of a VLAN under /interface/bridge/vlan. And I WOULDN'T want it to, either, since there are some VLANs which I would NOT want to expose the CPU to at all! But I would think that it's the /interface/vlan most people are likely to forget creating, not the /interface/bridge/vlan...

mkx · Thu Mar 27, 2025 10:31 am

What I take this changelog entry to mean is, on 7.16 or newer, if you create an /interface/vlan interface with a bridge as the parent interface, it will simply also add your bridge as a tagged member under /interface/bridge/vlan of whatever VLAN-ID you set in your vlanX interface. Sounds like a nice convenience, but I don't see what this does to help people to avoid locking themselves out of their router management.

It's not that by creating /interface/vlan on top of bridge interface and not adding bridge as tagged port to that VLAN automatically locks you out from management. It's that device CPU can't communicate with that VLAN ... and we've seen quite a number of forum posts by users who were struggling due to that. So adding bridge port as tagged member of such VLAN is a nice comodity for users with less than perfect understanding of how bridge works.
My guess is that most people do know that they need /interface/vlan interface for ROS to interact with certain VLAN ...

The opposite presumably isn't true, meaning ROS will not automatically create a dynamic /interface/vlan for you if you add "bridge1" or whatever as a tagged member of a VLAN under /interface/bridge/vlan. And I WOULDN'T want it to, either, since there are some VLANs which I would NOT want to expose the CPU to at all!

In principle you don't want to set bridge port as tagged member of a VLAN if you don't intend CPU to interact with that VLAN over that bridge. Apart from doing it to work around a certain ROS bug (which affects traffic between HW-offloaded bridge ports, hosted on switch chip, and other bridge ports, ether hosted on adjacent switch chip or attached directly to CPU) ... which is supposed to be fixed but users which did get hurt by it didn't report any change in behaviour (either the behaviour is not fixed or users didn't bother to report success).
So I'm eager to hear use case for such setup.

NathanA · Thu Mar 27, 2025 10:55 am

In principle you don't want to set bridge port as tagged member of a VLAN if you don't intend CPU to interact with that VLAN over that bridge. [...] So I'm eager to hear use case for such setup.

Huh? That's just not true. Maybe you are assuming that the MT in question is a router that will also be handling other duties for devices in that VLAN, such as DHCP server, or gatewaying/firewalling/NATting, etc. That's a big assumption, though. We are talking about SWITCHES, after all. If I buy a CRS and put it somewhere on my network, the only VLAN that I typically want exposed to the CPU is whatever VLAN the management traffic to the switch (Winbox / SSH / whatever) is going to be happening over. All of the other VLANs, typically no! I would only make temporary exceptions for troubleshooting (for example: "why can't I see things connected to port X on this switch through this VLAN? Is the VLAN even making it all the way over to that switch? Well, let's expose that VLAN to the CPU and see if I can even talk to the switch itself over that VLAN.")

Let's take a very simple example: a guest WiFi network in a small office. Guest VLAN gets trunked from some router at the head-end, THROUGH a CRS switch model of some kind, TO an access point. When there are guests connected to that network, I don't want them to be able to bring up Winbox, go over to the Neighbors tab, and see my switch! The less surface area I expose to people who have no business accessing those devices, the less opportunity I am giving anybody to compromise a device.

CGGXANNX · Thu Mar 27, 2025 12:05 pm

I have never needed to manually maintain /interface/bridge/vlan table for access ports, ever. I literally just change 'pvid=' per bridge member in /interface/bridge/port, and ROS has always created [D]ynamic entries for those VLANs in the table you reference if they don't exist, and if the VLAN is already defined (so that I can add it to some trunk ports), ROS adds the access ports with pvid=<that_VLAN> to the read-only "current-untagged" port list for that VLAN-ID. This is true going all the way back to ROS 6.4x.

Yes, if you only use the device as a switch. What I wrote (notice that I did include adding the /interface vlan entry) is for the case where people use the router as router, providing WAN access and inter-VLAN access to the VLANs that it managed. For most "beginners" that's what they start with as goal when learning VLAN on RouterOS. And as we can see on this same forum, on previous version < 7.16, many of them missed the requirement that the bridge port must be tagged if they need any >= L3 functionality from the router on that VLAN, including being able to use MAC WinBox (in case they also forgot the /ip address entry).

Huh? That's just not true. Maybe you are assuming that the MT in question is a router that will also be handling other duties for devices in that VLAN, such as DHCP server, or gatewaying/firewalling/NATting, etc. That's a big assumption, though. We are talking about SWITCHES, after all.

Look at the device in the OP of this thread, it's a RB5009, a router. Look at OP's current config that he/she wants to extend with VLAN, it's a ROUTER!

NathanA · Thu Mar 27, 2025 12:50 pm

Look at the device in the OP of this thread, it's a RB5009, a router. Look at OP's current config that he/she wants to extend with VLAN, it's a ROUTER!

Fair point. But then read through the rest of the thread up to this point, where we all kind of got a bit off the beaten path, and the conversation wandered away from the original specifics (especially since OP came back and gave the "all clear") towards more general discussion of VLAN switching config implementation in RouterOS vs. other SWITCHES. So yes sorry, I did rather assume a more generally switching-centric POV there in my last couple responses.

lurker888 · Thu Mar 27, 2025 1:03 pm

In principle you don't want to set bridge port as tagged member of a VLAN if you don't intend CPU to interact with that VLAN over that bridge. [...] So I'm eager to hear use case for such setup.

Huh? That's just not true. Maybe you are assuming that the MT in question is a router that will also be handling other duties [...]

I think @mkx was specifically talking about adding the bridge port named "bridge" (as in the CPU-facing port) as a tagged port. This is the way I read it, and this reading makes the statement correct. (Especially because of it being surrounded by adding "vlan interfaces" and using the CPU to software bridge between two hardware switch chips.) Of course maybe I'm the one who misunderstood it.

NathanA · Thu Mar 27, 2025 1:35 pm

I think @mkx was specifically talking about adding the bridge port named "bridge" (as in the CPU-facing port) as a tagged port.

Oh my goodness! I think you're right!

And in retrospect when I re-read that part of my reply with that in mind, it doesn't even make sense...yes of course he's correct that if you explicitly add the bridge itself (== CPU-facing port) to the bridge, by implication you want the CPU to be exposed to that VLAN, duhhh. I'm re-reading it over and over trying to understand what I would have been thinking at the time I wrote that, and can't even reverse-engineer my way back to anything sensical. My brain just seems to have slipped a major gear there.

mkx · Thu Mar 27, 2025 2:26 pm

In principle you don't want to set bridge port as tagged member of a VLAN if you don't intend CPU to interact with that VLAN over that bridge. [...] So I'm eager to hear use case for such setup.

Huh? That's just not true.

....

Let's take a very simple example: a guest WiFi network in a small office. Guest VLAN gets trunked from some router at the head-end, THROUGH a CRS switch model of some kind, TO an access point. When there are guests connected to that network, I don't want them to be able to bring up Winbox, go over to the Neighbors tab, and see my switch! The less surface area I expose to people who have no business accessing those devices, the less opportunity I am giving anybody to compromise a device.

So in which way my statement doesn't apply to your example? Your CRS is not supposed to interact with Guest VLAN and its bridge is thus not member (neither tagged or untagged) of Guest VLAN. And that's both true for "CPU-facing bridge port" (you'd set that in /interface/bridge/vlan) and for "bridge-facing interface" (you'd set that in /interface/vlan). The first one (not making bridge port member of Guest VLAN) already blocks all the communication between CPU and the rest of Guest VLAN ... and the second (vlan interface) is thus a NO-OP. You claimed (or so I undersoot) that you are making brdige "CPU-facing" port member of Guest VLAN, but you don't want to see corresponding VLAN interface to get created automatically (with later I fully agree BTW).

NathanA · Thu Mar 27, 2025 2:34 pm

So in which way my statement doesn't apply to your example?

Please read my response directly above your last (posted about an hour prior). It explains...well, as much as can possibly be explained, heh. In short, I had a most massive frain bart.

spippan · Thu Mar 27, 2025 2:44 pm

Sorry for blurring the picture for you, my response was mainly triggered by @erlinden as I am kind of tired of everyone treating VLAN 1 as black magic that has to be avoided by all means, hence that approach spreads as a meme (in the meaning of a "human software" virus, not the funny picture with a caption), becoming a self-fulfilling prophecy. There is no magic - it's just that many vendors think it is a good idea not to show default values in the configuration export unless you explicitly ask for them to be shown, so VLAN ID 1, being the default value for pvid on all switch ports probably for all vendors, stays out of the mind map until you start thinking about VLANs as a whole. And once you start, "hidden" easily transforms into "missing".

100% and thanks.
there is nothing bad/magical about VLAN 1 !
no purpose to "hype" it down the way it happens here...

anav · Thu Mar 27, 2025 2:47 pm

Not hyping it down, but its actual use as a data vlan is very niche (rare).

Amm0 · Thu Mar 27, 2025 4:18 pm

Not hyping it down, but its actual use as a data vlan is very niche (rare).

I'm with @sindy on FUD on VLAN 1 - over-emphasis creates a worse problems.

IMO it's needing "/interface/bridge/vlan tagged=bridge" that created more confusion, than VLAN 1. And the default use VLAN 1, so saying it's "bad"/"special"/etc send mixed messages to someone whose trying to learn how it work.

I think the point I was trying to make was that if you want to understand VLAN 1, understanding why — with a SOHO default configuration alone – you can enabled vlan-filtering=yes or =no and everything will still work same... be a better starting point to a deeper understanding vlan bridging on RouterOS. If you add one Layer3 /interface/vlan, you can then see how it works in /bridge/interface/vlan step-by-step.

And for those that don't, the "dynamic config" of bridge in "recent" RouterOS (7.18.2 is stable now), better hides mysteries (i.e. no need to explain "why /interface/bridge/vlan tagged=bridge" is needed - which takes a LOT of words). But for a truck port you do that in /interface/bridge/vlan, or access port set pvid= frame-type=allow-only-untagged... on a /interface/bridge/port (*assuming some /interface/vlan add interface=bridge ...).

spippan · Thu Mar 27, 2025 5:13 pm

Not hyping it down, but its actual use as a data vlan is very niche (rare).

yes and no ...
in more complex setups - sure. segregation is a plus and in that case, vlan1 should not be used. okay
otherwise the use of vlan1 also as a normal data vlan is no problem at all after all. if only for the sake of not overcomplicating things. don't get me wrong, i am not shy or uncapable of handling complex vlan setups (coming from daily work in a datacenter) but that does not mean, vlan1 has to be avoided at all costs and is "EVIL"

anav · Thu Mar 27, 2025 5:25 pm

For me its clear enough,
/interface bridge ports and /interface bridge vlans tells a story, the combination informs the router ( and the reader ) how to distribute subnets on the device.
Nothing hidden all up front. The two groups of settings cross-check each other for a consistent story.
Really the /interface bridge ports identify the functionality of the port and the /interface bridge vlans provide the distribution detail of the vlans going over the trunk ports and confirm the now known information of vlans being untagged when leaving the ports ( pvid already known).

Sure, its cool that MT is dynamically making these config lines or entries, but know the above first gives one an appreciation of what the router is doing for you.

====================

In terms of bridge tagging, if there L3 involved be it routing, ip address, firewall rules etc, then tagging the bridge is required.
Since the management vlan in a sense is being terminated on the switch (to provide the switch its IP address) it must be tagged.
There is interaction with the CPU and practically speaking, allows the device to be accessed remotely.

Put as a rote rule, if you need to identify the vlan for whatever L3 reason, on the config, it needs to be tagged on the bridge (/interface bridge vlan)
On a switch, none of the data vlans need to be identified, ( they simply are transparently switched from ether1 to whatever port they are supposed to go out on at L2).

eltikpad · Thu Mar 27, 2025 7:00 pm

In terms of bridge tagging, if there L3 involved be it routing, ip address, firewall rules etc, then tagging the bridge is required.
Since the management vlan in a sense is being terminated on the switch (to provide the switch its IP address) it must be tagged.
There is interaction with the CPU and practically speaking, allows the device to be accessed remotely.

Put as a rote rule, if you need to identify the vlan for whatever L3 reason, on the config, it needs to be tagged on the bridge (/interface bridge vlan)

Im not sure this is true. It works perfectly well to have an untagged vlan on a bridge, and add an IP address to the bridge itself. This gives the untagged vlan a layer 3 interface. Other tagged vlans on the bridge will need a VLAN interface with IP address to interact at layer 3.

anav · Fri Mar 28, 2025 3:50 pm

I wouldnt know eltikpad, I have never had to resort to putting an address on the bridge while using vlans. I prefer clean separation of bridge from DHCP etc, once I start using vlans.

lurker888 · Fri Mar 28, 2025 11:07 pm

I wouldnt know eltikpad, I have never had to resort to putting an address on the bridge while using vlans. I prefer clean separation of bridge from DHCP etc, once I start using vlans.

I can image one situation where it would be natural to have the bridge port as an access port: when using the device as a pure switch (or switch+AP) where the CPU only has access to the management VLAN. I did that for a while but then returned to tagging it and using a VLAN interface there as well, just for consistency.

Buckeye · Fri Mar 28, 2025 11:29 pm

We really need a topic "ROS Best Practice, Guidelines, Folklore, Myths, FUD, Dogma, and Lies"

mkx · Sat Mar 29, 2025 11:20 am

We really need a topic "ROS Best Practice, Guidelines, Folklore, Myths, FUD, Dogma, and Lies"

It'd be (another) flame war. Something could be a myth or FUD for some and good practice for others. Example is recent discussion about explicit use of VLAN ID 1.

anav · Sat Mar 29, 2025 4:34 pm

I think mkx said it best in poetry, just make your config look like mine and all will be happy.

What we need, no joke, is for new users to be educated prior to making their first posting, and a sandbox where posts can be reviewed prior to posting live.

eltikpad · Sat Mar 29, 2025 6:54 pm

Im not sure I agree that gate keeping a pubic forum, especially one with a topic named “Beginner Basics” is the right thing to do. I do wish there was better documentation of a basic, straight forward way to configure vlans on the popular home router models with up to date Ros that we could point people to. Based on the confusion seen in these threads it doesnt seem to exist, either in the official Mikrotik docs or in the common threads new users are pointed to. It would be hard to get consensus from all the experts around here but would be very useful.

anav · Sat Mar 29, 2025 7:42 pm

Even more pertinent in Basic but based on your lack of experience on the forum ( clearly IT trained and more knowledgeable than I will ever be ) I disagree.