Skip to main content
Cisco SD-WAN
Support
Product Documentation
Viptela Documentation

Configuring Cloud OnRamp for IaaS

Cloud OnRamp for IaaS extends the fabric of the Viptela overlay network into public cloud instances, allowing branches with vEdge routers to connect directly to public-cloud application providers. By eliminating the need for a physical data center, Cloud OnRamp for IaaS improves the performance of SaaS applications.

The connection between the overlay network and a public-cloud application is provided by two redundant vEdge Cloud routers, which act together as a transit between the overlay network and the application. Using two routers to form the transit offers path resiliency to the public cloud. In addition, having redundant routers assists in brownout protection to improve the availability of public-cloud applications. Together, the two routers can remediate link degradation that might occur during brownouts.

Cloud OnRamp for IaaS discovers any already existing private cloud instances in geographical cloud regions and allows you to select which of them to make available for the overlay network. In such a brownfield scenario, Cloud OnRamp for IaaS allows simple integration between legacy public-cloud connections and the Viptela overlay network.

You configure and manage Cloud OnRamp for IaaS through the vManage NMS server. A configuration wizard in the vManage NMS automates the bring-up the transit to a your public cloud account and automates the connections between public-cloud applications and the users of those applications at branches in the overlay network.

Cloud OnRamp for IaaS works in conjunction with AWS virtual private clouds (VPCs) and Azure virtual networks (VNets).

Cloud OnRamp Configuration Overview

To configure Cloud OnRamp for IaaS for AWS, you create AWS transit VPCs, each of which consists of a pair of vEdge routers. You then map the transit VPCs to host VPCs that already exist in the AWS cloud.

  • Transit VPCs provide the connection between the Viptela overlay network and the cloud-based applications running on host VPCs. Each transit VPC consists of two vEdge Cloud virtualized routers that reside in their own VPC. Two routers are used to provide redundancy for the connection between the overlay network and cloud-based applications. On each of these two vEdge Cloud routers, the transport VPN (VPN 0) connects to a branch vEdge router, and the service-side VPNs (any VPN except for VPN 0 and VPN 512) connect to applications and application providers in the public cloud.
  • Host VPCs are virtual private clouds in which your cloud-based applications reside. When a transit VPC connects to an application or application provider, it is simply connecting to a host VPC.

Similarly, to configure Cloud OnRamp for IaaS for Azure, you create Azure transit VNets, each of which consists of a pair of vEdge routers. You then map the host vNets to transit VNets that already exist in the Azure cloud. All VNets reside in the same resource group.

  • Transit VNets provide the connection between the Viptela overlay network and the cloud-based applications running on host VNet. Each transit VNet consists of two vEdge Cloud virtualized routers that reside in their own VNet. Two routers are used to provide redundancy for the connection between the overlay network and cloud-based applications. On each of these two vEdge Cloud routers, the transport VPN (VPN 0) connects to a branch vEdge router, and the service-side VPNs (any VPN except for VPN 0 and VPN 512) connect to applications and application providers in the public cloud.
  • Host VNets are virtual private clouds in which your cloud-based applications reside. When a transit VNet connects to an application or application provider, it is simply connecting to a host VNet.

In the Cloud OnRamp configuration process, you map one or more host VPCs or host VNets to a single transit VPC or transit VNet. In doing this, you are configuring the cloud-based applications that branch users are able to access.

The mapping process establishes IPsec and BGP connections between the transit VPC or transit VNet and each host VPC or host VNet. The IPsec tunnel that connects the transit and host VPC or VNet runs IKE to provide security for the connection. For AWS, the IPsec tunnel runs IKE Version 1. For Azure, the IPsec tunnel runs IKE version 2. The BGP connection that is established over the secure IPsec tunnel allows the transit and host VPC or VNet to exchange routes so that the transit VPC or VNet can direct traffic from the branch to the proper host VPC or VNet, and hence to the proper cloud-based application.

During the mapping process, the IPsec tunnels and BGP peering sessions are configured and established automatically. After you establish the mappings, you can view the IPsec and BGP configurations, in the VPN Interface IPsec and BGP feature configuration templates, respectively, and you can modify them as necessary.

vManage NMS Prerequisites

