About the program

Cisco Meraki’s technical training track

Engineering Cisco Meraki Solutions I Engineering Cisco Meraki Solutions II

To equip attendees with the core To equip attendees with the advanced
knowledge and skills to operate the knowledge and skills to plan, design,
Cisco Meraki platform. implement, and operate complex Cisco
Meraki solutions.
Path to certification

ECMS1 ECMS2 Meraki Certification

Build your Cisco Meraki Elevate your Cisco Meraki This Cisco technical specialist
technical knowledge and technical knowledge and certification will recognize IT
skills with this full-day, skills with this three-day, professionals' expertise in
virtual, instructor-led training instructor-led training Meraki solutions
 About the program

Who?
• IT professional
• Led by Meraki Training & Enablement

What? Where?
• 3-day training course
• Led by Meraki instructors
• Meraki offices and virtual
Why?
• Demand for advanced
Meraki technical training
How? • Bootcamp for certification
• Interactive technical content
• Innovative lab environment
Course syllabus

Day 1 Day 2 Day 3

Lesson 1: Planning new Meraki Lesson 6: Architecting VPN and Lesson 11: Physical security concepts
architectures and expanding WAN topologies and practices
existing deployments
Lesson 7: Securing the network Lesson 12: Gaining additional network
Lesson 2: Designing for scalable with Advanced Security features insight through application monitoring
management and high availability
Lesson 8: Switched network Lesson 13: Preparing and setting up
Lesson 3: Automating and scaling concepts and practices monitoring, logging, and alerting
Meraki deployments services
Lesson 9: Wireless concepts and
Lesson 4: Routing design and practices Lesson 14: Setting up dashboard
practices on the Meraki platform reporting and auditing capabilities
Lesson 10: Endpoint management
Lesson 5: QoS and traffic shaping concepts and practices Lesson 15: Gaining visibility and
design resolving issues using Meraki tools
Agenda – Day 1

30 minutes Welcome: Overview, Lab Introduction

60 minutes Lesson 1: Planning new Meraki architectures and expanding existing deployments
10 minutes Break
75 minutes Lesson 2: Designing for scalable management and high availability
15 minutes Lab 2 (self-paced)
30 minutes Lunch
70 minutes Lesson 3: Automating and scaling Meraki deployments
10 minutes Break
90 minutes Lesson 4: Routing design and practices on the Meraki platform
30 minutes Lab 4 (self-paced)
60 minutes Lesson 5: QoS and traffic shaping design
Agenda – Day 2

30 minutes Lab 5 (self-paced)

90 minutes Lesson 6: Architecting VPN and WAN topologies
10 minutes Break
70 minutes Lesson 7: Securing the network with Advanced Security features
30 minutes Lunch
30 minutes Lab 7 (self-paced)
30 minutes Lesson 8: Switched network concepts and practices
20 minutes Lab 8 (self-paced)
90 minutes Lesson 9: Wireless concepts and practices
30 minutes Lab 9 (self-paced)
60 minutes Lesson 10: Endpoint management concepts and practices
Agenda – Day 3

30 minutes Lab 10 (self-paced)

60 minutes Lesson 11: Physical security concepts and practices
30 minutes Lab 11 (self-paced)
30 minutes Lesson 12: Gaining additional network insight through application monitoring
30 minutes Lesson 13: Preparing and setting up monitoring, logging, and alerting services
30 minutes Lunch
30 minutes Lab 13 (self-paced)
60 minutes Lesson 14: Setting up dashboard reporting and auditing capabilities
20 minutes Lab 14 (self-paced)
70 minutes Lesson 15: Gaining visibility and resolving issues using Meraki tools
45 minutes Lab 15 (self-paced)
Course participant guidelines
How to attend this class effectively

• Course presentation slides

[Link]

• Watch the presentation

(slides include useful, teaching animations)

• Join the Webex audio bridge

(verbally ask questions)

• Post questions in Chat / Webex Teams space

(Teams space preferred, instructors will post answers)

• Take notes separately

(use your preferred note-taking methods)
Technical documentation and references

[Link]

URL Links Videos File Sharing

Online webpages On-demand clips Shared repositories
Lab overview
Lab objectives
The lab exercises are an essential component of the learning objectives for the ECMS2 course

Reinforce Lecture Additional Topics Break Period

Topics and features will be Other features or functionalities Use the time to take a short
configured in Dashboard with not discussed during the break, use the restroom, or
validation checks to test your presentations will be included in address follow-up questions
understanding the lab exercises from the last lesson
Lab format

• Remote lab
(access to physical hardware through Dashboard)

• Individual lab stations

(isolated & segmented from others)

• Self-guide
(go at your own speed)

• Not graded
(instructors will not be checking lab work)

• Verification section
(knowledge checks in the lab guide)
 LESSON 1
Planning new Meraki architectures
and expanding existing deployments
Meraki solution sizing | Per-device Licensing
 TOPIC
Meraki solution sizing
Dashboard structure

Dashboard Account Associated with an e-mail address,

used to log in to Dashboard

Provides visibility, management, and

Global Overview admin access to multiple orgs

Organization 1 Organization 2 Contains licenses and inventory of a

single organizational entity

Contains devices, their configurations,

Network A Network B Network AA Network BB
statistics, and any client-device
MX MX MX SM information

MS MS

MR MR

MV
Organization sizing
Single vs. multi-org

Geographic locations Operational structures Service providers

Data sovereignty, compliance Split business units, sub-groups Managed services or tiers

Operational response times Large, very distinct use cases Varying levels of SLA/domains
depends on proximity and separate departments and management requirements
Network scope and design
Scenario 1
A company has 4 sites, each with their own IT team. How many networks should this company have?

Company

Site A Site B Site C Site D

Network 1 Network 2 Network 3 Network 4

IT team 1 access IT team 2 access IT team 3 access IT team 4 access

Network scope and design
Scenario 2
A company has 1 site with a building that has 3 floors. Each floor has a different customer renting space and
you are providing their wireless infrastructure. How many networks could this company have?

Company

Site B

Network 3 Wireless configuration 3

Network 2 Wireless configuration 2

Network 1 Wireless configuration 1

Network scope and design
Scenario 3
A company has 3 sites: site A and site B are located in a different time zone than site C. Only their physical
security team should have access to their MV cameras while their main IT manages everything else (assume
all locations have MX appliances). How many networks could this company have?

Company

Site A Site B Site C

Network 1 Network 2 Network 3

(MX + etc.) (MX + etc.) IT team 1 access
(MX + etc.)

Network 4 Network 5 Physical security

(MV) (MV) team access
Solution sizing
Other considerations

SD-WAN Device limits Templates and configs

Each org is a separate Org: 25k | Network: 1k Network templates, network

SD-WAN instance 1 MX per network cloning, firmware consistency
 TOPIC
Per-device licensing
New features and capabilities

Partial Renewals Individual Device 90-day Activation Licensing APIs* Move licenses
Shutdowns Window between orgs*

API

Renew a subset of Only devices with Licenses won’t burn Claim, assign, and Move devices and
devices or networks expired license are until applied or 90 move licenses through licenses between
independently shut down, not days have elapsed API calls networks and across
organizations from purchase date organizations

*Moving licenses between co-term orgs is also supported (can be performed through Dashboard and via APIs).
Per-device case study
Licenses and expiration dates are tied directly to a device

Organization

Network A Network B Network C

Jan 01, 2023

Feb 01, 2023

Jan 01, 2026

2025

Expiration Date: Jan 01, 2023 Expiration Date: Feb 01, 2023 Expiration Date: (different)

Renewal: (add 1 year to AP)

Grace periods and shutdown
30 days from the time that the license expires

License expires, 30 days expires, device

grace period starts (software) shutdown

x
Original license License Active – OK Grace Period

New license New License Active – OK

• Devices and software products are shutdown at the individual level, not organization-wide

• If MI, MV sense, etc., that functionality/capability will be turned off

• When a license is applied, Meraki will take the time back

License renewals and feature add-on licenses
Straight forward and easy to calculate expiration dates
Admin applies 1-year renewal
(2 months remaining on license)

1-year license 1-year license

+ Expiration date: 14 months

1-year license Grace Period

• Add-on licenses can only be assigned to Meraki devices with an active base license – if the device
expires before the add-on license does, the add-on functionality will not work
• Add-on licenses inherit the same properties of all other licenses (i.e. 30-day grace period, 90-day
activation window)
License true-ups
Preserving the co-termination date in the organization with 1-day licenses

Licenses on the device

Expires:
Expires: JulyAugust
31, 202331, 2023
( 1 ) 1-year license (MX)
1-year license 1-day ( 31 ) 1-day licenses (MX)

Expires: August 31, 2023

1-year license ( 1 ) 1-year license (MS)

90-day activation window
Customers have up to 90 days to claim and assign licenses before they activate

January 1, 2023 January 31, 2023 April 2, 2023

Order Customer orders Assign Customer assigns (5) licenses to Remaining unused (2) licenses 90 Days
(10) LIC-ENT-3YR licenses devices, 5 licenses are activated activate

January 7, 2023 February 28, 2023

Claim Customer claims license key/order Assign Customer assigns (3) licenses to
into their dashboard organization devices, (3) licenses are activated

(5) (3) (2)

Start Date Jan 31, 2023 Feb 28, 2023 Apr 2, 2023
End Date Jan 31, 2026 Feb 28, 2026 Apr 2, 2026
 Single license keys
Generating multiple license ID’s from a single (primary) license key

Customer purchases Customer claims license Customer can assign license

Meraki licenses key/order number in Dashboard ID’s to a device or network*

1 2 3

Items ordered: (3) LIC-ENT-3YR Claim primary license key:

Order number: 0C1234567 1111-2222-3333
ID: 123
License key (primary): 1111-2222-3333

ID: 456
ID: 123 ID: 456 ID: 789
Generate individual license ID’s (3)

*With the PDL model, some licenses are applied on a per-network level (i.e. Systems Manager, vMX) ID: 789
Converting from co-term to PDL

• Default licensing model is co-term Organization expiration Device expiration

date: Jan 1, 2023 date: Jan 1, 2023

• Conversion is available through Meraki Support*

A. Dashboard (submit an email case)
B. Call the Meraki Support Team Device Expiration
date: Jan 1, 2023
C. Email: licensing@[Link]

• Once converted, the organization cannot be Device expiration

date: Jan 1, 2023
converted back to the old (co-term) model

Co-term to PDL Conversion

*Customers/partners who have access to Global Overview and are already using the same expiration date will be assigned to all
PDL model can leverage the ‘organization cloning’ workflow to expedite the process devices during the conversion process
Co-term and PDL knowledge check

Co-termination Per-device
Licensing Licensing

Where is licensing enforced? Org-wide Per-device

How many expiration dates? 1 1 or many

Is the 30-day grace period still in effect? Yes Yes

What happens when a device exceeds the grace period? Org shutdown Device shutdown

When do license keys begin to burn (count-down)? Order generated When activated or 90 days

What durations can I purchase licenses in? 1, 3, 5, 7, 10 years 1 day, 1, 3, 5, 7, 10 years

Can I purchase all available add-on licenses? No Yes

 Tiered licenses
Higher license tiers include all lower tier features

6 12 SD-WAN Plus
MI advanced analytics,
Smart SaaS optimization, Segmentation

4 Advanced 7 Advanced Security 7 Advanced

Extended routing table, Fully featured unified threat Umbrella DNS security,
Adaptive Policy management Adaptive Policy

Enterprise Enterprise Enterprise

Essential NGFW features,
Switching features Wireless features
Essential SD-WAN features

MS MX MR
 Lesson 1 review

Understand limitations & best practices Be able to distinguish between the Do you know how to strategically
when planning & designing logical two licensing models plan and execute license renewals
organizations, networks and account with both licensing models?
access in the Meraki Dashboard
 LESSON 2
Design for scalable management
& high availability
Role-based access | Tag design and structure | MX high-availability
MS high-availability | High density wireless design
 TOPIC
Role-based access
Org and network admin permission types
In Dashboard
Organization > Administrators
Full Read-only
Organization Admin

In Dashboard
Network-wide > Administration Full Read-only

Network Admin
Guest
Monitor-only Ambassador
 TOPIC
Tag design & structure
Types of tags
What are their uses?

Network
Tags
+
Device
Tags + + + + +
Policy, User,
Time-Based
Tags + + +
 TOPIC
MX high-availability
Design check
Why do we want high availability with MX Warm Spare?
• Minimize downtime
• Prevent single point of failure
• No manual intervention needed

What are the other factors to consider?

• Separate/redundant: UPS, power supplies, ISPs
• Physical separation

What are the costs and requirements of running (setting up) MX Warm Spare?
• Cost of: hardware (appliances, power supplies, accessories), rack space, but not a license for the spare unit
• Internet connection (both appliances checked into Dashboard)
• Same hardware model
• Primary appliance: bound/assigned to a network
• Secondary: NOT bound/assigned to a network
Terms and definitions
Primary
The MX that is configured as the "main" MX for the network. If both MX’s are online, this is the MX that traffic
should be flowing through – static designation.

Spare
The MX that is configured as the "secondary" MX for the network. If both MX’s are online, this is the MX that is
the inactive warm spare – static designation.

Active
The MX that is currently acting as the edge firewall/security appliance for the network – dynamic designation.

