03-18-2026 03:27 AM
Hello Community,
I have a question regarding MR SSID settings.
In the MR SSID configuration, VLAN tagging is enabled, and the VLAN ID configured for VLAN tagging is the same as the device management VLAN.
What I would like to understand is this:
When the same VLAN as the device management VLAN is configured under SSID VLAN tagging, wireless clients receive a 169.254.X.X address.
Could you please explain why this happens?
From my understanding, unless there is an IP conflict with the device management IP, I would expect the clients to communicate normally, but in reality they do not.
Is there any official documentation that explains this behavior as well?
Best regards.
Solved! Go to Solution.
03-18-2026 03:56 AM
How is the switch port configured where the APs are connected?
If it's configured as an access port and you're tagging the VLAN, this is the expected behavior since the packet comes with the VLAN tag.
If you leave the SSID untagged, does the client receive an IP address normally?
A 169.254.x.x (APIPA) address means the client didn’t receive a DHCP Offer. On Meraki MRs in Bridge mode with Per‑SSID VLAN tagging, the AP tags client data frames with the VLAN you configured on the SSID, while the AP’s own management traffic is sent untagged (native VLAN) unless you explicitly configure a management VLAN tag on the AP. If anything in the upstream path treats those two things differently, the DHCP Offer never makes it back to the client, and the client falls back to APIPA.
03-18-2026 03:56 AM
How is the switch port configured where the APs are connected?
If it's configured as an access port and you're tagging the VLAN, this is the expected behavior since the packet comes with the VLAN tag.
If you leave the SSID untagged, does the client receive an IP address normally?
A 169.254.x.x (APIPA) address means the client didn’t receive a DHCP Offer. On Meraki MRs in Bridge mode with Per‑SSID VLAN tagging, the AP tags client data frames with the VLAN you configured on the SSID, while the AP’s own management traffic is sent untagged (native VLAN) unless you explicitly configure a management VLAN tag on the AP. If anything in the upstream path treats those two things differently, the DHCP Offer never makes it back to the client, and the client falls back to APIPA.
03-18-2026 04:20 AM
thanks to reply
switch port config mode is trunk and also native vlan was done.
Regards
03-18-2026 04:31 AM
Based on your explanation, I would like to confirm whether my understanding is correct.
SSID client traffic is forwarded with an 802.1Q VLAN tag, whereas MR management traffic is carried untagged on the native VLAN.
If both are configured to use the same VLAN/subnet, could this create a situation where client traffic is expected to be treated as tagged traffic, but the switch/network path treats return traffic as native/untagged traffic instead, which then causes DHCP assignment to fail?
Is my understanding correct?
Regards
03-18-2026 04:44 AM
Even when the AP port is correctly configured as a trunk and the native VLAN matches the AP's management VLAN, the crucial detail is that the SSID's VLAN tagging uses tagged traffic, while the AP's management uses untagged/native traffic, even if both use the same VLAN ID.
Therefore, the AP may function fine (management), but the tagged client VLAN may still not reach DHCP correctly.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide