Cisco Multicloud Portfolio: Cloud Connect · In addition, by using the Cloud Services Router 1000V,...

© 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 34

Cisco Multicloud Portfolio:

Cloud Connect

AWS Transit VPC with Cisco Cloud Services

Router 1000V

June 2018

Design and Deployment Guide


Contents

Executive summary ................................................................................................................................................. 3 Cloud Multicloud: Overview ................................................................................................................................... 3 Cloud Connect: Overview ..................................................................................................................................... 4 Cloud Connect: Use cases.................................................................................................................................... 4 Cloud Connect: Benefits ....................................................................................................................................... 4

Technology overview .............................................................................................................................................. 5 Cisco Cloud Services Router 1000V ..................................................................................................................... 5 Application Visibility and Control ........................................................................................................................... 6 Zone-Based Firewall ............................................................................................................................................. 6

Solution design ........................................................................................................................................................ 6 Validated deployment steps .................................................................................................................................. 7

Procedure 1. Deploy transit VPC template using CloudFormation ................................................................... 7 Procedure 2. Verify transit VPC deployment .................................................................................................. 11 Procedure 3. Modify security group to allow access to CSR1000Vs .............................................................. 12

Create spoke VPC .............................................................................................................................................. 14 Procedure 1. Create the VPC ......................................................................................................................... 14 Procedure 2. Create a virtual private gateway ............................................................................................... 15 Procedure 3. Attach the VGW to the spoke VPC ........................................................................................... 16

Connect the spoke VPC to the transit VPC ......................................................................................................... 17 Procedure 1. Add tag name to spoke VPC ..................................................................................................... 17 Procedure 2. Verify connectivity from spoke VPC to transit VPC ................................................................... 19 Procedure 3. Confirming the VPC is using the VGW to route traffic ............................................................... 20

Implementing application visibility and control .................................................................................................... 22 Procedure 1. Enable AVC and web GUI on the CSR1000V ........................................................................... 22 Procedure 2. Open web ports on the security group ...................................................................................... 22 Procedure 3. Access the CSR1000V web GUI .............................................................................................. 24

Implementing a zone-based firewall .................................................................................................................... 26 Procedure 1: Create security zones for interfaces.......................................................................................... 28 Procedure 2. Assign interfaces to security zones ........................................................................................... 28 Procedure 3. Create zone pairs ..................................................................................................................... 29 Procedure 4. Define class-maps to match traffic ............................................................................................ 29 Procedure 5. Define policy maps to associate actions to traffic ..................................................................... 30 Procedure 6. Attach policy-maps to zone pairs .............................................................................................. 32

Additional resources ............................................................................................................................................. 32


Executive summary

This guide focuses on the deployment of transit Virtual Private Cloud (VPC) on the Amazon Web Services (AWS)

platform using the Cisco® Cloud Services Router 1000V (CSR1000V). Because the CSR1000V runs the same

software as the Cisco ASR 1000 Series Aggregation Services Routers and the 4400 Series Integrated Services

Routers, you get a feature-rich router running on the AWS platform. When implementing the CSR1000v, you gain

access to enterprise-class features such as Application Visibility Control (AVC) and Zone-Based Firewall (ZBFW).

Therefore, this guide also covers the implementation of AVC and ZBFW.

The audience for this guide includes, but is not limited to, network design engineers, network operations personnel,

and security operations personnel who wish to deploy transit VPC on the AWS platform with a feature-rich router.

Cloud Multicloud: Overview

In a multicloud world, growing complexity is driving a cloud gap between what your customers require and what

your people, processes, and tools can support. With the Cisco Multicloud Portfolio, we make it simple: simple to

connect, simple to protect, and simple to consume.

The Cisco Multicloud Portfolio is a set of essential products, software, and services supported with simplified

ordering and design deployment guides to help you when it comes to multicloud adoption. The Cisco Multicloud

Portfolio consists of four component portfolios (Figure 1):

● Cloud Advisory: Helps you design, plan, accelerate, and reduce risk during your multicloud migration

● Cloud Connect: Securely extends your private networks into public clouds and makes sure of the

appropriate application experience

● Cloud Protect: Protects your multicloud identities, direct-to-cloud connectivity, data, and applications,

including Software as a Service (SaaS), and detects infrastructure and application threats on-premises and

in public clouds

● Cloud Consume: Helps you deploy, monitor, and optimize applications in multicloud and container

environments

Figure 1. Cisco Multicloud portfolio: Cloud Advisory, Cloud Connect, Cloud Protect, and Cloud Consume


Cloud Connect: Overview

Cloud Connect consists of essential products that help securely extend your private networks—including data

center, branches, and campuses—to public clouds and ensure the application experience is optimal:

● Cisco Cloud Services Router 1000V

● Cisco Application Centric Infrastructure (Cisco ACI™

) Virtual Edge with Cisco Umbrella®

For detailed use cases, see the section about Cloud Connect on the portfolio’s solution page at

