Cisco SD-WAN Cloud OnRamp for Colocation Solution

Find all the information you need about this release—new features, known behavior, resolved and open bugs, and related information.


Explore Content Hub, the all new portal that offers an enhanced product documentation experience. Content Hub offers the following features to personalize your content experience.

  • Faceted Search to help you find content that is most relevant

  • Customized PDFs

  • Contextual Recommendations

About Cisco SD-WAN Cloud OnRamp for Colocation Solution

Cisco SD-WAN Cloud OnRamp for Colocation solution is a flexible architecture that securely connects to enterprise applications that are hosted in the enterprise data center, public cloud, private or hybrid cloud to an enterprise’s endpoints such as, employees, devices, customers, or partners. This functionality is achieved by using Cloud Services Platform 5000 series(CSP 5444) as the base Network Function Virtualization (NFV) platform that securely connects enterprise's endpoints to applications. By deploying Cisco SD-WAN Cloud OnRamp for Colocation solution in colocation centers, customers can virtualize network services and other applications, and consolidate them into a single platform.

The components of Cisco SD-WAN Cloud OnRamp for Colocation solution are:

  • Cisco Cloud Services Platform (CSP) 5444—CSP is an x86 Linux hardware platform that runs NFVIS software. It is used as the compute platform for hosting the virtual network functions in the Cisco SD-WAN Cloud OnRamp for Colocation solution.The whole solution can scale horizontally. You can have up to eight CSP devices. Depending on the load requirement, you can have anywhere from two to eight compute platforms in a cluster.

  • Cisco Network Function Virtualization Infrastructure Software (NFVIS)—The Cisco NFVIS software is used as the base virtualization infrastructure software running on the x86 compute platform.

  • Virtual Network Functions (VNFs)—The Cisco SD-WAN Cloud OnRamp for Colocationb solution supports both Cisco-developed and third-party virtual network functions.

  • Network Fabric—Forwards traffic between the VNFs in a service chain by using a L2 and VLAN-based lookup.

  • Mangament Network—A separate management network connects the NFVIS software running on the CSP systems, the virtual network functions, and the switches in the fabric. This management network is also used for transferring files and images into and out of the systems. The Out of Band (OOB) management switch configures the management network.

  • VNF Network Connectivity— A VNF can be connected to the physical network by using either Single Root IO Virtualization (SR-IOV) or through a software virtual switch. A VNF can have one or more virtual network interfaces (vNICs), which can be directly or indirectly connected to the physical network interfaces. A physical network interface can be connected to a software virtual switch and one or more VNFs can share the virtual switch. The Cisco SD-WAN Cloud OnRamp for Colocation solution manages the creation of virtual switch instances and the virtual NIC membership to create connectivity.

  • Service Chains—In Cisco SD-WAN Cloud OnRamp for Colocation solution deployment, the traffic between the VNFs (with SR-IOV) running on the CSP 5444 systems is service chained externally through Catalyst 9500.

  • Cisco Colo Manager (CCM)—This component is a software stack that manages a colocation. In this solution, CCM is hosted on NFVIS software in a docker container. A single CCM instance per cluster is brought up in one of the CSPs after activating a cluster.

  • Orchestration through vManage—The Cisco vManage is used for orchestrating theCisco SD-WAN Cloud OnRamp for Colocation solution.

Essentially, you can purchase the devices, add them in colocation centers, power them, cable them and devices automatically boot up, bootstrap themselves and get managed by vManage. You can go ahead with designing service chains, building security policies and application policies, thereby influencing the network traffic.

Software Version Matrix

Software Matrix

The following are the NFVIS, vManage, vBond, vSmart, vEdge, Catalyst 9500 versions.













Catalyst 9500



For Cisco SD-WAN Cloud OnRamp for Colocation solution deployment, ensure that you use the vEdge version, 19.1. The vManage version can be greater than or equal to the vBond version, and the vBond version can be greater than or equal to the vSmart version.

