Course contents

Unit 7: Cloud and hybrid WANLesson 7.4 (3 of 4 in this unit)16 of 25 in the Advanced Cisco SD-WAN course

Cloud OnRamp for IaaS and prerequisites

Extending the fabric into cloud networks: cloud router pairs, mapping cloud networks to VPNs, what the cloud account must allow, and what the automation does.

Advanced · 14 min read

You'll learn to describe what Cloud OnRamp for IaaS builds in a cloud account, list what the account must allow before it starts, and name the first things to check when a deployment fails.

Technical definition

Cloud OnRamp for IaaS is a Catalyst SD-WAN workflow that extends the fabric into public-cloud networks. SD-WAN Manager (vManage) uses the cloud provider's APIs to deploy a pair of virtual WAN Edge routers (cEdge/vEdge) and then maps cloud networks, such as AWS VPCs or Azure VNets, to SD-WAN service VPNs.

From a request for twelve VPCs to a working route table

The application team has twelve cloud networks that must be reachable from the branches. Building each by hand means tunnels, route tables and VPN mappings repeated twelve times, and each repetition is a chance to make a different mistake. Cloud OnRamp for IaaS turns this into one workflow. This lesson describes the pattern, what the automation owns, and what stays with you. The steps and screens differ between releases, so use this as a map and the configuration guide for your release as the detail.

What gets built

  1. A connection to the cloud account. Manager stores the account details and uses them to call the provider's APIs.
  2. A transit network. The workflow creates a network in the cloud to hold the routers, or attaches them to a transit service of the provider. The exact form depends on the workflow and cloud.
  3. A pair of cloud routers. Virtual WAN Edge instances launched from the marketplace image, for example Catalyst 8000V. They join the fabric like any WAN Edge: they authenticate with the controllers, form tunnels and exchange routes over OMP.
  4. Host network discovery. Manager lists the cloud networks it can see in the account, often by region, and you select which to include, sometimes by tag.
  5. VPN-to-network mapping. Each selected cloud network is mapped to an SD-WAN service VPN, for example a development VPC to VPN 10 (corporate) and a guest application network to VPN 30 (guest).
  6. Routes in both directions. The cloud routers advertise the cloud network prefixes into OMP, and the provider side is changed so traffic for branch prefixes goes to the cloud routers.

VPN numbers are lab examples. The mapping is the segmentation boundary: a cloud network mapped to VPN 30 is in the same routing domain as the guest VPN, and nothing in VPN 10 can reach it unless a policy or route leak allows it.

What Cloud OnRamp for IaaS builds in the cloud account
What Cloud OnRamp for IaaS builds in the cloud accountThe SD-WAN Manager uses the cloud account details to call the provider's APIs. It creates a transit network and a pair of cloud routers, which join the fabric like any WAN Edge. Selected cloud networks, such as 10.100.0.0/16, are mapped to service VPNs. The cloud routers advertise those prefixes into OMP, and BR-01 and HUB-01 reach the cloud networks through tunnels to the cloud routers.SD-WAN Manager10.255.0.10BR-0110.255.2.1Your cloud accountCloud router 1Cloud router 210.100.0.0/16mapped to VPN 10cloud provider APIs

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The VPN mapping is the segmentation boundary: a cloud network in VPN 30 cannot be reached from VPN 10 unless policy allows it. VPN numbers are lab examples.

What you can see after it works

A cloud network 10.100.0.0/16 is mapped to VPN 10. The cloud routers advertise it. From BR-01, the OMP table should show it reachable through both cloud routers. The system IPs below are lab examples, and the cloud routers take the same kind of system IP as any other device.

Example output written for this lesson, simplified; real output has more fields and a different layout
BR-01#show sdwan omp routes 10.100.0.0/16
VPN  PREFIX          FROM PEER    PATH ID  LABEL  STATUS  TLOC IP       COLOR         PREF
10   10.100.0.0/16   10.255.0.11  301      1002   C,I,R   10.255.3.1    biz-internet  -
10   10.100.0.0/16   10.255.0.11  302      1002   C,I,R   10.255.3.2    biz-internet  -
Two paths, one per cloud router (10.255.3.1 and 10.255.3.2 are made-up system IPs for this example), both resolved. If one line is missing, the first question is whether that cloud router is up and has tunnels. If both are missing, check that the cloud network is mapped to the right VPN and that its prefix is not filtered. Seeing the route at BR-01 proves the control plane. A ping from a branch host to a cloud host tests the rest, including cloud security rules.

What the cloud account has to allow