Passive
The MX that is currently acting as an inactive warm spare with no traffic passing through it – dynamic
designation.
Concepts and functions

VRRP Heartbeats
These advertisements are sent to help monitor
the status of the current active device. Internet Internet

Connection Monitor
An uplink monitoring engine on the MX that runs WAN 1 WAN 2 WAN 1 WAN 2
a series of tests.
Primary Secondary
Failover Operations (active) (passive)
(active)

• If all uplinks on an MX are detected to have

Priority: 0
failed, the MX will change its VRRP priority to 0
and this advertisement is received by the
secondary, failover is initiated.
• If no VRRP advertisements are received by the
secondary for 3 seconds, it will also take over
as the new active (initiates a failover).
Recommended MX HA design

Routed mode warm spare – multiple switches

Internet Internet
Failover Behavior
1. MX A (primary) WAN1 is the primary 1 2 3 4
interface WAN 1 WAN 2 WAN 1 WAN 2

2. MX A WAN1 fails, MX A initiates failover to

WAN2 interface
(both WAN1 and WAN2 of MX A fails) MX A MX B

3. Failover to MX B (spare) WAN1 interface

4. MX B WAN1 fails, MX B initiates failover
to WAN2 interface
Layer 2 switch Layer 2 switch
Recommended MX HA design

Routed Mode warm spare – switch stack

Internet Internet
Failover Behavior
1. MX A (primary) WAN1 is the primary 1 2 3 4
interface WAN 1 WAN 2 WAN 1 WAN 2

2. MX A WAN1 fails, MX A initiates

failover to WAN2 interface
(both WAN1 and WAN2 of MX A fails) MX A MX B

3. Failover to MX B (spare) WAN1

interface
4. MX B WAN1 fails, MX B initiates
failover to WAN2 interface
Layer 2 switch
stack
MX HA (warm spare)

VPN concentrator mode

WAN 1 Gateway
X.X.X.254 X.X.X.1

(one-arm configuration)
MX
(VPN Concentrator Mode)

MS
(Datacenter Core Switch Stack)
MX HA (warm spare)

VPN concentrator mode – upgraded to HA

WAN 1
X.X.X.253

VIP Gateway
X.X.X.252 X.X.X.1

MX
(Warm-spare VPN WAN 1
Concentrator Mode) X.X.X.254 MS
(Datacenter Core Switch Stack)
MG cellular gateway
Unlock wireless WAN connectivity via cellular as a primary or backup link

Feature Highlights
Up to 2Gbps CAT20 5G

2 separate gateway connections (GbE RJ45)

Compact form factor with multiple mounting options

Up to two physical SIM cards

High performance antennas (integrated or external*)

PoE (802.3AF) or DC powered

IP67 rated (4°F to 113°F or -20°C to 45°C)

Dipole antennas come included with external antenna models, patch antennas are available as an accessory
MG as a primary WAN interface

HA pair HA pair

Primary: Cellular SP Primary: Cellular SP 1 Primary: Cellular SP 2 Primary: Cellular SP Primary: Cellular SP

2 cellular service providers: 1 cellular service provider:

• Increased redundancy • Cost efficient
• More expensive • Single point of failure
 MG as a failover WAN interface

Internet Internet Internet Internet Internet

HA pair HA pair

Primary: ISP Primary: ISP 1 Primary: ISP 2 Primary: ISP 1 Primary: ISP 2
Secondary: Cellular SP Secondary: Cellular SP 1 Secondary: Cellular SP 2 Secondary: Cellular SP Secondary: Cellular SP

1 or 2 cellular and internet providers: 1 cellular service provider as backup:

• Up to 4 different providers (paths) • Leverage both interfaces on MG
• Maximum redundancy • Single cellular SP as backup to ISP links
 TOPIC
MS high-availability
Terms and definitions
Virtual stacking Physical stacking
The ability to easily push configuration to hundreds of Uses physical, dedicated stacking ports on a switch to
ports in the network regardless of where the switches create a stack that provides for gateway redundancy
are physically located. at layer 3 and dual-homing redundancy at layer 2.
Terms and definitions
Flexible stacking StackPower
The ability on select MS switches to use any of Provides an additional level of power redundancy
the front ports as either Ethernet (default) or by pooling power from each individual PSU in a
stacking ports. switch stack to form a larger, shared pool of
power that is readily available to any switch in a
stack that may need it.
Stacking matrix
Virtual Stacking Physical Stacking Stacking Bandwidth Flexible Stacking StackPower
MS120 ✔
MS125 ✔
MS130 ✔
MS210 ✔ ✔ 80G
MS225 ✔ ✔ 80G
MS250 ✔ ✔ 80G
MS350 ✔ ✔ 160G
MS355 ✔ ✔ 400G
MS390 ✔ ✔ 480G ✔
MS410 ✔ ✔ 160G
MS425 ✔ ✔ 160G ✔
MS450 ✔ ✔ 400G
Link Aggregation and Load Balancing
Implementation by Cisco Meraki

…MS series …MX series …link aggregation

between MS + Cisco

Hash of source and destination

Different ratios, specific rules Link bonding (EtherChannel)
IP, MAC, and port
2 to 8 ports
Open standards LACP using Proprietary algorithm to provide Enable LACP, set EtherChannel
link bonding load balancing mode to active or passive
 TOPIC
High-density wireless deployments
Capacity planning
Primary application and throughput

Application Throughput
VoIP 16 – 320 Kbps

Streaming – Audio 128 – 320 Kbps

Web Browsing 500 Kbps

Streaming – Video (SD) 768 Kbps

Video Conferencing 1.5 Mbps

Streaming – Video (HD) 768 Kbps – 8 Mbps

Streaming – Video (4k) 8 – 20 Mbps

Aggregate application throughput
Calculating aggregate bandwidth required

(Application Throughput) x (Number of Concurrent Users) = Aggregate Application Throughput

5 Mbps x 500 users = 2,500 Mbps (2.5 Gbps)

Example high-density environment:

• Support Full HD (1080p) video streaming (average 5 Mbps)
• Max capacity of conference venue supports 500 users
Device throughput

Estimated Throughput Throughput with

Standard Max data rates range
(1/2 advertised rate) Overhead*

Wi-Fi 4 (802.11n) 72 (1SS) – 289 Mbps (4SS) 36 – 144 Mbps ~18 – 101 Mbps

Wi-Fi 5 (802.11ac) 87 (1SS) – 347 Mbps (4SS) 43 – 173 Mbps ~30 – 121 Mbps

Wi-Fi 6/6E (802.11ax) 143 (1SS) – 1,147 Mbps (8SS) 72 – 573 Mbps ~50 – 402 Mbps

Notes:
• SS = Spatial Stream
• 20MHz channel (common recommendation in a high-density environment)

*Given the multiple factors affecting performance it is a good practice to reduce the throughput further by 30%
Estimating access points
Calculating the number needed based on application and access point throughput

(Aggregate Application Throughput) / (Access Point Throughput) = # of APs Based on Throughput

2,500 Mbps / 200 Mbps* = 12.5 APs needed

(round up to the whole number) = 13 APs needed

Example high-density environment:

• Support Full HD (1080p) video streaming (average 5 Mbps)
• Max capacity of conference venue supports 500 users
• Network configured to use 20 MHz channels
• Wi-Fi 6/6E 4-stream access point

*50 Mbps per-stream bandwidth x 4 streams = 200 Mbps

Estimating access points
Calculating the number needed based on client count

(Concurrent 5 GHz Clients) / 25 = # of APs Based on client count

500 x 0.7 / 25 =
350 / 25 = 14 APs needed

Notes:
• In order to ensure quality of experience it is recommended to have around 25 clients per radio in
high-density deployments.
• A common strategy is to do a 30/70 split between 2.4 GHz and 5 GHz clients
Estimating access points
Compare estimates

