Meraki devices not using their static assigned IP when removing the management VLAN in native trunk

[Kurn]

Hi! I'm afraid my problem already exists, but I haven't found any topics similar to mine. Thanks in advance if you find one!

So here we go, my Meraki devices are today configured with static IPs on the Meraki dashboard (switches and APs). Until now, they were retrieving their IP addresses with DHCP because the management VLAN used for the switches and access points was declared as native VLAN on the uplink port configuration.

In order to secure and apply best practices (unless I'm mistaken), I wanted to set the native uplink trunk port of the distribution and core switches to trash/unrouted VLAN.

I checked beforehand that they all had their IP addresses set to static. However, once I switched the uplink trunk port to native trash VLAN (on both sides, the port that connects my distribution switch to the core switch), my distribution switch was assigned a completely random IP address from one of the other VLANs allowed in the trunk port and did not take the defined IP address of my management VLAN (VLAN which is also declared and allowed in the trunk config port).

I should point out that I have a network switch containing the cores, which delivers to three distributed switch networks (three different locations in our large building). Only one distributed switch network is not working. All the others have taken the static IP address, not facing the problem i'm explaining upside.

I could post photos of the cloud dashboard if that would help.

Thanks in advance!

[alemabrahao]

When you changed the native VLAN to a "trash/unrouted" VLAN, the switch port may no longer be tagging the management VLAN traffic correctly. If the management VLAN is not explicitly tagged on the trunk, and the native VLAN is no longer the management VLAN, the switch might not be able to reach the Meraki cloud using its static IP.
Them Meraki devices will fall back to DHCP if they can’t reach the cloud with their static IP. This is likely why you’re seeing a random IP from another VLAN, it’s trying to get online via any available path.

[Kurn]

Thanks for the fast answer.

What confuses me is that I did mention the VLAN ID in the switch's IP configuration. Why wouldn't it tag itself on the trunk?

Here is a fictive image. Let's say that I tag my switch in VLAN 280 with an uplink trunk port configured as native VLAN 999 but VLAN 280 is allowed on that port. The device should work with static IP assigned?

Because for now, if the uplink native VLAN is on 280, the switch is going to work with DHCP, getting an IP on that VLAN and reaching Meraki Cloud without any problem.

[RWelch]

VLAN 999 is the native VLAN or the default VLAN for untagged traffic and you have specified that in the uplink (port) config so the switch is looking for untagged routable traffic via VLAN 999.

That is what the switch is expecting.

You are then configuring the static IP with VLAN 280 info which is a tagged VLAN (but the switch is still looking for native VLAN or untagged data).

[Kurn]

So if I understand correctly, the native VLAN of every uplink trunk (port) config should be the VLAN of the switch on a Meraki switch?

I thought I could put instead a trash VLAN in native VLAN as my switch could tag itself with the VLAN 280 I set in the switch config.

[RWelch]

No, the native VLAN for your Meraki switch doesn't have to match the VLAN ID of the switch itself. It can be any VLAN in your network, but there are important caveats.

If you set a "trash" or non-routable VLAN as the native VLAN, it will cause issues with your Meraki switches because they need a routable VLAN for communication with the Meraki Dashboard. The native VLAN should be routable and configured in a way that allows your switches to reach the dashboard for management purposes.

Also, leaving the native VLAN ID blank effectively drops untagged traffic, but it can break other things like Spanning Tree Protocol, so it’s not ideal for larger networks with mixed vendors.

When integrating Meraki with other vendors, be aware of potential Multiple Spanning Tree compatibility issues as well.

In the end, the native VLAN can be any VLAN you choose, but it must be routable for the switches to communicate properly with the Meraki cloud.

[RWelch]

Meraki switches need to stay connected to the dashboard to keep things running smoothly.

The cloud-based Meraki dashboard takes care of all the management, setup, and reporting for the devices.

So even if the dashboard goes down for a bit, the switches can still send and receive traffic.

But, to keep everything working perfectly and up-to-date, they need a reliable internet connection to fetch the latest configurations and stay fully operational. 

[RWelch]

> In order to secure and apply best practices (unless I'm mistaken)

Are you applying Meraki best practices or other vendor switch best practices?

[RWelch]

If you are trying to reduce the possibility of VLAN hopping (typically tied to VLAN 1), you can change the native VLAN ID from VLAN 1 to VLAN 280.

If you decide to change the native VLAN ID, be sure to also change it in the Dashboard by going to:

Switching > Configure > Switch Settings under VLAN configuration.

 

[PhilipDAth]

Be careful doing this.  Spanning tree uses the untagged VLAN.  It is easy to cause intermittent outages when the switches don't form a consistent view of the network.

Personally, 99% of the time, for Meraki switches to Meraki switches and Meraki MX to Meraki switch links, I only use a native VLAN of 1.

I have had too many outages caused by spanning tree over the years.