New and Changed Information

The following table provides an overview of the significant changes to the organization and features in this guide from the release the guide was first published to the current release. The table does not provide an exhaustive list of all changes made to the guide.

Table 1. Latest Updates

Release

New Feature or Update

Where Documented

4.2(2e)

First release of this document.

--

Summary

Prior to the Cisco Cloud Network Controller (CCNC) 26.0(2) release, all subnets belonging to one Azure VNet logical construct were associated to a single route table. This implied that communication from endpoints connected to the subnets part of that VNet would always use the same routing policy (that is, the same route entry in the single route table).

CCNC 26.0(2) introduces the per subnet route table feature that allows you to create an Azure VNet with multiple subnets, where each subnet can map to its own route table, or you can group subnets to share a specific route table.

Figure 1.
Route Table Subnet Relation

From a configuration point of view, the support of per subnet route table requires the configuration of multiple VRF instances. The main VRF instance is still mapped to a region and allows you to create a VNet (modeled in CCNC with a Cloud Context Profile object) with the associated the CIDR prefix. Additional VRFs instances (named as "Secondary VRFs") are then associated to one or more subnets defined in the VNet, carved out from the CIDR, to implement the logical mapping between subnets and route tables shown in figure below.

Figure 2.
CCNC Schema to Support Per Subnet UDR.

Note

This document interchangeably uses "route table" and "Azure user-defined routing (UDR)."

This document shows how to use Cisco Nexus Dashboard Orchestrator (NDO) release 4.2(2) to drive the configuration of the per subnet route table functionality in one or more CCNC domains. The value proposition of this new functionality is highlighted by the use case described later in this chapter.

Variable Routing Policy Per Subnet

The benifit of this solution is to allow different routing treatments for different subnets in a VNet. It also opens the way for other useful features in the future. In the example below we see subnets belonging to the same VNet1 can have different routing policy based its own route table.

Figure 3.
Route Table Subnet Relation

  • subnet-1 cannot reach out to the internet.

  • While subnet-2 can connect to the internet directly.

  • Similarly, only subnet-3 and subnet-4 can reach out to the On-premises Data Center (DC).

Prerequisites

Before you follow the procedures described in this document, you must complete the following basic configuration tasks:

Creating Schema and Templates

Before you begin

The following guidelines apply when creating the schemas and templates using the Cisco Nexus Dashboard Orchestrator:

Procedure

Step 1

Log in to your Cisco Nexus Dashboard and open the Cisco Nexus Dashboard Orchestrator service.

Step 2

Create a new schema.

  1. From the left navigation pane, choose Configure > Tenant Templates.

  2. Under the Application tab, click Add Schema.

    Figure 4.
    Create Schemas.

  3. In the schema creation dialog, provide the Name and optional description for the schema and click Next.

    By default, the new schema is empty, so you must add one or more templates.

Step 3

In the schema page, click Create New Template.

  1. In the Select a Template type window, choose ACI Multi-Cloud and click Add.

  2. Click Next to continue adding the template details.

    Figure 5.
    Create Cloud Application Template.

  3. In the left sidebar, provide the Display Name for the template.

  4. (Optional) Provide a Description.

  5. From the Select a Tenant drop-down list, choose the tenant for this template.

    Note

     

    The user account you are using to create a new schema must be associated with the tenant that you will add to the schema, otherwise the tenant will not be available in the drop-down list. For more information on importing the tenant, see Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics.

  6. In the template view page, click Next.

    Save the template after this initial configuration for extra options (such as site association) to become available.

    Figure 6.
    Create Template.

    Note

     

    Leave the default Deployment Mode to the Multi-Site option, to stretch the template across mutiple sites.

  7. Click Continue to finish adding the template to the schema.

Step 4

The next step is to assign the template to sites.

Deploy fabric configuration by deploying one template at a time to one or more sites. You must associate the template with at least one site where you want to deploy the configuration.

  1. In the template view page, click Actions and choose Add/Remove Sites.

  2. In the Add/Remove Sites <template> dialog, select one or more Azure sites where you want to deploy the template and click Ok.

    Figure 7.
    Add Sites to the template.

Creating the VRF Instances

This section describes how to create the VRF instances.

Before you begin

Create the schema and template and assign a tenant to the template, for more information on importing the tenant, see Creating Schema and Templates.

Procedure

Step 1

Choose the schema and template where you want to create the VRF instance.

Step 2

Create the VRF instance.

  1. In the main pane, choose Create Object > VRF.

    Figure 8.

  2. In the properties pane, provide the Display Name for the VRF instance.

  3. (Optional) Provide a Description.

Figure 9.
Creating the VRF.

Step 3

(Optional) Add one or more Annotations.

This allows you to add arbitrary key:value pairs of metadata to an object as annotations (tagAnnotation). Annotations provide any customization that you may require, such as descriptions, markers for personal scripting or API calls, or flags for monitoring tools or orchestration applications such as your Cisco Nexus Dashboard Orchestrator. Cisco APIC ignores these annotations and merely stores them with other object data, Cisco APIC also does not impose any format nor content restrictions.

What to do next

For our example use Step 1 - Step 3, to create two more secondary VRF instances (hv1 and hv2) under the same template as the parent VRF instance. Secondary VRF instances associate with each individual subnet (or with a group of subnets) as described later in the example.

Figure 10.
Parent VRF with two hosted VRF

Configuring the VRF Instances

This section describes how to create a cloud context profile and configure the VRF instances.

Before you begin

Create the schema and template and assign a tenant to the template, for more information on importing the tenant, see Creating Schema and Templates.

Procedure

Step 1

Select the site local template for the Azure site choose the parent VRF from the list of objects.

  1. Click on the Add Region and Cloud Context Profile.

    Add Cloud Context Profile.

  2. In the Select Region drop-down list, choose the region on which this VRF instance will be deployed.

    Add Cloud Context Profile.

    Note

     

    Beginning with release 4.2(2), Cisco Nexus Dashboard Orchestrator users can configure multiple VNets within one VRF region.

  3. Click on the Add Cloud Context Profile and enter the following information.

    • Name—Enter the name for the cloud context profile, then click on Add CIDRs.
      Figure 11.

    • CIDR—Enter the VPC/VNet CIDR information. For example, 51.51.0.0/16.

      The CIDR includes the scope of all subnets that are going to be available to an VPC/VNet.

      Note

       

      The VNet CIDR information that you enter in this field cannot overlap with the infra pool. Verify that the CIDR information that you enter in this field does not overlap with the infra pool information that you entered in the Infra Subnet field in Step Deploying the Cisco Cloud Network Controller in Azure.

    • CIDR Type—Select Primary or Secondary. If this is your first CIDR, choose Primary for the CIDR type.

    • Add Subnet—Enter the subnet information, then click the check mark. For example, 51.51.1.0/24.

      For our example, we add at least two subnets each with a secondary VRF instance (hv1 or hv2) defined earlier.

  4. Click Save to exit from the window.

    Figure 12.
    Update Cloud Context Profile.

Step 2

Put a check on VNet Peering box then choose Default from Hub Network drop-down list to enable VNet peering to the Infra VNet.

Figure 13.
Enable VNET Peering.

Step 3

Click Ok to finish adding the cloud context profile to the VRF instance.

Step 4

Click on the Deploy Template button at the top-right corner of the screen to deploy the schema to the sites. You should see a message saying "Successfully Deployed" at this point.

Figure 14.
Deply the Template.

What to do next

After the template is sucessfully deployed, you can see the newly created VNet and two newly created subnets that are hosted under two different secondary VRFs with separate route tables on your Azure portal.
Figure 15.
Azure CCNC