Number of APs = Max (# of APs based on Throughput, # of APs based on Client Count)

= Max ( 13 , 14 )
= 14 APs needed

Example high-density environment:

• Support Full HD (1080p) video streaming (average 5 Mbps)
• Max capacity of conference venue supports 500 users
• Network configured to use 20 MHz channels
• Wi-Fi 6/6E 4-stream access point
Mounting and antenna selection

X-Y plane

signal coverage
patterns

Y-Z plane
Lesson 2 review

Are you able to understand and Are you able to leverage and design Do you understand how MX
enforce various levels of a logical and effective tag structure appliances function when configured
administrative access to Dashboard? for an organization based on in a HA pair for both concentrator as
administrative needs? well as Routed modes?

Can you explain the different ways that Are you able to successfully plan for, calculate the
MS switches can achieve redundancy? requirements needed and configure SSID best
practices for a high-density wireless deployment?
 LESSON 3
Automating & scaling Meraki
deployments with Dashboard tools
Role-based access control with SAML | Network & org cloning
Configuration templates | Provisioning networks with APIs
 TOPIC
Role-based access control with SAML
Components of single sign-on

Service Provider

User

Single Sign On Solution

Identity Provider
IdP-Initiated SAML Authentication Flow

Service Provider (Meraki) User Identity Provider (IdP)

1 Browser accesses to User authenticates

2
IdP URL with IdP

IdP provides
3
SAML token

Browser connects to
5 Meraki Dashboard and IdP redirects browser to
4
provides SAML token Meraki Dashboard

Meraki Dashboard
6
verifies SAML token

User is logged into

7 Meraki Dashboard
SP-Initiated SAML Authentication Flow
Service Provider (Meraki) User Identity Provider (IdP)

User attempts to log

1
into Meraki Dashboard

Meraki Dashboard
2 generates
authentication request

Meraki Dashboard
Browser redirects to IdP parses request &
3 redirects browser to 3 4
IdP URL authenticates user
IdP URL

IdP generates
5
SAML token

Browser send SAML

6 IdP returns encoded SAML
token to Meraki 6
token to browser
Dashboard URL

Meraki Dashboard
7
verifies SAML token

User is logged into

8 the Meraki Dashboard
 TOPIC
Network & org cloning
Cloning networks

Network A Network B

MX MX
XYZ
XYZ

MS MS
XYZ

MR MR
XYZ

Firmware: 22.14 Firmware: 22.14

Firmware: 22.17

Default firmware: 22.17

Cloning networks

Network A Network B

MX MX
XYZ XYZ

MS MS
XYZ XYZ

MR MR
XYZ XYZ

Firmware: 23.1 Firmware: 23.1

Default firmware: 22.17

Configuration sync

MX network A MX network B

MX MX
AAA
ABC
ABC AAA

MR network C MR network D
MR

MR
DDD
DEF DDD
Cloning organizations

Organization A Organization B

• Dashboard organization administrators

• Organization administrators created through SAML

• Configuration templates

• Settings previously enabled by Meraki Support

• Dashboard branding policies

• Splash page themes

• Organization region

• Licensing model

Global Overview access required

 TOPIC
Configuration templates
Built-in automation with templates
Network A

MX

MS
Template DEF

MR
MX

MS
Network B
DEF
XYZ

MX
MR

MS
DEF

MR
MX templates: subnet considerations
Design requirement Branch 1
• 220 sites/branch locations
• 3 VLANs per site MX
• No subnet overlaps allowed
VLAN1: [Link]/24
• Need up to 254 hosts per subnet VLAN2: [Link]/24
VLAN3: [Link]/24

Template Branch 220

MX MX

VLAN1: [Link]/16 VLAN1: [Link]/24

VLAN2: [Link]/16 VLAN2: [Link]/24
VLAN3: [Link]/16 VLAN3: [Link]/24
 TOPIC
Provisioning Networks with APIs
API categories

Dashboard API Webhooks Captive Portal Location MV Sense

A RESTful API Method of subscribing Providing complete Delivering real-time Turning cameras into
to programmatically to alerts sent from the control of content and data from the Meraki sensors to understand
manage and monitor Meraki cloud when authentication of cloud to detect WiFi patterns, trigger
Meraki networks at events occur splash pages and BLE devices actions, and provide
scale insights over time
Dashboard API
RESTful API

Transport: Object serialization:

HTTPS
GET, PUT, POST, DELETE
+ JSON
Attribute-Value Pair

Use cases:
Automate provisioning of new orgs, admins, networks, devices, VLANs…
Build your own Dashboard for store managers, field techs
and much more…
API tools

cURL Python
Python library

Clone ananOrganization
Update SSID
API tools

Postman Node-RED
API tools

Google Sheets Google Apps Script

Python script (API demo)
Provisioning workflow
Traffic Analytics
Create Customer Customer
Admin account receives email
Location
Analytics

Bind Default Customize

Template Template for
Customer
Customer Signs Up Clone Default Create Network
Organization
Enable Monitor
Webhooks Webhooks

Update Device
Information
Warehouse Claim Devices Name, Location
Scans Devices & Licenses
Update
Customer Billing

Meraki
Meraki API Internal Tools
Dashboard
Lesson 3 review

Be able to leverage SAML to create Understand how to rapidly deploy a site using
a secure single sign-on system (various forms of) cloning within Dashboard

API

Are you able to establish a baseline of Know how to take advantage of the
configurations and understand how to near-endless possibilities and utility of
scale effectively by leveraging templates? the various Meraki APIs
 LESSON 4
Routing design & practices
on the Meraki platform
Routing across Meraki networks | Dynamic routing – OSPF |
BGP for scalable WAN routing & redundancy | IPv6 with Meraki
 TOPIC
Routing across Meraki networks
Routing on the MS (vs MX) – design best practices

Pros
• offload tasks from MX appliance
• inter-VLAN communication uses VLAN 1: [Link]/29
shorter path MX
Static route: subnet [Link]/24 next-hop: [Link] ✔
VLAN 20: [Link]/24 ❌
Transit
VLAN
Cons VLAN 1: [Link]/29
• inter-VLAN traffic is not filtered by MS
VLAN 20: [Link]/24
the MX appliance (IDS/IPS)

VLAN 20
Routing on the MS: Cloud management vs. client traffic

Management traffic Client traffic

“how the switch communicates “how packets from client devices
with the Meraki cloud” downstream of the switch are routed”

MX

[Link]
MS

[Link]

[Link]

[Link]
VLAN 20
Routing on the MS: Requirements
What is required for a L3 capable MS switch to be able to route traffic?

• Layer 3 must be enabled (by creating an SVI)

• Default route must be configured

• Clients should be configured to use the switch’s routed interface IP address as their gateway
Routing on the MS
True or False?
T F

1 The management IP of the switch cannot be the

same as the IP of an SVI

2 Multiple SVIs can be created for each VLAN

3 When creating the first SVI, the guided procedure will

also add a default static route on the target switch
Routing on the MX – Routed mode
MX serves as a layer 3 gateway for configured subnets

Deployments
Most branch deployments utilize MX in Routed Mode to take advantage of NAT
translations performed by the MX, DHCP services, and firewall functionalities
VLAN 1: [Link]/24
MX
VLAN 20: [Link]/24

Trunk Default gateway

MX appliance generally also serves as the default gateway for devices on the
MS VLAN 1: [Link]/29 LAN (Internet port is often given a public IP address, LAN ports are private IP
addresses)

Routing
Provides per-port inter-VLAN routing, handling of client VPN subnets, static
VLAN 20 routes, Auto VPN routes, and iBGP
Routing on the MX – Routed mode
MX serves as a layer 3 gateway for configured subnets

MX

MS

VLAN 20
Routing on the MX – Passthrough or VPN concentrator
MX acts as a layer 2 bridge or one-armed VPN concentrator

MX
WAN one-armed VPN Deployments
concentrator
• As a one-armed concentrator in datacenters for site-to-site
VPN and client VPN aggregation

datacenter • To redistribute Auto VPN routes via OSPF

services datacenter
MS
switches • As a BGP router to bridge Auto VPN routes

Routing
L3 core router
• No inter-VLAN routing, no static routes
• No access to DHCP settings/services on the MX
• No address translations are provided by the MX (typically
datacenter edge at a datacenter edge by a Cisco ASA or third party firewall)
Internet
 TOPIC
Dynamic routing (OSPF)
Dynamic routing protocol support
Which protocol? Which Meraki devices support it?

MX MS

Only advertises Meraki Auto Advertises routes, but also learns

VPN routes with OSPF routes from other OSPF sources

OSPFv2
OSPF on MS switches
Static Routing
• Supported on MS210 and above
• Static routes can be redistributed into OSPF
• Can be preferred over OSPF learned routes

Dynamic Routing (OSPF)

• OSPFv2
• OSPF network-type broadcast only
• 16 ECMP paths per destination
• Normal, Stub and NSSA Areas
• Support for MD5 authentication
• Adjustable Hello and Dead timers
• Virtual links are not supported
OSPF on MS – key considerations
Neighbors per subnet

= LSA

DR

Normal Area
OSPF on MS – key considerations
Number of OSPF links on a device

[Link]/24

[Link]/24
DR-other DR/BDR
[Link]/24

[Link]/24

...

etc.
OSPF on MS – key considerations
OSPF areas on a device

SPF calculations:
• convergence normal, stub or not
• any network topology changes AREA 1
so stubby areas
Route Summarization!

ABR
AREA 0 AREA 2

backbone area
OSPF on MS
Recap of key considerations

Neighbor per subnet OSPF links per device OSPF areas per device

Be mindful of the workload Size the appropriate hardware Minimize calculations, summarize
OSPF on MX appliances

EMEAR Region
1000’s sites
Auto VPN

Auto-VPN static routes

NA Region
1000’s sites

OSPF
APJC Region
1000’s sites
 Auto VPN – auto routing Route Table
subnet A
MX route redistribution

OSPF route subnet B

L3 switch
OSPF: on
subnet A static route

L3 switch VPN
OSPF: on
OSPF: on
L3 switch
OSPF route subnet C

Route Table Route Table

subnet A subnet A
 Auto VPN – auto routing Route Table
subnet A
MX route redistribution subnet B

static route subnet B

L3 switch
OSPF: on
OSPF route

L3 switch VPN
OSPF: on
OSPF: on
L3 switch
OSPF route

Route Table Route Table

subnet A subnet A
subnet B subnet B
OSPF on MX – key considerations
If you are using…

… Routed mode …passthrough mode … other subnets

OSPF
OSPF

WAN WAN static

LAN LAN route

OSPF

OSPF packets are only sent OSPF packets are only sent Requires the configuration
out of the LAN interfaces out of the WAN interfaces of static routes
 TOPIC
BGP for scalable WAN
routing & redundancy
BGP basics

ISP ISP 1 ISP 2

SP

Advertising IP Ranges Multihoming MPLS

Definitions
• BGP: Border Gateway Protocol
• AS: Autonomous System
• Dynamic routing protocols: Interior Gateway Protocols (IGPs) vs. Exterior Gateway Protocols (EGPs)

RIPv2, EIGRP, OSPF, IS-IS BGP

eBGP vs. iBGP

BGP operating modes
More than 1 path?
Various metrics, but typically the best path to the destination will be the shortest AS path (fewest hops)

AS: 65001 AS: 65002

TCP: 179

Peer 1 Peer 2
Routes
Prefixes Routes
Prefixes
a.a.a.a
a.a.a.a->->local
local c.c.c.c
c.c.c.c->->
local
local
b.b.b.b -> local d.d.d.d -> local
b.b.b.b -> local d.d.d.d -> local
c.c.c.c -> BGP: AS 65002 a.a.a.a -> BGP: AS 65001
d.d.d.d -> BGP: AS 65002 b.b.b.b -> BGP: AS 65001
BGP operating modes
eBGP and iBGP

Path: 65000 > 65001 (2 hops)

Default
Gateway A C
iBGP eBGP

eBGP eBGP
Path: 65000 > 65003 >
65001 (3 hops)

D
MPLS or Auto VPN
Auto VPN
MPLS
(customer
(customerview)
view)

MPLS
(service provider view)
 Data Center 1 Data Center 2
Meraki BGP
AS 65001 AS 65002
Deployment fundamentals eBGP in DC1 edge device eBGP in DC2 edge device
eBG
• Auto VPN between hubs (one-armed P
concentrator) and spokes (Routed or one-
armed concentrator) eBGP eBGP

• Auto VPN domain is considered a single BGP

Autonomous System

• When BGP is enabled, all hubs and spokes VPN concentrator in DC1 VPN concentrator in DC2

within the AS share routes via iBGP and no

Hub 1 Hub 2
longer use the Auto VPN registry

• Hubs will learn and advertise routes via their

AutoVPN AS 65000
eBGP neighbors in other AS’s iBGP

• By default MXs do not share learned routes

from other AS’s – this prevents routes from
transiting through the Meraki AS Routed mode – iBGP
Only
Branch A Branch B Branch C

Branch Offices
 Data Center 1 Data Center 2
Meraki BGP use cases
AS 65001 AS 65002
DC-DC Failover spoke sites eBGP in DC1 edge device eBGP in DC2 edge device

• Spoke sites will form VPN tunnels to both

primary and secondary hubs
DC routes advertised southbound
eBGP eBGP
• Spoke sites will learn and maintain route
information learned via BGP from both hub sites

• Concentrators at each data center advertise

Prepends ASN 1x Prepends ASN 2x
spoke site routing information to DC edge 65000 1 65000 1 2
devices
Hub 1 Hub 2

• The scalability of this solution is preserved with

max limits for BGP routes – this will protect the
AutoVPN AS 65000
Auto VPN domain from route leaks iBGP

• Route table integrity will be protected by utilizing

AS Path Access Lists
Hub 1 is primary Hub 2 is secondary
concentrator concentrator
• AS Path pre-pending adds hops based on hub Branch B
priority

Branch Offices
 TOPIC
IPv6 with Meraki
An IPv6 address

2001:0db8:85a3:0042:1000:8a2e:0370:7334
Global Routing Prefix Subnet ID Host
/48 /64 64 bits

• 128 bits
• Hexadecimal notation
• Sets of 16 bits
• Link Local (FE80::)
• Global
IPv6 Aggregation

2001:0410:1:1::/64 Customer 1 IPv6

2001:0410:1::/48
2001::/16

2001:0410:2:1::/64 Customer 2
ISP
2001:0410:2::/48
2001:0410::/35

2001:0410:3:1000:1::/64 Customer 3
2001:0410:3:1000::/56
IPv6 on Meraki devices
ISP
The MX uses DHCP-NA or SLAAC to
obtain prefixes to be used on the LAN

MX

The MX generates a /64 for the VLANs

MS
The MR, MS, and client devices will all
obtain an IPv6 address from the MX
using autoconfiguration
MR
IPv6 MX WAN (auto)
IPv6 MX WAN (PPPoE)
IPv6 MX WAN (static)
IPv6 MX WAN (cellular)
IPv6 MX LAN (delegation)
IPv6 MX LAN (VLAN)
IPv6 MX LAN
Lesson 4 review

Can you explain Meraki’s implementation Can you describe the best practices when it
of dynamic routing protocols across the comes to implementing routing on L3
various product platforms? capable Meraki MS switches?

Are you able to configure OSPF on your MX Be able to increase VPN scalability and
appliance as a method of automatically advertising integrations with data centers through the use of
VPN routes to downstream L3 OSPF neighbors? the MX’s implementations of MPLS and BGP
 LESSON 5
QoS & traffic shaping design
Wireless & wired QoS design |
Preparing the network for voice |
Traffic shaping & prioritizing with the MX
 TOPIC
Wireless & wired QoS design
Traffic classification

1 E-Mail, Web browsing A Voice (low latency)

(delivery not
2 E-Commerce B Transactional guaranteed)
Traffic Classification
3 Admin/Management Traffic C Mission Critical (guaranteed)

(delivery not
4 VoIP/SIP/Skinny D Best-effort guaranteed)
QoS design principles
True or False?
T F

1 Classify and mark applications as close to their

sources as technically and administratively feasible

2 Mark at Layer 3 whenever possible

3 Follow standards-based markings to ensure

interoperability and future expansion

4 Police traffic flows as close to their source as possible

5 Enable queuing policies at every node that has the

potential for congestion
Elements of QoS
Where can it be applied?

MR MS MX

What is the name of the standards?

WMM DiffServ

What are the configurable QoS mechanisms?

QoS policies CoS queues Load balancing

Traffic shaping DSCP (added, modified QoS policies
or trusted) Prioritization & traffic shaping
Wireless QoS – upstream
Wireless Multimedia (WMM aka 802.11e)

WMM classes

Voice

Client supporting Video AP honor all upstream

WMM sends traffic Best effort QoS sent by client

Background

Fast Lane
Wireless QoS – 802.11e
Queuing with Enhanced Distributed Channel Access (EDCA)

Previous Packet Next Packet

0 – m slots

SIFS
n slots
SIFS, slots, timers Minimum Random Backoff
vary based on protocol Assumptions:
(802.11 a,b,g,n) WAIT (AIFSN) Wait • WME Default Parameters
• Backoff values shown are for initial
Voice 0 – 3 slots
SIFS

2 slots CW equal to Cwmin = 15

Video 2 slots 0 – 7 slots

SIF
S

Best effort 0 – 15 slots

SIFS

3 slots

Background 0 – 15 slots
SIFS

7 slots
Minimum Random Backoff
Wait Wait
 Wireless QoS – upstream
Mapping wireless (WMM) to wired (DiffServ)

WMM DiffServ

IEEE 802.11 (802.11e WMM-AC) 802.3 DSCP (decimal) 802.3 DSCP RFC 4594-Based Model

Voice AC (AC_VO) 46 EF + 44 Voice + DSCP-Admit

 Wired QoS – DSCP and CoS

Frame *

L2 Encapsulation Frame payload (L3 packet)

802.1Q tag DS (TOS)

CoS VLAN ID DSCP ECN

DstMAC SrcMAC SrcIP DstIP Payload FCS
3-bit 12-bit 6-bit 2-bit

802.1p

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

* Note: an actual frame/packet contains other important fields, omitted in this graphic for simplicity.
CoS bandwidth calculations
Suppose we have a switched environment with the following…

Sum of all configured

CoS queue weight / CoS queues weight = % of Bandwidth

CoS queue 3 8 / (8+4+1) = 62%

CoS queue 2 4 / (8+4+1) = 30%

unclassified 1 / (8+4+1) = 8%

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

What is the resulting percentage of bandwidth allocated to each?

 TOPIC
Preparing the network for voice
Ensuring VoIP readiness

1. End-to-end QoS 3. Honor DSCP tags

When configured in Dashboard, QoS settings Trust DSCP tags set by other devices (e.g. IP phones)
automatically apply to all MS switches in the network

2. Voice VLAN 4. Mark packets (adding a DSCP tag)

To separate broadcast domains and enforce Once a packet is marked, it is placed into the
prioritization corresponding layer-2 CoS queue for forwarding

2 3

1 4

Optional: Edit DSCP to CoS mapping

Customize the mapping of DSCP value to a different CoS value from the default
Terms, concepts, and definitions

Network MOS
The mean opinion score measures the network’s impact on the listening quality of the VoIP
conversation
• MOS should be at least 3.5 or higher

Interarrival jitter
A measure of the quality and variation in arrival times (in ms) of packets (for real-time voice
applications)
• Jitter should be 10-30 ms or less
Wireless voice
Voice call quality without best practices
Wireless voice
Voice call quality following best practices
 TOPIC
Traffic shaping & prioritizing with the MX
MX traffic shaping & prioritization
Low Latency Queue (LLQ)

4x
High
Step 2 2x 10 Mbps WAN1
Step 1 Normal
Step 3
1x
Low
LAN Traffic Mux
High 4x

Normal 2x 5 Mbps WAN2

Low 1x

Traffic Shaping and Round

Path Selection Priority Queues WAN Uplinks
Prioritization Robin Scheduler

Classify traffic and Selection based on L7 classifiers. The 4x, 2x, 1x packets Traffic distribution is
forward based on app L3/4 classifiers. default priority is are consumed proportional to the path
(L7) Unclassified traffic is Normal respectively from bandwidth ratio. In the
distributed based on each queue example above, WAN1
WAN1 / WAN2 ratio gets 2x packets as WAN2
Shaping and prioritization
To optimize your network, you can create shaping policies to apply per-user controls on a per-application
basis. Traffic priority is a way of ensuring that specific applications or subnets are guaranteed a certain
amount of the uplink bandwidth at all times.
Valid uplink states

ISP 1
10 Mbps

Primary
WAN 1: 10 Mbps
WAN 2: 5 Mbps

ISP 2
1 5 Mbps
2
Secondary

Cellular: 1 Mbps
ISP 3
Priority:
1 Mbps
Critical business apps: WAN 1 High
Policy-based routing Backup
Non-critical business apps: WAN 1 Low
Guest subnet: WAN 2
Guest subnet Active
Standby
YouTube: 1 Mbps Down
Traffic shaping Online backups: 2 Mbps
Webex: Unlimited
Lesson 5 review

Do you understand the importance of proper Be able to configure your switching

QoS design and its implementation across infrastructure to prioritize latency sensitive
Meraki wireless and wired networks? traffic such as VoIP

Understand and deploy Meraki’s Are you able to configure and optimize traffic
recommended wireless voice best patterns with policy-based routing and packet
practices through Dashboard prioritization through granular traffic shaping rules?
 LESSON 6
Architecting VPN & WAN topologies
MX VPN operation modes | VPN design & topologies |
Auto VPN 101 | Designing a scalable VPN topology |
Integrating vMX into your Auto VPN architecture |
SD-WAN fundamentals & design
 TOPIC
MX VPN operation modes
Routed mode concentrator (routed mode)
Deployments
Very commonly implemented in branch or campus
networks

Public IP address
LAN switch Internet port is most often given a public IP address

Use of LAN ports

WAN 1 WAN 2 LAN 1
NAT concentrator
and firewall
Both the Internet and the LAN ports on the MX are used

NAT performed by the MX

NAT is performed by the MX and private IP addresses
are most often assigned to LAN ports
Internet
One-armed concentrator

WAN One-armed VPN Datacenter deployments

concentrator One-armed concentrator is the recommended
design choice

Single ethernet connection to the upstream network

Datacenter
switches All traffic is sent and received on the interface
Datacenter
services
Strategically assigned private IP address
IP addressing via DHCP or the use of a public IP
address on this interface is highly discouraged
L3 core router

NAT not performed by the MX

NAT is performed at a datacenter edge usually by
Datacenter a Cisco ASA or third-party firewall
Internet edge
Routed mode concentrator (DC deployment)

Datacenter Datacenter deployments

switch A Routed mode concentrator should be
positioned in between the datacenter edge and
Datacenter WAN LAN 1 NAT VPN the services edge
services concentrator
Separate ports for upstream and downstream
Internet port(s) and LAN ports are used
separately: upstream (WAN) towards the network
Datacenter edge; downstream (LAN) closer towards the
switches datacenter services

Public IP assignment
L3 core router Can be configured (ideally statically assigned)
with either a publicly routable IP address or be
deployed behind another NAT device within the
Datacenter
datacenter topology
Internet edge
 TOPIC
VPN design & topologies
Terms, concepts, and definitions

VPN Topology Routing Strategy

Full mesh Full tunnel

• All peers are connected to provide the • All network traffic (including internet
shorted possible path bound) from remote peers traverse back
to a central site where security and
• Reduces latency for applications between
internet access policies are enforced
locations

Hub-and-spoke Split tunnel

• Multiple remote peers (spokes) are • Traffic can be split at the branch location,
connected to a central hub using local ISP connections for direct
internet access and VPN tunnels to
• Spoke to spoke traffic traverses the hub
communicate between VPN peers
VPN topologies
Full mesh

Pros:
• Reliable
• Redundant

Cons:
• Expensive
• Harder to scale
VPN topologies
Exit hubs in a full mesh
Internet

Exit Hub
VPN topologies
Hub-and-spoke

Pros:
• More scalable
• Cost effective

Cons:
• Harder to achieve redundancy
VPN topologies
Adding redundancy to hub-and-spoke

Hub (primary) Hub (secondary)

 TOPIC
Auto VPN 101
Connection monitor
Three tests to validate WAN connectivity

0. Physical
Internet

1. ARP

2. DNS
WAN1 WAN2
3. Internet (ping, HTTP get)
Cloud orchestration of VPN
Site & Uplink Interface IP Public IP Source Port Destination port: UDP 9350 - 9381
Site A – WAN 1 [Link] [Link] 35000 Source port: UDP 32768 - 61000
Site A – WAN 2 [Link] [Link] 44000

Site D – WAN 1 [Link] [Link] 33000 Internet

Site D – WAN 2 [Link] [Link] 47000 VPN Registry
Site B

Internet

Site C
Internet UDP hole punch

Internet
Internet

MPLS
Site D
Site A
Cloud orchestration of VPN

Internet

Site B

Internet

Site C
Internet

Internet
Internet

MPLS
Site D
Site A
 TOPIC
Designing a scalable VPN topology
Design complexity
Number of tunnels

Hub A
W1 W2

ISP 1 ISP 2

W1 W2

Hub B

2 Hubs = 4 tunnels/hub
Hub A ISP 1 to Hub B ISP 1
Hub A ISP 1 to Hub B ISP 2 4 Hubs + 100 Spokes = ? Tunnels per hub/spoke
Hub A ISP 2 to Hub B ISP 1
Hub A ISP 2 to Hub B ISP 2
Tunnel count formulas
Hub and Spoke Full Mesh

𝐻 number of hubs

𝑆 number of spokes

𝐿1 number of hub uplinks

𝐿2 number of spoke uplinks

Hub tunnel count 𝐻 − 1 ∗ (𝐿1 2 ) + 𝑆 ∗ 𝐿1 ∗ 𝐿2 𝐻 − 1 ∗ 𝐿1 2

Spoke tunnel count 𝐻 ∗ 𝐿1 ∗ 𝐿2 Not Applicable

Tunnel calculations
Example 1: Full mesh topology

20 hubs with 2 uplinks each

500 Mbps of VPN throughput per hub
Hub tunnel count

𝐻 − 1 ∗ 𝐿1 2 = 𝟐𝟎 − 𝟏 ∗ 𝟐𝟐 = 76

Recommended MX model for hubs?

MX105 (or higher) = max VPN throughput
is 1 Gbps

𝐻 number of hubs 𝐿1 number of hub uplinks

𝑆 number of spokes 𝐿2 number of spoke uplinks
Tunnel calculations
Example 2: Hub-and-spoke topology
Hub tunnel count
2 hubs with 2 uplink each
200 Mbps of VPN throughput per hub
𝐻 − 1 ∗ (𝐿1 2 ) + 𝑆 ∗ 𝐿1 ∗ 𝐿2 =
5 spokes with 2 uplinks each
50 Mbps of VPN throughput per spoke = 𝟐 − 𝟏 ∗ (𝟐𝟐 ) + 𝟓 ∗ 𝟐 ∗ 𝟐 = 𝟐𝟒

Recommended MX model for hubs?

MX75 (500 Mbps, 75 concurrent tunnels) or higher

Spoke tunnel count

𝐻 ∗ 𝐿1 ∗ 𝐿2 = 2 ∗ 2 ∗ 2 = 8

Recommended MX model for spokes?

𝐻 number of hubs 𝐿1 number of hub uplinks Any MX device, except Z-series
𝑆 number of spokes 𝐿2 number of spoke uplinks teleworker gateways
Datacenter redundancy with Auto VPN failover
A DC-DC failover architecture is as follows:

One-armed VPN One-armed VPN

• One-armed VPN concentrator or
Concentrator Concentrator
Routed mode concentrators in each
DC
Datacenter Datacenter
switches switches

• 1 or more subnet(s) or static route(s)

Inter-DC
Connection

advertised by 2 or more
Internet Datacenter
concentrators
Datacenter services
services

• Hub & spoke or Full Mesh topology

L3 Core Datacenter Datacenter L3
Router Edge Edge Core
Router

Primary DC
Branch Location
Secondary DC • Split or full tunnel configuration

(Example topology using a hub & spoke configuration

with a one-armed VPN concentrator in each DC)
 TOPIC
Integrating the vMX into the
Auto VPN architecture
Traditional public cloud connectivity

Overhead required:

• Manual configurations AWS / Azure

• Additional setup for redundancy

• Manual (static) routing

• Dynamic routing requires BGP

• Physical connectivity requirements

IPSec VPN IPSec VPN IPSec VPN
vMX in the public cloud

vMX

AWS / Azure
Auto VPN

Auto VPN Auto VPN

vMX deployments in the public cloud

• vMX runs the same firmware across all platforms

• One-armed concentrator and NAT mode
(Default) can be used
• vMX should be configured with a private IP
address
• Firewall rules must be correctly updated

Global support for all $

major public clouds • Instance usage costs (cloud provider)
• vMX license (Cisco Meraki)
vMX – concentrator vs NAT mode
Concentrator NAT
Destination Next Hop Destination Next Hop
vMX
VPC Subnet Local VPC Subnet Local
Subnet A vMX [Link]/0 Internet GW
Auto VPN
Subnet B vMX
AWS / Azure
Subnet C vMX
[Link]/0 Internet GW

Auto VPN Auto VPN

Subnet A Subnet B Subnet C

vMX license sizing

vMX-S specs: vMX-M specs:

vMX-100 specs: vMX-L specs:
200 Mbps VPN throughput 500 Mbps VPN throughput 1 Gbps VPN throughput
50 concurrent tunnels 250 concurrent tunnels 1000 concurrent tunnels

*not all cloud providers currently support vMX-L

 TOPIC
Software-defined WAN
(SD-WAN) fundamentals
WAN growth options
M P L S O N LY

1 M P L S
• Increase the capacity of an existing MPLS network
HQ / DC BRANCH

REDUCING COST
AUGMENTED MPLS

M P L S
• Supplement an existing MPLS network with
broadband for increased bandwidth
2 B R O A D B A N D

HQ / DC BRANCH
• Offload critical traffic from MPLS to broadband
with policy based routing dynamic path
BROADBAND -BRO ADB AND selection
B R O A D B A N D
• Dual high speed broadband connections
3 B R O A D B A N D
• Load balance business critical traffic based on
HQ / DC BRANCH
policy or link performance

● business critical [PER 10Mbps PER MONTH]

● non-critical AVERAGE
PRICE OF WAN Broadband $15
CONNECTIVITY
MPLS $775
M E R AK I S D - WAN
[Source: [Link], How much does business internet cost, 2017]
SD-WAN

Three key features:

• Dual-active path

• Dynamic path selection WAN 1 WAN 2

Secure VPN tunnel (active) Secure VPN tunnel (active)
Latency / loss > threshold Latency / loss < threshold
• Policy-based routing (PbR)

Data
Based on L3 – L7 categorization, this
data normally travels out WAN1 (PbR)
but MX detects optimal path is WAN2
based on latency / loss on WAN 1
Benefits of SD-WAN
WAN link 1
Dual active VPN
Increased bandwidth and improved reliability MX WAN link 2
BRANCH

WAN link 1
Transport Independence Concept Internet
Supported over any Internet or MPLS link MX
WN link 2
BRANCH MPLS

WAN link 1
Improved reliability Business critical

MX
Automatic failover and high availability Non critical WAN link 2
BRANCH

WAN link 1
Enhanced visibility
MX
Live and historical tools for monitoring WAN link 2
BRANCH
SD-WAN algorithm
Dual path availability Can I establish VPN on
both interfaces?
NO

Performance based
L1 flow match?
Unchecked

W2

W1 Policy based flow match?

W1 Unchecked

Is load balancing on?

Decision: Unchecked
Use the only active path!
SD-WAN algorithm
No match or default/empty configurations Can I establish VPN on
both interfaces?
YES

Performance based
L1 flow match?
NO

W2

W1 Policy based flow match?

W1 NO

Is load balancing on?

Decision: NO
No to all, so we’ll default to
using the primary interface!
SD-WAN algorithm
Load balancing Can I establish VPN on
both interfaces?
YES

Performance based
L1 flow match?
NO

W2

W1 Policy based flow match?

W1 NO

Is load balancing on?

Decision: YES
Load balance across
both interfaces?
SD-WAN algorithm
Policy-based routing Can I establish VPN on
both interfaces?
YES

Performance based
L1 flow match?
NO

W2
What is the policy for
W1 Policy based flow match? Use WAN 2
this flow?
W1 YES

Is load balancing on?

Decision: Unchecked
Follow the defined policy!
SD-WAN algorithm
Performance based routing (1 path) Can I establish VPN on
both interfaces?
YES

Performance based
Which links satisfy
Only WAN 1
L1 flow match?
performance criteria?
YES

W2

W1 Policy based flow match?

W1 Unchecked

Is load balancing on?

Decision: Unchecked
Follow the defined
performance criteria!
SD-WAN algorithm
Performance based routing (0 or 2 paths) Can I establish VPN on
both interfaces?
YES

Which links satisfy

Neither / both links
L1 performance criteria?
YES

W2

W1 Policy based flow match?

W1 NO YES

Is load balancing on?

Decision:
NO YES Unchecked
Check if there is a policy based match and
if load balancing is on before making decision.
SD-WAN
Full decision flow chart
Performance probes MX A

Each uplink will send a probe across all available paths W1 W2

Probe: 100 byte UDP (based on Protobuf) with no DSCP marking 1 4

2 3
• Interval: 1 sec (default) or 10 sec (>2500 Auto VPN peers)

Average latency, loss, and jitter is computed using the last 6 samples
• Metrics are computed across all available paths of each MX W1 W2

path latency
Current average: MX B
Incoming latency value 10 15 20 20 15 10 15 ms

path jitter
Calculated Jitter K = Current average:
Latency (K + 1) – Latency K 5 5 0 5 5 … 4 ms

path loss
Current average:
Incoming loss value 0 0 0 0 0 0 0%
 TOPIC
SD-WAN design
Gathering requirements and design choices

Application List Site Internet Breakout

What are the business critical applications Identify sites that require local internet breakout
that this network will be supporting?

Sites and Locations

Site-to-Site connectivity
Where are applications hosted?
Select sites that are to be directly connected
Where are users located?

Traffic Flow Throughput Speeds

What is the estimated traffic flow per Determine necessary broadband
application between each two sites? speeds for each location

Performance Requirements Redundancy

What are the network performance Design proper warm-spare MX and
requirements for these applications? dual WAN link implementations
Example design scenario

Cisco Collaboration System

• CUCM with SIP breakout at the Private Data Center
• Phones at HQ and Branches

HQ Private Email Server

• UCS server at the Private Data Center
• Users at HQ, Branches, and Remote

Private Cloud Services

Data Center Cloud Storage Service
• Cloud service hosted on the public cloud
• Users at HQ, Branches, and Remote

SQL Database
Branch 1 Branch 2 Branch 3
• AWS deployment in the public cloud
• Users at HQ only
Cisco collaboration system

Cisco Collaboration System

• CUCM with SIP breakout at the Private Data Center
• Phones at HQ and Branches
SIP
HQ Calls between HQ and branches
Calls from HQ and branches to SIP breakout
CUCM to phones (management data)

Private Cloud Services

Data Center Delay up to 100ms
Jitter up to 2ms
Packet loss up to 2%

Branch 1 Branch 2 Branch 3 MX redundancy (warm-spare)

recommended
Private email server

Private email server

• UCS server at the private data center
• Users at HQ, branches, and remote

HQ Traffic flow: users at HQ and branches to DC

Traffic flow: remote users to DC (via client VPN)

Private Cloud Storage Service

Data Center
MX redundancy (warm-spare)
recommended

Remote

Branch 1 Branch 2 Branch 3

Cloud storage server

Cloud storage server

• Cloud services hosted on the public cloud
• Users at HQ, branches, and remote

HQ Traffic flow: each user to a cloud

application hosted on a third party public
cloud

Private Cloud Storage Service

Data Center
Local internet breakout at each site

Remote

Branch 1 Branch 2 Branch 3

SQL database

SQL database
• AWS deployment in the public cloud
• Users at HQ only

HQ Traffic flow: users at HQ to an

application hosted in AWS environment

Private Cloud Storage Service

Delay up to 50ms
Data Center
Jitter up to 10ms
Packet loss up to 2%

Branch 1 Branch 2 Branch 3

Proposed VPN topology

MX redundancy at the DC and HQ

HUB Local internet breakout at each site

Split tunnels

Branches as VPN spokes

Spoke vMX at the AWS deployment
HUB (vMX)

VPN NAT concentrator at DC & HQ

Remote VPN NAT concentrator at Branch sites
VPN one-armed concentrator vMX in cloud
Spoke Spoke Spoke

Hub-to-hub tunnel
Client VPN concentrator at DC
Hub-to-spoke tunnel
Proposed WAN topology and SD-WAN

Dual WAN
Each location has dual broadband connections
from different Internet Services Providers
HQ
Two custom performance classes
• Voice: 100 ms delay, 2ms jitter, 2% loss
• SQL: 50ms delay, 10ms jitter, 2% loss

Public
Private DC Cloud Implementation locations
SD-WAN rules implemented at HQ
and branch locations
Remote

Branch Branch Branch Load balancing

Load balancing enables at all locations
 Lesson 6 review

Can you differentiate between different MX Can you explain the mechanism Be able to design a scalable Auto VPN
VPN operation modes, VPN topologies, as behind Auto VPN? architecture that utilizes appropriately-
well as their pros/cons/use cases? sized Meraki MX appliances?

Do you understand the primary Be able to design and successfully

functions of SD-WAN, its key features, configure SD-WAN in the Meraki Dashboard
and the benefits that it delivers
 LESSON 7
Securing the network with
Advanced Security features
Security intro | Default behavior and rules processing order |
Advanced security services | Content filtering |
Umbrella integration
 TOPIC
Security intro
Embedded security features on the MX appliance
Meraki solutions feature centralized cloud-based security intelligence which dynamically controls and
enforces policy on the network via embedded device security engines.

APP
Layer 3 firewall Layer 7 rules Geo-based firewall

AMP
Dynamic content filtering Advanced Malware Protection & Intrusion Detection & Prevention
Secure Malware Analytics

Business goals:
Prevent breaches automatically to keep the business moving
& automate operations to save time and reduce complexity
Threat intelligence from Cisco Talos
Did you know? Cisco Talos is the world’s largest non-government threat intelligence organization.

Snort IPS ISE Cloudlock Umbrella AMP

NGFW Malware Analytics Meraki Network ISR/ASR Stealthwatch

350+ full-time threat researchers, Per day: 1.5 million malware samples, 600 billion
analysts, and engineers email messages, 16 billion web requests
 TOPIC
Default behavior and
rules processing order
MX appliances: default operations
All Meraki MX appliances operate as stateful firewalls – it keeps track of the state and characteristic of
network connections traversing across it

Routed mode MX

LAN WAN

✕
DENY INBOUND

ALLOW OUTBOUND

ALLOW INBOUND (return traffic)

VPN

ALLOW INBOUND & OUTBOUND

ALLOW ICMP
Rules processing order

Traffic received Matching L3 NO Matching L7 NO Traffic allowed

Rule? Rule?

YES ALLOW

YES

Allow/Deny?

DENY Traffic blocked

• Rules are processed in a top down fashion, with Layer 3 rules being processed, followed by Layer 7 rules.
• Unless traffic is explicitly blocked by at least one rule, it will be allowed through by a default allow all rule.
Rules processing order

L3 Default
L3 Firewall Rule L7 Firewall Rule L7 Firewall Rule
Firewall Rule

Policy Protocol Source Src port Destination Dst port

Deny TCP Any Any [Link] Any

match

Packet discarded as it matched a deny L3 firewall rule

Rules processing order

L3 Default
L3 Firewall Rule L7 Firewall Rule L7 Firewall Rule
Firewall Rule

Policy Protocol Source Src port Destination Dst port

Deny TCP Any Any [Link] Any

no match
Policy Protocol Source Src port Destination Dst port
Allow Any Any Any Any Any

match
Policy Application
Deny Gaming All Gaming
match

Packet discarded as it matched a L7 firewall rule

Rules processing order

L3 Default
L3 Firewall Rule L7 Firewall Rule L7 Firewall Rule
Firewall Rule

Policy Protocol Source Src port Destination Dst port

Deny TCP Any Any [Link] Any

no match
Policy Protocol Source Src port Destination Dst port
Allow Any Any Any Any Any

match
Policy Application
Deny Gaming All Gaming
no match

Policy Application
Deny HTTP hostname [Link]
no match
 TOPIC
Advanced security services
Advanced security services: Cisco AMP
Industry leading anti-malware technology that blocks HTTP-based file downloads, based on disposition

LAN WAN

File download request

URL/SHA256 in allowlist? → ALLOW File download

Not allowlisted→ Send hash to AMP cloud
5201c5c551063912a55f794e9b26352f… AMP

malicious→ DENY ✕ File disposition

[clean | malicious | unknown]
clean or unknown→ ALLOW

malicious→ ALERT
Retrospective disposition
Advanced security services: Cisco AMP + Secure Malware Analytics
SMA (Threat Grid) combines advanced sandboxing with threat intelligence into one unified solution

LAN WAN

File download request

URL/SHA256 in allowlist? → ALLOW File download

Not allowlisted→ Send hash to AMP cloud
5201c5c551063912a55f794e9b26352f… AMP

File disposition: unknown Database

Update
unknown→ ALLOW
(first time)

malicious→ DENY ✕ Threat score

SMA

72
95 15
clean → ALLOW Threat Behavioral
score indicators
Advanced security services: other considerations

AMP SMA
Supported file types: Supported file types:

EXE PDF EXE

ZIP PDF

XLSX
Platforms: Windows 7 64 bit (English, Korean, Japanese) & Windows 10

Unlimited AMP cloud lookups. Number of file submissions determined on file analysis pack.

E-mail alerts can be configured for malware events The MX currently supports Integration with SMA cloud.
(including retrospective) in the Network-wide > Alerts page. (no integration with on-prem SMA appliance)
Advanced security services: IDS/IPS (Snort)
Snort is an intrusion detection and prevention engine that performs real-time traffic analysis

LAN WAN

URL request

Rule ID in allowlist? → ALLOW URL response

Not allowlisted→ Snort service

✕
Ruleset:
CVSS [8|9|10]→ DENY Snort Connectivity (CVSS = 10)
Balanced (CVSS = 9, 10) → default
Security (CVSS = 8, 9, 10)
CVSS less than [8|9|10]→ ALLOW
 TOPIC
Content filtering
Content filtering powered by Cisco Talos
Uses URL patterns and pre-defined categorizations for determining what types of traffic are let through

LAN WAN

URL request
1. URL in allowlist? → ALLOW
2. URL in blocklist? → BLOCK

3. URL in local cache? → BLOCK

If HTTP: URL NOT in local cache? → Send to Talos
redirected to custom
block page

✕
Talos
If HTTPS:
website times out In blocked category→ BLOCK
Add to MX local cache

NOT in blocked category→ ALLOW

*Talos-powered content filtering requires MX 17.x or higher firmware

 TOPIC
Umbrella integration
Meraki MR and Cisco Umbrella
DNS firewall is a relevant control against one-third of cyber-security breaches over the last 5 years

Effortless Deployment Increased Visibility One License, Two Solutions

100% configured in Dashboard Security Center provides MR Advanced will license MR

org-wide reporting functionality devices and include Umbrella
7 predefined Umbrella
policies (different security View MR DNS events MR Upgrade is an add-on for
settings + content filtering) including blocked websites already licensed MR devices
MR + Umbrella integration
Applying pre-defined policies to SSIDs or clients to block content or security threats at the DNS layer

LAN WAN

1. attaches an identifier for Umbrella enforcement

DNS query 2. encrypt query using DNSCrypt
3. source NAT (MR management IP) and redirect to Umbrella resolver

directed to desired domain name ALLOWED→ encrypted DNS response with appropriate IP Identifier
allowed?

redirected to Umbrella block page* BLOCKED→ encrypted DNS response pointing to blocked page IP

*Requires Cisco Root Certificate to be installed on client

Applying an Umbrella policy to an SSID

Step 1:
Select the desired SSID

1 Step 2:
2 Enable DNS layer protection

3
Step 3:
Select the desired Umbrella policy
from the dropdown list

Dashboard Location:
Wireless > Firewall and Traffic Shaping
Lesson 7 review

Can you identify and explain the Be able to protect your network
embedded security features on the from malware with Cisco AMP
Meraki MX appliance?

Be able to protect your network from Understand content filtering capabilities with
cyber internet threats with Cisco Snort the Meraki platform and utilize it effectively
to refine network traffic
 LESSON 8
Switched network
concepts and practices
Access policies using Meraki Authentication |
Adaptive Policy | Cloning switch settings |
Switch templates & profiles
 TOPIC
Access policies using
Meraki Authentication
Access policies
802.1X (port-based network access control)

EAPOL RADIUS

Supplicant Authenticator Authentication server

Easy 802.1X deployment with Meraki Authentication
Leveraging Meraki Auth (a RADIUS server in the cloud) to reduce overhead

RADIUS
EAPOL RADIUS

Supplicant Authenticator Authentication server

 TOPIC
Adaptive Policy
Traditional ways to secure a network
Staff IoT Server
Traditional segmentation tools: VLAN 200 VLAN 200
• VLANs [Link] [Link]

• Access control lists

• Firewall rules
Staff
VLAN 10
[Link]

Limitations:
• Difficult to segment inside a VLAN
• IP addresses can change over time
• Where to put a firewall
• Administrative headaches
IoT Device IoT Device
VLAN 7 VLAN 8
[Link] [Link]
Securing a network with Adaptive Policy
Advantages:
• Policy is defined by identity
• No need to worry with IP addresses or VLANs
Staff IoT Server
• Policy is populated onto every
supported switch and access point Policy

IoT IoT
Staff
Device Server
Staff
Staff

IoT
Device
Supported on:
• MS390, release MS14.5+ IoT
Server
• 802.11ac Wave 2 and Wi-Fi 6
MR access points, release
MR27+
IoT Device IoT Device
 Adaptive Policy in action
Staff IoT Server
Policy is applied at the destination
Policy

Tag is applied at the source IoT IoT

Staff
Tag must be carried end-to-end Device Server
10
Staff 20 30
SGT=10 SGT=30
To IoT Server Staff
10
SGT=10
IoT
Device
Cisco MetaData
20
Dst MAC Src MAC 802.1Q CMD ETYPE Payload IoT
Server
SGT=20 SGT=20 30
EtherType Version Length Opt Type SGT Options
0x8909

IoT Device IoT Device

Configuring Adaptive Policy
Navigate to Organization > Adaptive policy

Step 1. Define policy groups and map to SGT tag values

Step 2. Define optional custom ACLs to be used in policy rules

• IPv4, IPv6, agnostic
• Allow or Deny ICMP, UDP, TCP, or Any protocol
• Source port
3 1 2 4
• Destination port

Step 3. Define a list of policies

• Source group name
• Destination group name
• Permission: Allow, Deny, or Custom ACL

Step 4. Enable the policy on a network

Step 5. Map users and devices to Adaptive policy groups

• Statically map switch ports and wireless SSIDs to statically map to a policy group
• Dynamically map users to a policy group via RADIUS (cisco-av-pair:cts:security-group-tag)
 TOPIC
Cloning switch settings
Cloning MS switch configurations

Branch A Branch B

MS 1 MS 1

XYZ

MS 2 MS 2

Note: MS switch cloning requires the source and destination switches to be the same model (exception: cloning MS210/225 to MS250)
Cloning MS switch configurations: which settings?
Port-level

Port name Access policy (access only)

Switch-level
Port tags MAC allowlist (access only)
STP bridge priority Interface state Allowlisted MACs (access only)
Port mirroring

What are NOT cloned?

+ Spanning tree
STP guard / BPDU guard
PoE *
Sticky MAC allowlist (access only)
Allowlist size limit (access only)
Native VLANs (trunk only)
Link Allowed VLAN (trunk only)
Local settings
Port schedules (access only) VLAN (access only)
(switch name, management IP)
Interface type Voice VLAN (access only)
Any layer 3 settings
Adaptive Policy group Adaptive Policy peer SGT configuration
(interfaces, DHCP, multicast, OSPF)

Notes:
• If cloning a non-PoE switch to a PoE switch, the PoE state of 'disabled' will be applied to the clone destination
• If the switch receiving the cloned settings exists in a different network, then access policies will only be copied
if that different network does not already have any access policies.
 TOPIC
Switch templates and profiles
Built-in automation with templates

Branch A

Switch 1
Template DEF

Switch 2
DEF

Branch B
DEF
XYZ
XYZ

Switch 1
DEF

Switch 2
DEF
Switch templates, profiles and settings

Template Branch A

8-port
Profile (8-port)

24-port PoE

XYZ

Branch B
Profile (24-port PoE)
8-port

ABC 24-port PoE

Port profiles: efficient port provisioning

Switch 1
(ports 1-6)

Switch 2
(ports 9-12)
Lesson 8 review

Be able to secure network access via Be able to implement micro-

802.1X through leveraging Meraki segmentation and simplify access
authentication control by leveraging Adaptive policy

Do you know how to improve a network’s

scalability and automation using MS switch
templates and profiles?
 LESSON 9
Wireless configuration
practices and concepts
Dashboard maps, floor plans, and RF profiles |
Wireless encryption and authentication |
SSID modes for client IP addressing |
Bluetooth low energy | Wireless threats
 TOPIC
Dashboard maps & floor plans
Maps in Dashboard
Where do we see/access maps?
TOPIC
RF profiles
Terms, concepts, and definitions
Band selection
Enable or disable the broadcast of an SSID in each operational band (2.4 – 5 – 6 GHz)

Channel width
Controls how broad the data transmission signal is – a wider channel results in faster speed

Transmit power range

Controls how far a signal can travel – the higher the transmit power, the farther a signal can reach

Minimum bitrate
Determine the minimum bitrate for a client – higher bitrates can be used to optimize performance (e.g., reduce the
overhead, exclude legacy client, facilitate client roaming)
RF profiles
Combining pre-determined radio settings together in order to automate the deployment of configs at scale
for groups of access points

Band selection

Channel width
RF
Profile
Transmit
power range

Minimum
bitrate
Profile types
Different RF profiles can be used to address different needs and spaces

• Default profiles (indoor and outdoor)

• Manual override for channel and transmit power

• 5 customizable predefined profiles

• Up to 50 RF profiles
 TOPIC
Wireless encryption & authentication
Wireless encryption and authentication
802.11 association process

1. Probe Request

2. Probe Response

3. Authentication Request

4. Authentication Response

5. Association Request

6. Association Response
Wi-Fi Protected Access version 3 (WPA3)
SAE (Personal)

1. Probe Request

2. Probe Response

3. Authentication (Commit) Seq 1

4. Authentication (Commit) Seq 1

5. Authentication (Confirm) Seq 2

6. Authentication (Confirm) Seq 2

7. Association Request

8. Association Response

WPA3 Personal has two scenarios: A.) WPA3 SAE only and B.) WPA3 SAE transition mode (WPA2 + WPA3)
Association requirements and splash page options
Endpoint
Sponsored Sign-on Sign-on with Cisco ISE
None Click-through management Billing
guest login with (various) SMS Auth Auth
enrollment

