¶ KBA-044 - Meraki MX — LAN Port Behaviour and Limitations
Summary Explains how Meraki MX LAN ports differ from traditional switch ports, covering VLAN handling, STP, unsupported features, and design considerations that can cause problems in practice.
Meraki MX appliances include several LAN ports that can be configured as access or trunk ports, which can give the impression that they behave like ports on a managed switch. They do not. The MX is a security appliance and router — its LAN ports are entry points into a routing and firewall engine, not a switching fabric. Understanding this distinction is essential before designing any network that relies on MX LAN port behaviour.
The practical consequence is that many things engineers expect from a switch port — STP participation, LACP, port mirroring, 802.1x, dynamic trunking — are either absent or behave differently on an MX LAN port.
¶ VLAN Configuration and Trunk Behaviour
On a traditional switch, a trunk port carries all VLANs by default (or a permitted range configured per-port). On an MX, a trunk port only passes VLANs that have been explicitly configured as subnets in the Meraki dashboard. If a VLAN is not defined on the MX, tagged frames for that VLAN are silently discarded regardless of how the downstream switch is configured.
This means:
- Adding a new VLAN to a downstream switch does not automatically make it available through the MX trunk. The VLAN must be created in the dashboard first, with a subnet and gateway IP assigned to the MX interface.
- The MX is always the Layer 3 gateway for every VLAN it carries. There is no concept of a passthrough VLAN where the MX forwards frames transparently without being the routing boundary.
- Native VLAN behaviour on MX trunk ports follows 802.1Q conventions, but the native VLAN must also be a configured subnet on the MX if inter-VLAN routing is required.
⚠️ No STP Participation: The MX does not run Spanning Tree Protocol on its LAN ports. This is the most operationally dangerous difference from a switch port.
On a traditional switch, STP prevents Layer 2 loops by blocking redundant paths. Because the MX does not participate in STP, it has no awareness of the spanning tree topology and does not send BPDUs. The practical implications are:
- If two MX LAN ports are connected to the same switch (directly or indirectly), this creates a Layer 2 loop that STP on the switch will not be able to detect across the MX boundary. Broadcast storms can result.
- If you connect two switches to separate MX LAN ports on the same VLAN, Layer 2 traffic can loop between them through the MX without being blocked.
- The MX cannot be used as a redundant uplink device in any topology that relies on STP for loop prevention.
The safe design is a strict star topology: each MX LAN port connects to a single downstream switch with no inter-switch paths that pass through the MX.
On the MX, inter-VLAN routing is always active and handled by the MX itself. Every VLAN configured on the MX has the MX as its default gateway, and traffic between VLANs is always routed through the MX's firewall and routing engine. There is no way to disable this without using Layer 3 firewall rules to block the specific traffic.
This differs from environments where a separate router or L3 switch controls inter-VLAN routing, because:
- All inter-VLAN traffic is subject to MX Layer 3 firewall rules. Rules must be explicitly configured to permit or deny traffic between VLANs.
- The default MX behaviour is to permit all inter-VLAN traffic unless rules are added. In a Meraki deployment with multiple VLANs, this means all VLANs can reach each other out of the box.
- Performance for inter-VLAN traffic is bounded by the MX's routing throughput, not by the switch fabric. High-volume inter-VLAN flows (e.g., backup traffic between server VLANs) should be factored into MX sizing.
Traffic between devices on the same VLAN connected to MX LAN ports is handled at Layer 2 via the MX's internal switch chip. The MX does not route this traffic. However, the MX security engine still processes this traffic on some models for threat detection and content inspection purposes. The exact behaviour varies by model and firmware version and is not clearly documented by Meraki.
The practical consequence is that intra-VLAN throughput between endpoints directly connected to MX LAN ports may be lower than equivalent traffic through a dedicated switch, and in some configurations the MX's security policies may affect intra-VLAN traffic in ways that are not visible in the Layer 3 firewall rules.
The following features common on managed switch ports are not available on MX LAN ports:
- LACP / Link Aggregation — MX LAN ports do not support port channels or LACP on most models. Each port is independent; there is no mechanism to bond two MX LAN ports for redundancy or additional bandwidth.
- 802.1x Port Authentication — the MX does not support port-based NAC on its LAN ports. If 802.1x is required at the access layer, it must be implemented on downstream Meraki MS or Cisco Catalyst switches.
- SPAN / Port Mirroring — there is no facility to mirror traffic from MX LAN ports to a monitoring device. Packet capture on the MX is available through the dashboard but is limited to sampling and cannot replicate the continuous full-fidelity capture that SPAN provides.
- VTP / DTP — MX ports do not support Cisco proprietary protocols for VLAN propagation or dynamic trunk negotiation. All port configurations (access or trunk, VLAN assignments) must be set manually in the dashboard.
- Storm Control — MX LAN ports have no configurable storm control thresholds. In a broadcast storm scenario, the MX provides no protection beyond whatever the downstream switch applies before traffic reaches the MX.
MX Layer 3 firewall rules are applied to traffic between VLANs as it passes through the MX routing engine. The rule direction (inbound vs outbound) is defined relative to the MX's own interface, not from the perspective of connected endpoints. This can lead to unintuitive rule ordering if engineers are accustomed to writing ACLs from an endpoint-facing perspective.
Key points:
- L3 firewall rules do not apply to intra-VLAN traffic between devices on the same subnet connected to MX LAN ports.
- Rules that deny traffic from a specific VLAN to another are applied at the routing step, after the MX has received the packet from the source VLAN interface and before it forwards it to the destination VLAN interface.
- Group policies applied to specific clients can override the default firewall rules and allow finer-grained per-device control within a VLAN.
Given the limitations above, MX LAN ports are best used as uplinks to downstream switches rather than as direct endpoint connections. The recommended pattern is:
- Connect each MX LAN port to a single downstream switch as a trunk or access uplink.
- All endpoint connectivity and port-level features (STP, LACP, 802.1x, SPAN, storm control) are handled by the downstream switches.
- Avoid connecting more than one MX LAN port to the same Layer 2 broadcast domain unless the downstream switch infrastructure is carefully designed to prevent loops — and even then, this is an advanced configuration that requires explicit validation.
- Do not rely on dual MX LAN port connections for redundancy. If uplink redundancy from a switch to the MX is required, consider Meraki MX warm spare (HA) mode with a virtual IP, which provides appliance-level redundancy without requiring multiple LAN ports into the same switch.