ECMS2 Training Slides.pdf

Engineering Cisco Meraki Solutions I
To equip attendees with the core
knowledge and skills to operate the
Cisco Meraki platform.
About the program
Cisco Meraki’s technical training track
Engineering Cisco Meraki Solutions II
To equip attendees with the advanced
knowledge and skills to plan, design,
implement, and operate complex Cisco
Meraki solutions.

Path to certification
ECMS1
Build your Cisco Meraki
technical knowledge and
skills with this full-day,
virtual, instructor-led training
ECMS2
Elevate your Cisco Meraki
technical knowledge and
skills with this three-day,
instructor-led training
Meraki Certification
This Cisco technical specialist
certification will recognize IT
professionals' expertise in
Meraki solutions

About the program
What? Where?
• 3-day training course
• Led by Meraki instructors
• Meraki offices and virtual
Who?
• IT professional
• Led by Meraki Training & Enablement
How?
• Interactive technical content
• Innovative lab environment
Why?
• Demand for advanced
Meraki technical training
• Bootcamp for certification

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

Agenda – Day 2
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 Lesson 8: Switched network concepts and practices
90 minutes Lesson 9: Wireless concepts and practices
60 minutes Lesson 10: Endpoint management concepts and practices

Agenda – Day 3
60 minutes Lesson 11: Physical security concepts and practices
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
60 minutes Lesson 14: Setting up dashboard reporting and auditing capabilities
70 minutes Lesson 15: Gaining visibility and resolving issues using Meraki tools

Course participant guidelines
How to attend this class effectively
• Course presentation slides
http://cs.co/ecms2-course-slides
• Watch the presentation
(slides include useful, teaching animations)
• Join the WebEx audio bridge
(verbally ask questions)
• Post questions in Q&A panel
(instructors will post answers)
• Take notes separately
(use your preferred note-taking methods)

Technical documentation and references
https://documentation.meraki.com
URL Links
Online webpages
Videos
On-demand clips
File Sharing
Shared repositories

Lab objectives
The lab exercises are an essential component of the learning objectives for the ECMS2 course
Break Period
Use the time to take a short
break, use the restroom, or
address follow-up questions
from the last lesson
Reinforce Lecture
Topics and features will be
configured in Dashboard with
validation checks to test your
understanding
Additional Topics
Other features or functionalities
not discussed during the
presentations will be included in
the lab exercises

Lab format
• Virtual lab
(access 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)

Planning new Meraki architectures
and expanding existing deployments
Meraki solution sizing | Per-device Licensing
LESSON 1

Network A
MX
MS
MR
MV
Network B
MX
Network AA
MX
MS
MR
Network BB
SM
Dashboard structure
Organization 1 Organization 2
Associated with an e-mail address,
used to log in to Dashboard
Provides visibility, management, and
admin access to multiple orgs
Contains licenses and inventory of a
single organizational entity
Contains devices, their configurations,
statistics, and any client-device
information
Dashboard Account
Global Overview

Organization sizing
Single vs. multi-org
a
Geographic locations
Data sovereignty, compliance
Operational response times
depends on proximity
Operational structures
Split business units, sub-groups
Large, very distinct use cases
and separate departments
Service providers
Managed services or tiers
Varying levels of SLA/domains
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

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 should this company have?
Company
Site B
Network 3
Network 2
Network 1
Wireless configuration 3

Site A Site B Site C
Network 1
(MX + etc.)
Network 2
(MX + etc.)
Network 3
(MX + etc.)
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 should this company have?
Company
Network 4
(MV)
Network 5
(MV)
IT team 1 access
Physical security
team access

Solution sizing
Other considerations
SD-WAN
Each org is a separate
SD-WAN instance
Device limits
Org: 25k | Network: 1k
1 MX per network
Templates and configs
Network templates, network
cloning, firmware consistency

New features and capabilities
Partial Renewals Individual Device
Shutdowns
Licensing APIs*
90-day Activation
Window
Move licenses
between orgs*
API
Renew a subset of
devices or networks
independently
Only devices with
expired license are
shut down, not
organizations
Licenses won’t burn
until applied or 90
days have elapsed
from purchase date
Claim, assign, and
move licenses through
API calls
Move devices and
licenses between
networks and across
organizations
*Moving licenses between co-term orgs is also supported (can be performed through Dashboard and via APIs).

Per-device case study
Network A Network C
Network B
Expiration Date: Jan 01, 2023 Expiration Date: Feb 01, 2023 Expiration Date: (different)
Jan 01, 2023
Feb 01, 2023
Jan 01, 2025
Jan 01, 2026
Renewal: (add 1 year to AP)
Organization
Licenses and expiration dates are tied directly to a device

License Active – OK
Grace periods and shutdown
30 days from the time that the license expires
Original license Grace Period
License expires,
grace period starts
30 days expires, device
(software) shutdown
• 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
New License Active – OK
New license
• When a license is applied, Meraki will take the time back
x

License renewals and feature add-on licenses
Straight forward and easy to calculate expiration dates
1-year license 1-year license
Admin applies 1-year renewal
(2 months remaining on 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
1-year license
Expires: July 31, 2023
1-year license
Expires: August 31, 2023
1-day
Expires: August 31, 2023
Licenses on the device
( 1 ) 1-year license (MX)
( 1 ) 1-year license (MS)
( 31 ) 1-day licenses (MX)

90-day activation window
Customers have up to 90 days to claim and assign licenses before they activate
Order
January 1, 2023
Customer orders
(10) LIC-ENT-3YR licenses
Assign
January 31, 2023
Customer assigns (5) licenses to
devices, 5 licenses are activated
Claim
January 7, 2023
Customer claims license key/order
into their dashboard organization
Assign
February 28, 2023
Customer assigns (3) licenses to
devices, (3) licenses are activated
90 Days
April 2, 2023
Remaining unused (2) licenses
activate
Start Date
End Date
Jan 31, 2023
(5)
Jan 31, 2026
Feb 28, 2023
(3)
Feb 28, 2026
Apr 2, 2023
(2)
Apr 2, 2026

Single license keys
Generating multiple license ID’s from a single (primary) license key
1
Customer purchases
Meraki licenses
2
Customer claims license
key/order number in Dashboard
3
Customer can assign license
ID’s to a device or network*
Items ordered: (3) LIC-ENT-3YR
Order number: 0C1234567
License key (primary): 1111-2222-3333
Claim primary license key:
1111-2222-3333
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: 123
ID: 456
ID: 789

Organization expiration
date: Jan 1, 2023
Converting from co-term to PDL
• Default licensing model is co-term
• Conversion is available through Meraki Support*
A. Dashboard (submit an email case)
B. Call the Meraki Support Team
C. Email: licensing@meraki.net
• Once converted, the organization cannot be
converted back to the old (co-term) model
Device expiration
date: Jan 1, 2023
Device expiration
date: Jan 1, 2023
Device Expiration
date: Jan 1, 2023
Co-term to PDL Conversion
same expiration date will be assigned to all
devices during the conversion process
*Customers/partners who have access to Global Overview and are already using the
PDL model can leverage the ‘organization cloning’ workflow to expedite the process

Co-term and PDL knowledge check
Co-termination
Licensing
Per-device
Licensing
Where is licensing enforced? Org-wide
How many expiration dates?
Is the 30-day grace period still in effect?
What happens when a device exceeds the grace period?
When do license keys begin to burn (count-down)?
What durations can I purchase licenses in?
Can I purchase all available add-on licenses?
Per-device
1
Yes
Org shutdown
Order generated
1, 3, 5, 7, 10 years
No
1 or many
Yes
Device shutdown
When activated or 90 days
1 day, 1, 3, 5, 7, 10 years
Yes

Tiered licenses
Higher license tiers include all lower tier features
MX
SD-WAN Plus
MI advanced analytics,
Smart SaaS optimization, Segmentation
Advanced Security
Fully featured unified threat
management
Enterprise
Essential NGFW features,
Essential SD-WAN features
MS
Advanced
Extended routing table,
Adaptive Policy
Enterprise
Switching features
MR
Advanced
Umbrella DNS security,
Adaptive Policy
Enterprise
Wireless features
4
6
7 7
12

Lesson 1 review
Understand limitations & best practices
when planning & designing logical
organizations, networks and account
access in the Meraki Dashboard
Be able to distinguish between the
two licensing models
Do you know how to strategically
plan and execute license renewals
with both licensing models?

Lesson 1 Knowledge Check
Which of the following is an advantage unique to the per-device licensing (PDL) model?
A. 30-day grace period
B. A single co-termination date for the entire organization
C. Licensing may be purchased in 1, 3, 5, 7 or 10 year increments as well as in 1-day SKUs
D. Licenses may be added as "license more devices" and as a "renewal"
Which of the following is a valid reason to split an organization into multiple networks?
A. To create additional SD-WAN instances
B. To calculate a longer licensing co-termination date
C. To avoid exceeding Dashboard limitations with the max number of devices per network
D. To unlock the Global Overview page

Design for scalable management
& high availability
Role-based access | Tag design and structure | MX high-availability
MS high-availability | High density wireless design
LESSON 2

Org and network admin permission types
In Dashboard
Organization > Administrators
In Dashboard
Network-wide > Administration
Organization Admin
Network Admin
Monitor-only
Full
Full
Read-only
Read-only
Guest
Ambassador

Types of tags
What are their uses?
+
+
+ +
+
+ +
+
Network
Tags
Device
Tags
Policy, User,
Time-Based
Tags
+

Design check
Why do we want high availability with MX in 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 in warm-spare?
• Cost of: hardware (appliances, power supplies, accessories), rack space, but not a license
• Internet connection (checked into Dashboard)
• Same firmware release
• 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.
Connection Monitor
An uplink monitoring engine on the MX that runs
a series of tests.
Failover Operations
• If all uplinks on an MX are detected to have
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).
Internet Internet
WAN 1 WAN 1
WAN 2 WAN 2
Primary
(active)
Secondary
(passive)
Secondary
(active)
Priority: 0

1
Recommended MX HA design
Routed mode warm spare – multiple switches
Failover Behavior
1. MX A (primary) WAN1 is the primary
interface
2. MX A WAN1 fails, MX A initiates failover to
WAN2 interface
(both WAN1 and WAN2 of MX A fails)
3. Failover to MX B (spare) WAN1 interface
4. MX B WAN1 fails, MX B initiates failover
to WAN2 interface
Internet Internet
WAN 1 WAN 1
WAN 2 WAN 2
MX A MX B
1 2 3 4
Layer 2 switch Layer 2 switch
2 3

3
1
Recommended MX HA design
Routed Mode warm spare – switch stack
Failover Behavior
1. MX A (primary) WAN1 is the primary
interface
2. MX A WAN1 fails, MX A initiates
failover to WAN2 interface
(both WAN1 and WAN2 of MX A fails)
3. Failover to MX B (spare) WAN1
interface
4. MX B WAN1 fails, MX B initiates
failover to WAN2 interface
Internet Internet
WAN 1 WAN 1
WAN 2 WAN 2
MX A MX B
1 2 3 4
Layer 2 switch
stack
2

MX HA (warm spare)
VPN concentrator mode
WAN 1
X.X.X.254
Gateway
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
MX
(Warm-spare VPN
Concentrator Mode) MS
(Datacenter Core Switch Stack)
WAN 1
X.X.X.253
Gateway
X.X.X.1
WAN 1
X.X.X.254
VIP
X.X.X.252

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
Primary: Cellular SP
HA pair
Primary: Cellular SP 1 Primary: Cellular SP 2
2 cellular service providers:
• Increased redundancy
• More expensive
HA pair
Primary: Cellular SP Primary: Cellular SP
1 cellular service provider:
• Cost efficient
• Single point of failure