Open
✔ ✔ ✔ ✔ ✔ ✔ ✔
OWE
✔ ✔ ✔ ✔ ✔ ✔
Password ✔ ✔ ✔ ✔ ✔ ✔
MAC-based
✔ ✔ ✔ ✔
Meraki
✔ ✔ ✔
ENTERPRISE

Cloud Auth

RADIUS
✔ ✔ ✔ ✔
Local Auth
✔ ✔ ✔
IPSK with
RADIUS ✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔ ✔
IPSK without
RADIUS

OWE = Opportunistic Wireless Encryption, IPSK = Identity Pre-Shared Key

Local authentication
Connecting to 802.1X protected SSID’s without relying on the reachability of a RADIUS server

Typical EAP

✕
LDAP

✕
EAP RADIUS
Framework exchange exchange exchange

wireless client MR RADIUS server LDAP server

(supplicant) (authenticator) (authentication server) (e.g. Active Directory)

RADIUS exchange
Meraki Local Auth (handled internally)

✕
EAP LDAP
exchange exchange

wireless client MR LDAP server

(supplicant) (authenticator + RADIUS server) (e.g. Active Directory)
IPSK authentication without RADIUS
Typical enterprise WLAN: IPSK without RADIUS:
Multiple SSID’s, single PSK each Reduced SSID’s, multiple PSK, map to group policy

