Explore Cisco
How to Buy

Have an account?

  •   Personalized content
  •   Your products and support

Need an account?

Create an account

Cisco SD-WAN CloudOps

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco SD-WAN CloudOps

Chapter Title

Provisioning

Results

Updated:
July 28, 2022

Chapter: Provisioning

Provisioning

Getting Access to Cloud Hosted Controllers

Cisco managed Cloud Hosted controllers are by default closed for management access. Cisco does not allow access to 0.0.0.0/0 to the Cloud Hosted SD-WAN controllers for security reasons. It is expected that you have specific public IP prefixes within your enterprise VPN that you access from and hence only those will be allowed to be opened for access. You can restrict access by requesting to allow only https and ssh to be on the allowed list, for your given source IP prefixes. By default, Cisco marks all the customer provided source IP prefixes to be allowed access for all destination ports and protocols.

The cloud hosted controllers have a private IP on their interfaces. Each of the private IPs has a 1:1 NAT to a public IP on the cloud. These IPs do not change irrespective of whether the interface is configured itself with static IP or DHCP. The IPs only change when the instance is recovered or replaced.

The allowed-list is applied to all the network interfaces of all the controllers, that have public IP addresses. To update or view the allowed-list applied to your cloud-hosted controller set, open a case with Cisco TAC.

To add, delete, or modify cloud security group allowed-list, use one of the following options:

  • You can login into the Cisco Self Service Portal at https://ssp.sdwan.cisco.com and manage the access-list. You need to be the Cisco PNP Smart Account Admin for the Smart Account where the overlay controller profile is based.

  • You can open a Cisco TAC support case and provide the following information:

    • Overlay/VA name

    • Cisco vManage IP/FQDN

    • Prefixes/Rules (vManage GUI access) that need to be added, deleted, or modified in the allowed-list.

    • IP address

    • Specify whether to mark an IP address as allowed for all traffic or selected traffic (for example https, SSH, and so on).

For the Cisco SD-WAN Self-Service Portal, Cisco has granted the right to access the Cisco SD-WAN Self-Service Portal to the Smart Account administrator. A Smart Account administrator can now view and perform operational tasks related to a customer's hosted controller infrastructure, such as viewing the controllers’ IP addresses and modifying the controllers' IP access lists. If you do not wish for certain users to receive such access, go to the Manage Smart Account section of Cisco Software Central, and remove those users as Smart Account administrators, or use the IDP (identity provider) onboarding feature to grant access to the Cisco SD-WAN Self-Service Portal based on the trusted users in the IDP.

Cloud Hosted Controller IP Provisioning

The Cisco vManage fully qualified domain names (FQDN) are mapped to the VPN 512 public IP and is used for management access. The edge nodes, however, form a tunnel with the transport interface of the Cisco vManage, which is on VPN 0 and has a different public IP address. Cisco assigns FQDN to Cisco vManage and Cisco vBond Orchestrator for cloud hosting.

HTTP access is not available for Cisco vBond Orchestrator, and only Cisco vManage has web server and access to web/https.

Each controller instance has a private IP interface that is NATed to a public IP 1:1. In general, public and private IP addresses will not change for the instance interfaces. Private/Public IPs of Cisco vBond Orchestrator/Cisco vSmart Controller/Cisco vManage changes only when an instance needs to be replaced or moved to a new region.

All edges communicate with the controllers via the DTLS/TLS ports, therefore you may open your firewall to any IP for these DTLS/TLS ports, or just the current public IPs of the cloud controllers. For more information on DTLS/TLS ports, refer to Table 3 in Ports Used by Cisco SD-WAN Devices Running Multiple vCPUs section.

Custom IP Prefixes for Cloud Hosted Controllers

There are certain use-cases, where you may need custom network prefix-based IPs on the cloud controller interfaces for management access and control. For example,

  • To access the management VPN 512 of Cisco vManage and Cisco vBond Orchestrator or Cisco vSmart Controller devices over Cisco SD-WAN tunnel with AAA or TACACS based authentication.

  • To send syslog from Cisco vManage over VPN 512 to a syslog server over Cisco SD-WAN tunnel.

Figure 1. AAA TACAS

By default, the Cisco-managed cloud hosted controllers are deployed with 10.0.0.0/16 based subnets, including the VPN 512 subnet. If you add the cloud Cisco SD-WAN and bring the VPN 512 subnet as a reachable subnet within your fabric, it might conflict with an existing subnet.

In such cases, you need to share a /24 prefix for each of the two regions of deployment of controllers. These IP prefixes are used to create the controllers, and the subnets are then configured to be available within the Cisco SD-WAN fabric.

Request for Cloud vEdges for AAA/TACACs purpose post overlay provisioning:

