I think my trouble is that I can’t set a static IP for the Control (maybe other devices too, but I don’t have any need for anything static just yet). The only way I know how to set a static IP is to go to the device and set the IP Address field.
If you don’t define the static address there, do you still experience the same connectivity issue? Does it only occur with an address applied?
Yes, only when applying a static address.
Update, I just tried removing the device configuration and then moving the Control back over to the Route 10 port that is configured for VLAN 460. Couldn’t connect.
Moved the Control back to the Default VLAN port on the 8 port switch so that I could connect and remove the 460 VLAN from the Route 10 port. Moved the Control back over to the Route 10 and I can connect on Default VLAN. Changed port from Default VLAN to 460 and now Control is on 460 with a DHCP address and I can connect (takes a few moments for the DHCP to kick over).
I’m on 1.0t for Control and 1.3v for Route 10.
My understanding is that when you set the MGMT VLAN at the device level, you’re inherently tagging that VLAN traffic. When you define NATIVE VLAN at the switchport level, you’re expecting Untagged traffic across the VLAN.
Test the following combination:
- Device configured for MGMT VLAN 460
- Switchport Native VLAN Default
- Switchport Allow VLAN 460
Further evidence: The tooltip of Allowed VLANs states, “All of these VLANS, except for the native LAN, will be tagged on this port.”
@larry.hafford, thanks for the reply and insight. I’m not sure how to set the MGMT VLAN on the Control. The APs and Switches have a setting for MGMT VLAN, but the Control and Route 10 do not.
As far as it looks right now, specifying a different MGT plan is not supported on control. Route10 doesn’t really have a specific MGT vlan you can specify. It would be serving up the MGT vlan as it is your router.
I feel pretty confident that the Native VLAN should reference the VLAN ID I want the device to communicate on. I just don’t understand how I can keep it on that VLAN and give it a static IP in the process.
This issue might now have been resolved by an update at least on Control(manage.alta.inc), as of today. From what I can see so far is that the surprising overrides of VLAN does not happen anymore. Fingers crossed. And, if it is not yet updated on the hardware Control, let’s hope it won’t be long. 
Thanks. I’ll be on the look out for this in on-prem Control version 1.0v
1 Like
@ebuckland81 I can also confirm that on release 1.0v I can now set the VLAN ID and DHCP reservation for the local hardware Control and it will get that IP on the next DHCP renew.
Thanks to @Alta-Josh and the team for getting this issue resolved. I also like how when you set the IP and the VLAN ID on the device, it’s now clearer that setting the VLAN ID is on the port and not the device itself.
1 Like