Home > Architectures and Best Practices > Cisco Meraki Best Practice Design > Best Practice Design - MS Switching

Best Practice Design - MS Switching

General Switching Best Practices

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

 

Screen Shot 2018-04-15 at 6.45.24 PM.png

 

  • 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

 

Screen Shot 2018-04-15 at 6.55.56 PM.png

 

  • 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

 

Screen Shot 2018-04-15 at 6.58.18 PM.png

 

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

In case of switch stacks, ensure that the management IP subnet does not overlap with the subnet of any configured L3 interface. Overlapping subnets on the management IP and L3 interfaces can result in packet loss when pinging or polling (via SNMP) the management IP of stack members. 

 

  • Access Control Lists (ACLs)

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

 

Screen Shot 2018-04-15 at 8.35.15 PM.png

 

 

Screen Shot 2018-04-15 at 8.36.21 PM.png

 

 

  • 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 Switch > 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

 

Screen Shot 2018-04-15 at 7.23.27 PM.png

 

  • 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.

 

Screen Shot 2018-04-15 at 7.26.33 PM.png

 

  • Configure MD5 authentication for added security

 

Screen Shot 2018-04-15 at 7.28.06 PM.png

 

  • 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.

 

Screen Shot 2018-04-15 at 7.55.11 PM.png

 

  • 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)

  • 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

Switch Stacking

The following steps explain how to prepare a group of switches for physical stacking, how to stack them together, and how to configure the stack in the dashboard:

  1. Add the switches into a dashboard network. This can be a new dashboard network for these switches, or an existing network with other switches. Do not configure the stack in the dashboard yet.

  2. Connect each switch with individual uplinks to bring them both online and ensure they can check in with the dashboard.

  3. Download the latest firmware build using the Firmware Upgrade Manager under Organization > Monitor > Firmware Upgrades. This helps ensure each switch is running the same firmware build.

  4. With all switches powered off and links disconnected, connect the switches together via stacking cables in a ring topology (as shown in the following image). To create a full ring, start by connecting switch 1/stack port 1 to switch 2/stack port 2, then switch 2/stack port 1 to switch 3/stack port 2 and so forth, with the bottom switch connecting to the top switch to complete the ring.

 

physical_cabling.png

 

  1. Connect one uplink for the entire switch stack.

  2. Power on all the switches, then wait several minutes for them to download the latest firmware and updates from the dashboard. The switches may reboot during this process.

    • The power LEDs on the front of each switch will blink during this process.

    • Once the switches are done downloading and installing firmware, their power LEDs will stay solid white or green.

  3. Navigate to Switch > Monitor > Switch stacks.

  4. Configure the switch stack in the dashboard. If the dashboard has already detected the correct stack under Detected potential stacks, click Provision this stack to automatically configure the stack.

  5. Otherwise, to configure the stack manually:

  • Navigate to Switch > Monitor > Switch stacks.

  • Click add one / Add a stack:

 

switch_stacks_overview.png

 

  • Select the checkboxes of the switches you would like to stack, name the stack, and then click Create.

 

create_stack.jpg

 

The configuration is complete and the stack should be up and running.

  • Use 2 ports on each of “top” and “bottom” switches of the stack for uplink connectivity and redundancy.
  • Configure cross-stack link aggregation for uplink connectivity  
Warm Spare for Layer 3 Switches

MS Series switches configured for layer 3 routing can also be configured with a “warm spare” for gateway redundancy. This allows two identical switches to be configured as redundant gateways for a given subnet, thus increasing network reliability for users.

 

Note that, while warm spare is a method to ensure reliability and high availability, generally, we recommend using switch stacking for layer 3 switches, rather than warm spare, for better redundancy and faster failover.

 