https://www.cisco.com/go/multicloud.

Cloud Connect: Use cases

Cloud Connect delivers value in the following use cases:

● Securely extend a private network to single or multiple public cloud environments: This use case

includes multiple clouds (such as multiple AWS and Azure), multiple regions in cloud, multiple VPCs in a

cloud, VPN, multicloud and multi-VPC connectivity, scaling, and performance optimization-transit VPC. It

also supports extending data centers into the clouds and enabling direct branch-to-cloud connectivity (such

as when a branch has Cisco 4000 Series Integrated Services Routers and wants to connect the clouds, or a

branch has Virtual Edge and requires a software-defined WAN [SD-WAN] extension to the cloud).

● Optimize data center and branch connectivity performance to cloud Infrastructure-as-a-Service

(IaaS) and Software-as-a-Service (SaaS) applications. This use case includes best path to destination

(SD-WAN), cloud segmentation, monitoring to assure best performance, visibility to traffic going to

application, and traffic shaping/Quality of Service (QoS). It also supports extending data centers into the

clouds and enabling direct branch-to-cloud connectivity (such as when a branch has 4000 Series ISRs and

wants to connect the clouds, or a branch has Virtual Edge and requires an SD-WAN extension to the cloud).

● Secure access to the Internet and SaaS from the branch: This use case includes connecting (and

protecting) branch office users directly to the multicloud environment leveraging direct Internet access, SD-

WAN (Virtual Edge), and secure Internet gateways (Cisco Umbrella).

Cloud Connect: Benefits

Cloud Connect benefits include:

● Extend private network to multicloud while leveraging existing investments.

● Apply consistent security policies across private and public cloud footprint.

● Enhance and secure application experience on a cloud network by enabling visibility and path selection/

optimization.

● Centralize management in a manner that is intuitive; fast; and easy to design, provision, and apply policies

to across the entire network.

● Achieve faster, simpler adoption of cloud.

● Improve TCO.

● Access a richer networking security feature set and higher performance.

● Improve ease of use through consistency of management tools for on-premises and cloud.

● Simplify implementation through increased visibility into public cloud network.

https://www.cisco.com/go/multicloud


Technology overview

If you have multiple virtual private clouds with Amazon Web Services, you have the option to provide connectivity

between your VPCs. One option for connecting multiple VPCs is through a transit VPC. A transit VPC simplifies

network management and minimizes the number of connections. In addition, by using the Cloud Services Router

1000V, you gain the added benefits of a feature-rich router’s enterprise-class capabilities.

In this guide, transit VPC is deployed in a high-availability design using two CSR1000Vs in separate availability

zones and deployed using the AWS CloudFormation Template. All the resources that are required to make the

transit VPC fully functional are installed when the template is executed. Spoke VPC and remote networks—

connecting via the transit VPC—utilize VPN connectivity. Routes are learned dynamically using Border Gateway

Protocol (BGP).

Note

For more information on the transit VPC solution, including the AWS CloudFormation Template and resources the solution uses, refer to additional resources at the end of this guide.

Transit VPC deploys a hub-and-spoke network topology (see Figure 2). The transit VPC serves as the hub while

the VPC acts as the spokes. Note that although it is possible to connect remote networks, such as an on-premises

network, that is beyond the scope of this guide.

Figure 2. Transit VPC topology

Cisco Cloud Services Router 1000V

The CSR1000V is a software router that an enterprise or a cloud provider can deploy as a virtual machine in a

provider-hosted cloud or in its own virtual environment. It contains Cisco IOS XE software networking and security

features, as well as enterprise-class features such as Application Visibility Control (AVC) and Zone-Based Firewall

(ZBFW).


Application Visibility and Control

The AVC feature leverages multiple technologies to recognize, analyze, and control over 1000 applications,

including voice and video, email, file sharing, gaming, peer-to-peer, and cloud-based applications. This feature can

be enabled on the CSR1000V.

Zone-Based Firewall

The ZBFW feature changes the firewall configuration from an older interface-based model to a more flexible, more

easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic

moving between the zones. This is a feature of the CSR1000V.

Solution design

This guide assumes familiarity with the AWS platform. Issues such as how to log into the AWS management

console and how to navigate through AWS will not be discussed.

You can implementing the CSR1000V in a manner that resembles a manual process or by using a template,

specifically the CloudFormation template. The CloudFormation tool can be accessed from the AWS management

console. This guide uses the template.

Note:

Using this particular template assumes you are deploying it in a primary account. If you have a secondary account, it will not work. Another template specifically for use with a secondary account is available, but this guide does not cover it.

The template deploys the following components on the AWS platform:

● 1 Transit VPC

● 2 Subnets in two availability zones

● 2 Route tables in two availability zones

● 1 Internet gateway

● 2 CSR1000Vs in two availability zones

● 2 Lambda scripts

Note:

We do not recommended deploying other services in the transit VPC.

The general procedures to deploy the transit VPC, AVC, and ZBFW are as follows:

● Implement transit VPC.

● Create spoke VPCs.

● Connect spoke VPCs to the transit VPC.

● Implement AVC.

● Implement ZBFW.


Figure 3 provides guidelines on how to read commands given in this guide.

Figure 3. How to read commands given in this guide

Validated deployment steps

Procedure 1. Deploy transit VPC template using CloudFormation

This section describes how to deploy the transit VPC template using CloudFormation.

Step 1: Log in to the AWS management console.

Step 2: Specify the region where you are deploying the transit VPC.

Note:

If you do not specify the region, AWS will use its default: US East (N. Virginia).

Step 3: Launch the CloudFormation tool from Services > Management Tools.

Step 4: Click Create Stack to launch the wizard used to deploy the transit VPC template (Figure 4).

Step 5: Choose Specify an Amazon S3 template URL, and then input the correct URL. For this guide, use

https://s3.amazonaws.com/solutions-reference/transit-vpc/latest/transit-vpc-primary-account.template.

https://s3.amazonaws.com/solutions-reference/transit-vpc/latest/transit-vpc-primary-account.template


Figure 4. Select the transit VPC template

Step 5: Click Next when done.

Step 6: Enter the necessary parameters on the specify details screen (Figure 5).

Figure 5. Specify the necessary parameters

Step 7: Specify a stack name.

Step 8: Select the throughput. Currently, CSR1000V comes in four types of instances. The higher the throughput,

the larger the instances. When you are deploying the solution in this guide, you are deploying two CSR1000Vs,

hence the number 2 before x500Mbps. The second number is the throughput.


Step 9: Select a key pair. You will need this to access the CSR1000V. If you have not created a key pair, do so

before you continue. This guide does not cover creating a key pair. Consult the AWS online documentation for

instructions on how to do this. Note that each region requires a separate key pair. Make a note of which region you

create your key pair in. If you do not see your key pair, you may have created it in another region.

Step 10: Input your license option. Two types of licensing are available for the CSR1000V: Bring Your Own

License (BYOL) and license included. Consult the AWS Marketplace for additional information.

Step 11: Leave the default option, Yes, for Enable Termination Protection to protect the CSR1000V from

accidental deletion.

Step 12: For Prefix for S3 objects, leave the default: vpnconfigs/. Any object created by this guide on the Amazon

S3 will have this prefix.

Step 13: If you have an additional AWS account that you want to connect to the transit network, specify it here.

This guide does not cover the use of additional AWS accounts, so leave this option blank for this guide’s

deployment.

It is now time to enter the network configuration parameters (Figure 6). Note: We recommend using the defaults for

steps 14–22.

Figure 6. Specify the network configuration

Step 14: For the transit VPC classless interdomain routing (CIDR) block, you can modify this field or leave it blank.

If this address does not conflict with your existing network, we recommend leaving the default.

Step 15: The first subnet CIDR block is created in availability zone 1. It can be modified, but unless this setting

conflicts with your existing network, we recommend using the default.

Step 16: The second subnet CIDR block is created in availability zone 2.

Step 17: You can modify the transit VPC BGP ASN (autonomous system number), if necessary.

Step 18: The spoke VPC tag name is used to identify the spoke VPC and to join a spoke VPC to a transit network.


Step 19: The transit VPC solution uses a script that polls the value of the spoke VPC tag name. When the script

sees the value true, it will join the spoke to the transit VPC.

Step 20: Traffic is normally passed through using both 1000Vs (basically an active/active state). Each spoke VPC

receives an equal-cost path to both the 1000Vs. If you prefer an active/standby state, you can use the preferred

VPN endpoint tag name to accomplish this. For our use case, we keep the default.

Step 21: You can modify the availability zone the first subnet can be created on, if necessary.

Step 22: You can also modify the availability zone for the second subnet, if necessary.

Step 23: Click Next when done.

Step 24: For the options page, do not need to make any changes. Leave the defaults and click Next to continue.

Step 25: Review the information you have entered to verify it (Figure 7). Then check “I acknowledge that AWS

CloudFormation might create IAM resources.”

Step 26: Click Create to deploy the template.

Figure 7. Review screen allows you to verify the information you have entered


Procedure 2. Verify transit VPC deployment

Once you have deployed the transit VPC template, you can verify its successful deployment in various ways. In

general, if you do not get any errors when you deploy the transit VPC template using CloudFormation, chances are

good you have a successful deployment.

Step 1: Verify successful deployment of the transit VPC Template in CloudFormation. From the CloudFormation

dashboard, you should see the stack or template recently deployed (Figure 8). Its status should be

Create_Complete. In the Events tab, you should see the individual tasks listed.

Figure 8. Verify transit VPC deployment from the CloudFormation dashboard

Step 2: Use the Amazon Elastic Compute Cloud (EC2) dashboard to verify that the CSR1000V has been deployed

(Figure 9).

Figure 9. Verify transit VPC deployment using the EC2 dashboard