New Features

  • Supported VNFs: The following are the supported Cisco and third-party VNFs for this release.


    You must procure license for the required VNFs. Optionally, you can choose to bring in your own Day-0 configuration and repackage the VNFs, if required.

    Table 1. Validated Cisco VNFs



    Cisco CSR1000v

    16.9.1, 16.10.1, 16.11.1a

    Cisco ASAv

    9.9.2, 9.10.1

    Cisco FTDv

    6.2.3, 6.3.0

    Cisco vEdge Cloud

    18.4, 19.1

    Table 2. Validated Third-party VNFs



    Palo Alto Firewall (PAFW)

    8.0.5, 8.1.3, 9.0.0

    Fortinet Firewall


    AVI Load Balancer


  • Custom VNF Packaging: Provides the capability to create a custom VNF package along with image properties and bootstrap files into a TAR archive file. The VNFs are packaged by using the vManage user interface according to NFVIS VNF package format. You can create a VNF package once and then deploy multiple service chains and service groups across clusters. You can also tokenize custom variables and apply system variables that you pass with the bootstrap configuration files during deployment.

  • NFVIS and CSP software management from vManage: You can upgrade a CSP device by uploading NFVIS upgraded image in vManage repository. Also, you can easily view the upgrade status in the CSP device and choose to delete an NFVIS software image if the image version is not active.


    The upgrade of CSP device is supported from NFVIS versions, 3.11.x–3.12.x.

  • CCM upgrade from CSP or NFVIS: Provision to upgrade Cisco Colo Manager (CCM) from CSP through NFVIS CLI is available. When performing a CCM upgrade, ensure that those CSP devices are not managed by vManage. Perform the following steps when performing a CCM upgrade:

    1. To make a device unmanaged by vManage, clear the installed certificates on the device.

    2. Copy the upgrade package into NFVIS.

    3. Cofigure the NFVIS upgrade package.

    4. Apply the upgraded package.


    CCM upgrade functionality is useful when CCM only upgrade is required due to potential big fix after GA. To minimize service chain impact, the CCM upgrade can only be done on one CSP that hosts CCM.

  • Custom Service Chain: You have the flexibility to create a customized VNF sequence apart from the predefined sequence of service chains. You can add any VNFs such as, router, load balancer, firewall, and others that you can deploy within a cluster from vManage.

  • Serviceability Enhancements: Provides the following serviceability enhancements.

    • Fixed misleading information when hosting CCM.

    • Availability of incorrect speed and duplex interface information.

    • Availability of management IP address of each VM that has been assigned by vManage.

    • Availability of improved and readable messages for failures, if any.

Open Bugs

About the Cisco Bug Search Tool

Use the Cisco Bug Search Tool to access open and resolved bugs for a release.

The tool allows you to search for a specific bug ID, or for all bugs specific to a product and a release.

You can filter the search results by last modified date, bug status (open, resolved), severity, rating, and support cases.

Open vManage Bugs

All open vManage bugs for this release are available in the Cisco Bug Search Tool through the Open Bug Search.

Bug ID


CSCvn32064 vManage is losing the notification on switch down event from CCM.


Modifying resource pool in an activated cluster is not disabled.


VNF appears Active when CSP is not reachable (no control connections).


Resource got exhausted when attaching service chain failure.


HA network fix with right VLAN.


vManage interface path is still using CLOUDDOCK instead of COLOCATION


Service Chain template push validation fails with the error, "Push Feature Template Configuration" operation is already in progress.


When attaching few service chains, the "Template push failure - {vnf-1-ha-net}/trunk (value "false"): Access mode supports 1 vlan tag only" error is displayed.


Memory utils page does not display, "No data to display".


Page scroll issue


vManage does not push CCM configuration after a CSP device is powered on or a CSP device reboots.


The cluster credentials does not get saved on the first click.


vManage user interface does not draw correctly if the side tab is expanded.


vManage user interface changes management subnet gateway to first IP address in pool after it is changed to


No Error or Information message is prompted for over subscription scenario.


ENH vManage–Custom service chain does not allow removing a VNF while editing.


Platform information is missing in audit log message when uploading or deleting images from repository.


Modifying a cluster name and saving the settings throws an exception.


The detach cluster option is updated to attach cluster option even though Configure button is not clicked.


SWIM–Remote-Server, Remote-Server vManage radio buttons under Upgrade tab for CSP devices in Software upgrade.


PAFW UUID is missing in Day-0 configuration.

Open Device Bugs

All open device bugs for this release are available in the Cisco Bug Search Tool through the Open Bug Search.

Bug ID


CSCvp31683 RMA of CSP-5444 hosting CCM might cause stale configuration left in the switches.


The factory-reset all command fails with an application error.


Catalyst 9k CDB has not been updated with later-joined interfaces of switch, after initial single switch SVL booting.


Some subsystems keep restarting when service groups are attached and detached.


vEdge intermittenlty fails to come up with Day-0 configuration, and interface comes up as DHCP.


Reachability issue for Day-0 configuration of Fortinet VPN mode with two static gateways.


Spoofed packets detected on MAC address change for ASAv subinterface.


CSR VNF spin-off stays in 'booting' state or VM_INERT_STATE and enters into recovery (reboot).


Attaching or detaching service groups fails due to "configuration database is locked by session".


CSP device reboots with an error, nginx not running.


An error, "[3.11.1-18 - 3028] vManage report failure for Outstanding changes in database" is displayed.

Related Documentation