Open a case for CloudOps at TAC-CSOne with the following details:

  1. To request AAA or TACACs enablement, you need to provide IP prefixes, unused within your existing fabric, that you can use to create the controllers (original controllers are shutdown, snapshotted, and cloned back).

    Each region in which the controllers are set up has one /24 SDWAN fabric wise unique custom subnet. Each overlay has two regions, so we need two subnets. They must be a private address space.

    Refer to Internet Assigned Numbers Authority (IANA) for IPv4 special purpose addresses.

  2. Admin credentials to the Cisco vBond Orchestrator, Cisco vSmart Controller and Cisco vManage devices.

  3. You can schedule eight-hour maintenance window after the preapproval and prechecks completed by CloudOps engineer.

  4. Enable DNS for Cisco vBond Orchestrator and configure all the controllers prior to start of the process.

  5. Ensure that GR is set to default of 12 hours or more on Cisco SD-WAN or Cisco vSmart Controller devices.

  6. Reserve two available Cloud Cisco SD-WAN UUIDs through PNP and attach to Cisco vManage.

  7. Supported only for Single Tenant Single Node Cisco vManage overlays for provisioned controllers, and all new to-be-provisioned controller sets. This feature isn't supported for Cisco vManage cluster overlay and MT Cisco vManage nodes.

  8. It is recommended that Cisco vManage have templates attached to Cisco vBond Orchestrator, Cisco vSmart Controller, and if existing cloud Cisco SD-WAN devices from Cisco.

Configuration of Cloud vEdges Post Cisco Provisioning

  1. Once Cisco CloudOps has completed the provisioning of the cloud vEdges next to the cloud hosted controllers, CloudOps shares the public & private IP assignments for each cloud vEdge to the customer. They are in the format (VPN 512, VPN 0, VPN X).

    Cisco CloudOps will share the credentials for the newly provisioned cloud vEdges.

  2. The cloud vEdges have their VPN 512 & VPN X interfaces in the same subnet as the VPN 512 of the controllers in that region.

    The cloud vEdges provisioned by the Cisco CloudOps are specifically for the AAA/TACACS purpose and always created in the above network layout format.

    If there are any reachability issues to the cloud vedge, the issue generally lies with the interface IP or route configurations in the cloud vEdge.

  3. Also, note that the public & private IPs are 1:1 NAT'd and assigned to the cloud vEdge interfaces. The vEdge interface itself may be configured with dhcp, but it will always get the same IP from Cloud.

    For VPN X interfaces, you will need to configure the static IP, exactly as the one shared by Cisco CloudOps.

    Random IPs within the subnet cannot be used.

  4. The cloud vEdges are subject to the same Inbound allowed access-list as the controllers, as they are provisioned in the same unique environment per overlay.

    You must login via SSH to the vEdge public IPs and the credentials provided.

  5. You must now configure the new cloud vEdges with the necessary configurations. For example, site-id, system IP, organization name, vBond DNS or IP, and so on.

  6. If you are using Enterprise root-ca, then you must upload and install the same on the cloud vEdges as well.

  7. You may configure AAA/TACACS on the Cisco vManage with auth-fallback to local with local having the viptelatac/ciscotacro/ciscotacrw user enabled. This allows Cisco support to login and troubleshoot issues when required.

  8. You would need to acquire an unused cloud vEdge UUID from the device list of the Cisco vManage, one per cloud vEdge provisioned.

    If you don't have any cloud vEdge UUID available in the WAN Edge Device list on your Cisco vManage, then you may need to login into the Cisco PNP portal, on the overlay's associated Smart Account & Virtual Account, and Add Software Devices (VEDGE-CLOUD-DNA) and then Sync Smart Account on the Cisco vManage.

  9. You must then activate the UUID on the cloud vEdges to allow them to be authenticated by the Cisco vManage and join the Cisco SD-WAN fabric.

  10. You must configure the controllers' (Cisco vManage, Cisco vBond Orchestrator, Cisco vSmart Controller) vpn 512 with a specific static route for customer's Enterprise subnets (from customers admin team intend to access the controllers for management) to point to the cloud vEdge's VPN X static IP.

  11. For an overlay hosted by Cisco on Azure, please open a Cisco TAC case and provide the specific enterprise subnet prefixes, from where the connectivity to the vpn 512 of the controllers is required.

    The Azure subnet default gateway is the defacto gateway even if you configure the vEdge service VPN IP to be the gateway for your enterprise subnets. Hence in addition to your configuration on vpn 512 on the controllers, there is additional configuration needed on the Azure side. Cisco will help apply an Azure Route Table(RT) entry for each of the necessary Enterprise subnets and also enable IP forwarding on the cloud vEdge interfaces.

Was this Document Helpful?

FeedbackFeedback

Contact Cisco