Name: SSID 1 Name: SSID 4

PSK: (RADIUS) PSK: XYZ
Use: employees Use: digital displays

Name: SSID 1 Name: SSID 2

Name: SSID 2 Name: SSID 3
PSK: ABC PSK: DEF PSK: (RADIUS) PSK: ABC PSK: DEF PSK: XYZ
Use: printers Use: warehouse Group policy: Group policy: Group policy: Group policy:
employees office devices inventory access office devices
 TOPIC
SSID modes for client IP addressing
SSID modes for client IP assignment (access control)
NAT mode

Client Traffic Client Traffic

Source IP Address: [Link] Source IP Address: [Link]

IP Address: [Link] IP Address: [Link] IP Address: [Link]

(DHCP server)
SSID modes for client IP assignment (access control)
Bridge mode

Client Traffic Client Traffic

Source IP Address: [Link] Source IP Address: [Link]

IP Address: [Link] IP Address: [Link] IP Address: [Link]

(DHCP server)
SSID modes for client IP assignment (access control)
L3 roaming

IP Address: [Link] /24

IP Address: [Link] /24 IP Address: [Link] /24

SSID modes for client IP assignment (access control)
L3 roaming – distributed to help scale and provide redundancy

“Client’s anchor AP
is: [Link]”
Is VLAN 1 available? ✕

