Why AP and Wifi clients get Native Vlan IP when AP connects to a Trunk Port with Native Vlan setup

[Marlon]

Hi, 

I am testing Meraki Access Point connections with Meraki Switch Port. The basic Connection is: I setup e.g. Vlan 1, Vlan 10, Vlan 11 on Core Switch, the DHCP server for each Vlan is setup on Meraki Firewall, but I setup DHCP relay on the Core-Switch to lead the DHCP request to the firewall. All the connections between Switch are setup as Trunk with Native Vlan1, but on the Port between Switch and AP, I setup Native Vlan to be 1, or 10, or 11. 

I realize on the Port that connect to AP, if I setup the Port to be Trunk and Native Vlan to 10 for example, the AP and all its WiFi clients will get Vlan 10's IP addresses. If I setup the Native Vlan to be 11 or other Vlan, the AP and clients will get that Native Vlan's IP. I didn't setup tagging on AP or Port, just this basic setting shown in the screenshot. 

Why APs get Native Vlan's IP address by DHCP? What's the Logic for this?

How does the Switch know that AP and its client are belonging to that Vlan (Native Vlan)? 

Are there any risks of doing this way?

I will be very grateful if anyone can help. Thanks. 

Regards,

Marlon

[GIdenJoe]

In your SSID you must configure bridge mode (now known as external dhcp assigned mode) and actually tag a VLAN to have tagged traffic for your clients.

[Marlon]

Thanks Joe, I actually setup Bridge Mode on the SSID, but how the Tag happens when I setup Native Vlan 10 on the Switch Port. My understanding Native Vlan won't be tagged, how does the Switch know this port connects to Vlan 10. 

It's easy to understand when I setup the Switch Port to be Access (e.g. access Vlan 10 only) to connect to AP, as Switch know on this port it connects to Vlan 10, when AP and clients request DHCP, the request will be sent to Vlan 10's Gateway, but when I setup the Port to be Trunk with Native Vlan 10, how does the Switch know clients from this port belongs to Vlan 10? 

[alemabrahao · Accepted solution]

If you do not specify the VLAN that should be tagged in the SSID, the native VLAN will be used instead, just read the document I shared.

[Marlon]

Thanks @alemabrahao , I should read the article first (was going to read after I posted). The Article actually tell you why on the first page, It's saying "untagged traffic to the upstream switch port and then DHCP discover in the configured native VLAN". 

To be honest, I am still a bit confused, why DHCP Discover in the Configured Native VLAN? If you can explain that would be great, if not I will do more research myself. Thanks so much. 

[alemabrahao]

The concept of “DHCP Discovery on Configured Native VLAN” is related to how VLANs and DHCP work together.

By default, all untagged traffic arriving on this trunk port is assumed to belong to the native VLAN.

To be honest, I didn't understand your question completely, for me it's something that is so natural that I don't understand what is confusing for you.

[alemabrahao]

Take a look at this.

https://documentation.meraki.com/MR/Monitoring_and_Reporting/Understanding_and_Configuring_Managemen...

[Marlon]

I just did a bit more studying and I am clear now. 

I think the process is this:

Clients send untagged DHCP request to the Port, as the Port is setup a Native Vlan 10, Switch will know that the untagged request is from Native Vlan 10 because they are all untagged. When Switch forward that DHCP to another Trunk Port with a different Native Vlan e.g. 20, Switch will tag the request to the Original Native Vlan 10 and forward that request to Vlan 10's Gateway, from Gateway it will use DHCP relay to find the DHCP server. 

I was a bit confused on the process when a DHCP requests sent from on one Port with a Native Vlan and passed to another Port with a different Vlan, the Switch actually will tag the request with the origianl Native Vlan. It's all make sense now. 

Thanks. 

[alemabrahao]

I think this documentation will make everything clearer.

https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/VLAN_Tagging_on_MR_Access_Points#...