Step 3: Verify the networking aspect on AWS. Click each of the items listed on the left-hand side to verify that the

various components—subnets, route tables, Internet gateways, etc.— have been created.


Figure 10. Verify transit VPC deployment using the VPC dashboard

Procedure 3. Modify security group to allow access to CSR1000Vs

This procedure covers how you can modify the security group to allow access to the CSR1000Vs using Secure

Shell (SSH) Protocol for troubleshooting and configuration of additional features.

Step 1: From the EC2 dashboard, click the instances (Figure 11). Each CSR1000V has a public IP address. The

dashboard also shows which security group each CSR1000V instance is associated with. The security group

controls the inbound and outbound traffic to the instance.

Note:

Make note of the public IP addresses. You will use them to access the CSR1000V via SSH.

Figure 11. EC2 dashboard shows the CSR1000V’s public IP address and the security group it is associated with

Step 2: Click the security group that is associated with the CSR1000V instance and allow SSH. You need to do

this to be able to access the CSR1000V.


You will be taken to the Security Group page. From here, you can modify the security group.

Step 3: Click Edit to modify the inbound rule and allow SSH (Figure 12). Notice that there is already a rule that

allows SSH from a specific source, which is the Lambda script. To make it accessible from the outside world, we

need to add an additional SSH rule.

Figure 12. From the Security Group page, allow SSH so you can access the CSR1000V

Step 4: Click Add Rule to add an inbound SSH rule. If you know where you are accessing from, specify a

custom source.

Note:

Security groups are stateful. If you allow a specific protocol inbound, the same protocol will be allowed outbound, which is why you do not need to specify an outbound for SSH.

Tech Tip

As a best security practice, specify a specific source.

Figure 13. Edit the security group to add an inbound SSH rule

You do not need to modify the security group for the second CSR1000V since it is using the same security group

as the one you just modified.

Once you have completed this configuration, you should be able to use SSH to access the 1000V wherever an

SSH client is available.


Note:

Similar to the process of accessing an instance, you will need your key pair file—.pem file—to access the CSR1000V.

Note:

The username to access the CSR1000V is ec2-user—not root, as indicated by AWS.

Create spoke VPC

A transit VPC has been created on the AWS platform. Now we need to create spoke VPCs. In this use case

scenario, we will create two spoke VPCs, each of which will be connected to the other via the transit VPC. The

joining of the spoke VPC to the transit VPC is automated.

Previously, we defined a tag name to a spoke VPC with a value of true. A Lambda script is running in the

background that polls the tag name once every minute. If the tag name contains the value of true, this will trigger

another Lambda script that will generate and configure the components required to connect to a transit VPC. This

script will configure both the CSR1000Vs in the transit VPC as well.

Procedure 1. Create the VPC

Step 1: Click Create VPC in the VPC dashboard (Figure 14).

Figure 14. Create a VPC from the VPC dashboard

Step 2: Specify a name and an IPv4 CIDR block for the VPC (Figure 15).

Figure 15. Create spoke VPC


Step 3: Repeat steps 1 and 2 to create another spoke.

Procedure 2. Create a virtual private gateway

The connection between a spoke VPC and a transit VPC is an IPSec tunnel. To create this connection, we need

two endpoints: one on the AWS side and the other on the transit VPC side. For the AWS side, this is where the

virtual private gateway (VGW) comes in. On the transit VPC side, the CSR1000Vs are the endpoints. Endpoints

that are not from the AWS side are referred to as customer gateways.

In this procedure, you will create a VGW. Once the VGW is created, you need to attach it to the spoke VPC.

Attaching the VGW to the spoke VPC is covered in Procedure 3.

Step 1: Click Create Virtual Private Gateway from the VPC dashboard (Figure 16).

Figure 16. Create a VGW from the VPC dashboard

Step 2: Specify a name for the VGW and select Amazon default ASN (Figure 17). You can modify the ASN

number, but we recommend using the default so that you don’t have to manage the ASN number.


Figure 17. Create the VGW

Step 3: Repeat steps 1 and 2 to create a second VGW for the second spoke.

Procedure 3. Attach the VGW to the spoke VPC

To put the VGW to use, you need to attach it to the spoke VPC.

Step 1: Select VGW-A, click the Actions tab, and then click Attach to VPC to start the setup wizard (Figure 18).

Figure 18. Select the VGW and attach it to the spoke VPC

Step 2: Select the SpokeA VPC, and then click Yes, Attach to complete this task (Figure 19).

Figure 19. Attach the spoke VPC

Step 3: Repeat steps 1 and 2 for the second VGW.

The two VGWs should now be in an attached state. VGW-A should be attached to SpokeA and VGW-B should be

attached to SpokeB. You can verify this on the VPC dashboard under Virtual Private Gateways.


Connect the spoke VPC to the transit VPC

Now that you have created the spoke VPCs, you are ready to connect them to the transit VPC.

This guide refers to connecting the VPC to the transit VPC. What you are actually doing is connecting to the VGW.