Before you can configure Cloud OnRamp for IaaS, you must properly provision the vManage NMS.

  • Make sure that your vManage server has access to the internet and that it has a DNS server configured so that it can reach AWS. To configure a DNS server, in the vManage VPN feature configuration template, enter the IP address of a DNS server, and then reattach the configuration template to the vManage server.
  • Ensure that two vEdge Cloud routers that are to be used to bring up the Cloud OnRamp for IaaS have been added to the vManage NMS and have been attached to the appropriate configuration template. (These two routers are deployed in AWS in their own VPC, and together they form the transit VPC, which is the bridge between the Viptela overlay network and AWS cloud applications.) Ensure that the configuration for these two routers includes the following:
    • Hostname
    • IP address of vBond orchestrator
    • Site ID
    • Organization name
    • Tunnel interface configuration on the eth1 interface
  • Ensure that the vManage NMS is synchronized to the current time. To check the current time, click the Help (?) icon in the top bar of any vManage screen. The Timestamp field shows the current time. If the time is not correct, configure the vManage server’s time to point to an NTP time server, such as the Google NTP server. To do this, in the vManage NTP feature configuration template, enter the hostname of an NTP server, and then reattach the configuration template to the vManage server. The Google NTP servers are time.google.com, time2.google.com, time3.google.com, and time4.google.com.

AWS Prerequisites

Before you can configure Cloud OnRamp for IaaS, you must properly provision AWS.

  • Ensure that you have subscribed to the Viptela marketplace Amazon machine images (AMIs) in your AWS account. See Subscribe to Viptela AMIs.
  • Ensure that at least one user who has administrative privileges has the AWS API keys for your AWS account. For Cloud OnRamp for IaaS, these keys are used to authenticate the vManage server with AWS and to bring up the VPC and Elastic Compute Cloud (EC2) instances.
  • Check the AWS limits associated with your account (in the Trusted Advisor section of AWS) to ensure that the following resources can be created in your account:
    • 1 VPC, which is required for creating the transit VPC
    • 6 Elastic IP addresses associated with the transit vEdge Cloud routers
    • 1 AWS virtual transit (VGW) for each host VPC
    • 4 VPN connections for mapping each host VPC
  • C3 and C4 compute-intensive families are supported for the vEdge Cloud Routers.

Subscribe to Viptela AMIs

To use the Cloud OnRamp for IaaS and other Viptela services, you must subscribe to the Viptela vEdge router AMI in AWS. In the subscription process, you launch a vEdge Cloud Router AMI instance, you generate a key pair to use for the instance, and finally you use the key pair to subscribe to the vEdge Cloud router instance.

You subscribe to the vEdge Cloud router AMI only once, when you first create a Viptela AMI instance.

To create a new AMI subscription and generate a key pair:

  1. In AWS, do a search to locate the Viptela vEdge Cloud Router AMI.
  2. Select and launch an EC2 instance with the vEdge AMI instance. For more information, see Create vEdge Cloud VM Instance on AWS.
  3. To generate the key pair, in Step 12 in the section Set Up the vEdge Cloud VM Instance, select Create a new key pair.
  4. Click Download Key Pair. The key pair is then downloaded to your local computer as a .pem file.
  5. Click Launch Instance. A failure message is displayed, because you now need to upload the key pair to complete the subscription process.

To upload the key pair:

  1. In AWS Marketplace, http://aws.amazon.com/marketplace, search for the Viptela vEdge Cloud router AMI.
  2. Click the Continue button.
  3. Click Key Pair to spin up a vEdge Cloud router instance. In the option to enter the key pair, upload the .pem file from your local computer. This is the file that you generated in Step 4, above.

Azure Prerequisites

