MX Layer 2 Functionality
Overview
While all LAN ports on all Meraki MX and Z-series devices can be configured with certain switchport settings, such as setting access or trunk mode, specifying VLANs to tag and allow, and applying access policies, these LAN ports do not function like standard switchports, and are not intended to function with full switching capabilities. As such, when connecting an MX to a more complex layer 2 network, additional planning may be required to ensure there are no issues with layer 2 traffic. This article describes the functionality and expected behavior of LAN ports on MX and Z-series devices, and how they handle and interact with layer 2 traffic and protocols. This article may be useful for:
-
Integrating an MX with a new or existing switched network
-
Optimizing the MX configuration for efficient operation
-
Troubleshooting potential layer 2 issues on your network
Please note that this article assumes familiarity with fundamental layer 2 concepts such as VLANs, broadcast traffic, and MAC forwarding.
MX Layer 2 Configuration Options
MX LAN ports can be configured under Security & SD-WAN > Configure > Addressing & VLANs, under Per-Port VLAN Settings.
Routed - Use VLANs Disabled
When the Use VLANs option is unchecked, all LAN ports will act as access ports with no VLAN configured. Any traffic received with a VLAN tag will be dropped, regardless of its IP destination.
Routed - Use VLANs Enabled
When the Use VLANs option is checked, the Per-port VLAN Settings will appear below the Subnets section, and individual LAN ports will follow these settings.
-
Enabled/Disabled: Determines whether the port will pass traffic or not.
-
Type - Access: The port will only send and receive untagged traffic, and any tagged traffic received on the port will be dropped.
-
VLAN: Traffic received from unknown MAC addresses will be recorded on the MX with the VLAN specified here. Only VLANs configured on the Addressing & VLANs page will be selectable.
-
Access Policy: Access Policies can only be configured on Access ports. More information on configuring access policies can be found in our MX Access Policies KB article.
-
-
Type - Trunk: Traffic can be sent and received from multiple VLANs, including untagged traffic.
-
Native VLAN: Untagged traffic will be recorded with this VLAN. Only VLANs configured on the Addressing & VLANs page will be selectable. If Drop untagged traffic is selected, all untagged traffic will be dropped by the port instead of recorded with a VLAN.
-
Allowed VLANs: Determines which VLANs can pass traffic on this port. You can select All VLANs (allowing all VLANs configured on the MX), or specify which VLANs to allow. At least one other VLAN must be selected here.
-
Passthrough Mode
When Passthrough or VPN Concentrator mode is enabled, the MX will act as a layer 2 bridge. All traffic received on a LAN port will be transmitted on the WAN port(s), and vice versa, regardless of VLAN or other layer 2 information.
MX Handling of Multicast Traffic
The MX does not interact with any type of multicast traffic. In effect, when multicast traffic is received on an MX LAN port, it is treated as broadcast traffic and is flooded out all other ports configured for the VLAN it was received on. This can cause unexpected behavior with protocols that leverage multicast, like CDP/LLDP, STP, LACP, VRRP, and others if not properly accounted for. The following sections describe how this particular behavior can affect some more commonly-used protocols on switched networks connected to the MX LAN.
Spanning Tree Protocol (STP)
Note: The MX does not run STP in any capacity, and will not exchange BPDUs with other switches or participate in the root bridge election process.
If the MX received BPDUs on the LAN, these BPDUs will be re-forwarded within the broadcast domain that they were received on. If there are multiple switches connected to the LAN of the MX participating in an STP election, all BPDUs sent to the MX will be forwarded to other links with the same VLAN allowed, which can cause switches to see BPDUs from multiple other switches, causing ports to get into an unknown/unidentifiable state and impacting the root bridge election process.
Below is a diagram illustrating how the STP election process can be affected by this MX LAN forwarding behavior - when 3+ switches are connected in the same broadcast domain, each switch will receive BPDUs from 2 or more switches on their connected uplinks. In the case of switches 2 and 3, the uplink is both a root port and a designated port from the switches' perspectives, causing the ports to go into an unknown state. In practice, this can also result in rapid STP port status changes for uplinks on multiple switches.
There are a few things that can be done to prevent this from occurring:
-
Avoid connecting more than two switches in the same STP domain directly to the LAN of the MX
-
Isolate the MX in its own broadcast domain by implementing Layer 3 switching downstream
The STP Root Bridge doesn't generate TCNs to notify of topology changes, only the non-root switches do. This can cause longer failover and STP convergence times and should be considered when setting up the root bridge and/or redundant links in the environment.
Note: STP convergence times may vary depending on the size of the network.
LACP & Link Aggregation
The MX does not run LACP or any link aggregation protocols. Connecting aggregated ports to the LAN of the MX is not supported; all connected ports should be un-aggregated. If multiple ports are connected to the MX from a single switch for redundancy, it is highly recommended that you run STP on that switch, to ensure that one of the redundant ports is safely put into a blocking state.
LLDP/CDP
The MX will send its own LLDP information to its directly connected links. Unlike MS and MR products, however, the MX will not run CDP.