The VGW in turn is attached to the VPC. To be precise, the VGW is a logical concept. When it connects to the

CSR, it is actually creating two endpoints at the back end. It does this for redundancy. In this use case, it is also

connecting to the two CSRs. Not only does this provide redundancy on the AWS side, there is also redundancy on

the transit VPC. Therefore, there will be a total of two VPN connections with each VPN connection having two

tunnels. With regards endpoints, there will be a total of four endpoints on the AWS side (see Figure 20).

Figure 20. VGW is a logical concept

Connecting the spoke VPC to the transit VPC is an automated process. You only need to add a tag name to the

VGW with a value of true. From that point on, the Lambda script (a component of the transit VPC solution) polls the

VGW for a specific tag name and value. Once it meets the criteria, it launches another Lambda script to configure

the VGW, generate a CSR1000V IPsec configuration, and push that out to the CSR1000Vs.

Procedure 1. Add tag name to spoke VPC

This procedure adds a tag name to the spoke VPCs.

Step 1: Select the first spoke VPC, SpokeA, and click the Tags tab (Figure 21).


Figure 21. Tags tab showing only one tag

Step 2: Click Add/Edit Tags and then Create Tag (Figure 22). Add a tag name—transitvpc:spoke—with a value of

true. Click Save when done.

Figure 22. Add a new tag

Step 3: Repeat steps 1 and 2 for the second spoke VPC, SpokeB.


Procedure 2. Verify connectivity from spoke VPC to transit VPC

Four customer gateways and four VPN connections should have been created. You can verify this on the VPC

dashboard under Customer Gateways and VPN Connections. If you select VPN Connections, you should see two

tunnels under the Tunnel Details tab (Figure 23). As outlined above, each VPN connection will have two tunnels.

Figure 23. Customer gateway and VPN connection verification

On the CSR1000Vs, you can verify the tunnels are up (Figure 24) by issuing this command:

show ip interface brief

Figure 24. Sample output from show IP interface brief command

You can also see the BGP routes (Figure 25) with this command:

show bgp all


Figure 25. Sample output from show BGP all command

Procedure 3. Confirming the VPC is using the VGW to route traffic

At this point, the VPN connections should be up and there are routes on the CSR1000V. The last thing you need to

do is to ensure the VPC is using the VGW to route traffic between the spoke VPCs.

Step 1: From the VPC dashboard, go to Route Tables.

Step 2: Click the Route Propagation tab. Verify that If Propagate is enabled. If it is not, click Edit and select

Propagate (Figure 26).


Figure 26. Enable route propagation

Step 3: From the Routes tab, you can verify if the routes in the table are using the VGW.

Figure 27. Verify that routes in the tables are using the VGW


You have finished deploying the transit VPC with CSR1000V in the AWS platform. You should now have a

functional networking configuration that enables connectivity between VPCs. If you want to further test connectivity,

create a Linux instance in each of the VPCs and verify end-to-end connectivity.

Implementing application visibility and control

This section shows how to get visibility into traffic in the cloud using the CSR1000V's Application Visibility and

Control (AVC) feature.

This guide does not cover how to export application flow data to NetFlow Collector. Rather, it shows how to use the

CSR1000V's web GUI to visualize what traffic has traversed it.

Note:

Make sure the CSR1000Vs are properly licensed to take advantage of AVC.

Procedure 1. Enable AVC and web GUI on the CSR1000V

To get visibility into traffic in the cloud, first enable AVC on the CSR1000V.

Step 1: Log in to the first CSR1000V via SSH and enter the following commands to create a username and

password for CSR1000V web GUI use:

ip ssh server algorithm authentication publickey password

username cisco privilege 15 password 0 cisco

crypto key generate rsa modulus 1024

Step 2: Enable the web GUI on the CSR1000V using the following commands in global configuration mode:

ip nbar http-services

ip http secure-server

transport-map type persistent webui TRANSITVPC_TMAP

secure-server

transport type persistent webui input TRANSITVPC_TMAP

Step 3: Enable Network-Based Application Recognition (NBAR) on all interfaces from which you want to collect

traffic. Input this command in interface mode:

ip nbar protocol-discovery

Step 4: Repeat steps 1–3 to configure the second CSR1000V.

Procedure 2. Open web ports on the security group

To access the CSR1000Vs via the web GUI, you need to open the ports on the security group with which the

CSR1000V instances are associated.

Note:

It is not a best practice to open ports for outside access. The preferred method is to allow only inside access. In the AWS platform, it is best to utilize a bastion or jump station. For demonstration purposes only, this procedure utilizes outside access.

Step 1: On the EC2 dashboard, under Instances, select the CSR1000V instance you want to modify (Figure 28). In

the Description tab, click the security group that is associated with the CSR1000V instance. This will redirect you to

the Security Group page.


Figure 28. Select the CSR1000V instance from the EC2 dashboard

Step 2: Click the Inbound tab and then Edit to modify the inbound rules (Figure 29).

