White paper

Cisco public

Cisco Cloud Services

Router and Google Cloud
Platform Solutions
Technology overview
The Cisco® Cloud Services Router 1000V (CSR 1000V) is a virtual-form-factor router that delivers
comprehensive WAN gateway and network services functions into virtual and cloud environments.
Using familiar, industry-leading Cisco IOS® XE Software networking capabilities, the CSR 1000V
enables enterprises to transparently extend their WANs into provider-hosted clouds. Similarly,
cloud providers themselves can use it to offer enterprise-class networking services to their
tenants or customers.
Built on the same proven Cisco IOS XE Software platform that powers the Cisco Integrated
Services Router (ISR) and Aggregation Services Router (ASR) product families, it offers a rich set
of features, including routing, VPN, firewall, Network Address Translation (NAT), Quality of Service
(QoS), Application Visibility and Control (AVC), failover, and WAN optimization. This broad suite of
functions empowers enterprises and cloud providers to build highly secure, optimized, scalable,
and consistent hybrid networks.
Zone-Based Firewall (ZBFW): The Cisco CSR 1000V Series includes the advanced security
features built into Cisco IOS XE Software, such as Access Control Lists (ACLs) and a stateful
ZBFW. Configuration of these features is familiar to existing IT staff and allows you to extend
existing enterprise security into the Google Cloud Platform (GCP). You can configure the security
policies between different Virtual Private Clouds (VPC) or VPC-to-on-premises networks.
Cisco Application Visibility and Control (AVC): The CSR 1000V provides a powerful,
pervasive, integrated service management solution based on stateful Deep Packet Inspection
(DPI). With Cisco AVC, instead of processing packets as individual events, the Cisco CSR 1000V
fully identifies flows and the layer 7 state of each application flow for application- and session-
based classification and management of IP traffic. Customers who have already enabled AVC in
their on-premises environment can now extend AVC into Google Cloud with the CSR 1000V to
visualize traffic in and out to Google VPCs.
Virtual Route Forwarding (VRF): The CSR 1000V allows multiple instances of a routing table to
exist in a router and work separately at the same time. The IP addressing in different VRFs can
overlap, since routes are not exchanged across multiple VRFs by default. However, you can route-
leak between VRFs, if the IP addressing does not overlap. Customers can use VRFs to segment
traffic for different VPCs or bring their VRFs from their on-premises network into Google Cloud.
© 2018 Cisco
© 2018and/or
Ciscoitsand/or
affiliates.
its affiliates.
All rightsAll
reserved.
rights reserved.
White paper
Cisco public

Contents Cisco CSR 1000V use cases in the Google

Cloud Platform
Technology overview Secure connectivity between premises and GCP
Cisco CSR 1000V use cases in More and more enterprise customers are moving their workloads from on-
premises data centers to Google Cloud Platform (GCP). Cisco CSR 1000V
the Google Cloud Platform
enables customers to securely extend on-premises network connectivity to

Secure connectivity between GCP and allows consistent routing and security policies across all networks.
premises and GCP Cisco CSR 1000V provides multiple VPN connectivity options such as IPsec
Site-to-site IPsec VPN VPN, Dynamic Multipoint VPN (DMVPN), Cisco EasyVPN, and more.

Encrypt Google Cloud Site-to-site IPsec VPN
Interconnect
One very common use case is to establish site-to-site IPsec VPNs between

Dynamic Multipoint an on-premises network and GCP to encrypt the traffic. With Cisco CSR
VPN (DMVPN) 1000V you can encrypt traffic between the on-premises network and

Allow overlapping IP addressing GCP, irrespective of the underlying transport layer such as Internet, direct
in VPCs interconnect, or partner interconnect (Figure 1).


Google Kubernetes Engine (GKE) Figure 1. Site-to-site IPsec VPNs

VRF segmentation
Zone-based firewall security Cloud Virtual Network

Application traffic visibility into
GCP VPC Internet