Before you can configure Cloud OnRamp for IaaS, you must properly provision Azure.

  • Ensure that you have accepted the terms and conditions for the Cisco Cloud vEdge Router in the Azure Marketplace. See Accept the Azure Terms of Service.
  • Ensure that you create an App Registration in Azure and retrieve the credentials for your Azure account. For Cloud OnRamp for IaaS, these credentials are used to authenticate the vManage server with Azure and bring up the VNet and the Virtual Machine instances. See Create and Retrieve Azure Credentials.
  • Check the Azure limits associated with your account (by going to your subscription in the portal and checking Usage + Quotas) to ensure that the following resources can be created in your account:
    • 1 VNet, which is required for creating the transit VNet
    • 1 Availability set, required for Virtual Machine distribution in the transit VNet
    • 6 Static Public IP addresses associated with the transit vEdge Cloud routers
    • 1 Azure Virtual Network Transit and 2 Static Public IP Addresses for each host VNet
    • 4 VPN connections for mapping each host VNet
  • F-series VMs (F4 and F8) are supported for the vEdge cloud routers.

Accept the Azure Terms of Service

To use the Cisco vEdge Cloud Router as part of the Cloud OnRamp workflow, you must accept marketplace terms for using a virtual machine (VM). You can do this in one of the following ways:

  • Spin up the vEdge Cloud router on the portal manually, and accept the terms as part of the final page of the bringup wizard.
  • In the Azure APIs or Powershell/Cloud Shell, use the Set-AzureRmMarketplaceTerms command.

Create and Retrieve Azure Credentials

To create and retrieve Azure credentials, you must create an App Registration in Azure with Contributor privileges:

  1. Launch the Microsoft Azure portal.
  2. Create an application ID:
    1. In the left pane of the Azure portal, click Azure Active Directory.
    2. In the sub-menu, click App registrations.
    3. Click New application registration. The system displays the Create screen.

      appName.png
    4. In the Name field, enter a descriptive name such as CloudOnRampApp.
    5. In the Application Type field,
    6. In the Sign-on URL field, enter any valid sign-on URL; this URL is not used in Cloud OnRamp.
    7. Click Create. The system displays a summary screen with the Application ID.

      appSummary.png
  3. Create a secret key for the Cloud OnRamp application:
    1. In the summary screen, click Settings in the upper-left corner.
    2. In the right pane, click Keys. The system displays the Keys > Passwords screen.

      generateSecretKey.png
    3. In the Passwords screen:
      1. In the Description column, enter a description for your secret key.
      2. In the Expires column, from the Duration drop-down, select the duration for your secret key.
      3. Click Save in the upper-left corner of the screen. The system displays the secret key in the Value column but then hides it permanently, so be sure to copy and save the password in a separate location.
  4. In the left pane of the Azure portal, click Subscriptions to view the subscription ID. If you have multiple subscriptions, copy and save the subscription ID which you are planning to use for configuring the Cloud OnRamp application.
  5. View the Tenant ID:
    1. In the left pane of the Azure portal, click Azure Active Directory.
    2. Click Properties. The system displays the directory ID which is equivalent to the tenant ID.
  6. Assign Contributor privileges to the application:
    1. In the left pane of the Azure portal, click Subscriptions.
    2. Click on the subscription you will be using for the Cloud OnRamp application.
    3. In the subscription pane, navigate to Access Control (IAM).
    4. Click Add. The system displays the Add Permissions screen.

      addPermissions.png
    5. From the Role drop-down menu, select Contributor.
    6. From the Assign Access To drop-down, select the default value Azure AD user, group, or application.
    7. From the Select drop-down, select the application you just created for Cloud OnRamp.
    8. Click Save.

You can now log into the Cloud OnRamp application with the Azure credentials you just created and saved.

Configure Cloud OnRamp for IaaS for AWS