MG as a failover WAN interface
Primary: ISP
Secondary: Cellular SP
Internet
HA pair
Primary: ISP 1
Secondary: Cellular SP 1
Primary: ISP 2
Secondary: Cellular SP 2
Internet Internet
1 or 2 cellular and internet providers:
• Up to 4 different providers (paths)
• Maximum redundancy
HA pair
Internet
Internet
Primary: ISP 1
Primary: ISP 2
1 cellular service provider as backup:
• Leverage both interfaces on MG
• Single cellular SP as backup to ISP links

Virtual stacking
The ability to easily push configuration to hundreds of
ports in the network regardless of where the switches
are physically located.
Physical stacking
Uses physical, dedicated stacking ports on a switch to
create a stack that provides for gateway redundancy
at layer 3 and dual-homing redundancy at layer 2.

Flexible stacking
The ability on select MS switches to use any of
the front ports as either Ethernet (default) or
stacking ports.
StackPower
Provides an additional level of power redundancy
by pooling power from each individual PSU in a
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 Backplane Flexible Stacking StackPower
MS120
MS125
MS210
MS225
MS250
MS350
MS355
MS390
MS410
MS425
MS450
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
80G
80G
80G
160G
400G
480G
160G
160G
400G
✔
✔

Link Aggregation and Load Balancing
Implementation by Cisco Meraki
…MS series
Source/destination IP, MAC, port
Open standards LACP using
link bonding
…MX series
Different ratios, specific rules
Proprietary algorithm to provide
load balancing
…link aggregation
between MS + Cisco
Link bonding (EtherChannel)
2 to 8 ports
Enable LACP, set EtherChannel
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
3 Mbps x 500 users = 1500 Mbps (1.5 Gbps)
Example high-density environment:
• Support HD video streaming (average 3 Mbps)
• Max capacity of conference venue supports 500 users

Device throughput
Protocol Data rate (Mbps)
Estimated Throughput
(1/2 advertised rate)
Throughput with Overhead
802.11a or 802.11g 54 Mbps 27 Mbps ~19 Mbps
1 stream 802.11n 72 Mbps 36 Mbps ~25 Mbps
1 stream 802.11ac 87 Mbps 44 Mbps ~31 Mbps

Estimating access points
Calculating the number needed based on application and device throughput
(Aggregate Application Throughput) / (Device Throughput) = # of APs Based on Throughput
1,500 Mbps / 101 Mbps = 14.85 APs needed
(round up to the nearest whole number) = 15 APs needed
• Max capacity of conference venue supports 500 users on laptops
• Laptops are company issues MacBook Pro (or similar) supporting 3 spatial streams
• Network will be configured to use 20 MHz channels

Calculating the number needed based on client count
(Concurrent 5 GHz Clients) / 25 = # of APs Based on client count
(common for 30/70 split between 2.4 GHz and 5 GHz clients)
500 x 0.7 / 25 =
350 / 25 = 14 APs needed

Compare estimates
Number of APs = Max (# of Aps based on Throughput, # of Aps based on Client Count)
= Max ( 15 , 14 )
= 15 APs needed

Mounting and antenna selection
X-Y plane
Y-Z plane
signal coverage
patterns

Lesson 2 review
Are you able to understand and
enforce various levels of
administrative access to Dashboard?
Are you able to leverage and design
a logical and effective tag structure
for an organization based on
administrative needs?
Do you understand how MX
appliances function when configured
in a HA pair for both concentrator as
well as Routed modes?
Can you explain the different ways that
MS switches can achieve redundancy?
Are you able to successfully plan for, calculate the
requirements needed and configure SSID best
practices for a high-density wireless deployment?

Which of the following is an effective use of network tags?
A. To automatically distribute licenses from a primary license key
B. To quickly select multiple networks while generating Summary Reports
C. To mark specific networks for archiving local device configurations to the Meraki cloud
D. To automate the allocation of hardware on the Inventory page
A. Through the application and removal of specific network tags by a Dashboard administrator
B. After VRRP heartbeats from the primary MX are missed
C. When the secondary MX no longer receives ICMP responses from the primary MX
D. Once the primary MX triggers its high-temperature threshold and sends Dashboard an alert
When does a secondary MX in warm spare take over from the primary?

Automating & scaling Meraki
deployments with Dashboard tools
Role-based access control with SAML | Network cloning |
Configuration templates | Provisioning networks with APIs
LESSON 3

TOPIC
Role-based access control with SAML

Components of single sign-on
Service Provider
Identity Provider
Single Sign On Solution
User Agent

IdP generates
SAML response
5
Service Provider User Agent Identity Provider
8
User is logged into
the application
2 SP generates SAML
request
7
SP verifies SAML
response
Browser send SAML
response to SP URL
6
IdP returns encoded SAML
response to browser
6
IdP parses request &
authenticates user
4
Browser redirects to
IdP URL
3
SP redirect browser
to IdP URL
3
User attempts to log
into your application
1

Cloning networks
Network A Network B
MX
MS
MR
Firmware: 22.14
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
MX
MS
MR
Firmware: 22.14
Default firmware: 22.17
Firmware: 22.17
Firmware: 22.14

Cloning networks
Network A Network B
MX
MS
MR
Firmware: 23.1
XYZ
XYZ
XYZ
XYZ
XYZ
XYZ
MX
MS
MR
Firmware: 23.1
Default firmware: 22.17
Firmware: 23.1

MR network C MR network D
Configuration sync
MX network A MX network B
MX
MR
MX
MR
DDD
DDD
AAA
AAA
DEF
ABC
DDD
AAA
ABC
DEF

Cloning organizations
• Dashboard organization administrators
• Organization administrators created through SAML
• Configuration templates
• Settings previously enabled by Meraki Support
• Dashboard branding policies
• Splash page themes
• Datacenter location (North America, South America,
Europe, Asia)
• Dashboard organization administrators
• Organization administrators created through SAML
• Configuration templates
• Settings previously enabled by Meraki Support
• Dashboard branding policies
• Splash page themes
• Datacenter location (North America, South America,
Europe, Asia)
Organization B
Organization A
Global Overview access required

Built-in automation with templates
Template
Network A
MX
MS
MR
MX
MS
MR
Network B
MX
MS
MR
XYZ
XYZ
XYZ
XYZ
XYZ
DEF
DEF
DEF

MX templates: subnet considerations
Design requirement
• 220 sites/branch locations
• 3 VLANs per site
• No subnet overlaps allowed
• Need up to 254 hosts per subnet
Template
MX
VLAN1: 172.16.0.0/16
VLAN2: 172.17.0.0/16
VLAN3: 172.18.0.0/16
Branch 1
VLAN1: 172.16.0.0/24
VLAN2: 172.17.0.0/24
VLAN3: 172.18.0.0/24
MX
Branch 220
VLAN1: 172.16.219.0/24
VLAN2: 172.17.219.0/24
VLAN3: 172.18.219.0/24
MX

TOPIC
Provisioning Networks with APIs

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

Dashboard API
Use cases:
Automate provisioning of new orgs, admins, networks, devices, VLANs…
Build your own Dashboard for store managers, field techs
and much more…
Object serialization:
JSON
Transport:
HTTPS
RESTful API
GET, PUT, POST, DELETE Attribute-Value Pair
+

Python library
Clone an Organization
Update an SSID

Google Sheets
API tools
Google Apps Script

Traffic Analytics
Location
Analytics
Update Device
Information
Name, Location
Update
Customer Billing
Customize
Template for
Customer
Monitor
Webhooks
Customer
receives email
Bind Default
Template
Enable
Webhooks
Claim Devices
& Licenses
Create Customer
Admin account
Create Network
Warehouse
Scans Devices
Provisioning workflow
Meraki
Dashboard
Meraki API Internal Tools
Clone Default
Organization
Customer Signs Up

Lesson 3 review
Be able to leverage SAML to create
a secure single sign-on system
Understand how to rapidly deploy a site using
(various forms of) cloning within Dashboard
Are you able to establish a baseline of
configurations and understand how to
scale effectively by leveraging templates?
Know how to take advantage of the
near-endless possibilities and utility of
the various Meraki APIs
API

What are the TWO steps necessary to set up SAML single sign-on for Dashboard? (select 2)
A. Contact a Certificate Authority to obtain necessary certificate for the IDP
B. Enable SAML SSO for the organization
C. Map out existing RADIUS or Active Directory user roles
D. Create SAML roles in Dashboard
A. To generate a new org with the same configuration templates as the source org
B. To start a new org that has the same Dashboard branding and splash page themes
C. To mirror the same organization administrators and their respective privileges
D. To clone non-template network configurations to a new organization
Which of the following is NOT an effective use of cloning an organization?

Routing design & practices
on the Meraki platform
Routing across Meraki networks | Dynamic routing – OSPF |
BGP for scalable WAN routing & redundancy | IPv6 with Meraki
LESSON 4

TOPIC
Routing across Meraki networks

Static route: subnet 10.0.20.0/24 next-hop: 192.168.1.2
Routing on the MS (vs MX) – design best practices
Pros
• offload tasks from MX appliance
• inter-VLAN communication uses
shorter path
Transit
VLAN
VLAN 1: 192.168.1.1/29
VLAN 1: 192.168.1.2/29
VLAN 20: 10.0.20.1/24
✔
❌
MX
MS
VLAN 20
VLAN 20: 10.0.20.1/24
Cons
• inter-VLAN traffic is not filtered by
the MX appliance (IDS/IPS)

Routing on the MS: Cloud management vs. client traffic
VLAN 20
Management traffic
“how the switch communicates
with the Meraki cloud”
192.168.128.3
1
199.88.77.166
192.168.128.1
192.168.128.1
MX
MS
Client traffic
“how packets from client devices
downstream of the switch are routed”

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?
1
2
3
The management IP of the switch cannot be the
same as the IP of an SVI
Multiple SVIs can be created for each VLAN
When creating the first SVI, the guided procedure will
also add a default static route on the target switch
T F

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
Default gateway
MX appliance generally also serves as the default gateway for devices on the
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
routes, Auto VPN routes, and iBGP
MX
MS
Trunk
VLAN 1: 192.168.1.1/24
VLAN 20: 10.0.20.1/24
VLAN 1: 192.168.1.2/29
VLAN 20

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
WAN
datacenter
services
one-armed VPN
concentrator
datacenter
switches
L3 core router
datacenter edge
MX
MS
Internet
Deployments
• As a one-armed concentrator in datacenters for site-to-site
VPN and client VPN aggregation
• To redistribute Auto VPN routes via OSPF
• As a BGP router to bridge Auto VPN routes
Routing
• 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
at a datacenter edge by a Cisco ASA or third party firewall)

Dynamic routing protocol support
Which protocol? Which Meraki devices support it?
MX MS
Only advertises Meraki Auto
VPN routes with OSPF
Advertises routes, but also learns
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
Normal Area
DR

Number of OSPF links on a device
10.10.0.0/24
10.10.1.0/24
10.10.2.0/24
10.10.3.0/24
…
...
etc.
DR-other DR/BDR

OSPF areas on a device
AREA 0
AREA 1
backbone area
AREA 2
normal, stub or not
so stubby areas
ABR
SPF calculations:
• convergence
• any network topology changes
Route Summarization!