Figure 29. Edit the security group

Step 3: Add an inbound rule: HTTPS. Click Save when done.


Figure 30. Add or modify an inbound rule

Procedure 3. Access the CSR1000V web GUI

You can now access the CSR1000V web GUI to view the traffic.

Step 1: To access the CSR1000V web GUI, use the URL format https://ip.address.of.csr. For the username and

password, use the credentials you specified earlier. In this case, cisco/cisco.

The main dashboard appears and displays the chart for the top applications (Figure 31). This gives you a quick

summary of the top applications on this particular CSR1000V.

Note:

If you do not see any traffic, it is most likely using other tunnels that are connected to the second CSR1000V. You will need to log into the other one to view the traffic.

Figure 31. The CSR1000V web GUI dashboard


Step 2: Click Monitoring and then Application Visibility. This will direct you to a page where you can view the traffic

that the CSR1000V sees.

Figure 32. CSR1000V web GUI monitoring display

Clicking the Application Visibility tab shows application traffic that is traversing the CSR1000V. You can apply filters

to this data. For example, if you want to see traffic appearing on a certain interface of the CSR1000V, use the

interface filter to isolate traffic to that interface. You can do the same for traffic direction, either egress or ingress.

You can also specify the interval you want.

At the bottom of the Application Visibility page, you can see the various applications (Figure 33).

Figure 33. CSR1000V web GUI application visibility display


Application traffic can also be viewed using the command line interface on the CSR1000V (Figure 34). Use this

command in global configuration mode:

show ip nbar protocol-discovery

This command has options, such as to view the top application talkers, filter by interface, etc.

Figure 34. Sample output from the show ip nbar command

Implementing a zone-based firewall

One of the benefits of utilizing a CSR1000V in a transit VPC is the ability to implement a zone-based firewall. This

section covers configuration of the Zone-Based Firewall feature on the CSR1000V.

The Zone-Based Firewall (ZBFW) feature is the successor to the Context-Based Access Control feature of Cisco

IOS® Firewall software. The integration of ZBFW in the CSR1000V makes it a cost-effective virtual device. Instead

of addressing a specific interface, ZBFW works with the security zones—where router interfaces, or in this case,

tunnel interfaces, can be assigned to various security zones. Thus, traffic is controlled between zones as compared

to interfaces.


While AWS offers Network ACL (which is stateless) and Security Group (which is distributed), enabling security on

the CSR1000V centralizes security management.

Configuring a zone-based firewall can get complex, depending on what type of scenarios you want to implement

and the type of traffic you want to police (Figure 35). The procedures highlighted here support a basic configuration

and are a good starting point for more complex configurations. Once you complete this procedure, you will have a

basic foundation upon which you can build.

Figure 35. Zone-based firewall use case

This particular ZBFW deployment consists of an additional spoke VPC, which is the DMZ that was not created in

our earlier deployment. The overall concept is the same. You start by creating another spoke VPC and connecting

it to the transit VPC, or you can use an existing spoke VPC as the DMZ.

This use case scenario consists of four zones:

● PUBLIC

● DMZ

● PRIVATE1

● PRIVATE2

Communications between any two different zones is unidirectional. The dotted arrow in Figure 35 represents who

is initiating the traffic and where the traffic is going, as well as what type of traffic is allowed.

The zones and the interfaces to which they belong are color-coded as well. Refer to the topology in Figure 35 for

further details.


Procedure 1: Create security zones for interfaces

The first step to creating security zones is to define the various zones. How many you need will depend on your

use case scenario. In this use case, we define four zones: PRIVATE1, PRIVATE2, PUBLIC, and DMZ. Once the

zones are defined, they need to be configured in the two CSR1000Vs.

Step 1: Configure the zones. Use the following commands to create the zones in both the CSR1000Vs:

zone security DMZ

zone security PUBLIC

zone security PRIVATE1

zone security PRIVATE2

Step 2: Verify the zones using this command:

show zone security

Procedure 2. Assign interfaces to security zones

Once a zone is defined in the CSR1000Vs, you can assign interfaces to it. An interface is assigned to a zone using

interface configuration mode.

Tech tip

Keep in mind that once you assign an interface to a particular zone, all traffic will be dropped unless the interface is in the same zone it is passing traffic to.

Tech tip

Group together interfaces that are similar when they are viewed from a security perspective.

Tech tip

Zones may not span interfaces in different VPN routing and Virtual Route Forwarding (VRF) instances.

Step 1: Enter interface mode using this command:

Interface gigabitEthernet1

Step 2: Configure the interface to be a member of a zone:

zone-member security DMZ

Step 3: Repeat steps 1 and 2 for each interface you want to assign to a zone. Refer to Table 1 for which interface

to assign to which zone.

Table 1. Security zone assignments

Security zones Interfaces

DMZ (DMZ spoke) Tunnel5

Tunnel6

PUBLIC GigabitEthernet1

PRIVATE1 (Spoke A) Tunnel1