What the cloud account has to allow
What the cloud account has to allowRequirement; What goes wrong without it. Permission to create and change networking resources (networks, subnets, route tables, gateways, security rules) and instances: The workflow stops partway with an access error and may leave half-built resources Marketplace subscription to the router image, accepted for the account and region: The instance cannot launch SD-WAN licensing that covers the virtual routers: The routers launch but do not become usable fabric members. Check your licensing model Quota for instances of the chosen size and for public addresses: Launch fails with a limit error. New accounts often have low limits Manager can reach the provider's APIs: Every step fails the same way, from the very start The cloud routers can reach the controllers and the other fabric sites: The routers exist but do not join. Security rules or routes in the transit network block themRequirementWhat goes wrong without itPermission to create andchange networking resources(networks, subnets, routetables, gateways, securityrules) and instancesThe workflow stops partway with an access error and may leave half-builtresourcesMarketplace subscription tothe router image, acceptedfor the account and regionThe instance cannot launchSD-WAN licensing thatcovers the virtual routersThe routers launch but do not become usable fabric members. Check yourlicensing modelQuota for instances of thechosen size and for publicaddressesLaunch fails with a limit error. New accounts often have low limitsManager can reach theprovider's APIsEvery step fails the same way, from the very startThe cloud routers can reachthe controllers and theother fabric sitesThe routers exist but do not join. Security rules or routes in the transitnetwork block them

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.

Addressing, overlap and cost

Cloud networks are often created by different teams, and 10.0.0.0/16 or 172.16.0.0/16 can appear several times. Two cloud networks with the same prefix in one VPN cannot both be reached, because there is only one best route for the prefix. Fix the plan first. Renumbering a cloud network later usually means rebuilding what is inside it. Where overlap cannot be avoided, one option is to place the networks in separate VPNs, but a branch that needs both will then need a different solution, so decide this before building.

The pair of routers is a running cost, and so are the larger instance sizes that give more throughput. Data leaving a cloud network or crossing between zones and regions is usually charged. Pricing differs by provider and changes, so check the current price list before the design is agreed, not after the first bill.

What the automation builds and what you still own

What the automation builds and what you still own
What the automation builds and what you still ownAutomation builds and reports; You still own. Transit network and router instances: The cloud account, its permissions and its quotas Tunnels and OMP sessions of the cloud routers: Licences and marketplace subscriptions Mapping of cloud networks to VPNs: Choosing the mapping and the segmentation design Route changes it was asked to make: Address plan, overlaps and any policy between VPNs State shown in Manager: Security rules and cloud firewalls beyond those it creates Initial build: Day-two checks, upgrades, cost review and capacityAutomation builds andreportsYou still ownTransit network and routerinstancesThe cloud account, its permissions and its quotasTunnels and OMP sessions ofthe cloud routersLicences and marketplace subscriptionsMapping of cloud networksto VPNsChoosing the mapping and the segmentation designRoute changes it was askedto makeAddress plan, overlaps and any policy between VPNsState shown in ManagerSecurity rules and cloud firewalls beyond those it createsInitial buildDay-two checks, upgrades, cost review and capacity

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.
Why does a cloud security rule break the tunnels when the routers look fine?

The routers are instances inside the provider's network, and the provider filters traffic to and from them with its own security rules. SD-WAN tunnels use UDP on specific ports, and an inbound rule that does not allow them leaves the tunnel down while the instance reports healthy. Manager shows the routers running, because that is true. The fabric view shows the missing tunnels. Compare the two views before blaming either side.

When a deployment fails: order of checks

  1. Permissions. Read the error. Access or authorisation messages point at the account permissions.
  2. Quota. Limit messages for instances, addresses or networks point at the account limits for that region.
  3. Image and licence. Look for a marketplace or licensing error, and check the subscription in the region used.
  4. Overlapping prefixes. If routers are up but a network is unreachable, compare prefixes across all sites and cloud networks.
  5. Security rules. If routers are up but tunnels are not, check inbound and outbound rules and routes in the transit network.
  6. Mapping. If the tunnels are up but a network is missing from OMP, check the VPN mapping and any filter.

Test yourself on cloud router deployments

Predict · scenario 1

A Cloud OnRamp for IaaS deployment stops with an error that the router instance could not be launched. The account is new. Which cause fits best?

Predict · scenario 2

Both cloud routers show as running in the cloud console, but BR-01 sees no routes for 10.100.0.0/16 and no tunnels to the cloud routers. What do you check first?

Predict · scenario 3

Two VPCs, both 10.100.0.0/16, are mapped to VPN 10 by different teams. What is the problem?

Predict · scenario 4

Why does the workflow deploy a pair of cloud routers instead of one?

FAQ

Why does the workflow deploy two cloud routers?
For redundancy. With a pair, the loss of one instance, or of its availability zone, leaves the other carrying traffic. A single router would be a single point of failure for every cloud network behind it. Whether the pair shares or splits the load depends on the design and release.
Which cloud router image does it use?
A virtual WAN Edge image from the provider's marketplace. The Catalyst 8000V is an example of such a router. Which images and sizes are supported differs by release and by provider, so read the current support list before you plan instance types.
Is there only one Cloud OnRamp for IaaS workflow?
No. Older and newer workflows exist side by side across releases, and the newer multicloud workflow covers some of the same ground. Look at what your Manager offers and read the guide for that release instead of relying on a description from another one.