OSPF on MS
Recap of key considerations
Neighbor per subnet
Be mindful of the workload
OSPF links per device
Size the appropriate hardware
OSPF areas per device
Minimize calculations, summarize

OSPF on MX appliances
EMEAR Region
1000’s sites
APJC Region
1000’s sites
NA Region
1000’s sites
Auto-VPN
Auto VPN
OSPF
static routes

Auto VPN – auto routing
MX route redistribution
VPN
L3 switch
L3 switch
L3 switch
subnet A static route
OSPF route
OSPF route
OSPF: on
OSPF: on
OSPF: on
subnet B
subnet C
Route Table
subnet A
Route Table
subnet A
Route Table
subnet A

Auto VPN – auto routing
MX route redistribution
L3 switch
L3 switch
L3 switch
OSPF: on
OSPF: on
OSPF: on
subnet B
Route Table
subnet A
Route Table
subnet A
Route Table
subnet A
static route
subnet B
subnet B
subnet B
OSPF route
OSPF route
VPN

OSPF on MX – key considerations
If you are using…
… Routed mode
OSPF
WAN
LAN
OSPF packets are only sent
out of the LAN interfaces
…passthrough mode
WAN
LAN
OSPF
OSPF packets are only sent
out of the WAN interfaces
… other subnets
OSPF
static
route
Requires the configuration
of static routes

TOPIC
BGP for scalable WAN
routing & redundancy

BGP basics
ISP
Advertising IP Ranges
ISP 1 ISP 2
Multihoming
SP
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
AS: 65002
Peer 2
Routes
c.c.c.c -> local
d.d.d.d -> local
AS: 65001
Peer 1
TCP: 179
Routes
a.a.a.a -> local
b.b.b.b -> local
Prefixes
a.a.a.a -> local
b.b.b.b -> local
c.c.c.c -> BGP: AS 65002
d.d.d.d -> BGP: AS 65002
Prefixes
c.c.c.c -> local
d.d.d.d -> local
a.a.a.a -> BGP: AS 65001
b.b.b.b -> BGP: AS 65001
More than 1 path?
Various metrics, but typically the best path to the destination will be the shortest AS path (fewest hops)

BGP operating modes
eBGP and iBGP
B
A C
D
Default
Gateway
eBGP
eBGP
eBGP
iBGP
Path: 65000 > 65001 (2 hops)
Path: 65000 > 65003 >
65001 (3 hops)

MPLS
(customer view)
MPLS or Auto VPN
MPLS
(service provider view)
Auto VPN
(customer view)

Meraki BGP
Deployment fundamentals
• Auto VPN between hubs (one-armed
concentrator) and spokes (Routed or one-
armed concentrator)
• Auto VPN domain is considered a single BGP
Autonomous System
• When BGP is enabled, all hubs and spokes
within the AS share routes via iBGP and no
longer use the Auto VPN registry
• Hubs will learn and advertise routes via their
eBGP neighbors in other AS’s
• By default MXs do not share learned routes
from other AS’s – this prevents routes from
transiting through the Meraki AS
eBGP
Branch Offices
AutoVPN
Branch A Branch B Branch C
AS 65000
eBGP
Data Center 1
AS 65001
Data Center 2
AS 65002
VPN concentrator in DC2
VPN concentrator in DC1
Routed mode – iBGP
Only
eBGP in DC1 edge device eBGP in DC2 edge device
iBGP
Hub 1 Hub 2
eBG
P

Hub 2 is secondary
concentrator
Hub 1 is primary
concentrator
Meraki BGP use cases
DC-DC Failover spoke sites
• Spoke sites will form VPN tunnels to both
primary and secondary hubs
• Spoke sites will learn and maintain route
information learned via BGP from both hub sites
• Concentrators at each data center advertise
spoke site routing information to DC edge
devices
• The scalability of this solution is preserved with
max limits for BGP routes – this will protect the
Auto VPN domain from route leaks
• Route table integrity will be protected by utilizing
AS Path Access Lists
• AS Path pre-pending adds hops based on hub
priority
Branch Offices
Data Center 1
AS 65001
Data Center 2
AS 65002
AS 65000
AutoVPN
iBGP
Branch B
eBGP eBGP
eBGP in DC1 edge device eBGP in DC2 edge device
Hub 1 Hub 2
DC routes advertised southbound
Prepends ASN 1x
65000 1
Prepends ASN 2x
65000 1 2

An IPv6 address
2001:0db8:85a3:0042:1000:8a2e:0370:7334
Global Routing Prefix
/48
Subnet ID
/64
Host
64 bits
• 128 bits
• Hexadecimal notation
• Sets of 16 bits
• Link Local (FE80::)
• Global

IPv6 Aggregation
ISP
IPv6
Customer 1
Customer 2
Customer 3
2001::/16
2001:0410::/35
2001:0410:1::/48
2001:0410:2::/48
2001:0410:3:1000::/56
2001:0410:1:1::/64
2001:0410:2:1::/64
2001:0410:3:1000:1::/64

IPv6 on Meraki devices
MX
MS
MR
ISP
The MX uses DHCP-NA or SLAAC to
obtain prefixes to be used on the LAN
The MX generates a /64 for the VLANs
The MR, MS, and client devices will all
obtain an IPv6 address from the MX
using autoconfiguration

Lesson 4 review
Can you explain Meraki’s implementation
of dynamic routing protocols across the
various product platforms?
Can you describe the best practices when it
comes to implementing routing on L3
capable Meraki MS switches?
Are you able to configure OSPF on your MX
appliance as a method of automatically advertising
VPN routes to downstream L3 OSPF neighbors?
Be able to increase VPN scalability and
integrations with data centers through the use of
the MX’s implementations of MPLS and BGP

Which of the following statement about OSPF support on Meraki MX security appliances is FALSE?
A. MX appliances in Routed mode must be configured with VLANs disabled
B. MX appliances can be configured in Passthrough mode
C. MX appliances only support OSPF with an Advanced Security license
D. MX appliances leverages OSPF to advertise remote VPN subnets to neighboring L3 devices
E. All MX appliance models support OSPFv2
Which TWO of the following statements about the OSPF support for Meraki MS switches are FALSE? (select 2)
A. OSPF dead timers on MS Switches are predetermined and cannot be changed
B. MS switches advertise and learn routes via OSPF
C. MS switches are capable of implementing MD5 authentication
D. MS switches only support Normal, Stub, and Not-So-Stubby areas
E. All MS switch models have OSPF capability

QoS & traffic shaping design
Wireless & wired QoS design |
Preparing the network for voice |
Traffic shaping & prioritizing with the MX
LESSON 5

TOPIC
Wireless & wired QoS design

Traffic classification
E-Mail, Web browsing
Traffic Classification
Admin/Management Traffic
E-Commerce
VoIP/SIP/Skinny
Voice
Mission Critical
Transactional
Best-effort
(low latency)
(guaranteed)
(delivery not
guaranteed)
(delivery not
guaranteed)
1
2
3
4
A
B
C
D

QoS design principles
True or False?
1
2
3
Classify and mark applications as close to their
sources as technically and administratively feasible
Mark at Layer 3 whenever possible
Follow standards-based markings to ensure
interoperability and future expansion
T F
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?
What is the name of the standards?
MR MS MX
WMM DiffServ
What are the configurable QoS mechanisms?
QoS policies
Traffic shaping
CoS queues
DSCP (added, modified
or trusted)
Load balancing
QoS policies
Prioritization & traffic shaping

Wireless QoS – upstream
Wireless Multimedia (WMM aka 802.11e)
Voice
Video
Best effort
Background
WMM classes
Client supporting
WMM sends traffic
AP honor all upstream
QoS sent by client
Fast Lane

Wireless QoS – 802.11e
Queuing with Enhanced Distributed Channel Access (EDCA)
Wait Wait
Voice
Video
Best effort
Background
Previous Packet
n slots 0 – m slots
Next Packet
Minimum Random Backoff
WAIT (AIFSN) Wait
2 slots 0 – 3 slots
2 slots 0 – 7 slots
3 slots
7 slots
0 – 15 slots
0 – 15 slots
Minimum Random Backoff
Assumptions:
• WME Default Parameters
• Backoff values shown are for initial
CW equal to Cwmin = 15
SIFS
SIFS
SIF
S
SIFS
SIFS
SIFS, slots, timers
vary based on protocol
(802.11 a,b,g,n)

Wireless QoS – upstream
Mapping wireless (WMM) to wired (DiffServ)
DiffServ
WMM
IEEE 802.11 (802.11e WMM-AC)
Voice AC (AC_VO)
802.3 DSCP (decimal)
46
802.3 DSCP
EF + 44
RFC 4594-Based Model
Voice + DSCP-Admit

Wired QoS – DSCP and CoS
DstMAC SrcMAC
VLAN ID
12-bit
ECN
2-bit
SrcIP DstIP Payload FCS
Frame *
L2 Encapsulation Frame payload (L3 packet)
802.1Q tag
* Note: an actual frame/packet contains other important fields, omitted in this graphic for simplicity.
802.1p
CoS
3-bit
DS (TOS)
DSCP
6-bit
CoS 0 (default) 1 2 3 4 5
Weight 1 2 4 8 16 32

CoS bandwidth calculations
Suppose we have a switched environment with the following…
What is the resulting percentage of bandwidth allocated to each?
8
4
1
(8+4+1)
(8+4+1)
(8+4+1)
62%
30%
8%
CoS queue 3
CoS queue 2
unclassified
CoS 0 (default) 1 2 3 4 5
Weight 1 2 4 8 16 32
CoS queue weight
Sum of all configured
CoS queues weight
% of Bandwidth
/ =
/
/
/
=
=
=

TOPIC
Preparing the network for voice

Ensuring VoIP readiness
4. Mark packets (adding a DSCP tag)
Once a packet is marked, it is placed into the
corresponding layer-2 CoS queue for forwarding
1. End-to-end QoS
When configured in Dashboard, QoS settings
automatically apply to all MS switches in the network
4
3
1
2
3. Honor DSCP tags
Trust DSCP tags set by other devices (e.g. IP phones)
2. Voice VLAN
To separate broadcast domains and enforce
prioritization
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
LAN Traffic
Classify traffic and
forward based on app
(L7)
Traffic Shaping and
Prioritization
10 Mbps
5 Mbps
Traffic distribution is
proportional to the path
bandwidth ratio. In the
example above, WAN1
gets 2x packets as WAN2
WAN Uplinks
WAN1
WAN2
Round
Robin Scheduler
4x
2x
1x
4x, 2x, 1x packets
are consumed
respectively from
each queue
4x
2x
1x
Path Selection
Mux
Selection based on
L3/4 classifiers.
Unclassified traffic is
distributed based on
WAN1 / WAN2 ratio
High
Normal
Low
L7 classifiers. The
default priority is
Normal
Priority Queues
High
Normal
Low
Step 1
Step 2 Step 3
Low Latency Queue (LLQ)

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.
Guest subnet
Secondary
ISP 1
10 Mbps
Primary
ISP 2
5 Mbps
ISP 3
1 Mbps
Backup
WAN 1: 10 Mbps
WAN 2: 5 Mbps
Cellular: 1 Mbps
1
2
Valid uplink states
Critical business apps:
Non-critical business apps:
High
Low
Priority:
Guest subnet:
WAN 1
WAN 1
WAN 2
Active
Standby
Down
Policy-based routing
Traffic shaping
YouTube:
WebEx:
Online backups:
1 Mbps
2 Mbps
Unlimited

