Best Practice Design - MS Switching

Layer 2 Features

• STP

  • RSTP is enabled by default and should always be enabled. Disable only after careful consideration.

  • PVST interoperability (Catalyst/Nexus)

    • VLAN 1 should be allowed on a trunk between Catalyst and MS. This is crucial for RSTP

    • Make Catalyst the root switch

  • Set root switch priority to “0 - likely root”

    • Higher end models such as the MS410, MS425 deployed at core or aggregation are suitable candidates for the role

    • Ideally, the switch designated as the root should be one which sees minimal changes (config changes, link up/downs etc.) during daily operation

 

 

• Keep the STP diameter under 7 hops, such that packets should not ever have to travel across more than 7 switches to travel from one point of the network to the other
• BPDU Guard should be enabled on all end-user/server access ports to avoid rogue switch introduction in network
• Loop Guard should be enabled on trunk ports that are connecting switches 
• Root Guard should be enabled on ports connecting to switches outside of administrative control

 

• MTU

  • Recommended to keep at default of 9578 unless intermediate devices don’t support jumbo frames. This is useful to optimize server-to-server and application performance. Avoid fragmentation when possible.

 

• Switchports

  • Trunk

    • Prune unnecessary VLANs off trunk ports using allowed VLAN list in order to reduce scope of flooding

    • Ensure that the native VLAN and allowed VLAN lists on both ends of trunks are identical. Mismatched native VLANs on either end can result in bridged traffic

    Tagging

    • For ease of management, assign tags to switch ports. For example, switch<->switch links can be assigned “trunk”, switch<->AP can be “wireless” etc

  • Aggregation

    • Only LACP is supported for link aggregation. Ensure the other end supports LACP

    • It is recommended to configure aggregation on the dashboard before physically connecting to a partner device

 

 

• UDLD (Unidirectional Link Detection)
  • This should be enabled on fiber trunks - in “Alert Only” mode
• Link Negotiation
  • This should be set to auto-negotiate for ports connecting Meraki devices
  • Use “forced” mode only if a device connected to the port does not support auto-negotiation

 

• Switchport count in a network
  • It is recommended to keep the total switch port count in a network to fewer than 8000 ports for reliable loading of the switch port page.

Layer 3 Features

• IP addressing and subnetting schema
  • Dedicate /24 or /23 subnets for end-user access
  • Avoid overlapping subnets as this may lead to inconsistent routing and forwarding

• L3 Interfaces

  • Assign a dedicated management VLAN

  • Avoid configuring a L3 interface for the management vlan. Use L3 interfaces only for data VLANs. This helps in separating management traffic from user data

• Access Control Lists (ACLs)

  • Summarize IP addresses as much as possible (before-after examples below).

 

 

 

• Maximum ACL limit is 128 access control entries (ACEs) per network
  Take control over your network traffic. Review user and application traffic profiles and other permissible network traffic to determine the protocols and applications that should be granted access to the network. Ensure traffic to the Meraki dashboard is permitted (Help > Firewall Info)

 

• OSPF
  • Found under Switching > Configure > OSPF Routing
  • All configured interfaces should use broadcast mode for hello messages
  • We recommend leaving the “hello” and “dead” timers to a default of 10s and 40s respectively. If more aggressive timers are required, ensure adequate testing is performed.
  • Ensure all areas are directly attached to the backbone Area 0. Virtual links are not supported
  • Configure a Router ID for ease of management

 

 

• With multiple VLANs on a trunk, OSPF attempts to form neighbor relationships over each VLAN, which may be unnecessary. To exchange routing information, OSPF doesn’t need to form neighbor relationships over every VLAN. Instead, a dedicated transit VLAN can be defined and allowed on trunks, typically between the core and aggregation layers with OSPF enabled and “Passive” set to “no.” For all other subnets that need to be advertised, enable OSPF and set “Passive” to “Yes.” This will reduce unnecessary load on the CPU. If you follow this design, ensure that the management VLAN is also allowed on the trunks.

 

 

• Configure MD5 authentication for added security

 

 

• DHCP

  • Specify allowed DHCP servers to protect against rogue servers

  • In a warm spare configuration, the load balancing mechanism for DHCP, in some case, may be inefficient and cause an issue where devices may try to get an address from a member with no leases remaining. This is addressed in a stacked configuration, where this issue will not occur.

Topology

 

• We highly recommend having the total switch count in any dashboard network to be less than or equal to 400 switches. If switch count exceeds 400 switches, it is likely to slow down the loading of the network topology/ switch ports page or result in display of inconsistent output.

 

