VLAN fail since upgrade to 7.16 from 6.49

Hi all,

I have an issue with wireless interfaces and VLANs since upgrading to 7.16 from 6.49.
For whatever reason the Wi-Fi clients are not getting IP addresses, sort of like the bridge port for the wireless interfaces is somehow not acting as an access port as intended.
My work around is to change the port at the switch to an access port. Then on the AP remove all VLAN settings and bridge the ethernet and wireless interfaces.

I created a test network stripping back everything and following http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1 with the same results.
Configuration is as follows:

VLAN220 - management
VLAN221 - Wi-Fi
VLAN222 - LAN

/interface bridge
add name=VLAN-Bridge protocol-mode=none vlan-filtering=yes
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=8 band=2ghz-g/n disabled=no frequency=2412 installation=indoor mode=ap-bridge name=WLAN2 radio-name=test_AP-1-2 \
    ssid=test-2 wireless-protocol=802.11 wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=8 band=5ghz-n/ac disabled=no frequency=5500 installation=indoor mode=ap-bridge name=WLAN5 radio-name=test_AP-1-5 \
    ssid=test-5 wireless-protocol=802.11 wps-mode=disabled
/interface vlan
add interface=VLAN-Bridge name=VLAN220-MGMT vlan-id=220
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/port
set 0 name=serial0
set 1 name=serial1
/interface bridge port
add bridge=VLAN-Bridge frame-types=admit-only-vlan-tagged interface=ether1
add bridge=VLAN-Bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=220
add bridge=VLAN-Bridge frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=222
add bridge=VLAN-Bridge frame-types=admit-only-untagged-and-priority-tagged interface=WLAN2 pvid=221
add bridge=VLAN-Bridge frame-types=admit-only-untagged-and-priority-tagged interface=WLAN5 pvid=221
/interface bridge vlan
add bridge=VLAN-Bridge tagged=ether1 vlan-ids=220
add bridge=VLAN-Bridge tagged=ether1 vlan-ids=221
add bridge=VLAN-Bridge tagged=ether1 vlan-ids=222
/ip address
add address=192.168.220.3/24 interface=VLAN220-MGMT network=192.168.220.0
/ip route
add distance=1 gateway=192.168.220.1
/system identity
set name=AP1
/system note
set show-at-login=no

Connections to the ethernet ports work correctly, IP addresses are assigned and internet connectivity is confirmed. I think this rules out an issue with the trunk port, singling out the 2 wireless interfaces.
The AP is an RBM33 with R11e-5HacD and R11e-2HPnD.

Any help pointing out where i’m going wrong would be greatly appreciated!

To me it seems there’s misconfiguration of bridge VLAN, conceptually it should be

/interface bridge vlan
add bridge=VLAN-Bridge tagged=> VLAN-Bridge,> ether1 vlan-ids=220

Since you probably have management access via IP address on VLAN220-MGMT interface, it seems that the whole VLAN stuff on bridge is not working correctly .

What do commands /interface/bridge/port/print and /interface/bridge/vlan/print show?

mkx hit the major problem other minor tweaks shown.

/interface bridge
add name=VLAN-Bridge protocol-mode=none vlan-filtering=yes
/interface wireless
set [ find default-name=wlan1 ] antenna-gain=8 band=2ghz-g/n disabled=no frequency=2412 installation=indoor mode=ap-bridge name=WLAN2 radio-name=test_AP-1-2
ssid=test-2 wireless-protocol=802.11 wps-mode=disabled
set [ find default-name=wlan2 ] antenna-gain=8 band=5ghz-n/ac disabled=no frequency=5500 installation=indoor mode=ap-bridge name=WLAN5 radio-name=test_AP-1-5
ssid=test-5 wireless-protocol=802.11 wps-mode=disabled
/interface vlan
add interface=VLAN-Bridge name=VLAN220-MGMT vlan-id=220
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk mode=dynamic-keys supplicant-identity=MikroTik
/port
set 0 name=serial0
set 1 name=serial1
/interface list
add list=TRUSTED
/interface list members
add interface=vlan220-MGMT list=TRUSTED
/ip neighbor discovery-settings
set discover-interface-list=TRUSTED

/interface bridge port
add bridge=VLAN-Bridge ingress-filtering=yes frame-types=admit-only-vlan-tagged interface=ether1
add bridge=VLAN-Bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether2 pvid=220
add bridge=VLAN-Bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=ether3 pvid=222
add bridge=VLAN-Bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=WLAN2 pvid=221
add bridge=VLAN-Bridge ingress-filtering=yes frame-types=admit-only-untagged-and-priority-tagged interface=WLAN5 pvid=221
/interface bridge vlan
add bridge=VLAN-Bridge tagged=VLAN-Bridge,ether1 untagged=ether2 vlan-ids=220
add bridge=VLAN-Bridge tagged=ether1 untagged=WLAN2,WLAN5 vlan-ids=221
add bridge=VLAN-Bridge tagged=ether1 untagged=ether3 vlan-ids=222
/ip address
add address=192.168.220.3/24 interface=VLAN220-MGMT network=192.168.220.0
/ip route
add distance=1 gateway=192.168.220.1
/system identity
set name=AP1
/system note
set show-at-login=no
/ip dns
set server=192.168.220.1

/tool mac-server
set allowed-interface-list=NONE
/tool mac-server mac-winbox
set allowed-interface-list=TRUSTED

Thanks for pointing out the error in my test config, and the security tips too! I have now corrected the tagged error.

However, I am still having the same issue with the wireless interfaces - in that any connected clients will not get an IP address from DHCP.
Yet using ether3 will successfully give an IP address in the VLAN221 subnet, 192.168.220.0/24 (i changed the pvid to 221 from 222 for ether3).

Having a look at the log on the router, it will show errors relating to “…offering lease [IP] for [MAC] without success”. I suspect maybe it’s a layer3 issue, layer2 is ok…maybe.
May need to get some packet captures.

I have downgraded the AP’s on the office network back to 6.49 successfully and that has restored the VLAN issues there, I will continue to mess around with the test network, when time permits, to try and understand why this is not working with routerOS 7.

The access point is not involved in giving out DHCP, so look to the upstream device…