Lesson 5 review
Do you understand the importance of proper
QoS design and its implementation across
Meraki wireless and wired networks?
Be able to configure your switching
infrastructure to prioritize latency sensitive
traffic such as VoIP
Understand and deploy Meraki’s
recommended wireless voice best
practices through Dashboard
Are you able to configure and optimize traffic
patterns with policy-based routing and packet
prioritization through granular traffic shaping rules?

Which TWO of the following features/options can be configured on MS switches? (select 2)
A. Traffic prioritization
B. 6 different COS queues
C. Load balancing across uplink ports
D. Layer 3 and layer 7 traffic shaping
E. Adding, modifying, and trusting DSCP tags
On the SD-WAN & traffic shaping page, which TWO of the following areas needs to be configured to
properly enforce load balancing across multiple links? (select 2)
A. Uplink speed
B. Load balancing
C. Flow preferences
D. Custom performance classes
E. Traffic shaping rules

Routed mode concentrator (routed mode)
Deployments
Very commonly implemented in branch or campus
networks
Public IP address
Internet port is most often given a public IP address
Use of LAN ports
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
NAT concentrator
and firewall
WAN 1 WAN 2 LAN 1
LAN switch
Internet

One-armed concentrator
Datacenter deployments
One-armed concentrator is the recommended
design choice
Single ethernet connection to the upstream network
All traffic is sent and received on the interface
Strategically assigned private IP address
IP addressing via DHCP or the use of a public IP
address on this interface is highly discouraged
NAT not performed by the MX
NAT is performed at a datacenter edge usually by
a Cisco ASA or third-party firewall
One-armed VPN
concentrator
WAN
Datacenter
switches
Internet
Datacenter
edge
L3 core router
Datacenter
services

Routed mode concentrator (DC deployment)
Datacenter deployments
A Routed mode concentrator should be
positioned in between the datacenter edge and
the services edge
Separate ports for upstream and downstream
Internet port(s) and LAN ports are used
separately: upstream (WAN) towards the network
edge; downstream (LAN) closer towards the
datacenter services
Public IP assignment
Can be configured (ideally statically assigned)
with either a publicly routable IP address or be
deployed behind another NAT device within the
datacenter topology
NAT VPN
concentrator
LAN 1
Datacenter
switch
Internet
Datacenter
edge
L3 core router
Datacenter
services
WAN
Datacenter
switches

VPN Topology
Full mesh
• All peers are connected to provide the
shorted possible path
• Reduces latency for applications between
locations
Routing Strategy
Full tunnel
• All network traffic (including internet
bound) from remote peers traverse back
to a central site where security and
internet access policies are enforced
Hub-and-spoke
• Multiple remote peers (spokes) are
connected to a central hub
• Spoke to spoke traffic traverses the hub
Split tunnel
• Traffic can be split at the branch location,
using local ISP connections for direct
internet access and VPN tunnels to
communicate between VPN peers

VPN topologies
Full mesh
Pros:
• Reliable
• Redundant
Cons:
• Expensive
• Harder to scale

VPN topologies
Exit hubs in a full mesh
Exit Hub
Internet

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)

Connection monitor
Three tests to validate WAN connectivity
WAN1 WAN2
0. Physical
1. ARP
2. DNS
3. Internet (ping, HTTP get)
Internet

Cloud orchestration of VPN
Internet
MPLS
VPN Registry
Site & Uplink Interface IP Public IP Source Port
Site A – WAN 1 5.5.5.5 5.5.5.5 35000
Site A – WAN 2 192.168.0.10 4.4.4.4 44000
Site A
Site B
Site C
Site D
Site D – WAN 1 10.0.0.2 6.6.6.6 33000
Site D – WAN 2 192.168.0.11 4.4.4.4 47000
UDP hole punch
Internet
Internet
Internet
Internet
Destination port: UDP 9350
Source port: UDP 32768 - 61000

Cloud orchestration of VPN
Site A
Site B
Site C
Site D
Internet
Internet
Internet
Internet
Internet
MPLS

TOPIC
Designing a scalable VPN topology

Design complexity
Number of tunnels
Hub A
Hub B
ISP 1 ISP 2
2 Hubs = 4 tunnels/hub
Hub A ISP 1 to Hub B ISP 1
4 Hubs + 100 Spokes = ? Tunnels per hub/spoke
W2
W1
W1 W2

Tunnel count formulas
Hub and Spoke Full Mesh
𝐻 − 1 ∗ (𝐿1
2
) + 𝑆 ∗ 𝐿1 ∗ 𝐿2
𝐻 ∗ 𝐿1 ∗ 𝐿2
𝐻 − 1 ∗ 𝐿1
2
𝐻
𝑆
𝐿1
𝐿2
number of hubs
number of spokes
number of hub uplinks
number of spoke uplinks
Hub tunnel count
Spoke tunnel count Not Applicable

Tunnel calculations
Example 1: Full mesh topology
Hub tunnel count
Recommended MX model for hubs?
MX105 (or higher) = max VPN throughput
is 1 Gbps
𝐻 − 1 ∗ 𝐿1
2
=
20 hubs with 2 uplinks each
500 Mbps of VPN throughput per hub
number of hubs
number of spokes
𝐿1
𝐿2
𝑆
𝐻 number of hub uplinks
𝟐𝟎 − 𝟏 ∗ 𝟐𝟐
= 76

Tunnel calculations
Example 2: Hub-and-spoke topology
Spoke tunnel count
Hub tunnel count
Recommended MX model for hubs?
Recommended MX model for spokes?
MX75 (500 Mbps, 75 concurrent tunnels) or higher
Any MX device, except Z3(C)
𝐻 − 1 ∗ (𝐿1
2
) + 𝑆 ∗ 𝐿1 ∗ 𝐿2 =
𝐻 ∗ 𝐿1 ∗ 𝐿2 =
2 hubs with 2 uplink each
200 Mbps of VPN throughput per hub
5 spokes with 2 uplinks each
50 Mbps of VPN throughput per spoke
number of hubs
number of spokes
𝐿1
𝐿2
𝑆
𝐻 number of hub uplinks
= 𝟐 − 𝟏 ∗ (𝟐𝟐
) + 𝟓 ∗ 𝟐 ∗ 𝟐 = 𝟐𝟒
2 ∗ 2 ∗ 2 = 8

Datacenter redundancy with Auto VPN failover
A DC-DC failover architecture is as follows:
L3
Core
Router
Datacenter
Edge
Branch Location
Datacenter
services
One-armed VPN
Concentrator
Datacenter
switches
L3 Core
Router
Datacenter
Edge
Internet Datacenter
services
One-armed VPN
Concentrator
Datacenter
switches
Inter-DC
Connection
Primary DC Secondary DC
• One-armed VPN concentrator or
Routed mode concentrators in each
DC
• 1 or more subnet(s) or static route(s)
advertised by 2 or more
concentrators
• Hub & spoke or Full Mesh topology
• 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
AWS / Azure
IPSec VPN IPSec VPN IPSec VPN
Overhead required:
• Manual configurations
• Additional setup for redundancy
• Manual (static) routing
• Dynamic routing requires BGP
• Physical connectivity requirements

vMX in the public cloud
AWS / Azure
Auto VPN Auto VPN
vMX
Auto VPN

vMX deployments in the public cloud
Global support for all
major public clouds
• 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
• Instance usage costs (cloud provider)
• vMX license (Cisco Meraki)
$

vMX – concentrator vs NAT mode
Concentrator NAT
Destination Next Hop
VPC Subnet Local
Subnet A vMX
Subnet B vMX
Subnet C vMX
0.0.0.0/0 Internet GW
Destination Next Hop
VPC Subnet Local
0.0.0.0/0 Internet GW
AWS / Azure
Auto VPN Auto VPN
vMX
Auto VPN
Subnet A Subnet B Subnet C

vMX-M specs:
500 Mbps VPN throughput
250 concurrent tunnels
vMX-100 specs:
vMX license sizing
vMX-S specs:
200 Mbps VPN throughput
vMX-L specs:
1 Gbps VPN throughput
*not all cloud providers currently support vMX-L

TOPIC
Software-defined WAN
(SD-WAN) fundamentals

WAN growth options
M P L S
B R O A D B A N D
AUG ME NTE D MP LS
BRANCH
HQ / DC
B R O A D B A N D
B R O A D B A N D
BRO ADBAND -BRO ADB AND
BRANCH
HQ / DC
M P L S
BRANCH
HQ / DC
MP LS O NLY
MERAKI SD-WAN
1
2
3
• Increase the capacity of an existing MPLS network
• Supplement an existing MPLS network with
broadband for increased bandwidth
• Offload critical traffic from MPLS to broadband
with policy based routing dynamic path
selection
• Dual high speed broadband connections
• Load balance business critical traffic based on
policy or link performance
R
E
D
U
C
I
N
G
C
O
S
T
● business critical
● non-critical AVERAGE
PRICE OF WAN
CONNECTIVITY
[Source: BusinessInternet.com, How much does business internet cost, 2017]
Broadband
MPLS
$15
$775
[PER 10Mbps PER MONTH]

SD-WAN
Three key features:
• Dual-active path
• Dynamic path selection
• Policy-based routing (PbR)
WAN 1
Secure VPN tunnel (active)
Latency / loss > threshold
WAN 2
Secure VPN tunnel (active)
Latency / loss < threshold
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
Data

Benefits of SD-WAN
BRANCH
MX
WAN link 1
WAN link 2
Dual active VPN
Increased bandwidth and improved reliability
BRANCH
MX
WAN link 1
WN link 2
Internet
MPLS
Transport Independence Concept
Supported over any Internet or MPLS link
Improved reliability
Automatic failover and high availability
Enhanced visibility
Live and historical tools for monitoring
BRANCH
MX
WAN link 1
WAN link 2
Business critical
Non critical
BRANCH
MX
WAN link 1
WAN link 2

SD-WAN algorithm
Dual path availability
Unchecked
Unchecked
Unchecked
Decision:
Use the only active path!
Can I establish VPN on
both interfaces?
W2
W1
L1
W1
Performance based
flow match?
Policy based flow match?
Is load balancing on?
NO

SD-WAN algorithm
No match or default/empty configurations
Decision:
No to all, so we’ll default to
using the primary interface!
both interfaces?
W2
W1
L1
Performance based
flow match?
YES
NO
NO
NO
W1

SD-WAN algorithm
Load balancing
Decision:
Load balance across
both interfaces?
both interfaces?
Performance based
flow match?
YES
NO
NO
W1
W2
W1
L1
YES

SD-WAN algorithm
Policy-based routing
W1
W2
W1
L1
What is the policy for
this flow?
YES
Performance based
flow match?
Decision:
Follow the defined policy!
Use WAN 2
both interfaces?
YES
NO
Unchecked

SD-WAN algorithm
Performance based routing (1 path)
W1
W2
W1
L1
Performance based
flow match?
Which links satisfy
performance criteria?
Decision:
Follow the defined
performance criteria!
YES
Only WAN 1
Unchecked
Unchecked
both interfaces?
YES

SD-WAN algorithm
Performance based routing (0 or 2 paths)
W1
W2
W1
L1
Decision:
Check if there is a policy based match and
if load balancing is on before making decision.
NO
NO YES
YES
Unchecked
YES
Neither / both links
Which links satisfy
performance criteria?
both interfaces?
YES

SD-WAN
Full decision flow chart

Performance probes
Each uplink will send a probe across all available paths
Probe: 100 byte UDP (based on Protobuf) with no DSCP marking
• 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
10 15 20
path latency
Current average:
15 ms
Incoming latency value
Calculated Jitter K =
Latency (K + 1) – Latency K
Incoming loss value
20 15 10
5 5 0
path jitter
Current average:
4 ms
5 5 …
0 0 0
path loss
Current average:
0%
0 0 0
MX A
MX B
W1 W2
W1 W2
1 4
2 3

