Documentation Digest: July 29 - Sep 13

[CameronMoody]

Hi Community,

Below are the most important changes to our documentation between July 29 - September 13, 2019:

Week of August 5-9 

Band Steering Overview - Note on RF Profiles

Change: Added link to Enabling Band Steering via RF Profiles.

MAC Enrollment - APNS Needed

Change: Updated KB to notify readers to have APNS prior to macOS enrollment.

The Cisco Meraki Dashboard API - api.meraki.cn

Change: Added a note to use api.meraki.cn for China host.

Meraki Auto VPN

Change: New article

SSID Tunneling and Layer 3 Roaming

Change: Removed mentions of VM concentrators.

SNMP Overview and Configuration

Change: Added note that SNMP traps use SHA1 for authentication and AES for privacy.

OSPF VPN Concentrator

Change: Added a link to "Using OSPF to Advertise Remote VPN Subnets" in the OSPF section.

Week of August 12-16

SNMP Overview and Configuration

Change: Corrected security piece mentioning that SNMP polling uses SHA1 & DES.  SNMP traps use SHA1 & AES

VPN Concentrator Deployment Guide

Change: Added link for “Using OSPF to Advertise Remote VPN subnets”.  Updated with new hub-hub and spoke-spoke NFOs.

Configuring SAML SSO with Azure AD

Change: New article

Wired Sentry Enrollment for MS

Change: Added a note explaining that sentry enrollment is available for MS switches, but is only compatible with MacOS devices, not Windows or other.

Facebook Login (Chinese)

Change: New article

MS220 EOL

Change: Updated replacement switch to be MS120, not the MS225.

Resetting Cisco Meraki Devices to Factory Defaults - MV

Change: Added MV

Week of August 19-23

Motion Alerts

Change: Rewrote to include info about motion sensitivity and areas of interest.

Change: Added note - "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."

SM - Enrolling Devices

Change: Added clarification for supported Windows 10 editions: "Profile installation is only supported on Windows 10 Pro."

Floor Plan Geoalignment

Location Analytics

Change: Added section explaining floor plan geolocation data and how to geoalign existing floor plans.

MX Routing Behavior

Change: Expanded Non-Meraki VPN section to include configuration with overlapping networks.

MX Warm Spare (VRRP) Overview

Change: Added note - "Warm spare switches cannot be stacked or have OSPF enabled."

Creating and Applying Group Policies

Change: When a group policy is applied to a VLAN, that policy becomes the new "network default" for any other group policies applied to clients in that VLAN.

Staged Upgrades for Meraki Switches

Change: Updated FAQ to note that individual stack members cannot be upgraded using this feature.

Meraki Insight Introduction

Change: New article, splitting previously existing Web App Health article into an MI intro, and Web App Health details.

Hostname Visibility

Change: Updated "Enabling Hostname Visibility" instructions to reflect differences between combined and uncombined networks

MX Layer 2 Functionality

Change: New article

Week of August 26-29

Switch Cloning

Change: Adjusted switch cloning steps.

Meraki Reference Architecture - Small Office Business

Change: New article

Week of September 2-6

Extending the LAN with a Wireless Mesh Link

Change: Refined verbiage around supported topologies

Switch ACL Operation

Change: Listed examples of unsupported inputs

Band Steering Overview

Change: New article

Week of September 9-13

Meraki and Cisco Cloud Calling Connected Branch Solution

Change: New article  

[Nash]

The refined wording on "Extending the LAN with a Wireless Mesh Link" is pretty darn good. Thanks for doing that! The old article led to some confusion in my office, a time or two.

[PhilipDAth]

Configuring SAML SSO with Azure AD

Change: New article

Do you *really* have to "Generate SHA-1 certificate"?  We should not be using SHA-1 for anything new.  We should be encouraging everyone to use SHA256 - minimum.

Wired Sentry Enrollment for MS

Change: Added a note explaining that sentry enrollment is available for MS switches, but is only compatible with MacOS devices, not Windows or other.

I have had support cases open about this - and no one has ever mentioned that it only works on Macs.  Good to know I guess.

MX Layer 2 Functionality

Change: New article

Good article.

Meraki Reference Architecture - Small Office Business

Change: New article

Good article.

Great work overall!

[PhilipDAth]

This existing page seems to have become broken.

https://documentation.meraki.com/MR/MR_Splash_Page/Changing_the_Language_on_a_Splash_Page 

It is linked to on this page:

https://documentation.meraki.com/MR/MR_Splash_Page/Customizing_the_Splash_page#Changing_Language 

[jdsilva]

Meraki Auto VPN

Change: New article

