Problems while initializing a LAN enviroment based on MS150's: switch mgmt ip assignment

[WojtekMitus]

Hi, we have yet another problem with the switches removed from an existing network in portal. As Alessandro clarified in another post, the switches are factory defaulted and restarted when they are removed from network.

So we are removing the entire network manually from portal, and example switch which was a part of that network is factory defaulting an restarting, and then it tries to get an in band management address (out of band management ports are not connected).

The site's topology is such, that central aggregation stack of two MS150's is connected to two Cisco SDWAN routers, with trunked ports, where there are around 10 different VLAN's. SVI's for these VLAN's are on SDWAN routers, and most of them has a DHCP helper directing DHCP requests to an external DHCP server.

We would expect that factory defaulted MS150 while restaring, should query for DHCP assignment only on native (untagged) vlan, but we see factory defaulted and rebooting switches getting in band management IP's from a random tagged VLAN's present on the router's trunk. Not all of these VLAN's networks are allowed to get to the internet, so not all of the switches are able to connect to Meraki portal. It seems that sometimes a factory defaulted switch, which is booting first time after config reset, will get an IP from a native untagged VLAN on trunk (correct), but sometimes it gets an IP from a tagged VLAN (incorrect), and then it is not able to reach portal, as we are allowing portal reachability only from one vlan, which is untagged on the trunk connecting SDWAN routers to the aggregation layer MS150's. 

Could anyone tell how this actually works, and what we could do to prevent factory defaulted switches from querying DHCP for a management IP on tagged VLAN's? How it's even possible that they know VLAN ID's present on the network, if they are factory defaulted?

Thanks,

Wojtek

[alemabrahao]

This behavior is not compatible with VLANs, as you would expect from a fully configured switch. The switch does not "know" which VLANs are tagged or not, so it just listens for DHCP offers and accepts the first one that works.

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

As suggested, temporarily isolate the switches during provisioning.

[WojtekMitus]

Hi Alessandro, i don't fully understand. To get any DHCP offer from a VLAN different than native on the trunk, the switch first has to send DHCP query tagged with that VLAN tag. Only then router will reply with DHCP offer from that particular VLAN, also tagged with the same VLAN tag. We are observing factory defaulted switches getting IPs' in different, tagged VLAN's (this is visible in ARP cache of the SDWAN routers). So the switch had to produce a DHCP query with some particular VLAN ID tag to get an DHCP offer in that VLAN, so in turn it had to be aware of that particular VLAN ID being active on the network (unless of course it tried all possible VLAN ID's).

Is it trying to query DHCP with all possible VLAN ID's? Is that what they mean by querying "Alternate VLAN"?

Is "config not safe" behavior relevant to an IP address acquisition procedure of a factory defaulted switch? Referring to isolation - we are observing this behavior also in the network with redundancy removed and no STP loop occuring. How further isloation would help here?

Thanks,

Wojtek

[alemabrahao]

No, it does not actively try all VLANs. There is no VLAN scanning or probing behavior in factory default mode. The switch simply sends untagged DHCP Discover on its native VLAN e accepts the first valid DHCP Offer it receives, regardless of the VLAN it came from.
This is what Meraki sometimes refers to as “alternate VLAN” behavior, not that it probes VLANs, but that it may accept an IP from a VLAN other than the intended one if the network allows it.