• 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 VNet (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 VNet (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 VNet, 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 VNet level). For example, if the access policy at the parent VNet 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="coke" status="">
        <cloudAccount name="insbu" id="<id>" vendor="azure" accessType="credentials" status="">
            <cloudRsAccountToAccessPolicy tDn="uni/tn-infra/accesspolicy-routing-only"/>
        </cloudAccount>
    </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) VNet is in a different subscription, then you must create a new tenant.

The new tenant to be used with the brownfield VNet can have the following characteristics:

• It can be configured as a Read Only account, if you have an account (subscription) on the cloud that has only unmanaged VNets and you are never going to use Cisco Cloud APIC to manage any VNets in this subscription on Azure.

• An unmanaged tenant with Read Only access can be configured in either of these modes:

  • Managed identity mode

  • Service Principle mode

For instructions on creating a new tenant, see the following sections in the Cisco Cloud APIC for Azure User Guide, Release 5.2(x) or later:

• "Understanding Tenants, Identities, and Subscriptions"

• "Creating a Tenant Using the Cisco Cloud APIC GUI"

Note that this tenant should use the same Azure subscription ID as the unmanaged (brownfield) VNet in Azure.

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 Virtual Network window appears, with a list of all available brownfield VNets (VNets that are not managed by Cisco Cloud APIC) that are available in Azure under the subscription where you created the tenant. The list of VNets that is populated in this window is based on the inventory pull on this subscription.

In this window in the Cisco Cloud APIC GUI, the unmanaged VNets in this list are shown with this format:

AZURE > {Azure_subscription_ID} > {Azure_resource_group}

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

Return to the Azure portal and click on the unmanaged VNet in the Azure page, then locate the Resource Group, Subscription ID, and Name fields for this brownfield VNet 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 VNet.

You are returned to the main Import Brownfield Virtual Network window.

This unmanaged cloud context profile will be created under this tenant.

Enabling this VNet peering field allows the Cisco Cloud APIC to create the peering from the infra VNets to the unmanaged VNet on the cloud. For more information, see the "Support for VNet Peering Across Azure Active Directories" section in the Configuring VNet Peering for Cloud APIC for Azure document.

Beginning with release 25.0(4), additional access policies are available at the VNet (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 VNet level, then the VNet has the Routing & Security access policy applied to it by default.

  Assigning a Routing & Security access policy to a VNet 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 VNet level means that it can control only the routing policy and the network connectivity.

• Read Only: Assigning a read-only access policy at the VNet 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 VNet (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 VNet (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) VNet 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 VNet that you are importing, in the Copy Existing Routing Tables from VNet area, click Do Not Copy Existing Routes, then go to Step 17.

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

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

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

If you are copying an existing route table from the brownfield VNet, 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.

A What's Next page is displayed.

You are returned to the main Cloud Context Profiles page, with all the configured cloud context profiles listed.

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

A list of configure VRFs appears.

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

As described in About VNet Peering for Unmanaged (Brownfield) VNets, because only the first leg of the VNet peering was configured by Cisco Cloud APIC (from the infra VNet to the unmanaged VNet), but the other leg is not yet configured (from the unmanaged VNet to the infra VNet), the Peering status will show as initiated for this VNet peering, with the unmanaged (brownfield) VNet shown in the Peer column.

The text in bold shows the lines that are specific to creating an unmanaged cloud context profile, where:

• The cloudRsCtxProfileToAccessPolicy line sets the cloud context profile to be Read Only.

• The cloudBrownfield lines are used to import a brownfield VNet on the cloud with its cloud provider ID.

POST https://<cloud-apic-ip-address>/api/mo/uni.xml

<fvTenant name="tn15">
    <cloudCtxProfile name="cProfilewestus151" status="" azVirtualNetwork="vnet1" status=""> 
        <cloudRsCtxProfileToAccessPolicy tDn="uni/tn-infra/accesspolicy-read-only" status=""/>
        <cloudRsCtxProfileToRegion status="" tDn="uni/clouddomp/provp-azure/region-westus" status=""/>
        <cloudRsToCtx tnFvCtxName="ctx151"/> 
        <cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
        <cloudBrownfield status="">
            <cloudIDMapping cloudProviderId="/subscriptions/xxxxxxx-xxxx-xxxx-xxxxxx/resourceGroups/BrownfieldResGrp/providers/Microsoft.Network/virtualNetworks/VNET1" status=""/>
        </cloudBrownfield>
        <cloudCidr name="cidr1" addr="xx.10.0.0/16" primary="yes" status="" />
        <cloudCidr name="cidr2" addr="xx.50.0.0/16" primary="no" status="" />
    </cloudCtxProfile>
</fvTenant>

The Intent menu appears.

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

The Create EPG dialog box appears.

For more information, see How EPGs are Associated With Brownfield Cloud Context Profiles Through VRFs.

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

The EPG Communication Configuration window appears.

The Select Contract window appears.

You are returned to the EPG Communication Configuration window.

The Select Provider EPGs window appears.

You are returned to the EPG Communication Configuration window.

The Select Consumer EPGs window appears.

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 VNet.

<fvTenant name=”UnManagedTenant1">
    <fvCtx name=”VRF" />
    <cloudApp name=”UnManagedapp" status="">
        <cloudEPg name="Epg" status="">
            <cloudRsCloudEPgCtx tnFvCtxName="VRF" />
            <cloudEPSelector name="1" subnet=”20.0.0.0/24"/>
            <cloudEPSelector name="1" matchExpression="IP=='20.47.0.16/32'"/>
            <fvRsCons status="" tnVzBrCPName="http" />
            <fvRsCons tnVzBrCPName="contract_http_https_ssh" />
        </cloudEPg>
    </cloudApp>
</fvTenant>