IP Address: [Link] /24

Host AP

“Client’s anchor AP “Client’s anchor AP

is: [Link]” is: [Link]”
IP Address: [Link] /24 IP Address: [Link] /24 IP Address: [Link] /24
VLAN 1 Anchor AP Alternate Anchor AP
SSID modes for client IP assignment (access control)
L3 roaming – distributed to help scale and provide redundancy

“Client’s anchor AP
is: [Link]”
[Link]”
Is VLAN 1 available? ✔
client layer 2 roams
IP Address: [Link] /24 IP Address: [Link] /24
Anchor
Host AP
AP

“Client’s anchor AP “Client’s anchor AP

is: [Link]”
[Link]” is: [Link]”
[Link]”
IP Address: [Link] /24 IP Address: [Link] /24
Anchor AP
SSID modes for client IP assignment (access control)
Layer 3 mobility with a concentrator

VLAN 5
IP Address: [Link] /24

IP Address: [Link] /24

MX serving as the mobility
concentrator

IP Address: [Link] /24 IP Address: [Link] /24

VLAN 5
SSID modes for client IP assignment (access control)
Ethernet over GRE

Client’s L2 traffic w/
802.1q header
tunneled by MR ASR responds
to the MR

(private network)

Client IP Address or FQDN:

receives [Link]
Client’s L2 traffic w/ DHCP
802.1q header Cisco ASR serving as the
tunneled by MR GRE concentrator
IP Address: [Link] (DHCP Server)
SSID modes for client IP assignment (access control)
VPN: tunnel to a concentrator

MX as concentrator

Internet

(if split tunnel is configured)

corporate resources
 TOPIC
Bluetooth low energy
BLE beacons
What does it look like?

Access MAC Beacon

Preamble Header UUID Major Minor TX Power CRC
Address Address Prefix
Size 1B 4B 2B 6B 9B 16B 2B 2B 1B 3B

Brand Store Shelf

(optional) (optional)
 TOPIC
Wireless threats
Dedicated security radio

Bluetooth Low Dedicated 2.4 GHz 5 GHz

Energy beacon and dual-band* scanning 802.11b/g/n/ax 802.11a/n/ac/ax
scanning radio and security radio radio radios

*This pictures shows a dual-band access point; a tri-band access point may have a dedicated tri-band scanning radio.
Wireless threats Corporate
SSID

Legitimate Malicious Unsuspecting User

SSID SSID (connects to malicious SSID)

Unauthorized User
(gains access to corporate
LAN resources)

Unauthorized
Wireless AP
Connected

SSID Spoofing Wired LAN Compromise

Containment: The process by which clients will be unable to connect and any currently
associated clients will lose their connection to the rogue AP
Rogue AP containment
802.11 packets being sent by MR:
Meraki MR
w/ Air Marshal 1. Broadcast de-authorization
source = Rogue, destination = broadcast

2. Deauthorization messages
source = Rogue, destination MAC = client

3. Deauthorization & disassociation msgs

source = client, destination = Rogue

Source = Rogue AP
Destination = broadcast

Source = client Destination = Rogue AP

Destination MAC = client Source = Rogue AP

Rogue
Wireless Client
Access Point
Lesson 9 review

Do you understand the importance and Be able to choose and deploy the proper combination of
proper utilization of maps, floor plans, wireless authentication, encryption, splash page, SSID
and RF profiles in Dashboard? mode of client IP addressing, and SSID availability

Enabling BLE features and Do you understand how Meraki identifies

understanding use cases wireless threats and the remediation methods?
 LESSON 10
Endpoint management
concepts and practices
Platform overview | Deployment methodologies |
Deploying applications and containerization profiles |
Implementing security policies |
Securing the network with SM Sentry |
Agent-less onboarding with Trusted Access
 TOPIC
Platform overview
Systems manager overview

Centralized Rapid App and Profile Remote Security Network

Management Deployment Management Troubleshooting Automation Integration
 TOPIC
Deployment methodologies
Enrollment options

• Manual

• Automated
Enrollment through Apple ADE (DEP)
2. Apple sees S/N is owned by
an MDM, enrollment forwarded

4. Enrollment initiates – 3. Admin configures and customizes