Maintain consistent policies
With Cisco TrustSec IPSEC
Corporate
DC ASR CSR
Deployment options Cloud Interconnect
Single NIC
Multi-NIC Note: See more details in the following sections on achieving encryption over a cloud interconnect.

High availability As shown in Figure 1, an IPsec tunnel can be established between the Cisco
Shared VPC ASR 1000 Aggregation Services Router deployed in the corporate data
Automation and management center and the CSR 1000V in GCP. In order for the CSR 1000V to build the
IPsec tunnel, inbound Google Compute Engine (GCE) firewall rules must

Deployment manager example
be added to allow traffic for User Datagram Protocol (UDP) ports 500 and
(YAML file)
4500. The source address could be the ASR’s public IP address. To allow

Get the CSR 1000V image Virtual Machines (VMs) inside the VPC to use the CSR 1000V as a secure
from Cisco gateway to reach out to the data center, specific routes for data center
prefixes must be added in the GCE routing table with next-hop as the CSR
Summary 1000V’s interface private IP address. For example, if the data center prefix
is 192.168.0.0/16 and the CSR 1000V’s IP address is 10.138.0.6 in a VPC
(10.138.0.0/16), the route would look like:

Static routing or dynamic routing should be enabled over the IPsec tunnel to
establish end-to-end connectivity.
© 2018 Cisco and/or its affiliates. All rights reserved.
White paper
Cisco public

Encrypt Google Cloud Interconnect

Google Cloud Interconnect provides a dedicated, enterprise-grade connection to GCP. A customer can directly peer
with Google or through a range of supported service providers. More detailed information can be found at the Google
Cloud Interconnect website. Once Google Cloud Interconnect is established, the customer can access their VPC VMs
using a private IP address through this dedicated connection, without traversing the Internet. However, if there is a
mandate to encrypt traffic, even over a private link, CSR 1000V can be deployed to encrypt the data.
In Figure 2, a Cisco ASR 1000 is deployed in the customer’s data center. Google Cloud Interconnect is established
between the data center and the customer’s project in GCP. Since a cloud router is mandatory with Google Cloud
Interconnect, the first BGP connection is established between the ASR 1000 and the Google Cloud Router. The
Google Cloud Router advertises the Cloud Interconnect VPC’s Classless Inter-Domain Routing (CIDR) to the ASR
1000. In order to let the CSR 1000V take over the routing and prevent recursive routing issues, the ASR 1000
advertises a specific loopback IP address (instead of the data center prefix) over the first Border Gateway Protocol
(BGP) connection to the Google Cloud Router.
The ASR 1000 can then use this loopback interface to establish the IPsec tunnel with the CSR 1000V to encrypt the
Cloud Interconnect connection. Overlay BGP peering can be established using the tunnel interfaces to exchange on
premises and Dev/Pro VPC CIDRs.
Figure 2. Cisco ASR 1000 in a data center

Dev VPC CIDR

DC Prefix Pro VPC CIDR

BGP2

IPSEC

Cloud Interconnect G1 G2 Dev VPC

Corporate ASR
DC CSR1000V
Google G3
Cloud Router

Loopback IP BGP1 Interconnect VPC CIDR Pro VPC

Note: Interconnect Circuit is terminated in Interconnect VPC Interconnect VPC

Note: In Figure 2’s topology, the CSR 1000V is deployed with multiple Network Interface Cards (NIC), each attached to a different VPC. The same
topology can be deployed with a single NIC CSR 1000V as well. However, appropriate import and export routing policies must be configured to
avoid recursive routing issues.

Dynamic Multipoint VPN (DMVPN)

Most enterprises have multiple branch offices and data centers. In these cases, typically Cisco’s DMVPN is deployed
across branches and data centers. DMVPN simplifies the VPN configurations to a hub-and-spoke model while a
spoke-to-spoke tunnel can be built dynamically. As an example, if a new VPC requires connectivity to the data center
and branch office, it can simply be added to the DMVPN network with the CSR 1000V.
Note: DMVPN uses Multipoint Generic Routing Encapsulation (MGRE; same port as GRE). However, it is encrypted by IPsec so even if GCP does not
allow GRE, DMVPN can be established.

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Figure 3. Dynamic Multipoint VPM