Warm Spare is built on VRRP to provide clients with a consistent gateway. The switch pair will share a virtual MAC address and IP address for each layer 3 interface. The MAC address will always begin with 00-00-5E-00-01, and the IP address will always be the configured interface IP address on the primary. Clients will always use this virtual IP and MAC address to communicate with their gateway.

  • For redundancy, ensure an alternate path exists for the exchange of VRRP messages between the Primary and Spare. A direct connection between the Primary and Spare is recommended

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:

 

Screen Shot 2018-04-04 at 6.09.42 PM.png

 

  • 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.

 

Screen Shot 2018-04-15 at 8.00.47 PM.png

 

  • 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

 

Screen Shot 2018-04-15 at 8.15.43 PM.png

 

  • 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.

Large Campus Switching Best Practices

This guide provides information and guidance to help the network administrator deploy the Meraki Switch (MS) line in a Campus environment.

Campus networks typically adopt a tiered design, scaled according to the specific needs of the individual campus. These larger networks generally comprise WAN access, a core, an aggregation layer and an access/edge layer. This blueprint is used over and over again as it’s proven to be scalable to fit all use cases. An example outline of this template/blueprint can be found below.

 

Large Campus Switching Best Practices.png

 

Campus Design

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

The Aggregation Layer

The best networks have redundancy, so our recommended environment will leverage the stackable switches capable of running layer 3 features like the MS425 at the aggregation layer. This will allow the network to get 40 Gigabit connections to interconnect the two aggregation layer switches for physical redundancy as well as the resiliency of protocol failover in this setup. This way, the gateway remains up.

 

To begin, the MS425s should be online and connected to their gateway upstream. This will allow them to download any available firmware updates, in addition to grabbing any configuration changes made (before or after deployment). If the switches are online, the status LED should be solid white. If the LED is not turning white several minutes after being connected, the MS425 Series Installation Guide can be used to help troubleshoot. In the dashboard, the units should show a green status, meaning the the device is connected, has received the latest configuration, and is ready to go.
 

One the switches are online, the next step is to configure the dedicated QSFP+ stacking ports on the back of the switch to act as stacking ports. This can be configured across many switches in the dashboard via Switch > Switch Ports or for each individual switch, by clicking on the ports.

 

flexible_stacking.png

 

In the switch port configuration window, select stacking and save the configuration. This will push the change to the switches and the ports will be enabled for stacking. The next step is to configure the stack members in dashboard. This can be done on the Switch > Switch Stacks page in the dashboard. Switch stack members can either be selected from the Detected potential stacks section, or by selecting add one near the top of the page. Once the switches have been added to a stack in the dashboard, it will take about a minute for them to receive their configuration. Once the switches have received their stacking configuration from the dashboard, they will appear on the detected stacks list.

 

switch_stacks_overview.png

 

Name the stack and save changes to get the switches ready for adding interfaces and routes. The next step is to configure VLANs on a switch or stack basis under Switch > Routing and DHCP. From there, interfaces and static routes can be configured to keep traffic restricted. Click Add a static route or Add an interface and fill out the appropriate information, making sure to select the switch stack that was defined earlier.

 

After this configuration has been completed, OSPF can also optionally be enabled. The need for this depends on the size of the campus, with larger environments generally being more likely to require a dynamic routing protocol among sites/locations. OSPF is enabled via Switch > OSPF, and enabling it will provide failover capabilities for redundant internet paths as well as connections between buildings. If choosing to use OSPF, enable it, advertise the appropriate interfaces and set the Hello and Dead timers to the desired values. It is generally bast practice to start with low timer values of 1 (Hello) and 3 (Dead), but your network may require higher values if there is a great deal of delay or distance between your devices.

 

OSPF.png

 

This configuration will provide a foundation for the campus architecture at the aggregation layer. The next part to configure for the campus architecture is the Access Layer.

The Access Layer