SM, profiles, and apps are enrollment settings in Dashboard
1. Factory default device
auto pushed to device
checks in with Apple

5. Enrollment completes – device is

provisioned and ready to be used
Android zero-touch enrollment
2. Zero-touch configs
specify SM as the EMM
device policy controller

4. Device initiates the 3. Admin configures and customizes

1. Factory default fully managed device enrollment using tags in Dashboard
device checks for provisioning method – to scope settings and apps
with the Android SM is downloaded,
zero-touch portal followed by the profile
settings/apps

5. Enrollment completes – device is

provisioned and ready to be used

*Requires Android 8.0+ on supported devices

 TOPIC
Deploying applications and
containerization profiles
Containerization
SM implements native containerization

• Built into their core operating systems, it clearly separates work from personal data
• No need for proprietary SDKs or APIs when managing apps

Android Enterprise (Android for Work) Apple’s Managed Open-In

 TOPIC
Implement security policies
 TOPIC
Securing the network with
SM Sentry
 TOPIC
Agent-less onboarding with
Trusted Access
 Enabling personal devices access with SM + MR

2. Admin enables Trusted

Access on Amber’s device
in Dashboard

Allowed access?
4. Amber’s device 3. Amber (employee) 1. Amber (employee)
gains secure access visits the Self-service needs access to
to network resources Portal and downloads company resources
a certificate using their personal
mobile device
Security and accessibility in 3 easy steps

Step 1:
Configure authentication, enable SSP
(Self Service Portal)

Take note of the portal link, which will be

sent to the user.

Dashboard location:
Systems Manager > General
Security and accessibility in 3 easy steps

Step 2:
Enable Trusted Access on an SSID
and tie it to the Systems Manager
network
(Security must be configured as Enterprise with
Meraki Cloud Authentication)

Dashboard location:
Wireless > Access control
Security and accessibility in 3 easy steps

Step 3:
Create owners (users), enable the
SSP and Trusted Access

Dashboard location:
Systems Manager > Owners
Lesson 10 review

Be able to explain the various enrollment Be able to utilize a SM as a platform to

methods of Systems Manager secure sensitive enterprise data on devices
through containerization

Do you understand the device security Be able to enhance the security of your Meraki
posturing capabilities of Systems Manager network through leveraging Systems Manager to
when paired with security policies? assign dynamic access
 LESSON 11
Physical security concepts and practices
MV architecture | Flexible camera deployments with wireless |
MV portfolio | Business intelligence
 TOPIC
MV architecture
A traditional security camera deployment

Cameras Network Video Recorders (NVRs) Servers Video Viewing Software

Multiple Software Packages, Manual Configuration, Highly Complex

Huge Network Vulnerability
Meraki edge architecture

• Less than 50 Kbps upstream bandwidth per camera

• Configuration, thumbnails, and metadata stored in the cloud

• Hybrid video processing: video is analyzed on camera, motion indexed in the cloud
HTTP Live Streaming (HLS)
Video delivery mechanism developed by Apple

• Video is broken into a sequence of small HTTPS-based file downloads

• Camera creates playlist file (.m3u8)
• This is followed by 2 sec long .ts video segments
• Small buffering period which leads to a slight delay:
• HLS: between 5-10 seconds during local streaming (cloud-proxy stream dependent on path)
• Low-latency HLS: <2 seconds during local streaming (cloud-proxy stream dependent on path but latency is lower)

HTTPS

Playlist
.m3u8

Segments
.ts
.ts
Video transport

• Dashboard and MV cameras are only accessible via HTTPS

• Cameras automatically obtain, provision and renew a publicly-signed SSL certificate

• Certificate encrypts footage in transit from camera to the user

Technical breakdown of certificates:

-- Hashing algorithm is SHA256 --

-- Signing algorithm is RSA2048 --
-- Key parameters are secp384r1 --
-- Key exchange is Diffie-Hellman 2048 --
-- Cipher is AES128 --
 Local vs. remote video access
Direct access vs. cloud proxy

Meraki

Remote scene being

“cloud proxy” stream recorded
(access through Dashboard
or Meraki Vision Portal) on-device
storage

Local
“direct” stream
(access through Dashboard
or Meraki Vision Portal)
Local or remote access?
Identify the connectivity method Local Remote
(direct stream) (cloud proxy)

Which method securely streams the video through

1
Meraki’s cloud infrastructure to the client?

Which method is used if the client has a direct IP route

2
to the camera’s private IP and is connected via HTTPS?

Which method is used if no VPN is established

3
between the client and the camera connection?

4
Which method consumes little to no WAN bandwidth while
streaming live or recorded camera footage to the client?
Cloud archive
An optional add-on license for users who have specific, non-negotiable requirements for extended storage

• Camera dual records to on-device + cloud storage

• 30/90/180/365-day 24/7 storage options

video frame
• Enabled by an optional, per-camera license

• Archive data is stored in four data regions

(United States, Germany, Japan, Canada)
local on-device cloud remote
viewing client storage storage viewing client
• Data stored in Amazon Web Services (AWS) (direct stream) (cloud proxy)
 TOPIC
Flexible camera deployments
with wireless
From analog to IP-based

power data

power analog video power

 TOPIC
MV portfolio
Indoor models - technical specifications
MV12
MV2 MV22 MV22X MV32
(N / W / WE)

Camera
Fixed Fixed Varifocal Varifocal Fixed
lens

Highest 1080p 1080p 1080p 4MP 360°

resolution 1920 x 1080 1920 x 1080 1920 x 1080 2560 x 1440 2058 x 2058

Advanced
analytics ✔ ✔ ✔ ✔ ✔

✔ ✔ ✔ ✔ ✔
Wireless-
enabled

✔ ✔ ✔ ✔ ✔
Audio
recording

Storage
0 128 to 256 256 512 256
(in GB)
Outdoor models - technical specifications

MV52 MV63 MV63X MV72 MV72X MV93 MV93X

Camera
Varifocal Fixed Fixed Varifocal Varifocal Fixed Fixed
lens

Highest 4K 4MP 4K 1080p 4MP 360° 360°

resolution 3840 x 2160 2560 x 1440 3840 x 2160 1920 x 1080 2560 x 1440 2112 x 2112 2880 x 2880

Advanced
analytics ✔ ✔ ✔ ✔ ✔ ✔ ✔

✔ ✔ ✔ ✔ ✔ ✔ ✔
Wireless-
enabled

✔ ✔ ✔ ✔ ✔ ✔ ✔
Audio
recording

IP code and IP67 IP67 IP67 IP67 IP67 IP67 IP67

IK rating IK10+ IK10+ IK10+ IK10+ IK10+ IK10+ IK10+

Storage
1000 256 1000 256 512 256 1000
(in GB)
 TOPIC
Business intelligence
Advanced analytics
Doing more with the traditional security camera

Motion Search 2.0 Motion Heat Maps Object Detection

improved algorithm + Motion Recap a visualization of motion data people, vehicle, and custom detections
Meraki MV Sense
HISTORICAL
AGGREGATE REQUEST
How many were here
at X time?

INPUT
CURRENT SNAPSHOT
REQUEST THIRD PARTY
Lots & lots of How many people APPLICATIONS
video data are here now?

MV COMPUTER VISION /
MACHINE LEARNING ALGORITHM
REALTIME FEED
SUBSCRIBE
Sub-second feed of
objects and location

10 trial MV Sense included in every MV organization!

Lesson 11 review

Can you explain the difference between Be able to choose and implement the
traditional physical security camera architecture proper retention and storage options
versus that of Meraki MV camera architecture? including Cloud Archive

Be able to configure MV cameras to be Do you understand how Motion Search, visual heat
deployed over the WLAN maps, and the person detection capabilities of the
MV cameras help to provide business intelligence?
 LESSON 12
Gaining network insight
through application monitoring
Application performance monitoring |
WAN and Internet outage monitoring |
Scaling & licensing | Smart Thresholds
 TOPIC
Application performance monitoring
Cloud services: traditional troubleshooting
• Thomas, the employee, has an issue accessing Gmail.
traceroute ping
• He notifies Jenna, the IT administrator.
• Jenna does troubleshooting using available tools and believes that
the ISP is the root cause of the issues.
pcap
Thomas Jenna • Jenna calls their ISP and after some time is routed to Anna, the SP
(Employee) (IT admin) Customer Representative.

• Anna performs diagnostics but doesn’t believe that they are the
cause of the problem.

• Anna thinks the Cloud Services provider must be the issue. She
manages to get to Adam, a Cloud Service Customer Representative.

• Adam performs his analysis but also doesn’t believe the root cause is
with their platform.
Adam Anna
(Cloud Services (ISP Customer • Result: Jenna is back at square 1 and needs to continue
Representative) Representative) troubleshooting the problem without conclusive evidence and has
wasted a lot of valuable time.
Meraki insight troubleshooting
• Jenna, an IT administrator with a Meraki
Dashboard enabled with Meraki Insight.

• She begins her troubleshooting by looking at

Insight, which informs her of the outage.
Jenna Anna
(IT admin) (ISP Customer
Representative)
• Jenna leverages Insight for further analysis and
extracts data points to confirm the issue.

• Jenna places a call to Anna, their ISP customer

representative and supplies her with specific data
and reports.

• Anna is able to take full ownership of the issue and

works with her team until the issue is resolved.
Traffic analysis

client (end user) LAN MX with MI enabled ISP web apps & cloud services

Internet /
WAN

Meraki Cloud
(with Insight engine)
Performance metrics and indicator

Network WAN
• Performance Score • Available Goodput (WAN-limited)
• Total Network Usage • HTTP response time
• Latency • WAN loss / WAN latency
Performance Indicator • Total network usage

Application
< 80% ≥ 80% LAN

• HTTP response time • Available Goodput (LAN-limited)

• App usage • LAN loss
• HTTP request rate • LAN latency
• Total network usage
 TOPIC
WAN and Internet outage
monitoring
WAN Health
ISP 1
At-a-glance view of the status of all WAN links
Primary

1. Primary uplink

ISP 2
2. Secondary uplink
Secondary
MX + MI License

3. Cellular uplink
ISP 3

4. All networks with MX + MI license in Cellular

the organization
Monitoring interfaces
Primary, secondary, and cellular uplinks
Internet Outages
A global overview of network outages in service providers around the world
 TOPIC
Scaling and licensing
Insight licensing

Security Appliance models License size

FW Throughput

Z3 I Z3C | Z4 | Z4C Extra Small

MX6x Small
Up to 450 Mbps

MX75 I MX84 I MX85 Medium

MX95 | MX100 | MX105 Up to 750 Mbps

MX250 I MX400 I MX600 Large

Up to 5 Gbps

MX450 Extra Large

Up to 10 Gbps
Licensing scenario Network A
MX450
An company has an organization that contains 3 networks:

• Network A: two MX450 (HA pair)

• Network B: one MX105
• Network C: two MX250 (HA pair)

They would like to deploy MI on Network A and Network B,

but currently not on Network C.

Q1: Is it possible to use MI for only some of the

networks in their organization?
Yes – MI is licensed per network

Q2: What license(s) will they need to purchase?

MX105
1x Extra Large (for Network A)
1x Medium (for Network B) MX250
Network B
Network C
Licensing scenario Network A
MX450

An org admin has configured a full VPN tunnel between

Network A and Network C of this organization.

Q3: With the full tunnel between Network A and

Network C, will traffic from Network C be analyzed
and processed by Meraki Insight? Full
VPN
tunnel
No – MX’s do not provide MI information on VPN
traffic originating from non-licensed MX’s

MX105

MX250
Network B
Network C
Licensing scenario Network A
MX450

After using MI for several months, the company is

significantly benefiting from reduced troubleshooting
times for Network A and Network B – they now wish to
extend Meraki Insight to Network C as well.

Q4: Which license(s) should they buy?

1x Large license (for Network C)

Bonus: If we had a situation where Network B was

going to get shut down, and we wanted to transfer the
license from that location to Network C, can we do it?
No, because the MX250 requires at least a Large
license. If it was a Large or Extra Large license MX105
purchased for the MX105 at start, then the answer
would be ‘yes’ (it can be transferred).
MX250
Network B
Network C
 TOPIC
Smart Thresholds
Smart Thresholds
Increasing the effectiveness of Web App Health in Meraki Insight

Auto-adjusting thresholds Per app, per network Reduced false positive alerts

Branch A
Branch B
Branch C

Using machine-learned Assessing the performance of Alert based on expected behavior

behavioral patterns apps on a per network basis of an app per site (true outages)
Lesson 12 review

Do you understand the purpose of Meraki Can you explain how Meraki Insight gathers data
Insight and applicable scenarios? and the various metrics it uses to analyze the
performance scores produced in Dashboard?

Be able to navigate the Dashboard to find and Be able to choose and accurately size
interpret the metrics produced by Meraki out the appropriate license options
Insight and WAN Health
 LESSON 13
Preparing monitoring, logging,
and alerting services
Logging capabilities | Monitoring tools and services |
Supported alerts | API for flexibility
 TOPIC
Logging capabilities
Integrated and historical log databases

Event log Change log

Tracks events occurring in a Network Tracks changes made in an Organization
(timestamps in local network time zone) (timestamps In UTC)

Who was affected Who did it

What happened What was changed
When it occurred When was it done
Where it took place Where (which device)

Retention: 3 months * Retention: 2 years **

