For further details on setting up your private instance of UCMC please refer to UCM Cloud Help.
This document helps qualified Cisco UCM Cloud partners who have completed integration to the UCM Cloud platform. Partners can establish processes and procedures to onboard customers to the UCM Cloud platform.
Use the document and supporting material to:
· Understand customer onboarding phases
· Understand Cisco and partner responsibilities
· Turn up service for a fully integrated customer private instance
The audience for this document is product managers, operations personnel, support organizations, sales specialists and partner/customer success organizations.
UCMC Customer Onboarding Phases
Activation of a private instance in UCM Cloud for the customer occurs in three distinct phases. Cisco and the partner have varied responsibilities during different stages of customer onboarding. It’s expected that the partner is fully integrated into UCM Cloud prior to onboarding a customer.
Before customer onboarding can start, the partner must complete peering and integration with Cisco UCM Cloud. This includes onboarding to the customer support process. For further details, refer to Cisco UCM Cloud Partner Onboarding Guide.
This table provides a high-level plan of required activities for successful onboarding and activation of a customer onto Cisco UCM Cloud.
Table 1: High-Level Plan
1 Cisco Commerce Workspace Annuity Platform
UCMC Reference Architectures
Figure 1. Example of Meraki SD-WAN Deployment for a Cisco HCS Customer with MPLS on Headquarters
Figure 2. Example of Meraki SD-WAN Deployment for a Cisco HCS Customer without MPLS on Headquarters
For further details on setting up your private instance of UCMC please refer to UCM Cloud Help.
Meraki vMX Setup
The rest of this document is a walkthrough for setting up a virtual MX (vMX) appliance in your Meraki dashboard for deployment in to Cisco's UCM Cloud (UCMC) platform. After completing these steps outlined in this document, you will have a virtual MX appliance running in UCMC that serves as an AutoVPN termination point to your physical MX devices.
Currently, vMX on UCMC supports a one-armed concentrator configuration with split-tunnel hub and spoke VPN architecture. For more info on how to deploy a one-armed concentrator, please refer to this document.
Before deploying a virtual MX, it is important to understand several key concepts.
All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, click here.
In this mode, the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the only supported configuration for MX appliances serving as VPN termination points into AWS.
NAT Mode Concentrator
In this mode, the MX is configured with a single Ethernet connection to the upstream network and one Ethernet connection to the downstream network. VPN traffic is received and sent on the WAN interfaces connecting the MX to the upstream network and the decrypted, un-encapsulated traffic is sent and received on the LAN interface that connects the MX to the downstream network.
Note: This is not supported for virtual MX VPN concentrators operating within UCMC as we rely on BGP peering from the vMX to the UCMC datacenter for routing to your UCMC hosted call manager platform.
There are several options available for the structure of the VPN deployment.
In this configuration, branches will only send traffic across the VPN if it is destined for a specific subnet that is being advertised by another MX in the same Dashboard organization. The remaining traffic will be checked against other available routes, such as static LAN routes and third-party VPN routes, and if not matched will be NATed and sent out the branch MX unencrypted.
Note: This is the recommended and supported tunneling mechanism to reach UCMC as only VOIP and call-setup traffic should route to UCMC. All other internet bound traffic should not route to UCMC.
In full tunnel mode all traffic that the branch or remote office does not have another route to is sent to a VPN hub.
Note: This is not supported for virtual MX VPN concentrators operating within UCMC.
During the setup of your vMX instance, or over the course of working within UCMC, you may encounter additional terminology which is not defined in this document. To find out more about these terms, and for additional details on the terms listed above, please refer to the UCMC documentation here.
Meraki Dashboard Configuration
Begin by creating a new Security Appliance network in your organization. This guide will walk you through creating a new network in the Meraki Dashboard.
The Meraki Dashboard will require a vMX license to be added before you are able to continue. If you do not have access to a vMX license, please reach out to your Meraki Reseller or Sales Rep.
Once you have created the network and added the appropriate license you will be able to deploy a new vMX to your network by clicking on the respective 'Add vMX' button as seen below. The "add vMX" button will deploy a vMX100 node (not supported in UCMC) and the remaining buttons will deploy a vMX node of the type specified. The below buttons (or a subset thereof) will only show up if vMX licenses of that type are added/available in the org:
After you add the new vMX to your network, navigate to Security Appliance > Appliance status and select “Generate Authentication Token” to generate the token needed by the UCMC team in order to instantiate a vMX VM for this node.
Copy the newly generated token and provide it to the UCMC team when requested.
The authentication token must be provided to the UCMC team and the vMX instance instantiated within 1 hour of generating it. If it has been more than 1 hour then a new token must be generated.
Next, follow the steps outlined in this guide to configure the vMX as a one-armed concentrator.
On the Site-to-Site VPN page, add the BGP config provided by UCMC in order to peer your vMX with the UCM cloud and receive the routes to your UCM Cloud infrastructure.
The most common problem people face when deploying a vMX is getting it provisioned and online in their Meraki dashboard in the first place. New troubleshooting/diagnosis messages have been added to the vMX console screen now so you can identify what went wrong during the provisioning process.
When the vMX boots it will execute the following steps during its initial provisioning process:
- Connect to Network
- Obtain user-data (vMX auth token)
- Authenticate with dashboard (using auth token)
- Connect to Dashboard
Connect to Network
When a vMX first connects to a network it will do so via DHCP unless a static IP config is provided in the user-data. Once a vMX connects to dashboard (step 4 above) then a static IP can be applied through dashboard just as it can with any Meraki product.
NOTE: NFVIS is the only platform that currently supports static network configuration via user-data for the initial vMX provisioning process (pre-dashboard checkin). Public cloud environments such as AWS, Azure, GCP and Alicloud rely on DHCP from their VPC.
Please see the cloud-init section above for providing static IP information via user-data. If static network addressing is provided via the Day0 config, it will be displayed on the vMX console as well as seen below.
The following errors will be displayed on the vMX console if incorrect network configuration is provided.
Invalid IP Address
Invalid Subnet Mask
Invalid Default Gateway
Obtain User-Data & Authenticate to Dashboard
Once a vMX has successfully connected to a network, it will then attempt to obtain its user-data (vMX auth token). There are different user-data mechanisms in each platform that the vMX currently runs on to provide the token to the vMX. In AWS, Azure, GCP and Alicloud there are user-data fields in the VM config where this can be provided. In CSP we use the Day0 Config mechanism to get this token to the vMX.
NOTE: Unlike the network config above, the token is not displayed on the console for security and usability reasons (the token is a very long string that is meaningless to anyone looking at it). If you see a token value on the console it means that the token was not provided in the format "token <token>" (note that token should be lowercase).
vMX auth tokens have a lifetime of only 1 hour for security purposes. If you see the following message on your vMX console it means the token you provided is no longer valid. Please generate a new one in dashboard, update the Day0 config and restart your vMX. The vMX will attempt to authenticate against dashboard with the provided token 3 times. After 3 failures, the provisioning process stops and the "provisioning failed" message is displayed.
If the token provided is incorrect in any way the "invalid token" message is displayed on the console.
Unable to reach Meraki Dashboard
If the vMX is unable to reach dashboard on TCP port 7734 then the initial provisoning phase will fail and an "Unable to reach Meraki Dashboard" message will be displayed on the console. Please refer to this document on the correct ports/IP's that need to be opened for Meraki Dashboard communication.
No Add vMX Button
When navigating to Security & SD-WAN > Appliance Status, if there is no "Add vMX" button please ensure the following two conditions are met:
- You have available vMX licenses in your license pool
- Your organization license status is not expiring in <30 days (yellow warning at the top of the Organization > License Info page)
Please note that Meraki Support does not troubleshoot UCMC specific firewall rules and deployments.