Once the aggregation layer has been configured, a campus network architecture will require a way to connect end-users and clients to the network. It is generally recommended best practice to introduce physical stacking into the access or edge of the network. Physical stacking will provide a high-performance and redundant access layer to minimize any type of failure that might occur, while giving the network ample bandwidth for an enterprise deployment. The MS350 is an ideal example of an access layer switch that has been engineered for this purpose with fully redundant power supplies and fans, plus the ability to stack up to eight switches, providing up to 384 ports in a single stack. Stacked access layer switches like the MS350 should provide ample connectivity for a network closet to accommo­date a floor or a wing of a floor, and coupled with 160 Gbps stack bandwidth, multiple uplinks can be used with cross-stack link aggregation to achieve more throughput to aggregation or core layers. High bandwidth uplinks through access-layer port stacking will allow integration with the stacked aggregation layer MS425s that were setup earlier to provide redun­dancy from access to core, minimizing any sort of failures that might occur.

 

Before configuring a switch stack, every switch should be added to the same dashboard network and individually brought online with separate, individual uplinks. This ensures that the switches are up-to-date with the latest (and same) firmware versions, and helps ensure the entire stack will come online. 
To begin setting up stacking, the first step is to connect the stack links. Make sure the switches are powered down for this. As best practice, stacking should be set up in a full ring topology by connecting stack port "one" of one switch to stack port "two" of the next switch, continuing this pattern the whole way through the stack, and finishing with the bottom switch connecting to the top switch to complete the ring.

 

physical_cabling.png

 

Once the stack has been cabled correctly, the stack should be brought online with a single uplink for the entire stack. This will allow the switches to connect to the Meraki cloud and configure everything or sync with the configuration that was set up ahead of time. Once the switches comes online from their single uplink, the Meraki cloud will automatically detect the stack if it’s not already configured and will ask to provision or name the stack:

 

switch_stacks_overview.png

 

Once the stack has been named and configured, clients can be connected and link aggregation can be configured for an uplink back to the aggregation layer or core. Enterprise Meraki switches are able to use Link Aggre­gation Control Protocol (LACP) to bundle up to eight links. It is best practice to make sure to accommodate for additional bandwidth by using at least two links for the uplink in any stack.

 

When selecting ports for an aggregated stack uplink, it is best to space the links out so there are minimal hops across the stack for traffic to get to an uplink. In a stack with four switches, this would mean that switch 1 and switch 3 have uplinks. In a stack with eight switches and two uplink cables, this would mean that switch 1 and switch 4 have uplinks. This "maximum spacing" method will provide optimal coverage, during normal operation and in failures. This should help avoid having traffic unnecessarily traverse the whole stack to get to an uplink. Link aggregation is simple to configure using the dashboard, as all ports for all switches can be viewed from a single page. Simply select the ports to be in the link aggregate and click the Aggregate button in dashboard.

 

Aggregate Ports.png

 

For even higher-capacity needs, the Meraki MS355 switch family has a multigigabit ethernet model that pairs with the Meraki multigigabit MR access points to provide single-cable speeds greater than a gigabit. This allows a campus to have the stacking redundancy as well as greater throughput for end clients should it be needed. 

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 Switch > Switch Settings and define the QoS through the user interface:

 

DSCP to COS Map.png

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 allows us to then whitelist the servers that should be handing out DHCP addresses to keep the network up and operational.

 

DHCP Servers.png

 

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).

 

Update Port.png

 

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.

 

Update Port 2.png

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.

 

Update Port3.png

 

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.

 

Enabling Traffic Analytics

This is an opt-in feature and can be enabled under the Configure > Network-wide settings page by selecting the Enable Hostname Visibility function.

 

Traffic Analysis.png

 

Using Traffic Analytics

The enhanced Traffic analytics page will be visible under the Monitor menu whenever hostname visibility is enabled. This page will provide a total unique client count across an entire network over time. The view can be customized for different time periods (last 2 hours, week, day, and month), and on a per-SSID basis.

 

This page will show the following information on a per-network or per-SSID basis:

  • Application

  • Specific destination for broad application categories such as ‘Miscellaneous secure web’

  • Protocol information

  • Port information

  • Usage breakdowns by %, data sent and received, number of flows

  • Total active time on application across all clients

  • Number of clients