To configure Cloud OnRamp for IaaS for AWS, you configure cloud instances using a configuration wizard. Follow the steps below, which are illustrated by this video. (Note that the video has no sound.)

  1. In vManage NMS, select the Configuration ► Cloud OnRamp screen.
  2. Click Add New Cloud Instance.
  3. In the Add Cloud Instance–Log In to a Cloud Server popup:
    1. In the Cloud drop-down, select the cloud type to be AWS.
    2. Click IAM Role or Key to log in to the cloud server. It is recommended that you use IAM Role.
    3. If you select IAM Role:
      1. In the Role ARN field, enter the role ARN of the IAM role.
      2. In the External ID field, enter external ID created for the role ARN. It is recommended that the external ID include 10 to 20 characters in random order.
        To authenticate to the vManage NMS using an IAM role, vManage NMS must be hosted by Viptela on AWS and have the following attributes:
        • Trusts the AWS account, 200235630647, that hosts the vManage NMS.
        • Have all permissions for EC2 and VPC resources.
        • A  default timeout of at least one hour.
        If vManage NMS is not hosted by Viptela on AWS, assign an IAM role with permissions to AssumeRole to the vManage server running the Cloud OnRamp process. Refer to the AWS documentation for details.
    4. If you select Key:
      1. In the API Key field, enter your Amazon API key.
      2. In the Secret Key field, enter the password associated with the API key.
  4. Click Login to log in to the cloud server.
    The cloud instance configuration wizard opens. This wizard consists of three screens that you use to select a region and discover hosts VPCs, add transit VPC, and map host VPCs to transit VPCs.
    A graphic on the right side of each wizard screen illustrates the steps in the cloud instance configuration process. Steps not yet completed are shown in light gray. The current step is highlighted within a blue box. Completed steps are indicated with a green checkmark and are shown in light orange.
  5. Select a region and discover host VPCs:
    1. In the Choose Region drop-down, select a geographical region.
    2. Click Discover Host VPCs. A list of host VPCs discovered in that region is displayed.
    3. Select the desired VPCs.
    4. Click Next.
  6. Add a transit VPC:
    1. In the Transit VPC Name field, type a name for the transit VPC. The name can be up to 128 characters and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.
    2. Under Device Information, enter information about the transit VPC:
      1. In the vEdge Version drop-down, select the Viptela software version to run on the VPC transit.
      2. In the Size of Transit vEdge drop-down, select how much memory and how many CPUs to create on the VPC transit.
      3. In the Device 1 drop-down, select the serial number to use.
      4. In the Device 2 drop-down, select the serial number to use.
      5. Click Advanced if you wish to enter more specific configuration options:
        1. In the Transit VPC Subnet field, enter a custom CIDR that has a network mask in the range of 16 to 25. If you choose to leave this field empty, the Transit VPC is created with a default CIDR of 10.0.0.0/16.
        2. In the SSH PEM Key drop-down, select a PEM key pair to log in to an instance.
          Note that the key pairs are region-specific. Refer to the AWS documentation for instructions on creating key pairs.
        3. Click Save and Finish to create the transit VPC. Or click Proceed to Mapping to continue with the wizard.
    3. Click Next.
  7. Map the host VPCs to transit VPCs:
    1. In the table of host VPCs, select the desired host VPCs.
    2. Click Map VPCs. The Map Host VPCs popup opens.
    3. In the Transit VPC drop-down, select the transit VPC to map to the host VPCs.
    4. In the VPN drop-down, select the VPN in the overlay network in which to place the mapping.
    5. Click Map VPCs.
    6. Click Save and Complete.

When you configure the two vEdge Cloud routers that form the transit VPC, in the VPN feature configuration template for VPN 0, ensure that the color you assign to the tunnel interface is a public color, not a private color. Public colors are 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, public-internet, red, and silver.

Configure Cloud OnRamp for IaaS for Azure

To configure Cloud OnRamp for IaaS for Azure, you configure cloud instances using a configuration wizard:

Create a Cloud Instance

  1. In vManage NMS, select the Configuration ► Cloud onRamp screen.
  2. Click Add New Cloud Instance:

    G00525.png
  3. In the Add Cloud Instance–Log In to a Cloud Server popup:
    1. In the Cloud drop-down, select the cloud type to be Azure.
    2. To give vManage programmatic access to your Azure Subscription, log in to the cloud server:
      1. In the Subscription ID field, enter the ID of the Azure subscription you want to use as part of the Cloud OnRamp workflow.
      2. In the Client ID field, enter the ID of an existing application or create a new application in Azure. To create a new application, go to your Azure Active Directory ► App Registrations ► New Application Registration.
      3. In the Tenant ID field, enter the ID of your Azure account. To find the tenant ID, go to your Azure Active Directory and click Properties.
      4. In the Secret Key field, enter the password associated with the client ID.
  4. Click Log In.
    The cloud instance configuration wizard opens. This wizard consists of three screens that you use to select a location and discover host VNets, add transit VNet, and map host VNets to transit VNets.
    A graphic on the right side of each wizard screen illustrates the steps in the cloud instance configuration process. Steps not yet completed are shown in light gray. The current step is highlighted within a blue box. Completed steps are indicated with a green checkmark and are shown in light orange.

    G00479.png
  5. Select a location and discover host VNets:
    1. In the Choose Location drop-down, select a geographical location.
    2. Click Discover Host VNets. A list of host VNets discovered in that location is displayed.
    3. Select the desired VNet.
    4. Click Next.
  6. Add a transit VNet:
    1. In the Transit VNet Name field, type a name for the transit VNet. The name can be up to 32 characters and can contain only uppercase and lowercase letters, the digits 0 through 9, hyphens (–), and underscores (_). It cannot contain spaces or any other characters.
    2. Under Device Information, enter information about the transit VNet:
      1. In the WAN Edge Version drop-down, select the Viptela software version to run on the VNet transit. The drop-down lists the published versions of the Viptela software in the Azure marketplace.
      2. In the Size of Transit VNet drop-down, select how much memory and how many CPUs to create on the VNet transit.
      3. In the Device 1 drop-down, select the serial number to use.
      4. In the Device 2 drop-down, select the serial number to use.
      5. Click Advanced if you wish to enter more specific configuration options.
      6. In the Transit VPC Subnet field, enter a custom CIDR that has a network mask in the range of 16 to 25. If you choose to leave this field empty, the Transit VPC is created with a default CIDR of 10.0.0.0/16.
    3. Click Next.
  7. Map the host VNets to transit VNets:
    1. In the table of host VNets, select the desired host VNet.
    2. Click Map VNets. The Map Host VNets popup opens.
    3. In the Transit VNet drop-down, select the transit VNet to map to the host VNets.
    4. In the VPN drop-down, select the VPN in the overlay network in which to place the mapping.
    5. In the IPSec Tunnel CIDR section, enter two pairs of interface IP addresses for each vEdge Cloud router to configure IPSec tunnels to reach the Azure virtual network transit. The IP addresses must be network addresses in the /30 subnet, be unique across the overlay network, and not be a part of the host VNet CIDR. If they are part of the host VNet CIDR, Azure will return an error while attempting to create VPN connections to the transit VNet.
    6. In the Azure Information section:
      1. In the BGP ASN field, enter the ASN that will be configured on the Azure Virtual Network Transit that is spun up within the host VNet. Use an ASN that is not part of an existing configuration on Azure. For acceptable ASN values, refer to Azure documentation.
      2. In the Host VNet Gateway Subnet field, enter a host VNet subnet in which the Virtual Network Gateway can reside. It is recommended you use a /28 subnet or higher. You must not provide a subnet that is already created in the VNet.
    7. Click Map VNets.
    8. Click Save and Complete.

When you configure the two vEdge Cloud routers that form the transit VNet, ensure that the color you assign to the tunnel interface in the VPN feature configuration template for VPN 0, is a public color, not a private color. Public colors are 3g, biz-internet, blue, bronze, custom1, custom2, custom3, default, gold, green, lte, metro-ethernet, mpls, public-internet, red, and silver.

Troubleshoot Cloud OnRamp for IaaS

This section describes how to troubleshoot common problems with Cloud OnRamp for IaaS.

Two vEdge Routers Not Available

Problem Statement

In vManage NMS, when you select the Configuration ► Cloud OnRamp screen and click Add New Cloud instance, you see an error message indicating that two vEdge routers are not available.

Resolve the Problem

The vManage NMS does not have two vEdge Cloud routers that are running licensed Viptela software. Contact your operations team so that they can create the necessary vEdge Cloud routers.

If the vEdge routers are present and the error message persists, the two vEdge Cloud routers are not attached to configuration templates. Attach these templates in the vManage Configuration ► Templates ► Device screen. Select the vEdge Cloud router, and then select Attach Devices from the More Actions icon to the right of the row.

Required Permissions for API

Problem Statement

When you enter your API keys, you get an error message indicating that this user does not the the required permissions.

Resolve the Problem

Ensure that the vManage server can reach the internet and has a DNS server configured so that it can reach AWS or Azure. To configure a DNS server, in the vManage VPN feature configuration template, enter the IP address of a DNS server, and then reattach the configuration template to the vManage server.