Tunnel2

PRIVATE2 (Spoke B) Tunnel3

Tunnel4


Note

Remember to configure both CSR1000Vs.

Procedure 3. Create zone pairs

A zone pair allows you to specify a unidirectional firewall between two security zones. By default, communication

between zones is denied. If you want communication to pass between zones, you need to create zone pairs. Each

zone pair defines a traffic flow between two zones. Table 2 shows the zone pairs for this use case.

Table 2. Zone pairs

Source Destination Allow traffic

PRIVATE1 DMZ HTTP, ICMP, SSH

PUBLIC DMZ WWW

PRIVATE1 PUBLIC HTTP, ICMP

PRIVATE2 PUBLIC HTTP, ICMP

PRIVATE1 PRIVATE2 IP

PRIVATE2 PRIVATE1 IP

Step 1: Create a zone pair. Use this command in global configuration mode:

zone-pair security PRIVATE1_TO_DMZ source PRIVATE1 destination DMZ

Step 2: Repeat step 1 to create the rest of the zone pairs shown in Table 2.

Step 3: Verify the zone pairs:

show zone-pair security

Procedure 4. Define class-maps to match traffic

To allow or deny traffic between zones, you first need to identify it. You can do this using class maps to define a set

of rules that apply to communication between different zones. For this guide, use the following rule sets:

● PRIVATE1 to DMZ: match WWW, ICMP, and SSH traffic

● PUBLIC to DMZ: match WWW, ICMP

● PRIVATE1 to PUBLIC: match WWW, ICMP

● PRIVATE2 to PUBLIC: match WWW, ICMP

● PRIVATE1 to PRIVATE2: match all

● PRIVATE2 to PRIVATE1: match all

Begin by creating an extended access list and class map for PRIVATE1 to DMZ.

Step 1: Create an extended access list. This list specifies which traffic you want to pass.

ip access-list extended PRIVATE1_TO_DMZ_ACL

permit tcp 10.255.16.0 0.0.15.255 10.255.0.0 0.0.15.255 eq www

permit tcp 10.255.16.0 0.0.15.255 10.255.0.0 0.0.15.255 eq 22

permit icmp 10.255.16.0 0.0.15.255 10.255.0.0 0.0.15.255

Step 2: Create a class map. This map will match any traffic that is listed on the access list you just created.

class-map type inspect match-any PRIVATE1_TO_DMZ_CMAP

match access-group name PRIVATE1_TO_DMZ_ACL


Step 3: Repeat steps 1 and 2 to create an extended access list and class map for the following zone pairs.

Note

Remember to configure both CSR1000Vs.

Zone pair PUBLIC_TO_DMZ

ip access-list extended PUBLIC_TO_DMZ_ACL

permit tcp any 10.255.0.0 0.0.15.255 eq www

class-map type inspect match-any PUBLIC_TO_DMZ_CMAP

match access-group name PRIVATE1_TO_DMZ_ACL

Zone pair PRIVATE1_TO_PUBLIC

ip access-list extended PRIVATE1_TO_PUBLIC_ACL

permit tcp 10.255.16.0 0.0.15.255 any eq www

permit icmp 10.255.16.0 0.0.15.255 any

class-map type inspect match-any PRIVATE1_TO_PUBLIC_CMAP

match access-group name PRIVATE1_TO_PUBLIC_ACL


ip access-list extended PRIVATE2_TO_PUBLIC_ACL

permit tcp 10.255.32.0 0.0.15.255 any eq www

permit icmp 10.255.32.0 0.0.15.255 any

class-map type inspect match-any PRIVATE2_TO_PUBLIC_CMAP

match access-group name PRIVATE1_TO_PUBLIC_ACL

Zone pair PRIVATE1_TO_PRIVATE2

ip access-list extended PRIVATE1_TO_PRIVATE2_ACL

permit ip any any

class-map type inspect match-any PRIVATE1_TO_PRIVATE2_CMAP

match access-group name PRIVATE1_TO_PRIVATE2_ACL


ip access-list extended PRIVATE2_TO_PRIVATE1_ACL

permit ip any any

class-map type inspect match-any PRIVATE2_TO_PRIVATE1_CMAP

match access-group name PRIVATE2_TO_PRIVATE1_ACL

Procedure 5. Define policy maps to associate actions to traffic

Once we classify traffic, we can apply a policy that will take an action, such as either pass or drop the traffic. This is

accomplished through policy maps.


Step 1: Create the policy map in global configuration mode:

policy-map type inspect PRIVATE1_TO_DMZ_PMAP

class type inspect PRIVATE1_TO_DMZ_CMAP

inspect

class class-default

drop

Step 2: Repeat step 1 to create additional policy maps for the following zone pairs:

Zone pair PUBLIC_TO_ DMZ

policy-map type inspect PUBLIC_TO_DMZ_PMAP

class type inspect PUBLIC_TO_DMZ_CMAP

inspect

class class-default

drop