Multicast

• The most important consideration before deploying a multicast configuration is to determine which VLAN the multicast source and receivers should be placed in. If there are no constraints, it is recommended to put the source and receiver in the same VLAN and leverage IGMP snooping for simplified configuration and operational management.

 

 

• Multicast Routing

  • Meraki switches provide support for 30 multicast routing enabled L3 interfaces on a per switch level

  • PIM SM requires the placement of a rendezvous point (RP) in the network to build the source and shared trees. It is recommended to place the RP as close to the multicast source as possible. Where feasible, connect the multicast source directly to the RP switch to avoid PIM’s source registration traffic which can be CPU intensive. Typically, core/aggregation switches are a good choice for RP placement

  • Ensure every multicast group in the network has an RP address configured on Dashboard

  • Ensure that the source IP address of the multicast sender is assigned an IP in the correct subnet. For example, if the sender is in VLAN 100 (192.168.100.0/24), the sender's IP address can be 192.168.100.10 but should not be 192.168.200.10.

  • Make sure that all Multicast Routing enabled switches can ping the RP address from all L3 interfaces that have Multicast Routing enabled

  • Configure an ACL to block non-critical groups such as 239.255.255.250/32 (SSDP). As of MS 12.12, Multicast Routing is no longer performed for the SSDP group of 239.255.255.250. 

• IGMP Snooping

  • Disable IGMP Snooping if there are no layer 2 multicast requirements. IGMP Snooping is a CPU dependent feature, therefore it is recommended to utilize this feature only when required. For example, IPTV.

  • It is recommended to use 239.0.0.0/8 multicast address space for internal applications

  • Always configure an IGMP Querier if IGMP snooping is required and there are no Multicast routing enabled switches/routers in the network. A querier or PIM enabled switch/router is required for every VLAN that carries multicast traffic.

 

High Availability and Redundancy

Quality of Service

• Classification

  • Identify different traffic classes within the network for prioritization. On a high level, traffic can be classified based on VLAN (user, voip, network control etc)

  • You can further classify traffic within a VLAN by adding a QoS rule based on protocol type, source port and destination port as data, voice, video etc.

  • Typical enterprise traffic classes are listed below:

 

 

• Marking

  • Meraki MS supports trusting or remarking of incoming DSCP values. Meraki MS supports marking (remarking/trusting) based on DSCP values only. CoS values carried within Dot1q headers are not acted upon. If the end device does not support automatic tagging with DSCP, configure a QoS rule to manually set the appropriate DSCP value.

 

 

• CoS markings within a Dot1q header are not preserved by default since MS switches support DSCP markings only.

• Queueing and Scheduling

  • Assign an appropriate Class-of-Service queue to each DSCP value

 

 

• An MS network has 6 configurable CoS queues labeled 0-5. Each queue is serviced using FIFO. Without QoS enabled, all traffic is serviced in queue 0 (default class) using a FIFO model. The queues are weighted as follows:

 

CoS	Weight
0 (default class)	1
1	2
2	4
3	8
4	16
5	32

 

Take, for example, a switched environment where VoIP traffic should be in CoS queue 3, an enterprise application in CoS queue 2, and all of other traffic is unclassified. The percentage of bandwidth allocation can be calculated using the weight of the individual CoS queue as the numerator and the sum of all configured CoS queues as the denominator (in this example 8+4+1=13):

• VoIP would be guaranteed 8/13 or ~62% percent of the bandwidth. The switch would forward 8 frames from the CoS queue 3 and move to CoS queue 2.

• The enterprise application would be guaranteed 4/13 or ~30% bandwidth.The switch would forward 4 frames from the CoS queue 2 and move to the default queue.

• All other traffic would receive 1/13 or ~8% of the bandwidth. The switch would forward 1 frame from the default queue, then cycle back to CoS queue 3.

 

Based on the information above, determine the appropriate CoS queue for each class of traffic in your network. Remember, QoS kicks in only when there is congestion so planning ahead for capacity is always a best practice.

 

Cabling Best Practices for Multi-Gigabit operations

 

While Category-5e cables can support multigigabit data rates upto 2.5/5 Gbps, external factors such as noise, alien crosstalk coupled with longer cable/cable bundle lengths can impede reliable link operation. Noise can originate from cable bundling, RFI, cable movement, lightning, power surges and other transient event. It is recommended to use Category-6a cabling for reliable multigigabit operations as it mitigates alien crosstalk by design.

 

 

