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

Configuring Cloud onRamp Service

Cloud onRamp service for IaaS and SaaS 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, the Cloud onRamp service 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 gateway between the overlay network and the application. Using two routers to form the gateway 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 service 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 service allows simple integration between legacy public-cloud connections and the Viptela overlay network.

You configure and manage Cloud onRamp service through the vManage NMS server. A configuration wizard in the vManage NMS automates the bring-up the gateway 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.

The Cloud onRamp service works in conjunction with AWS virtual private clouds (VPCs).

Cloud onRamp Configuration Overview

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

Gateway VPCs provide the connection between the Viptela overlay network and the cloud-based applications running on host VPCs. Each gateway 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 gateway VPC connects to an application or application provider, it is simply connecting to a host VPC.

In the Cloud onRamp configuration process, you map one or more host VPCs to a single gateway VPC. 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 gateway VPC and each host VPC. The IPsec tunnel that connects the gateway VPC and host VPC runs IKE Version 1 to provide security for the connection. The BGP connection that is established over the secure IPsec tunnel allows the gateway VPC and host VPC to exchange routes so that the gateway VPC can direct traffic from the branch to the proper host VPC, 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.

Prerequisites for Using Cloud onRamp Service

Before you can configure the Cloud onRamp Service, you must properly provision the vManage NMS and AWS.

vManage NMS Prerequisites

  • 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 service 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 gateway 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

  • Ensure that you have subscribed to the Viptela marketplace Amazon machine images (AMIs) in your AWS account, as described below.
  • Ensure that at least one user who has administrative privileges has the AWS API keys for your AWS account. For Cloud onRamp service, 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 gateway VPC
    • 6 Elastic IP addresses associated with the gateway vEdge Cloud routers
    • 1 AWS virtual gateway (VGW) for each host VPC
    • 4 VPN connections for mapping each host VPC

Subscribe to Viptela AMIs

To use the Cloud onRamp service 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.

Configure Cloud onRamp Service

To configure Cloud onRamp service, 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, enter the information to log in to the cloud server:
    1. In the Cloud drop-down, select the cloud type. Currently, this can be only AWS.
    2. In the API Key field, enter your Amazon API key.
    3. In the Secret Key field, enter the password associated with the API key.
  4. Click Log In.
    The cloud instance configuration wizard opens. This wizard consists of three screens that you use to configure regions, hosts VPNs, and gateway VPCs, and to map host and gateway VPCs to each other.
    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 gateway VPC:
    1. In the Gateway VPC Name field, type a name for the gateway 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 gateway VPC:
      1. In the vEdge Version drop-down, select the Viptela software version to run on the VPC gateway.
      2. In the Size of Gateway VPC drop-down, select how much memory and how many CPUs to create on the VPC gateway.
      3. In the Device 1 drop-down, select the serial number to use FOR WHAT?
      4. In the Device 2 drop-down, select the serial number to use FOR WHAT?
    3. Click Next.
  7. Map the host VPCs to gateway 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 Gateway VPC drop-down, select the gateway VPN 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.

Troubleshoot Cloud onRamp Service

This section describes how to troubleshoot common problems with Cloud onRamp service.

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. 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.

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

If 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 gateway 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.

Also ensure that the vEdge Cloud is running software Release 17.2.0 or later.

No VPNs Appear in Drop-Down

Problem Statement

When you select the host VPCs 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 gateway VPC and the host VPC.

This problem can also occur if the two vEdge Cloud routers selected for the gateway VPC 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 gateway VPCs, 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 resources, ensure that all required AWS 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 gateway VPCs.
    2. Delete the gateway 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 service, 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 templates, and then reattach the configuration to the two vEdge Cloud routers that you selected for the gateway VPC.

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?