us-west
Cloud Virtual Network

us-east
CSR Cloud Virtual Network
Corporate ASR
DC

DMVPN/VPN
CSR

Branch Branch Branch

ISR ISR ISR

For DMVPN configuration samples, refer to the white paper, “Dynamic Multipoint IPsec VPNs.”

Allow overlapping IP addressing in VPCs

Oftentimes, customers may run into situations where overlapping IP address space exists in different VPCs that
require connectivity to each other. Since GCP does not allow VPC peering with overlapping IP address spaces,
the VPCs cannot peer with each other. The Cisco CSR 1000V provides a stop-gap solution and gives customers
a migration path to either update the IP addressing or continue to run it as is. With the Cisco CSR 1000V you can
establish IPsec VPNs between two VPCs and configure NAT rules for them to communicate with each other.

As shown in Figure 4, customers can deploy the CSR 1000V with NAT to address the overlapping IP address
problem. The IPsec tunnel is built using public IP addresses owned by Google. It rides over Google’s backbone,
not through public Internet. A customer can enable NAT on interface G1 and Tunnel1 and translate each side into a
different CIDR block. For example, the test VPC (172.16.2.0/24) can be translated into 10.0.2.0/24, the development
VPC (172.16.2.0) can be translated into 192.168.2.0/24. This is called static 1:1 NAT, and it requires the NAT Pool to
be the same size as your VPC CIDR. A customer can also use Port Address Translation (PAT) to translate the test VPC
into a single (or multiple) IP address to save some space. Either way, for the CSR 1000V to get the return traffic, a
specific route (NAT pool or next-hop CSR 1000V) needs to be configured in the development VPC’s route table.

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Figure 4. Deploying a Cisco CSR 1000V with NAT to address overlapping IP addresses

Test VPC Route Table Dev VPC Route Table

Prefix Next-hop Prefix Next-hop
192.168.2.0/24 G1 10.0.2.0/24 G1

Text VPC Dev VPC

172.16.2.0/24 172.16.2.0/24
Cloud Interconnect Cloud Interconnect
Translate to Google Translate to
10.0.2.0/24 G1 Backbone G1 192.168.2.0/24

IPSEC
CSR CSR
Tunnel1 Tunnel1

Src: 172.16.2.0, Dst: 192.168.2.0 Src: 192.168.22.0, Dst: 10.0.2.0

Traffic
Src: 192.168.2.0, Dst: 172.16.2.0 Src: 172.16.2.0, Dst: 10.0.2.0

NAT configuration sample:

#Left CSR
ip nat inside source static network 172.16.2.0 10.0.2.0/24
ip nat outside source static network 10.0.2.0 172.16.2.0/24

!
interface gigabitethernet 1
ip address 172.16.2.5 255.255.255.0
ip nat inside
!
interface Tunnel 1
ip address x.x.x.1(depends on your environment) 255.255.255.240
ip nat outside

ip route 192.168.2.0 255.255.255.0 x.x.x.2 <assume .2 is the remote tunnel ip address>

#Right CSR
ip nat inside source static network 172.16.2.0 192.168.2.0/24
ip nat outside source static network 192.168.2.0 172.16.2.0/24

!
interface gigabitethernet 1
ip address 172.16.2.5 255.255.255.0
ip nat inside
!
interface Tunnel 1
ip address x.x.x.2 (depends on your environment) 255.255.255.240
ip nat outside

ip route 10.0.2.0 255.255.255.0 x.x.x.1 <assume .1 is the remote tunnel ip address>

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Google Kubernetes Engine (GKE)

