VLAN & DHCP Issues: This device is using a DHCP IP address from VLAN instead of using config VLAN

[jhyoung09]

We are starting to roll out a Meraki installation for our remote stores. I'm working on setting up a switch now and I keep getting this error, "This device is using a DHCP IP address from VLAN instead of using configured VLAN 1." I have DHCP options set in the MX65 the switch is connected to but still no go. Below are some of my configs if you all can help, I'm new to Meraki. 

Management VLan setup on MX65

Switch Config

[jdsilva]

Basically it's telling you that the static IP config you gave it doesn't work, so it fell back to using a DHCP address on VLAN 1 to reach the cloud.

https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Behavior_during_Conn...

So something's wrong with connectivity on your VLAN 903. Verify that the ports you have connected are configured to carry that VLAN the same way on both sides. 

Also, if you're changing the Mgmt VLAN from 1 then you should be changing that in Switch-->Configure-->Switch settings.

https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#Management_VLAN

[Adam]

Check the upstream port VLAN configuration as well. 

[jhyoung09]

Which are you referring, the port on our MS210 or the MX65?

[jdsilva]

Check both.

[jhyoung09]

I have a couple times, but i checked again. I'm allowing all traffic on my trunk up to the MX65, and on the MX65 down to the MS210 i'm allowing all traffic. 

MS210

MX65

 I'm at a complete loss right now. 

[BB]

is it solved now?

[Adam]

@jhyoung09 For the switch static IP configuration have you specified VLAN 1? 

Also on that MX trunk port you may want to try setting a native VLAN of 1 instead of drop all untagged for testing.  You can always tighten it up after you get it working.  

[ArshadSafrulla]

I would change the native vlan on both the side to match the management vlan

[Steven5455]

Same issue here

[jimmyj]

same error here, nothing has changed (apart from maybe automated firmware updates) - what gives?

[Brons2]

You need to configure both ports on the uplink for VLAN 903, if you want the MX, or any Meraki device, to use an IP on VLAN 903.  It's not going to be able to use a management IP on VLAN 903 if you don't have any ports configured for it.  It found an IP with internet access on VLAN1, (which is the default VLAN, or the same as no VLAN) so it used that.

This error is actually new(er/ish) in later versions of the Meraki software - it will try to find an IP if your settings don't work.  Which is what it's done here.  Before, in the older versions of the software, you just wouldn't get any traffic at all if it wasn't configured correctly.

[JAYSNET]

Agreed.. Did the same and worked for me.

[Lexikoala]

Did you ever find a resolution to this issue? I am having the same problem, but I cannot figure it out.

[Nedy]

Hi! I have the same problem.

[Fozzy]

When configuring an IP address statically - don't put the VLAN in if the native VLAN is the same as the VLAN with the subnet you want to get an IP address from.

[Brons2]

I don't have any problem with the setting that you describe, Fozzy.  My native VLAN is also included in the allowed VLANs and it's also the managment VLAN.  Static IP set on all devices.  It works fine.

Exception being switches from vendor XYZ we have connected to Meraki switches - if you configure the connection as a trunk port, the other vendor switch will not accept having a native VLAN on the connection, so we don't configure a native VLAN on those.

(Vendor XYZ not being traditional Cisco Catalyst switches, if that helps anyone)

[whistleblower]

Hi,

I´d like to ask several questions for understanding about that topic "management vlan"

1 - reading through the documentation Advanced MS Setup Guide - Cisco Meraki I understand, that the configuration can be done either "Globally" via the Switch Settings or "per Switch" -  so is my understanding correct, that when e.g. globally Vlan300 is configured and per Switch it`s Vlan400 it the globally configuration will be overruled and a notification appears under the device that the configured Management VLAN is`nt matching correct between globally and per Switch locally as well?

2- if the configuration is done only globally - is that VLAN automatically send tagged from the switches without a configuration needed per Switch or via local status page from the devices?
3 - the VLAN-ID which can be specified per Switch "statically" as well as per "DHCP" will be tagged or send untagged? what will happen with e.g. that configuration?

4 - the respective section in Behavior during Connection Loss to Cisco Meraki Cloud - Cisco Meraki says...

If the configuration is not safe

• MS will try to obtain an IP address on an alternate VLAN and then connect to the cloud through that alternate connection

about the keyword = "configuration is not safe" what does that mean exactly? is this procedure also happening when the switch is installed the first time with factory default configuration?

[Bruce]

Hi @whistleblower, here’s my take on your questions based on experience. Happy for others to advise if they’ve had different outcomes.

1. Yes, local configuration overrides network-wide configuration, but I’ve never seen a warning message if the two don’t match. I’ve only seen warning messages if there is a communication issue with the Meraki cloud.

2. There is no automatic tagging for the management VLAN across the network. You have to get the traffic to/from the switch. Based on this I always find it easiest to have the management VLAN set as the native on all trunks that are uplinks.

3. Imagine the management address as an access port on the switch. It doesn’t care which VLAN it is, only if there in a path to a DHCP server on that VLAN. Since it’s an ‘access port’ it’s always untagged, whether it’s tagged or not on another port depends on that port’s configuration.