Both stored in Dashboard, not on Meraki devices, and have advanced filtering capabilities

* Extended retention can be achieved using an external syslog server ** 14 months in EU

 TOPIC
Monitoring tools and services
Single-pane-of-glass monitoring
Dashboard is your multi-tool

• Check the status of all devices

• Native analytics

• Real-time network diagrams

• Built-in tools throughout Dashboard

 TOPIC
Supported alerts
Alerting and notifications
Supported alert types

• Email*

• SMS

• Webhooks

*All network alerts will be sourced from the same email address. To ensure that alerts are not being lost to a spam filter, please
be sure to add alerts-noreply@[Link] as a trusted email source.
 TOPIC
API for flexibility
Exporting data through APIs

Scanning API Dashboard API

Example use cases: Example use cases:

… history of device associations … CDP/LLDP information
(who is accessing my network) (what was plugged into my switches)
… logs of device probe requests … list of administrators
(who was nearby but not joined) (accounting for who existed and when)
Lesson 13 review

Understand Dashboard’s logging Be able to setup and configure different

capabilities and how they differ levels and types of alerts for various needs

API

Are you familiar with the various Understand how to leverage APIs to export
monitoring tools and interfaces that and gain additional insights from historical
Dashboard provides? data that Dashboard has logged
 LESSON 14
Setting up Dashboard’s reporting
and auditing capabilities
Reporting in Cisco Meraki |
Managing firmware through Dashboard |
Running a PCI audit
 TOPIC
Reporting in Cisco Meraki
Summary reports
Dashboard Location:
Organization > Summary report

Tips for generating a useful & accurate report:

• Properly set and adjust the report timeframe

• Select the desired network(s) to report on

• Customize what information should or

shouldn’t be included in a report

• Direct export to Excel spreadsheet (.xlsx)

• Generate on-demand or recurring reports to be

e-mailed to select recipients
 TOPIC
Managing firmware through Dashboard
Traditional upgrade process
Firmware upgrades
Dashboard Location:
Organization > Firmware upgrades
Overview:
• Most recent changes (possible rollback option)
• Latest firmware versions (with release notes)
Scheduled changes:
• Pending scheduled upgrades across the org
All networks:

• A table listing all networks in the org

• Ability to sort/filter (network name, device type,
firmware version, firmware status, or template)
• Schedule individual or bulk network upgrades
Firmware upgrade FAQs

Q1: How does the upgrade process work?

A1: Cisco Meraki devices have two memory partitions that store the old and new firmware in parallel. Once the new
firmware has been successfully downloaded, the device will reboot and the new firmware will be loaded.

Q2: How long does an average upgrade take?

A2: The upgrade process generally takes under 11 minutes on wired devices with a fast Internet connection.

Q3: How do I know if my devices are up to date?

A3: Device details page, under the Status section, look for “Up to date” under Configured firmware.

Q4: How can I track the progress of an upgrade?

A4: When a device is in the process of upgrading, its progress can be tracked on the local status page (on the Overview
tab > Firmware section).

Q5: What are the 3 versions of firmware available?

A5: Stable, Release Candidate, and Beta are available through the Firmware Upgrades tool.
Staged switch firmware upgrades
Upgrade MS switch firmware in customized groups

1. Create and define groups of switches

2. Configure the desired sequence order for the
upgrades to take place
3. Assign the date/time to perform the firmware
upgrade

Use Cases
• Prioritize upgrades (by department, by building,
by floor, etc.)
• Schedule upgrades to fit maintenance windows
• Test new firmware builds on a small switch
group
Rolling firmware upgrades – wireless
Minimize client downtime by avoiding upgrading adjacent APs simultaneously

1. Upgrade scheduled
2. Group 1 is identified and created by
Dashboard
3. Group 1 performs firmware upgrade, clients
associated to Group 1 roams
4. Group 1 completes upgrade, Group 2 performs
firmware upgrade
5. Clients associated to Group 2 roams
6. Group 2 completes upgrade

This feature requires firmware MR 26.8+

 TOPIC
Running a PCI audit
Who needs PCI DSS?

If you work in…

• Retail
• Hospitality
• Transportation
• Healthcare
• Food services
• Telecom
• Media/Entertainment
• Construction
• Finance
…if you take digital payments, you need to be compliant!
• Energy
PCI audit process

1 2 3
Scans and
Online registration Gap analysis
penetration tests

6 5 4
Remediation
Offsite audit Remediation plan
support

7 8 Draft report 9 Report on

Onsite validation
on compliance compliance
WLAN PCI reporting
Dashboard Location:
Wireless > PCI report

Tips for running an accurate report:

• Properly define the CDE (Cardholder Data

Environment) subnets and selecting all SSIDs
that are in the CDE

• Accurately answering the information

gathering questions (do not check the box
unless absolutely certain that you are in
compliance)

• For failed items on the report, click Fail and

expand the item to see the recommended
actions to remediate
Lesson 14 review

Do you know how to generate different Understand the differences between

Summary Reports and interpret their Meraki firmware versions and how to
outputs to identify key metrics? strategically deploy them

Be able to compare, schedule, and plan Leverage Dashboard’s PCI reporting tool
for staged firmware upgrades across to recommend proper actions to meet
networks in Dashboard PCI DSS compliance
 LESSON 15
Gaining visibility and resolving
issues using Meraki tools
Troubleshoot methods | Native logging capabilities |
Wireless troubleshooting | Troubleshooting cloud applications performance
| Troubleshooting Meraki auto VPN | Local status page
 TOPIC
Troubleshooting methods
Troubleshooting: not an exact science

Classic approaches Meraki Dashboard

Top-down Unified view

Bottom-up Native logging
Divide-and-conquer Wireless Health
Follow-the-path Meraki Insight
Spot-the-differences VPN status page
Move-the-problem Network topology

Business goals:
reduced time-to-fix & incident prevention
 TOPIC
Native logging capabilities
Native vs. external logging

Event log Syslog

Change log SNMP

Native logging capabilities
Event log vs. change log

Event log Change log

Scope Network Organization

Timestamps Local (Network-wide > General) UTC

Retention period 3 months 2 years

Can export via Syslog Yes No

Can export to .csv Yes Yes

Filtering capabilities Yes Yes

Threat logs: Security Center

Monitor & identify Drill-down Take action

Latest and most common threats Determine origin Block country

Allowlist false positives

Inspect malicious packet

Prevent threats from spreading

Retrospective detections
 TOPIC
Wireless troubleshooting
An IT admin’s inbox…

1 new message

“Hi, this is Todd from the marketing department on level 6. I am connecting to access point AP-
6B with my Windows 10 laptop, I successfully authenticate via 802.1X but I am not obtaining an
IP address although I can see my laptop is sending out DHCP discoveries. Could you help me?”

“wireless not working, pls fix asap”

Meraki Health: network monitoring

75% 70% 100% 100%

EASY TO USE & UNDERSTAND RIGHT DATA AT THE RIGHT TIME EFFICIENT TROUBLESHOOTING
Quickly understand root cause even Having the right data and context Finding issues takes time. The Meraki
when the underlying issue is known available is key to troubleshooting Health now makes it easy to identify
problem areas
Smarter wireless troubleshooting
Successful wireless network access depends on several steps

1 2 3 4
Associate with an AP Authenticate to the network Obtain an IP address Resolve hostnames
Being proactive

Can users access the wireless Are connected users having a Are any AP’s overloaded or in
network successfully? good experience? need of optimization?
Wireless information: client’s perspective

Client Status
client info & connection path

Connections
client’s wireless connection
steps & problems

Performance
client & associated
access point’s performance

Roaming
interactive visualization
of roaming behavior

Timeline
client’s connection
event logs
Wireless information: MR’s perspective

Current Client
list of all associated clients

VLAN request status

RADIUS, DNS, DHCP & ARP
packet exchange status

Current channel usage

access point’s broadcasting
channel utilization
Capture the actual packets
Packet captures can be done on both wired and wireless interfaces

Wired
View the communications sent to the MX
infrastructure upstream

MS

Wireless ?
Examine the wireless communication [Link]

between the client and AP MR

?
Slow data rates? Check the signal-to-noise ratio (SNR)

SNR Recommendation
The difference in decibels between the received 20 dB or more for data networks
signal and the background noise level (noise 25 dB or more for voice applications
floor).
SNR is visible on the client’s details page

Noise floor and utilization under Wireless > RF spectrum

 TOPIC
Troubleshooting cloud
applications performance
Troubleshooting application performance with Meraki Insight

TLS-encrypted syslog
T CP 443
LAN WAN SERVER
Web App
User
HTTP/S Request

HTTP/S Response

Meraki Insight monitors HTTPS traffic on TCP port 443; for HTTP, any port can be specified.
No synthetic probes required.
VoIP Health
An active tool within Meraki Insight that measures network links for the performance of the uplink for cloud-
managed VoIP services.

VoIP Health provides insight into the following:

1 Is the link causing poor call quality?

If the link is not causing poor call quality, what/where is

2
the issue and who should I contact to fix the problem?

What does VoIP Health measure and how does it

rank the performance of uplinks?

MOS, loss, latency, and jitter are measured based on the

provider’s responses to ICMP probes.
The 3 categories of link health are based on the measured MOS
thresholds. Good: > 4 Moderate: 3.5 – 4 Bad: < 3.5
 Hop-by-hop analysis

1. Utilize the built-in traceroute tool to Hop number Status IP address Domain MOS Loss Latency Jitter
find the root cause gw-276meraki-
1 ● [Link] [Link].n 4.0 5.00% 75 ms 6.4 ms
2. Tool probes each hop along the path et
between MX and VoIP server [Link]
2 ● [Link]
[Link]
4.1 2.00% 78 ms 3.5 ms

3. MOS is calculated at each hop and cr1-200p-a-

checked to see if it meets thresholds
3 ● [Link]
[Link]
3.8
4.2 6.00%
0.00% 88 ms
33 19 ms

4. Thresholds less than < 3.5 are marked

4 ● [Link] [Link] 1.7
4.0 23.00%
3.00% 120ms
20 ms 4.8 ms
1.8

as ‘Bad’ 5 ● [Link] [Link] 4.3 0.00% 120ms

40 ms 5.6 ms
8.6
 TOPIC
Troubleshooting Meraki Auto VPN
Auto VPN: registration phase

Site IP Port Subnet(s)

VPN Registries (x2) HQ [Link] 50000 A, B, C

Branch [Link] 60000 Y

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Subnet Y
Registration Phase
VPN Registry
UDP 9350 - 9381
Auto VPN: connection phase

VPN Registries (x2)

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Subnet Y
S: 50000 S: 60000
D: 60000
Connection Phase D: 50000
Direct tunnel between peers (P2P)
UDP hole punching
Auto VPN: what can go wrong?

Site IP Port Subnet(s)

VPN Registries (x2) HQ [Link] 50000 A, B, C

Branch [Link] 60000 Y

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Firewall Subnet Y

Registration Phase
VPN Registry: Disconnected.
Outbound UDP 9350 - 9351 blocked
Auto VPN: what can go wrong?

Site IP Port Subnet(s)

VPN Registries (x2) HQ [Link] 50000 A, B, C

HQ [Link] 54321 A, B, C ?
Branch [Link] 60000 Y

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Load balancer Subnet Y

Registration Phase

NAT type unfriendly

Auto VPN: what can go wrong?

VPN Registries (x2)

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Firewall Subnet Y

S: 50000
D: 60000 ✕ Connection Phase
S: 60000
D: 50000

Branch
Auto VPN: what can go wrong?

Site IP Port Subnet(s)

VPN Registries (x2) HQ [Link] 50000 A, B, C

Branch [Link] 60000 Y

HQ Branch
[Link] [Link]
Internet

Subnets A, B, C Subnet Y
D: subnet Y ? Registration Phase
Name VPN mode

Subnet Y Disabled
Auto VPN: what can go wrong and resolutions

VPN Registry: Disconnected. Name VPN mode

Outbound UDP 9350 - 9381 blocked NAT type unfriendly
Subnet Y Disabled

[Link]:56125 - >[Link]:9350
[Link]:56126 - >[Link]:9350

✕ ✕

VPN
[Link]:44019 - > [Link]:9350
[Link]:44019 - > [Link]:9350

WAN
LAN
 TOPIC
Local status page
Local status page
Make local configuration changes, monitor device status/utilization, and perform local troubleshooting

MX

[Link] Internet
[Link]

MS

Internet
connection is
NOT required
MR

Note: [Link] or [Link] will work for any Cisco Meraki device (MX, MS, MR) but will only access the first device in the path
Local status page: alternative access
If access via DNS doesn’t work, there are other ways

MX

[Link] Internet
[Link]

MS

Internet
connection is
NOT required
MR

Note: alternate access requires local client/workstation to be manually configured with an IP in the same range (/24)
Troubleshooting the local status page
What can go wrong?

[Link]

Local status page disabled DNS traffic not through MX MX in Passthrough Mode
Lesson 15 review

Understand various troubleshooting Are you able to assess wireless failures Do you know how to monitor threats
methods (on the Meraki platform) and network issues through the tools via the Security Center and take
available in the Dashboard? protective actions?

[Link]

Understand the various forms of Do you know how to access and fully
troubleshooting with respect to Auto VPN utilize the local status page?
and the VPN status page in Dashboard