Connecting on premises to GKE can be achieved in the same way as described in earlier sections. A pod represents
a running process on your GKE cluster. GKE assigns separate IP ranges to pods than to the VPC CIDR cluster
where they are created. For example, in Figure 5, the VPC’s primary CIDR is 172.16.0.0/16 with a secondary CIDR
10.0.0.0/16 for pods. To establish connectivity to pods you can simply advertise the pod CIDR to the on-premises
router. An additional static route on the CSR 1000V is required for traffic destined to the pod CIDR with the next hop
as the VPC gateway. As discussed in a previous section of this paper, the VPC route table should be modified to use
the CSR 1000V as the gateway for on-premises CIDRs.
Figure 5. Establishing IP connectivity to pods

Cloud Virtual Network

Container (10.0.0.10/24)
Internet Container (10.0.0.11/24)
VM: 172.16.1.10
IPSEC Container (10.0.1.10/24)

ASR CSR Container (10.0.1.11/24)

Corporate Cloud VM: 172.16.1.20
Interconnect
DC
10.0.0.0/16 (Alias IP Range)
DC Prefix 172.16.0.0/16 (VPC CIDR)

Static route sample:

ip route 10.0.0.0 255.255.0.0 172.16.0.1

VRF segmentation
Place the CSR 1000V’s interfaces in different Virtual Routing Forwarding (VRF) instances to have different
segmentations. By default, VRFs don’t share routing information. A VRF doesn’t have routes to another VRF, so all
traffic is segmented. If the customer needs cross-VRF communication, there are different ways to enable route
leaking, such as Policy-Based Routing (PBR), Multiprotocol Border Gateway Protocol (MP-BGP) with VRF Route Target
(RT) import and export, and others. The idea is that customers have the flexibility to decide which VRF can talk to
which VRF. Furthermore, if customers are already using VRFs in their data centers or running a MPLS VPN network,
they can bring VRFs from on premises to Google Cloud for the same consistent network policy. The CSR 1000V
supports up to 4000 VRFs. Figure 6 is an example of extending VRF segmentation into Google VPC by using the CSR
1000V. Note that it requires multi-NIC deployment, which is discussed in detail in the Deployment Options section.

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Figure 6. Extending VRFs into Google VPC by using CSR 1000V with multi-NIC

Public VPC
172.16.1.0/24
Internet Front
Dev Door VRF
VRF G1
Dev VRF G2 Dev Dev VPC
Pro VRF 172.16.2.0/24
Pro Tunnel 1 VRF
ASR IPSEC
VRF CSR1000V G3

Corporate Pro Pro VPC

DC VRF 172.16.3.0/24

Zone-based firewall security

With the Cisco IOS XE Zone-Based Firewall (ZBFW) capability, you can place the CSR 1000V’s interfaces in different
zones. As firewalls, zones can’t communicate with each other by default. A cross-zone access policy needs to be
set up for that. ZBFW can also work with VRFs (not discussed in this white paper). You can find more information at:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/sec-
zone-pol-fw.html
Figure 7. Setting up zone-based firewalls

zone UNTRUSTED zone TRUSTED

Public VPC

G1 G2 Dev VPC
Internet 172.16.2.0/24
CSR1000V G3

Pro VPC
172.16.3.0/24

Application traffic visibility into GCP VPC

GCP VPC flow logs provide layer 4 visibility of your traffic within a VPC or going out of a VPC, which might not be
enough. What if you need more than just the five tuples of information (src_ip, dest_ip, src_port, dest_port, protocol)?
For example, besides HTTP, TCP port 80 is used by other applications like Skype, Bittorrent, and more. How can you
differentiate those applications if they appear as the same port in your VPC flow logs? How can you apply different
policies to those applications? Cisco Application Visibility and Control (AVC) can give you a deeper view into what’s
going on in your network.

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

AVC uses stateful Deep Packet Inspection (DPI) to classify more than 1400 applications. It creates a true
application-aware network and improves the performance of business-critical applications. It sends application
usage and performance statistics through NetFlow to a central collector, such as Cisco Prime® Infrastructure, Cisco
Stealthwatch®, or any third-party NetFlow collector like LiveAction. Based on the application performance, different
policies can be automatically applied to re-prioritize applications using QoS capabilities. AVC has been widely
deployed in customers’ campus and data center networks. Now you can bring the same functionality into the GCP
VPC by using the Cisco CSR 1000V.