4. The definition of a safe configuration is a few paragraphs further up in that document, “Safe configuration means that ‘the device has connectivity to cloud and hasn't rebooted for 30 minutes following a configuration change.’ That is, the safe configuration is the last configuration the device received from the cloud that was not followed by a reboot within 30 minutes.” A ‘not safe configuration’ is just the reverse - I.e. one where no connectivity to the cloud has been achieved.

[Wenz]

remove VLAN903 and leave it blank

[RubenMeraki]

Hi, 

Try the following; 

1) go to Switch Port,

2) click on the proper port 

3)  Edit

4) Allow VLAN -> Type the Vlan you need, if this is not clear, type "all" 

5) Save

6) Reboot the Ap 

Good Luck! 🙂 

[StuHare]

We are having the same issue so the AP is showing a down amber state.

We have two APs configured identically, both with DHCP using reservations and not statics. VLANS, trunks and natives all fine and the same. One AP is fine the other is reporting this error DHCP from vlan 0.

This is even though the AP is getting its correct DHCP reserved IP from the correct VLAN. 

Tried changing to static and changing vlans etc but no difference.

Confirmed correct settings on both the dashboard and local AP config page.

[John59]

I am having the same issue with one of our AP's.  We do not have the port set as a trunk to our AP's they are access ports on a set vlan the same as our data.  One AP connects fine the other same version of software same port configuration but getting the error "This device is using a DHCP IP address from VLAN 0 instead of using configured VLAN 1."

What's the resolution?

[Kacy]

I have the same issue on one AP, configured with an static IP, the portal shows the correct static IP and no vlan indicated in the network config of the AP. The AP is connected to a Cisco switch set to access desired vlan, dhcp reservation for the AP to retain the correct IP

[Bruce]

What are the configurations of your SSIDs? Where are clients getting their IP addresses from? Even if you configure the switch port as an Access Port you need to remember that the MR is still effectively a Trunk Port. If you use an IP addressing mode on the SSID that potentially tags traffic on the port (e.g. Bridge Mode, Layer 3 Roaming) then you might be seeing unexpected behaviour that has nothing to do with the Management IP address and VLAN of the MR. 

[Kacy]

Only one SSID, it is the same SSID in all locations. DHCP pool is on the asa, as this is guest wifi only and routed out the local internet. There is no SVI for the vlan on the switch. This AP is setup the same as the other 14 that have no issue with the same config. 

[Bruce]

What 'Client IP Assignment' are you using on the SSID - I'm assuming NAT mode. So the traffic is intended to go directly from the AP to the ASA and then out to the internet. Any you're seeing the "This device is using a DHCP IP address...." in the Meraki Event Log for the AP?

[Kacy]

Local LAN, firewall does the NAT. "This device is using a DHCP IP address from VLAN 0 instead of using configured VLAN 1." is displayed on the AP dash board. The connectivity bar color is the yellow/brown color.

[Bruce]

Sounds like the SSID configuration is probably not the problem. You mention the AP has Static IP with no VLAN. If the AP has a static IP address then it shouldn't be using DHCP. If it is using DHCP then it means that its failed to contact the Meraki cloud using the statically configured IP address. Does the AP have DNS services and an IP gateway configured correctly too? (Or if you're using reservations on the DHCP server, just move it to DHCP).

[cmr]

@Kacy I'd change the AP to get its IP address from DHCP and that should clear the issue.  There is very little point in configuring static IP addresses on Meraki APs and if you really need it to stay the same then use a DHCP reservation.

[Kacy]

It has a dhcp reservation because it doesnt retain config when rebooted and will pull a dhcp address that is not allowed to use the same ports as the static IP. This is the same for other locations that do not have this issue. The static IP and the dhcp pool are in the same subnet. When the AP does not have a dhcp reservation it pulls an IP runs through the cycles of trying to connect to the portal when it fails it drops that IP and pulls another, then repeats. Yes the gateway and DNS are configured. This is a guest wifi it has no access to internal networks therefore cannot reach an internal DHCP server. The static IP is set in the network config of the AP in the Meraki portal, it was set this way because Just like other sites.

[cmr]

@Kacy if it is only used for public internet then why not use the DHCP server on the ASA, it clearly can get an IP from a DHCP server or you would not see the alert.  A DHCP reservation is where you set the MAC address of the device to always be given a particular IP on the DHCP server, a static IP is a manually configured address and although appearing similar is not the same.  You can set the reserved IP on the DHCP server to be the currently assigned static IP so the firewall rules work.

If the statically assigned IP is not in the public range and there is a trunk to the AP,  the VLAN that you want the AP's management port to be on does not have a DHCP server or possibility of relay then you will need to stick to the static IP method.

[Kacy]

DHCP is configured on the ASA along with the static arp entry, sorry I have been calling it dhcp reservation

The static IP in the Meraki portal is the same IP as the static arp entry. This works for other sites without issue. The static arp entry is in the public subnet, the switch port is not trunked, it set as access. There is no specific management connection.

The AP boots, requests an IP, the asa gives 192.168.1.10 because of the static arp entry. The AP takes the IP then reaches out to the portal and downloads the config that says its IP is the same as the static arp entry. If I reboot the AP it comes up fine and gets the config and is green. Leave it for a while and check back day or two later and its back to yellow with this error. 

[cmr]

@Kacy as you have static ARP and static IP, why not just use a DHCP reservation, it gives the same outcome and I'd be willing to bet that it fixes the problem.