Cisco Multicloud Portfolio: Cloud Connect

Transcription

1 Design and Deployment Guide Cisco Multicloud Portfolio: Cloud Connect AWS Transit VPC with Cisco Cloud Services Router 1000V June Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 1 of 34

2 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 Procedure 3. Modify security group to allow access to CSR1000Vs Create spoke VPC Procedure 1. Create the VPC Procedure 2. Create a virtual private gateway Procedure 3. Attach the VGW to the spoke VPC Connect the spoke VPC to the transit VPC Procedure 1. Add tag name to spoke VPC Procedure 2. Verify connectivity from spoke VPC to transit VPC Procedure 3. Confirming the VPC is using the VGW to route traffic Implementing application visibility and control Procedure 1. Enable AVC and web GUI on the CSR1000V Procedure 2. Open web ports on the security group Procedure 3. Access the CSR1000V web GUI Implementing a zone-based firewall Procedure 1: Create security zones for interfaces Procedure 2. Assign interfaces to security zones Procedure 3. Create zone pairs Procedure 4. Define class-maps to match traffic Procedure 5. Define policy maps to associate actions to traffic Procedure 6. Attach policy-maps to zone pairs Additional resources Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 2 of 34

3 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 3 of 34

4 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 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 4 of 34

5 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) Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 5 of 34

6 Application Visibility and Control The AVC feature leverages multiple technologies to recognize, analyze, and control over 1000 applications, including voice and video, , 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 6 of 34

7 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 7 of 34

8 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 8 of 34

9 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 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 9 of 34

10 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 10 of 34

11 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 11 of 34

12 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 12 of 34

13 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 13 of 34

14 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 14 of 34

15 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 15 of 34

16 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 16 of 34

17 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) Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 17 of 34

18 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 18 of 34

19 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 19 of 34

20 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) Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 20 of 34

21 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 21 of 34

22 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 22 of 34

23 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 23 of 34

24 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 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 24 of 34

25 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 25 of 34

26 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 26 of 34

27 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 27 of 34

28 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 DMZ (DMZ spoke) PUBLIC PRIVATE1 (Spoke A) PRIVATE2 (Spoke B) Interfaces Tunnel5 Tunnel6 GigabitEthernet1 Tunnel1 Tunnel2 Tunnel3 Tunnel Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 28 of 34

29 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 eq www permit tcp eq 22 permit icmp 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 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 29 of 34

30 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 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 any eq www permit icmp any class-map type inspect match-any PRIVATE1_TO_PUBLIC_CMAP match access-group name PRIVATE1_TO_PUBLIC_ACL Zone pair PRIVATE2_TO_PUBLIC ip access-list extended PRIVATE2_TO_PUBLIC_ACL permit tcp any eq www permit icmp 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 Zone pair PRIVATE2_TO_PRIVATE1 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 30 of 34

31 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 Zone pair PRIVATE1_TO_PUBLIC policy-map type inspect PRIVATE1_TO_PUBLIC_PMAP class type inspect PRIVATE1_TO_PUBLIC_CMAP inspect class class-default drop Zone pair PRIVATE2_TO_PUBLIC policy-map type inspect PRIVATE2_TO_PUBLIC_PMAP class type inspect PRIVATE2_TO_PUBLIC_CMAP inspect class class-default drop Zone pair PRIVATE1_TO_PRIVATE2 policy-map type inspect PRIVATE1_TO_PRIVATE2_PMAP class type inspect PRIVATE1_TO_PRIVATE2_CMAP inspect class class-default drop Zone pair PRIVATE2_TO_PRIVATE1 policy-map type inspect PRIVATE2_TO_PRIVATE1_PMAP class type inspect PRIVATE2_TO_PRIVATE1_CMAP inspect class class-default drop 2018 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 31 of 34

32 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 PRIVATE1_TO_PUBLIC 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 PRIVATE1_TO_PRIVATE2 zone-pair security PRIVATE1_TO_PRIVATE2 source PRIVATE1 destination PRIVATE2 service-policy type inspect PRIVATE1_TO_PRIVATE2_PMAP Zone pair PRIVATE2_TO_PRIVATE1 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: Application Visibility and Control: Zone-based firewall: Amazon S3 template: For a complete list of all of our design and deployment guides for the Cisco Multicloud Portfolio, including Cloud Connect, visit Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 32 of 34

33 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: 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 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 33 of 34

34 Printed in USA C / Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. Page 34 of 34