Gathering requirements and design choices
Application List
What are the business critical applications
that this network will be supporting?
Sites and Locations
Where are applications hosted?
Where are users located?
Traffic Flow
What is the estimated traffic flow per
application between each two sites?
Performance Requirements
What are the network performance
requirements for these applications?
Site Internet Breakout
Identify sites that require local internet breakout
Site-to-Site connectivity
Select sites that are to be directly connected
Redundancy
Design proper warm-spare MX and
dual WAN link implementations
Throughput Speeds
Determine necessary broadband
speeds for each location

Example design scenario
HQ
Branch 1 Branch 2 Branch 3
Private
Data Center
Cloud Services
Cisco Collaboration System
• CUCM with SIP breakout at the Private Data Center
• Phones at HQ and Branches
Private Email Server
• UCS server at the Private Data Center
• Users at HQ, Branches, and Remote
Cloud Storage Service
• Cloud service hosted on the public cloud
• Users at HQ, Branches, and Remote
SQL Database
• AWS deployment in the public cloud
• Users at HQ only

HQ
Private
Data Center
Cloud Services
Cisco collaboration system
Cisco Collaboration System
• CUCM with SIP breakout at the Private Data Center
• Phones at HQ and Branches
Calls between HQ and branches
Calls from HQ and branches to SIP breakout
CUCM to phones (management data)
Delay up to 100ms
Jitter up to 2ms
Packet loss up to 2%
MX redundancy (warm-spare)
recommended
SIP

HQ
Private
Data Center
Private email server
Private email server
• UCS server at the private data center
• Users at HQ, branches, and remote
Traffic flow: users at HQ and branches to DC
Traffic flow: remote users to DC (via client VPN)
MX redundancy (warm-spare)
recommended
Remote

HQ
Private
Data Center
Cloud storage server
Cloud storage server
• Cloud services hosted on the public cloud
• Users at HQ, branches, and remote
Traffic flow: each user to a cloud
application hosted on a third party public
cloud
Local internet breakout at each site
Remote

HQ
Private
Data Center
SQL database
SQL database
• AWS deployment in the public cloud
• Users at HQ only
Traffic flow: users at HQ to an
application hosted in AWS environment
Delay up to 50ms
Jitter up to 10ms
Packet loss up to 2%

Proposed VPN topology
Branches as VPN spokes
vMX at the AWS deployment
MX redundancy at the DC and HQ
Local internet breakout at each site
Split tunnels
VPN NAT concentrator at DC & HQ
VPN NAT concentrator at Branch sites
VPN one-armed concentrator vMX in cloud
Client VPN concentrator at DC
HUB
HUB
Spoke Spoke Spoke
Spoke
(vMX)
Hub-to-hub tunnel
Hub-to-spoke tunnel
Remote

Proposed WAN topology and SD-WAN
Private DC
HQ
Branch Branch Branch
Public
Cloud
Remote
Two custom performance classes
• Voice: 100 ms delay, 2ms jitter, 2% loss
• SQL: 50ms delay, 10ms jitter, 2% loss
Implementation locations
SD-WAN rules implemented at HQ
and branch locations
Dual WAN
Each location has dual broadband connections
from different Internet Services Providers
Load balancing
Load balancing enables at all locations

Lesson 6 review
Can you differentiate between different MX
VPN operation modes, VPN topologies, as
well as their pros/cons/use cases?
Can you explain the mechanism
behind Auto VPN?
Be able to design a scalable Auto VPN
architecture that utilizes appropriately-
sized Meraki MX appliances?
Do you understand the primary
functions of SD-WAN, its key features,
and the benefits that it delivers
Be able to design and successfully
configure SD-WAN in the Meraki Dashboard

Which of the following information is stored in the Meraki cloud VPN registry?
A. An administrator-defined PSK for each Auto VPN tunnel
B. Interface MAC address
C. Public IP address
D. TCP hole punching logs
E. Randomly chosen well-known UDP ports (0-1023)
What are TWO design requirements for proper, functional SD-WAN deployment? (select 2)
A. MX properly configured in an HA-pair
B. L3 routing configured on the MX security appliance
C. Dual-active VPN paths
D. Performance and policy-based rules configured on the MX
E. Load-balancing enabled and configured for a 1:1 ratio

Securing the network with
Advanced Security features
Security intro | Default behavior and rules processing order |
Advanced security services | Content filtering |
Umbrella integration
LESSON 7

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.
Business goals:
Prevent breaches automatically to keep the business moving
& automate operations to save time and reduce complexity
Advanced Malware Protection &
Secure Malware Analytics
AMP
Dynamic content filtering
Layer 3 firewall Geo-based firewall
Layer 7 rules
APP
Intrusion Detection & Prevention

Threat intelligence from Cisco Talos
NGFW Malware Analytics Meraki Network ISR/ASR Stealthwatch
Snort IPS ISE Cloudlock Umbrella AMP
Per day: 1.5 million malware samples, 600 billion
email messages, 16 billion web requests
Did you know? Cisco Talos is the world’s largest non-government threat intelligence organization.
350+ full-time threat researchers,
analysts, and engineers

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
LAN WAN
Routed mode MX
✕
DENY INBOUND
ALLOW OUTBOUND
ALLOW INBOUND (return traffic)
ALLOW ICMP
ALLOW INBOUND & OUTBOUND
VPN

Rules processing order
• 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.
YES
YES
DENY
NO NO
Traffic received Matching L7
Rule?
Matching L3
Rule?
Traffic allowed
Traffic blocked
ALLOW
Allow/Deny?

L3 Firewall Rule
L3 Default
Firewall Rule
L7 Firewall Rule L7 Firewall Rule
Policy Protocol Source Src port Destination Dst port
Deny TCP Any Any 10.0.0.2 Any
match
Packet discarded as it matched a deny L3 firewall rule

L3 Firewall Rule
L3 Default
Firewall Rule
Allow Any Any Any Any Any
Policy Application
Deny Gaming All Gaming
no match
match
match
Packet discarded as it matched a L7 firewall rule

L3 Firewall Rule
L3 Default
Firewall Rule
Allow Any Any Any Any Any
Policy Application
Deny Gaming All Gaming
Policy Application
Deny HTTP hostname bbc.co.uk
no match
match
no match
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
Retrospective disposition
File download request
URL/SHA256 in allowlist? → ALLOW File download
5201c5c551063912a55f794e9b26352f… AMP
File disposition
[clean | malicious | unknown]
clean or unknown→ ALLOW
malicious→ ALERT
malicious→ DENY✕
Not allowlisted→ Send hash to AMP cloud

AMP
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…
File disposition: unknown
unknown→ ALLOW
(first time)
Threat score
clean → ALLOW
malicious→ DENY ✕
72
Threat
score
15
Behavioral
indicators
SMA
95
Threat
score
Database
Update

Advanced security services: other considerations
The MX currently supports Integration with SMA cloud.
(no integration with on-prem SMA appliance)
Supported file types:
E-mail alerts can be configured for malware events
(including retrospective) in the Network-wide > Alerts page.
EXE
ZIP
PDF
XLSX
Platforms: Windows 7 64 bit (English, Korean, Japanese) & Windows 10
AMP
Supported file types:
EXE PDF
SMA
Unlimited AMP cloud lookups. Number of file submissions determined on file analysis pack.

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
Snort
Ruleset:
Connectivity (CVSS = 10)
Balanced (CVSS = 9, 10) → default
Security (CVSS = 8, 9, 10)
CVSS [8|9|10]→ DENY✕
CVSS less than [8|9|10]→ ALLOW
Not allowlisted→ Snort service

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
Add to MX local cache
Talos
In blocked category→ BLOCK ✕
NOT in blocked category→ ALLOW
If HTTP:
redirected to custom
block page
If HTTPS:
website times out
URL NOT in local cache? → Send to Talos
*Talos-powered content filtering requires MX 17.x or higher firmware

Meraki MR and Cisco Umbrella
DNS firewall is a relevant control against one-third of cyber-security breaches over the last 5 years
One License, Two Solutions
MR Advanced will license MR
devices and include Umbrella
MR Upgrade is an add-on for
already licensed MR devices
Increased Visibility
Security Center provides
org-wide reporting functionality
View MR DNS events
including blocked websites
Effortless Deployment
7 predefined Umbrella
policies (different security
settings + content filtering)
100% configured in Dashboard

MR + Umbrella integration
Applying pre-defined policies to SSIDs or clients to block content or security threats at the DNS layer
DNS query
LAN WAN
1. attaches an identifier for Umbrella enforcement
2. encrypt query using DNSCrypt
3. source NAT (MR management IP) and redirect to Umbrella resolver
ALLOWED→ encrypted DNS response with appropriate IP
BLOCKED→ encrypted DNS response pointing to blocked page IP
directed to desired domain name
redirected to Umbrella block page
Identifier
allowed?

Applying an Umbrella policy to an SSID
Step 1:
Select the desired SSID
Step 2:
Enable DNS layer protection
Step 3:
Select the desired Umbrella policy
from the dropdown list
Dashboard Location:
Wireless > Firewall and Traffic Shaping
3
1
2

Lesson 7 review
Can you identify and explain the
embedded security features on the
Meraki MX appliance?
Be able to protect your network
from malware with Cisco AMP
Be able to protect your network from
cyber internet threats with Cisco Snort
Understand content filtering capabilities with
the Meraki platform and utilize it effectively
to refine network traffic

What are the ruleset types that can be configured when enabling Intrusion Detection and Prevention on an
MX security appliance?
A. Critical, uptime, and passive
B. Balanced, connectivity, and security
C. Top list and full list
D. Block list and allow list
Which of the following accurately describes the firewall rules processing order of an MX security appliance?
A. L3 allow/deny > L3 implicit deny > L7 deny
B. L3 allow/deny > L3 implicit allow > L7 deny
C. L3 allow/deny > L7 deny > L3 default deny
D. L7 deny > L3 allow/deny > L3 implicit allow

Switched network
LESSON 8
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)
Supplicant Authenticator Authentication server
EAPOL RADIUS

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

Traditional segmentation tools:
• VLANs
• Access control lists
• Firewall rules
Limitations:
• Difficult to segment inside a VLAN
• IP addresses can change over time
• Where to put a firewall
• Administrative headaches
Traditional ways to secure a network
Staff
VLAN 200
192.168.200.71
IoT Server
VLAN 200
192.168.200.19
Staff
VLAN 10
192.168.3.173
IoT Device
VLAN 7
192.168.100.88
IoT Device
VLAN 8
192.168.110.54

IoT Device IoT Device
Staff
IoT Server
Staff
Staff
IoT
Device
IoT
Server
Staff
IoT
Device
IoT
Server
Policy
Securing a network with Adaptive Policy
Advantages:
• Policy is defined by identity
• No need to worry with IP addresses or VLANs
• Policy is populated onto every
supported switch and access point
Supported on:
• MS390, release MS14.5+
• 802.11ac Wave 2 and Wi-Fi 6
MR access points, release
MR27+

Staff
10
IoT
Device
20
IoT
Server
30
Staff
10
IoT
Device
20
IoT
Server
30
IoT Device IoT Device
Tag is applied at the source
IoT Server
Staff
SGT=10
SGT=20 SGT=20
SGT=10 SGT=30
To IoT Server
Policy
Dst MAC Src MAC 802.1Q ETYPE
CMD Payload
EtherType Version Length Opt Type SGT Options
0x8909
Cisco MetaData
Staff
Tag must be carried end-to-end
Policy is applied at the destination
Adaptive Policy in action

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
• 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)
1
3 2 4

