• Routing & Security: The default access policy. If you do not assign an access policy to the Cisco Cloud APIC, then the Cisco Cloud APIC has the Routing and Security access policy applied to it by default.

  Assigning a Routing and Security access policy to a Cisco Cloud APIC means that it has full permissions, where it is able to control routing and security.

• Routing Only: Assigning a routing-only access policy to a Cisco Cloud APIC means that it can control only the routing policy and the network connectivity.

The current access policy setting for the account/tenant is displayed in the following format:

<inherit setting> (<current access policy>)

For example, if you see this in the Cloud Access Privilege for a tenant:

Inherited (Routing & Security)

That means:

• The access policy for this account/tenant is set to the Routing & Security access policy

• This access policy was inherited from the parent level (in this case, the global, or Cisco Cloud APIC level), which was also set to the Routing & Security access policy

• Routing & Security: Assigning a Routing & Security access policy to an account/tenant means that it has full permissions, where it is able to control routing and security.

• Routing Only: Assigning a routing-only access policy to an account/tenant means that it can control only the routing policy and the network connectivity.

• Read Only: The existing access policy that was available prior to release 25.0(4). Assigning a read-only access policy to an account/tenant means that it does not have write permissions and can only read the inventory.

Keep in mind that the access policies available to you at the account/tenant level are based on the access policy that was assigned at the parent level (in this case, at the global level). For example, if the access policy at the parent global level is set to Routing Only, then you will only see Routing Only and Read Only as options at the child account/tenant level because the access policy at the child level cannot be more restrictive than the access policy at the parent level. See Updates to Access Policies in Release 25.0(4) for more information.

The current access policy setting for the cloud context profile is displayed in the following format:

<inherit setting> (<current access policy>)

For example, if you see this in the Cloud Access Privilege for a cloud context profile:

Inherited (Routing & Security)

That means:

• The access policy for this cloud context profile is set to the Routing & Security access policy

• This access policy was inherited from the parent level (in this case, the account/tenant level), which was also set to the Routing & Security access policy

• Routing & Security: Assigning a Routing & Security access policy to a cloud context profile means that it has full permissions, where it is able to control routing and security.

• Routing-Only: Assigning a routing-only access policy to a cloud context profile means that it can control only the routing policy and the network connectivity.

• Read-Only: Assigning a read-only access policy to a cloud context profile means that it does not have write permissions and can only read the inventory.

Keep in mind that the access policies available to you at the VPC (cloud context profile) level are based on the access policy that was assigned at the parent level (in this case, at the account/tenant level). For example, if the access policy at the parent account/tenant level is set to Read Only, then you will only see Read Only as an option at the child VPC (cloud context profile) level because the access policy at the child level cannot be more restrictive than the access policy at the parent level. See Updates to Access Policies in Release 25.0(4) for more information.

The CIDRs and subnets associated with this cloud context profile are displayed.

The current setting for the access policy for the subnet is displayed in the following format:

<inherit setting> (<current access policy>)

For example, if you see this in the Cloud Access Privilege column for a subnet:

Inherited (Routing & Security)

That means:

• The access policy for this subnet is set to the Routing & Security access policy

• This access policy was inherited from the parent level (in this case, the VPC, or cloud context profile, level), which was also set to the Routing & Security access policy

• Routing & Security: Assigning a Routing & Security access policy to a cloud context profile means that it has full permissions, where it is able to control routing and security.

• Routing Only: Assigning a routing-only access policy to a cloud context profile means that it can control only the routing policy and the network connectivity.

• Read Only: Assigning a read-only access policy to a cloud context profile means that it does not have write permissions and can only read the inventory.

Keep in mind that the access policies available to you at the subnet level are based on the access policy that was assigned at the parent level (in this case, at the VPC level). For example, if the access policy at the parent VPC level is set to Read Only, then you will only see Read Only as an option at the child subnet level because the access policy at the child level cannot be more restrictive than the access policy at the parent level. See Updates to Access Policies in Release 25.0(4) for more information.

<polUni>
    <cloudDomP>
        <cloudRsDomPToAccessPolicy tDn="uni/tn-infra/accesspolicy-routing-only" />
    </cloudDomP>
</polUni>

<polUni>
    <fvTenant name="pepsi" status="">
        <cloudAwsProvider accountId="<account-id>" accessKeyId="<key-id>" 
secretAccessKey="<access-key>" shareableAcrossTenant="yes" providerId="aws" status="">
              <cloudRsProviderToAccessPolicy tDn="uni/tn-infra/accesspolicy-read-only" />
        </cloudAwsProvider>
    </fvTenant>
</polUni>