Campus Design

This document will walk through the configuration of an ideal campus network design with Meraki hardware, using a theoretical, recommended environment.

Topology

We highly recommend having the total switch count in any dashboard network to be less than or equal to 400 switches. If switch count exceeds 400 switches, it is likely to slow down the loading of the network topology/ switch ports page or result in display of inconsistent output.

QoS Considerations in the Campus

In any campus deployment, traffic prioritization is key to keeping critical network applications run­ning, even under heavy load. This is done through the use of Quality of Service (QoS) configuration. The simplest explanation of QoS is the prioritization of traffic, ensuring that important or latency-sensitive traffic will get bandwidth before less demanding traffic. To read the guide for QoS on Meraki refer to our MS QoS documentation.

 

The table below lists the commonly used DSCP values as described by RFC 2475. To keep things standardized it’s recommended to utilize these values, unless the deployment already uses a differ­ent set of values.

 

DSCP VALUE	DECIMAL	VALUE MEANING	DROP PROBABILITY	EQUIVALENT IP PRECEDENCE VALUE
101 110	46	High Priority Expedited Forwarding (EF)	N/A	101 - Critical
000 000	0	Best Effort	N/A	000 - Routine
001 010	10	AF11	Low	001 - Priority
001 100	12	AF12	Medium	001 - Priority
001 110	14	AF13	High	001 - Priority
010 010	18	AF21	Low	001 - Immediate
010 100	20	AF22	Medium	001 - Immediate
010 110	22	AF23	High	001 - Immediate
011 010	26	AF31	Low	011 - Flash
011 100	28	AF32	Medium	011 - Flash
011 110	30	AF33	High	011 - Flash
100 010	34	AF41	Low	100 - Flash Override
100 100	36	AF42	Medium	100 - Flash Override
100 110	38	AF43	High	100 - Flash Override
001 000	8	CS1	-	1
010 000	16	CS2	-	2
011 000	24	CS3	-	3
100 000	32	CS4	-	4
101 000	40	CS5	-	5
110 000	48	CS6	-	6
111 000	56	CS7	-	7
000 000	0	Default	-	-
101 110	46	EF	-	-

To help with the reasoning behind the above chart, here’s the IP precedence priority from lowest to highest as per the RFC 791.
 

DSCP VALUE	DESCRIPTION
000 (0)	Routine or Best Effort
001 (1)	Priority
010 (2)	Immediate
011 (3)	Flash - Mainly used for Voice Signaling for for Video
100 (4)	Flash Override
101 (5)	Critical - mainly used for Voice RTP
110 (6)	Internet
111 (7)	Network

We’ll want to mirror the rest of the network deployment on the access switches so that QoS is the same across the network, so match default Cisco settings we’ll be setting the following:

 

CoS Value	0	1	2	3	4	5	6	7
DSCP Value	0	8	16	24	32	40	48	56
DSCP Values	0	8, 10	16, 18	24, 26	32, 34	40, 46	48	56
CoS Values	0	1	2	3	4	5	6	7

You’ll configure these under Switching > Configure > Switch settings and define the QoS through the user interface:

 

Security Settings

With QoS out of the way and traffic prioritized correctly, any network admin who wants to make sure they have the most control of their network will want to implement security settings. To achieve this, we can use the DHCP server detection mechanism and set it to automatically block new DHCP servers on the network. This will allow the network to remain resilient against people trying to reroute hosts and people who’ve accidentally plugged in something that they should not. This enables us to then allow the servers that should be handing out DHCP addresses to keep the network up and operational.

 

 

Another important area of campus deployment security is authentication. Most security-minded deployments will have a RADIUS server to authenticate clients within the network. The Meraki switch line can integrate with a RADIUS server to provide authentication via 802.1x or MAC Authentication Bypass (MAB) on any switch port. This allows control over who connects and the resources accessible to them. With the MS switch line, either is allowed. Alternatively, a deployment could also use a hybrid mode which will first attempt 802.1x and fall back to MAB before choosing to not allow the client access or move them into a guest or remediation VLAN. It is highly recommended to set up a remediation VLAN to isolate unauthorized, guest or non-compliant devices.

 

In addition to the authentication methods mentioned above, Meraki also includes a RADIUS server monitoring mechanism within the switch line to enable use of Hybrid Auth, whereby if the RADIUS server is offline, clients will be bounced for re-authentication when the server is available again. This allows a re-prompt login for clients so that they can get network resources when authentication is available, without manual intervention. Use of this particular feature is up to the design of the network, but is extremely useful if the network utilizes a data center or cloud hosted radius server that might become unreachable.

 

