Deploying the Cisco Cloud Network Controller in AWS
Before you begin
-
Verify that you have met the requirements that are outlined in Requirements for Extending the Cisco ACI Fabric to the Public Cloud before proceeding with the tasks in this section. For example, verify that you have the correct number of elastic IP addresses and that you have checked the limits allowed to deploy the instances.
-
Verify that you have the full Administrator Access on AWS, because specific AWS IAM roles and permissions are required for the installation and operation of the Cisco Cloud Network Controller .
When installing Cisco Cloud Network Controller using the CloudFormation template (CFT), we recommend installation by a user who has the full Administrator Access on AWS (for example, by a user who has the permission policy ARN arn:aws:iam::aws:policy/AdministratorAccess attached to it, either directly, by using a role policy, or with a user group). However, if there is no one with AWS Administrator Access available, the person installing Cisco Cloud Network Controller must have a minimum set of permissions. See AWS IAM Roles and Permissions for more information on these AWS IAM roles and permissions.
-
If you are using AWS Organizations to control access policies and permissions for various accounts and you want to use Cisco Cloud Network Controller to manage these accounts, verify that the AWS account where you are deploying the Cisco Cloud Network Controller in these procedures (the Cisco Cloud Network Controller infra tenant) is the master account for that AWS organization. When the Cisco Cloud Network Controller is deployed in the master account for an AWS organization, you can add any AWS accounts that are part of the organization as tenants through the Cisco Cloud Network Controller GUI. See Support for AWS Organizations and Organization User Tenant and Configuring a Shared Tenant for more information.
-
If you are deploying Cisco Cloud Network Controller on AWS GovCloud, review the information provided in the section "AWS GovCloud Support" in Extending the Cisco ACI Fabric to the Public Cloud for information specific to those deployments.
Procedure
Step 1 |
Log into your Amazon Web Services account for the Cisco Cloud Network Controller infra tenant and go to the AWS Management Console, if you are not there already: |
||
Step 2 |
In the upper right corner of the AWS Management Console screen, locate the area that shows a region, and choose the region in AWS that you want to have managed by Cisco Cloud Network Controller (where the Cisco Cloud Network Controller AMI image will be brought up). |
||
Step 3 |
Create an Amazon EC2 SSH key pair: |
||
Step 4 |
Go to the Cisco Cloud Network Controller page on the AWS Marketplace: |
||
Step 5 |
Click Subscribe. |
||
Step 6 |
Review and accept the End User License Agreement (EULA) by clicking the Accept Terms button. |
||
Step 7 |
After a minute, you should see the message Subscription should be processed. Click the Continue to Configuration button. The Configure this software page appears. |
||
Step 8 |
Select the following parameters:
|
||
Step 9 |
Click the Continue to Launch button. The Launch this software page appears, which shows a summary of your configuration and lets you launch the cloud formation template. |
||
Step 10 |
Click Launch to go directly to the CloudFormation service in the correct region, with the correct Amazon S3 template URL already populated. |
||
Step 11 |
Click Next at the bottom of the screen. The Specify Details page appears within the Create stack page. |
||
Step 12 |
Enter the following information on the Specify Details page.
|
||
Step 13 |
Click Next at the bottom of the screen. The Options page appears within the Create stack page. |
||
Step 14 |
Accept all the default values in the Options screen. There is a Permissions: IAM Role area on this page. An IAM role is an IAM entity that defines a set of permissions for making Amazon Web Services service requests. You can use roles to delegate access to users, applications, or services that don't normally have access to your Amazon Web Services resources. There is no need for IAM role information with regards to the Cisco Cloud Network Controller, but if you want to assign an IAM role for another reason, choose the appropriate role in the IAM Role field. |
||
Step 15 |
Click Next at the bottom of the Options screen. The Review page appears within the Create stack page. |
||
Step 16 |
Verify that all the information on the Review page is correct. If you see any errors on the Review page, click the Previous button to go back to the page with the incorrect information. |
||
Step 17 |
When you have verified that all the information on the Review page is correct, check the box next to the I acknowledge that AWS CloudFormation might create IAM resources with custom names area. |
||
Step 18 |
Click the Create button at the bottom of the page. The CloudFormation page reappears, and the Cisco Cloud Network Controller template that you created is displayed with the text CREATE_IN_PROGRESS displayed in the Status column. The system now uses the information that you provided in the template to create the Cisco Cloud Network Controller instance. This process takes 5-10 minutes to complete. You can monitor the progress of the creation process by checking the box next to the name of your Cisco Cloud Network Controller template, then clicking on the Events tab. The text CREATE_IN_PROGRESS is displayed in the Status column under the Events tab. |
||
Step 19 |
When the CREATE_COMPLETE message is shown, verify that the instance is ready before proceeding. |
What to do next
Go to Setting Up the AWS Account for the User Tenant to set up the AWS account for the user tenant.
Resolving Subnet Conflict Issue With Infra Subnet
In some situations, you might encounter an issue with a subnet conflict with your Cisco Cloud Network Controller . This issue might occur when the following conditions are met:
-
Your Cisco Cloud Network Controller is running on release 25.0(2)
-
The infra VPC subnet for your Cisco Cloud Network Controller is configured within the 172.17.0.0/16 CIDR (for example, if you entered
172.17.10.0/24
in the Infra VPC Pool field as part of the procedures in Deploying the Cisco Cloud Network Controller in AWS) -
There is something else configured that overlaps with the 172.17.0.0/16 CIDR that you are using for the infra VPC subnet for your Cisco Cloud Network Controller (for example, if the Docker bridge IP subnet is configured with
172.17.0.0/16
, which is the default subnet in Cisco Cloud Network Controller ).
In this situation, your Cisco Cloud Network Controller might not be able to reach the CCR private IP address due to this subnet conflict and the Cisco Cloud Network Controller will raise an SSH connectivity fault for the affected CCR.
You could determine if there might be a possible conflict by logging in as root into the Cisco Cloud Network Controller and
entering the route -n
command:
[root@ACI-Cloud-Fabric-1 ~]# route -n
Assume that you see output similar to the following:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
In this example output, the highlighted text shows that a Docker bridge is configured with 172.17.0.0/16
.
Because this overlaps with the 172.17.0.0/16 CIDR that you used for the infra VPC subnet for your Cisco Cloud Network Controller, you might see an issue where you lose connectivity to the CCR, where you are not able to SSH into the CCR, and you see a Host Unreachable message when you try to ping the CCR (such as in the following example, where 172.17.0.84 is the private IP address of the CCR):
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
From 172.17.0.1 icmp_seq=1 Destination Host Unreachable
From 172.17.0.1 icmp_seq=2 Destination Host Unreachable
From 172.17.0.1 icmp_seq=3 Destination Host Unreachable
From 172.17.0.1 icmp_seq=5 Destination Host Unreachable
From 172.17.0.1 icmp_seq=6 Destination Host Unreachable
^C
--- 172.17.0.84 ping statistics ---
9 packets transmitted, 0 received, +5 errors, 100% packet loss, time 8225ms
pipe 4
[root@ACI-Cloud-Fabric-1 ~]#
To resolve the conflict in this situation, enter a REST API post similar to the following to change the IP address for the other area that is causing the conflict:
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="<new-IP-address>" />
</apPluginPolContr>
For example, to move the Docker bridge IP address out from under the 172.17.0.0/16 CIDR, which was shown in the example scenario above, you might enter a REST API post such as the following:
https://{{apic}}/api/plgnhandler/mo/.xml
<apPluginPolContr>
<apContainerPol containerBip="172.19.0.1/16" />
</apPluginPolContr>
where 172.19.0.1/16
is the new subnet for the Docker bridge. This moves the Docker bridge IP address under the 172.19.0.0/16 CIDR, where there
is no longer a conflict with the infra VPC subnet for your Cisco Cloud Network Controller that is configured within the 172.17.0.0/16
CIDR.
You can use the same commands as before to verify that there is no longer a conflict:
[root@ACI-Cloud-Fabric-1 ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.17.0.17 0.0.0.0 UG 16 0 0 oobmgmt
169.254.169.0 0.0.0.0 255.255.255.0 U 0 0 0 bond0
169.254.254.0 0.0.0.0 255.255.255.0 U 0 0 0 lxcbr0
172.17.0.12 0.0.0.0 255.255.255.252 U 0 0 0 bond0
172.17.0.16 0.0.0.0 255.255.255.240 U 0 0 0 oobmgmt
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
In this example output, the highlighted text shows that a Docker bridge is configured with the IP address 172.19.0.0
. Because there is no overlap with the 172.17.0.0/16 CIDR that you are using for the infra VPC subnet for your Cisco Cloud
Network Controller, there is no issue with connectivity with the CCR:
[root@ACI-Cloud-Fabric-1 ~]# ping 172.17.0.84
PING 172.17.0.84 (172.17.0.84) 56(84) bytes of data.
64 bytes from 172.17.0.84: icmp_seq=1 ttl=255 time=1.15 ms
64 bytes from 172.17.0.84: icmp_seq=2 ttl=255 time=1.01 ms
64 bytes from 172.17.0.84: icmp_seq=3 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=4 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=5 ttl=255 time=1.09 ms
64 bytes from 172.17.0.84: icmp_seq=6 ttl=255 time=1.06 ms
64 bytes from 172.17.0.84: icmp_seq=7 ttl=255 time=1.03 ms
64 bytes from 172.17.0.84: icmp_seq=8 ttl=255 time=1.05 ms
^C
--- 172.17.0.84 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7005ms
rtt min/avg/max/mdev = 1.014/1.061/1.153/0.046 ms
[root@ACI-Cloud-Fabric-1 ~]#