Cloning MS switch configurations
XYZ
Branch A Branch B
MS 1
MS 2
MS 1
MS 2
XYZ
XYZ
XYZ

Cloning MS switch configurations: which settings?
Port-level
+
Switch-level Access policy (access only)
MAC allowlist (access only)
Allowlisted MACs (access only)
Sticky MAC allowlist (access only)
Allowlist size limit (access only)
Native VLANs (trunk only)
Allowed VLAN (trunk only)
VLAN (access only)
Voice VLAN (access only)
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.
STP bridge priority
Port mirroring
Port Name
Port Tags
Interface state
Spanning tree
STP guard / BPDU guard
PoE *
Link
Port schedules (access only)
Interface Type
What is NOT cloned?
Local Settings
(switch name, management IP)

TOPIC
Switch templates and profiles

Built-in automation with templates
Branch A
Switch 1
Switch 2
Template
Branch B
Switch 1
Switch 2
XYZ
XYZ
XYZ
XYZ
XYZ
DEF
DEF
DEF
DEF
DEF

Switch templates, profiles and settings
Branch A
Profile (8-port)
Branch B
8-port
24-port PoE
8-port
24-port PoE
XYZ
XYZ
XYZ
Profile (24-port PoE)
ABC
ABC
ABC
Template

TOPIC
LAN / WLAN guest
network design

Gathering requirements and design choices
Medium
Internet
Guest VLAN
Traffic
Isolation
Network
Resources
Required
Bandwidth
5 Mbps
5 Mbps
Encryption
ABC
#&^%
Blocked
Application
Traffic Shaping
File sharing – 1 Mbps
Online Backup – 1 Mbps
Onboarding
Experience
Duration

Wireless guest network
Open
PSK
Enterprise
Internet
ABC
XYZ
%*$&
#&^%
• Meraki RADIUS
• Internal RADIUS
Authentication methods

Wireless guest network - continued
NAT mode
Bridge mode
• Guest VLAN
• VLAN Tagging
• L3 Firewall Rule
• Layer 2 Isolation
• Bandwidth Shaping
• Traffic Shaping Rule
5 Mbps
5 Mbps
Online backup – 1Mbps
Internet
Traffic access and routing

Wireless guest network - continued
Splash Page
• Meraki
• External - Captive Portal API
5 Mbps
5 Mbps
− Sponsored Guest
− Self-Registration
Internet
Splash page options

Wired guest network
Internet
• Guest VLAN
• VLAN Tagging
• Port Isolation
• Bandwidth Shaping
• Traffic Shaping Rule
• Splash Page - Meraki
5 Mbps
5 Mbps
• ACL • L3 Firewall Rule

Lesson 8 review
Do you know how to improve a network’s
scalability and automation using MS switch
templates and profiles?
Be able to implement micro-
segmentation and simplify access
control by leveraging Adaptive policy
Be able to secure network access via
802.1X through leveraging Meraki
authentication

Select the correct statement concerning templates.
A. Only a single child network can be bound to a template network
B. Changes made to a child network will not affect the template network
C. A child network will only sync with a template network after a Dashboard admin configures a syncing
schedule
D. Only one template network can exist per organization
Which of the below options is NOT an available access policy types that can be enabled on an MS switchport?
A. 802.1X with Meraki authentication or RADIUS
B. MAC authentication bypass
C. Hybrid authentication
D. Rule and role-based access control (RBAC)

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
LESSON 9

TOPIC
Dashboard maps & floor plans

Maps in Dashboard
Where do we see/access maps?

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
RF
Profile
Band selection
Minimum
bitrate
Channel width
Transmit
power range
Combining pre-determined radio settings together in order to automate the deployment of configs at scale
for groups of access points

Profile types
• Default profiles (indoor and outdoor)
• Manual override for channel and transmit power
• 5 customizable predefined profiles
• Up to 50 RF profiles
Different RF profiles can be used to address different needs and spaces

TOPIC
Wireless encryption & authentication

Wireless encryption and authentication
802.11 association process
1. Probe Request
3. Authentication Request
5. Association Request
2. Probe Response
4. Authentication Response
6. Association Response

Wi-Fi Protected Access version 3 (WPA3)
SAE (Personal)
5. Authentication (Confirm) Seq 2
4. Authentication (Commit) Seq 1
3. Authentication (Commit) Seq 1
2. Probe Response
1. Probe Request
6. Authentication (Confirm) Seq 2
8. Association Response
7. Association Request
WPA3 Personal has two scenarios: A.) WPA3 SAE only and B.) WPA3 SAE transition mode (WPA2 + WPA3)

Association requirements and splash page options
Combinations
None Click-through
Sponsored
guest login
Sign-on
with (various)
Sign-on with
SMS Auth
Cisco ISE
Auth
SM Sentry
enrollment
Billing
Open
Pre-shared
key
MAC-based
Meraki
Cloud Auth
RADIUS
Local Auth
Identity PSK
E
N
T
E
R
P
R
I
S
E
✔ ✔ ✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔
✔ ✔ ✔
✔ ✔ ✔ ✔
✔ ✔ ✔
✔ ✔ ✔ ✔ ✔ ✔

Local authentication
Connecting to 802.1X protected SSID’s without relying on the reachability of a RADIUS server
Typical EAP
Framework
MR
(authenticator)
wireless client
(supplicant)
RADIUS server
(authentication server)
LDAP server
(e.g. Active Directory)
EAP
exchange
RADIUS
exchange
LDAP
exchange
Meraki Local Auth
MR
(authenticator + RADIUS server)
wireless client
(supplicant)
LDAP server
(e.g. Active Directory)
EAP
exchange
RADIUS exchange
(handled internally)
LDAP
exchange
✕ ✕
✕

IPSK authentication without RADIUS
Name: SSID 3
PSK: DEF
Use: warehouse
Name: SSID 2
PSK: ABC
Use: printers
Typical enterprise WLAN:
Multiple SSID’s, single PSK each
Name: SSID 4
PSK: XYZ
Use: digital displays
Name: SSID 1
PSK: (RADIUS)
Use: employees
PSK: DEF
Group policy:
inventory access
PSK: XYZ
Group policy:
office devices
PSK: ABC
Group policy:
office devices
Name: SSID 2
Name: SSID 1
PSK: (RADIUS)
Group policy:
employees
IPSK without RADIUS:
Reduced SSID’s, multiple PSK, map to group policy

TOPIC
SSID modes for client IP addressing

SSID modes for client IP assignment (access control)
NAT mode
IP Address: 10.1.1.50 IP Address: 192.168.1.2
(DHCP server)
IP Address: 192.168.1.1
Client Traffic
Source IP Address: 10.1.1.50
Client Traffic

Bridge mode
IP Address: 192.168.1.50 IP Address: 192.168.1.2 IP Address: 192.168.1.1
(DHCP server)
Client Traffic
Client Traffic

L3 roaming
IP Address: 192.168.1.2 /24
IP Address: 192.168.2.2 /24
IP Address: 192.168.1.50 /24

L3 roaming – distributed to help scale and provide redundancy
IP Address: 192.168.1.2 /24
IP Address: 192.168.2.2 /24
IP Address: 192.168.1.50 /24
VLAN 1 Anchor AP
“Client’s anchor AP
is: 192.168.1.2”
is: 192.168.1.2”
Host AP
Is VLAN 1 available? ✕
IP Address: 192.168.1.3 /24
is: 192.168.1.2”
Alternate Anchor AP

IP Address: 192.168.1.50 /24
L3 roaming – distributed to help scale and provide redundancy
Host AP
Anchor AP
Is VLAN 1 available? ✔
IP Address: 192.168.1.2 /24
IP Address: 192.168.2.2 /24
Anchor AP
client layer 2 roams
IP Address: 192.168.1.3 /24
is: 192.168.1.2”
is: 192.168.1.2”
is: 192.168.1.2”
is: 192.168.2.2”
is: 192.168.2.2”
is: 192.168.2.2”

L3 roaming with a concentrator
IP Address: 192.168.5.50 /24
VLAN 5
VLAN 5
VLAN 5
MX serving as the mobility
concentrator
IP Address: 192.168.5.1 /24
IP Address: 192.168.1.2 /24
IP Address: 192.168.2.2 /24

VPN: tunnel to a concentrator
(if split tunnel is configured)
MX as concentrator
corporate resources
Internet

BLE beacons
What does it look like?
Preamble
Access
Address
Header
MAC
Address
Beacon
Prefix
UUID Major Minor TX Power CRC
Size 1B 4B 2B 6B 9B 16B 2B 2B 1B 3B
Brand Store Shelf
(optional) (optional)

Dedicated security radio
Bluetooth Low
Energy beacon and
scanning radio
Dedicated
dual-band scanning
and security radio
2.4 GHz
802.11b/g/n/ax
radio
5 GHz
802.11a/n/ac/ax
radios

Wireless threats
Containment: The process by which clients will be unable to connect and any currently
associated clients will lose their connection to the rogue AP
SSID Spoofing
Legitimate
SSID
Malicious
SSID
Unsuspecting User
(connects to malicious SSID)
Corporate
SSID
Unauthorized
Wireless AP
Connected
Unauthorized User
(gains access to corporate
LAN resources)
Wired LAN Compromise

Rogue AP containment
2. Deauthorization messages
source = Rogue, destination MAC = client
Wireless Client
Rogue
Access Point
Meraki MR
w/ Air Marshal
802.11 packets being sent by MR:
1. Broadcast de-authorization
source = Rogue, destination = broadcast
3. Deauthorization & disassociation msgs
source = client, destination = Rogue
Source = Rogue AP
Destination = broadcast
Destination MAC = client Source = Rogue AP
Source = client Destination = Rogue AP

Lesson 9 review
Do you understand the importance and
proper utilization of maps, floor plans,
and RF profiles in Dashboard?
Be able to choose and deploy the proper combination of
wireless authentication, encryption, splash page, SSID
mode of client IP addressing, and SSID availability
Enabling BLE features and
understanding use cases
Do you understand how Meraki identifies
wireless threats and the remediation methods?

Which of the following features should be used if an administrator was tasked with automating the
deployment of pre-determined radio settings of hundreds of access points?
A. Network template with only access points
B. Bluetooth low-energy (BLE) scanning API
C. Bulk inventory import with a pre-filled CSV file
D. RF profiles
Which of the following SSID client IP addressing modes gives clients DHCP leases from the access point
itself on the 10.0.0.0/8 subnet?
A. Bridge mode
B. NAT mode
C. Layer 3 roaming
D. Layer 3 roaming with a concentrator

Systems manager overview
Network
Integration
Centralized
Management
Rapid
Deployment
App and Profile
Management
Remote
Troubleshooting
Security
Automation

TOPIC
Deployment methodologies

Enrollment options
• Manual
• Automated

Enrollment through Apple ADE (DEP)
1. Factory default device
checks in with Apple
2. Apple sees S/N is owned by
an MDM, enrollment forwarded
3. Admin configures and customizes
enrollment settings in Dashboard
4. Enrollment initiates –
SM, profiles, and apps are
auto pushed to device
5. Enrollment completes – device is
provisioned and ready to be used