policy-map type inspect PRIVATE1_TO_PUBLIC_PMAP

class type inspect PRIVATE1_TO_PUBLIC_CMAP

inspect

class class-default

drop


policy-map type inspect PRIVATE2_TO_PUBLIC_PMAP

class type inspect PRIVATE2_TO_PUBLIC_CMAP

inspect

class class-default

drop


policy-map type inspect PRIVATE1_TO_PRIVATE2_PMAP

class type inspect PRIVATE1_TO_PRIVATE2_CMAP

inspect

class class-default

drop


policy-map type inspect PRIVATE2_TO_PRIVATE1_PMAP

class type inspect PRIVATE2_TO_PRIVATE1_CMAP

inspect

class class-default

drop


Procedure 6. Attach policy-maps to zone pairs

This final procedure associates the policy maps to the zone pairs.

Step 1: Associate policy maps to zone pairs in global configuration mode:

zone-pair security PRIVATE1_TO_DMZ source PRIVATE1 destination DMZ

service-policy type inspect PRIVATE1_TO_DMZ_PMAP

Step 2: Repeat step 1 for the following zone pairs:

Zone pair PUBLIC_TO_DMZ

zone-pair security PUBLIC_TO_DMZ source PUBLIC destination DMZ

service-policy type inspect PUBLIC_TO_DMZ_PMAP


zone-pair security PRIVATE1_TO_PUBLIC source PRIVATE1 destination PUBLIC

service-policy type inspect PRIVATE1_TO_PUBLIC_PMAP

Zone pair PRIVATE2 _TO_PUBLIC

zone-pair security PRIVATE2_TO_PUBLIC source PRIVATE2 destination PUBLIC

service-policy type inspect PRIVATE2_TO_PUBLIC_PMAP


zone-pair security PRIVATE1_TO_PRIVATE2 source PRIVATE1 destination PRIVATE2

service-policy type inspect PRIVATE1_TO_PRIVATE2_PMAP


zone-pair security PRIVATE2_TO_PRIVATE1 source PRIVATE2 destination PRIVATE1

service-policy type inspect PRIVATE2_TO_PRIVATE1_PMAP

At this point you should have a zone-based firewall configured on your transit VPC. This is only the basic setup.

However, it is a good starting point for expanding your own configurations to fit your specific use cases.

Additional resources

If you have further questions, please refer to the following additional resources:

● Cisco Cloud Services Router 1000V Series:

https://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-

series/index.html?dtid=osscdc000283

● Application Visibility and Control:

https://www.cisco.com/c/en/us/products/routers/avc-control.html

● Zone-based firewall:

https://www.cisco.com/c/en/us/products/security/ios-firewall/index.html?dtid=osscdc000283

● Amazon S3 template:


For a complete list of all of our design and deployment guides for the Cisco Multicloud Portfolio, including Cloud

Connect, visit https://www.cisco.com/go/clouddesignguides.

https://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html?dtid=osscdc000283

https://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html?dtid=osscdc000283

https://www.cisco.com/c/en/us/products/routers/avc-control.html

https://www.cisco.com/c/en/us/products/security/ios-firewall/index.html?dtid=osscdc000283


https://www.cisco.com/go/clouddesignguides


About Cisco design and deployment guides

Cisco Design and Deployment Guides consists of systems and/or solutions designed, tested, and documented to

facilitate faster, more reliable, and more predictable customer deployments. For more information visit:

https://www.cisco.com/go/designzone.

ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS

(COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED "AS IS," WITH ALL FAULTS. CISCO AND

ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF

MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING

FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS

SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES,

INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE

USE OR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF

THE POSSIBILITY OF SUCH DAMAGES.

THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARE SOLELY RESPONSIBLE FOR

THEIR APPLICATION OF THE DESIGNS. THE DESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER

PROFESSIONAL ADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULT THEIR

OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS. RESULTS MAY VARY DEPENDING

ON FACTORS NOT TESTED BY CISCO.

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx,

the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live,

Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting

To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified

Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo,

Cisco Unified Computing System (Cisco UCS), Cisco UCS B-Series Blade Servers, Cisco UCS C-Series Rack

Servers, Cisco UCS S-Series Storage Servers, Cisco UCS Manager, Cisco UCS Management Software, Cisco

Unified Fabric, Cisco Application Centric Infrastructure, Cisco Nexus 9000 Series, Cisco Nexus 7000 Series. Cisco

Prime Data Center Network Manager, Cisco NX-OS Software, Cisco MDS Series, Cisco Unity, Collaboration

Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive,

HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, LightStream, Linksys, MediaTone, MeetingPlace,

MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX,

PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way

to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco

Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website 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. (0809R)

© 2018 Cisco Systems, Inc. All rights reserved.

https://www.cisco.com/go/designzone


Printed in USA C07-740270-01 06/18

Date post:	22-Jun-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Cisco Multicloud Portfolio: Cloud Connect · In addition, by using the Cloud Services Router 1000V,...

Documents