Cisco Meraki MX and MS: VLANs and Switch Port Profiles

Meraki pushes almost all configuration from the cloud dashboard, which changes the troubleshooting model: a port that carries the wrong VLAN is usually a dashboard object mismatch rather than a CLI typo. This guide explains how MX VLANs, MS switch port profiles and Auto VPN relate to each other, and gives the dashboard checks that isolate a misrouted access port or a site-to-site tunnel that refuses to come up.

The three layers to keep straight

• MX VLANs (Security & SD-WAN > Appliance > VLANs) define the routed subnets, the DHCP server behaviour and whether an MX port is in trunk or access mode.
• MS port profiles (Switch > Switch settings > Port profiles) are reusable templates that assign a VLAN, voice VLAN, PoE, STP and 802.1X settings to a group of ports.
• Auto VPN builds the IPsec mesh between MX devices, advertising each MX's VLAN subnets into the overlay.

Step 1: define VLANs on the MX

Security & SD-WAN > Appliance > VLANs
  VLAN 1   default, DHCP enabled, subnet 192.168.1.0/24
  VLAN 10  "Users",     DHCP enabled, subnet 10.10.10.0/24, MX IP .1
  VLAN 20  "Voice",     DHCP enabled, subnet 10.10.20.0/24, MX IP .1
  VLAN 30  "Servers",   DHCP disabled (static), subnet 10.10.30.0/24

Addressing & VLANs > VLAN 10 > "Auto VPN: advertise this subnet" = Yes

Only subnets marked for advertisement appear in the Auto VPN route table of the other sites. A site that can reach local resources but not remote ones almost always has one VLAN missing this tick.

Step 2: build port profiles instead of per-port edits

Switch > Switch settings > Port profiles > Add profile
  Name:   ACCESS-USERS
  Type:   Access
  VLAN:   10
  Voice VLAN: 20
  Spanning tree: Edge (PortFast)

  Name:   TRUNK-UPLINK
  Type:   Trunk
  Allowed VLANs: 1,10,20,30
  Native VLAN: 1

Switch > Ports > select ports 1-12 > Assign profile: ACCESS-USERS

Profiles keep the configuration idempotent: changing VLAN 10's ID in one place re-provisions every port that uses the profile. Reserve manual per-port overrides for genuine exceptions, because they silently drift when profiles change.

Step 3: verify forwarding on the switch

Switch > Ports  ->  per-port "Status / Live tools / Cable test / Cycle port"
Switch > Live tools > "Port usage"  ->  utilisation and errors per port
Switch > Switch settings > STP       ->  per-VLAN root and blocking ports

A port that shows Up but no client traffic usually means the assigned VLAN does not match the client's expectations (untagged frames landing in VLAN 1, or a DHCP scope that does not exist on that VLAN).

Step 4: confirm Auto VPN and the advertised routes

Security & SD-WAN > Site-to-site VPN
  Topology:        Hub-and-spoke / Full mesh
  Hubs:            HQ MX
  Subnets:         tick per-VLAN advertisement
  Local networks:  add any non-Meraki subnets that must be reachable

Security & SD-WAN > Site-to-site VPN > Status
  -> shows per-peer tunnels, last success, and advertised vs received subnets

If a tunnel reaches Up but a subnet is unreachable, compare the "advertised" column at the hub against the local subnet list. A summary route configured on the MX with Local networks overrides the per-VLAN advertisement.

Troubleshooting order that saves time

1. Confirm the client's gateway is the MX VLAN interface (10.10.10.1), not another device.
2. Confirm the switch port profile matches the intended VLAN and that the port is Edge/PortFast for a host.
3. Confirm the VLAN is advertised in Auto VPN at both ends.
4. Only then look at upstream firewall rules — most "Meraki problems" are routing or VLAN placement.

Related reading: Cisco Catalyst SD-WAN architecture and components, ArubaOS-Switch VLAN tagging and trunk configuration, and Cisco DHCP snooping configuration.

原文链接：https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Switch_Port_Profiles