You need to add a route in the VPC to redirect traffic to the CSR 1000V (described in the previous section). Once the
addition has been done, the CSR 1000V will be able to receive the VM’s traffic and inspect the traffic. For example,
Figure 8, which is a screenshot taken using LiveAction, displays the traffic going through a CSR 1000V in a GCP VPC.
Figure 8. Traffic flowing through a CSR 1000V in a GCP VPC

Guidance:
1. You need to change the <LIVEACTION_SERVER_IP> to your LiveAction server IP.
2. G1 is enabled with AVC for this example. You need to re-apply those configurations to other interfaces that need visibility.
CSR configurations sample:
flow record LIVEACTION-FLOWRECORD
description DO NOT MODIFY. USED BY LIVEACTION.
match flow direction

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

match interface input

match ipv4 destination address
match ipv4 protocol
match ipv4 source address
match ipv4 tos
match transport destination-port
match transport source-port
collect application http host
collect application name
collect application ssl common-name
collect counter bytes
collect counter packets
collect flow sampler
collect interface output
collect ipv4 destination mask
collect ipv4 dscp
collect ipv4 id
collect ipv4 source mask
collect ipv4 source prefix
collect routing destination as
collect routing next-hop address ipv4
collect routing source as
collect timestamp sys-uptime first
collect timestamp sys-uptime last
collect transport tcp flags
!
!
flow exporter LIVEACTION-FLOWEXPORTER-IPFIX
description DO NOT MODIFY. USED BY LIVEACTION.
destination <LIVEACTION_SERVER_IP>
transport udp 2055
export-protocol ipfix
option interface-table
option vrf-table
option sampler-table
option application-table
option application-attributes
option c3pl-class-table
option c3pl-policy-table
!
!
flow monitor LIVEACTION-FLOWMONITOR
description DO NOT MODIFY. USED BY LIVEACTION.
exporter LIVEACTION-FLOWEXPORTER-IPFIX
cache timeout inactive 10
cache timeout active 60
record LIVEACTION-FLOWRECORD

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

interface GigabitEthernet1
ip flow monitor LIVEACTION-FLOWMONITOR input
ip flow monitor LIVEACTION-FLOWMONITOR output
ip address dhcp
ip nbar protocol-discovery
negotiation auto
no mop enabled
no mop sysid

Maintain consistent policies With Cisco TrustSec

In a previous section, we discussed using VRFs to segment traffic at the routing level, and using ZBFW to segment
traffic from zones or firewalls. Alternatively, you can use Cisco TrustSec® and Security Group Access Control Lists
(SG-ACLs) to implement a Group-Based Policy (GBP) solution with the CSR 1000V in GCP. The benefit of Cisco
TrustSec is that it allows you to configure a group tag in the policy, instead of individual IP addresses, which are hard
to maintain when the number of addresses grows. Then you can create the SG-ACLs that define which groups can
talk to which groups based on which ports and protocols you’re using. Cisco TrustSec can work with ZBFW as well.
Note: The Security Group Tag (SGT) is different than the tag you configured in VPCs.

For customers who have already deployed TrustSec with Cisco Identity Services Engine (ISE), you don’t have to
modify the current policies. Just connect ISE with the CSR 1000V in GCP. Tag mappings and polices are automatically
propagated to the CSR 1000V, and enforcement can happen on the CSR 1000V in GCP. For example, a customer
may have a development server in the data center tagged as Dev Group, and it has a policy associated that states the
Dev Group can’t access the HR server in the data center. By moving this development server into GCP, the customer
just needs to update the mapping to include the development server in GCP tagged as Dev Group. Then the same
policy will be applied. The development server in GCP won’t be able to access HR server in the data center.

Deployment options
Customers have the option to deploy the CSR 1000V either as single NIC VM or multi-NIC VM, depending upon the
customer’s requirements.