For AWS, check the API keys belonging to your AWS account. If you think you have the wrong keys, generate another pair of keys.

For AWS, f you are entering the correct keys and the error message persists, the keys do not have the required permissions. Check the user permissions associated with the key. Give the user the necessary permissions to create and edit VPCs and EC2 instances.

If the error message persists, check the time of the vManage server to ensure that it is set to the current time. If it is not, configure the vManage server’s time to point to the Google NTP server. In the vManage NTP feature configuration template, enter a hostname of time.google.com, time2.google.com, time3.google.com, or time4.google.com. Then reattach the configuration template to the vManage server.

No vEdge Software Versions Appear in the Drop-Down

Problem Statement

When you are trying to configure transit VPC parameters for the transit VPC, no vEdge Cloud software versions are listed in the drop-down.

Resolve the Problem

Ensure that your customer account has subscribed to the Viptela vEdge Cloud routers.

Ensure that the vEdge Cloud router is running software Release 17.2.0 or later.

No VPNs Appear in Drop-Down

Problem Statement

When you select the host VPCs or VNets to map, no VPNs are listed in the drop-down.

Resolve the Problem

This problem occurs when the device configuration template attached to the vEdge Cloud router includes no service-side VPNs. Service-side VPNs (VPNs other than VPN 0 and VPN 512) are required to configure the IPsec connection between the two vEdge Cloud routers selected for the transit and host VPCs or VNets.

This problem can also occur if the two vEdge Cloud routers selected for the transit VPC or VNet have no overlapping service-side VPNs. Because the two vEdges routers form and active–active pair, the same service-side VPNs must be configured on both of them.

To configure service-side VPNs, in the vManage VPN feature configuration template, configure at least one service-side VPN. Ensure that at least one of the service-side VPNs is the same on both routers. Then reattach the configuration template to the routers.

Cloud OnRamp Task Fails

Problem Statement

After you have completed mapping the host VPCs to the transit VPCs, or host VNets to transit VNets, the Cloud OnRamp tasks fails.

Resolve the Problem

Review the displayed task information that is displayed on the screen to determine why the task failed. If the errors are related to AWS or Azure esources, ensure that all required resources are in place.

Cloud OnRamp Task Succeeds, But Routers Are Down

Problem Statement

The Cloud OnRamp task was successful, but the vEdge Cloud routers are still in the Down state.

Resolve the Problem

Check the configuration templates:

  • Check that all portions of the vEdge Cloud router configuration, including policies, are valid and correct. If the configuration are invalid, they are not applied to the router, so the router never comes up.
  • Check that the configuration for the vBond orchestrator is correct. If the DNS name or IP address configured of the vBond orchestrator is wrong, the vEdge router is unable to reach it and hence is unable to join the overlay network.

After you have determined what the configuration issues are:

  1. Delete the Cloud OnRamp components:
    1. Unmap the host VPNs and the transit VPCs or VNets.
    2. Delete the transit vEdge routers.
  2. Edit the configuration templates and reattach them to the vEdge Cloud routers.
  3. Repeat the Cloud OnRamp configuration process.

Desired Routes Not Exchanged

Problem Statement

The Cloud OnRamp configuration workflow is successful, the Cloud vEdge routers are up and running, but the desired routes are not getting exchanged.

Resolve the Problem

In vManage NMS, check the BGP configuration on the transit vEdge Cloud routers. During the mapping process when you configure Cloud OnRamp for IaaS, BGP is configured to advertise the network 0.0.0.0/0. Make sure that the service-side VPN contains an IP route that points to 0.0.0.0/0. If necessary, add a static route in the VPN feature configuration template, and then reattach the configuration to the two vEdge Cloud routers that you selected for the transit VPC or VNet.

On AWS, go to the host VPC and check its route table. In the route table, click the option “Enable route propagation” to ensure that the VPC receives the routes.

End-to-End Ping Is Unsuccessful

Problem Statement

Routing is working properly, but an end-to-end ping is not working.

Resolve the Problem

On AWS, check the security group rules of the host VPC. The security group rules must allow the source IP address range subnets of the on-premises or branch-side devices, to allow traffic from the branch to reach AWS.

  • Was this article helpful?