Oh wow, I never realized this didn't have its own article before, but I'm super glad to see it now!

Couple things though:

Using the latest version of Chrome this image is blank.

Under the "Auto VPN Configuraiton Details" section this sentence hurts my head:

"If the MX is configured as a Hub, it will build a full mesh of VPN tunnels to all other MXs in the Auto VPN domain that are configured as hubs and point-to-point tunnels to all MXs in the Auto VPN domain that have this MX configured as a hub.  "

Please consider rewriting that. Also, all tunnels, even the full mesh, are point to point.

And lastly, please please please document what the current encryption cipher is on the AutoVPN tunnels. I know there's no phase one, but phase two encryption really should be documented in this article. 

[jdsilva]

Site-to-Site VPN Settings - IKEv2 & FQDN

Change: In MX15, aggressive mode is no longer supported. If User FQDN needs to be configured, IKEv2 needs to be enabled in addition to the user FQDN NFO.

I don't see these changes. Am I missing something?

[CameronMoody]

---

@jdsilva wrote:

Site-to-Site VPN Settings - IKEv2 & FQDN

Change: In MX15, aggressive mode is no longer supported. If User FQDN needs to be configured, IKEv2 needs to be enabled in addition to the user FQDN NFO.

I don't see these changes. Am I missing something?

---

That one was a mistake, and wasn't changed. Apologies. Removed from my post.

[CameronMoody]

Oh wow, I never realized this didn't have its own article before, but I'm super glad to see it now!

Yes, me too.

Using the latest version of Chrome this image is blank.

Thank you, fixed that.

Under the "Auto VPN Configuraiton Details" section this sentence hurts my head:

I agree, that was a bit awkward. Try this new version instead:

"If the MX is configured as a Hub, it will build VPN tunnels to all other Hub MXs in the Auto VPN domain (in the same same dashboard organization). It will also build VPN tunnels to all Spoke MXs in the Auto VPN domain that have this MX configured as a hub. If all MXs in the Auto VPN domain are configured as Hub then the Auto VPN has a full mesh topology."

And lastly, please please please document what the current encryption cipher is on the AutoVPN tunnels.

It's a 128-bit AES cipher. I added that it's an AES cipher to the "How Auto VPN Works" section under #3, it's in the image that you mentioned was grayed out, and it's in the "Auto VPN vs Non-Meraki Site-to-Site VPN" section.

I am personally always negotiating with our internal teams to find a balance of detail we can share, and I appreciate the feedback around why this information is helpful. I understand why missing those details is frustrating, and I'm always pushing for more.

[jdsilva]

"If the MX is configured as a Hub, it will build VPN tunnels to all other Hub MXs in the Auto VPN domain (in the same same dashboard organization). It will also build VPN tunnels to all Spoke MXs in the Auto VPN domain that have this MX configured as a hub. If all MXs in the Auto VPN domain are configured as Hub then the Auto VPN has a full mesh topology."

That reads a lot better!

It's a 128-bit AES cipher. I added that it's an AES cipher to the "How Auto VPN Works" section under #3, it's in the image that you mentioned was grayed out, and it's in the "Auto VPN vs Non-Meraki Site-to-Site VPN" section.

I am personally always negotiating with our internal teams to find a balance of detail we can share, and I appreciate the feedback around why this information is helpful. I understand why missing those details is frustrating, and I'm always pushing for more.

This is good, but I would suggest that it states AES128 plainly. We see this question every now and then here in the community, and it's still a requirement for audit purposes for many organizations to be able to state what level of encryption is being used on their IPesc tunnels. I totally get the way Meraki operates and how you control what information you share, but in my mind this sort of thing should be stated clearly, and plainly for all to see. It's not part of any secret sauce.

Thanks @CameronMoody. Great work here!

[CameronMoody]

---

@PhilipDAth wrote:

This existing page seems to have become broken.

https://documentation.meraki.com/MR/MR_Splash_Page/Changing_the_Language_on_a_Splash_Page 

It is linked to on this page:

https://documentation.meraki.com/MR/MR_Splash_Page/Customizing_the_Splash_page#Changing_Language 

---

My mistake, moved the content to a new page and missed that link. Thank you @PhilipDAth 

[CameronMoody]

---

Meraki Reference Architecture - Small Office Business

Change: New article

---

This is the first in a series of detailed reference architectures that we'll be releasing, which are intended to be used as a baseline for generating ideas about deployment planning.

I'd love feedback on what is or isn't useful on this article, or what sort of environments would be most useful to see documented. We plan on releasing a Branch site reference architecture next, followed by many others of various sizes and types (if they're useful!).