<polUni>
    <fvTenant name=”pepsi”>
        <cloudCtxProfile name="c3" status="">
            <cloudRsCtxProfileToAccessPolicy tDn="uni/tn-infra/accesspolicy-default"/>
            <cloudBrownfield status="">
                <cloudIDMapping cloudProviderId="vpc-0123456789abcd" status=""/>
            </cloudBrownfield>
            <cloudCidr name="cidr1" addr="40.0.0.0/16" primary="yes" >
                <cloudSubnet ip="40.0.1.0/24" usage="gateway">
                    <cloudRsSubnetToAccessPolicy tDn="uni/tn-infra/accesspolicy-routing-only"/>
                    <cloudBrownfield status="">
                        <cloudIDMapping cloudProviderId="subnet-0123456789abcd" status=""/>
                    </cloudBrownfield>
                </cloudSubnet>
                <cloudSubnet ip="40.0.2.0/24" usage="gateway">
                    <cloudRsSubnetToAccessPolicy tDn="uni/tn-infra/accesspolicy-read-only"/>
                    <cloudBrownfield status="">
                        <cloudIDMapping cloudProviderId="subnet-dcba987654321" status=""/>
                    </cloudBrownfield>
                </cloudSubnet>
            </cloudCidr>
        </cloudCtxProfile>
    </fvTenant>
</polUni>

If the unmanaged (brownfield) VPC is in a different AWS account, then you must create a new tenant.

For instructions on creating a new tenant, see "Configuring a Tenant AWS Provider For Release 4.2(3) and Later" in the Cisco Cloud APIC for AWS User Guide, Release 25.0(x) or later.

Note that this tenant should use the same AWS account as the unmanaged (brownfield) VPC in AWS.

A slide-in pane appears from the right of the window, asking What would you like to do?.

A setup wizard for creating an unmanaged cloud context profile appears.

The Select Brownfield VPC window appears, with a list of all available brownfield VPCs (VPCs that are not managed by Cisco Cloud APIC) that are available in AWS under the AWS account where you created the tenant. The list of VPCs that is populated in this window is based on the inventory pull on this AWS account.

In this window in the Cisco Cloud APIC GUI, the unmanaged VPCs in this list are shown with this format in the Cloud Provider ID column:

VPC_ID

AWS > {tenant} > {AWS_region}

And the name of the brownfield VPC in the Name column in the Cisco Cloud APIC GUI page.

Go to the Amazon VPC console at https://console.aws.amazon.com/vpc/ and locate the unmanaged VPC in the AWS page, then locate the Name and VPC ID fields for this brownfield VPC to verify that the information matches with the information displayed in the Cisco Cloud APIC GUI page.

The right pane in the window is populated with additional information about this unmanaged VPC.

You are returned to the main Import Brownfield VPC window.

Once an unmanaged VPC is selected from the list to import, the corresponding tenant is automatically populated in this field. This unmanaged cloud context profile will be created under this tenant.

Beginning with release 25.0(4), additional access policies are available at the VPC (cloud context profile) level. The access policy is set to Inherit by default, unless you explicity change the access policy at this level. See Updates to Access Policies in Release 25.0(4) for more information.

The current access policy setting for the cloud context profile is displayed in the following format:

<inherit setting> (<current access policy>)

For example, if you see this in the Cloud Access Privilege for a cloud context profile:

Inherited (Routing & Security)

That means:

• The access policy for this cloud context profile is set to the Routing & Security access policy

• This access policy was inherited from the parent level (in this case, the account/tenant level), which was also set to the Routing & Security access policy

• Routing & Security: The default access policy. If you do not assign an access policy to at the VPC level, then the VPC has the Routing & Security access policy applied to it by default.

  Assigning a Routing & Security access policy to a VPC means that it has full permissions, where it is able to control routing and security.

• Routing Only: Assigning a routing-only access policy at the VPC level means that it can control only the routing policy and the network connectivity.

• Read Only: Assigning a read-only access policy at the VPC level means that it does not have write permissions and can only read the inventory.

Keep in mind that the access policies available to you at the VPC (cloud context profile) level are based on the access policy that was assigned at the parent level (in this case, at the account/tenant level). For example, if the access policy at the parent account/tenant level is set to Read Only, then you will only see Read Only as an option at the child VPC (cloud context profile) level because the access policy at the child level cannot be more restrictive than the access policy at the parent level. See Updates to Access Policies in Release 25.0(4) for more information.

Beginning with release 25.0(4), you can copy route tables that are associated with the subnets in the existing brownfield (unmanaged) VPC that you are importing. See About Route Table Copying for more information.

• If you do not want to copy any route tables that are associated with the subnets in the existing VPC that you are importing, in the Copy Existing Routing Tables from VPC area, click Do Not Copy Existing Routes, then go to Step 16.

• If you want to copy route tables that are associated with the subnets in the existing VPC that you are importing, in the Copy Existing Routing Tables from VPC area, click Copy Existing Routes.

  The Brownfield Route Tables fields appear. Follow the steps below to copy the existing route tables from the brownfield VPC.

The primary CIDR block range in the unmanaged VPC is imported automatically and is tagged as the primary CIDR.

If you are copying an existing route table from the brownfield VPC, select the necessary subnets that are associated with the route table that you are copying that you want to import. Make sure that all the desired subnets and their associated route tables are selected for import and copy in order to avoid traffic disruption.