As with any of the above security considerations, no network is complete without the use of Access Control Lists (ACLs) to be able to keep traffic restricted between VLANs. For more information on configuring ACLs on MS switches, please refer to our article on Switch ACL Operation.

Multiple VLANs

With security in place, we can take some initiative in designing the campus to decrease the size of broadcast domains by limiting where VLANs traverse. This requires architecting for VLANs to be trunked to only certain floors of the building or even to only certain buildings depending on the physical environment. This reduces the flooding expanse of broadcast packets so that traffic doesn’t reach every corner of the network every time there’s a broadcast, reducing the potential impact of broadcast storms. For example, the network design may utilize VLAN 3 for Data and VLAN 4 for Voice on the first floor, then apply VLAN 5 for Data and VLAN 6 for Voice on the second floor.

 

When configuring trunks to the first floor Intermediate Distribution Frames (IDFs), only VLANs 5 and 6 would be required. Such a design can be easily repeated, scaling up to a multi-building campus, assigning one or more VLANs for traffic segregation. This also helps in troubleshooting, helping to locate a user based on the IP address received. Configuring VLANs allowed on a trunk is straightforward in dashboard by using a comma separated list, so to allow VLANs 1,2,3,4 and 10 through 20, simply type 1-4, 10-20.

 

Note that Meraki switches do not require VLANs to be created or added in order for them to be accepted on trunk interfaces. Therefore, protocols such as Cisco VTP are not necessary, but are compatible with MS switches (i.e. VTP transparent mode).

 

 

For any deployment using Voice over IP (VoIP) it’s a good idea to ensure the voice traffic gets assigned to the correct VLAN. A lot of times, this voice VLAN is defined in addition to the normal traffic VLAN and modern phones will often have a PC connected through them. With Meraki switches we can easily assign a voice VLAN that the phone will get passed so that it can tag its traffic into the appropriate VLAN. This transaction is done via CDP or LLDP, depending on the phone model being used. The configuration of this VLAN is straightforward in the dashboard. Configure the port as an access port, defining the normal VLAN and then, additionally, the Voice VLAN.

 

Administration & Access Control

Administration visibility and access can be custom-defined within the Meraki dashboard. With different privilege levels and the ability to tag ports/devices to control who has access visibility and control can be handed out as necessary. Within the dashboard, the options of full access, restricted access, or read only access can be defined on a per-individual basis. This allows your help desk staff to have visibility and control over user ports, allows your networking team to have control over specific building or the entire organization level, and allows the stakeholders to have visibility without the ability to break anything.

 

To isolate or reduce the amount of access certain admins have the ability to tag switches and/or ports provides the ability to give some access to certain ports/switches and reduce the ability of the admin to bring down critical network functions. This can be done easily in the UI on the list of switch ports. Once the ports are tagged, just tie the tag to the admin.

 

 

Visibility

At this point the campus network setup is complete, utilizing the cloud. The next step would be ensuring users transition smoothly to the brand new network. The dashboard can be used to provide excellent reporting and knowledge of what’s happening in the new campus deployment. The dashboard will provide an overview of what clients are doing with Meraki’s built-in traffic analytics.

 

Meraki’s layer 7 application visibility is enhanced to dynamically detect applications running on the network, and provide hostname and IP address visibility. This information can be used to understand user behavior on the network and make policy decisions, such as creating custom traffic shaping rules, or applying group policies to specific users.

 

Troubleshooting with MS

Traffic analytics and summary reports emailed directly to the inbox help ease the burden of the engineer. That is, until the first trouble ticket comes in from someone unable to print to their local printer or unable to access a resource on the file server. While this used to be a headache, the task can be done quickly by utilizing the visibility of the dashboard. Simply open up the clients page and type in the name associated with the user or their PC. This will filter the list directly to the machine in question.

 

 

Once the machine in question has been located, there’s more information that can be provided. By clicking on the device we’re interested in, we can get details such as what switch/port or even AP it’s connected to as well as IP address, MAC address and even firewall information.

 

 

This screen allows us to quickly get an overview of the client and even try to ping it from the dashboard. We can also simply take a packet capture of the traffic while having the end user attempt the action that was failing. There’s also additional information if we’re tracking clients using Systems Manager (SM), enabling us to see what software is installed and making sure it’s in sync with any updates or policies that might be applied via SM.