Signature or Application-Level Analytics

By clicking on an application signature (e.g. ‘Dropbox’ or ‘Non-web TCP’), it’s possible to see a complete breakdown of hostnames and IP addresses comprising this application category. Use this information to understand the communication patterns of certain types of traffic.

 

Application Analysis.png

 

This page will show you the following information on a per-application basis:

  • Application name, category, ports, description

  • Usage over time

  • List of users

  • Destination list - hostnames and IP addresses contributing to this application

  • Total number of clients per destination

  • Time spent per client

User Level Analytics

By clicking on a specific user, it’s possible to see a complete breakdown of hostnames and IP addresses this user has visited, including the time spent on each destination. Use this information to understand individual user behavior and apply policies on a per-user basis.

User level analytics.png

 

 

Summary reports can be mailed directly to the network administrator, relieving them of at least one task when their plate is full. These reports provide updates on the network and can be shared directly to key stakeholders with little to no effort.

 

Report Email.png

 

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.

 

Client Search.png

 

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.

 

Client Details.png

 

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.

 

Cable Test.png

 

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.

 

Topology.png

 

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

Templates for Switching Best Practices

As a network deployment grows to span multiple sites, managing individual devices can become highly cumbersome and unnecessary. To help alleviate these operating costs, the Meraki MS switch offers the use of templates to quickly roll out new site deployments and make changes in bulk.

This guide will outline how to create and use MS switch templates in Dashboard.

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 profiles.

Layer 3 Routing & DHCP

Layer 3 settings for networks bound to a template act as exceptions to the template. The Routing & DHCP, OSPF routing, and DHCP servers & ARP pages will be configurable on each network bound to a template and behave the same as if the network was not bound to a template. The one difference is that setting email alerts for newly detected DHCP servers on the DHCP servers & ARP page is available from the parent template's Network-wide > Alerts page and therefore applies to all networks bound to the template. 

Template Networks

A "site" in network deployment terms is usually the same as a "network" in Dashboard terms; each site gets their own Dashboard network. As such, when planning multiple sites to be configured the same way, they will share a template network.

A template network is a network configuration that is shared by multiple sites/networks. Individual site networks can be bound to a template network, so changes to the template will trickle down to all bound sites. A new network can also be created based on a template, making it easy to spin up new sites of the same type.

When planning a template deployment, you should have one template network for each type of site.

Switch Profiles

If multiple switches on a site share the same port configuration, they can easily be deployed and updated using switch profiles. Within a template network, a switch profile defines the per-port configuration for a group of switches. For example, if all sites contain multiple MS220-24 switches that are all configured identically, an administrator can set up a switch profile for their MS220-24 switches. This way, whenever a new MS220-24 is installed at a site, it will automatically assume its switch profile and configure its ports accordingly.

When planning a template deployment, if multiple switches share the same configuration, consider using a switch profile for each type of switch.

Profiles can be overwritten by a local port configuration. If the port of a profile-bound switch is manually configured, that manual configuration will be "sticky" and remain on the switch, even if the profile is changed.

Different MS switch models cannot share the same profile.

 

The following diagram shows the relationship between network templates and switch profiles:

Configuration

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

Creating a Template Network

As outlined above, a template network should be created for each type of site to be deployed.

To create a template network:

  1. In Dashboard, navigate to Organization > Monitor > Configuration templates.
  2. Click Create a new template.
  3. Select a descriptive name for your template. If this is a completely new template, select Create new and Switch template.
    • If this template should be based on an existing network, select Copy settings from and an existing switch network.
  4. Click Add:
  5. If you would like to bind existing networks to this new template, select those networks as Target networks and click Bind. Otherwise, click Close.

Multiple device types can be managed within a single template, acting as a combined network. For more information on managing non-switch devices in a template, refer to our documentation.

