This section contains the guidelines and limitations for Cisco Cloud APIC.

• Inter-site (VRF-to-VRF) traffic is not supported if one of the VRFs is present as an attachment in a different VRF group (hub network). For example, consider the following scenario:

  • VRF-1 is stretched across different sites (Azure and AWS). In the AWS site, VRF-1 is in VRF group 1.

  • VRF-2 is present in a different VRF group (VRF group 2).

  In this scenario, traffic from VRF-2 to VRF-1 across sites is not supported, since the contracts between the VRFs will be implicitly allowing traffic between different VRF groups as well. Traffic across different VRF groups (hub networks) is not supported.

• You cannot stretch more than one VRF between on-prem and the cloud while using inter-VRF route leaking in the CCRs (cloud routers). For example, in a situation where VRF1 with EPG1 is stretched and VRF2 with EPG2 is also stretched, EPG1 cannot have a contract with EPG2. However, you can have multiple VRFs in the cloud, sharing one or more contracts with one on-premises VRF.

• Set the BD subnet for on-premises sites as advertised externally to advertise to the CSR1kv on the cloud.

• The default AWS security group (SG) rules limit only permits 2 CCRs per region and only 2 regions can deploy CCRs (a total maximum of 4 CCRs). To deploy more CCRs, increase the AWS SG rule limit to 120 or more. We recommend increasing the rule limit to 500.

• When configuring an object for a tenant, first check for any stale cloud resources in AWS. A stale configuration might be present if it was not cleaned properly from the previous Cisco Cloud APIC instances that managed the account.

  Note	It takes some time for Cisco Cloud APIC to detect the stale cloud resources after adding the tenant account ID.

  To check for and clean up stale cloud resources:

  1. Click the Navigation menu > Application Management > Tenants. The Tenants summary table appears in the work pane with a list of tenants as rows in a summary table.

  2. Double click the tenant you are creating objects for. The Overview, Cloud Resources, Application Management, Statistics, and Event Analytics tabs appear.

  3. Click the Cloud Resources > Actions > View Stale Cloud Objects. The Stale Cloud Objects dialog box appears.

  4. If you see any stale objects, click to place a check mark in the Automatically Clean Up Stale Cloud Objects check box.

  5. Click Save. The Cisco Cloud APIC automatically cleans up stale cloud objects.

     Note	To disable the automatic cleanup, follow steps 1 - 4 and click the Automatically Clean Up Stale Cloud Objects check box to remove the check mark.

• Cisco Cloud APIC tries to manage the AWS resources that it created. It does not attempt to manage resources created by other applications, other than listing existing resources as inventory. At the same time, it is also expected that AWS IAM users in the AWS infra tenant account, and the other tenant accounts, do not disturb the resources that Cisco Cloud APIC creates. For this purpose, all resources Cisco Cloud APIC creates on AWS has at least one of these two tags:

  • AciDnTag

  • AciOwnerTag

  Cisco Cloud APIC must prevent AWS IAM users who have access to create, delete, or update EC2, or any other resources, from accessing or modifying the resources that Cisco Cloud APIC created and manages. Such restrictions should apply on both the infra tenant and other user tenant accounts. AWS account administrators should utilize the above two tags to prevent their unintentional access and modifications. For example, you can have an access policy like the following to prevent access to resources managed by Cloud APIC:

  {
    "Effect": "Deny",
    "Action": [
      "ec2:*"
    ],
    "Resource": "*",
    "Condition": {
      "StringLike": {"ec2:ResourceTag/AciDnTag": "*"}
    }
  }

• When configuring shared L3Out:

  • An on-premises L3Out and cloud EPGs cannot be in tenant common.

  • If an on-premises L3Out and a cloud EPG are in different tenants, define a contract in tenant common. The contract cannot be in the on-premises site or the cloud tenant.

  • Specify the CIDR for the cloud EPG in the on-premises L3Out external EPGs (l3extInstP).

  • When an on-premises L3Out has a contract with a cloud EPG in a different VRF, the VRF in which the cloud EPG resides cannot be stretched to the on-premises site and cannot have a contract with any other VRF in the on-premises site.

  • When configuring an external subnet in an on-premises external EPG:

    • Specify the external subnet as a non-zero subnet.

    • The external subnet cannot overlap with another external subnet.

    • Mark the external subnet with a shared route-control flag to have a contract with a cloud EPG.

  • The external subnet that is marked in the on-premises external EPG should have been learned through the routing protocol in the L3Out or created as a static route.

• When mapping availability zones, choose only a or b in Cisco Cloud APIC. Internally, the zone-mapping function maps this to actual availability zones in AWS.

  Note	The mapping works in alphabetical order. The availability zones are sorted alphabetically and then the function picks the first two and associates them to a zone a and b in Cisco Cloud APIC.

• Configuring ASN 64512 for cloud routers causes BGP sessions to not work between cloud routers and AWS virtual private gateways.

• For the total supported scale, see the following Scale Supported table:

  Note	With the scale that is specified in the Scale Supported table: You can have only 4 total managed regions. You can have only CCRs in 2 regions, 2 * 2 CCRs. This is irrespective of AWS SG rule limit.

The Cisco Cloud APIC GUI is categorized into groups of related windows. Each window enables you to access and manage a particular component. You move between the windows using the Navigation menu that is located on the left side of the GUI. When you hover your mouse over any part of the menu, the following list of tab names appear: Dashboard, Topology, Application Management, Cloud Resources, Operations, Infrastructure, and Administrative.

Each tab contains a different list of subtabs, and each subtab provides access to a different component-specific window. For example, to view the tenant-specific window, hover your mouse over the Navigation menu and click Application Management > Tenants. From there, you can use the Navigation menu to view the details of another component. For example, you can navigate to the Availability Zones window from Tenants by clicking Cloud Resources > Availability Zones.

The Intent menu bar icon enables you to create a component from anywhere in the GUI. For example, to create a tenant while viewing the Availability Zones window, click the Intent icon. A dialog appears with a search box and a drop-down list. When you click the drop-down list and choose Application Management, a list of options, including the Tenant option, appears. When you click the Tenant option, the Create Tenant dialog appears displaying a group of fields that are required for creating the tenant.

For more information about the GUI icons, see Understanding the Cisco Cloud APIC GUI Icons

For more information about configuring Cisco Cloud APIC components, see Configuring Cisco Cloud APIC Components