Android zero-touch enrollment
1. Factory default
device checks for
with the Android
zero-touch portal
2. Zero-touch configs
specify SM as the EMM
device policy controller
3. Admin configures and customizes
enrollment using tags in Dashboard
to scope settings and apps
4. Device initiates the
fully managed device
provisioning method –
SM is downloaded,
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
1. Amber (employee)
needs access to
company resources
using their personal
mobile device
2. Admin enables Trusted
Access on Amber’s device
in Dashboard
3. Amber (employee)
visits the Self-service
Portal and downloads
a certificate
4. Amber’s device
gains secure access
to network resources
Allowed access?

Security and accessibility in 4 easy steps
Step 1:
Enable Trusted Access on an SSID
(association requirements must first be configured
as WPA2-Enterprise with Meraki authentication)
Dashboard Location:
Wireless > Access Control

Step 2:
Create end-user profile(s) in the
Systems Manager network
Dashboard Location:
Systems Manager > Owners
Step 3:
Select end-user’s network access
privileges and tie it to the Trusted
Access enabled SSID
Dashboard Location:
Systems Manager > Owners

Step 4:
Send the Self Service Portal link to
the end-user
(to download the trusted certificate)
Dashboard Location:
Systems Manager > General

Lesson 10 review
Be able to explain the various enrollment
methods of Systems Manager
Be able to utilize a SM as a platform to
secure sensitive enterprise data on devices
through containerization
Do you understand the device security
posturing capabilities of Systems Manager
when paired with security policies?
Be able to enhance the security of your Meraki
network through leveraging Systems Manager to
assign dynamic access

Which of the following is a valid Systems Manager Sentry integration with Cisco Meraki hardware?
A. Sentry Authentication (Systems Manager + MS switches)
B. Sentry Enrollment (Systems Manager + MR access points)
C. Sentry Gateway (Systems Manager + MG cellular gateway)
D. Sentry Vision (Systems Manager + MV smart cameras)
E. Sentry Healthcare (Systems Manager + MR PCI reporting)
Which feature allows client devices to access secured networks through MR wireless access points without
enrolling in Systems Manager?
A. Meraki Trusted Access
B. Systems Manager Sentry
C. Apple Device Enrollment Program (DEP)
D. Windows Agent Installation

Physical security concepts and practices
MV architecture | Flexible camera deployments with wireless |
MV portfolio | Business intelligence
LESSON 11

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
.ts
.ts
.ts
.ts
.m3u8
Playlist
Segments
• 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

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
-- Hashing algorithm is SHA256 --
-- Signing algorithm is RSA2048 --
-- Key parameters are secp384r1 --
-- Key exchange is Diffie-Hellman 2048 --
-- Cipher is AES128 --
Technical breakdown of certificates:

Local vs. remote video access
Direct access vs. cloud proxy
scene being
recorded
on-device
storage
Remote
“cloud proxy” stream
(access through Dashboard
or Meraki Vision Portal)
Local
“direct” stream
(access through Dashboard
or Meraki Vision Portal)
Meraki

Local or remote access?
Identify the connectivity method
1
2
3
4
Which method securely streams the video through
Meraki’s cloud infrastructure to the client?
Which method is used if the client has a direct IP route
to the camera’s private IP and is connected via HTTPS?
Which method is used if no VPN is established
between the client and the camera connection?
Which method consumes little to no WAN bandwidth while
streaming live or recorded camera footage to the client?
Local
(direct stream)
Remote
(cloud proxy)

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
• Enabled by an optional, per-camera license
• Archive data is stored in four data regions
(United States, Germany, Japan, Canada)
• Data stored in Amazon AWS
video frame
local
viewing client
(direct stream)
remote
viewing client
(cloud proxy)
on-device
storage
cloud
storage

TOPIC
Flexible camera deployments
with wireless

From analog to IP-based
power analog video
power
power
data

Indoor models - technical specifications
MV2
MV12
(N / W / WE)
MV22 MV22X MV32
Camera
lens
Highest
resolution
Advanced
analytics
Wireless-
enabled
Audio
recording
Storage
(in GB)
Varifocal
Fixed Fixed
Varifocal
Fixed
1080p
1920 x 1080
1080p
1920 x 1080
360°
2058 x 2058
4MP
2560 x 1440
1080p
1920 x 1080
✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔
256
0 256
512
128 to 256
✔ ✔ ✔ ✔
✔

Outdoor models - technical specifications
MV52 MV63 MV63X MV72X MV72X MV93 MV93X
Camera
lens
Highest
resolution
Advanced
analytics
Wireless-
enabled
Audio
recording
IP code and
IK rating
Storage
(in GB)
Fixed
Varifocal Varifocal
Varifocal Fixed
Fixed Fixed
4K
3840 x 2160
4K
3840 x 2160
4MP
2560 x 1440
1080p
1920 x 1080
360°
2880 x 2880
4MP
2560 x 1440
360°
2112 x 2112
✔ ✔ ✔ ✔ ✔ ✔ ✔
✔ ✔ ✔ ✔ ✔ ✔ ✔
1000
1000 512
256 1000
256 256
✔ ✔ ✔ ✔ ✔ ✔ ✔
IP67
IK10+
IP67
IK10+
IP67
IK10+
IP67
IK10+
IP67
IK10+
IP67
IK10+
IP67
IK10+

Advanced analytics
Doing more with the traditional security camera
Motion Search 2.0
improved algorithm + Motion Recap
Motion Heat Maps
a visualization of motion data
Object Detection
people, vehicle, and occupancy detection

Meraki MV Sense
Lots & lots of
video data
INPUT
How many were here
at X time?
HISTORICAL
AGGREGATE
How many people
are here now?
CURRENT SNAPSHOT
Sub-second feed of
objects and location
REALTIME FEED
MV COMPUTER VISION /
MACHINE LEARNING ALGORITHM
THIRD PARTY
APPLICATIONS
REQUEST
REQUEST
SUBSCRIBE
10 trial MV Sense included in every MV organization!

Lesson 11 review
Can you explain the difference between
traditional physical security camera architecture
versus that of Meraki MV camera architecture?
Be able to choose and implement the
proper retention and storage options
including Cloud Archive
Be able to configure MV cameras to be
deployed over the WLAN
Do you understand how Motion Search, visual heat
maps, and the person detection capabilities of the
MV cameras help to provide business intelligence?

Which of the following is a part of the process when deploying MV cameras across the WLAN?
A. Adjusting upstream firewall settings to allow for potential camera proxy streaming
B. Creating a backup Dashboard network admin with camera-only permissions
C. Disabling a camera's local status page to reduce WLAN security risks
D. Purchasing an add-on license to enable wireless connectivity
Which of the following statements about recorded video footage is correct?
A. Recorded footage can be stored directly on the camera
B. Recorded footage can be stored in the cloud
C. Recorded footage can be streamed through a MQTT broker server
D. Recorded footage stored on a camera will be retained even if the camera is removed from the network

Gaining network insight
through application monitoring
Application performance monitoring |
WAN and Internet outage monitoring |
Scaling & licensing | Smart Thresholds
LESSON 12

TOPIC
Application performance monitoring

Cloud services: traditional troubleshooting
• Thomas, the employee, has an issue accessing Gmail.
• He notifies Jenna, the IT administrator.
• Jenna does troubleshooting using available tools and believes that
the ISP is the root cause of the issues.
• Jenna calls their ISP and after some time is routed to Anna, the SP
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.
• Result: Jenna is back at square 1 and needs to continue
troubleshooting the problem without conclusive evidence and has
wasted a lot of valuable time.
Thomas
(Employee)
Jenna
(IT admin)
Anna
(ISP Customer
Representative)
Adam
(Cloud Services
Representative)
traceroute
pcap
ping

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 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.
Jenna
(IT admin)
Anna
(ISP Customer
Representative)

Traffic analysis
MX with MI enabled
Meraki Cloud
(with Insight engine)
client (end user) LAN web apps & cloud services
ISP
Internet /
WAN

Performance metrics and indicator
Network
• Performance Score
• Total Network Usage
• Latency
Application
• HTTP response time
• App usage
• HTTP request rate
LAN
• Available Goodput (LAN-limited)
• LAN loss
• LAN latency
• Total network usage
WAN
• Available Goodput (WAN-limited)
• HTTP response time
• WAN loss / WAN latency
• Total network usage
Performance Indicator
< 80% ≥ 80%

TOPIC
WAN and Internet outage
monitoring

WAN Health
At-a-glance view of the status of all WAN links
1. Primary uplink
2. Secondary uplink
3. Cellular uplink
4. All networks with MX + MI license in
the organization
Secondary
ISP 1
Primary
ISP 2
ISP 3
Cellular
MX + MI License

Monitoring interfaces
Primary, secondary, and cellular uplinks

Internet Outages
A global overview of network outages in service providers around the world

Insight licensing
MX models License size
FW Throughput
Z3 I Z3C Extra Small
Up to 100 Mbps
MX6x Small
Up to 450 Mbps
MX75 I MX84 I MX85
MX95 | MX100 | MX105
Medium
Up to 750 Mbps
MX250 I MX400 I MX600 Large
Up to 5 Gbps
MX450 Extra Large
Up to 10 Gbps

Licensing scenario
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)
MX105
MX450
MX250
Network A
Network B
Network C
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?
Q2: What license(s) will they need to purchase?
Yes – MI is licensed per network
1x Extra Large (for Network A)
1x Medium (for Network B)

Licensing scenario
An org admin has configured a full VPN tunnel between
Network A and Network C of this organization.
MX105
MX250
Network B
Network C
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
MX450
Network A
No – MX’s do not provide MI information on VPN
traffic originating from non-licensed MX’s

Licensing scenario
MX105
MX450
MX250
Network A
Network B
Network C
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?
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?
1x Large license (for Network C)
No, because the MX250 requires at least a Large
license. If it was a Large or Extra Large license
purchased for the MX105 at start, then the answer
would be ‘yes’ (it can be transferred).

Smart Thresholds
Increasing the effectiveness of Web App Health in Meraki Insight
Auto-adjusting thresholds
Using machine-learned
behavioral patterns
Per app, per network
Assessing the performance of
apps on a per network basis
Branch A
Branch B
Branch C
Reduced false positive alerts
Alert based on expected behavior
of an app per site (true outages)

Be able to navigate the Dashboard to find and
interpret the metrics produced by Meraki
Insight and WAN Health
Lesson 12 review
Do you understand the purpose of Meraki
Insight and applicable scenarios?
Can you explain how Meraki Insight gathers data
and the various metrics it uses to analyze the
performance scores produced in Dashboard?
Be able to choose and accurately size
out the appropriate license options

Which TWO of the following statements about Meraki Insight WAN Health are typical use cases? (select 2)
A. For monitoring mission-critical LAN applications
B. When multiple MX devices have been deployed in the organization
C. For observing switch uplink traffic across an MPLS
D. When there are cellular (LTE) links configured as uplink failover options
At what percentage will Meraki Insight's Web App Health display a red performance indicator symbol for
underperforming LAN, WAN, or servers?
A. Less than or equal to 70%
B. Greater than 75%
C. Less than 80%
D. Greater than or equal to 85%

Preparing monitoring, logging,
and alerting services
Logging capabilities | Monitoring tools and services |
Supported alerts | API for flexibility
LESSON 13

Integrated and historical log databases
Tracks events occurring in a Network
(timestamps in local network time zone)
Who did it
What was changed
When was it done
Where (which device)
Tracks changes made in an Organization
(timestamps In UTC)
Who was affected
What happened
When it occurred
Where it took place
Retention: 2 years **
Retention: 3 months *
Both stored in Dashboard, not on Meraki devices, and have advanced filtering capabilities
Event log Change log
* 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

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@meraki.com as a trusted email source.