Enabling this field allows you to select the hub network and the transit gateway route table association scope in the next steps. Based on the selections that you make in those steps, the route tables are created on the infra transit gateway. For more information, see the Increasing Bandwidth Between VPCs by Using AWS Transit Gateway or AWS Transit Gateway Connect document.

You should have created this hub network when you first set up AWS Transit Gateway or AWS Transit Gateway Connect. If you did not create a hub network yet, create the hub network using the procedures provided in Increasing Bandwidth Between VPCs by Using AWS Transit Gateway or AWS Transit Gateway Connect.

The following choices are based on the change beginning with release 25.0(2), where the transit gateway route tables are deployed per VRF by default when configuring AWS Transit Gateway. As part of this change, label-based deployments for transit gateway route tables are also available, where, for each new label, a new transit gateway route table that is named after the label will be deployed. For more information, see the "Transit Gateway External Networking" section in the Increasing Bandwidth Between VPCs by Using AWS Transit Gateway or AWS Transit Gateway Connect document.

A What's Next page is displayed.

The details screen for the cloud context profile that you just created is displayed.

The following figure shows a configured unmanaged cloud context profile, with the Read Only flag enabled and the associated VPC ID.

A list of configure VRFs appears.

Verify that the VRF is associated with the imported brownfield VPC.

The areas below show the lines that are used when creating an unmanaged cloud context profile, where:

• The cloudRsCtxProfileToAccessPolicy line sets the cloud context profile to be read-only.

• The cloudBrownfield and cloudIDMapping lines are used to import a brownfield VPC, using the VPC ID of the brownfield VPC in the AWS cloud.

• The cloudRsCtxProfileToRegion line points to the region where the VPC exists in the AWS cloud.

• The cloudCidr lines are one or more CIDRs (one of which is the primary CIDR) that match the CIDRs in the AWS cloud.

POST https://<cloud-apic-ip-address>/api/mo/uni.xml
<fvTenant name=”unmanagedTenant1">
 <fvCtx name="vrf1" />
    <cloudCtxProfile name=”BrownfieldCtxProfile1">
        <cloudRsCtxProfileToAccessPolicy tDn="uni/tn-infra/accesspolicy-read-only"/>
        <cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-aws/region-us-west-1"/>
        <cloudRsToCtx tnFvCtxName="vrf1" />
        <cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default-foo" label="system=='vrf'"/>
        <cloudBrownfield status="">
            <cloudIDMapping cloudProviderId="vpc-0fe1afe17568417c8"/>
        </cloudBrownfield>
        <cloudCidr name="cidr1" addr="40.0.0.0/16" primary="yes" />
    </cloudCtxProfile>
</fvTenant>

The Intent menu appears.

A list of Application Management options appear in the Intent menu.

The Create EPG dialog box appears.

A list of Application Management options appear in the Intent menu.

A What's Next window is displayed.

The details window for the contract is displayed.

The EPG Communication Configuration window appears.

The Select Consumer EPGs window appears.

For example:

• If you had created epg1 previously for the greenfield EPG

• And you created epg2 for the brownfield EPG using the procedures in Creating an EPG Associated With the Brownfield Cloud Context Profile Using the GUI

Then you would select both epg1 (greenfield EPG) and epg2 (brownfield EPG) in the Select Consumer EPGs window.

You are returned to the EPG Communication Configuration window.

The Select Provider EPGs window appears.

Using the examples provided for the consumer EPGs step, you would select the same EPGs (the greenfield EPG epg1 and the brownfield EPG epg2) in the Select Provider EPGs window.

You are returned to the EPG Communication Configuration window.

You will be creating a cloud EPG to allow an on-premises site or another cloud site to be able to send or receive the traffic to this unmanaged brownfield VPC.

<fvTenant name=”unmanagedTenant1">
 <fvCtx name="vrf1" />
    <cloudCtxProfile name=”BrownfieldCtxProfile1">
        <cloudRsCtxProfileToAccessPolicy tDn="uni/tn-infra/accesspolicy-read-only"/>
        <cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-aws/region-us-west-1"/>
        <cloudRsToCtx tnFvCtxName="vrf1" />
        <cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default-foo" label="system=='vrf'"/>
        <cloudBrownfield status="">
            <cloudIDMapping cloudProviderId="vpc-0fe1afe17568417c8"/>
        </cloudBrownfield>
        <cloudCidr name="cidr1" addr="40.0.0.0/16" primary="yes" />
    </cloudCtxProfile>
</fvTenant>

Note that in this example, the EPG is associated with the brownfield cloud context profile through the VRF vrf1 as shown in the following post:

<fvTenant name=”unmanagedTenant1">
    <fvCtx name="vrf1" />
    <cloudApp name="ap3">
        <cloudEPg name="epg3">
            <cloudRsCloudEPgCtx tnFvCtxName="vrf1"/>
            <fvRsProv tnVzBrCPName="contract4"/>
            <cloudEPSelector name="EP_SEL1" matchExpression="IP=='40.0.0.0/24'" status=""/>
        </cloudEPg>
    </cloudApp>
</fvTenant>