Single NIC
The Cisco CSR 1000V can be deployed with a single NIC in a given VPC as shown in
Figure 9. CSR 1000V as a single NIC

Pro VPC

DC
Tun
ne
l1

.... G1
Branch
Tunnel N
CSR 1000V

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

To connect multiple VPCs to an on-premises environment, multiple CSR 1000V routers (one CSR 1000V per VPC)
need to be deployed, as shown in Figure 10.
Figure 10. Two single NIC CSR 1000Vs deployed in two VPCs

Pro VPC Dev VPC

G1 G1

CSR CSR
1
n el
Tu n
Tunnel 1

Tunnel 2
nne Tu
l2

DC Branch

Multi-NIC
GCP supports VMs with multiple network interfaces, each connecting to different VPCs. During the CSR 1000V
creation, you can select up to eight interfaces, meaning eight different VPCs. This gives a customer the capability to
connect multiple VPCs to the on-premises network with a single CSR 1000V. As shown in Figure 11, the CSR 1000V
has a primary interface, G1 in Pro VPC, and a second interface, G2 in Dev VPC. The CSR 1000V can advertise the
CIDR of both the Pro VPC and Dev VPC over tunnels to establish end-to-end connectivity. Compared to single NIC,
multi-NIC deployment consolidates the IPsec connection.
Figure 11. Multi-NIC CSR 1000V

CSR 1000V Pro VPC

Tunnel 1 G1
DC

.... G2
Dev VPC

Tunnel N
Branch

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

High availability
Cisco’s cloud-native high availability is not yet supported on GCP, however customers can still achieve high availability
with GCE’s native routing capabilities and redundant IPsec tunnels on premises for most failure scenarios. Similar to
an on-premises environment, two Cisco CSR 1000V routers can be deployed, as shown in Figure 12. Both active-
active and active-standby architectures are possible by choosing the same or different priorities on GCE to forward
traffic to the CSR 1000Vs. If one CSR 1000V fails, GCE will detect the failure of the instance and deactivate the
associated route. That will trigger all outbound traffic to flow through the second CSR 1000V. Next, establish IPsec
tunnels from both CSR 1000Vs with the Cisco ASR 1000 deployed on premises with appropriate routing metrics, as
shown in Figure 12.
Figure 12. CSR 1000V setup as active-standby through use of VPC routes

VPC
App Subnet A
CSR Subnet1
IPSEC Route
Table
Internet
CSR 1
ASR IPS
EC App Subnet B
Corporate DC
CSR Subnet2
Route
Table
CSR 2

Prefix Next-hop Priority

CSR1 as Active Corporate DC CSR1’s G1 1000
CSR2 as Standby Corporate DC CSR2’s G1 900

With the Cisco cloud-native high-availability feature, both CSR 1000V routers can be configured with a keep-alive
that will monitor the state of the CSR 1000V. In case the CSR 1000V fails, the loss of keep-alive messages will trigger
high-availability failover. Then the CSR 1000V will make Representational State Transfer (REST) APIs to modify GCE
route tables, as shown in Figure 13. It supports both active-active and active-standby. Failover can also be triggered
by a Cisco IOS Embedded Event Manager (EEM) event and Guest Shell script, which offer customers flexibility to
create more advanced scenarios like failover and failback.

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Figure 13. Cloud-native high availability on the CSR 1000V

VPC
App Subnet A
CSR Subnet1
IPSEC Route
Table
Internet
CSR 1
ASR IPSEC
Keepalive App Subnet B
Corporate DC CSR Subnet2
Route
Table
CSR 2

Prefix Next-hop Priority

Cloud REST API Corporate DC CSR1’s G1 1000
Before HA Failover/After HA Failover Corporate DC CSR2’s G1 1000