If we want to rule out a physical layer issue this can be done straight from dashboard using the cable test utility available on the switches.

 

 

This allows us to rule out the physical layer simply and easily without trying to find a cable tester or sending someone to a remote location with cables and a tester to verify. With the information provided by the cable test, extra cables or a new cable run can be implemented if the test comes back as failed.

 

Another dashboard tool is the topology view, which provides insight into the network and how it’s connected, even showing a redundant link that’s not plugged in. In the case of a hybrid deployment, information can be pulled from directly connected devices to see that things are wired properly in the infrastructure.

 

 

It should be noted that the dashboard topology view is only available on networks with at least one MS switch.

Planning a Template Deployment

Before rolling out a template deployment (or enabling templates on a production network), it may be helpful to plan the "units" that make up your deployments. This involves asking questions such as:

• What are my sites? (e.g. retail location, school, branch office, etc.)
• How many switches are at each site?
• Are multiple switches at the same site configured the same way? (e.g. access switches, classroom switches, etc.)

The answers to these questions should directly affect your template deployment, specifically your use of template networks and switch templates.

Configuration

The following sections walk through configuration and use of switch templates in dashboard:

Auditing a Template Deployment

Though templates can be used to consolidate most switch configuration, there may be exceptions for individual ports or settings that necessitate local configuration changes on the switch. Since local configuration changes override template and template configurations, it is important to keep track of any local configuration changes across the organization.

To view local configuration overrides of a template:

1. Navigate to Organization > Configuration templates > Template name.
2. The Local overrides column will show if any networks are overriding the template configuration:

To view local configuration overrides of a switch template:

1. Select the appropriate template from the network drop-down.
2. Navigate to Switching > Configure > Switch templates > Template name.
3. The Local overrides column will show if any switches are overriding the template configuration:

Switch Replacement Walkthrough for Stacks

Below are instructions for how to copy configurations from a failed switch that is part of a stack and where the network is bound to a template.

1. On the Organization > Configure > Inventory page, claim the new switch and then add the new switch to the existing network.

2. Bind new switch to the switch template.

• Navigate to the parent template in dashboard.

• Navigate to Switching > Configure > Switch templates within that template.

• Click on the corresponding template.

• Click the Bind switches button.

• Click the checkbox next to the new switch and click the Bind to switch template button.

3. Firmware upgrade for the new switch.

• Provide the new switch a physical uplink connection and then power it on. The new switch needs to be brought online as a standalone device, not yet added to the stack so that it can update its firmware.

• Confirm via the connectivity graph or Support that the switch has upgraded its firmware.

• While the new switch upgrades, you may proceed with the below steps, stopping before Step 8 until the new switch has had a chance to upgrade.

4. Obtain Current Configuration.

• Navigate to Switching > Configure > Switch templates within the parent template.

• Click on the template in question.

• Filter in the  Search switches… field for the name of the old switch.

• Note the local override configuration. Save in a text editor for use in Step 5.

• In the child network, navigate to the Switching > Monitor > Switch ports page.

• In the Search switches… field, filter by the name of the old switch and select the below column options.

• Then, take screenshots of the port configurations or copy and paste into a spreadsheet or text editor application.

5. Configure replacement switch.

• On the Switching > Monitor > Switch ports page of the child network, configure the switch ports of the new switch based on the configuration gathered in Step 4.

• Once complete, navigate back to the switch template details page from Step 4 and ensure that the local overrides between the old and new switch match.

6. Power down the old switch.
7. Unbind Old Switch from template.

• On the switch template details page, click the check box next to the old switch and then click the Unbind button.

8. Add the new switch to the stack.

• After confirming that the new switch has upgraded its firmware as mentioned in Step 3, power down the new switch.

• In the child network, navigate to the Switching > Monitor > Switch stacks page.

• Click on the stack in question.

• Click the Manage members tab.

• Under Add members, click the checkbox next to the new switch and then click the Add switches button.

9. Remove the old switch from the stack.

• In the child network, navigate to the Switching > Monitor > Switch stacks page.

• Click on the stack in question.

• Click the Manage members tab.

• Click the checkbox next to the old switch and then click the Remove switches button.

10. Physically cable and stack the new switch.

11. Power on the new switch.

Additional Notes and Resources

If many networks are being deployed at once, the bulk network creation tool can be used to bind templates in bulk.

Please reference our documentation for more information on Meraki configuration templates.