Exporting data through APIs
Scanning API Dashboard API
Example use cases:
… history of device associations
(who is accessing my network)
… logs of device probe requests
(who was nearby but not joined)
Example use cases:
… CDP/LLDP information
(what was plugged into my switches)
… list of administrators
(accounting for who existed and when)

Lesson 13 review
Understand Dashboard’s logging
capabilities and how they differ
Be able to setup and configure different
levels and types of alerts for various needs
Are you familiar with the various
monitoring tools and interfaces that
Dashboard provides?
Understand how to leverage APIs to export
and gain additional insights from historical
data that Dashboard has logged
API

What is an appropriate use case for leveraging the Scanning API?
A. Soliciting CDP/LLDP information from a switch port
B. Building a list of network administrators for a specific network
C. Logging wireless and Bluetooth device probe requests
D. Scanning and claiming license keys into an organization
Which of the following is a true statement about Meraki device and network alerts?
A. E-mailed network alerts will arrive from the source address: alerts-noreply@meraki.com
B. SMS, webhooks, and automated phone calls are all supported alert types
C. Default recipients for network alerts will include all organizational administrators
D. Individual device alerts can be also be configured through the Local Status Page

Setting up Dashboard’s reporting
and auditing capabilities
Reporting in Cisco Meraki |
Managing firmware through Dashboard |
Running a PCI audit
LESSON 14

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

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+

Who needs PCI DSS?
If you work in…
…if you take digital payments, you need to be compliant!
• Retail
• Hospitality
• Transportation
• Healthcare
• Food services
• Telecom
• Media/Entertainment
• Construction
• Finance
• Energy

PCI audit process
Online registration Gap analysis
Scans and
penetration tests
Offsite audit
Remediation
support
Remediation plan
Onsite validation
Draft report
on compliance
Report on
compliance
1 2 3
6 5 4
7 8 9

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
Summary Reports and interpret their
outputs to identify key metrics?
Understand the differences between
Meraki firmware versions and how to
strategically deploy them
Be able to compare, schedule, and plan
for staged firmware upgrades across
networks in Dashboard
Leverage Dashboard’s PCI reporting tool
to recommend proper actions to meet
PCI DSS compliance

Which of the following is a feature available on the Firmware Upgrades page?
A. Managing Dashboard account privileges to control and schedule firmware changes
B. Release notes for stable, release candidate, and beta firmware
C. Opting-in to Meraki-managed beta firmware upgrade cycles
D. Firmware trial option with automatic rollback after 24 hours
Which of the following is a true statement about the firmware rollback option?
A. Rollback always requires the authorization of Meraki Support before it can be performed
B. Rollback allows admins to return from a beta or RC to a stable firmware release
C. Rollback can be performed up to three months after an upgrade has completed
D. Rollback can be performed by network administrators

Troubleshooting: not an exact science
Unified view
Native logging
Wireless Health
Meraki Insight
VPN status page
Network topology
Meraki Dashboard
Business goals:
reduced time-to-fix & incident prevention
Classic approaches
Top-down
Bottom-up
Divide-and-conquer
Follow-the-path
Spot-the-differences
Move-the-problem

TOPIC
Native logging capabilities

Native vs. external logging
Event log
Change log
Syslog
SNMP

Native logging capabilities
Event log vs. change log
Event log Change log
Scope
Timestamps
Retention period
Can export via Syslog
Can export to .csv
Filtering capabilities
Network Organization
Local (Network-wide > General) UTC
3 months 2 years
Yes No
Yes Yes
Yes Yes

Threat logs: Security Center
Inspect malicious packet
Prevent threats from spreading
Drill-down
Monitor & identify
Determine origin
Allowlist false positives
Take action
Latest and most common threats
Retrospective detections
Block country

TOPIC
Wireless troubleshooting

An IT admin’s inbox…
“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”
1 new message

Meraki Health: network monitoring
100% 100%
EASY TO USE & UNDERSTAND
Quickly understand root cause even
when the underlying issue is known
RIGHT DATA AT THE RIGHT TIME
Having the right data and context
available is key to troubleshooting
EFFICIENT TROUBLESHOOTING
Finding issues takes time. The Meraki
Health now makes it easy to identify
problem areas
70%
75%

Smarter wireless troubleshooting
Successful wireless network access depends on several steps
1
Associate with an AP
2
Authenticate to the network
3
Obtain an IP address
4
Resolve hostnames

Being proactive
Can users access the wireless
network successfully?
Are connected users having a
good experience?
Are any AP’s overloaded or in
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
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
my.meraki.com
MX
MS
MR
?
Wired
View the communications sent to the
infrastructure upstream
Wireless
Examine the wireless communication
between the client and AP
?
Packet captures can be done on both wired and wireless interfaces

Slow data rates? Check the signal-to-noise ratio (SNR)
SNR
The difference in decibels between the received
signal and the background noise level (noise
floor).
Recommendation
20 dB or more for data networks
25 dB or more for voice applications
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
6514
HTTP/S Request
Meraki Insight monitors HTTPS traffic on TCP port 443; for HTTP, any port can be specified.
No synthetic probes required. Ensure TCP 6514 is open on any firewall upstream.
LAN WAN SERVER
Web App
User
HTTP/S Response

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:
Good: > 4 Moderate: 3.5 – 4 Bad: < 3.5
1 Is the link causing poor call quality?
If the link is not causing poor call quality, what/where is
the issue and who should I contact to fix the problem?
2
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.

Hop number Status IP address Domain MOS Loss Latency Jitter
1 ● 10.20.30.1
gw-276meraki-
dhcp.static.monkeybrains.n
et
4.0 5.00% 75 ms 6.4 ms
2 ● 38.88.216.117
be2681.ccr21.sfo01.stlas.co
gentco.com
4.1 2.00% 78 ms 3.5 ms
3 ● 208.76.187.13
cr1-200p-a-
be100.bb.spectrumnet.us
3.8 6.00% 88 ms 19 ms
4 ● 129.250.4.202 broadsoft-gw.ip4.gtt.net 1.7 23.00% 120 ms 4.8 ms
5 ● 199.59.65.228 cisco.sipflash.com 4.3 0.00% 120 ms 5.6 ms
Hop number Status IP address Domain MOS Loss Latency Jitter
1 ● 10.20.30.1
gw-276meraki-
dhcp.static.monkeybrains.n
et
4.0 5.00% 75 ms 6.4 ms
2 ● 38.88.216.117
be2681.ccr21.sfo01.stlas.co
gentco.com
4.1 2.00% 78 ms 3.5 ms
3 ● 208.76.187.13
cr1-200p-a-
be100.bb.spectrumnet.us
4.2 0.00% 33 ms 19 ms
4 ● 129.250.4.202 broadsoft-gw.ip4.gtt.net 4.0 3.00% 20 ms 1.8 ms
5 ● 199.59.65.228 cisco.sipflash.com 4.3 0.00% 40 ms 8.6 ms
Hop-by-hop analysis
1. Utilize the built-in traceroute tool to
find the root cause
2. Tool probes each hop along the path
between MX and VoIP server
3. MOS is calculated at each hop and
checked to see if it meets thresholds
4. Thresholds less than < 3.5 are marked
as ‘Bad’

TOPIC
Troubleshooting Meraki Auto VPN

Auto VPN: registration phase
Subnet Y
Subnets A, B, C
HQ Branch
Internet
Site IP Port Subnet(s)
HQ 1.1.1.1 50000 A, B, C
Branch 2.2.2.2 60000 Y
1.1.1.1 2.2.2.2
Registration Phase
VPN Registry
UDP 9350
VPN Registries (x2)

Auto VPN: connection phase
Subnet Y
Subnets A, B, C
HQ Branch
Internet
1.1.1.1 2.2.2.2
Connection Phase
Direct tunnel between peers (P2P)
UDP hole punching
VPN Registries (x2)
S: 50000
D: 60000
S: 60000
D: 50000

Auto VPN: what can go wrong?
Subnet Y
Subnets A, B, C
HQ Branch
1.1.1.1 2.2.2.2
Registration Phase
VPN Registries (x2)
VPN Registry: Disconnected.
Outbound UDP 9350 blocked
HQ 1.1.1.1 50000 A, B, C
Branch 2.2.2.2 60000 Y
Firewall
Internet

Subnet Y
Subnets A, B, C
HQ Branch
1.1.1.1 2.2.2.2
Registration Phase
VPN Registries (x2)
HQ 1.1.1.1 50000 A, B, C
HQ 1.1.1.1 54321 A, B, C
Branch 2.2.2.2 60000 Y
Load balancer
NAT type unfriendly
?
Internet

Subnet Y
Subnets A, B, C
HQ Branch
1.1.1.1 2.2.2.2
Connection Phase
VPN Registries (x2)
✕
Firewall
S: 50000
D: 60000
S: 60000
D: 50000
Branch
Internet

Subnet Y
Subnets A, B, C
HQ Branch
1.1.1.1 2.2.2.2
VPN Registries (x2)
HQ 1.1.1.1 50000 A, B, C
Branch 2.2.2.2 60000 Y
D: subnet Y ? Registration Phase
Internet
Disabled
Subnet Y
Name VPN mode

Auto VPN: what can go wrong and resolutions
WAN
LAN
✕
VPN Registry: Disconnected.
Outbound UDP 9350 blocked
192.168.1.5:44019 - > 203.0.113.57:9350
192.168.1.5:44019 - > 203.0.113.194:9350
192.51.100.23:56125 - >203.0.113.57:9350
192.51.100.23:56126 - >203.0.113.194:9350
NAT type unfriendly
VPN
✕
Disabled
Subnet Y
Name VPN mode

Local status page
Make local configuration changes, monitor device status/utilization, and perform local troubleshooting
Internet
connection is
NOT required
my.meraki.com
switch.meraki.com
MX
MS
MR
Note: my.meraki.com or setup.meraki.com will work for any Cisco Meraki device (MX, MS, MR) but will only access the first device in the path
Internet

Local status page: alternative access
If access via DNS doesn’t work, there are other ways
Internet
connection is
NOT required
my.meraki.com
MX
MS
MR
1.1.1.100 Internet
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?
Local status page disabled
my.meraki.com
✕
DNS traffic not through MX MX in Passthrough Mode

Lesson 15 review
Understand various troubleshooting
methods (on the Meraki platform)
Are you able to assess wireless failures
and network issues through the tools
available in the Dashboard?
Do you know how to monitor threats
via the Security Center and take
protective actions?
Understand the various forms of
troubleshooting with respect to Auto VPN
and the VPN Status page in Dashboard
Do you know how to access and fully
utilize the Local Status Page?
my.meraki.com

Which of the following is a supported method for accessing Dashboard's packet capture tool?
A. Navigating on the Dashboard to Organization > Packet Capture
B. Selecting a switch port and going to the "Troubleshooting" section
C. Configuring Wireshark integration with Dashboard to map to specific Meraki devices
D. Accessing the Packet Capture tab on the device's Local Status Page
Which of the following is NOT one of main benefits or uses of the Local Status page?
A. To make local configuration changes
B. Monitor device status and utilization
C. Perform device connectivity troubleshooting
D. Providing SSH access into the device
E. To run a speed test to check connectivity to the device from a client

ECMS2 Training Slides.pdf

More Related Content

What's hot (20)

Similar to ECMS2 Training Slides.pdf (20)

Recently uploaded (20)

ECMS2 Training Slides.pdf