Shared VPC
Shared VPC is a powerful feature that allows organization administrators to delegate responsibilities, such as creating
instances in service projects, while maintaining centralized control over network resources such as subnets, firewall
rules, etc. To learn more about shared VPC see Google’s shared VPC overview. For the purposes of this document,
the CSR 1000V can be deployed in the host project and a single VPC or multiple shared VPCs can be connected
to the CSR based on the requirements. The main advantage of deploying the CSR 1000V in the host project is that
multiple service projects can receive connectivity to the on-premises network versus deploying a CSR 1000V in
each project separately. In the case of a shared VPC, all custom routes, which make VMs to use the CSR 1000V as a
gateway (described in the previous section), are defined in the host project.
Figure 14. CSR 1000V (single NIC) deployed in a shared VPC

Shared VPC Route Table

Prefix Next-hop
DC Prefix G1
Service Project
(Web Testing)
Shared VPC Web
Internet subnet Instance

VPC Routing
IPSEC Public
subnet
ASR G1 Mobile Instance
Corporate DC Tunnel subnet
Cloud CSR 1000V
Interconnect Service Project
Host Project (Shared Testing) (Mobile Testing)

© 2018 Cisco and/or its affiliates. All rights reserved.

White paper
Cisco public

Automation and management

For customers who like to use an automation script, Google Deployment Manager or a GCloud Command can be used
to deploy the CSR 1000V. Following is an example of a GCloud CLI.

Gcloud CLI example (creates a CSR 1000V with 1vCPU, 4 GB memory, 8 GB disk):

gcloud beta compute --project=<your-project> instances create <vm-name> --zone=<your-az> --machine-

type=custom-1-4096 --subnet=public-subnet1 --address=<csr-public-ip> --network-tier=PREMIUM
--metadata=block-project-ssh-keys=true,ssh-keys=<username>:<ssh-key> --can-ip-forward --image=<image-
name> --image-project=<project-contains-csr-image> --boot-disk-size=8GB --boot-disk-type=pd-standard
--boot-disk-device-name=<vm-name>

Deployment manager example (YAML file)

The CSR 1000V also has an on-box automation capability, called Guest Shell, which provides a Linux bash
environment for customers to run Python scripts. Guest Shell scripts can be triggered by Cisco IOS Embedded Event
Manager (EEM). One use case could be to have a script monitoring the CSR 1000V’s throughput and send it to
Stackdriver Monitoring. You can create an EEM applet that triggers the script every minute. After that, a network admin
can monitor the CSR 1000V’s real-time throughput on Stackdriver in a visualized fashion. A specific altering rule can
be created on Stackdriver Monitoring to take actions. For example, if traffic reaches 80 percent of the CSR 1000V’s
throughput capacity for five minutes continuously, a notification can be sent out to a network administrator for larger
capacity planning. To enable Guest Shell, refer to the Cisco IOS XE Programmability Configuration Guide.

Once the CSR 1000V is up and running in the customer’s VPC environment, the customer can use Secure Shell (SSH)
to log in and configure it like any other Cisco IOS XE Software routers. The CSR 1000V also supports a RESTConf/
NetConf API. More detailed information can be found at: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/
configuration/169/b_169_programmability_cg/restconf_programmable_interface.html

For later login management, customers can add the CSR 1000V router to their TACACS+ or RADIUS server for
Authentication, Authorization, and Accounting (AAA).

Get the CSR 1000V image from Cisco

You can contact ask-csr-gcp-pm@cisco.com to get CSR 1000V images. We will share the CSR 1000V image with
customers individually. The deployment guide can be accessed at: https://www.cisco.com/c/en/us/td/docs/routers/
csr1000/software/gcp/b_csrgcp.html.

Summary
As customers move workloads to Google Cloud Platform, it’s important that they maintain a consistent network
across branches, campus, data center, and cloud. By deploying the Cisco CSR 1000V in the GCP VPC, customers
can extend their on-premises network to GCP using the same Cisco IOS XE features so they can maintain the same
secure VPN connections, segmentation, and application visibility and control.

To learn more about the Cisco CSR 1000V, visit: http://cisco.com/go/cloudrouter

© 2018 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of
Cisco trademarks, go to this URL: https://www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (1110R) C11-741200-00 12/18