Once a network has been bound to this template, the template network should appear in the network drop-down:

Configuring a Template Network

Once a template has been created, it can be configured with some global switch settings. These settings will also apply to all networks bound to this template.

To configure a template network, select the template from the network drop-down and configure settings normally under the Switch > Configure menu options. This can include setting a global management VLAN, IPv4 ACLs, port schedules, etc. Switch profiles can also be configured here, as detailed below.

Please note that any configuration changes made here will apply to all bound networks.

Creating and Using Switch Profiles

Switch profiles can be used to bulk configure switches of the same model.

To create a switch profile:

  1. Select the appropriate network template from the network drop-down.
  2. Navigate to Switch > Configure > Profiles.
  3. If no profiles have been created, a Create Profile window will appear. Otherwise, click Create profile.
  4. Select a descriptive name and the switch model to be configured.
  5. Click Save:
  6. Click on the newly created profile.
  7. To configure the profile, select Configure ports on this profile.
  8. The following port configuration page can be used identically to the normal switch port configuration page:
  9. Navigate back to the switch profile under Switch > Configure > Profiles > Profile name.
  10. Click Bind switches.
  11. Select one or more switches, then click Bind to profile:

All bound switches will now use the port configuration set in the switch profile. Any changes made in the profile will now affect all bound switches.

Link aggregation can only be configured on the switch profile, not directly on bound switches through local overrides.

Local Overrides

Once a switch has been bound to a profile, it can still be configured normally through Dashboard. Any port configuration changes made directly on the switch will override the profile configuration, and be reported as a local override. If there is a need to override template configuration on a large scale, it is recommended to keep the the switch port count (with local overrides) per network up to 2500. For better performance on loading the switchport page, reduce the count to 2000. 

In the example below, the bound switch was directly configured to have a custom VLAN set on port 3. In the template network, under Switch > Configure > Switch Profiles, this configuration change is shown under the Local overrides column:

Auto-Binding Switches

When a new network is bound to an existing template with at least one switch profile, the option is available to "auto-bind" switches to that template's profiles. This dramatically reduces the amount of work necessary to set up a new site; if profiles exist for every switch model to be deployed, the only necessary configuration is binding the network to the template.

To auto-bind switches in a new network:

  1. Create a new switch network.
  2. Add devices to the network as normal.
  3. Navigate to Organization > Configuration templates > Template name.
  4. Click Bind additional networks.
  5. Select the newly created network, and check Auto-bind target devices.
  6. Click Bind:

All switches in the new network will now automatically be bound to their appropriate profiles.

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 profile 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 profile:

  1. Select the appropriate template from the network drop-down.
  2. Navigate to Switch > Configure > Profiles > Profile name.
  3. The Local overrides column will show if any switches are overriding the profile 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.

Claim_and_Add.png

  1. Bind new switch to the template profile.
  • Navigate to the parent template in Dashboard.

  • Navigate to Switch > Configure > Profiles within that template.

  • Click on the corresponding profile.

  • Click the Bind switches button.

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

Bind.png

  1. 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.

Connectivity.png

  1. Obtain Current Configuration.
  • Navigate to Switch > Configure > Profiles within the parent template.

  • Click on the profile 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.

Override.png

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

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

Column.png

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

Copy.png

  1. Configure replacement switch.
  • On the Switch > 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 template profile details page from Step 4 and ensure that the local overrides between the old and new switch match.

Compare.png

  1. Power down the old switch.
  2. Unbind Old Switch from profile.
  • On the template profile details page, click the check box next to the old switch and then click the Unbind button.

Unbind.png

  1. 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 Switch > 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.

Add.png

  1. Remove the old switch from the stack.
  • In the child network, navigate to the Switch > 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.

Remove_from_Stack.png

  1. Physically cable and stack the new switch.
  1. 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 and profiles in bulk.

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

Last modified

Tags

This page has no custom tags.

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7126

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community