This year has been quite significant for Cisco's multicloud networking software evolution. Earlier in the year Cisco introduced, along with other exciting feature announcements, Google Cloud Platform (GCP) support for Cisco Cloud Network Controller (CNC), formerly known as Cisco Cloud APIC. This blog series covers the GCP support capabilities divided into three parts:

• Part 1: Native Cloud Networking Automation
• Part 2: Contract-based Routing and Firewall Rules Automation
• Part 3: External Cloud Connectivity Automation

More about the rebranding and other expanded capabilities on our Modernize your Multi-Cloud Network with Cisco Cloud Network Controller blog. For brevity, Cisco CNC will be used throughout the series.

The Need for Multicloud Networking Software

While organizations are increasingly becoming more mature with theirto the cloudstrategies, lately there has been a shift in focus toin the cloudnetworking, as also observed by Gartner in their first Market Guide for Cloud Networking Software and subsequent releases. This series will show how a cloud-like policy model can help addressing inside the cloud challenges with the aim to keep improving operations in public cloud environments and augmenting native cloud networking capabilities, as needed.

High Level Architecture

Google Cloud resources are organized hierarchically, and the Project level is the most relevant from the Cisco CNC perspective as a tenant is mapped one-to-one to a GCP project. Cisco CNC is deployed from the Google Cloud Marketplace into a dedicated infra VPC (Virtual Private Cloud) contained within a project mapped to the infra tenant, while user VPCs are provisioned in dedicated or shared projects associated to their own tenants within the Cisco CNC.

The Cisco CNC architecture on GCP is similar to that of AWS and Azure, as it also supports BGP IPv4 or BGP EVPN to on-premises or other cloud sites using Cisco Cloud Router (CCR) based on Cisco Catalyst 8000v. It also supports native GCP Cloud Router with Cloud VPN gateway for external connectivity. As for internal cloud connectivity, it leverages VPC Network Peering between user VPCs within the same or across regions as illustrated on the diagram below.

Native Cloud Networking Automation

A brief overview of the Cisco CNC GUI before proceeding. The left side of the GUI contains the navigation pane which can be expanded for visualization of cloud resources or configuration. The application management tab is where one can go to make configurations, or alternatively, use the blue intent icon at the top right which provides easy access to various configuration options.

To demonstrate how Cisco CNC automates inter-region routing across VPCs, let's build a simple scenario with two VPCs in different regions contained within the same user-tenant project called engineering. Note that the same scenario could exist with these two VPCs in the same region, as VPC networks in GCP are global resources and not associated to any region, unlike subnets which are regional resources.

Provisioning VPC Networks and Regional Subnets

The first step is to create a Tenant and map it to a GCP Project as depicted below. The access type is set to Managed Identity, which allows Cisco CNC to make changes to user-tenant projects by means of a pre-provisioned service account during the initial deployment.

The configuration below illustrates the creation of two Cloud Context Profiles used as a mapping tool for a VPC. It is contained within a Tenant and provides the region association to determine which region(s) a VPC gets deployed to, along with regional subnets. Additionally, a Cloud Context Profile is always associated to a logical VRF.

By creating these two profiles and mapping to VPCs in different regions, each with their respective CIDR and subnet(s), the Cisco CNC translates them into native constructs in the Google Cloud console under VPC networks as seen below. Note that the VRF name defines the name of the VPC, in this example, network-a and network-b.

Cisco CNC GUI provides the same level of visibility, under Application Management where additional VPCs can be created or under Cloud Resources.

Route Leaking Between VPCs

For this scenario, a route leak policy is configured to allow inter-VRF routing which is done independently of contract-based routing or security policies to be reviewed in part 2 of this blog series. As seen previously, the VRF association to a particular VPC is done within the Cloud Context Profile.

While the "Add Reverse Leak Route" option is not depicted for brevity, it is also enabled to allow for bi-directional connectivity. In this scenario, since it is only inter-VPC route leaking, VRFs are labeled as internal and all routes are leaked.

In the GCP console, it automates VPC network peering between network-a and network-b with proper imported and exported routes.

Peering routes are auto generated for both VPCs, along with default routes automated during VPC setup.

Summary

This is a simple scenario with only two VPCs as to introduce Cisco CNC capabilities in automating cloud networking within GCP. It goes from provisioning VPCs to setting up route advertisements, automating peering, and providing visibility and control over what is being deployed.

Cisco CNC can automate other scenarios and use cases in just a few clicks. Those can be single VPC across multiple regions or multiple VPC networks in the same region, within the same or different projects. This allows customers to scale their cloud environments using a common policy model that abstracts native cloud networking and accelerates their cloud journey.

Part 2 of this blog series will show how Cisco CNC can also use contract-based routing along with automating VPC firewall rules in GCP by extending the same policy model.

Resources

Cisco Cloud Network Controller for Google Cloud -Installation Guides

Cisco Cloud Network Controller for Google Cloud -User Guides

Modernize your Multi-Cloud Network with Cisco Cloud Network Controller -blog

Blog Series: Introducing Cisco Cloud Network Controller on Google Cloud Platform

Part 2: Contract-based Routing and Firewall Rules Automation

Part 3: External Cloud Connectivity Automation