Changelog: New Features in MS10

Changelog: New Features in MS10

Several new switch features were introduced in Meraki’s MS10 firmware including loop guard, DIA, storm control, and LAN anomaly detection for improved control-plane monitoring and stability.

This serves as a quick look into some of the new enhancements available. More information including a full list of features can be found in the detailed firmware change notes within the Meraki Dashboard (Organization > Firmware upgrades page).

Switch Storm Control

Platform availability: MS210, 225, 250, 350, 410 and 425

Storm control is a switch feature that enables additional administrative controls for broadcast, unknown unicast and multicast traffic entering a switch port. Unlike unicast frames, these 1:many traffic types can quickly add an unnessecary level of noise to the LAN switch fabric. Worse, a single misbehaving client or application can lead to switch port saturation, drowning out critical appliation, management, or control-plane traffic. Storm control aims to solve that.

In this implementation of storm control, thresholds are used for each traffic type expressed as a percent of the total port bandwidth. The storm control service monitors traffic levels in one second intervals. If traffic exceeds the defined limit, excess packets will be dropped. The defined rate is applied to each port based on the port’s total available bandwidth.

meraki storm control example configuration
Storm control can be configured under Switch > Switch Settings

Loop Guard

Loop guard is a Spanning-Tree Protocol extension added as a protective mechanism against unanticipated switch forwarding loops. If STP BPDU’s are not received on a loop guard enabled non-designated port, the port is put into an inconsistent state and functions identically to a port in blocking state.

Loop Guard Details

The minutia of Spanning Tree extensions isn’t something most network professionals dig into frequently, so here’s a quick primer on loop guard.

Switch loops are formed when a STP blocking port in a redundant topology transitions to a forwarding state. This often is the result of one switch port (in a redundant connectivity setup) no longer recieving BPDUs. STP relies on the continuous transmission of BPDUs throughout the switch fabric to determine port roles and redundant paths. In STP parlance, designated ports send BPDUs and non-designated ports listen for BPDUs.

When a redundant port in blocked state stops hearing BPDUs (perhaps due to a 1-way fiber connection or buggy switch software upstream), it:

  1. Assumes the topolology is now loop-free
  2. The blocked port (technically in alternate or backup state) is promoted to designated and starts forwarding

This condition creates a L2 loop.

Loop guard adds additional checks to the BPDU listening process for situations like this. If STP BPDUs are not received on a non-designated port running loop guard, it moves to a loop-inconsistent blocking state. If this sounds similar to UDLD (Unidirectional Link Detection) then you’re correct. It solves effectively the same one-way BPDU challenges, although loop guard is better suited for protecting against STP control-plane and software processing problems.

meraki ms spanning tree loop guard configuration
Loop guard can be configured under Switch > Switch ports

STP and LAN Anomaly Detection

Multiple enhancements have been added in MS10 for identifying and debugging STP or link problems. When viewing the list of ports on a switch in Dashboard, the connectivity bar will take into account L1 link errors (e.g. bad CRC) or excessive STP topology change notifications, and for the durations these persist, the bar will be colored red or orange based on severity. Sorting by connectivity bars will now give the highest weighting to these sorts of errors, so they will all appear at the top of the list.

Additionally, there is a new event log category: STP BPDU sender conflict. These events are created when the following switch port conditions are met:

  1. The port is in RSTP (not legacy STP) mode
  2. The port is full duplex
  3. Multiple BPDUs are received within a small window that identify different sending ports
  4. The port link state has not changed between receiving such BPDUs

Rapid Spanning Tree, which runs by default on Meraki switches, assumes point to point links on full duplex interfaces. This is useful for enabling rapid switch-to-switch STP proposal/agreements throughout the switch “tree” for fast, loop-free LAN convergence.

Because RSTP makes the assumption that two switches on a point-to-point, full duplex link are directly connected, a switch expects to only receive BPDU from 1 source on each port. If however a hub is connected to the port and there are multiple switches connected to the hub, the switch will receive multiple BPDU’s from different sources on a single port. This is not desirable and a “STP BPDU sender conflict” message will be logged in the Event log to alert this.

meraki ms stp bpdu sender conflict

This new STP error reporting is automatically enabled by default and doesn’t require administrator configuration in Dashboard.

Dynamic ARP Inspection

Platform availability: MS210, 225, 250, 350, 410 and 425

Dynamic ARP Inspection, commonly abreviated as DAI, protects against man-in-the-middle ARP spoofing attacks. It is configured on a per-port basis and should only be configured on edge ports which lead to client devices.

If a port has DAI enabled, the switch will begin inspecting all ARP packets entering the port, specifically looking at the source IP and MAC address. If the source IP and MAC seen does not match an IP-to-MAC assignment that the switch snooped in a previous successful DHCP transaction then the ARP frames are dropped to prevent the bad actor.

As an example, let’s assume a DAI is enabled on a given Meraki switch port where a client (MAC of 11:22:33:44:55:66) is assigned an IP address of 172.16.1.100 by the local DHCP server. If an ARP packet then enters the port with a source IP of 172.16.1.100 but a MAC of aa:bb:cc:dd:ee:ff, this does not match the assignment snooped from the DHCP transaction and the ARP packet is dropped.

This is a compliment to the existing DHCP server monitoring and containment features. DAI is effective for reducing the risk of man-in-the-middle client attacks while DHCP server containment helps prevent rogue DHCP services from being introduced into the LAN (from either malicious or unintentional sources).

meraki switch dia configuration
Dynamic ARP Inspection can be enabled under Switch > DHCP Servers and ARP

After enabling DIA, switch port trust posture can be configured on the Switch > Switch portsĀ configuration page. All edge ports are untrusted by default and therefore will be inspected for source IP/MAC mismatches.

enabling dia on meraki switch port

The Changelog series is an opportunity for to highlight the constant, behind-the-scenes updates to the Meraki cloud Dashboard that many operators aren’t aware of. Part of what makes the Cisco Meraki platform so compelling is the pace at which the Engineering and UI teams continue to iterate and improve the management experience. Featuring updates gives the community better insight into the elements being delivered. And, new is fun.