Cisco Cloud Application Policy Infrastructure Controller User Guide

Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
First Published: 2021-06-04
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (1721R)
© 2021
Cisco Systems, Inc. All rights reserved.
CONTENTS
CHAPTER 1
New and Changed Information
1
New and Changed Information 1
CHAPTER 2
About Cisco Cloud APIC
3
Overview 3
Guidelines and Limitations 4
About the Cisco Cloud APIC GUI 6
Understanding the Cisco Cloud APIC GUI Icons 6
CHAPTER 3
Cisco Cloud APIC Policy Model
13
About the ACI Policy Model 13
Policy Model Key Characteristics 13
Logical Constructs 14
The Cisco ACI Policy Management Information Model 15
Tenants 17
Understanding Tenants, Identities, and Subscriptions 18
Cloud Context Profile 20
Cloud Service Routers 20
Changing the Number of CSRs 21
Private IP Address Support for Cisco Cloud APIC and Cisco Cloud Services Router
22
VRFs 23
Cloud Application Profiles 24
Cloud Endpoint Groups 25
Cloud Service Endpoint Groups 27
About Service Types 29
About Deployment Types 31
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
iii
Contents
Security Groups 33
Guidelines and Limitations for ASGs and NSGs 35
Security Rules 36
NSG Behavior With Software Upgrades or Downgrades 36
Contracts 38
Comma-separated Filters Support for Contract Rule Consolidation 39
Filters and Subjects Govern Cloud EPG Communications 40
About the Cloud Template 41
Managed Object Relations and Policy Resolution 44
Default Policies 45
Shared Services 46
CHAPTER 4
Configuring Cisco Cloud APIC Components
49
About Configuring the Cisco Cloud APIC 49
Configuring the Cisco Cloud APIC Using the GUI 49
Creating a Tenant Using the Cisco Cloud APIC GUI 49
Creating an Application Profile Using the Cisco Cloud APIC GUI 53
Creating a VRF Using the Cisco Cloud APIC GUI 54
Creating an EPG Using the Cisco Cloud APIC GUI 55
Creating an Application EPG Using the Cisco Cloud APIC GUI 55
Creating an External EPG Using the Cisco Cloud APIC GUI 59
Creating a Service EPG 62
Creating a Filter Using the Cisco Cloud APIC GUI 75
Creating a Contract Using the Cisco Cloud APIC GUI 77
Creating an Inter-Tenant Contract Using the Cisco Cloud APIC GUI 79
Configuring Network Security Groups Using the Cloud APIC GUI 82
Viewing Security Group Details 85
Specifying Consumer and Provider EPGs Using the Cisco Cloud APIC 86
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI 87
Configuring Virtual Machines in Azure 91
Creating a Backup Configuration Using the Cisco Cloud APIC GUI 92
Creating a Tech Support Policy Using the Cisco Cloud APIC GUI 95
Creating a Scheduler Using the Cisco Cloud APIC GUI 96
Creating a Remote Location Using the Cisco Cloud APIC GUI 98
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
iv
Contents
Creating a Login Domain Using the Cisco Cloud APIC GUI 99
Creating a Security Domain Using the Cisco Cloud APIC GUI 101
Creating a Role Using the Cisco Cloud APIC GUI 101
Creating a Certificate Authority Using the Cisco Cloud APIC GUI 106
Creating a Key Ring Using the Cisco Cloud APIC GUI 108
Creating a Local User Using the Cisco Cloud APIC GUI 109
Managing Regions (Configuring a Cloud Template) Using the Cisco Cloud APIC GUI 112
Configuring Smart Licensing 114
Cloud Resources Naming 115
Variables Available for Naming Rules 116
Naming Rules Guidelines and Limitations 118
Viewing Cloud Resource Naming Rules 119
Configuring Cisco Cloud APIC Using the REST API 120
Creating a Tenant Using the REST API 120
Creating a Contract Using the REST API 121
Creating a Cloud Context Profile Using the REST API 121
Managing a Cloud Region Using the REST API 122
Creating a Filter Using the REST API 123
Creating an Application Profile Using the REST API 123
Configuring Network Security Groups Using the REST API 124
Creating an EPG Using the REST API 125
Creating a Cloud EPG Using the REST API 125
Creating an External Cloud EPG Using the REST API 125
Creating a Service EPG Using the REST API 126
Creating a Cloud Template Using the REST API 127
Triggering an Upgrade of the Cloud Service Routers Using the REST API 128
Defining Global Cloud Resource Naming Rules or Overriding Specific Object's Name 128
CHAPTER 5
Viewing System Details
131
Viewing Application Management Details 131
Viewing Cloud Resource Details 132
Viewing Operations Details 134
Viewing Infrastructure Details 136
Viewing Administrative Details 136
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
v
Contents
Viewing Health Details Using the Cisco Cloud APIC GUI 138
CHAPTER 6
Deploying Layer 4 to Layer 7 Services
141
Overview 141
About Service Graphs 141
Using Service Graphs with Cloud Native and Third-Party Services 142
About Application Load Balancers 143
About Network Load Balancer 144
About Third-Party Load Balancers 145
About Allow All Traffic Option 146
Dynamic Server Attachment to Server Pool 147
About Inter-VNet Services 147
About Multinodes 148
About Layer 4 to Layer 7 Service Redirect 148
Passthrough Rules 150
Redirect Programming 150
Redirect Policy 151
Workflow for Configuring Redirect 151
Example Use Cases 152
Example Use Cases for Service Graphs with Cloud Native and Third-Party Services 167
Example Use Cases Without Redirect 167
Example Use Cases With Redirect 174
Guidelines and Limitations for Redirect 186
Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI 188
Deploying a Service Graph 190
Deploying a Service Graph Using the GUI 191
Creating Service Devices Using The Cloud APIC GUI 191
Creating a Service Graph Template Using the Cisco Cloud APIC GUI 196
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI 199
Deploying a Service Graph Using the REST API 203
Creating an Internal-Facing Load Balancer Using the REST API 203
Configuring an Internet-Facing Load Balancer Using the REST API 204
Creating a Third-Party Firewall Using the REST API 205
Creating a Third Party Load Balancer Using the REST API 206
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
vi
Contents
Creating a Service Graph Using the REST API for an Application Gateway 206
Creating a Service Graph Using the REST API for Azure Load Balancer 207
Creating a Service Graph Using the REST API for a Third Party Load Balancer 208
Creating a Multi-Node Service Graph Using the REST API 209
Creating a Multi-Node Service Graph With Redirect Using the REST API 212
Attaching a Service Graph Using the REST API 216
Configuring an HTTP Service Policy Using the REST API 217
Configuring a Key Ring Using the REST API 218
Creating an HTTPS Service Policy Using the REST API
CHAPTER 7
220
Cisco Cloud APIC Security 223
Access, Authentication, and Accounting 223
Configuration 223
Configuring TACACS+, RADIUS, LDAP and SAML Access 224
Overview 224
Configuring Cloud APIC for TACACS+ Access 224
Configuring Cloud APIC for RADIUS Access 225
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+ Access to the Cloud
APIC 227
Configuring LDAP Access 227
Configuring Windows Server 2008 LDAP for APIC Access with Cisco AVPair 227
Configuring Cloud APIC for LDAP Access 227
Configuring Cloud APIC for SAML Access 229
About SAML 229
Configuring Cloud APIC for SAML Access 230
Setting Up a SAML Application in Okta 231
Setting Up a Relying Party Trust in AD FS 231
Configuring HTTPS Access 231
About HTTPS Access 232
Guidelines for Configuring Custom Certificates 232
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI 232
CHAPTER 8
Restricting Access
235
Restricting Access by Domains 235
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
vii
Contents
RBAC Roles 235
RBAC Rules 239
Guidelines and Limitations for Restricted Domains
240
Creating an RBAC Rule Using the Cisco Cloud APIC GUI 240
CHAPTER 9
Configuration Drifts
243
Configuration Drift Notifications and Faults 243
Enabling Configuration Drift Detection 244
Checking for Missing Contracts Configuration 245
Configuration Drift Troubleshooting 248
CHAPTER 10
Express Route Gateway 249
About Express Route Gateway 249
About Deploying Express Route Gateway Using Redirect 249
Deploying Express Route Gateway Using Redirect 251
About Deploying Express Route Gateway Without Redirect 252
Deploying Express Route Gateway Without Redirect 253
APPENDIX A
Cisco Cloud APIC Error Codes
257
Cisco Cloud APIC Error Codes 257
APPENDIX B
Service EPG Configuration Examples
265
Azure Kubernetes Services (AKS) Service EPG Configuration Example 265
Creating a Subnet in the Cloud Context Profile 265
Creating the Cloud Service EPG for AKS 267
Verifying the Outbound Security Rules 269
Creating a Kubernetes Service 269
Verifying the New Kubernetes Service 273
Installing the Azure and AKS CLI 275
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
viii
CHAPTER
1
New and Changed Information
This chapter contains the following sections:
• New and Changed Information, on page 1
New and Changed Information
The following table provides an overview of the significant changes to the organization and features in this
guide up to this current release. The table does not provide an exhaustive list of all changes made to the guide
or of the new features up to this release.
Table 1: New Features and Changed Behavior in Cisco APIC for Cisco APIC Release 5.2(1)
Feature or Change
Description
Where Documented
This document has no changes from the previous release.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
1
New and Changed Information
New and Changed Information
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
2
CHAPTER
2
About Cisco Cloud APIC
• Overview, on page 3
• Guidelines and Limitations, on page 4
• About the Cisco Cloud APIC GUI, on page 6
Overview
Cisco Application Policy Infrastructure Controller (APIC) Release 4.1(1) introduces Cisco Cloud APIC, which
is a software deployment of Cisco APIC that you deploy on a cloud-based virtual machine (VM). Release
4.1(1) supports Amazon Web Services. Beginning in Release 4.2(x), support is added for Azure.
When deployed, the Cisco Cloud APIC:
• Provides an interface that is similar to the existing Cisco APIC to interact with the Azure public cloud
• Automates the deployment and configuration of cloud constructs
• Configures the cloud router control plane
• Configures the data path between the on-premises Cisco ACI fabric and the cloud site
• Translates Cisco ACI policies to cloud native construct
• Discovers endpoints
• Provides a consistent policy, security, and analytics for workloads deployed either on or across on-premises
data centers and the public cloud
Note
• Cisco Multi-Site pushes the MP-BGP EVPN configuration to the on-premises
spine switches
• On-premises VPN routers require a manual configuration for IPsec
• Provides an automated connection between on-premises data centers and the public cloud with easy
provisioning and monitoring
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
3
About Cisco Cloud APIC
Guidelines and Limitations
• Policies are pushed by Cisco Multi-Site Orchestrator to the on-premises and cloud sites, and Cisco Cloud
APIC translates the policies to the cloud native constructs to keep the policies consistent with the
on-premises site
For more information about extending Cisco ACI to the public cloud, see the Cisco Cloud APIC Installation
Guide.
When the Cisco Cloud APIC is up and running, you can begin adding and configuring Cisco Cloud APIC
components. This document describes the Cisco Cloud APIC policy model and explains how to manage (add,
configure, view, and delete) the Cisco Cloud APIC components using the GUI and the REST API.
Guidelines and Limitations
This section contains the guidelines and limitations for Cisco Cloud APIC.
• You cannot stretch more than one VRF between on-prem and the cloud while using inter-VRF route
leaking in the cloud CSRs (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.
• Before configuring an object for a tenant, first check for any stale cloud resource objects. A stale
configuration might be present if it was not cleaned properly from the previous Cisco Cloud APIC virtual
machines that managed the account. Cisco Cloud APIC can display stale cloud objects, but it cannot
remove them. You must log in to the cloud account and remove them manually.
Note
It takes some time for Cisco Cloud APIC to detect the stale cloud resources after
adding the tenant subscription ID.
Azure allows multiple tenants to share an Azure account owned by one tenant.
When the account is shared by multiple tenants, only the owner tenant is able to
view the stale objects in the other tenants.
To check for stale cloud resources:
1. From the Cisco Cloud APIC GUI, 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.
• Cisco Cloud APIC tries to manage the Azure 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 Azure IAM users in the Azure infra tenant subscription, and the other tenant
subscriptions, do not disturb the resources that Cisco Cloud APIC creates. For this purpose, all resources
Cisco Cloud APIC creates on Azure has at least one of these two tags:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
4
About Cisco Cloud APIC
Guidelines and Limitations
• AciDnTag
• AciOwnerTag
Cisco Cloud APIC must prevent Azure IAM users who have access to create, delete, or update VM, 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 subscriptions.
Azure subscription 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:
{
"properties": {
"level": "CanNotDelete",
"notes": "Optional text notes."
}
}
• 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.
• 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.
Table 2: Scale Supported
Component
Number Supported
Tenants
20
Application Profiles
500
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
5
About Cisco Cloud APIC
About the Cisco Cloud APIC GUI
Component
Number Supported
EPGs
500
Cloud Endpoints
1000
VRFs
20
Cloud Context Profiles
40
Contracts
1000
Service Graphs
200
Service Devices
100
About the Cisco Cloud APIC GUI
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, 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 EPG-specific window, hover your mouse over the Navigation menu and
click Application Management > EPGs. From there, you can use the Navigation menu to view the details
of another component. For example, you can navigate to the Active Sessions window from EPGs by clicking
Operations > Active Sessions.
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 Routers 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, on page 6
For more information about configuring Cisco Cloud APIC components, see Configuring Cisco Cloud APIC
Components, on page 49
Understanding the Cisco Cloud APIC GUI Icons
This section provides a brief overview of the commonly used icons in the Cisco Cloud APIC GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
6
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Table 3: Cisco Cloud APIC GUI Icons
Icon
Description
Figure 1: Navigation Pane (Collapsed)
The left side of the GUI contains the Navigation pane,
which collapses and expands. To expand the pane, hover
your mouse icon over it or click the menu icon at the
top. When you click the menu icon, the Navigation
pane locks in the open position. To collapse it, click the
menu icon again. When you expand the Navigation
pane by hovering the mouse icon over the menu icon,
you collapse the Navigation pane by moving the mouse
icon away from it.
When expanded, the Navigation pane displays a list of
tabs. When clicked, each tab displays a set of subtabs
that enable you to navigate between the Cisco Cloud
APIC component windows.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
7
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Icon
Description
Figure 2: Navigation Pane (Expanded)
The Cisco Cloud APIC component windows are
organized in the Navigation pane as follows:
• Dashboard Tab—Displays summary information
about the Cisco Cloud APIC components.
• Application Management Tab—Displays
information about tenants, application profiles,
EPGs, contracts, filters, VRFs, service graphs,
devices, and cloud context profiles.
• Cloud Resources Tab—Displays information
about regions, VNETs, routers, security groups
(application security groups/network security
groups), endpoints, instances, and cloud services
(and target groups).
• Operations Tab—Displays information about
event analytics, active sessions, backup & restore
policies, tech support policies, firmware
management, schedulers, and remote locations.
• Infrastructure Tab—Displays information about
the system configuration, inter-region connectivity,
and on-premises connectivity.
• Administrative Tab—Displays information about
authentication, event analytics, security, local and
remote users, and smart licensing.
Note
Figure 3: Intent Menu-Bar Icon
For more information about the contents of
these tabs, see Viewing System Details, on
page 131
The Intent icon appears in the menu bar between the
search and the help icons.
When clicked, the Intent dialog appears (see below).
The Intent dialog enables you to create a component
from any window in the Cisco Cloud APIC GUI. When
you create or view a component, a dialog box opens and
hides the Intent icon. Close the dialog box to access
the Intent icon again.
For more information about creating a component, see
Configuring Cisco Cloud APIC Components, on page
49.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
8
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Icon
Description
Figure 4: Intent Dialog Box
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
9
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Icon
Description
The Intent dialog box contains a search box and a
drop-down list. The drop-down list enables you to apply
a filter for displaying specific options. The search box
enables you to enter text for searching through the
filtered list.
• All Categories
• Configuration—Displays the following options:
• Set Up cAPIC
• EPG Communication
• Application Management—Displays the
following options:
• Create Tenant
• Create Application Profile
• Create EPG
• Create Contract
• Create Filter
• Create VRF
• Create Device
• Create Service Graph
• Create Cloud Context Profile
• Operations—Displays the following options:
• Create Backup Configuration
• Create Tech Support
• Create Scheduler
• Create Remote Location
• Administrative—Displays the following options:
• Create Login Domain
• Create Security Domain
• Create Role
• Create RBAC Rule
• Create Certificate Authority
• Create Key Ring
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
10
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Icon
Description
• Create Local User
Figure 5: Help Menu-Bar Icon
The help menu-bar icon opens the Cisco Cloud APIC
Quick Start Guide .
Figure 6: System Tools Menu-Bar Icon
The system tools menu-bar icon provides the following
options:
• About—Display the Cisco Cloud APIC version.
• ObjectStore Browser—Open the Managed Object
Browser, or Visore, which is a utility that is built
into Cisco Cloud APIC that provides a graphical
view of the managed objects (MOs) using a
browser.
Figure 7: Search Menu-Bar Icon
The search menu-bar icon displays the search field,
which enables you to to search for any object by name
or any other distinctive fields.
Figure 8: User Profile Menu-Bar Icon
The user profile menu-bar icon provides the following
options:
• Change Password—Enables you to change the
password.
• Change SSH Key—Enables you to change the
SSH key.
• Change User Certificate—Enables you to change
the user certificate.
• Logout—Enables you to log out of the GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
11
About Cisco Cloud APIC
Understanding the Cisco Cloud APIC GUI Icons
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
12
CHAPTER
3
Cisco Cloud APIC Policy Model
• About the ACI Policy Model, on page 13
• Policy Model Key Characteristics, on page 13
• Logical Constructs, on page 14
• The Cisco ACI Policy Management Information Model, on page 15
• Tenants, on page 17
• Cloud Context Profile, on page 20
• VRFs, on page 23
• Cloud Application Profiles, on page 24
• Cloud Endpoint Groups, on page 25
• Security Groups, on page 33
• Contracts, on page 38
• About the Cloud Template, on page 41
• Managed Object Relations and Policy Resolution, on page 44
• Default Policies, on page 45
• Shared Services, on page 46
About the ACI Policy Model
The ACI policy model enables the specification of application requirements policies. The Cisco Cloud APIC
automatically renders policies in the cloud infrastructure. When you or a process initiates an administrative
change to an object in the cloud infrastructure, the Cisco Cloud APIC first applies that change to the policy
model. This policy model change then triggers a change to the actual managed item. This approach is called
a model-driven framework.
Policy Model Key Characteristics
Key characteristics of the policy model include the following:
• As a model-driven architecture, the software maintains a complete representation of the administrative
and operational state of the system (the model). The model applies uniformly to cloud infrastructure,
services, system behaviors, and virtual devices attached to the network.
• The logical and concrete domains are separated; the logical configurations are rendered into concrete
configurations by applying the policies in relation to the available resources. No configuration is carried
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
13
Cisco Cloud APIC Policy Model
Logical Constructs
out against concrete entities. Concrete entities are configured implicitly as a side effect of the changes
to the Cisco Cloud policy model.
• The system prohibits communications with newly connected endpoints until the policy model is updated
to include the new endpoint.
• Network administrators do not configure logical system resources directly. Instead, they define logical
(hardware-independent) configurations and the Cisco Cloud APIC policies that control different aspects
of the system behavior.
Managed object manipulation in the model relieves engineers from the task of administering isolated, individual
component configurations. These characteristics enable automation and flexible workload provisioning that
can locate any workload anywhere in the infrastructure. Network-attached services can be easily deployed,
and the Cisco Cloud APIC provides an automation framework to manage the lifecycle of those network-attached
services.
Logical Constructs
The policy model manages the entire cloud infrastructure, including the infrastructure, authentication, security,
services, applications, cloud infrastructure, and diagnostics. Logical constructs in the policy model define
how the cloud infrastructure meets the needs of any of the functions of the cloud infrastructure. The following
figure provides an overview of the ACI policy model logical constructs.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
14
Cisco Cloud APIC Policy Model
The Cisco ACI Policy Management Information Model
Figure 9: ACI Policy Model Logical Constructs Overview
cloud infrastructure-wide or tenant administrators create predefined policies that contain application or shared
resource requirements. These policies automate the provisioning of applications, network-attached services,
security policies, and tenant subnets, which puts administrators in the position of approaching the resource
pool in terms of applications rather than infrastructure building blocks. The application needs to drive the
networking behavior, not the other way around.
The Cisco ACI Policy Management Information Model
The cloud infrastructure comprises the logical components as recorded in the Management Information Model
(MIM), which can be represented in a hierarchical management information tree (MIT). The Cisco Cloud
APIC runs processes that store and manage the information model. Similar to the OSI Common Management
Information Protocol (CMIP) and other X.500 variants, the Cisco Cloud APIC enables the control of managed
resources by presenting their manageable characteristics as object properties that can be inherited according
to the location of the object within the hierarchical structure of the MIT.
Each node in the tree represents a managed object (MO) or group of objects. MOs are abstractions of cloud
infrastructure resources. An MO can represent a concrete object, such as a cloud router, adapter, or a logical
object, such as an application profile, cloud endpoint group, or fault. The following figure provides an overview
of the MIT.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
15
Cisco Cloud APIC Policy Model
The Cisco ACI Policy Management Information Model
Figure 10: Cisco ACI Policy Management Information Model Overview
The hierarchical structure starts with the policy universe at the top (Root) and contains parent and child nodes.
Each node in the tree is an MO and each object in the cloud infrastructure has a unique distinguished name
(DN) that describes the object and locates its place in the tree.
The following managed objects contain the policies that govern the operation of the system:
• A tenant is a container for policies that enable an administrator to exercise role-based access control.
The system provides the following four kinds of tenants:
• The administrator defines user tenants according to the needs of users. They contain policies that
govern the operation of resources such as applications, databases, web servers, network-attached
storage, virtual machines, and so on.
• Although the system provides the common tenant, it can be configured by the cloud infrastructure
administrator. It contains policies that govern the operation of resources accessible to all tenants,
such as firewalls, load balancers, Layer 4 to Layer 7 services, intrusion detection appliances, and
so on.
Note
As of the Cisco Application Policy Infrastructure Controller (APIC) Release
4.1(1), the Cisco Cloud APIC only supports load balancers as a Layer 4 to Layer
7 service.
• The infrastructure tenant is provided by the system but can be configured by the cloud infrastructure
administrator. It contains policies that govern the operation of infrastructure resources. It also enables
a cloud infrastructure provider to selectively deploy resources to one or more user tenants.
Infrastructure tenant policies are configurable by the cloud infrastructure administrator.
• The cloud infra policies enable you to manage on-premises and inter-region connectivity when setting
up the Cisco Cloud APIC. For more information, see the Cisco Cloud APIC Installation Guide.
• Cloud inventory is a service that enables you to view different aspects of the system using the GUI. For
example, you can view the regions that are deployed from the aspect of an application or the applications
that are deployed from the aspect of a region. You can use this information for cloud resource planning
and troubleshooting.
• Layer 4 to Layer 7 service integration lifecycle automation framework enables the system to dynamically
respond when a service comes online or goes offline. For more information, see Deploying Layer 4 to
Layer 7 Services, on page 141
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
16
Cisco Cloud APIC Policy Model
Tenants
• Access, authentication, and accounting (AAA) policies govern user privileges, roles, and security domains
of the Cisco Cloud ACI cloud infrastructure. For more information, see Cisco Cloud APIC Security, on
page 223
The hierarchical policy model fits well with the REST API interface. When invoked, the API reads from or
writes to objects in the MIT. URLs map directly into distinguished names that identify objects in the MIT.
Any data in the MIT can be described as a self-contained structured tree text document encoded in XML or
JSON.
Tenants
A tenant (fvTenant) is a logical container for application policies that enable an administrator to exercise
domain-based access control. A tenant represents a unit of isolation from a policy perspective, but it does not
represent a private network. Tenants can represent a customer in a service provider setting, an organization
or domain in an enterprise setting, or just a convenient grouping of policies. The following figure provides
an overview of the tenant portion of the management information tree (MIT).
Figure 11: Tenants
Tenants can be isolated from one another or can share resources. The primary elements that the tenant contains
are filters, contracts, Virtual Routing and Forwarding (VRF) instances, cloud context profiles, Azure provider
configurations, and cloud application profiles that contain cloud endpoint groups (cloud EPGs). Entities in
the tenant inherit its policies. VRFs are also known as contexts; each VRF can be associated with multiple
cloud context profiles. A cloud context profile, in conjunction with a VRF, tenant and region, represents a
resource group in Azure. A VNET is created inside the resource group based on the VRF name.
Tenants are logical containers for application policies. The cloud infrastructure can contain multiple tenants.
You must configure a tenant before you can deploy any Layer 4 to Layer 7 services. The ACI cloud
infrastructure supports IPv4 and dual-stack configurations for tenant networking.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
17
Cisco Cloud APIC Policy Model
Understanding Tenants, Identities, and Subscriptions
Understanding Tenants, Identities, and Subscriptions
Azure has an active directory structure. The top level structure is the organization, and underneath the
organization are the directories (also known as Azure tenants). Inside the directories, you can have one or
more Azure subscriptions.
The relationship between certain Azure components is as follows:
Tenants > Subscriptions > Resource Groups > Resources
Where:
• One tenant can have multiple subscriptions, but each subscription can belong to only one tenant
• One subscription can have multiple resource groups, but each resource group can belong to only one
subscription
• One resource group can have multiple resources, but each resource can belong to only one subscription
The following sections provide more detail about each of these components:
• Mapping Azure and Cloud APIC Components, on page 18
• About Azure Subscriptions, on page 18
• About Tenants and Identities, on page 18
Mapping Azure and Cloud APIC Components
In Cloud APIC, each Azure resource group is mapped to one Cloud APIC tenant, and one Cloud APIC tenant
can have multiple Azure resource groups.
The relationship between certain Cloud APIC components is as follows:
Tenants > VRFs > Regions
When you create a VRF in Cloud APIC, a new resource group is also created on Azure.
About Azure Subscriptions
An Azure subscription is used to pay for Azure cloud services. An Azure subscription has a trust relationship
with Azure Active Directories (Azure ADs), where the subscription uses the Azure AD to authenticate users,
services, and devices. While multiple subscriptions can trust the same Azure AD, each subscription can trust
only one Azure AD.
In Azure, the same Azure subscription ID can be used for multiple ACI fabric tenants. This means that you
could configure the infra tenant using one Azure subscription, and then configure more user tenants in the
same subscription. ACI tenants are tied to Azure subscriptions.
About Tenants and Identities
Following are the different types of tenants and identities available through Azure and Cloud APIC.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
18
Cisco Cloud APIC Policy Model
Understanding Tenants, Identities, and Subscriptions
Note
For releases prior to release 5.2(1), only managed identity was supported as the access type for infra tenants,
while both managed identity and service principal was supported as the access type for user tenants.
Beginning with release 5.2(1), both managed identity and service principal is now supported as an access type
for the infra tenants and the user tenants.
Managed Identity
Managed identities provide an identity for applications to use when connecting to resources that support
Azure AD authentication. Applications can use the managed identity to obtain Azure AD tokens. For example,
an application could use a managed identity to access resources like Azure Key Vault, where developers can
store credentials in a secure manner or to access storage accounts.
Following are several benefits to using managed identities:
• You don't need to manage credentials, since credentials are not even accessible to you.
• You can use managed identities to authenticate to any resource that supports Azure AD authentication,
including your own applications.
• Managed identities can be used without any additional cost.
For additional information on managed identities in Azure, see:
https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview
If you are configuring tenants in the Cloud APIC using managed identity, then you will make the following
configurations in the Azure portal and in the Cloud APIC:
1. In the Azure portal, you will add a role assignment for a virtual machine. You use this option when the
Azure subscriptions are in the same Azure directory (of the same organization).
Note
If your Azure subscriptions are in different directories and you want to configure tenants using managed
identity, you can go to the Azure console and click on each of the subscriptions and move the subscriptions
under the same Azure directory. You can only do this if the directories (containing the different subscriptions)
are a child of the same parent organization.
2. In the Cloud APIC, you will choose the Managed Identity option when configuring a tenant in Cloud
APIC.
See Creating a Tenant Using the Cisco Cloud APIC GUI, on page 49 for more information on making these
configurations.
Service Principal
An Azure service principal is an identity created for use with applications, hosted services, and automated
tools to access Azure resources. You would use the service principal identity when you want to configure
tenants in different subscriptions. The subscriptions are either in different Azure directories (Azure tenants)
in the same organization, or the subscriptions can be in different organizations.
If you are configuring tenants in the Cloud APIC using service principal, then you will make the following
configurations in the Azure portal and in the Cloud APIC:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
19
Cisco Cloud APIC Policy Model
Cloud Context Profile
1. In the Azure portal, you will be adding a role assignment for an app, where the cloud resources will be
managed through a specific application.
2. In the Cloud APIC, you will choose the Service Principal option when configuring a tenant in Cloud
APIC. The subscriptions that you enter in this page can be in different Azure directories (Azure tenants)
in the same organization, or the subscriptions can be in different organizations.
See Creating a Tenant Using the Cisco Cloud APIC GUI, on page 49 for more information on making these
configurations.
Shared Tenant
You will choose this option when you have already associated Azure subscriptions with either of the two
methods above and want to create more tenants in that subscription.
If you are configuring a tenant in the Cloud APIC as shared tenant, then you will make the following
configurations in the Azure portal and in the Cloud APIC:
1. You do not have to make any configurations in Azure specifically for a shared tenant, because you will
have already associated Azure subscriptions with either of the two methods above. With the shared tenant,
you will just create more tenants in that existing subscription.
2. In the Cloud APIC, you will choose the Shared option when configuring a tenant in Cloud APIC.
See Creating a Tenant Using the Cisco Cloud APIC GUI, on page 49 for more information on making these
configurations.
Cloud Context Profile
The cloud context profile contains information on the following Cisco Cloud APIC components:
• CIDRs
• VRFs
• EPGs
• Regions
• Virtual Networks
• Routers
• Endpoints
Cloud Service Routers
The Cisco Cloud Services Router 1000V (CSR 1000V) is a virtual router that delivers comprehensive WAN
gateway and network services into virtual and cloud environments. The CSR 1000V enables enterprises to
extend their WANs into provider-hosted clouds. Two CSR 1000Vs are required for Cisco Cloud ACI solution.
For more information, see the Cisco CSR 1000v documentation.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
20
Cisco Cloud APIC Policy Model
Changing the Number of CSRs
Changing the Number of CSRs
Beginning with Release 5.1(2), the maximum number of CSRs supported per region increased from 4 to 8.
These procedures provide instructions for increasing the number of CSRs above 4, or for reducing the number
of CSRs back to 4, if necessary.
Note the following:
• You do not have to use these instructions if you are increasing or decreasing the number of CSRs in a
range between 2-4 CSRs. Use these instructions only if you are increasing the number of CSRs above
4, or if you are decreasing the number of CSRs from a range of 5-8 CSRs.
• Changing the number of CSRs can impact traffic for up to 30 minutes.
Step 1
Disable Azure VNet peering at the local level on all infra cloud context profiles.
a) Navigate to the Create Cloud Context Profile page:
Application Management > Cloud Context Profiles
b) Click the link under the Name column for the infra cloud context profile.
A panel showing details for this cloud context profile slides in from the right side of the window.
c) Click the Details icon (
).
Another window appears that provides more detailed information for this cloud context profile.
d) Click the pencil icon in the upper right corner of the window.
The Edit Cloud Context Profile window appears.
e) Uncheck (disable) the Hub Network Peering field.
f) Click Save when finished.
Repeat these steps to disable Azure VNet peering on all infra cloud context profiles.
Step 2
If you are increasing the number of CSRs above 4, add additional subnet pools for the additional CSRs, if necessary.
You will see an error message is you attempt to increase the number of CSRs above 4 and the system determines that
additional subnet pools are required.
a) In the Cloud APIC GUI, click the Intent icon (
) and select cAPIC Setup.
b) In the Region Management area, click Edit Configuration.
c) In the Regions to Manage window, click Next.
The General Connectivity window appears.
d) Under the General area, in the Subnet Pools for Cloud Routers field, click Add Subnet Pool for Cloud Routers
if you want to add additional subnets for CSRs.
Addresses from this subnet pool will be used for inter-region connectivity for any additional regions that are added
that need to be managed by the Cloud APIC. This must be a valid IPv4 subnet with mask /24.
Step 3
Increase the number of CSRs above 4, or decrease the number of CSRs from a range of 5-8 CSRs.
a) In your Cloud APIC GUI, click the Intent icon (
) and choose cAPIC Setup.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
21
Cisco Cloud APIC Policy Model
Private IP Address Support for Cisco Cloud APIC and Cisco Cloud Services Router
b) In the Region Management area, click Edit Configuration.
The Regions to Manage window appears.
c) Click Next to leave the previously-selected regions and CSRs as-is.
The General Connectivity window appears.
d) Locate the CSRs area in the General Connectivity window and, in the Number of Routers Per Region field, make
the necessary changes to increase or decrease the number of CSRs.
e) Click Next, then enter the necessary information in the following page and click Save and Continue.
The process of adding or removing the CSRs might take roughly a half hour.
Step 4
Enable Azure VNet peering again at the local level on all infra cloud context profiles.
a) Navigate to the Create Cloud Context Profile page:
Application Management > Cloud Context Profiles
b) Click the link under the Name column for the infra cloud context profile.
A panel showing details for this cloud context profile slides in from the right side of the window.
c) Click the Details icon (
).
Another window appears that provides more detailed information for this cloud context profile.
d) Click the pencil icon in the upper right corner of the window.
The Edit Cloud Context Profile window appears.
e) Check (enable) the Hub Network Peering field.
f) Click Save when finished.
Repeat these steps to enable Azure VNet peering on all infra cloud context profiles.
Private IP Address Support for Cisco Cloud APIC and Cisco Cloud Services Router
Prior to Release 5.1(2), Cisco Cloud Router (CSR) interfaces were assigned both public and private IP address
by Cloud APIC. Beginning with Release 5.1(2) , CSR interfaces are assigned private IP addresses only and
assignment of public IP addresses to CSR interfaces is optional. Private IP addresses are always assigned to
all the interfaces of a CSR. The private IP of GigabitEthernet1 of a CSR is used as BGP and OSPF router IDs.
Hcloud with on-premise ACI sites over express route is supported when CSRs are assigned private IP addresses.
To enable private IP for a CSR, see Managing Regions (Configuring a Cloud Template) Using the Cisco
Cloud APIC GUI, on page 112 procedure.
Prior to Release 5.1(2), the management interface of the Cloud APIC was assigned a public IP address and a
private IP address. Beginning with Release 5.1(2), a private IP address is assigned to the management interface
of the Cisco Cloud APIC and assigning a public IP address is optional. To enable private IP for Cloud APIC,
see Deploying the Cloud APIC in Azure procedure in the Cisco Cloud APIC for Azure Installation Guide.
Restrictions for CSR with private IP address:
• No support for multicloud deployments as intersite communication needs IPsec.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
22
Cisco Cloud APIC Policy Model
VRFs
VRFs
A Virtual Routing and Forwarding (VRF) object (fvCtx) or context is a tenant network (called a VRF in the
Cisco Cloud APIC GUI). A tenant can have multiple VRFs. A VRF is a unique Layer 3 forwarding and
application policy domain. The following figure shows the location of VRFs in the management information
tree (MIT) and their relation to other objects in the tenant.
Figure 12: VRFs
A VRF defines a Layer 3 address domain. One or more cloud context profiles are associated with a VRF. You
can only associate one cloud context profile with a VRF in a given region. All the endpoints within the Layer
3 domain must have unique IP addresses because it is possible to forward packets directly between these
devices if the policy allows it. A tenant can contain multiple VRFs. After an administrator creates a logical
device, the administrator can create a VRF for the logical device, which provides a selection criteria policy
for a device cluster. A logical device can be selected based on a contract name, a graph name, or the function
node name inside the graph.
Support for Multiple VRFs Under Single VNet
Support is now available for multiple VRFs under a single VNet, depending on the APIC release:
• Beginning with Release 5.0(2), you can have an infra (hub) VNet (a cloudCtxProfile in the infra
tenant) that can be carved out into multiple VRFs. The cloud template subnets will be mapped to the
overlay-1 VRF, but the user-created subnets will be implicitly mapped to the overlay-2 VRF in the same
infra VNet. All subnets in the respective VRFs will have separate route tables in the cloud for VRF
segregation.
• Beginning with Release 5.1(2), the ability to carve out multiple VRFs has been extended beyond the
infra VNet so that you can divide any VNet into multiple VRFs under the same tenant, where multiple
VRFs can exist in a single VNet. This is useful for situations such as cloud service access, where you
might want to carve out multiple networks (VRFs) within a given VNet, allowing you to have separate
routing by having unique route tables for each VRF within the VNet in the cloud.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
23
Cisco Cloud APIC Policy Model
Cloud Application Profiles
The following graphic shows an example manged object (MO) relationship tree with multiple VRFs under
the same tenant (VNet).
In this example, two VRFs exist under the same tenant (VNet):
• The primary VRF with the name mainVRF
• A secondary VRF with the name servicesVRF
A second CIDR block and subnet exists in the same cloud context profile, under the same tenant (VNet), but
that second CIDR block and subnet is associated with the secondary VRF in that same VNet.
Cloud Application Profiles
A cloud application profile (cloudAp) defines the policies, services and relationships between cloud EPGs.
The following figure shows the location of cloud application profiles in the management information tree
(MIT) and their relation to other objects in the tenant.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
24
Cisco Cloud APIC Policy Model
Cloud Endpoint Groups
Figure 13: Cloud Application Profiles
Cloud application profiles contain one or more cloud EPGs. Modern applications contain multiple components.
For example, an e-commerce application could require a web server, a database server, data located in a
storage service, and access to outside resources that enable financial transactions. The cloud application profile
contains as many (or as few) cloud EPGs as necessary that are logically related to providing the capabilities
of an application.
Cloud EPGs can be organized according to one of the following:
• The application they provide, such as a DNS server or SAP application (see Tenant Policy Example in
Cisco APIC REST API Configuration Guide).
• The function they provide (such as infrastructure)
• Where they are in the structure of the data center (such as DMZ)
• Whatever organizing principle that a cloud infrastructure or tenant administrator chooses to use
Cloud Endpoint Groups
The cloud endpoint group (cloud EPG) is the most important object in the policy model. The following figure
shows where application cloud EPGs are located in the management information tree (MIT) and their relation
to other objects in the tenant.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
25
Cisco Cloud APIC Policy Model
Cloud Endpoint Groups
Figure 14: Cloud Endpoint Groups
A cloud EPG is a managed object that is a named logical entity that contains a collection of endpoints. Endpoints
are devices that are connected to the network. They have an address (identity), a location, attributes (such as
version or patch level), and are virtual. Knowing the address of an endpoint also enables access to all its other
identity details. Cloud EPGs are fully decoupled from the physical and logical topology. Endpoint examples
include servers, virtual machines, storage services, or clients on the Internet. Endpoint membership in a cloud
EPG can be dynamic or static.
The ACI cloud infrastructure can contain the following types of cloud EPGs:
• Cloud endpoint group (cloudEPg)
• Cloud external endpoint group (cloudExtEPg)
• Cloud service endpoint group (cloudSvcEPg): Introduced in Release 5.1(2). See Cloud Service Endpoint
Groups, on page 27 for more information.
Cloud EPGs contain endpoints that have common policy requirements such as security or Layer 4 to Layer
7 services. Rather than configure and manage endpoints individually, they are placed in a cloud EPG and are
managed as a group.
Policies apply to cloud EPGs, never to individual endpoints.
Regardless of how a cloud EPG is configured, cloud EPG policies are applied to the endpoints they contain.
WAN router connectivity to the cloud infrastructure is an example of a configuration that uses a static cloud
EPG. To configure WAN router connectivity to the cloud infrastructure, an administrator configures a
cloudExtEPg cloud EPG that includes any endpoints within an associated WAN subnet. The cloud infrastructure
learns of the cloud EPG endpoints through a discovery process as the endpoints progress through their
connectivity life cycle. Upon learning of the endpoint, the cloud infrastructure applies the cloudExtEPg cloud
EPG policies accordingly. For example, when a WAN connected client initiates a TCP session with a server
within an application (cloudEPg) cloud EPG, the cloudExtEPg cloud EPG applies its policies to that client
endpoint before the communication with the (cloudEPg) cloud EPG web server begins. When the client server
TCP session ends, and communication between the client and server terminates, the WAN endpoint no longer
exists in the cloud infrastructure.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
26
Cisco Cloud APIC Policy Model
Cloud Service Endpoint Groups
The Cisco Cloud APIC uses endpoint selectors to assign endpoints to Cloud EPGs. The endpoint selector is
essentially a set of rules that are run against the cloud instances that are assigned to the Azure VNET managed
by Cisco ACI. Any endpoint selector rules that match endpoint instances assign that endpoint to the Cloud
EPG. The endpoint selector is similar to the attribute-based microsegmentation available in Cisco ACI.
Cloud Service Endpoint Groups
A cloud service EPG, introduced in Release 5.1(2), is a managed object that is a named logical entity that
contains a collection of cloud native or third-party service instances or endpoints. In this situation, an endpoint
refers to a particular service instance. For example, an SQL server would be considered an endpoint, and a
collection of SQL servers would form a service endpoint group. Other examples of service EPGs would be a
collection of Storage Accounts, a collection of Key Vaults, and so on.
Service EPGs have several unique attributes:
• Service Type: This attribute indicates what type of cloud service is being grouped. Examples of available
service types include Azure SQL, Azure Containter Registery, Azure ApiManagement Services,
and so on. The service type Custom is used when configuring a third-party service EPG.
• Deployment Type: This attribute indicates how and where the service is deployed. Following are the
available deployment types:
• Cloud Native: In this type of deployment, the service is instantiated in the cloud provider's network
and the user or applications consuming it have a handle to the service. For example, an Azure storage
account might reside inside Azure's own VNet, and you would have a URL to access the storage
contents.
• Cloud Native Managed: In this type of deployment, the service is instantiated in your VNet or
subnet (created through the Cisco Cloud APIC). For example, an Azure Kubernetes cluster (AKS)
could be deployed in a subnet that is managed by the Cisco Cloud APIC.
• Third-Party: This is a deployment where a third-party (not Azure) is providing services through
the market place. Access to this service is provided through the private links feature.
• Access Type: This indicates how the service will be accessed. Following are the available access types:
• Public: The service will be accessed using the public IP address assigned to it. Access to the public
IP address range of a particular service is achieved using the Azure "Service Tags" in the NSG rules.
• Private: The service will be accessed using a private IP address assigned to it. This assignment is
done through the creation of private endpoints when the deployment is of type Cloud Native and
Third-Party. In the case of a Cloud Native Managed deployment, the private IP is assigned by
the service from the subnet IP space.
Only certain deployment types, and certain access types within each deployment type, are supported for
each service type, described in the previous bullets. The following table provides more information on
the deployment types and access types that are supported for each service type.
Service Type
Azure Storage Blob
Provider
Microsoft.Storage
Deployment Type/Access Type
Cloud Native
Cloud Native Managed
Third-Party
Private
N/A
N/A
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
27
Cisco Cloud APIC Policy Model
Cloud Service Endpoint Groups
Service Type
Provider
Deployment Type/Access Type
Cloud Native
Microsoft.Sql
Azure SQL
• Public
Cloud Native Managed
Third-Party
N/A
N/A
N/A
N/A
• Private
Azure Cosmos DB
Microsoft.DocumentDB
• Public
• Private
Microsoft.Databricks
Azure Databricks
Public
• Private
N/A
• Public and Private
Microsoft.Storage
Azure Storage
• Public
N/A
N/A
• Private
Azure Storage File
Microsoft.Storage
Private
N/A
N/A
Azure Storage Queue
Microsoft.Storage
Private
N/A
N/A
Azure Storage Table
Microsoft.Storage
Private
N/A
N/A
Azure Kubernetes
Services (AKS)
Microsoft.ContainerService Private
Microsoft.ContainerRegistry
Public
• Private
N/A
• Public and Private
• Public
N/A
N/A
• Private
Azure ApiManagement Microsoft.ApiManagement Public
Services
Azure Key Vault
N/A
• Public and Private
Azure Active Directory Microsoft.AAD
Domain Services
Azure Container
Registry
• Private
Microsoft.KeyVault
• Public
• Private
N/A
• Public and Private
N/A
N/A
• Private
Redis Cache
Microsoft.Cache
N/A
• Private
N/A
• Public and Private
Custom Service
• Public
• Private
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
28
N/A
Private
Cisco Cloud APIC Policy Model
About Service Types
• Service Endpoint Selectors: Service endpoints can be selected using the existing selectors (used in the
cloud EPG selection) as well as the new types of selectors listed below:
• Resource Name: The service resource's name
• Resource ID: The cloud provider's ID for the resource
• URL: The alias or FQDN that identifies the service (the private link alias is used in Azure)
The following table provides more information on the endpoint selectors that are supported for each
deployment type.
Note
Information for the Cloud Native (Public) deployment type is not provided in the
following table because that deployment type does not support endpoint selectors.
Deployment Type
Tags
Region
IP
Resource
Name
Resource ID URL
Cloud Native (Private)
Y
Y
N
Y
Y
N
Cloud Native Managed
N
N
Y
N
N
N
Third-Party
N
N
N
N
N
Y (applicable
only for
private link
connection)
Guidelines and Restrictions for Cloud Service EPGs
You must have the NSG-per-subnet configuration enabled if you are configuring cloud service EPGs. See
Security Groups, on page 33 for more information.
About Service Types
Additional information specific to certain service types are provided below:
• Azure Storage, on page 29
• Azure ApiManagement Services, on page 30
• Azure Databricks Services, on page 30
• Azure Active Directory Domain Services, on page 31
• Azure Kubernetes Services, on page 31
• Azure Redis Cache, on page 31
Azure Storage
The Azure Storage service type is a general service type that can be broken down into four subtypes:
• Blob
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
29
Cisco Cloud APIC Policy Model
About Service Types
• File
• Table
• Queue
If you were to configure a service EPG with the following values, using the general Azure Storage service
type:
• Service type: Azure
Storage
• Deployment type: Cloud
Native
• Access type: Private
Then four private endpoints are automatically configured for this service EPG, one for each of the four subtypes
listed above.
However, if you were to configure a service EPG with the following values, using a more specific Azure
Storage service type:
• Service type: One of these service types:
• Azure
Storage Blob
• Azure
Storage File
• Azure
Storage Table
• Azure
Storage Queue
• Deployment type: Cloud
Native
• Access type: Private
Then only one private endpoint is automatically configured for this particular subtype for this service EPG.
Note that the four specific Azure Storage subtypes (Blob, File, Table, and Queue) are not allowed if you have
an access type of Public with the deployment type of Cloud Native. This is because Azure service tags are
not storage subtype specific.
Azure ApiManagement Services
For an Azure ApiManagement (APIM) Services instance to be deployed in a VNet, it needs to be able to
access a lot of other Azure services. In order to do this, the security group rules that allow this access must
be programmed.
Cisco Cloud APIC automates this and configures the rules listed here:
https://docs.microsoft.com/en-us/azure/api-management/
api-management-using-with-vnet#-common-network-configuration-issues
Azure Databricks Services
Azure Databricks requires the following:
• Access to other services
• Two subnets for deployment, where the subnets are delegated to Microsoft
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
30
Cisco Cloud APIC Policy Model
About Deployment Types
For Azure Databricks, make the following configurations:
• Before configuring the service EPG, you must configure two subnets specifically for the Azure Databricks
Services.
• When configuring the service EPG, you must create two service endpoint selectors that will be used to
match the two service subnets.
Once the subnet is identified with the Azure Databricks service EPG through the configured endpoint selectors,
Cisco Cloud APIC delegates subnets to Azure and configures the rules listed here:
https://docs.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/vnet-inject
Azure Active Directory Domain Services
Azure Active Directory Domain Services (ADDS) requires the following:
• Access to other services
• No routing table is attached to the subnet when it is being deployed
The action of de-associating the routing table from the subnet should be done through the Azure portal after
configuring the service EPG and before deploying ADDS. The routing table can be attached to the subnet
after the deployment is completed.
Cisco Cloud APIC automates the programming of the rules listed here:
https://docs.microsoft.com/en-us/azure/active-directory-domain-services/network-considerations
Azure Kubernetes Services
Azure Kubernetes Services (AKS) requires access to other services.
Cisco Cloud APIC automates the programming of the rules listed here:
https://docs.microsoft.com/en-us/azure/aks/
limit-egress-traffic#required-outbound-network-rules-and-fqdns-for-aks-clusters
See Service EPG Configuration Examples, on page 265 for an example configuration of the AKS service EPG.
Azure Redis Cache
Azure Redis cache requires access to other services.
Cisco Cloud APIC automates the programming of the rules listed here:
https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/
cache-how-to-premium-vnet#outbound-port-requirements
About Deployment Types
Additional information specific to certain deployment types are provided below:
• Cloud Native, on page 32
• Cloud Native Managed, on page 33
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
31
Cisco Cloud APIC Policy Model
About Deployment Types
Cloud Native
In this type of deployment, the service is instantiated in the cloud provider's network and the user or applications
consuming it have a handle to the service. For example, an Azure storage account might reside inside Azure's
own VNet, and you would have a URL to access the storage contents.
The following is an example service EPG with a Cloud Native deployment type:
• Service Type: Azure SQL
• Deployment type: Cloud Native
• Access type: Private
In this example scenario, you would make the following configurations in this order:
1. In the Cisco Cloud APIC GUI, create a private link label in a cloud context profile to be used by the Azure
SQL service EPG.
Follow the procedures in Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI, on page
87. Configure a private link label to be used by the Azure SQL service EPG (for example, SQL-PLL).
2. In the Cisco Cloud APIC GUI, create a service EPG of the service type Azure SQL.
Follow the procedures in Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66, using
the following parameters:
• Service Type: Azure SQL
• Deployment type: Cloud Native
• Access type: Private
When you are configuring the endpoint selector as part of the process of configuring this type of service
EPG, configure the endpoint selector to match the appropriate value for the SQL server.
For example, if you wanted to select an SQL server with the name ProdSqlServer, you would make the
following selections:
• Key: Name
• Operator: equals
• Value: ProdSqlServer
As another example, if you wanted to select an SQL server using the cloud provider's resource ID of
/subscriptions/{subscription-id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/servers/ProdSqlServer,
you would make the following selections:
• Key: Resource ID
• Operator: equals
• Value:
/subscriptions/{subscription-id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/servers/ProdSqlServer
3. In the Azure portal, configure the Azure SQL resources in the cloud.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
32
Cisco Cloud APIC Policy Model
Security Groups
Cloud Native Managed
In this type of deployment, the service is instantiated in your VNet or subnet (created through the Cisco Cloud
APIC). For example, an Azure ApiManagement Services could be deployed in a subnet that is managed by
the Cisco Cloud APIC.
The following is an example service EPG with a Cloud Native Managed deployment type:
• Service Type: Azure ApiManagement Services
• Deployment type: Cloud Native Managed
• Access type: Private
In this example scenario, you would make the following configurations in this order:
1. In the Cisco Cloud APIC GUI, create a subnet in a cloud context profile to be used by the Azure
ApiManagement Services service EPG.
Follow the procedures in Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI, on page
87. Configure a subnet to be used by the Azure ApiManagement Services service EPG (for example,
10.50.0.0/16).
2. In the Cisco Cloud APIC GUI, create a service EPG of the service type Azure ApiManagement Services.
Follow the procedures in Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66, using
the following parameters:
• Service Type: Azure ApiManagement Services
• Deployment type: Cloud Native Managed
• Access type: Private
When you are configuring the endpoint selector as part of the process of configuring this type of service
EPG, configure the endpoint selector to match the IP address that you used when you created a subnet in
the cloud context profile in the first step.
For example, using the example provided in the first step, you would configure this endpoint selector for
this service EPG:
• Key: IP
• Operator: equals
• Value: 10.50.0.0/16
3. In the Azure portal, configure the Azure ApiManagement Services resources in the cloud.
Security Groups
In Azure, two types of security groups are used to administer and control network traffic within a virtual
network (VNet):
• Network security groups: Network security groups, or NSGs, are used in Azure to filter network traffic
to and from Azure resources. An NSG is used to define incoming and outgoing security policies, and
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
33
Cisco Cloud APIC Policy Model
Security Groups
contains security rules that allow or deny inbound network traffic to, or outbound network traffic from,
several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.
In Cloud APIC, an NSG is automatically configured based on a contract.
• Application security groups: Application security groups, or ASGs, are used in Azure to group virtual
machine (VM) NICs according to the applications that run on them and define network security policies
based on those groups. ASGs are used within an NSG to define these security polices and to apply a
network security rule to a specific workload or group of virtual machines.
In Cloud APIC, an ASG is a collection of endpoints for each EPG and is referenced as the source or
destination in the NSG security policies.
The way that these security groups are configured, and what they are mapped to, differ depending on the
release.
• Releases Prior to Release 5.1(2): NSG-Per-EPG Configurations, on page 34
• Release 5.1(2) and Later: NSG-Per-Subnet Configurations, on page 34
• Release 5.1(2g) and Later: IP-Based Rules for Inter-VRF Contracts in the Same VNet, on page 35
Releases Prior to Release 5.1(2): NSG-Per-EPG Configurations
For releases prior to Release 5.1(2), there is a one-to-one mapping between NSGs in Azure and EPGs on
Cisco Cloud APIC (these configurations are also referred to as NSG-per-EPG configurations throughout this
document). These NSGs for the Cloud APIC EPGs are populated with security rules based on contracts
associated with the EPGs.
For releases prior to Release 5.1(2), the creation of an EPG in Cloud APIC results in the creation of the
following Azure components:
• An ASG, which is used to group all endpoints or virtual machine NICs for each EPG based on the endpoint
selectors
• An NSG, which gets associated with all of the NICs in that ASG and provides the security policy definition
for that EPG
Release 5.1(2) and Later: NSG-Per-Subnet Configurations
Beginning with Release 5.1(2), in addition to the existing NSG-per-EPG configurations available previously,
NSGs in Azure can also have a one-to-one mapping with subnets rather than EPGs on Cloud APIC (these
configurations are also referred to as NSG-per-subnet configurations throughout this document). By default,
NSGs are no longer created for EPGs beginning with Release 5.1(2), and NSGs are no longer associated with
the endpoints and VM NICs in the ASG for that EPG. Instead, the NSG for each subnet will contain all of
the rules based on the contracts for the ASGs, which have their endpoints discovered in the subnet.
For NSG-per-subnet configurations, the creation of an EPG in Cloud APIC results in the creation of the
following Azure components:
• An ASG, which is used to group all endpoints or virtual machine NICs for each EPG based on the endpoint
selectors [essentially no change in behavior for ASGs from releases prior to Release 5.1(2)]
• An NSG, which continues to provide the security policy definition for that EPG, but now gets associated
with a subnet in a Cloud APIC-managed VNet
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
34
Cisco Cloud APIC Policy Model
Guidelines and Limitations for ASGs and NSGs
Looked at from another perspective:
• Every EPG in a Cloud APIC-managed VNet will have an ASG associated with it, which will group all
the endpoints based on the endpoint selectors configured for the EPG.
• Every subnet in a Cloud APIC-managed VNet will have an NSG associated with it.
The default setting for a Greenfield or a fresh Cloud APIC deployment is NSG-per-subnet. When manually
setting this configuration, as described previously, you can choose either a newer NSG-per-subnet configuration
or the older NSG-per-EPG configuration beginning with Release 5.1(2). However, we recommend choosing
the newer NSG-per-subnet configuration for several reasons:
• Using the NSG-per-subnet configuration reduces the number of NSGs in the VNet, and also reduces
the number of rules for deployments with a large number of subnets accessing common shared services.
This provides for easier management, since all of the rules can be checked in one NSG for a subnet,
rather than for each NSG mapped to individual EPGs or ASGs.
• You must use the NSG-per-subnet configuration if you are configuring service EPGs. See Cloud Service
Endpoint Groups, on page 27 for more information.
See Configuring Network Security Groups Using the Cloud APIC GUI, on page 82 for instructions on enabling
or disabling the NSG-per-EPG or NSG-per-subnet configurations.
Release 5.1(2g) and Later: IP-Based Rules for Inter-VRF Contracts in the Same VNet
Prior to release 5.1(2g), if two EPGs had a contract and were in the same VNet but belonged to different
VRFs, ASG-based rules were used to enable communication between those hosted VRFs in that VNet. Azure
has a limit of 100 ASGs in rules for every NSG, and this limit could be reached quickly in some situations
(for example, if you have one VNet for all of your shared services).
Beginning with release 5.1(2g), if two EPGs have a contract and are in the same VNet but belong to different
VRFs, IP-based rules are now used to enable communication between those hosted VRFs in that VNet, which
is preferrable because an NSG can support 4000 IP addresses in the rules. These IP-based rules are based on
endpoints discovered or on subnet selectors used in the EPG.
Guidelines and Limitations for ASGs and NSGs
Following are the guidelines and limitations for ASGs and NSGs.
• Guidelines and Limitations for Releases Prior to 5.1(2), on page 35
• Guidelines and Limitations for Release 5.1(2) or Later, on page 35
Guidelines and Limitations for Releases Prior to 5.1(2)
For releases prior to Release 5.1(2), support is only available for NSG-to-EPG mapping for Cloud APIC.
Guidelines and Limitations for Release 5.1(2) or Later
• Beginning with Release 5.1(2), support is also available for NSG-to-subnet mapping for Cloud APIC.
However, you can have either the newer NSG-per-subnet configuration or the NSG-per-EPG configuration,
but not both in the same Cloud APIC system.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
35
Cisco Cloud APIC Policy Model
Security Rules
• You can configure one NSG per subnet in a Cloud APIC-managed VNET. Having one NSG per a group
of subnets is not supported for Cloud APIC at this time.
• Passthrough devices, such as transparent firewall, will not have NSGs attached to their NICs. If there
are multiple passthrough devices sharing a subnet, the passthrough rules for each device will apply to
all endpoints in the subnet.
Security Rules
The security rules for NSG differ, depending on whether they are rules for NSG-per-EPG configurations or
for NSG-per-subnet configurations. A major distinction on the processing of the security rules between the
two types of configurations is the trigger for installing and deleting the rules.
• NSG-Per-EPG Security Rules, on page 36
• NSG-Per-Subnet Security Rules, on page 36
NSG-Per-EPG Security Rules
• Once the EPGs and the contract are defined on the Cloud APIC, the NSG security rules that use ASGs
as the source and destination are always programmed, regardless of whether an endpoint for the ASG
that is referenced in the NSG security rule is discovered or not.
• For inter-VRF contracts:
• If either the consumer or the provider EPG uses an endpoint selector based on subnet, then the NSG
security rules that have the source or destination as the subnet from the EPG selector are always
programmed, regardless of the discovery of an endpoint.
• If the consumer or provider EPG does not use an endpoint selector based on subnet, then the NSG
security rules using the endpoint's IP address as the source and destination are programmed, depending
on the discovery of an endpoint.
• The rules created for an inter-site contract, where a cloud external EPG (cloudExtEPg) is involved, also
get pre-programmed without the endpoint getting discovered.
NSG-Per-Subnet Security Rules
The NSG security rules for an EPG are not programmed in a subnet-based NSG until the EPG has at least
one endpoint discovered in that subnet.
NSG Behavior With Software Upgrades or Downgrades
Because only NSG-per-EPG mapping is supported for releases prior to Release 5.1(2), and support for
NSG-per-subnet mapping became available beginning with Release 5.1(2), certain system configuration
changes might have to take place when you are upgrading or downgrading your software in certain situations.
The following sections describe these situations and what must occur during these upgrade or downgrade
operations.
• NSG Behavior With Software Upgrades, on page 37
• NSG Behavior With Software Downgrades, on page 37
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
36
Cisco Cloud APIC Policy Model
NSG Behavior With Software Upgrades or Downgrades
NSG Behavior With Software Upgrades
When you perform a standard upgrade from a release prior to Release 5.1(2) to Release 5.1(2) or later, NSGs
that were configured using the NSG-per-EPG mapping that was supported for the release prior to Release
5.1(2) will remain as-is after the upgrade. This is because either NSG-per-EPG or NSG-per-subnet
configurations are supported for Release 5.1(2) or later, so the older NSG-per-EPG configurations will be
retained automatically when performing a standard upgrade to Release 5.1(2) or later.
However, there are benefits to the NSG-per-subnet configuration, so we recommend that you convert the
NSG-per-EPG configurations to NSG-per-subnet to take advantage of those benefits. See Security Groups,
on page 33 for more information on the different NSG configurations, and Configuring Network Security
Groups Using the Cloud APIC GUI, on page 82 for instructions on enabling or disabling the NSG-per-EPG
or NSG-per-subnet configurations.
Keep in mind that, after the upgrade, you can have either older NSG-per-EPG or the newer NSG-per-subnet
configuration, but you cannot have both in the same Cloud APIC system. See Guidelines and Limitations for
ASGs and NSGs, on page 35 for more information.
However, if you backed up your existing Cloud APIC configuration using the procedures in Creating a Backup
Configuration Using the Cisco Cloud APIC GUI, on page 92, then performed an upgrade and imported the
backed-up configuration after the upgrade, the NSG-per-subnet configuration is turned on automatically, and
any older NSG-per-EPG configurations are automatically converted to the newer NSG-per-subnet configuration.
NSG Behavior With Software Downgrades
When you downgrade from Release 5.1(2) or later to a release prior to Release 5.1(2), you must manually
move any NSG-per-subnet configurations back to the NSG-per-EPG configuration that was supported for
releases prior to Release 5.1(2).
Following is the general process that you will follow to transition from NSG-per-subnet configurations to
NSG-per-EPG configurations before downgrading the software:
1. Before downgrading the software from Release 5.1(2) or later to a release prior to Release 5.1(2), disable
the NSG-per-subnet configuration using the procedures provided in Configuring Network Security Groups
Using the Cloud APIC GUI, on page 82. The Cloud APIC software begins the transition from
NSG-per-subnet mapping to NSG-per-EPG mapping.
2. Wait until the transition is complete, where the Cloud APIC software has deleted all of the NSGs that
were configured as part of the NSG-per-subnet mapping process and has created new NSGs for the
NSG-per-EPG mapping configuration. If you attempt to proceed with the downgrade before the transition
is complete, you will see an error message and the Cloud APIC software will not allow you to proceed
with the downgrade until this transition from NSG-per-subnet mapping to NSG-per-EPG mapping has
completed.
Note
You will get an error message if you attempt a software downgrade before the transition is complete when
downgrading through the GUI; however, you will not get an error message if you attempt a software downgrade
too early when downgrading through the REST API. For that reason, we recommend that you do not downgrade
your software through the REST API if you are in this situation.
If you decide to downgrade your software through the REST API, monitor the following MO:
hcloudReconcileDone
Verify that the property sgForSubnetModeConverged is set to yes before proceeding with the downgrade
through the REST API.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
37
Cisco Cloud APIC Policy Model
Contracts
3. When you have confirmation that the system has successfully completed the transition back to the
NSG-per-EPG mapping, you can downgrade the Cloud APIC software using the instructions provided in
the Cisco Cloud APIC for Azure Installation Guide.
Contracts
In addition to cloud EPGs, contracts (vzBrCP) are key objects in the policy model. Cloud EPGs can only
communicate with other cloud EPGs according to contract rules. The following figure shows the location of
contracts in the management information tree (MIT) and their relation to other objects in the tenant.
Figure 15: Contracts
An administrator uses a contract to select one or more types of traffic that can pass between cloud EPGs,
including the protocols and ports allowed. If there is no contract, inter-EPG communication is disabled by
default. There is no contract required for intra-EPG communication; intra-EPG communication is always
implicitly allowed.
Contracts govern the following types of cloud EPG communications:
• Between cloud EPGs (cloudEPg), both intra-tenant and inter-tenant
Note
In the case of a shared service mode, a contract is required for inter-tenant
communication. A contract is used to specify static routes across VRFs, although
the tenant VRF does not enforce a policy.
• Between cloud EPGs and cloud external EPGs (cloudExtEPg)
Contracts govern the communication between cloud EPGs that are labeled providers, consumers, or both. The
relationship between a cloud EPG and a contract can be either a provider or consumer. When a cloud EPG
provides a contract, communication with the cloud endpoints in that cloud EPG can be initiated from cloud
endpoints in other cloud EPGs as long as the communication complies with the provided contract. When a
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
38
Cisco Cloud APIC Policy Model
Comma-separated Filters Support for Contract Rule Consolidation
cloud EPG consumes a contract, the cloud endpoints in the consuming cloud EPG may initiate communication
with any cloud endpoint in a cloud EPG that is providing that contract.
Note
A cloud EPG can both provide and consume the same contract. A cloud EPG can also provide and consume
multiple contracts simultaneously.
Comma-separated Filters Support for Contract Rule Consolidation
After a contract is created, some of the rules defined in the contract are consolidated and displayed in Azure
based on certain criteria. You can combine multiple ports and multiple IP addresses and ranges into a single,
easy-to-understand rule. The criteria for consolidation of rules are:
• Rules are consolidated only within a contract. Two rules resulting from two different contracts are not
consolidated in Azure.
• The source/ destination address prefixes and destination port(s) are consolidated.
• The conditions for multiple rules to get consolidated together in an NSG are:
• Same contract
• Same protocol (UDP, TCP,ICMP)
• Same direction (inbound , outbound)
• Same type (SG, IP)
• Overlapping port ranges for same protocol (TCP/UDP) in the same contract are consolidated to one
range.
For example, TCP ports 100-200, 150-250 are consolidated to 100-250.
• If 1.2.3.4/32 (any address prefixes) is allowed, and an ext EPG with 0.0.0.0/0 is added, then the allowed
Source/Destination IP would be Any, not [1.2.3.4/32, 0.0.0.0/0].
Example below shows the EPG1 outbound rules and the consolidated EPG1 outbound rules, based on contracts
C1 and C2.
Contract C1:
Consumer: EPG1 , Provider: EPG2
Filter: TCP (ports 53)
Filter: UDP (port 53, 5000)
Contract C2:
Consumer: EPG1 , Provider: EPG2
Filter: TCP (ports 80, 8080)
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
outbound rules:
-> EPG2
TCP 80
-> EPG2
TCP 8080
-> EPG2
TCP
-> EPG2
UDP 53
-> EPG2
UDP 5000
-> 1.1.1.1/32 TCP 80
-> 1.1.1.1/32 TCP 8080
53
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
39
Cisco Cloud APIC Policy Model
Filters and Subjects Govern Cloud EPG Communications
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
EPG1
->
->
->
->
->
->
->
->
1.1.1.1/32
1.1.1.1/32
1.1.1.1/32
2.2.2.2/32
2.2.2.2/32
2.2.2.2/32
2.2.2.2/32
2.2.2.2/32
TCP 53
UDP 53
UDP 5000
TCP 80
TCP 8080
TCP
53
UDP 53
UDP 5000
Rules are consolidated by comma-separated filters (consolidated based on C1 and C2):
EPG1 -> EPG2
TCP 80,8080
EPG1 -> EPG2
UDP 53,5000
EPG1 -> EPG2
TCP 53
EPG1 -> 1.1.1.1/32, 2.2.2.2/32
TCP 80,8080
EPG1 -> 1.1.1.1/32, 2.2.2.2/32
UDP 53,5000
EPG1 -> 1.1.1.1/32, 2.2.2.2/32
TCP 53
Filters and Subjects Govern Cloud EPG Communications
Subject and filter managed-objects enable mixing and matching among cloud EPGs and contracts so as to
satisfy various applications or service delivery requirements. The following figure shows the location of
application subjects and filters in the management information tree (MIT) and their relation to other objects
in the tenant.
Figure 16: Subjects and Filters
Contracts can contain multiple communication rules and multiple cloud EPGs can both consume and provide
multiple contracts. A policy designer can compactly represent complex communication policies and re-use
these policies across multiple instances of an application.
Note
Subjects are hidden in Cisco Cloud APIC and not configurable. For rules installed in Azure, source port
provided in the filter entry is not taken into account.
Subjects and filters define cloud EPG communications according to the following options:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
40
Cisco Cloud APIC Policy Model
About the Cloud Template
• Filters are Layer 3 to Layer 4 fields, TCP/IP header fields such as Layer 3 protocol type, Layer 4 ports,
and so forth. According to its related contract, a cloud EPG provider dictates the protocols and ports in
both the in and out directions. Contract subjects contain associations to the filters (and their directions)
that are applied between cloud EPGs that produce and consume the contract.
• Subjects are contained in contracts. A subject within a contract uses filters to specify the type of traffic
that can be communicated and how it occurs. For example, for HTTPS messages, the subject specifies
the direction and the filters that specify the IP address type (for example, IPv4), the HTTP protocol, and
the ports allowed. Subjects determine if filters are unidirectional or bidirectional. A unidirectional filter
is used in one direction. Unidirectional filters define in or out communications but not the same for both.
Bidirectional filters are the same for both; they define both in and out communications.
• ACI contracts rendered in Azure constructs are always stateful, allowing return traffic.
About the Cloud Template
The cloud template provides a template that configures and manages the Cisco Cloud APIC infra network.
The template requires only the most essential elements for the configuration. From these elements, the cloud
template generates a detailed configuration necessary for setting up the Cisco Cloud APIC infra network.
However, it is not a one-time configuration generation—it is possible to add, modify, or remove elements of
the template input. The cloud template updates the resulting configuration accordingly.
One of the central things in the Azure network configuration is the Virtual Private Cloud (VNET). Azure
supports many regions worldwide and one VNET is specific to one region.
The cloud template accepts one or more region names and generates the entire configuration for the infra
VNETs in those regions. They are the infra VNETs. The Cisco Cloud APIC-managed object (MO)
corresponding to the Azure VNET is cloudCtxProfile. For every region specified in the cloud template, it
generates the cloudCtxProfile configuration. A cloudCtxProfile is the topmost MO for all the configuration
corresponding to a region. Underneath, it has many of other MOs organized as a tree to capture a specific
configuration. The cloudCtxProfile MO for the infra VNet is generated by the cloud template. It carries
ctxProfileOwner == SYSTEM, which means that this MO is generated by the system. For the non-infra network,
it is possible to configure cloudCtxProfile directly; in this case, cloudCtxProfile carries ctxProfileOwner
== USER.
A primary property of an Azure VNet is the CIDR. In Cisco Cloud APIC, you can choose and deploy CIDRs
in the user VNets. The CIDRs for the infra VNet are provided by users to the cloud template during the initial
setup of the cloud site, and are deployed to the Azure cloud by the cloud template.
Beginning with Release 5.0(2), a new property called createdBy is added for the CIDR. The default value
for this createdBy property is USER.
• For all user-created CIDRs, the value for the createdBy property is set to USER.
• For cloud template-created CIDRs, the value for the createdBy property is set to SYSTEM.
In releases prior to Release 5.0(2), you are not allowed to add more CIDRs to the infra VNet. Beginning with
Release 5.0(2), multiple CIDR and subnet blocks can now be configured on the infra VNet. You can create
CIDRs and associate subnets in the infra VNet. The cloud template subnets will be mapped to the overlay-1
VRF, but the user-created subnets will be implicitly mapped to the overlay-2 VRF in the same infra VNet.
All subnets in the respective VRFs will have separate route tables in the cloud for VRF segregation.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
41
Cisco Cloud APIC Policy Model
About the Cloud Template
In addition, beginning with Release 5.0(2), you can create cloud EPGs and cloud external EPGs in the infra
tenant, where all the cloud EPGs and cloud external EPGs will be associated with the overlay-2 VRF in the
infra tenant. A cloud EPG in the overlay-2 VRF can communicate with other cloud EPGs and cloud external
EPGs in the overlay-2 VRF, and can also communicate with cloud EPGS in other user tenant VRFs. We
recommend that you do not use existing "cloud-infra" application profiles, and instead create a new application
profile in the infra tenant and associate that new application profile to the cloud EPGs and cloud external
EPGs in the overlay-2 VRF.
For more information, see Creating an Application EPG Using the Cisco Cloud APIC GUI, on page 55 and
About the Overlay-1 and Overlay-2 VRFs, on page 149.
The cloud template generates and manages a huge number of MOs in the cloudCtxProfile subtree including,
but not limited to, the following:
• Subnets
• Cloud routers
• IP address allocation for the cloud router interfaces
• IP address allocation and configuration for tunnels
• IP address allocation and configuration for loopbacks
Without the cloud template, you would be responsible for configuring and managing these.
The Cisco Cloud Template MO table contains a brief summary of the inputs (MOs) to the cloud template.
Table 4: Cloud Template MOs
MO
Purpose
cloudtemplateInfraNetwork
The root of the cloud template configuration.
Attributes include:
numRoutersPerRegion—The number of cloud routers
for each cloudRegionName specified under
cloudtemplateIntNetwork.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
42
Cisco Cloud APIC Policy Model
About the Cloud Template
MO
Purpose
cloudtemplateProfile
Configuration profile for all the cloud routers.
Attributes include:
• routerUsername
Note
• The username cannot be
"admin."
• Any username restrictions from
Azure applies.
• routerPassword
• routerThroughput
• routerLicenseToken
• routeDataInterfacePublicIP
• routerMgmtInterfacePublicIP
cloudtemplateIntNetwork
Contains a list of regions, which specify where you
deploy the cloud routers. Each region is captured
through a cloudRegionName child MO
cloudtemplateExtNetwork
Contains infra network configuration input that is
external of the cloud.
Contains a list of regions where cloud routers are
configured for external networking.
Each region is captured through a cloudRegionName
child MO
cloudtemplateVpnNetwork
Contains information for setting up a VPN with an
ACI on-premises site or another Cisco Cloud APIC
site.
cloudtemplateIpSecTunnel
Captures the IP address of the IPSec peer in the ACI
on-premises site.
cloudtemplateOspf
Captures the OSPF area to be used for the VPN
connections.
cloudtemplateBgpEvpn
Captures the peer IP address, ASN, and so forth, for
setting up the BGP session with the on-premises site.
In Cisco Cloud APIC, the layering of MOs is slightly different from a regular Cisco APIC due to the cloud
template. In a regular Cisco APIC, you post logical MOs that go through two layers of translation:
1. Logical MO to resolved MO
2. Resolved MO to concrete MO
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
43
Cisco Cloud APIC Policy Model
Managed Object Relations and Policy Resolution
In Cisco Cloud APIC, there is an additional layer of translation for the infra network. This additional layer is
where the cloud template translates logical MOs in the cloudtemplate namespace to logical MOs in the cloud
namespace. For configurations outside of the infra network, you post logical MOs in the cloud namespace.
In this case, the MOs go through the usual two-layer translation as in the regular Cisco APIC.
Figure 17: Cloud and Cloud Template MO Conversion
Note
For information about configuring the cloud template, see Configuring Cisco Cloud APIC Components, on
page 49
Managed Object Relations and Policy Resolution
Relationship-managed objects express the relation between managed object instances that do not share
containment (parent-child) relations. MO relations are established between the source MO and a target MO
in one of the following two ways:
• An explicit relation, such as with cloudRsCloudEPgCtx, defines a relationship that is based on the target
MO distinguished name (DN).
• A named relation defines a relationship that is based on the target MO name.
The dotted lines in the following figure show several common MO relations.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
44
Cisco Cloud APIC Policy Model
Default Policies
Figure 18: MO Relations
For example, the dotted line between the cloud EPG and the VRF defines the relation between those two
MOs. In this figure, the cloud EPG (cloudEPg) contains a relationship MO (cloudRsCloudEPgCtx) that is
named with the name of the target VRF MO (fvCtx). For example, if production is the VRF name
(fvCtx.name=production), then the relation name is production
(cloudRsCloudEPgCtx.tnFvCtxName=production).
In the case of policy resolution based on named relations, if a target MO with a matching name is not found
in the current tenant, the ACI cloud infrastructure tries to resolve in the common tenant. For example, if the
user tenant cloud EPG contained a relationship MO targeted to a VRF that did not exist in the tenant, the
system tries to resolve the relationship in the common tenant. If a named relation cannot be resolved in either
the current tenant or the common tenant, the ACI cloud infrastructure attempts to resolve to a default policy.
If a default policy exists in the current tenant, it is used. If it does not exist, the ACI cloud infrastructure looks
for a default policy in the common tenant. Cloud context profile, VRF, and contract (security policy) named
relations do not resolve to a default.
Default Policies
Warning
Default policies can be modified or deleted. Deleting a default policy can result in a policy resolution process
to complete abnormally.
The ACI cloud infrastructure includes default policies for many of its core functions. Examples of default
policies include the following:
• Cloud Azure provider (for the infra tenant)
• Monitoring and statistics
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
45
Cisco Cloud APIC Policy Model
Shared Services
Note
To avoid confusion when implementing configurations that use default policies, document changes made to
default policies. Be sure that there are no current or future configurations that rely on a default policy before
deleting a default policy. For example, deleting a default firmware update policy could result in a problematic
future firmware update.
A default policy serves multiple purposes:
• Allows a cloud infrastructure administrator to override the default values in the model.
• If an administrator does not provide an explicit policy, the Cisco CloudAPIC applies the default policy.
An administrator can create a default policy and the Cisco Cloud APIC uses that unless the administrator
provides any explicit policy.
The following scenarios describe common policy resolution behavior:
• A configuration explicitly refers to the default policy: if a default policy exists in the current tenant, it is
used. Otherwise, the default policy in tenant common is used.
• A configuration refers to a named policy (not default) that does not exist in the current tenant or in tenant
common: if the current tenant has a default policy, it is used. Otherwise, the default policy in tenant
common is used.
Note
The scenario above does not apply to a VRF in a tenant.
• A configuration does not refer to any policy name: if a default policy exists in the current tenant, it is
used. Otherwise, the default policy in tenant common is used.
The policy model specifies that an object is using another policy by having a relation-managed object (MO)
under that object and that relation MO refers to the target policy by name. If this relation does not explicitly
refer to a policy by name, then the system tries to resolve a policy that is called default. Cloud context profiles
and VRFs are exceptions to this rule.
Shared Services
Cloud EPGs in one tenant can communicate with cloud EPGs in another tenant through a contract interface
that is contained in a shared tenant. Within the same tenant, a cloud EPG in one VRF can communicate with
another cloud EPG in another VRF through a contract defined in the tenant. The contract interface is an MO
that can be used as a contract consumption interface by the cloud EPGs that are contained in different tenants.
By associating to an interface, a cloud EPG consumes the subjects that are represented by the interface to a
contract contained in the shared tenant. Tenants can participate in a single contract, which is defined at some
third place. More strict security requirements can be satisfied by defining the tenants, contract, subjects, and
filter directions so that tenants remain isolated from one another.
Follow these guidelines when configuring shared services contracts:
• A shared service is supported only with non-overlapping and non-duplicate CIDR subnets. When
configuring CIDR subnets for shared services, follow these guidelines:
• CIDR subnets leaked from one VRF to another must be disjointed and must not overlap.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
46
Cisco Cloud APIC Policy Model
Shared Services
• CIDR subnets advertised from multiple consumer networks into a VRF or vice versa must be
disjointed and must not overlap.
• Inter-tenant contracts require a global scope.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
47
Cisco Cloud APIC Policy Model
Shared Services
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
48
CHAPTER
4
Configuring Cisco Cloud APIC Components
• About Configuring the Cisco Cloud APIC, on page 49
• Configuring the Cisco Cloud APIC Using the GUI, on page 49
• Configuring Cisco Cloud APIC Using the REST API, on page 120
About Configuring the Cisco Cloud APIC
You create the Cisco Cloud APIC components using either the Cisco Cloud APIC GUI or the REST API.
This section explains how to create configuration, application management, operations, and administrative
components.
Note
• For information about configuring a load balancer and service graph, see Deploying Layer 4 to Layer 7
Services, on page 141.
• For information about the GUI, such as navigation and a list of configurable components, see About the
Cisco Cloud APIC GUI, on page 6.
Configuring the Cisco Cloud APIC Using the GUI
Creating a Tenant Using the Cisco Cloud APIC GUI
This section explains how to create a tenant using the Cisco Cloud APIC GUI.
Before you begin
• You can create a tenant that is managed by the Cisco Cloud APIC or a tenant that is unmanaged. To
establish a managed tenant, you must first obtain the Azure subscription ID from the Azure portal. You
enter the subscription ID in the appropriate field of the Cisco Cloud APIC when creating the tenant.
Before you can use the managed tenant, you must explicitly grant the Cisco Cloud APIC permission to
manage the subscription. The steps for doing so are displayed in the Cisco Cloud APIC GUI during
tenant creation. The steps for the infra tenant, however, are displayed in the infra tenant details view:
1. Click the Navigation menu > Application Management subtab.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
49
Configuring Cisco Cloud APIC Components
Creating a Tenant Using the Cisco Cloud APIC GUI
2. Double-click the infra tenant.
3. Click View Azure Role Assignment Command. The steps for granting the Cisco Cloud APIC
permission to manage the subscription are displayed.
Note
For information about obtaining the Azure subscription ID, see the Microsoft
Azure documentation.
• Creating an unmanaged tenant requires obtaining a directory (Azure Tenant) ID, an Azure enterprise
application ID, and a client secret from the enterprise application. For more information, see the Microsoft
Azure documentation.
Note
Cloud APIC does not disturb Azure resources created by other applications or
users. It only manages the Azure resources created by itself.
• The required steps to explicitly grant the Cisco Cloud APIC permission to manage a given subscription
are located in the Cisco Cloud APIC GUI. When creating a tenant, the steps are displayed after entering
the client secret.
• Cloud APIC enforces ownership checks to prevent deployment of policies in the same tenant-region
combination done either intentionally or by mistake. For example, assume that Cloud APIC is deployed
in Azure subscription IA1 in region R1. Now you want to deploy a tenant TA1 in region R2. This tenant
deployment i.e. account-region combination TA1-R2 is now owned by IA1-R1. If another Cloud APIC
attempts to manage the same tenant-region combination later (say Capic2 in Azure subscription IA2
deployed in region R3), this will not be allowed because the current owner for the deployment TA1-R2
is IA1-R1. In other words, only one account in one region can be managed by one Cloud APIC. Example
below shows some valid and wrong deployment combinations.
Capic1:
IA1-R1: TA1-R1 - ok
TA1-R2 - ok
Capic2:
IA1-R2: TA1-R1 - not allowed
TA1-R3 - ok
Capic3:
IA2-R1: TA1-R1 - not allowed
TA1-R4 - ok
TA2-R4 - ok
• Ownership enforcement is done using Azure Resource Groups. When a new tenant in subscription TA1
in region R2 is managed by Cloud APIC, a Resource Group CAPIC_TA1_R2 (e.g.
CAPIC_123456789012__eastus2) is created in the subscription. This Resource Group has a resource tag
AciOwnerTag with value IA1_R1_TA1_R2, assuming it was managed by Cloud APIC in subscription
IA1 and deployed in region R1. If the AciOwnerTag mismatch happens, tenant-region management is
aborted.
Here is a summary of AciOwnerTag mismatch cases:
• Initially Cloud APIC is installed in a subscription, and then taken down and Cloud APIC is installed
in a different subscription. All existing tenant-region deployment will fail.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
50
Configuring Cisco Cloud APIC Components
Creating a Tenant Using the Cisco Cloud APIC GUI
• Another Cloud APIC is managing the same tenant-region.
In ownership mismatch cases, retry (to setup tenant-region again) is not currently supported. As a
workaround, if you are certain that no other Cloud APIC is managing the same tenant-region combination,
logon to the tenant's Azure subscription and manually remove the affected Resource Group (for example:
CAPIC_123456789012__eastus2). Next, reload Cloud APIC or delete and add the tenant again.
• Prior to release 5.2(1), support varied for the method that could be used to access Azure resources,
depending on the type of tenant:
• Infra tenants: Prior to release 5.2(1), support is only available for managed identity when dealing
with authorization or credentials.
• User tenants: Support is available for both managed identity and unmanaged identity/service
principal when dealing with authorization or credentials.
Beginning with release 5.2(1), for both the infra tenants and the user tenants, support is now available
for both managed identity and unmanaged identity/service principal when dealing with authorization or
credentials.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Tenant. The Create Tenant dialog box
appears.
Step 4
Choose the appropriate options and enter the appropriate values in each field as listed in the following Create Tenant
Dialog Box Fields table then continue.
Table 5: Create Tenant Dialog Box Fields
Properties
Description
Name
Enter the name of the tenant.
Description
Enter a description of the tenant.
Settings
Add Security Domain
To add a security domain for the tenant:
a. Click Add Security Domain. The Select Security
Domains dialog appears with a list of security domains
in the left pane.
b. Click to choose a security domain.
c. Click Select to add the security domain to the tenant.
Azure Subscription
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
51
Configuring Cisco Cloud APIC Components
Creating a Tenant Using the Cisco Cloud APIC GUI
Properties
Description
Mode
Choose an account type:
• Create Own—Choose this option to create a new
tenant.
• Select Shared—Choose this option to inherit the
managed or unmanaged settings from an existing
tenant.
Azure Subscription ID
Enter the Azure subscription ID.
Access Type
Choose an access type:
• Service Principal or Unmanaged Identity—Choose
this option if the tenant subscription is not managed
by the Cisco Cloud APIC.
• Managed Identity—Choose this option if the tenant
subscription is managed by the Cisco Cloud APIC.
Note
Prior to release 5.2(1), you could only assign
Managed Identity to the infra tenant. For release
5.2(1) and later, you can now assign either
Service Principal or Managed Identity to the
infra tenant.
For more information, see Understanding Tenants,
Identities, and Subscriptions, on page 18.
Application ID
Note
This field is only valid for the Service Principal
or Unmanaged Identity access type.
Enter the application ID.
Note
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
52
For information about obtaining the application
ID, see the Azure documentation or support.
Configuring Cisco Cloud APIC Components
Creating an Application Profile Using the Cisco Cloud APIC GUI
Properties
Description
Client Secret
Note
This field is only valid for the Service Principal
or Unmanaged Identity access type.
Enter the client secret.
Note
• For information about creating a client
secret, see the Azure documentation or
support.
• You must explicitly grant Cloud APIC
permission to manage a given subscription.
Go to the Azure portal and follow these
steps:
a. Open the Cloud Shell
b. Choose 'Bash'
c. Copy and paste the command displayed
in the Cisco Cloud APIC GUI.
Active Directory ID
Note
This field is only valid for the Service Principal
or Unmanaged Identity access type.
Enter the active directory ID.
Note
Add Security Domain
For information about obtaining the active
directory ID, see the Azure documentation or
support.
To add a security domain for the account:
a. Click Add Security Domain. The Select Security
Domains dialog appears with a list of security domains
in the left pane.
b. Click to choose a security domain.
c. Click Select to add the security domain to the tenant.
Step 5
Click Save when finished.
Creating an Application Profile Using the Cisco Cloud APIC GUI
This section explains how to create an application profile using the Cisco Cloud APIC GUI.
Before you begin
Create a tenant.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
53
Configuring Cisco Cloud APIC Components
Creating a VRF Using the Cisco Cloud APIC GUI
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Application Profile. The Create Application
Profile dialog box appears.
Step 4
Enter a name in the Name field.
Step 5
Choose a tenant:
a) Click Select Tenant.
The Select Tenant dialog box appears.
b) From the Select Tenant dialog, click to choose a tenant in the left column then click Select.
You return to the Create Application Profile dialog box.
Step 6
Enter a description in the Description field.
Step 7
Click Save when finished.
Creating a VRF Using the Cisco Cloud APIC GUI
This section explains how to create a VRF using the Cisco Cloud APIC GUI.
Before you begin
Create a tenant.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create VRF. The Create VRF dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create VRF Dialog Box Fields table then continue.
Table 6: Create VRF Dialog Box Fields
Properties
Description
General
Name
Enter a name for the VRF in the Name field.
All VRFs are assigned a vrfEncoded value. If the Tenant and VRF name combination has more
than 32 characters, then, a VRF name (which also contains the tenant name) is identified in the
cloud router using the vrfEncoded value. To see the vrfEncoded value, navigate to Application
Management > VRFs subtab. Click a VRF on the right hand pane and look for Encoded VRF
Name in Cloud Router.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
54
Configuring Cisco Cloud APIC Components
Creating an EPG Using the Cisco Cloud APIC GUI
Properties
Description
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column then click Select.
You return to the Create VRF dialog box.
Description
Step 5
Enter a description of the VRF.
When finished, click Save.
Creating an EPG Using the Cisco Cloud APIC GUI
Use the procedures in this section to create an application EPG, an external EPG, or a service EPG. The
available configuration options vary, depending on which type of EPG you are creating.
Creating an Application EPG Using the Cisco Cloud APIC GUI
This section explains how to create an application EPG using the Cisco Cloud APIC GUI. Each service needs
at least one consumer EPG and one provider EPG.
Note
Beginning with Release 5.0(2), Cisco Cloud APIC creates the overlay-2 VRF in the infra tenant by default
during the bring up, along with the overlay-1 VRF.
In addition, beginning with Release 5.0(2), you can create cloud EPGs and cloud external EPGs in the infra
tenant, where all the cloud EPGs and cloud external EPGs will be associated with the overlay-2 VRF in the
infra tenant. A cloud EPG in the overlay-2 VRF can communicate with other cloud EPGs and cloud external
EPGs in the overlay-2 VRF, and can also communicate with cloud EPGS in other user tenant VRFs. We
recommend that you do not use existing "cloud-infra" application profiles, and instead create a new application
profile in the infra tenant and associate that new application profile to the cloud EPGs and cloud external
EPGs in the overlay-2 VRF.
Before you begin
Create an application profile and a VRF.
Step 1
Click the Intent icon.
The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create EPG.
The Create EPG dialog box appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
55
Configuring Cisco Cloud APIC Components
Creating an Application EPG Using the Cisco Cloud APIC GUI
Step 4
Enter the appropriate values in each field as listed in the following Create EPG Dialog Box Fields table then continue.
Table 7: Create EPG Dialog Box Fields
Properties
Description
General
Name
Enter the name of the EPG.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column.
Beginning with Release 5.0(2), you can select the infra tenant and can create cloud EPGs and cloud
external EPGs in the infra tenant, as described earlier in this section.
c. Click Select. You return to the Create EPG dialog box.
Application Profile
To choose an application profile:
a. Click Select Application Profile. The Select Application Profile dialog box appears.
b. From the Select Application Profile dialog, click to choose an application profile in the left column.
Note
If you are creating an EPG in the infra tenant, we recommend that you do not choose the
cloud-infra application profile because that application profile is used by EPGs in
the overlay-1 VRF. Select a different application profile or click Create Application
Profile to create a new one.
c. Click Select. You return to the Create EPG dialog box.
Description
Enter a description of the EPG.
Settings
Type
Because this will be an application EPG, choose Application as the EPG type.
VRF
To choose a VRF:
a. Click Select VRF. The Select VRF dialog box appears.
b. From the Select VRF dialog, click to choose a VRF in the left column.
If you are creating an EPG in the infra tenant, select the overlay-2 VRF in this step. A cloud EPG in
the overlay-2 VRF can communicate with other cloud EPGs and cloud external EPGs in the overlay-2
VRF, and can also communicate with cloud EPGs in other user tenant VRFs.
c. Click Select. You return to the Create EPG dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
56
Configuring Cisco Cloud APIC Components
Creating an Application EPG Using the Cisco Cloud APIC GUI
Properties
Description
Endpoint Selectors
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
57
Configuring Cisco Cloud APIC Components
Creating an Application EPG Using the Cisco Cloud APIC GUI
Properties
Description
Note
See Configuring Virtual Machines in Azure, on page 91 for instructions on configuring virtual
machines in Azure as part of the endpoint selector configuration process.
To add an endpoint selector:
a. Click Add Endpoint Selector to open the Add Endpoint Selector dialog.
b. In the Add Endpoint Selector dialog, enter a name in the Name field.
c. Click Selector Expression. The Key, Operator, and Value fields are enabled.
d. Click the Key drop-down list to choose a key. The options are:
• Choose IP if you want to use an IP address or subnet for the endpoint selector.
Note
IPv6 is not supported for Cisco Cloud APIC in Azure. You must use a valid IPv4
address for this field.
• Choose Region if you want to use the Azure region for the endpoint selector.
• Choose Custom if you want to create a custom key for the endpoint selector.
Note
When choosing the Custom option, the drop-down list becomes a text box. You need
to enter a name for the key in the spaces after custom: (for example, custom:
Location).
e. Click the Operator drop-down list to choose an operator. The options are:
• equals: Used when you have a single value in the Value field.
• not equals: Used when you have a single value in the Value field.
• in: Used when you have multiple comma-separated values in the Value field.
• not in: Used when you have multiple comma-separated values in the Value field.
• has key: Used if the expression contains only a key.
• does not have key: Used if the expression contains only a key.
f.
Enter a value in the Value field then click the check mark to validate the entries. The value you enter
depends on the choices you made for the Key and Operator fields. For example, if the Key field is
set to IP and the Operator field is set to equals, the Value field must be an IP address or subnet.
However, if the Operator field is set to has key, the Value field is disabled.
g. When finished, click the check mark to validate the selector expression.
h. Determine if you want to create additional endpoint selector expressions to the endpoint selector. If
you create more than one expression under a single endpoint selector, a logical AND exists between
those expressions.
For example, assume you created two sets of expressions under a single endpoint selector:
• Endpoint selector 1, expression 1:
• Key: Region
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
58
Configuring Cisco Cloud APIC Components
Creating an External EPG Using the Cisco Cloud APIC GUI
Properties
Description
• Operator: equals
• Value: westus
• Endpoint selector 1, expression 2:
• Key: IP
• Operator: equals
• Value: 192.0.2.1/24
In this case, if both of these expressions are true (if the region is westus AND if the IP address belongs
to subnet 192.0.2.1/24), then that endpoint is assigned to the Cloud EPG.
i.
Click the check mark after every additional expression that you want to create under this endpoint
selector then click Add when finished.
If you create more than one endpoint selector under an EPG, a logical OR exists between those
endpoint selectors. For example, assume you had created endpoint selector 1 as described in the
previous step, and then you created a second endpoint selector as described below:
• Endpoint selector 2, expression 1:
• Key: Region
• Operator: in
• Value: eastus, centralus
In this case:
• If the region is westus AND the IP address belongs to the 192.0.2.1/24 subnet (endpoint selector
1 expressions)
OR
• If the region is either eastus or centralus (endpoint selector 2 expression)
Then that end point is assigned to the Cloud EPG.
Step 5
Click Save when finished.
Creating an External EPG Using the Cisco Cloud APIC GUI
This section explains how to create an external EPG using the Cisco Cloud APIC GUI. Each service needs
at least one consumer EPG and one provider EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
59
Configuring Cisco Cloud APIC Components
Creating an External EPG Using the Cisco Cloud APIC GUI
Note
Beginning with Release 5.0(2), Cisco Cloud APIC creates the overlay-2 VRF in the infra tenant by default
during the bring up, along with the overlay-1 VRF.
In addition, beginning with Release 5.0(2), you can create cloud EPGs and cloud external EPGs in the infra
tenant, where all the cloud EPGs and cloud external EPGs will be associated with the overlay-2 VRF in the
infra tenant. A cloud EPG in the overlay-2 VRF can communicate with other cloud EPGs and cloud external
EPGs in the overlay-2 VRF, and can also communicate with cloud EPGS in other user tenant VRFs. We
recommend that you do not use existing "cloud-infra" application profiles, and instead create a new application
profile in the infra tenant and associate that new application profile to the cloud EPGs and cloud external
EPGs in the overlay-2 VRF.
Before you begin
Create an application profile and a VRF.
Step 1
Click the Intent icon.
The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create EPG.
The Create EPG dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create EPG Dialog Box Fields table then continue.
Table 8: Create EPG Dialog Box Fields
Properties
Description
General
Name
Enter the name of the EPG.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column.
Beginning with Release 5.0(2), you can select the infra tenant and can create cloud EPGs and cloud
external EPGs in the infra tenant, as described earlier in this section.
c. Click Select. You return to the Create EPG dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
60
Configuring Cisco Cloud APIC Components
Creating an External EPG Using the Cisco Cloud APIC GUI
Properties
Description
Application Profile
To choose an application profile:
a. Click Select Application Profile. The Select Application Profile dialog box appears.
b. From the Select Application Profile dialog, click to choose an application profile in the left column.
Note
If you are creating an EPG in the infra tenant, we recommend that you do not choose the
cloud-infra application profile because that application profile is used by EPGs in
the overlay-1 VRF. Select a different application profile or click Create Application
Profile to create a new one.
c. Click Select. You return to the Create EPG dialog box.
Description
Enter a description of the EPG.
Settings
Type
Because this will be an external EPG, choose External as the EPG type.
VRF
To choose a VRF:
a. Click Select VRF. The Select VRF dialog box appears.
b. From the Select VRF dialog, click to choose a VRF in the left column.
If you are creating an EPG in the infra tenant, select the overlay-2 VRF in this step. A cloud EPG in
the overlay-2 VRF can communicate with other cloud EPGs and cloud external EPGs in the overlay-2
VRF, and can also communicate with cloud EPGs in other user tenant VRFs.
c. Click Select. You return to the Create EPG dialog box.
Route Reachability
Choose the type of route reachability for the external EPG. The options are:
• Internet
• External-Site
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
61
Configuring Cisco Cloud APIC Components
Creating a Service EPG
Properties
Description
Endpoint Selectors
Note
See Configuring Virtual Machines in Azure, on page 91 for instructions on configuring virtual
machines in Azure as part of the endpoint selector configuration process.
To add an endpoint selector:
a. Click Add Endpoint Selector to add an endpoint selector.
b. Enter a name in the Name field.
c. Enter a subnet in the Subnet.
IPv6 is not supported for Cisco Cloud APIC in Azure. You must use a valid IPv4 address
for this field.
Note
d. When finished, click the check mark to validate the endpoint selector.
e. Determine if you want to create additional endpoint selectors.
If you create more than one endpoint selector under an EPG, a logical OR exists between those
endpoint selectors. For example, assume you created two endpoint selectors:
• Endpoint selector 1:
• Name: EP_Sel_1
• Subnet: 192.1.1.1/24
• Endpoint selector 2:
• Name: EP_Sel_2
• Subnet: 192.2.2.2/24
In this case:
• If the IP address belongs to the 192.1.1.1/24 subnet (endpoint selector 1)
OR
• If the IP address belongs to the 192.2.2.2/24 subnet (endpoint selector 2)
Then that end point is assigned to the Cloud EPG.
Step 5
Click Save when finished.
Creating a Service EPG
Use the procedures in the following sections to create a service EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
62
Configuring Cisco Cloud APIC Components
Tasks To Perform Prior to Configuring Service EPGs
Tasks To Perform Prior to Configuring Service EPGs
Before you can configure a service EPG, there are certain tasks that you might have to perform beforehand.
If you are using subnets or private link labels with your service EPG, you must first configure the subnets
and/or private link label outside of the service EPG.
Step 1
Create a VRF, if necessary.
a) Click the Intent icon. The Intent menu appears.
b) Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
c) From the Application Management list in the Intent menu, click Create VRF. The Create VRF dialog box appears.
d) Make the following selections:
• Name: Enter the name for the VRF.
• Tenant: Select a tenant.
e) Click Save.
Step 2
Configure a cloud context profile.
a) Click the Intent icon. The Intent menu appears.
b) Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
c) From the Application Management list in the Intent menu, click Create Cloud Context Profile. The Create Cloud
Context Profile dialog box appears.
Step 3
Enter the appropriate values in each field as listed in the following Cloud Context Profile Dialog Box Fields table then
continue.
Table 9: Create Cloud Context Profile Dialog Box Fields
Properties
Description
Name
Enter the name of the cloud context profile.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column then click Select. You
return to the Create Cloud Context Profile dialog box.
Description
Enter a description of the cloud context profile.
Settings
Region
To choose a region:
a. Click Select Region. The Select Region dialog box appears.
b. From the Select Region dialog, click to choose a region in the left column then click Select. You
return to the Create Cloud Context Profile dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
63
Configuring Cisco Cloud APIC Components
Tasks To Perform Prior to Configuring Service EPGs
Properties
Description
VRF
To choose a VRF:
a. Click Select VRF. The Select VRF dialog box appears.
b. From the Select VRF dialog box, click to choose a VRF in the left column then click Select. You
return to the Create Cloud Context Profile dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
64
Configuring Cisco Cloud APIC Components
Tasks To Perform Prior to Configuring Service EPGs
Properties
Description
Add CIDR
Note
You cannot add, delete, or edit a CIDR when VNet peering is enabled. You must disable VNet
peering before adding, deleting or editing a CIDR. To disable VNet peering:
• For the infra tenant, disable the Hub Network Peering option in the cloud context profile
• For a user (non-infra) tenant, disable the VNet Peering option in the cloud context profile
Enable VNet peering again after you have made the changes to the CIDR configuration.
The following features are supported, depending on the release:
• Beginning in Release 5.0(2), you can add additional secondary CIDRs and subnets for infra VNets
(cloudCtxProfiles created by the cloud template). You cannot add primary CIDRs or modify
the existing CIDRs created by the cloud template. After subnets are created under the user-created
CIDRs, the subnets will be implicitly mapped to the overlay-2 VRF.
• Beginning with Release 5.1(2), you can add also additional secondary CIDRs and subnets for VNets
other than the infra VNet.
See Support for Multiple VRFs Under Single VNet, on page 23 for more information.
To add a CIDR:
a. Click Add CIDR. The Add CIDR dialog box appears.
b. Enter the address in the CIDR Block Range field.
c. Click to check (enabled) or uncheck (disabled) the Primary check box.
If you are adding additional secondary CIDRs and subnets for VNets, leave the Primary box
unchecked.
d. Click Add Subnet and enter the following information:
• In the Address field, enter the subnet address.
• In the Name field, enter the name for this subnet.
• In the Private Link Label field, choose Create New and enter a unique name for the private
link label to associate with this subnet.
e. In the VRF field, make a selection, if necessary.
• If you checked the box next to the Primary field, this CIDR is automatically associated with
the primary VRF.
• If you did not check the box next to the Primary field, you can associate this CIDR with a
secondary VRF. Click the X next to the VRF, then click on Select VRF to select the secondary
VRF to associate with this CIDR.
f.
VNet Gateway Router
When finished, click Add.
Click to check (enable) or uncheck (disable) in the VNet Gateway Router check box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
65
Configuring Cisco Cloud APIC Components
Creating a Service EPG Using the Cisco Cloud APIC GUI
Properties
Description
VNet Peering
Click to check (enable) or uncheck (disable) the Azure VNet peering feature.
For more information on the VNet peering feature, see the Configuring VNet Peering for Cloud APIC
for Azure document in the Cisco Cloud APIC documentation page.
Step 4
Click Save.
Creating a Service EPG Using the Cisco Cloud APIC GUI
This section explains how to create a service EPG using the Cisco Cloud APIC GUI. Each service needs at
least one consumer EPG and one provider EPG.
Before you begin
• Review the information in Cloud Service Endpoint Groups, on page 27.
• Verify that you have the NSG-per-subnet configuration enabled.
You must have the NSG-per-subnet configuration enabled if you are configuring cloud service EPGs.
See Security Groups, on page 33 for more information.
• Create an application profile and a VRF.
Step 1
Click the Intent icon.
The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create EPG.
The Create EPG dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create EPG Dialog Box Fields table then continue.
Table 10: Create EPG Dialog Box Fields
Properties
Description
General
Name
Enter the name of the EPG.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column.
c. Click Select. You return to the Create EPG dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
66
Configuring Cisco Cloud APIC Components
Creating a Service EPG Using the Cisco Cloud APIC GUI
Properties
Description
Application Profile
To choose an application profile:
a. Click Select Application Profile. The Select Application Profile dialog box appears.
b. From the Select Application Profile dialog, click to choose an application profile in the left column.
Note
If you are creating a service EPG in the infra tenant, we recommend that you do not choose
the cloud-infra application profile because that application profile is used by EPGs
in the overlay-1 VRF. Select a different application profile or click Create Application
Profile to create a new one.
c. Click Select. You return to the Create EPG dialog box.
Description
Enter a description of the EPG.
Settings
Type
Because this will be a service EPG, choose Service as the EPG type.
VRF
To choose a VRF:
a. Click Select VRF. The Select VRF dialog box appears.
b. From the Select VRF dialog, click to choose a VRF in the left column.
c. Click Select. You return to the Create EPG dialog box.
Deployment Type
Choose the EPG deployment type.
Services are differentiated based on their deployment mode:
• Cloud Native: A Cloud Native service deployed in the provider network
• Cloud Native Managed: A Cloud Native service deployed in your network
• Third-Party: A third-party service from the market place
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
67
Configuring Cisco Cloud APIC Components
Creating a Service EPG Using the Cisco Cloud APIC GUI
Properties
Description
Access Type
Choose the EPG deployment access type. The access type indicates how the other services or VMs will
connect to the service.
The choices vary, depending on the selection you made in the Deployment Type field:
• Cloud Native deployment type:
• Public: Access the public IP of the service.
• Private: Use private links and private endpoints to access the service.
• Cloud Native Managed deployment type:
• Private: Choose this type if the service deployed in the managed subnet has only private IP
addresses.
• Public and Private: Use public and private endpoints to access the service. This is used for
services that also expose public IP addresses when deployed in Cisco Cloud APIC-managed
subnets.
• Third-Party deployment type: Private is the only option available to you as an access type. This
means that you will use only private endpoints to the service, if the service offers it.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
68
Configuring Cisco Cloud APIC Components
Configuring Cloud Native as the Deployment Type
Properties
Description
Service Type
Choose the Azure service type.
Certain service types are only supported with certain specific deployment types. See Cloud Service
Endpoint Groups, on page 27 for more information on the service types that are supported with specific
deployment types.
The options are:
• Azure Storage Blob (see Azure Storage, on page 29)
• Azure SQL
• Azure Cosmos DB
• Azure Databricks (see Azure Databricks Services, on page 30)
• Azure Storage (see Azure Storage, on page 29)
• Azure Storage File (see Azure Storage, on page 29)
• Azure Storage Queue (see Azure Storage, on page 29)
• Azure Storage Table (see Azure Storage, on page 29)
• Azure Kubernetes Services (AKS) (see Azure Kubernetes Services, on page 31)
• Azure Active Directory Domain Services (see Azure Active Directory Domain Services, on page
31)
• Azure Container Registry
• Azure ApiManagement Services (see Azure ApiManagement Services, on page 30)
• Azure Key Vault
• Redis Cache (see Azure Redis Cache, on page 31)
• Custom Service (used if you choose Third-Party as the Deployment Type)
Step 5
Enter the necessary information in the Endpoint Selector area, depending on the selection you made in the Deployment
Type field:
• If you chose Cloud Native as the deployment type, go to Configuring Cloud Native as the Deployment Type, on
page 69.
• If you chose Cloud Native Managed as the deployment type, go to Configuring Cloud Native Managed as the
Deployment Type, on page 72.
• If you chose Third-Party as the deployment type, go to Configuring Third-Party as the Deployment Type, on page
74.
Configuring Cloud Native as the Deployment Type
Use the procedures in this section to configure Cloud Native as the deployment type for the service EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
69
Configuring Cisco Cloud APIC Components
Configuring Cloud Native as the Deployment Type
Before you begin
Review the information provided in Cloud Native, on page 32 to understand tasks that you might have to
perform prior to using these instructions.
Step 1
Verify that you have completed the steps in Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66
before beginning these procedures.
These procedures are a continuation of the procedures provided in Creating a Service EPG Using the Cisco Cloud APIC
GUI, on page 66, where you would have set a service type, such as Azure SQL, before configuring the deployment
type in these procedures.
Step 2
If you selected Private as the access type, the Select Private Link Label option becomes available.
A private link label is used to associate the subnets to the service EPGs.
Step 3
Click Select Private Link Label.
The Select Private Link Label window appears.
Step 4
Search for the appropriate private link label.
Search for the private link label that you created using the procedures provided in Tasks To Perform Prior to Configuring
Service EPGs, on page 63.
Step 5
In the Select Private Link Label window, select the appropriate private link label.
You are returned to the Create EPG window.
Next, add an endpoint selector in the Endpoint Selectors field.
Step 6
Click Add Endpoint Selector.
The Add Endpoint Selector window appears.
Step 7
In the Add Endpoint Selector window, enter a name in the Name field.
Step 8
Click the Key drop-down list to choose a key.
The options are:
• Choose Custom if you want to create a custom endpoint selector.
• Choose Region if you want to use the Azure region for the endpoint selector.
• Choose Name if you want to use the service resource's name for the endpoint selector.
For example, to select an SQL server with the name ProdSqlServer, you would choose Name in the Key field,
and you would enter ProdSqlServer in the Value field later in these procedures.
• Choose Resource ID if you want to use the cloud provider's ID for the endpoint selector.
For example, to select an SQL server using the cloud provider's resource ID, you would choose Resouce ID in
the Key field, and you would enter the value of the selector, such as
/subscriptions/{subscription-id}/resourceGroups/{resourceGroupName}/providers/Microsoft.Sql/servers/ProdSqlServer,
in the Value field later in these procedures.
Step 9
Click the Operator drop-down list to choose an operator.
The options are:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
70
Configuring Cisco Cloud APIC Components
Configuring Cloud Native as the Deployment Type
• equals: Used when you have a single value in the Value field.
• not equals: Used when you have a single value in the Value field.
• in: Used when you have multiple comma-separated values in the Value field.
• not in: Used when you have multiple comma-separated values in the Value field.
• has key: Used if the expression contains only a key.
• does not have key: Used if the expression contains only a key.
Step 10
Enter a value in the Value field then click the check mark to validate the entries.
The value you enter depends on the choices you made for the Key and Operator fields.
For example, if the Key field is set to IP and the Operator field is set to equals, the Value field must be an IP address
or subnet. However, if the Operator field is set to has key, the Value field is disabled.
Step 11
When finished, click the check mark to validate the selector expression.
Step 12
Determine if you want to create additional endpoint selector expressions for the endpoint selector.
If you create more than one expression under a single endpoint selector, a logical AND exists between those expressions.
For example, assume you created two sets of expressions under a single endpoint selector:
• Endpoint selector 1, expression 1:
• Key: Region
• Operator: equals
• Value: westus
• Endpoint selector 1, expression 2:
• Key: Name
• Operator: equals
• Value: ProdSqlServer
In this case, if both of these expressions are true (if the region is westus AND if the name attached to the resource is
ProdSqlServer), then that endpoint is assigned to the service EPG.
Step 13
Click the check mark after every additional expression that you want to create under this endpoint selector, then click
Add when finished.
You are returned to the Create EPG screen, with the new endpoint selector and the configured expressions shown.
Step 14
If you want to create additional endpoint selectors, click Add Endpoint Selector again and repeat these steps to create
additional endpoint selectors.
If you create more than one endpoint selector under an EPG, a logical OR exists between those endpoint selectors. For
example, assume you had created endpoint selector 1 as described in the previous step, and then you created a second
endpoint selector as described below:
• Endpoint selector 2, expression 1:
• Key: Region
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
71
Configuring Cisco Cloud APIC Components
Configuring Cloud Native Managed as the Deployment Type
• Operator: in
• Value: eastus, centralus
In this case:
• If the region is westus AND the name attached to the resource is ProdSqlServer (endpoint selector 1 expressions)
OR
• If the region is either eastus or centralus (endpoint selector 2 expression)
Then that end point is assigned to the service EPG.
Step 15
Click Save when finished.
Configuring Cloud Native Managed as the Deployment Type
Use the procedures in this section to configure Cloud Native Managed as the deployment type for the service
EPG.
Before you begin
Review the information provided in Cloud Native Managed, on page 33 to understand tasks that you might
have to perform prior to using these instructions.
Step 1
Verify that you have completed the steps in Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66
before beginning these procedures.
These procedures are a continuation of the procedures provided in Creating a Service EPG Using the Cisco Cloud APIC
GUI, on page 66, where you would have set a service type, such as Azure ApiManagement Services, before configuring
the deployment type in these procedures.
Step 2
Click Add Endpoint Selector.
The Add Endpoint Selector window appears.
Step 3
In the Add Endpoint Selector window, enter a name in the Name field.
Step 4
Click the Key drop-down list to choose a key.
At this time, IP is the only option available as a key for this access type.
Note
Step 5
IPv6 is not supported for Cisco Cloud APIC in Azure. You must use a valid IPv4 address for this field.
Click the Operator drop-down list to choose an operator.
The options are:
• equals: Used when you have a single value in the Value field.
• not equals: Used when you have a single value in the Value field.
• in: Used when you have multiple comma-separated values in the Value field.
• not in: Used when you have multiple comma-separated values in the Value field.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
72
Configuring Cisco Cloud APIC Components
Configuring Cloud Native Managed as the Deployment Type
• has key: Used if the expression contains only a key.
• does not have key: Used if the expression contains only a key.
Step 6
Enter the appropriate IP address or a subnet in the Value field then click the check mark to validate the entries.
Enter the IP address or subnet that you created using the procedures provided in Tasks To Perform Prior to Configuring
Service EPGs, on page 63.
Step 7
When finished, click the check mark to validate the selector expression.
Step 8
Determine if you want to create additional endpoint selector expressions to the endpoint selector.
If you create more than one expression under a single endpoint selector, a logical AND exists between those expressions.
For example, assume you created two sets of expressions under a single endpoint selector:
• Endpoint selector 1, expression 1:
• Key: IP
• Operator: equals
• Value: 192.1.1.1/24
• Endpoint selector 1, expression 2:
• Key: IP
• Operator: not equals
• Value: 192.1.1.2
In this case, if both of these expressions are true (if the IP address belongs to subnet 192.1.1.1/24 AND the IP address
is not 192.1.1.2), then that endpoint is assigned to the service EPG.
Step 9
Click the check mark after every additional expression that you want to create under this endpoint selector, then click
Add when finished.
You are returned to the Create EPG screen, with the new endpoint selector and the configured expressions shown.
Step 10
If you want to create additional endpoint selectors, click Add Endpoint Selector again and repeat these steps to create
additional endpoint selectors.
If you create more than one endpoint selector under an EPG, a logical OR exists between those endpoint selectors. For
example, assume you had created endpoint selector 1 as described in the previous step, and then you created a second
endpoint selector as described below:
• Endpoint selector 2, expression 1:
• Key: IP
• Operator: equals
• Value: 192.2.2.2/24
In this case:
• If the IP address belongs to subnet 192.1.1.1/24 AND the IP address is not 192.1.1.2 (endpoint selector 1 expressions)
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
73
Configuring Cisco Cloud APIC Components
Configuring Third-Party as the Deployment Type
OR
• If the IP address belongs to subnet 192.2.2.2/24
Then that end point is assigned to the service EPG.
Step 11
Click Save when finished.
Configuring Third-Party as the Deployment Type
Use the procedures in this section to configure Third-Party as the deployment type for the service EPG.
Note
Step 1
You must choose Custom as the Service Type if you choose Third-Party as the Deployment Type.
Verify that you have completed the steps in Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66
before beginning these procedures.
These procedures are a continuation of the procedures provided in Creating a Service EPG Using the Cisco Cloud APIC
GUI, on page 66, where you would have set the service type as Custom Service before configuring the deployment
type in these procedures.
Step 2
Make the necessary selections for the access type for the Third-Party deployment type.
Private is the only option available to you as an access type. This means that you will use only private endpoints to
the service, if the service offers it.
The Select Private Link Label option becomes available with this access type. A private link label is used to associate
the subnets to the service EPGs.
Step 3
Search for the appropriate private link label.
Search for the private link label that you created using the procedures provided in Tasks To Perform Prior to Configuring
Service EPGs, on page 63.
Step 4
In the Select Private Link Label window, select the appropriate private link label.
You are returned to the Create EPG window.
Next, add an endpoint selector in the Endpoint Selectors field.
Step 5
Click Add Endpoint Selector.
The Add Endpoint Selector window appears.
Step 6
In the Add Endpoint Selector window, enter a name in the Name field.
Step 7
Click the Key drop-down list to choose a key.
At this time, URL is the only option available as a key for this access type, where you will use the alias or fully qualified
domain name (FQDN) that identifies the service for the endpoint selector.
Step 8
Click the Operator drop-down list to choose an operator.
The options are:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
74
Configuring Cisco Cloud APIC Components
Creating a Filter Using the Cisco Cloud APIC GUI
• equals: Used when you have a single value in the Value field.
• not equals: Used when you have a single value in the Value field.
• in: Used when you have multiple comma-separated values in the Value field.
• not in: Used when you have multiple comma-separated values in the Value field.
• has key: Used if the expression contains only a key.
• does not have key: Used if the expression contains only a key.
Step 9
Enter a valid URL in the Value field then click the check mark to validate the entries.
Step 10
When finished, click the check mark to validate the selector expression, then click Add.
You are returned to the Create EPG screen, with the new endpoint selector and the configured expression shown.
Step 11
If you want to create additional endpoint selectors, click Add Endpoint Selector again and repeat these steps to create
additional endpoint selectors.
If you create more than one endpoint selector under an EPG, a logical OR exists between those endpoint selectors.
For example, assume you created two endpoint selectors as described below:
• Endpoint selector 1:
• Key: URL
• Operator: equals
• Value: www.acme1.com
• Endpoint selector 2:
• Key: URL
• Operator: equals
• Value: www.acme2.com
In this case:
• If the URL is www.acme1.com
OR
• If the URL is www.acme2.com
Then that end point is assigned to the service EPG.
Step 12
Click Save when finished.
Creating a Filter Using the Cisco Cloud APIC GUI
This section explains how to create a filter using the Cisco Cloud APIC GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
75
Configuring Cisco Cloud APIC Components
Creating a Filter Using the Cisco Cloud APIC GUI
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Filter. The Create Filter dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Filter Dialog Box Fields table then continue.
Table 11: Create Filter Dialog Box Fields
Properties
Description
Name
Enter a name for the filter in the Name field.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box
appears.
b. From the Select Tenant dialog, click to choose a tenant
in the left column then click Select. You return to the
Create Filter dialog box.
Description
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
76
Enter a description of the filter.
Configuring Cisco Cloud APIC Components
Creating a Contract Using the Cisco Cloud APIC GUI
Properties
Description
Add Filter
To add a filter:
a. Click Add Filter Entry. The Add Filter Entry dialog
box appears.
b. Enter a name for the filter entry in the Name field.
c. Click the Ethernet Type drop-down list to choose an
ethernet type. The options are:
• IP
• Unspecified
Note
When Unspecified is chosen, any
traffic type is alloed, including IP, and
the remaining fields are disabled.
d. Click the IP Protocol drop-down menu to choose a
protocol. The options are:
• tcp
• udp
• Unspecified
Note
The remaining fields are enabled only
when tcp or udp is chosen.
e. Enter the appropriate port range information in the
Destination Port fields.
f.
Step 5
When finished entering filter entry information, click
Add. You return to the Create Filter dialog box where
you can repeat the steps to add another filter entry.
When finished, click Save.
Creating a Contract Using the Cisco Cloud APIC GUI
This section explains how to create a contract using the Cisco Cloud APIC GUI.
Before you begin
Create filters.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
77
Configuring Cisco Cloud APIC Components
Creating a Contract Using the Cisco Cloud APIC GUI
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Contract. The Create Contract dialog box
appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Contract Dialog Box Fields table then continue.
Table 12: Create Contract Dialog Box Fields
Properties
Description
Name
Enter the name of the contract.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column.
Beginning in Release 5.0(2), you can create contracts in the infra tenant. You
can also export contracts from and import contracts to the infra tenant for shared
services use cases.
Note
c. Click Select. You return to the Create Contract dialog box.
Description
Enter a description of the contract.
Settings
Scope
The scope limits the contract to any endpoint groups within the same application profile, within
the same VRF instance, throughout the fabric (globally), or within the same tenant.
Note
Shared services enables communication between EPGs in different tenants and
between EPGs in different VRFs.
To enable EPGs in one tenant to communicate with EPGs in another tenant, choose
Global scope.
To enable an EPG in one VRF to communicate with another EPG in a different VRF,
choose Global or Tenant scope.
For more information about shared services, see Shared Services, on page 46.
Click the drop-down arrow to choose from the following scope options:
• Application Profile
• VRF
• Global
• Tenant
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
78
Configuring Cisco Cloud APIC Components
Creating an Inter-Tenant Contract Using the Cisco Cloud APIC GUI
Properties
Description
Add Filter
To choose a filter:
a. Click Add Filter. The filter row appears with a Select Filter option.
b. Click Select Filter. The Select Filter dialog box appears.
c. From the Select Filter dialog, click to choose a filter in the left column then click Select.
You return to the Create Contract dialog box.
Step 5
Click Save when finished.
Creating an Inter-Tenant Contract Using the Cisco Cloud APIC GUI
This section explains how to create an inter-tenant contract using the Cisco Cloud APIC GUI. See Shared
Services, on page 46 for more information on situations where you might want to create an inter-tenant
contract.
Before you begin
Create filters.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
Step 4
From the Application Management list in the Intent menu, click Create Contract. The Create Contract dialog box
appears.
Enter the appropriate values in each field as listed in the following Create Contract Dialog Box Fields table then continue.
Table 13: Create Contract Dialog Box Fields
Properties
Description
Name
Enter the name of the contract.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column.
Note
Beginning in Release 5.0(2), you can create contracts in the infra tenant. You
can also export contracts from and import contracts to the infra tenant for shared
services use cases.
c. Click Select. You return to the Create Contract dialog box.
Description
Enter a description of the contract.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
79
Configuring Cisco Cloud APIC Components
Creating an Inter-Tenant Contract Using the Cisco Cloud APIC GUI
Properties
Description
Settings
The scope limits the contract to any endpoint groups within the same application profile, within
the same VRF instance, throughout the fabric (globally), or within the same tenant.
Scope
For inter-tenant communication, you will first create a contract with the Global scope in one
of the tenants (for example, tenant1). This tenant’s EPG will always be the provider of this
contract.
This contract will then be exported to the other tenant (for example, tenant2). For the other
tenant that imports this contract, its EPG will be the consumer of the imported contract. If you
want tenant2’s EPG to be the provider and tenant1’s EPG to be the consumer, then create a
contract in tenant2 and then export it to tenant1.
Add Filter
To choose a filter:
a. Click Add Filter. The filter row appears with a Select Filter option.
b. Click Select Filter. The Select Filter dialog box appears.
c. From the Select Filter dialog, click to choose a filter in the left column then click Select.
You return to the Create Contract dialog box.
Step 5
Click Save when finished.
Step 6
Export the contract that you just created to another tenant.
For example, assume the following:
• The contract that you created in the procedure above is named contract1 in tenant tenant1.
• The contract that you want to export is named exported_contract1 and you are exporting it to tenant tenant2.
a) Navigate to the Contracts page (Application Management > Contracts).
The configured contracts are listed.
b) Select the contract that you just created.
For example, scroll through the list until you see the contract contract1 and click the box next to it to select it.
c) Go to Actions > Export Contract.
The Export Contract window appears.
d) Click Select Tenant.
The Select Tenant window appears.
e) Select the tenant that you want to export the contract to, then click Save.
For example, tenant2. You are returned to the Export Contract window.
f) In the Name field, enter a name for the exported contract.
For example, exported_contract1.
g) In the Description field, enter a description for the exported contract, if necessary.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
80
Configuring Cisco Cloud APIC Components
Creating an Inter-Tenant Contract Using the Cisco Cloud APIC GUI
h) Click Save.
The list of contracts appears again.
Step 7
Configure the first tenant's EPG as the provider EPG, with the original contract, as the first part of the EPG communication
configuration.
a) Click the Intent button, then choose EPG Communication.
The EPG Communication window appears.
b) Click Let's Get Started.
c) In the Contract area, click Select Contract.
The Select Contract window appears.
d) Locate and select the contract that you created at the beginning of these procedures.
In this example, you would locate and select contract1.
e) Click Select.
The EPG Communication window appears.
f) In the Provider EPGs area, click Add Provider EPGs.
The Select Provider EPGs window appears.
g) Leave the Keep selected items box checked, then select the first tenant's (tenant1) EPG.
h) Click Select.
The EPG Communication window appears.
i) Click Save.
Step 8
Configure the second tenant's EPG as the consumer EPG, with the exported contract, as the second part of the EPG
communication configuration.
a) Click the Intent button, then choose EPG Communication.
The EPG Communication window appears.
b) Click Let's Get Started.
c) In the Contract area, click Select Contract.
The Select Contract window appears.
d) Locate and select the contract that you created at the beginning of these procedures.
In this example, you would locate and select exported_contract1.
e) Click Select.
The EPG Communication window appears.
f) In the Consumer EPGs area, click Add Consumer EPGs.
The Select Consumer EPGs window appears.
g) Leave the Keep selected items box checked, then select the second tenant's (tenant2) EPG.
h) Click Select.
The EPG Communication window appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
81
Configuring Cisco Cloud APIC Components
Configuring Network Security Groups Using the Cloud APIC GUI
i) Click Save.
Configuring Network Security Groups Using the Cloud APIC GUI
As described in Security Groups, on page 33, the way the network security groups are configured differ,
depending on the release:
• For releases prior to Release 5.1(2), there is a one-to-one mapping between NSGs in Azure and EPGs
on Cisco Cloud APIC (these configurations are also referred to as NSG-per-EPG configurations
throughout this document).
• Beginning with Release 5.1(2), in addition to the existing NSG-per-EPG configurations available
previously, NSGs in Azure can also have a one-to-one mapping with subnets rather than EPGs on Cisco
Cloud APIC (these configurations are also referred to as NSG-per-subnet configurations throughout
this document).
Note
You can have either the newer NSG-per-subnet configuration or the older NSG-per-EPG configuration in
your Cisco Cloud APIC. You cannot have both configurations in the same Cisco Cloud APIC system.
These procedures describe how to select either the newer NSG-per-subnet configuration or the older
NSG-per-EPG configuration for your Cisco Cloud APIC for Release 5.1(2) or later.
Before you begin
Review the information provided in Security Groups, on page 33 to better understand how security groups
are configured, depending on the release, and to understand the guidelines and limitations for security groups.
Step 1
Log in to the Cloud APIC, if you are not logged in already.
Step 2
In the left navigation bar, navigate to Infrastructure > System Configuration.
The General tab is displayed by default.
Step 3
In the General area in the System Configuration window, locate the Network Security Group at Subnet Level field.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
82
Configuring Cisco Cloud APIC Components
Configuring Network Security Groups Using the Cloud APIC GUI
Step 4
Determine the current setting for the Network Security Group at Subnet Level field.
• If you see Enabled as the value in this field, that means that you have the newer NSG-per-subnet configuration
for your Cisco Cloud APIC.
• If you see Disabled as the value in this field, that means that you have the older NSG-per-EPG configuration for
your Cisco Cloud APIC.
Step 5
Determine if you want to change the setting for the Network Security Group at Subnet Level field or leave it as-is.
Desired Configuration
Existing Configuration
Action
If you want to have the newer
NSG-per-subnet configuration for your
Cisco Cloud APIC, and:
You see Enabled as the value in the
Your Cisco Cloud APIC is already set up
Network Security Group at Subnet Level with the NSG-per-subnet configuration
field, then:
that you want. You do not have to make
any changes.
You see Disabled as the value in the
You will have to change the setting in the
Network Security Group at Subnet Level Network Security Group at Subnet Level
field. Go to Step 6, on page 84.
field, then:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
83
Configuring Cisco Cloud APIC Components
Configuring Network Security Groups Using the Cloud APIC GUI
Desired Configuration
Existing Configuration
Action
If you want to have the older
NSG-per-EPG configuration for your
Cisco Cloud APIC, and:
You will have to change the setting in the
You see Enabled as the value in the
Network Security Group at Subnet Level Network Security Group at Subnet Level
field. Go to Step 6, on page 84.
field, then:
You see Disabled as the value in the
Your Cisco Cloud APIC is already set up
Network Security Group at Subnet Level with the NSG-per-EPG configuration that
field, then:
you want. You do not have to make any
changes.
Step 6
If you have to change the setting in the Network Security Group at Subnet Level field, click the pencil icon in the
upper right corner of the field.
The Settings window for Network Security Group at Subnet Level appears.
Step 7
Make the necessary changes in this window.
Note
Changing the network security group setting will result in traffic loss. If you have to change the network security
group setting, we recommend that you make the change during a maintenance window.
• If you want to have the newer NSG-per-subnet configuration for your Cisco Cloud APIC and you do not see a
check in the box next to the Enabled field in this window, then click the box to add the check mark. This allows
you to enable the newer NSG-per-subnet configuration for your Cisco Cloud APIC.
• If you want to have the older NSG-per-EPG configuration for your Cisco Cloud APIC and you see a check in the
box next to the Enabled field in this window, then click the box to remove the check mark. This allows you to
disable the newer NSG-per-subnet configuration, and to enable the older NSG-per-EPG configuration, for your
Cisco Cloud APIC.
Note the following:
• Changing the setting from the newer NSG-per-subnet to the older NSG-per-EPG configuration is not
recommended. Disabling the NSG-per-subnet setting means losing support for service EPG configurations
and will result in traffic loss.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
84
Configuring Cisco Cloud APIC Components
Viewing Security Group Details
• If you have a service EPG or a private link label configured, you will not be able to disable the NSG-per-subnet
configuration. You must disable the configured service EPG and/or a private link label before you can disable
the NSG-per-subnet configuration.
• To disable a configured service EPG:
a. Navigate to Application Management > EPGs.
b. Locate the EPGs with Service shown in the Type column.
c. Select the service EPG that you want to delete, then click Actions > Delete EPG.
• To disable a configured private link label:
a. Navigate to Application Management > Cloud Context Profiles.
b. Locate the necessary cloud context profile and click on that profile.
A panel showing details for this cloud context profile slides in from the right side of the window.
c. Click the Details icon (
).
Another window appears that provides more detailed information for this cloud context profile. In the
CIDRs area, you should see the text Private Link Labels in the Subnets column.
d. Click the pencil icon in the upper right corner of the window.
The Edit Cloud Context Profile window appears.
e. In the Settings area, locate the CIDRs area again and click the pencil icon in that row.
The Edit CIDR window appears.
f.
In the Subnets area, locate the row with an entry in the Private Link Label column and click on the
pencil icon for that subnet row.
The entries on this subnet row become editable.
g. Click the X next to the entry in the Private Link Label column for that subnet row.
This removes the private link label.
Step 8
Click Save after you have made the necessary changes in the Network Security Group at Subnet Level window.
The General area in the System Configuration window appears again, and the setting in the Network Security Group
at Subnet Level field reflects the change that you made in the previous step.
Viewing Security Group Details
Step 1
Log into your Cisco Cloud APIC GUI, if you aren't logged in already.
Step 2
Navigate to Cloud Resources > Security Groups.
The Security Groups window appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
85
Configuring Cisco Cloud APIC Components
Specifying Consumer and Provider EPGs Using the Cisco Cloud APIC
Step 3
Click on the Network Security Groups (NSG) tab or the Application Security Groups ASG tab, depending on which
type of security group that you want to get details on.
The following information is provided in each tab:
• Network Security Groups tab:
• Name: The name of the network security group.
• Cloud Provider ID: The cloud provider ID that is associated with the network security group.
Note that the value provided in the Name and the Cloud Provider ID fields will show whether the NSGs are
configured with the newer NSG-per-subnet configuration (shown as subnet- in the Cloud Provider ID column)
or with the older NSG-per-EPG configuration (shown as epg- in the Cloud Provider ID column). See Security
Groups, on page 33 for more information on the different types of NSG configurations available, depending
on the software release.
• EPGs: The EPG that is associated with the network security group, if you have the older NSG-per-EPG
configuration.
• Virtual Machines: The virtual machine that is associated with the network security group.
• Endpoints: The endpoints that are associated with the network security group.
• Subnets: The subnets that are associated with the network security group, if you have the newer NSG-per-subnet
configuration.
• Application Security Groups tab:
• Health: The health status for the application security group.
• Name: The name of the application security group.
• Cloud Provider ID: The cloud provider ID that is associated with the application security group.
• EPGs: The EPG that is associated with the application security group.
• Virtual Machines: The virtual machine that is associated with the application security group.
• Endpoints: The endpoints that are associated with the application security group.
Step 4
Click on the value in any of the columns to get more detailed information.
For example, clicking on a value in the Name column in the Network Security Groups tab will being up more detailed
information about that particular network security group.
In this window, clicking on the Details icon ( ) brings up another window that provides more detailed information for
this security group, such as cloud resources information, including ingress and egress rules.
Specifying Consumer and Provider EPGs Using the Cisco Cloud APIC
This section explains how to specify an EPG as a consumer or a provider.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
86
Configuring Cisco Cloud APIC Components
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI
Before you begin
• You have configured a contract.
• You have configured an EPG.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Configuration.
A list of Configuration options appears in the Intent menu.
Step 3
From the Configuration list in the Intent menu, click EPG Communication. The EPG Communication dialog box
appears with the Consumer EPGs, Contract, and Provider EPGs information.
Step 4
To choose a contract:
a) Click Select Contract. The Select Contract dialog appears.
b) In the pane on the left side of the Select Contract dialog, click to choose a contract then click Select. The Select
Contract dialog box closes.
Step 5
To add a consumer EPG:
a) Click Add Consumer EPGs. The Select Consumer EPGs dialog appears.
Note
EPGs within the tenant (where the contract is created) are displayed.
b) In the pane on the left side of the Select Consumer EPGs dialog, click to place a check in a check box to choose an
EPG.
Step 6
To add a provider EPG:
a) Click Add Provider EPGs. The Select Provider EPGs dialog appears.
Note
EPGs within the tenant (where the contract is created) are displayed.
b) In the pane on the left side of the Select Provider EPGs dialog, click to place a check in a check box to choose a
provider EPG.
Note
If the chosen contract is an Imported Contract, the provider EPG selection is disabled.
c) When finished, click Select. The Select Provider EPGs dialog box closes, and you return to the EPG Communication
Configuration window.
d) Click Save.
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI
This section explains how to create a cloud context profile using the Cisco Cloud APIC GUI.
Before you begin
Create a VRF.
Step 1
Click the Intent icon. The Intent menu appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
87
Configuring Cisco Cloud APIC Components
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Cloud Context Profile. The Create Cloud
Context Profile dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Cloud Context Profile Dialog Box Fields table then
continue.
Table 14: Create Cloud Context Profile Dialog Box Fields
Properties
Description
Name
Enter the name of the cloud context profile.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box appears.
b. From the Select Tenant dialog, click to choose a tenant in the left column then click Select.
You return to the Create Cloud Context Profile dialog box.
Description
Enter a description of the cloud context profile.
Settings
Region
To choose a region:
a. Click Select Region. The Select Region dialog box appears.
b. From the Select Region dialog, click to choose a region in the left column then click Select.
You return to the Create Cloud Context Profile dialog box.
VRF
To choose a VRF:
a. Click Select VRF. The Select VRF dialog box appears.
b. From the Select VRF dialog box, click to choose a VRF in the left column then click Select.
You return to the Create Cloud Context Profile dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
88
Configuring Cisco Cloud APIC Components
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI
Properties
Description
Add CIDR
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
89
Configuring Cisco Cloud APIC Components
Creating a Cloud Context Profile Using the Cisco Cloud APIC GUI
Properties
Description
Note
You cannot add, delete, or edit a CIDR when VNet peering is enabled. You must
disable VNet peering before adding, deleting or editing a CIDR. To disable VNet
peering:
• For the infra tenant, disable the Hub Network Peering option in the cloud
context profile
• For a user (non-infra) tenant, disable the VNet Peering option in the cloud
context profile
Enable VNet peering again after you have made the changes to the CIDR
configuration.
The following features are supported, depending on the release:
• Beginning in Release 5.0(2), you can add additional secondary CIDRs and subnets for
infra VNets (cloudCtxProfiles created by the cloud template). You cannot add
primary CIDRs or modify the existing CIDRs created by the cloud template. After subnets
are created under the user-created CIDRs, the subnets will be implicitly mapped to the
overlay-2 VRF.
• Beginning with Release 5.1(2), you can add also additional secondary CIDRs and subnets
for VNets other than the infra VNet.
See Support for Multiple VRFs Under Single VNet, on page 23 for more information.
To add a CIDR:
a. Click Add CIDR. The Add CIDR dialog box appears.
b. Enter the address in the CIDR Block Range field.
c. Click to check (enabled) or uncheck (disabled) the Primary check box.
If you are adding additional secondary CIDRs and subnets for VNets, leave the Primary
box unchecked.
d. Click Add Subnet and enter the following information:
• In the Address field, enter the subnet address.
• In the Name field, enter the name for this subnet.
• In the Private Link Label field, choose one of the following:
• Select Existing: Click Select Private Link Label, then choose an existing private
link label to associate with this subnet.
• Create New: Enter a unique name for the private link label to associate with this
subnet.
e. In the VRF field, make a selection, if necessary.
• If you checked the box next to the Primary field, this CIDR is automatically associated
with the primary VRF.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
90
Configuring Cisco Cloud APIC Components
Configuring Virtual Machines in Azure
Properties
Description
• If you did not check the box next to the Primary field, you can associate this CIDR
with a secondary VRF. Click the X next to the VRF, then click on Select VRF to select
the secondary VRF to associate with this CIDR.
f.
When finished, click Add.
VNet Gateway
Router
Click to check (enable) or uncheck (disable) in the VNet Gateway Router check box.
VNet Peering
Click to check (enable) or uncheck (disable) the Azure VNet peering feature.
For more information on the VNet peering feature, see the Configuring VNet Peering for Cloud
APIC for Azure document in the Cisco Cloud APIC documentation page.
Step 5
Click Save when finished.
Configuring Virtual Machines in Azure
When you configure endpoint selectors for Cisco Cloud APIC, you will also need to configure the virtual
machines that you will need in Azure that will correspond with the endpoint selectors that you configure for
Cisco Cloud APIC.
This topic provides the requirements for configuring the virtual machines in Azure. You can use these
requirements to configure the virtual machines in Azure either before you configure the endpoint selectors
for Cisco Cloud APIC or afterward. For example, you might go to your account in Azure and create a custom
tag or label in Azure first, then create an endpoint selector using a custom tag or label in Cisco Cloud APIC
afterward. Or you might create an endpoint selector using a custom tag or label in Cisco Cloud APIC first,
then go to your account in Azure and create a custom tag or label in Azure afterward.
Before you begin
You must configure a cloud context profile as part of the Azure virtual machine configuration process. When
you configure a cloud context profile, the configurations, such as the VRF and region settings, are pushed out
to Azure afterward.
Step 1
Review your cloud context profile configuration to get the following information:
• VRF name
• Subnet information
• Subscription Id
• The resource group that corresponds to where the cloud context profile is deployed.
Note
In addition to the information above, if you are using tag-based EPGs, you also need to know the tag names.
The tag names are not available in the cloud context profile configuration.
To obtain the cloud context profile configuration information:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
91
Configuring Cisco Cloud APIC Components
Creating a Backup Configuration Using the Cisco Cloud APIC GUI
a) From the Navigation menu, choose the Application Management tab.
When the Application Management tab expands, a list of subtab options appear.
b) Choose the Cloud Context Profiles subtab option.
A list of the cloud context profiles that you have created for your Cisco Cloud APIC are displayed.
c) Select the cloud context profile that you will use as part of this Azure virtual machine configuration process.
Various configuration parameters are displayed for this cloud context profile, such as the region, VRF, IP address
and subnets. Use the information displayed in this window when you configure the Azure virtual machine.
Step 2
Log in to the Azure portal account for the Cisco Cloud APIC user tenant and begin creating an Azure VM using the
information you gathered from the cloud context profile configuration.
For information about how to create the VM in the Azure portal, see the Microsoft Azure documentation.
Note
Creating a Backup Configuration Using the Cisco Cloud APIC GUI
This section explains how to create a backup configuration.
Before you begin
Create a remote location and a scheduler, if needed.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Operations.
A list of Operations options appear in the Intent menu.
Step 3
From the Operations list in the Intent menu, click Create Backup Configuration. The Create Backup Configuration
dialog box appears.
Enter the appropriate values in each field as listed in the following Create Backup Configuration Dialog Box Fields table
then continue.
Step 4
Table 15: Create Backup Configuration Dialog Box Fields
Properties
Description
General
Name
Enter the name of the backup configuration.
Description
Enter a description of the backup configuration.
Settings
Backup Destination
Choose a backup destination.
• Local
• Remote
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
92
Configuring Cisco Cloud APIC Components
Creating a Backup Configuration Using the Cisco Cloud APIC GUI
Properties
Description
Backup Object
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
93
Configuring Cisco Cloud APIC Components
Creating a Backup Configuration Using the Cisco Cloud APIC GUI
Properties
Description
Choose the root hierarchical content to consider for the
backup
• Policy Universe
• Selector Object—When chosen, this option adds the
Object Type drop-down list and Object DN field.
a. From the Object Type drop-down list, choose
from the following options:
• Tenant—When chosen the Select Tenant
option appears.
• Application Profile—When chosen the
Select Application Profile option appears.
• EPG—When chosen the Select EPG option
appears.
• Contract—When chosen the Select Contract
option appears.
• Filter—When chosen the Select Filter option
appears.
• VRF—When chosen the Select VRFoption
appears.
• Device—When chosen the Select
fvcloudLBCtxoption appears.
• Service Graph—When chosen the Select
Service Graph option appears.
• Cloud Context Profile—When chosen the
Select Cloud Context Profile option appears.
b. Click the Select <object_name>. The Select
<object_name> dialog appears.
c. From the Select <object_name> dialog, click to
choose from the options in the left column then
click Select. You return to the Create Backup
Configuration dialog box.
Note
The Object DN field is automatically
populated with the DN of the object it
will use as root of the object tree to
backup
• Enter DN—When chosen, this option displays the
Object DN field.
a. From the Object DN field, enter the DN of a
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
94
Configuring Cisco Cloud APIC Components
Creating a Tech Support Policy Using the Cisco Cloud APIC GUI
Properties
Description
specific object to use as the root of the object tree
to backup.
Scheduler
a. Click Select Scheduler to open the Select Scheduler
dialog and choose a scheduler from the left-side column.
b. Click the Select button at the bottom-right corner when
finished.
Trigger Backup After Creation
Choose one of the following:
• Yes—(Default) Trigger a backup after creating the
backup configuration.
• No—Do not trigger a backup after creating the backup
configuration.
Step 5
Click Save when finished.
Creating a Tech Support Policy Using the Cisco Cloud APIC GUI
This section explains how to create a tech support policy.
Before you begin
When creating a tech support policy for a remote location, you must first create the remote location.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Operations.
A list of Operations options appear in the Intent menu.
Step 3
From the Operations list in the Intent menu, click Create Tech Support. The Create Tech Support dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Tech Support Dialog Box Fields table then
continue.
Table 16: Create Tech Support Dialog Box Fields
Properties
Description
General
Name
Enter the name of the tech support policy.
Description
Enter a description of the tech support.
Settings
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
95
Configuring Cisco Cloud APIC Components
Creating a Scheduler Using the Cisco Cloud APIC GUI
Properties
Description
Export Destination
Choose an export destination.
• Controller
• Remote Location—When chosen the Select Remote
Location option appears.
a. Click Select Remote Location. The Select
Remote Location dialog box appears.
b. From the Select Remote Location dialog, click
to choose a remote location in the left column then
click Select. You return to the Create Tech
Suport dialog box.
Step 5
Include Pre-Upgrade Logs
Click to place a check in the Enabled check box if you
want to include pre-upgrade logs in the tech support policy.
Trigger After Creation
Click to place a check in the Enabled (the default) check
box if you want to create the tech support policy after the
policy creation. To disable, click the check box to uncheck.
Click Save when finished.
Creating a Scheduler Using the Cisco Cloud APIC GUI
This section explains how to create a scheduler, which would be in User Laptop Browser local time and will
be converted to the Cisco Cloud APIC default UTC time.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Operations.
A list of Operations options appear in the Intent menu.
Step 3
From the Operations list in the Intent menu, click Create Scheduler. The Create Scheduler dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Scheduler Dialog Box Fields table then continue.
Table 17: Create Scheduler Dialog Box Fields
Properties
Description
General
Name
Enter the name of the trigger scheduler policy.
Description
Enter a description of the trigger scheduler.
Settings
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
96
Configuring Cisco Cloud APIC Components
Creating a Scheduler Using the Cisco Cloud APIC GUI
Properties
Description
Recurring Windows
Click Add Recurring Window. The Add Recurring
Window dialog appears.
a. From the Schedule drop-down list, choose from the
following.
• every-day
• Monday
• Tuesday
• Wednesday
• Thursday
• Friday
• Saturday
• Sunday
• odd-day
• even-day
b. From the Start Time field, enter a time.
c. From the Maximum Concurrent Tasks field, enter a
number or leave the field empty to specify unlimited.
d. From the Maximum Running Time, click to choose
Unlimited or Custom.
e. Click Add when finished.
Add One Time Window
Click Add One Time Window. The Add One Time
Window dialog appears.
a. From the Start Time field, enter a date and time.
b. From the Maximum Concurrent Tasks field, enter a
number or leave the field blank to specify unlimited.
c. From the Maximum Running Time, click to choose
Unlimited or Custom.
d. Click Add when finished.
Step 5
Click Save when finished.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
97
Configuring Cisco Cloud APIC Components
Creating a Remote Location Using the Cisco Cloud APIC GUI
Creating a Remote Location Using the Cisco Cloud APIC GUI
This section explains how to create a remote location using the Cisco Cloud APIC.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Operations.
A list of Operations options appear in the Intent menu.
Step 3
From the Operations list in the Intent menu, click Create Remote Location. The Create Remote Location dialog box
appears.
Enter the appropriate values in each field as listed in the following Create Remote Location Dialog Box Fields table then
continue.
Step 4
Table 18: Create Remote Location Dialog Box Fields
Properties
Description
General
Name
Enter the name of the remote location policy.
Description
Enter a description of the remote location policy.
Settings
Hostname/IP Address
Enter the hostname or IP address of the remote location
Protocol
Choose a protocol:
• FTP
• SFTP
• SCP
Path
Enter the path for the remote location.
Port
Enter the port for the remote location.
Username
Enter a username for the remote location.
Authentication Type
When using SFTP or SCP, choose the authentication type:
• Password
• SSH Key
SSH Key Content
Enter the SSH key content.
SSH Key Passphrase
SSH key passphrase.
Password
Enter a password for accessing the remote location.
Confirm Password
Reenter the password for accessing the remote location.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
98
Configuring Cisco Cloud APIC Components
Creating a Login Domain Using the Cisco Cloud APIC GUI
Step 5
Click Save when finished.
Creating a Login Domain Using the Cisco Cloud APIC GUI
This section explains how to create a login domain using the Cisco Cloud APIC GUI.
Before you begin
Create a provider before creating a non-local domain.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Create Login Domain. The Create Login Domain dialog box
appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Login Domain Dialog Box Fields table then
continue.
Table 19: Create Login Domain Dialog Box Fields
Properties
Description
Name
Enter the name of the login domain.
Description
Enter a description of the login domain.
Realm
Choose a realm:
• Local
• LDAP—Requires adding providers and choosing an
authenication type.
• RADIUS—Requires adding providers.
• TACACS+—Requires adding providers.
• SAML—Requires adding providers.
Providers
To add a provider:
a. Click Add Providers. The Select Providers dialog
appears with a list of providers in the left pane.
b. Click to choose a provider.
c. Click Select to add the provider.
Advanced Settings
Displays the Authentication Type and LDAP Group Map
Rules fields.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
99
Configuring Cisco Cloud APIC Components
Creating a Login Domain Using the Cisco Cloud APIC GUI
Properties
Description
Authentication Type
When LDAP is chosen for realm option, choose one of the
following authentication types:
• Cisco AV Pairs—(Default)
• LDAP Group Map Rules—Requires adding LDAP
group map rules.
LDAP Group Map Rules
To add an LDAP group map rule:
a. Click Add LDAP Group Map Rule. The Add LDAP
Group Map Rule dialog appears with a list of providers
in the left pane.
b. Enter a name for the rule in the Name field.
c. Enter a description for the rule in the Description field.
d. Enter a group DN for the rule in the Group DN field.
e. Add security domains:
1. Click Add Security Domain. The Add Security
Domain dialog box appears.
2. Click Select Security Domain. The Select Security
Domain dialog box appears with a list of security
domains in the left pane.
3. Click to choose a security domain.
4. Click Select to add the security domain. You return
to the Add Security Domain dialog box.
5. Add a user role:
a. From the Add Security Domain dialog box,
click Select Role. The Select Role dialog box
appears with a list of roles in the left pane.
b. Click to choose a role.
c. Click Select to add the role. You retun to the
Add Security Domain dialog box.
d. From the Add Security Domain dialog box,
click the Privilege Type drop-down list and
choose Read Privilege or Write Privilege.
e. Click the check mark on the right side of the
Privilege Type drop-down list to confirm.
f.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
100
Click Add when finished. You return to the
Add LDAP Group Map Rule dialog box
where you can add another security domain.
Configuring Cisco Cloud APIC Components
Creating a Security Domain Using the Cisco Cloud APIC GUI
Step 5
Click Save when finished.
Creating a Security Domain Using the Cisco Cloud APIC GUI
A security domain restricts the tenant to the security domains that you add. If you do not add a security domain,
all security domains will have access to this tenant. This section explains how to create a security domain
using the GUI.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Security > Security Domains > Create Security Domain. The
Create Security Domain dialog box appears.
Step 4
In the Name field, enter the name of the security domain.
Step 5
In the Description field, enter a description of the security domain.
Step 6
Set the Restricted Domain control to Yes or No.
If the security domain is configured as a restricted domain (Yes), users who are assigned to this domain will not be able
to see policies, profiles, or users configured in other security domains.
Step 7
Click Save when finished.
Creating a Role Using the Cisco Cloud APIC GUI
This section explains how to create a role using the Cisco Cloud APIC GUI.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Create Role. The Create Role dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Role Dialog Box Fields table then continue.
Table 20: Create Role Dialog Box Fields
Properties
Description
General
Name
Enter a name for the role in the Name field.
Description
Enter a description of the role.
Settings
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
101
Configuring Cisco Cloud APIC Components
Creating a Role Using the Cisco Cloud APIC GUI
Properties
Privilege
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
102
Description
Configuring Cisco Cloud APIC Components
Creating a Role Using the Cisco Cloud APIC GUI
Properties
Description
Click to place a check mark in the check boxes of the
privileges you want to assign the user. The privileges are:
• aaa—Used for configuring authentication,
authorization, accouting and import/export policies.
• access-connectivity-l1Used for Layer 1 configuration
under infra. Example: selectors and port Layer 1 policy
configurations.
• access-connectivity-l2—Used for Layer 2
configuration under infra. Example: Encap
configurations on selectors, and attachable entity.
• access-connectivity-l3—Used for Layer 3
configuration under infra and static route
configurations under a tenant's L3Out.
• access-connectivity-mgmt—Used for management
infra policies.
• access-connectivity-util—Used for tenant ERSPAN
policies.
• access-equipment—Used for access port
configuration.
• access-protocol-l1—Used for Layer 1 protocol
configurations under infra.
• access-protocol-l2—Used for Layer 2 protocol
configurations under infra.
• access-protocol-l3—Used for Layer 3 protocol
configurations under infra.
• access-protocol-mgmt—Used for fabric-wide policies
for NTP, SNMP, DNS, and image management.
• access-protocol-ops—Used for operations-related
access policies such as cluster policy and firmware
policies.
• access-protocol-util—Used for tenant ERSPAN
policies.
• access-qos—Used for changing CoPP and QoS-related
policies.
• admin—Complete access to everything (combine ALL
roles)
• fabric-connectivity-l1—Used for Layer 1
configuration under the fabric. Example: selectors and
port Layer 1 policy and VNET protection.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
103
Configuring Cisco Cloud APIC Components
Creating a Role Using the Cisco Cloud APIC GUI
Properties
Description
• fabric-connectivity-l2—Used in firmware and
deployment policies for raising warnings for estimating
policy deployment impact.
• fabric-connectivity-l3—Used for Layer 3
configuration under the fabric. Example: Fabric IPv4
and MAC protection groups.
• fabric-connectivity-mgmt—Used for atomic counter
and diagnostic policies on leaf switches and spine
switches.
• fabric-connectivity-util—Used for atomic counter,
diagnostic, and image management policies on leaf
switches and spine switches.
• fabric-equipment—Used for atomic counter,
diagnostic, and image management policies on leaf
switches and spine switches.
• fabric-protocol-l1—Used for Layer 1 protocol
configurations under the fabric.
• fabric-protocol-l2—Used for Layer 2 protocol
configurations under the fabric.
• fabric-protocol-l3—Used for Layer 3 protocol
configurations under the fabric.
• fabric-protocol-mgmt—Used for fabric-wide policies
for NTP, SNMP, DNS, and image management.
• fabric-protocol-ops—Used for ERSPAN and health
score policies.
• fabric-protocol-util—Used for firmware management
traceroute and endpoint tracking policies.
• none—No privilege.
• nw-svc-device—Used for managing Layer 4 to Layer
7 service devices.
• nw-svc-devshare—Used for managing shared Layer
4 to Layer 7 service devices.
• nw-svc-params—Used for managing Layer 4 to Layer
7 service policies.
• nw-svc-policy—Used for managing Layer 4 to Layer
7 network service orchestration.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
104
Configuring Cisco Cloud APIC Components
Creating a Role Using the Cisco Cloud APIC GUI
Properties
Description
• ops—Used for operational policies including
monitoring and troubleshooting policies such as atomic
counter, SPAN, TSW, tech support, traceroute,
analytics, and core policies.
• tenant-connectivity-l1—Used for Layer 1 connectivity
changes, including bridge domains and subnets.
• tenant-connectivity-l2—Used for Layer 2 connectivity
changes, including bridge domains and subnets.
• tenant-connectivity-l3—Used for Layer 3 connectivity
changes, including VRFs.
• tenant-connectivity-mgmt—Used for tenant in-band
and out-of-band management connectivity
configurations and for debugging/monitoring policies
such as atomic counters and health score.
• tenant-connectivity-util—Used for atomic counter,
diagnostic, and image management policies on leaf
switches and spine switches.
• tenant-epg—Used for managing tenant configurations
such as deleting/creating endpoint groups, VRFs, and
bridge domains.
• tenant-ext-connectivity-l2—Used for managing tenant
L2Out configurations.
• tenant-ext-connectivity-l3—Used for managing tenant
L3Out configurations.
• tenant-ext-connectivity-mgmt—Used as write access
for firmware policies.
• tenant-ext-connectivity-util—Used for
debugging/monitoring/observer policies such as
traceroute, ping, oam, and eptrk.
• tenant-ext-protocol-l1—Used for managing tenant
external Layer 1 protocols. Generally only used for
write access for firmware policies.
• tenant-ext-protocol-l2—Used for managing tenant
external Layer 2 protocols. Generally only used for
write access for firmware policies.
• tenant-ext-protocol-l3—Used for managing tenant
external Layer 3 protocols such as BGP, OSPF, PIM,
and IGMP.
• tenant-ext-protocol-mgmt—Used as write access for
firmware policies.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
105
Configuring Cisco Cloud APIC Components
Creating a Certificate Authority Using the Cisco Cloud APIC GUI
Properties
Description
• tenant-ext-protocol-util—Used for
debugging/monitoring/observer policies such as
traceroute, ping, oam, and eptrk.
• tenant-network-profile—Used for managing tenant
configurations, such as deleting and creating network
profiles, and deleting and creating endpoint groups.
• tenant-protocol-l1—Used for managing
configurations for Layer 1 protocols under a tenant.
• tenant-protocol-l2—Used for managing
configurations for Layer 2 protocols under a tenant.
• tenant-protocol-l3—Used for managing
configurations for Layer 3 protocols under a tenant.
• tenant-protocol-mgmt—Only used as write access
for firmware policies.
• tenant-protocol-ops—Used for tenant traceroute
policies.
• tenant-protocol-util—Used for
debugging/monitoring/observer policies such as
traceroute, ping, oam, and eptrk.
• tenant-qos—Only used as Write access for firmware
policies.
• tenant-security—Used for Contract related
configurations for a tenant.
• vmm-connectivity—Used to read all the objects in
APIC's VMM inventory required for VM connectivity.
• vmm-ep—Used to read VM and Hypervisor endpoints
in the APIC's VMM inventory.
• vmm-policy—Used for managing policies for VM
networking.
• vmm-protocol-ops—Not used by VMM policies.
• vmm-security—Used for Contract related
configurations for a tenant.
Step 5
Click Save when finished.
Creating a Certificate Authority Using the Cisco Cloud APIC GUI
This section explains how to create a certificate authority using the GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
106
Configuring Cisco Cloud APIC Components
Creating a Certificate Authority Using the Cisco Cloud APIC GUI
Before you begin
• Have the certificate chain.
• If the certificate authority is for a tenant, create the tenant.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appears in the Intent menu.
Step 3
Step 4
From the Administrative list in the Intent menu, click Create Certificate Authority. The Create Certificate Authority
dialog box appears.
Enter the appropriate values in each field as listed in the following Create Certificate Authority Dialog Box Fields table
then continue.
Table 21: Create Certificate Authority Dialog Box Fields
Properties
Description
Name
Enter the name of the certificate authority.
Description
Enter a description of the certificate authority.
Used for
Choose from the following options:
• Tenant—Choose if the certificate authority is for a
specific tenant. When chosen, the Select Tenant option
appears in the GUI.
• System—Choose if the certificate authority is for the
system.
Select Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box
appears.
b. From the Select Tenant dialog, click to choose a tenant
in the left column then click Select. You return to the
Create Certificate Authority dialog box.
Certificate Chain
Enter the certificate chain in the Certificate Chain text
box.
Note
Add the certificates for a chain in the following
order:
a. CA
b. Sub-CA
c. Subsub-CA
d. Server
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
107
Configuring Cisco Cloud APIC Components
Creating a Key Ring Using the Cisco Cloud APIC GUI
Step 5
Click Save when finished.
Creating a Key Ring Using the Cisco Cloud APIC GUI
This section explains how to create a key ring using the Cisco Cloud APIC GUI.
Before you begin
• Create a certificate authority.
• Have a certificate.
• If the key ring is for a specific tenant, create the tenant.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Create Key Ring. The Create Key Ring dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Key Ring Dialog Box Fields table then continue.
Table 22: Create Key Ring Dialog Box Fields
Properties
Description
Name
Enter the name of the key ring.
Description
Enter a description of the key ring.
Used for
• System—The key ring is for the system.
• Tenant—The key ring is for a specific tenant. Displays
a Tenant field for specifying the tenant.
Select Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog box
appears.
b. From the Select Tenant dialog, click to choose a tenant
in the left column then click Select. You return to the
Create Key Ring dialog box.
Settings
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
108
Configuring Cisco Cloud APIC Components
Creating a Local User Using the Cisco Cloud APIC GUI
Properties
Description
Certificate Authority
To choose a certificate authority:
a. Click Select Certificate Authority. The Select
Certificate Authority dialog appears.
b. Click to choose a certificate authority in the column on
the left.
c. Click Select. You return to the Create Key Ring dialog
box.
Choose one of the following:
Private Key
• Generate New Key—Generates a new key.
• Import Existing Key—Displays the Private Key text
box and enables you to use an existing key.
Private Key
Enter an existing key in the Private Key text box (for the
Import Existing Key option).
Modulus
Click the Modulus drop-down list to choose from the
following:
• MOD 512
• MOD 1024
• MOD 1536
• MOD 2048—(Default)
Enter the certificate information in the Certificate text box.
Certificate
Step 5
Click Save when finished.
Creating a Local User Using the Cisco Cloud APIC GUI
This section explains how to create a local user using the Cisco Cloud APIC GUI.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Create Local User. The Create Local User dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Local User Dialog Box Fields table then
continue.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
109
Configuring Cisco Cloud APIC Components
Creating a Local User Using the Cisco Cloud APIC GUI
Table 23: Create Local User Dialog Box Fields
Properties
Description
Name
Enter the username of the local user.
Password
Enter the password for the local user.
Confirm Password
Reenter the password for the local user.
Description
Enter a description of the local user.
Settings
Account Status
To choose the account status:
• Active—Activates the local user account.
• Inactive—Deactivates the local user account.
First Name
Enter the first name of the local user.
Last Name
Enter the last name of the local user.
Email Address
Enter the email address of the local user.
Phone Number
Enter the phone number of the local user.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
110
Configuring Cisco Cloud APIC Components
Creating a Local User Using the Cisco Cloud APIC GUI
Properties
Description
Security Domains
To add a security domain:
a. Click Add Security Domain. The Add Security
Domain dialog box appears.
b. Click Select Security Domain. The Select Security
Domain dialog box appears with a list of security
domains in the left pane.
c. Click to choose a security domain.
d. Click Select to add the security domain. You return to
the Add Security Domain dialog box.
e. Add a user role:
1. From the Add Security Domain dialog box, click
Select Role. The Select Role dialog box appears
with a list of roles in the left pane.
2. Click to choose a role.
3. Click Select to add the the role. You retun to the
Add Security Domain dialog box.
4. From the Add Security Domain dialog box, click
the Privilege Type drop-down list and choose Read
Privilege or Write Privilege.
5. Click the check mark on the right side of the
Privilege Type drop-down list to confirm.
6. Click Add when finished. You return to the Create
Local User dialog box where you can add another
security domain.
Step 5
Click Advanced Settings and enter the appropriate values in each field as listed in the following Create Local User
Dialog Box Fields: Advanced Settings table then continue.
Table 24: Create Local User Dialog Box Fields: Advanced Settings
Property
Description
Account Expires
If you choose Yes, the account is set to expire at the time
that you choose.
Password Update Required
If you choose Yes, the user must change the password upon
the next login.
OTP
Put a check in the box to enable the one-time password
feature for the user.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
111
Configuring Cisco Cloud APIC Components
Managing Regions (Configuring a Cloud Template) Using the Cisco Cloud APIC GUI
Property
Description
User Certificates
To add a user certificate:
a. Click Add X509 Certificate. The Add X509
Certificate dialog box appears.
b. Enter a name in the Name field.
c. Enter the X509 certificate in the User X509 Certificate
text box.
d. Click Add. The X509 certificate in the User X509
Certificate dialog box closes. You return to the Local
User dialog box.
To add a an SSH key:
SSH Keys
a. Click Add SSH Key. The Add SSH Key dialog box
appears.
b. Enter a name in the Name field.
c. Enter the SSH key in the Key text box.
d. Click Add. The Add SSH Key dialog box closes. You
return to the Local User dialog box.
Step 6
Click Save when finished.
Managing Regions (Configuring a Cloud Template) Using the Cisco Cloud APIC
GUI
Regions are configured during the first-time setup. When configured, you specify the regions that are managed
by Cisco Cloud APIC and the region's inter-site and inter-region connectivity. This section explains how to
manage regions with the cloud template using the Cisco Cloud APIC GUI after the initial installation.
For more information about cloud templates, see About the Cloud Template, on page 41.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Configuration.
A list of options appear in the Intent menu.
Step 3
From the Configuration list in the Intent menu, click cAPIC Setup.
The Set up - Overview dialog box appears with options for DNS and NTP Servers, Region Management, and Smart
Licensing.
Step 4
For Region Management, click Edit Configuration.
The Setup - Region Management dialog box appears. and the first step in the Setup - Region Management series of
steps appears, Regions to Manage, with a list of managed regions.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
112
Configuring Cisco Cloud APIC Components
Managing Regions (Configuring a Cloud Template) Using the Cisco Cloud APIC GUI
Step 5
If you want inter-site connectivity, click to place a check mark in the Enabled box in the Inter-Site Connectivity area.
The Inter-Site Connectivity step is added in the Setup - Region Management steps at the top of the page.
Step 6
To choose a region that you want to be managed by the Cisco Cloud APIC, click to place a check mark in check box
of that region.
Step 7
To deploy cloud routers locally to this region, click to place a check mark in the Cloud Routers check box for that
region.
Step 8
To configure the fabric infra connectivity for the cloud site, click Next.
The next step in the Setup - Region Management series of steps appears, General Connectivity.
Step 9
To add a subnet pool for the CSRs, click Add Subnet Pool for Cloud Router and enter the subnet in the text box.
Note
Step 10
The /24 subnet provided during the Cloud APIC deployment would be sufficient for up to two cloud sites.
If you need to manage more than two cloud sites, you need to add more subnets.
Enter a value in the BGP Autonomous System Number for CSRs field.
The BGP ASN can be in the range of 1 - 65534.
Step 11
In the Assign Public IP to CSR Interface field, determine if you want to have a public or a private IP address assigned
to the CSR interface.
Note that CSRs require a public IP address for intersite communication.
• To have a public IP address assigned to the CSR interface, leave the check in the Enabled check box. By default,
the Enabled check box is checked.
• To have a private IP address assigned to the CSR interface, uncheck the Enabled check box. A private IP address
is used for connectivity in this case.
Note
Changing a CSR address from a public IP address to a private IP address (or vice-versa) is a disruptive
operation and can result in traffic loss.
Beginning with release 5.1(2), both the public and private IP addresses assigned to a CSR are displayed with the other
details of the router in the Cloud Resources area. If a public IP is not assigned to a CSR, only the private IP is displayed.
Step 12
To chose the number of routers per region, click the Number of Routers Per Region drop-down list and click 2, 3, 4,
6, or 8.
Step 13
Enter a username in the Username text box.
Note
Do not use admin as a username for the Cisco Cloud Services Router when connecting to an Azure cloud
site.
Step 14
Enter a password in the Password and Confirm Password text boxes.
Step 15
To choose the throughput value, click the Throughput of the routers drop-down list.
Currently, the maximum supported CSR throughput speed available for Cisco Cloud APIC is 5GB. Even though 7.5GB
and 10GB options are available in the Throughput of the routers field, those throughput speeds are not supported at
this time, so do not select the 7.5GB and 10GB options in the Throughput of the routers field.
Note
Step 16
Cloud routers should be undeployed from all regions before changing the throughput or login credentials.
Enter the necessary information in the TCP MSS field, if applicable.
Beginning with Release 4.2(4q), the TCP MSS option is available to configure the TCP maximum segment size (MSS).
This value will be applied to all cloud router tunnel interfaces, including VPN tunnels towards the cloud and external
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
113
Configuring Cisco Cloud APIC Components
Configuring Smart Licensing
tunnels towards the on-premises site or other cloud sites. For VPN tunnels towards the cloud, if the cloud provider's
MSS value is less than the value that you enter in this field, then the lower value is used; otherwise, the value that you
enter in this field is used.
The MSS value affects only TCP traffic, and has no impact on other types of traffic, such as ping traffic.
Step 17
(Optional) To specify the license token, enter the product instance registration token in the License Token text box.
Step 18
Note
If no token is entered, the CSR will be in EVAL mode.
Note
If you assigned private IP addresses to the CSRs in Step 11, on page 113, the only supported option is Direct
connect to Cisco Smart Software Manager (CSSM) when registering smart licensing for CSRs with private
IP addresses (available by navigating to Administrative > Smart Licensing). You must provide reachability
to the CSSM through express route in this case.
Click Next.
• If you placed a check mark in the Enabled box in the Inter-Site Connectivity area earlier in these procedures,
Inter-Site Connectivity appears as the next step in the Setup - Region Management series of steps. Go to Step 19,
on page 114.
• If you did not place a check mark in the Enabled box in the Inter-Site Connectivity area earlier in these procedures,
Cloud Resource Naming Rules appears as the next step in the Setup - Region Management series of steps. Go
to Step 23, on page 114.
Step 19
To enter a peer public IP address of the IPsec Tunnel peer on-premises in the text box, click Add Public IP of IPSec
Tunnel Peer.
Step 20
Enter the OSPF area ID in the OSPF Area Id text box.
Step 21
To add an external subnet pool, click Add External Subnet and enter a subnet pool in the text box.
Step 22
When you have configured all the connectivity options, click Next at the bottom of the page.
The Cloud Resource Naming Rules page appears.
Step 23
In the Cloud Resource Naming Rules page, configure the cloud resource naming rules, if necessary.
The cloud resource naming rules are described in detail in the Cloud Resources Naming, on page 115 section. If you
don't need to make any changes to the naming rules, you can skip this page.
Step 24
Click Save and Continue when finished.
Configuring Smart Licensing
This task demonstrates how to set up smart licensing in the Cisco Cloud APIC.
Before you begin
You need the product instance registration token.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Configuration.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
114
Configuring Cisco Cloud APIC Components
Cloud Resources Naming
A list of options appear in the Intent menu.
Step 3
From the Configuration list in the Intent menu, click Set Up cAPIC. The Set up - Overview dialog box appears with
options for DNS Servers, Region Management, and Smart Licensing.
Step 4
To register the Cloud APIC to Cisco's unified license management system: From Smart Licensing, click Register. The
Smart Licensing dialog appears.
Step 5
Choose a transport setting:
• Direct to connect to Cisco Smart Software Manager (CSSM)
• Transport Gateway/Smart Software Manager Satellite
• HTTP/HTTPS Proxy
Note
An IP address is alo required when choosing HTTP/HTTPS Proxy.
Step 6
Enter the product instance registration token in the provided text box.
Step 7
Click Register when finished.
Cloud Resources Naming
Prior to Cloud APIC Release 5.0(2), the cloud resources created by the Cloud APIC in Azure were assigned
names that were derived from the names of the ACI objects:
• Resource groups were created based on the Tenant, VRF, and region. For example,
CAPIC_<tenant>_<vrf>_<region>.
• VNET names matched the name of the Cloud APIC VRF.
• Subnet names were derived from the CIDR address space. For example, subnet-10.10.10.0_24 for the
10.10.10.0/24 cloud subnet.
• The cloud application name was derived from the EPG name and the application profile name. For
example, <epg-name>_cloudapp_<app-profile-name>
This approach is not ideal for deployments with strict cloud resource naming conventions and it does not
follow the Azure best practices for naming and tagging of cloud resources.
Starting with Cloud APIC Release 5.0(2), you can create a global naming policy on the Cloud APIC, which
allows you to define a custom cloud resources naming convention for all objects deployed from the Cloud
APIC into the Azure cloud. You can define custom naming rules for all cloud resources during the first time
setup wizard of the Cloud APIC, with the exception of the Resource group name used for the Cloud APIC
ARM template deployment. The resource group name for the template is defined when you first deploy it and
cannot be changed after. In addition to the global policy, you can also explicitly define the names of the cloud
resources created from each Cloud APIC object using the REST API.
Starting with Cloud APIC Release 5.1(2), for Layer 4 to Layer 7 service deployments, you can provide custom
names to cloud resources, such as, Network Load Balancers, Application Load Balancers and Device
Application Security Groups.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
115
Configuring Cisco Cloud APIC Components
Variables Available for Naming Rules
Note
Keep in mind that even with custom naming policy, once a cloud resource is created, you will not be able to
modify the name. If you want to change the name of an existing cloud resource, you would need to delete and
recreate it.
Variables Available for Naming Rules
When creating your cloud resources naming policy, you can use the following variables to dynamically define
the name of the cloud resource based on the Cisco Cloud APIC objects:
• ${tenant} – the resource will include the name of the Tenant
• ${ctx} – the resource will include the name of the VRF
• ${ctxprofile} – the resources will include the cloud context profile, which is a VRF deployed in a
given cloud region
• ${subnet} – the resource will include the string subnet followed by the subnet IP address
• ${app} – the resource will include the name of the application profile.
• ${epg} – the resource will include the name of the EPG.
• ${contract} – the resource will include the name of the contract
• ${region} – the resource will include the name of the cloud region
• ${priority} – the resource will include the name of the network security group (NSG) rule priority.
This number is allocated automatically to ensure that each NSG rule name is unique
• ${serviceType} – the resource will include an abbreviation of the service Type (only valid for private
endpoint resources)
• ${resourceName} – the resource will include the name of the target resource (only valid for private
endpoint resources)
• ${device} – the resource will include the name of the Layer 4 to Layer 7 device.
• ${interface} – the resource will include the name of the Layer 4 to Layer 7 device interface.
• ${deviceInterfaceDn} – the resource will include the DN of the Layer to Layer 7 device interface.
For private endpoints, the combination of the
${app}-${svcepg}-${subnet}-${serviceType}-${resourceName} makes the private endpoint name unique.
Removing any of these variables might form a name of a private endpoint that already exists. This would
result in a fault raised by the Cisco Cloud APIC. Also, the max length requirements vary from Azure service
to service.
When you define a global naming policy using one or more of the above variables, Cisco Cloud APIC validates
the string to ensure that all mandatory variables are present and no invalid string is specified.
There is a maximum name length limit in Azure. If the length of the name exceeds the length supported by
the cloud provider, it rejects the config and Cisco Cloud APIC raises a fault that the resource creation failed.
You can then check the fault for details and correct the naming rules. The maximum length limits at the time
of Cisco Cloud APIC, Release 5.0(2) are listed below, for the latest up-to-date information and any changes
to the length limit, consult the Azure documentation.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
116
Configuring Cisco Cloud APIC Components
Variables Available for Naming Rules
The following table provides a summary of which cloud resources support each of the naming variables above.
Cells denoted with an asterisk (*) indicate variables that are mandatory for that type of cloud resource. Cells
denoted with a plus sign (+) indicate that at least one of these variables is mandatory for that type of cloud
resource; for example, for VNET resources you can provide ${ctx}, or ${ctxprofile}, or both.
Table 25: Supported Variables for Cloud Resources
Azure
Resource
${tenant}
${ctx}
Resource
Group
Yes*
Yes*
Yes
Yes+
Yes+
Yes
Yes
Yes
${ctxprofile} ${subnet} ${app}
${epg}
${contract} ${region} ${priority}
Yes*
Max
Length: 90
Virtual
Network
(VNET)
Yes
Max
Length: 64
Subnet
Yes*
Yes
Max
Length: 80
Application Yes
Security
Group
(ASG)
Yes*
Yes*
Yes
Yes*
Yes*
Yes
Max
Length: 80
Network
Security
Group
(NSG)
Yes
Max
Length: 80
Network
Security
Group
Rule
Yes
Yes
Yes* (auto)
Max
Length: 80
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
117
Configuring Cisco Cloud APIC Components
Naming Rules Guidelines and Limitations
Table 26: Supported Variables for Cloud Resources (Layer 4 to Layer 7 device services)
Azure Resource
${tenant}
${region}
${ctxprofile}
${device}
Yes
Yes
Yes*
Yes
Yes
Yes
Yes*
Internal
Yes
Application Load
Balancer
Yes
Yes
Yes*
Yes
Yes
Yes*
Internal Network Yes
Load Balancer
${interface}
${deviceInterfaceDN}
Yes*
Yes*
Max Length: 80
Internet-facing
Network Load
Balancer
Max Length: 80
Max Length: 80
Internet-facing
Yes
Application Load
Balancer
Max Length: 80
Device ASG
Yes
Yes
Yes*
Max Length: 80
Naming Rules Guidelines and Limitations
When configuring custom rules for naming cloud resources, the following restrictions apply:
• You define global naming policy during the Cloud APIC's first time setup using two sets of naming rules:
• Hub Resource Naming Rules define names for the Hub Resource Group, Hub VNET, Overlay-1
CIDR, Overlay-2 CIDR subnet in the Infra Tenant, as well as the subnet prefixes for subnets that
are created automatically by the system in the Infra tenant.
• Cloud Resource Naming Rules define the names of the Network Security Group (NSG), Application
Security Group (ASG), Network Load Balancer, Application Load Balancer, Device Application
Security Group, and subnets you create in the Infra Tenant, as well as the names of all resources
(Resource Groups, Virtual Networks, Subnets, NSG, ASG, Network Load Balancer, Application
Load Balancer) in user Tenants.
After you define the naming rules, you will be required to review and confirm them. Keep in mind that
you must confirm the naming rules before any cloud resources are deployed.
• Once a cloud resource is created, its name cannot be changed and the naming policy cannot be updated
in the GUI. If you upgrade your Cloud APIC to Release 5.0(2) with some resources already deployed in
Azure, you will also not be able to change the global custom naming rules.
If you want to change the names of the existing cloud resources or the policy, you would need to delete
the deployed resources before being able to update the global naming policy in the GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
118
Configuring Cisco Cloud APIC Components
Viewing Cloud Resource Naming Rules
In these cases you can use the REST API to explicitly assign custom names to any new resources you
create.
• When updating cloud resources naming via REST API, we recommend you do not import configuration
at the same time.
We recommend you define any naming rules first. Then any tenant configuration.
We recommend that you do not change the naming policy after the tenant configuration is deployed.
Viewing Cloud Resource Naming Rules
You initially define the cloud resource naming rules in the Region Management part of the first time setup
wizard when you deploy your Cloud APIC, which is described in the Cisco Cloud APIC Installation Guide.
After the initial setup, you can view the rules you configured in the System Configuration screen of your
Cloud APIC GUI as described in this section.
Note that the information in this screen is presented in read-only view and if you want to change the rules any
time after the original deployment, you will need to re-run the first time setup wizard .
Step 1
Log in to your Cloud APIC GUI.
Step 2
Navigate to the Cloud Resource Naming Rules screen.
a) In the Navigation sidebar, expand the Infrastructure category.
b) From the Infrastructure category, select System Configuration.
c) In the System Configuration screen, select the Cloud Resource Naming Rules tab.
In the Cloud Resource Naming Rules tab, you can see a summary of the currently configured rules for the names
of resources that you deploy in the cloud site from your Cloud APIC.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
119
Configuring Cisco Cloud APIC Components
Configuring Cisco Cloud APIC Using the REST API
If you did not configure custom naming rules before, the default rules are listed here, which use the Cloud APIC
object names for cloud resources.
If you have not accepted the naming rules you have defined during the first time setup, a warning banner will be
displayed across the top of the screen.
Note
Keep in mind that you must confirm the naming rules before any cloud resources are deployed.
Configuring Cisco Cloud APIC Using the REST API
Creating a Tenant Using the REST API
There are two types of subscriptions: own and shared. Each subscription type has a primary tenant. You choose
the own subscription when creating a new managed or unmanaged tenant. You choose the shared subscription
when creating a tenant that inherits the managed or unmanaged settings of an existing primary tenant. This
section demonstrates how to create a managed and unmanaged tenant with the own type of subscription and
how to create a shared subscription.
This section demonstrates how to create a tenant using the REST API using sample POST requests from the
body of Postman.
Step 1
Create an own subscription.
a) To create an unmanaged tenant using a client secret:
POST https://<cloud-apic-ip-address>/api/mo/uni.xml
<fvTenant name="{{primary-tenant-name}}">
<cloudAccount id="{{user-tenant-subscription-id}}" vendor="azure" accessType="credentials"
status="">
<cloudRsCredentials tDn="uni/tn-{{primary-tenant-name }}/credentials-{{ primary-tenant-name
}}"/>
</cloudAccount>
<cloudCredentials name="{{ primary-tenant-name }}" keyId="{{application_key_id}}"
key="{{client_secret_key}}">
<cloudRsAD tDn="uni/tn-{{ primary-tenant-name }}/ad-{{active_directory_id}}"/>
</cloudCredentials>
<cloudAD name="{{active_directory_name}}" id="{{active_directory_id}}" />
<fvRsCloudAccount tDn="uni/tn-{{ primary-tenant-name }}/act-[{{ user-tenant-subscription-id
}}]-vendor-azure" status=""/>
</fvTenant>
b) To create a managed tenant:
POST https://<cloud-apic-ip-address>/api/mo/uni.xml
<fvTenant name="{{ primary-tenant-name }}">
<cloudAccount id="{{ user-tenant-subscription-id }}" vendor="azure" accessType="managed"
status="" />
<fvRsCloudAccount tDn="uni/tn-{{ primary-tenant-name }}/act-[{{ user-tenant-subscription-id
}}]-vendor-azure" status=""/>
</fvTenant>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
120
Configuring Cisco Cloud APIC Components
Creating a Contract Using the REST API
Step 2
Create a shared subscription:
POST https://<cloud-apic-ip-address>/api/mo/uni.xml
<fvTenant name="{{ primary-tenant-name }}">
<fvRsCloudAccount tDn="uni/tn-{{ primary-tenant-name }}/act-[{{ user-tenant-subscription-id
}}]-vendor-azure" status=""/>
</fvTenant>
Creating a Contract Using the REST API
This example demonstrates how to create a contract for the Cisco Cloud APIC using the REST API.
Before you begin
Create filters.
To create a contract:
Example:
<polUni>
<fvTenant name="t2" status="">
<vzFilter descr="" name="http-family-destination" ownerKey="" ownerTag="">
<vzEntry name="http" prot="tcp" etherT="ip" dFromPort="http" dToPort="http"/>
<vzEntry name="https" prot="tcp" etherT="ip" dFromPort="https" dToPort="https"/>
</vzFilter>
<vzBrCP name="httpFamily">
<vzSubj name="default" revFltPorts="yes" targetDscp="unspecified">
<vzRsSubjFiltAtt action="permit" directives="" tnVzFilterName="http-family-destination"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>
Creating a Cloud Context Profile Using the REST API
This section demonstrates how to create a cloud context profile.
Before you begin
Create a VRF.
Step 1
To create a basic cloud context profile:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
121
Configuring Cisco Cloud APIC Components
Managing a Cloud Region Using the REST API
<cloudCtxProfile name="cProfilewestus151">
<cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-azure/region-westus"/>
<cloudRsToCtx tnFvCtxName="ctx151"/>
<cloudCidr addr="15.151.0.0/16" primary="true" status="">
<cloudSubnet ip="15.151.1.0/24" name="GatewaySubnet" usage="gateway">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="15.151.2.0/24" name="albsubnet" >
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="15.151.3.0/24" name="subnet" usage="">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
</fvTenant>
</polUni>
Step 2
To create a cloud context profile where you are adding a secondary VRF, CIDR, and subnet for a VNet:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tenant1" status="">
<fvCtx name="VRF1" />
<fvCtx name="VRF2” />
<cloudCtxProfile name="vpc1" status="">
<cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-azure/region-centralus" status=""/>
<cloudRsToCtx tnFvCtxName="VRF1" />
<cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
<cloudCidr name="cidr1" addr="192.0.2.0/16" primary="yes" status="">
<cloudSubnet ip="192.0.3.0/24" usage="gateway" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-centralus/zone-default"/>
</cloudSubnet>
</cloudCidr>
<cloudCidr name="cidr1" addr="193.0.2.0/16" primary="no" status="">
<cloudSubnet ip="193.0.3.0/24" usage="" status="">
<cloudRsSubnetToCtx tnFvCtxName="VRF2"/>
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-centralus/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
</fvTenant>
</polUni>
Managing a Cloud Region Using the REST API
This section demonstrates how to manage a cloud region using the REST API.
To create a cloud region:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
122
Configuring Cisco Cloud APIC Components
Creating a Filter Using the REST API
<polUni>
<cloudDomP name="default">
<cloudProvP vendor="azure">
<cloudRegion adminSt="managed" name="eastus"><cloudZone name="default"/></cloudRegion>
<cloudRegion adminSt="managed" name="eastus2"><cloudZone name="default"/></cloudRegion>
<cloudRegion adminSt="managed" name="westus"><cloudZone name="default"/></cloudRegion>
</cloudProvP>
</cloudDomP>
</polUni>
Creating a Filter Using the REST API
This section demonstrates how to create a filter using the REST API.
To create a filter:
https://<IP_Address>/api/node/mo/.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="t15">
<vzFilter name="rule1">
<vzEntry etherT="ip" dToPort="22" prot="tcp" dFromPort="22" name="ssh"/>
<vzEntry etherT="ip" prot="unspecified" name="any"/>
</vzFilter>
<vzFilter name="rule2">
<vzEntry etherT="ip" dToPort="http" prot="tcp" dFromPort="http" name="http"/>
</vzFilter>
<vzFilter name="rule3">
<vzEntry etherT="ip" dToPort="22" prot="tcp" dFromPort="22" name="ssh"/>
</vzFilter>
<vzFilter name='all_rule'>
<vzEntry etherT="ip" prot="unspecified" name="any"/>
</vzFilter>
<vzBrCP name="c1">
<vzSubj name="c1">
<vzRsSubjFiltAtt tnVzFilterName="rule2"/>
<vzRsSubjGraphAtt tnVnsAbsGraphName="c13_g1"/>
<vzRsSubjFiltAtt tnVzFilterName="rule3"/>
<vzRsSubjFiltAtt tnVzFilterName="all_rule"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>
Creating an Application Profile Using the REST API
This section demonstrates how to create an application profile using the REST API.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
123
Configuring Cisco Cloud APIC Components
Configuring Network Security Groups Using the REST API
Before you begin
Create a tenant.
To create an application profile:
https://<IP_Address>/api/node/mo/.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<fvCtx name="ctx151"/>
<cloudVpnGwPol name="VgwPol1"/>
<cloudApp name="a1">
</cloudApp>
</fvTenant>
</polUni>
Configuring Network Security Groups Using the REST API
This example demonstrates how set the newer NSG-per-subnet configuration for your Cisco Cloud APIC
using the REST API.
Before you begin
Review the information provided in Security Groups, on page 33.
To set the NSG-per-subnet configuration for your Cisco Cloud APIC:
Example:
<polUni>
<cloudDomP status="">
<cloudProvP vendor="azure">
<cloudProvResPolCont><cloudProvSGForSubnetP enableSGForSubnet="true"
status=""/></cloudProvResPolCont>
</cloudProvP>
</cloudDomP>
</polUni>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
124
Configuring Cisco Cloud APIC Components
Creating an EPG Using the REST API
Creating an EPG Using the REST API
Use the procedures in this section to create an application EPG, an external EPG, or a service EPG using the
REST API.
Creating a Cloud EPG Using the REST API
This example demonstrates how to create a cloud EPG using the REST API.
Before you begin
Create an application profile and a VRF.
To create a cloud EPG:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<fvCtx name="ctx151"/>
<cloudVpnGwPol name="VgwPol1"/>
<cloudApp name="a1">
<cloudEPg name="epg1">
<cloudRsCloudEPgCtx tnFvCtxName="ctx151"/>
<cloudEPSelector matchExpression="custom:tag1=='value1'" name="selector-1"/>
</cloudEPg>
</cloudApp>
</fvTenant>
</polUni>
Creating an External Cloud EPG Using the REST API
This example demonstrates how to create an external cloud EPG using the REST API.
Before you begin
Create an application profile and a VRF.
Step 1
To create an external cloud EPG:
Example:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
125
Configuring Cisco Cloud APIC Components
Creating a Service EPG Using the REST API
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<fvCtx name="ctx151"/>
<cloudVpnGwPol name="VgwPol1"/>
<cloudApp name="a1">
<cloudExtEPg routeReachability="internet" name="extEpg-1">
<fvRsCons tnVzBrCPName="extEpg-1"/>
<cloudRsCloudEPgCtx tnFvCtxName="ctx151"/>
<cloudExtEPSelector name="extSelector1" subnet="0.0.0.0/0"/>
</cloudExtEPg>
</cloudApp>
</fvTenant>
</polUni>
Step 2
To create an external cloud EPG with type site-external:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="infra">
<cloudApp name="a1">
<cloudExtEPg routeReachability="site-ext" name="extEpg-1">
<fvRsCons tnVzBrCPName="extEpg-1"/>
<cloudRsCloudEPgCtx tnFvCtxName="overlay-2"/>
<cloudExtEPSelector name="extSelector1" subnet="10.100.0.0/16"/>
</cloudExtEPg>
</cloudApp>
</fvTenant>
</polUni>
Creating a Service EPG Using the REST API
This example demonstrates how to create a service EPG using the REST API.
Before you begin
• Review the information in Cloud Service Endpoint Groups, on page 27.
• Create an application profile and a VRF.
Step 1
To create a service EPG with a deployment type of Cloud Native:
Example:
<cloudSvcEPg name="Storage" type="Azure-Storage" accessType="Private" deploymentType="CloudNative">
<cloudPrivateLinkLabel name="ProductionSubnets"/>
<cloudRsCloudEPgCtx tnFvCtxName="HUB-SERVICES-VRF"/>
<cloudSvcEPSelector matchExpression="ResourceName=='StorageAcct1'" name="selector-1"/>
<cloudSvcEPSelector matchExpression="custom:Tag=='ProdStorage'" name="selector-2"/>
</cloudSvcEPg>
Step 2
To create a service EPG with a deployment type of Cloud Native Managed:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
126
Configuring Cisco Cloud APIC Components
Creating a Cloud Template Using the REST API
Example:
<cloudSvcEPg name="APIM" type="Azure-ApiManagement" accessType="Private"
deploymentType="CloudNativeManaged" status="">
<cloudRsCloudEPgCtx tnFvCtxName="infra-SvcCtx" />
<fvRsCons tnVzBrCPName="infra-APIM-Mock"/>
<fvRsProv tnVzBrCPName="infra-managedAPIM" status=""/>
<cloudSvcEPSelector matchExpression="IP=='10.21.52.0/28'" name="sel1" status=""/>
</cloudSvcEPg>
Step 3
To create a service EPG with a deployment type of Third-Party:
Example:
<cloudSvcEPg name="SaaS-Hub" type="Custom" accessType="Private" deploymentType="Third-party" status="">
<cloudRsCloudEPgCtx tnFvCtxName="infra-SvcCtx" status=""/>
<cloudSvcEPSelector
matchExpression="URL=='saassvcepg.286b0377-a9b7-40d7-a94f-67abe03ce5f4.centralus.azure.privatelinkservice'"
name="s1" status=""/>
<cloudPrivateLinkLabel name="saas-hub" status=""/>
<fvRsProv tnVzBrCPName="SaaS-Hub" status=""/>
</cloudSvcEPg>
Creating a Cloud Template Using the REST API
This section demonstrates how to create a cloud template using the REST API. For more information about
cloud templates, see About the Cloud Template, on page 41.
Before you begin
To create a cloud template:
<polUni>
<fvTenant name="infra">
<cloudtemplateInfraNetwork name="default" numRemoteSiteSubnetPool="2" numRoutersPerRegion="2"
status="" vrfName="overlay-1">
<cloudtemplateProfile name="default" routerPassword="cisco123" routerUsername="cisco"
routerThroughput="250M" routerLicenseToken="thisismycsrtoken" />
</cloudtemplateProfile>
<cloudtemplateExtSubnetPool subnetpool="10.20.0.0/16"/>
<cloudtemplateIntNetwork name="default">
<cloudRegionName provider="azure" region="westus"/>
<cloudRegionName provider="azure" region="westus2"/>
</cloudtemplateIntNetwork>
<cloudtemplateExtNetwork name="default">
<cloudRegionName provider="azure" region="westus2"/>
<cloudtemplateVpnNetwork name="default">
<cloudtemplateIpSecTunnel peeraddr="23.2.1.1/32" />
<cloudtemplateIpSecTunnel peeraddr="23.0.1.1/32" />
<cloudtemplateIpSecTunnel peeraddr="23.1.1.1/32" />
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
127
Configuring Cisco Cloud APIC Components
Triggering an Upgrade of the Cloud Service Routers Using the REST API
<cloudtemplateOspf area="0.0.0.1"/>
</cloudtemplateVpnNetwork>
</cloudtemplateExtNetwork>
</cloudtemplateInfraNetwork>
</fvTenant>
</polUni>
Triggering an Upgrade of the Cloud Service Routers Using the REST API
This section describes how to trigger an upgrade to the cloud service routers (CSRs) using the REST API.
For more information, see Triggering an Upgrade of the Cloud Service Routers.
Set the value for the routerUpgrade field to "true" in the cloud template to trigger an upgrade to the CSRs through the
REST API (routerUpgrade="true").
<polUni>
<fvTenant name="infra">
<cloudtemplateInfraNetwork name="default" vrfName="overlay-1">
<cloudtemplateProfile name="defaultxyz" routerUsername="SomeFirstName" routerPassword="SomePass"
routerUpgrade="true">
</cloudtemplateProfile>
<cloudtemplateExtSubnetPool subnetpool="10.20.0.0/16"/>
<cloudtemplateIntNetwork name="default">
<cloudRegionName provider="azure" region="westus"/>
<cloudRegionName provider="azure" region="westus2"/>
</cloudtemplateIntNetwork>
<cloudtemplateExtNetwork name="default">
<cloudRegionName provider="aws" region="us-west-2"/>
<cloudtemplateVpnNetwork name="default">
<cloudtemplateIpSecTunnel peeraddr="23.2.1.1/32" />
<cloudtemplateIpSecTunnel peeraddr="23.0.1.1/32" />
<cloudtemplateIpSecTunnel peeraddr="23.1.1.1/32" />
<cloudtemplateOspf area="0.0.0.1"/>
</cloudtemplateVpnNetwork>
<cloudtemplateBgpEvpn peeraddr="34.1.1.1/32" asn="63000" siteId="123" password="abcd1234"
/>
</cloudtemplateExtNetwork>
</cloudtemplateInfraNetwork>
</fvTenant>
</polUni>
Defining Global Cloud Resource Naming Rules or Overriding Specific Object's
Name
This section provides an example REST API POST you can use to configure a global policy for naming your
cloud resources or override a specific cloud resource's name.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
128
Configuring Cisco Cloud APIC Components
Defining Global Cloud Resource Naming Rules or Overriding Specific Object's Name
Note
Step 1
To ensure that any custom naming conventions can be supported, cloud resource names can be defined on a
per-object basis. These explicit name overrides are not available in the Cloud APIC GUI and can be done
using REST API only. We recommend using the global cloud resource naming policy to define the names.
Explicit name overrides shouldf be used only when naming requirements cannot be met using the global
naming policy.
To create Hub Resource Naming Rules:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="infra">
<cloudtemplateInfraNetwork name="default" numRemoteSiteSubnetPool="2"
numRoutersPerRegion="2" status="" vrfName="overlay-1">
<cloudtemplateIntNetwork name="default">
<cloudRegionName provider="azure" region=“west’s” status="">
<cloudtemplateRegionNameCustomization ctxProfileName="infra-vnet"
resourceGroupName="infra-rh" subnetNamePrefix="snet-" />
</cloudRegionName>
</cloudtemplateIntNetwork>
</cloudtemplateInfraNetwork>
</fvTenant>
</polUni>
Step 2
To create Cloud Resource Naming Rules:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<cloudDomP name="default">
<cloudNaming
azResourceGroup="${tenant}-network-${ctx}-${region}-rg"
azVirtualNetwork="${tenant}-${ctxprofile}-vnet"
azSubnet="${tenant}-${ctxprofile}-snet-${subnet}"
azNetworkSecurityGroup="${app}-${epg}-nsg"
azApplicationSecurityGroup="${app}-${epg}-asg"
azNetworkSecurityGroupRule="${contract}--${priority}"
internetApplicationBalancer="agw-e-${device}"
internalApplicationBalancer="agw-i-${device}"
internetNetworkBalancer="lbe-${device}"
internalNetworkBalancer="lbi-${device}"
l4L7DeviceApplicationSecurityGroup="${deviceInterfaceDn}"
reviewed="yes" />
</cloudDomP>
</polUni>
Step 3
To override an Azure cloud resource name corresponding to a specific Cloud APIC object:
You can use the same variables (for example, ${tenant}) when specifying the custom name using the API.
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<fvTenant name="ExampleCorp" status="">
<fvRsCloudAccount status="" tDn="uni/tn-infra/act-[<infra-subscription>]-vendor-azure"/>
<fvCtx name="VRF1"/>
<cloudApp name="App1">
<cloudEPg name="Db" azNetworkSecurityGroup="db-nsg" azApplicationSecurityGroup="db-asg-${region}">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
129
Configuring Cisco Cloud APIC Components
Defining Global Cloud Resource Naming Rules or Overriding Specific Object's Name
<cloudRsCloudEPgCtx tnFvCtxName="VRF1"/>
<cloudEPSelector matchExpression="custom:EPG=='db'" name="100"/>
</cloudEPg>
</cloudApp>
<cloudCtxProfile name="c02" azResourceGroup="custom-tc-rg1" azVirtualNetwork="vnet1">
<cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-azure/region-westus"/>
<cloudRsToCtx tnFvCtxName="VRF1"/>
<cloudCidr addr="10.20.20.0/24" name="cidr1" primary="yes" status="">
<cloudSubnet ip="10.20.20.0/24" name="subnet1" azSubnet="s1" status="">
<cloudRsZoneAttach status="" tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
</fvTenant>
Step 4
To override a Layer 4 to Layer 7 Azure cloud resource name corresponding to a specific Cloud APIC object:
You can use the same variables (for example, ${tenant}) when specifying the custom name using the API.
Override policy for load balancer:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<fvTenant>
<cloudLB name="ALB" type="application" scheme="internet" size="small" instanceCount="2" status=""
nativeLBName=”ALB” >
<cloudRsLDevToCloudSubnet
tDn="uni/tn-{{tenantName}}/ctxprofile-c1/cidr-[31.10.0.0/16]/subnet-[31.10.80.0/24]" status="" />
</cloudLB>
</fvTenant>
Override policy for device ASG:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<fvTenant>
<cloudLDev name="{{FWName}}" status="" l4L7DeviceApplicationSecurityGroup="Group1" >
<cloudRsLDevToCtx tDn="uni/tn-{{tenantName}}/ctx-VRF1" status=""/>
</cloudLIf>
</cloudLDev>
<fvTenant>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
130
CHAPTER
5
Viewing System Details
• Viewing Application Management Details, on page 131
• Viewing Cloud Resource Details, on page 132
• Viewing Operations Details, on page 134
• Viewing Infrastructure Details, on page 136
• Viewing Administrative Details, on page 136
• Viewing Health Details Using the Cisco Cloud APIC GUI, on page 138
Viewing Application Management Details
This section explains how to view application management details using the Cisco Cloud APIC GUI. The
application management details include the information of a specific tenant, application profile, EPG, contract,
filter, VRF, service, or cloud context profile.
Step 1
From the Navigation menu, choose the Application Management tab.
When the Application Management tab expands, a list of subtab options appear. See the Application Management
Options table for more information.
Table 27: Application Management Subtabs
Subtab Name
Description
Tenants
Displays tenants as rows in a summary table.
Application Profiles
Displays application profiles as rows in a summary table.
EPGs
Displays an EPGs as rows in a summary table.
Contracts
Displays a contracts as rows in a summary table.
Filters
Displays filters as rows in a summary table.
VRFs
Displays VRFs as rows in a summary table.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
131
Viewing System Details
Viewing Cloud Resource Details
Subtab Name
Description
Services
Contains the following two subtabs and information:
• Devices—Displays the devices as rows in a summary
table.
• Service Graphs—Displays service graphs as rows in
a summary table.
Cloud Context Profiles
Step 2
Displays cloud context profiles as rows in a summary table.
Click the tab that represents the component with the details you want to view.
A summary table appears with items as rows in the table. For example, if you chose the Tenants subtab, a list of tenants
appear as rows in a summary table
You can filter the rows by clicking the Filter by Attributes bar. Choose the attribute, operator and filter-value. For example,
for filtering based on a tenant, choose Name == T1 (where T1 is the name of a tenant).
Step 3
To view a summary pane, click the row that represents the specific component you want to view.
Step 4
For more information, double-click the summary table row that represents the specific component you want to view.
A new dialog box appears over the work pane with any of the following tabs:
Note
The tabs that appear differ between components and configurations.
• Overview—Provides a general overview of cloud resources, configuration relationships, and settings of the component.
• Topology —Provides visual relationship between an object and other related objects. The chosen object is displayed
at the center.
• Cloud Resources—Contains a list of subtabs that display the cloud resource information related to the component.
• Application Management—Contains a list of subtabs that display the ACI relation information related to the
component.
• Statistics—Enables you to view statistics based on a chosen sampling interval and statistics type. The Statistics tab
may contain subtabs, depending on the component you are viewing.
• Event Analytics—Contains a list of subtabs that display faults, events, and audit logs.
Note
The dialog box that appears over the work pane contains an edit button in the top-right corner between the
refresh button and the Actions button. When clicked, the edit button enables you to edit the chosen component.
Viewing Cloud Resource Details
This section explains how to view cloud resource details using the Cisco Cloud APIC GUI. The cloud resource
details include the information about a specific region, VNET, router, security group (application security
group/network security group), endpoint, VM, and cloud service.
Beginning with Release 5.0(2), for the Endpoints subtab, search based on Cloud Tag attribute is supported.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
132
Viewing System Details
Viewing Cloud Resource Details
Step 1
From the Navigation menu, choose the Cloud Resources tab.
When the Cloud Resources tab expands, a list of subtab options appear. See the Cloud Resource Options table for more
information.
Table 28: Cloud Resource Subtabs
Subtab Name
Description
Regions
Displays regions as rows in a summary table.
Virtual Networks
Displays VNETs as rows in a summary table.
Routers
Displays routers as rows in a summary table.
Security Groups
Displays security groups as rows in a summary table.
Endpoints
Displays endpoints as rows in a summary table.
Virtual Machines
Displays the VMs as rows in a summary table.
Cloud Services
Contains the following subtabs:
• Cloud Service Tab—Displays cloud services as rows in a summary table.
• Target Groups Tab—Displays target groups as rows in a summary table.
Step 2
Click the tab that represents the component with the details you want to view.
A summary table appears with items as rows in the table. For example, if you chose the Endpoints subtab, a list of
endpoints appear as rows in a summary table.
You can filter the rows by selecting an attribute from the drop-down menu when you click the Filter by attributes bar.
The attributes displayed in the drop-down menu depend on the selected subtab.
For the Endpoints subtab, you can narrow down the search based on a cloud tag, by entering a key or value term. If you
want to search based on both terms, click the (+) displayed as a superscript to the key or value term (depending on which
was entered first). Cloud tag filters cannot be edited. To modify a search, first delete the filters, and then enter the desired
key or value term again. Search based on multiple cloud tag filters is supported.
Step 3
To view a summary pane, click the row that represents the specific component you want to view.
Step 4
For more information, double-click the summary table row that represents the specific component you want to view.
A new dialog box appears over the work pane with any of the following tabs:
Note
The tabs that appear differ between components and configurations.
• Overview—Provides a general overview of cloud resources, configuration relationships, and settings of the component.
Beginning with Release 5.0(2), the cloud tags associated with endpoints are displayed.
• Cloud Resources—Contains a list of subtabs that display the cloud resource information related to the component.
• Application Management—Contains a list of subtabs that display the ACI relation information related to the
component.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
133
Viewing System Details
Viewing Operations Details
• Statistics—Enables you to view statistics based on a chosen sampling interval and statistics type. The Statistics tab
may contain subtabs, depending on the component you are viewing.
• Event Analytics—Contains a list of subtabs that display faults, events, and audit logs.
Viewing Operations Details
This section explains how to view operations details using the Cisco Cloud APIC GUI. The operations details
include the information of a specific fault, event, audit log, active sessions, backup and restore policies, tech
support policies, firmware management, scheduler policies, and remote locations.
Step 1
From the Navigation menu, choose the Operations tab.
When the Operations tab expands, a list of subtab options appear. See the Operations Options table for more information.
Table 29: Operations Subtabs
Subtab Name
Description
Event Analytics
Contains the following subtabs:
• Faults Tab—Displays faults as rows in a summary
table.
• Fault Records Tab—Displays fault records as rows
in a summary table.
• Events Tab—Displays events as rows in a summary
table.
• Audit Logs Tab—Displays audit logs as rows in a
summary table.
Active Sessions
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
134
Displays a list of active users who are logged into Cloud
APIC.
Viewing System Details
Viewing Operations Details
Subtab Name
Description
Backup & Restore
Contains the following subtabs:
• Backups Tab—Displays backup as rows in a summary
table.
• Backup Policies Tab—Displays backup policies as
rows in a summary table.
• Job Status Tab—Displays the job status as rows in a
summary table.
• Event Analytics Tab—Contains the following subtabs:
• Faults Tab—Displays faults as rows in a
summary table.
• Events Tab—Displays events as rows in a
summary table.
• Audit Logs Tab—Displays audit logs as rows in
a summary table.
Tech Support
Contains the following subtabs:
• Tech SupportTab—Displays tech support policies as
rows in a summary table.
• Core Logs Tab—Displays core logs as rows in a
summary table.
Firmware Management
Contains the following subtabs:
• General Tab—Displays general firmware management
information, such as Current Firmware Version,
Upgrade Status.
• Images Tab—Displays a list of images.
• Event Analytics Tab—Contains the following subtabs:
• Faults Tab—Displays faults as rows in a
summary table.
• Events Tab—Displays events as rows in a
summary table.
• Audit Logs Tab—Displays audit logs as rows in
a summary table.
Step 2
Schedulers
Displays scheduler policies as rows in a summary table.
Remote Locations
Displays remote locations as rows in a summary table.
Click the tab that represents the component you want to view.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
135
Viewing System Details
Viewing Infrastructure Details
A summary table appears with items as rows in the table. For example, if you chose the Active Sessions subtab, a list of
active sessions appear as rows in a summary table.
You can filter the rows by clicking the Filter by Attributes bar. Choose the attribute, operator and filter-value. For example,
for filtering based on a username, choose username == user1 (where user1 is a user logged into Cloud APIC).
Step 3
To view a summary pane, click the row that represents the specific component you want to view.
Step 4
For more information, double-click the summary table row that represents the specific item you want to view.
A new dialog box appears over the work pane that displays additional information about the item you chose from the
summary table.
Viewing Infrastructure Details
This section explains how to view infrastructure details using the Cisco Cloud APIC GUI. The infrastructure
details include information about system configuration, inter-region connectivity, and external connectivity.
Step 1
From the Navigation menu, choose the Infrastructure tab.
When the Infrastructure tab expands, a list of subtab options appear. See the Infrastructure Options table for more
information.
Table 30: Infrastructure Subtabs
Step 2
Subtab Name
Description
System Configuration
Displays General system configuration information,
Management Access information, Controllers, Cloud
Resource Naming Rules, and Event Analytics.
Inter-Region Connectivity
Displays one pane with a map that contains the inter-region
connectivity view and additional panes for each region.
Inter-Site Connectivity
Displays one pane with a map that contains the inter-site
connectivity view and additional panes for each site.
Click the tab that represents the component with the details you want to view.
Viewing Administrative Details
This section explains how to view administrative details using the Cisco Cloud APIC GUI. The administrative
details include the information about authentication, security, users, and smart licensing..
Step 1
From the Navigation menu, choose the Administrative tab.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
136
Viewing System Details
Viewing Administrative Details
When the Administrative tab expands, a list of subtab options appear. See the Administrative Options table for more
information.
Table 31: Administrative Subtabs
Subtab Name
Description
Authentication
Displays the Authentication Default Settings, Login
Domains, Providers and Event Analytics subtabs, which
contain the information described below:
• Authentication Default Settings Tab—Displays
settings information.
• Login Domains Tab—Displays the login domains as
rows in a summary table.
• Providers Tab—Displays the providers as rows in a
summary table.
• Event Analytics Tab—Displays the Faults, Events,
and Audit Logs subtabs, each with the corresponding
information displayed as rows in a summary table.
Security
Contains the following list of subtabs:
• Security Default Settings Tab—Enables you to view
the default security settings information.
• Security Domains Tab—Enables you to view security
domain information in a summary table.
• Roles Tab—Enables you to view the role information
in a summary table.
• RBAC Rules Tab—Enables you to view RBAC rule
information in a summary table.
• Certificate Authorities Tab—Enables you to view
the certificate authority information in a summary
table.
• Key Rings Tab—Enables you to view key ring
information in a summary table.
• User Activity Tab—Enables you to view user activity.
Users
Contains the following subtabs:
• Local Tab—Displays local users as rows in a summary
table.
• Remote Tab—Displays remote users as rows in a
summary table.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
137
Viewing System Details
Viewing Health Details Using the Cisco Cloud APIC GUI
Subtab Name
Description
Smart Licensing
Contains the following subtabs:
• General Tab—Displays the licenses as rows in a
summary table.
• CSRs Tab—Displays CSRs as rows in a summary
table.
• Faults Tab—Displays faults as rows in a summary
table.
Step 2
Click the tab that represents the component you want to view.
For some options, a summary table appears with items as rows in the table (For example, if you choose the Users tab, a
list of users appear as rows in a summary table). To view a summary pane, click the row that represents the specific
component you want to view. To view more information, double-click the summary table row that represents the specific
item you want to view. A new dialog box appears over the work pane that displays additional information about the item
you chose from the summary table.
You can filter the rows by clicking the Filter by Attributes bar. Choose the attribute, operator and filter-value. For example,
for filtering based on a user, choose User ID == admin (where admin is a user ID. ).
Viewing Health Details Using the Cisco Cloud APIC GUI
This section explains how to view health details using the Cisco Cloud APIC GUI. You can view health details
for any object that you can see in the Cloud Resources area in the Cisco Cloud APIC GUI, such as the following:
• Regions
• Availability Zones (for AWS cloud sites)
• VPCs (for AWS cloud sites)
• VNETs (for Azure cloud sites)
• Routers
• Security Groups
• Endpoints
• Instances
• Cloud Services
Step 1
From the Navigation menu, choose the Dashboard tab.
The Dashboard window for the Cisco Cloud APIC system appears. From this window, you can view the overall health
status of your system.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
138
Viewing System Details
Viewing Health Details Using the Cisco Cloud APIC GUI
Step 2
Click within the Fault Summary area in the Dashboard window.
The Event Analytics window appears, showing more detailed information for the specific fault level that you clicked.
The following screen shows an example Event Analytics window for the faults listed with critical severity.
Step 3
Click the X next to the Severity level to display Event Analytics information for all faults.
The information provided in the Event Analytics window changes to show the events with critical, major, and warning
levels of severity.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
139
Viewing System Details
Viewing Health Details Using the Cisco Cloud APIC GUI
Step 4
From the Navigation menu, choose the Cloud Resources tab.
When the Cloud Resources tab expands, a list of subtab options appear. See the Administrative Options table for more
information.
Step 5
Choose any item under the Cloud Resources tab to display health information for that component.
For example, the following figure shows health information that might be displayed when you click on Cloud Resources >
Regions, then you select a specific region.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
140
CHAPTER
6
Deploying Layer 4 to Layer 7 Services
• Overview, on page 141
• Example Use Cases, on page 152
• Example Use Cases for Service Graphs with Cloud Native and Third-Party Services, on page 167
• Guidelines and Limitations for Redirect, on page 186
• Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI, on page 188
• Deploying a Service Graph, on page 190
Overview
The Cisco Cloud APIC enables you to deploy Layer 4 to Layer 7 service devices to the public cloud. The
initial release (4.2(x)), supports Azure Application Gateway (Application Load Balancer) deployments in
Azure. Beginning with release 5.0(2), Azure Load Balancer (Network Load Balancer) and Third Party Firewall
deployments in Azure are supported. Beginning with release 5.1(2), Third Party Load Balancer deployments
in Azure are supported.
Four types of Layer 4 to Layer 7 services are supported for deployments in Azure:
• ALB refers to Azure Application gateway or Application Load balancer
• NLB refers to Azure Load balancer or Network Load balancer
• Third Party Firewall
• Third Party Load Balancer
About Service Graphs
A service graph is used to represent a set of Layer 4 to Layer 7 services devices inserted between two or more
pair of EPGs. EPGs can represent your applications running within a cloud (for example, Cloud EPG) or
internet (cloudExtEPG) or from other sites (for example, on-premises or remote cloud sites). Layer 4 to Layer
7 services devices can be NLB, ALB, a cluster of third party firewalls or a third party load balancer.
A service graph in conjunction with contracts (and filters) is used to specify communication between two
EPGs. A cloud APIC automatically derives security rules (network security group/NSG and ASG) and
forwarding routes (UDRs) based on the policy specified in Contract and Service Graph
Multiple service graphs can be specified to represent different traffic flows or topologies.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
141
Deploying Layer 4 to Layer 7 Services
Using Service Graphs with Cloud Native and Third-Party Services
Following combinations are possible with service graphs:
• Same device can be used in multiple service graphs.
• Same service graph can be used between multiple consumer and provider EPGs.
By using a service graph, the user can specify the policy once and deploy the service chain within regions or
inter-regions. Each time the graph is deployed, Cisco ACI takes care of changing the network configuration
to enable the forwarding in the new logical topology.
For Third party firewalls, the configuration inside the device is not managed by cloud APIC.
A service graph represents the network using the following elements:
• Service Graph Nodes—A node represents a function that is applied to the traffic, such as a load balancer.
A function within the service graph might require one or more parameters and have one or more
connectors.
• Connector—A connector enables input and output from a node.
After the graph is configured, the Cisco APIC automatically configures the services according to the service
function requirements that are specified in the service graph. The Cisco APIC also automatically configures
the network according to the needs of the service function that is specified in the service graph, which does
not require any change in the service device.
Using Service Graphs with Cloud Native and Third-Party Services
Beginning with Release 5.1(2), you can now use service graphs with cloud native and third-party services.
You can use service graphs in these situations either with or without redirect. See Example Use Cases for
Service Graphs with Cloud Native and Third-Party Services, on page 167 for example use cases, with or
without redirect.
You will use the cloud service endpoint group (service EPG), also introduced in Release 5.1(2), with this type
of service graph. See Cloud Service Endpoint Groups, on page 27 for more information about the service
EPG, and the deployment types and access types that are available for service EPGs.
The following deployment types and access types are supported with service graphs used with service EPGs
for this purpose.
Table 32: Provider Service EPG Types
Deployment Types
Access Types
Cloud Native
Private
Cloud Native Managed
Public and Private
Third-Party
Private
Table 33: Consumer Service EPG Types
Deployment Types
Access Types
Cloud Native Managed
Public and Private
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
142
Deploying Layer 4 to Layer 7 Services
About Application Load Balancers
Guidelines and Limitations
• You must have the newer NSG-per-subnet configuration enabled in order to use service graphs with
cloud native and third-party services, using the service EPGs. See Security Groups, on page 33 for more
information on the NSG-per-subnet configuration.
• Any restrictions that apply for cloud EPG and service graph combinations also apply to service EPG and
service graph combinations. For example, the cloud EPG/service graph restriction that a consumer and
provider that is tag-based cannot be in the same VRF in the same region would also apply for service
EPGs and service graphs.
• For two node graphs that don't perform redirect, SNAT and DNAT are enabled. It is assumed that the
DNATed address is a device that is equivalent to a load balancer, which can take care of spraying traffic
across different targets that may be in different subnets.
Note that if those targets are in different subnets, the service graph doesn't provide route reachability
rules for those targets. It is assumed that the service EPG will take care of the reachability in this case.
• For cases involving AKS and service graphs, the service graph will only establish route reachability to
the load balancer's subnet of the AKS cluster.
About Application Load Balancers
Application Load Balancer (also called Azure Application Gateway or ALB) is a Layer 7 load balancer, which
balances the web traffic based on attributes like HTTP request, URL filtering etc. For more details please
refer to Microsoft Documentation.
In Cisco ACI, there are two ways to deploy an Application Load Balancer:
• Internet-facing: inserts the Application Load Balancer as a service between the consumer external EPG
and the provider cloud EPG.
• Internal-facing: inserts the Application Load Balancer as a service between the consumer cloud EPG
and the provider cloud EPG.
You can consume an Application Load Balancer using a service graph. A typical configuration involves:
• Creation of Layer 4 to Layer 7 services device as Application Load Balancer
• Consume the ALB as a node in the service graph
• Creation of one or more listeners in EPG communication when a service graph is associated with a
contract.
Listeners enable you to specify the ports and protocols (HTTP or HTTPS) that the Application Load Balancer
accepts traffic on. When specifying HTTPS, you also choose a security policy and an SSL certificate.
Note
A listener can have multiple certificates.
All listeners require you to configure at least one rule (a default rule, which does not have a condition). Rules
enable you to specify the action that the load balancer takes when a condition is met. For example, you can
create a rule that redirects traffic to a specified URL when a request is made to a specified hostname or path.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
143
Deploying Layer 4 to Layer 7 Services
About Network Load Balancer
An Application load balancer (ALB) should be in a separate subnet which should not be used to deploy other
applications. Cloud APIC creates and attaches ALB’s NSG to the subnet associated with the ALB. Cloud
APIC supports Standard and Standard_v2 SKUs of Azure Application Gateway.
About Network Load Balancer
A Network Load Balancer (Azure Load Balancer or NLB) is a Layer 4 device that distributes the in-bound
flow packets based on Layer 4 ports. For more details, please refer to Microsoft Documentation.
Similar to ALB, NLB can be deployed using a service graph. You can specify these actions by configuring
one or more listeners.
Listeners enable you to specify the ports and protocols (TCP or UDP) that the load balancer accepts and
forwards traffic on. All listeners require you to configure at least one rule (a default rule, which does not have
a condition). Rules enable you to specify the action that the load balancer takes when a condition is met.
Unlike application gateway, here a rule can only forward traffic to specific port of the backend pool. NLB
should be in a separate subnet similar to ALB. There are two modes of operation in Network load balancer:
• Forward mode: Traffic is forwarded from a specific listener port to the specified backend port.
• HA Port mode: Network load balancer will load balance TCP and UDP flows on all the ports
simultaneously.
Cloud APIC supports Standard SKU Network Load Balancer only.
In Figure1, the frontend load balancer (ALB/NLB) - VM or firewall - backend load (ALB/NLB) balancer as
a service are inserted between the consumer external EPG and the provider cloud EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
144
Deploying Layer 4 to Layer 7 Services
About Third-Party Load Balancers
Figure 19: Internet-Facing and Internal-Facing Deployment
About Third-Party Load Balancers
Third-Party Load Balancer is a noncloud native Layer 4 to Layer 7 load balancer. Cloud APIC does not
manage the configuration of the third-party load balancers. However, Cloud APIC automates the network
stitching for connectivity to a third-party load balancer.
You can configure VIPs for a third-party load balancer from the external interface subnet. You can also
configure additional VIPs for the third- party load balancers as secondary IP addresses on the external interface.
Cloud APIC supports third-party load balancers that are deployed in a two-arm mode (external and internal
interfaces) with source NAT enabled.
Limitations for Third-Party Load Balancers:
• Cloud APIC does not support Direct Server Return (DSR) configurations on third-party load balancers.
• Third-party load balancers are not supported in active/standby high availability configurations.
For details about third-party load balancer VMs in active/active mode, see Example Use Cases, on page
152.
• Alien VIP range is not supported for third-party load balancers.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
145
Deploying Layer 4 to Layer 7 Services
About Allow All Traffic Option
About Allow All Traffic Option
Beginning with release 5.1(2g), the Allow All Traffic option is available for third-party firewalls and Azure
network load balancers deployed as pass-through devices on a redirect-enabled service graph.
Note
This option allows all inbound and outbound access to the subnet on which the interface belongs. Ensure that
this does not present a security risk before enabling this option.
The following sections provide instructions for enabling the Allow All Traffic option.
• Third-Party Firewall, on page 146
• Azure Network Load Balancer, on page 147
Third-Party Firewall
• To enable this option when creating a new service graph type:
1. From the Application Management list in the Intent menu, click Services > Devices > Create
Device.
2. Choose Third party firewall as the Service Type.
3. Click Add Interface, then locate the Allow All Traffic area.
4. Click the box next to the Enabled field in the Allow All Traffic area to allow all inbound and
outbound access to the subnet on which the interface belongs.
5. Click Save when finished.
• To enable this option when editing an existing service graph type:
1. From the Application Management list in the Intent menu, click Services, then click on an existing
service device with Third-Party Firewall shown as the Device Type.
A panel showing details for this service device type slides in from the right side of the window.
2. Click the Details icon (
).
Another window appears that provides more detailed information for this service device type.
3. Locate the Interfaces area in the window and click the necessary interface selector under the Interface
Selectors column.
A panel showing details for this interface slides in from the right side of the window.
4. Click the Details icon (
).
Another window appears that provides more detailed information for this interface.
5. Click the pencil icon to edit the configuration settings for this interface.
6. Locate the Allow All Traffic area, then click the box next to the Enabled field in the Allow All
Traffic area to allow all inbound and outbound access to the subnet on which the interface belongs.
7. Click Save when finished.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
146
Deploying Layer 4 to Layer 7 Services
Dynamic Server Attachment to Server Pool
Azure Network Load Balancer
• To enable this option when creating a new service graph type:
1. From the Application Management list in the Intent menu, click Services > Devices > Create
Device.
2. Choose Network Load Balancer as the Service Type.
3. In the Settings area, click the box next to the Enabled field in the Allow All Traffic area to allow
all inbound and outbound access to the subnet on which the interface belongs.
4. Click Save when finished.
• To enable this option when editing an existing service graph type:
1. From the Application Management list in the Intent menu, click Services, then click on an existing
service device with Network Load Balancer shown as the Device Type.
A panel showing details for this service device type slides in from the right side of the window.
2. Click the Details icon (
).
Another window appears that provides more detailed information for this service device type.
3. Click the pencil icon to edit the configuration settings for this service device.
4. In the Settings area, locate the Allow All Traffic area, then click the box next to the Enabled field
in the Allow All Traffic area to allow all inbound and outbound access to the subnet on which the
interface belongs.
5. Click Save when finished.
Dynamic Server Attachment to Server Pool
Servers in provider EPG are dynamically added to the target groups. In Azure, the target groups are referenced
as the backend pool. Listeners and rule configuration that define the frontend and backend protocol and port
number, and load balancing action are provided by the user. When configuring listener rule as part of service
graph configuration, user can select provider EPG for a given rule. The endpoints from that EPG would be
dynamically added to the target group of the load balancer. You do not need to specify the endpoints or FQDN
for the targets.
About Inter-VNet Services
Beginning with Release 5.0(2), support is available for the deployment and automation of the inter-VNet
services. This is both for the East-West and North-South use cases within the cloud.
Note the following considerations for this support:
• VNet peering needs to be configured for hub-spoke topology. For more information, refer to Configuring
VNet Peering for Cloud APIC for Azure.
• For multi-node services with redirect: The service device has to be present in the infra VNet. Service
devices such as ALB fronting the provider can be present in the provider VNet.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
147
Deploying Layer 4 to Layer 7 Services
About Multinodes
• For multi-node service without redirect: The service device can be in the provider VNet or spread
across the hub VNet and the provider VNet.
• Inter-VNet traffic is supported with an Application gateway in the infra VNet and the provider in a
non-infra VNet. VNets should be peered together and they should be from the same region.
About Multinodes
Beginning with release 5.0(2), Multinode service graph is supported. Multinodes enable multiple deployment
scenarios with service graphs.
Service devices that can be deployed are Application Load Balancer, Network Load Balancer and Third Party
Firewall.
Two types of nodes are admitted in a graph.
• Non-redirect: Traffic is destined to service devices (Load Balancers, Thirdparty firewalls with DNAT
and SNAT, Network Load Balancer).
• Redirect: Service device is a passthrough device (Network Load Balancer or Firewall).
About Layer 4 to Layer 7 Service Redirect
Beginning with Release 5.0(2), the Layer 4 to Layer 7 Service Redirect feature is available for Cisco Cloud
APIC, similar to the policy-based redirect (PBR) feature available for Cisco APIC. The Layer 4 to Layer 7
Service Redirect feature is configured using the Redirect option in the Cisco Cloud APIC.
Note
Throughout this section, the term "consumer-to-provider" is sometimes used as a blanket term to describe
traffic going from point A to point B, where a redirect service device might be inserted between those two
points. However, this does not mean that only consumer-to-provider traffic is supported for redirect; traffic
might also be from provider-to-consumer, such as in the use case described in Spoke to Spoke, on page 154.
With redirect, policies are used to redirect traffic through specific service devices, where service devices can
be deployed as a Network Load Balancer or a third-party firewall. This traffic isn't necessarily destined for
the service device as part of the standard consumer-to-provider configuration; rather, you would configure
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
148
Deploying Layer 4 to Layer 7 Services
About Layer 4 to Layer 7 Service Redirect
the consumer-to-provider traffic as you normally would, and you would then configure service graphs to
redirect that consumer-to-provider traffic to a specific service device.
Support for redirect for Cisco Cloud APIC is only available in conjunction with the VNet peering feature,
taking advantage of the hub-and-spoke topology used in VNet peering. For more information on the VNet
peering feature, see the Configuring VNet Peering for Cloud APIC for Azure document.
About the Overlay-1 and Overlay-2 VRFs
The overlay-1 and overlay-2 VRFs are automatically created in the infra tenant for Cloud APIC. In the Azure
portal, CIDRs and subnets from the overlay-1 and overlay-2 VRFs are deployed in the Azure cloud on the
overlay-1 VNet. The overlay-2 VRF is used to hold additional CIDRs. You shouldn't consider overlay-2 as
a separate VNet.
The following sections provide more information on the overlay-1 and overlay-2 VRFs.
Requirement for Separate VRFs in the Infra Hub
Prior to Release 5.0(2), the infra hub VNet was used to achieve transit routing functionality for inter-spoke
communications within the site through CSRs in the hub, and to send VxLAN packets for EPG communication
across sites.
There are situations where you might want to deploy a certain number of EPGs configured with shared services
and Layer 4 to Layer 7 service graphs in a common hub that can be shared across spokes. In some situations,
you might have multiple hub networks deployed separately (for example, for production, pre-production, and
core services). You might want to deploy all of these hub networks in the same infra hub VNet (in the same
infra cloud context profile), along with the existing cloud CSRs.
Thus, for these kind of requirements, you might need to split the hub VNet into multiple VRFs for network
segmentation while keeping the security intact.
About the Infra Hub Services VRF (Overlay-2 VRF in the Infra VNet)
Beginning with Release 5.0(2), the overlay-2 VRF is now created in the infra tenant implicitly during the
Cisco Cloud APIC bringup. In order to keep the network segmentation intact between the infra subnets used
by the cloud site (for CSRs and network load balancers) and the user subnets deployed for shared services,
different VRFs are used for infra subnets and user-deployed subnets:
• Overlay-1: Used for infra CIDRs for the cloud infra, along with Cisco Cloud Services Routers (CSRs),
the infra network load balancer, and the Cisco Cloud APIC
• Overlay-2: Used for user CIDRs to deploy shared services, along with Layer 4 to Layer 7 service devices
in the infra VNet (the overlay-1 VNet in the Azure cloud)
All the user-created EPGs in the infra tenant can only be mapped to the overlay-2 VRF in the infra VNet. You
can add additional CIDRs and subnets to the existing infra VNet (the existing infra cloud context profile).
They are implicitly mapped to overlay-2 VRF in the infra VNet, and are deployed in the overlay-1 VNet in
the Azure cloud.
Prior to Release 5.0(2), any given cloud context profile would be mapped to a cloud resource of a specific
VNet. All the subnets and associated route tables of the VNet would be have a one-to-one mapping with a
single VRF. Beginning with Release 5.0(2), the cloud context profile of the infra VNet can be mapped to
multiple VRFs (the overlay-1 and overlay-2 VRFs in the infra VNet).
In the cloud, the subnet’s route table is the most granular entity for achieving network isolation. So all
system-created cloud subnets of the overlay-1 VRF and the user-created subnets of the overlay-2 VRF will
be mapped to separate route tables in the cloud for achieving the network segmentation.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
149
Deploying Layer 4 to Layer 7 Services
Passthrough Rules
Note
On Azure cloud, you cannot add or delete CIDRs in a VNet when it has active peering with other VNets.
Therefore, when you need to add more CIDRs to the infra VNet, you need to first disable VNet peering in it,
which removes all the VNet peerings associated with the infra VNet. After adding new CIDRs to the infra
VNet, you need to enable VNet peering again in the infra VNet.
You do not have to disable VNet peering if you are adding a new subnet in an existing CIDR in the hub VNet.
See Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI, on page 188 for more information.
Passthrough Rules
When redirect is enabled, the rules in the NSGs (Network Security Groups) attached to the service devices
are updated to permit traffic from consumer to provider. These rules are called “passthrough rules". In general,
the passthrough rule is to permit traffic from consumer IP to provider IP. If the destination IP is an application
load balancer (ALB) VIP, the rule is to permit traffic from consumer IP to the ALB VIP.
Redirect Programming
Redirect programming depends on the classification of the destination EPG (tag-based or subnet-based):
• For a subnet-based EPG, subnets of the destination EPGs are used to program redirects
• For a tag-based EPGs, CIDRs of the destination VNet are used to program redirects
As a result of this, the redirect affects traffic from other EPGs going to the same destination in the redirect,
even if the EPG is not part of the service graph with the redirect. Traffic from EPGs that are not part of the
redirect will also get redirected to the service device.
The following table describes how redirect is programmed in different scenarios.
Consumer
Provider
Redirect on Consumer
VNet
Tag-based
Tag-based
Redirect for the provider Redirect for the consumer
are the CIDRs of the
are the CIDRs of the
provider's VNet
consumer's VNet
Tag-based
Subnet-based
Redirect for the provider Redirect for the consumer
are the subnets of the
are the CIDRs of the
provider
consumer's VNet
Subnet-based
Tag-based
Redirect for the provider Redirect for the consumer
are the CIDRs of the
are the subnets of the
provider's VNet
consumer
Subnet-based
Subnet-based
Redirect for the provider Redirect for the consumer
are the subnets of the
are the subnets of the
provider
consumer
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
150
Redirect on Provider VNet
Deploying Layer 4 to Layer 7 Services
Redirect Policy
Redirect Policy
To support the Layer 4 to Layer 7 Service Redirect feature, a new redirect flag is now available for service
device connectors. The following table provides information on the existing and new flags for the service
device connectors.
ConnType
Description
redir
This value means the service node is in redirect node
for that connection. This value is only available or
valid for third-party firewalls and Network Load
Balancers.
snat
This value tells the service graph that the service node
is performing source NAT on traffic. This value is
only available or valid for the provider connector of
third-party firewalls and only on the provider
connector of a node.
snat_dnat
This value tells the service graph that the service node
is performing both source NAT and destination NAT
on traffic. This value is only available or valid for the
provider connector of third-party firewalls and only
on the provider connector of a node.
none
Default value.
Workflow for Configuring Redirect
Following is the typical workflow for configuring redirect:
1. Create one or more service devices to use with the service graph:
• Network load balancer (NLB)
• Application load balancer (ALB)
• Third-party firewall
2. Create a service graph and select the appropriate service devices for this particular service graph.
You will configure redirect at this point in the procedures:
a. Drag and drop a network load balancer, application load balancer, or firewall icon to the Drop Device
area to select that service device for the service graph.
b. To enable the redirect feature, in the Service Node window that appears, check the box next to the
Redirect option under the Consumer Connector Type and/or under the Provider Connector Type
areas, depending on where you want to enable the redirect function.
Note
Even though you might have an application load balancer in the service graph, you cannot enable redirect on
an application load balancer service device.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
151
Deploying Layer 4 to Layer 7 Services
Example Use Cases
c. Complete the remaining configurations in the Service Node window, then click Add.
3. Configure the EPG communication, where you create a contract between the consumer and the provider
EPGs.
4. Attach the service graph to the contract.
5. Configure the service device parameters.
Example Use Cases
Following are several example use cases:
• Spoke to Internet, on page 152
• Spoke to Spoke, on page 154
• Inter-Region Spoke to Spoke, on page 157
• Internet to Spoke (Inter-VRF), on page 159
• High Availability Support for Third-Party Load Balancer, on page 161
• Consumer and Provider EPGs in Two Separate VNets, on page 163
• Hub VNet with Consumer and Provider EPGs in Two Separate VNets, on page 165
Spoke to Internet
In this use case, the consumer VNet (with consumer VMs) and the hub VNet are peered using VNet peering.
A network load balancer is also deployed, fronting two firewalls for scaling. In this use case, the consumer
VMs need access to the internet for a certain reason, such as patch updates. In the consumer VNet, the route
table is modified to include a redirect for the internet in this case, and traffic is redirected to the NLB in front
of firewalls in the hub VNet. Any traffic from this consumer that is part of the service graph that is going to
the internet goes to the NLB as the next-hop. With VNet peering, traffic first goes to the NLB, then the NLB
forwards the traffic to one of the firewalls in the back end. The firewalls also perform source network address
translation (SNAT) when sending traffic to the internet.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
152
Deploying Layer 4 to Layer 7 Services
Example Use Cases
The following figure shows the packet flow for this use case.
The following figure shows the service graph for this use case.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
153
Deploying Layer 4 to Layer 7 Services
Example Use Cases
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created in
the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the overlay-2
VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the consumer side.
• In the Provider Connector Type field, leave the boxes unchecked.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT when sending traffic to the internet in this use case, in the
Provider Connector Type field, place a check in the box next to the SNAT option.
Spoke to Spoke
In this use case, traffic flows from spoke to spoke, through the hub firewall fronted by a hub NLB. Consumer
endpoints are in the consumer VNet, and the provider VNet has VMs fronted by an internal NLB (or a
third-party load balancer). The egress route table is modified in the consumer and provider VNets so that
traffic is redirected to the firewall device fronted by the NLB. Redirect is applied in both directions in this
use case.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
154
Deploying Layer 4 to Layer 7 Services
Example Use Cases
The following figure shows the packet flow for this use case.
The following figure shows the service graph for this use case.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
155
Deploying Layer 4 to Layer 7 Services
Example Use Cases
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created in
the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the overlay-2
VRF.
• In the Create Device window, next create the service devices for the provider VNet:
• In the Tenant field, choose the provider tenant.
• In the Service Type field, choose Network Load Balancer, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet for the provider
VRF.
Note
A third-party load balancer can be used in place of an internal NLB. Choose
Third-party load balancer as the Service Type. Choose the VRF and set the
interface(s) details by clicking Add Interface.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer (for the hub VNet)
• Third-Party Firewall (for the hub VNet)
• Network Load Balancer or Third-Party Load Balancer (for the provider VNet)
• In the Service Node window for the Network Load Balancer in the hub VNet:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the consumer side.
• In the Provider Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the provider side.
• In the Service Node window for the Third-Party Firewall, leave the boxes unchecked for the Consumer
Connector Type and the Provider Connector Type.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
156
Deploying Layer 4 to Layer 7 Services
Example Use Cases
• In the Service Node window for the Network Load Balancer in the provider VNet, leave the boxes
unchecked for the Consumer Connector Type and the Provider Connector Type.
Note
Ensure SNAT is configured on the third-party load balancers.
Inter-Region Spoke to Spoke
In this use case, both regions must have service devices. The consumer VNet is in region 1, the provider is
stretched across both regions (regions 1 and 2), and some endpoints are in region 1 and some endpoints are
in region 2. Different redirects are programmed for local provider endpoints and for remote region endpoints.
In this case, the firewall that is used will be the firewall that is closest to the provider endpoint side.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
For example, consider the two subnets in the consumer VNet (VRF 1) egress route table (RT):
• 30.20.10.0/24 (NLB in region 1 [R1])
• 50.20.10.0/24 (NLB in region 2 [R2])
Assume the consumer wants to send traffic to the provider VMs 30.20.10.0/24, which are local to it. In that
case, traffic will get redirected to the region 1 hub NLB and firewall, and will then go to the provider.
Now assume the consumer wants to send traffic to the provider VMs 50.20.10.0/24. In this case, the traffic
will get redirected to the region 2 hub NLB and firewall, because that firewall is local to the provider endpoint.
The following figure shows the packet flow for this use case.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
157
Deploying Layer 4 to Layer 7 Services
Example Use Cases
The following figure shows the service graph for this use case.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created in
the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the overlay-2
VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
158
Deploying Layer 4 to Layer 7 Services
Example Use Cases
• In the Service Node window for the hub NLB:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the consumer side.
• In the Provider Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the provider side.
• In the Service Node window for the Third-Party Firewall, leave the boxes unchecked for the Consumer
Connector Type and the Provider Connector Type.
In the above use case, the provider VMs can also be front-ended by a cloud native or third-party load balancer.
Internet to Spoke (Inter-VRF)
In this use case, traffic coming from the internet needs to go through the firewall before hitting the provider
endpoints. Redirect is not used in this use case.
Note
The general term "external load balancer" is used in this section because in this use case, the external load
balancer could be either an NLB, ALB or a third-party load balancer. The following examples provide
configurations using an ALB, but keep in mind that the external load balancer could be an NLB or a third-party
load balancer instead.
The external load balancer exposes the service through VIP. Internet traffic is directed to that VIP, then external
load balancers direct traffic to the firewalls in the backend pool (the external load balancers have the firewall's
untrusted interface as its backend pool). The firewall performs SNAT and DNAT, and the traffic goes to the
internal NLB VIP. The internal NLB then sends traffic to one of the provider endpoints.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
The following figure shows the packet flow for this use case.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
159
Deploying Layer 4 to Layer 7 Services
Example Use Cases
The following figure shows the service graph for this use case.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Application Load Balancer or Network Load Balancer as the Service Type, and
in the Subnets area, click Add Subnet, then choose the appropriate region, cloud context
profile, and the subnet created in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the overlay-2
VRF.
• Choose Third-Party Load Balancer as the Service Type, and choose the VRF and set the
interface(s) details by clicking Add Interface.
• In the Create Device window, next create the service devices for the provider VNet:
• In the Tenant field, choose the provider tenant.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
160
Deploying Layer 4 to Layer 7 Services
Example Use Cases
• In the Service Type field, choose Network Load Balancer, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet for the provider
VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer or Application Load Balancer (for the hub VNet)
• Third-Party Firewall (for the hub VNet)
• Network Load Balancer or Third-Party Load Balancer (for the provider VNet)
• In the Service Node window for the Network Load Balancer or Application Load Balancer for the hub
VNet, leave the boxes unchecked for the Consumer Connector Type and the Provider Connector
Type.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT and DNAT when sending traffic to the internet in this use
case, in the Provider Connector Type field, place a check in the box next to the SNAT and DNAT
options.
• In the Service Node window for the Network Load Balancer for the provider VNet, leave the boxes
unchecked for the Consumer Connector Type and the Provider Connector Type.
Note
Ensure SNAT is configured on the third-party load balancers.
High Availability Support for Third-Party Load Balancer
In this use case, traffic coming from the internet needs to go through the third-party load balancer before
hitting the provider endpoints. Redirect is not used in this use case.
The third-party load balancer is configured as the backend pool of the NLB. Secondary IP addresses of the
devices act as the target for the NLBs. You can choose to add either primary or secondary IP address (or both)
as the target for the NLBs. The third-party load balancer VMs are deployed in active-active mode only.
Third-party load balancers can not be used in active-standby high availability configuration.
Ensure that the third-party load balancers and the network load balancers have dedicated subnets.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
161
Deploying Layer 4 to Layer 7 Services
Example Use Cases
The following figure shows the service graph for this use case.
As part of the configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created in
the overlay-2 VRF.
• Choose Third-Party Load Balancer as the Service Type, and choose the VRF and set the
interface(s) details by clicking Add Interface.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Load Balancer
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
162
Deploying Layer 4 to Layer 7 Services
Example Use Cases
Note
Ensure that the Network Load Balancer and the Third-Party Load Balancer are
in the same VNet.
• In the Service Node window for the Network Load Balancer for the hub VNet, leave the boxes unchecked
for the Consumer Connector Type and the Provider Connector Type.
Note
Ensure SNAT is configured on the third-party load balancers.
Consumer and Provider EPGs in Two Separate VNets
This use case is an example configuration with two VNets, with a consumer EPG and provider EPG in separate
VNets.
• A frontend ALB, firewall, and internal NLB are inserted between the consumer and provider EPGs.
• A consumer endpoint sends traffic to the frontend ALB VIP and it is forwarded to the firewall.
• The firewall performs SNAT and DNAT, and the traffic flows to internal NLB VIP.
• The internal NLB load balances the traffic to the backend provider endpoints.
In this use case, a third-party load balancer can be used in place of the frontend ALB or an internal NLB.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
163
Deploying Layer 4 to Layer 7 Services
Example Use Cases
In the figure:
• The consumer EPG is in a consumer VNet.
• The provider EPG and all the service devices are in the provider VNet.
• The application load balancer, network load balancer (or third-party load balancer), and firewall need to
have their own subnet in the VNet.
Packet flow for both the directions is shown in the following figure:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
164
Deploying Layer 4 to Layer 7 Services
Example Use Cases
Hub VNet with Consumer and Provider EPGs in Two Separate VNets
This use case is an example configuration with three VNets: a hub VNet, and a consumer EPG and provider
EPG in two separate VNets.
• A frontend ALB and firewall are inserted within the hub VNet, which is between the consumer and
provider EPGs.
• An internal NLB is inserted in the provider EPG.
• A consumer endpoint sends traffic to the frontend ALB VIP and it is forwarded to the firewall.
• The firewall performs SNAT and DNAT, and the traffic flows to internal NLB VIP.
• The internal NLB load balances the traffic to the backend provider endpoints.
In this use case, a third-party load balancer can be used in place of the frontend ALB or an internal NLB.
Ensure that all the Layer 4 to Layer 7 services devices used in this use case have dedicated subnets.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
165
Deploying Layer 4 to Layer 7 Services
Example Use Cases
In the figure:
• The consumer EPG is in a consumer VNet.
• The provider EPG and the internal NLB are in the provider VNet.
• The frontend ALB and firewall are in the hub VNet
• The application load balancer, network load balancer (or third-party load balancer), and firewall need to
have their own subnet in the VNet.
Packet flow for both the direction is shown in the following figure:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
166
Deploying Layer 4 to Layer 7 Services
Example Use Cases for Service Graphs with Cloud Native and Third-Party Services
Example Use Cases for Service Graphs with Cloud Native and
Third-Party Services
Following are several example use case for service graphs with cloud native and third-party services, with
and without redirect. Refer to Using Service Graphs with Cloud Native and Third-Party Services, on page
142 for more information and for guidelines and limitations.
Example Use Cases Without Redirect
Following are several example use case for service graphs with cloud native and third-party services without
redirect.
You will be configuring cloud service EPGs as part of the process for each of these use cases. You must have
the NSG-per-subnet configuration enabled if you are configuring cloud service EPGs. See Security Groups,
on page 33 and Cloud Service Endpoint Groups, on page 27 for more information.
• Single-Node Service Graph for Internet Inbound Traffic: Non-Managed Service EPG as Provider, on
page 168
• Single-Node Service Graph for Internet Inbound Traffic: Cloud Native Service EPG as Provider, on page
169
• Two-Node Service Graph for Internet Inbound Traffic: Cloud Native Managed Service EPG as Provider,
on page 170
• Three-Node Service Graph for Internet Inbound Traffic: Cloud Native Managed Service EPG as Provider,
on page 172
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
167
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
Note
For each of the following use cases, a similar topology with a single node, two node and three node service
graph with the service EPG as the provider can be supported for East-West traffic in the cloud. In these use
cases, the consumer will be a cloud EPG and the load balancer used will be an internal load balancer.
Single-Node Service Graph for Internet Inbound Traffic: Non-Managed Service EPG as Provider
This use case has a single-node service graph, where the service node is a load balancer (application load
balancer, network load balancer, or third-party load balancer).
In this use case, the service EPG is the provider, and an external EPG is configured on the consumer side.
The service EPG can be in the hub or spoke VNets. The service endpoints are learned dynamically and are
added to the application load balancer or network load balancer.
To configure this use case:
1. Create the external EPG on the consumer side.
See Creating an External EPG Using the Cisco Cloud APIC GUI, on page 59 for those procedures. Select
the infra tenant for this external EPG.
2. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, using
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure Storage would be a
supported service type with a Cloud Native deployment type.
• Deployment type: Cloud
Native
or Third-Party
• Access type: Private
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
168
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
Make the following selections:
• In the Create Device window, create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose Application Load Balancer or Network Load Balancer as the Service Type, and in
the Subnets area, click Add Subnet, then choose the appropriate region, cloud context profile,
and the subnet created in the overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the Application Load Balancer or Network
Load Balancer.
• In the Service Node window for the Application Load Balancer or Network Load Balancer for the
hub VNet, leave the boxes unchecked for the Consumer Connector Type and the Provider
Connector Type.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Single-Node Service Graph for Internet Inbound Traffic: Cloud Native Service EPG as Provider
This use case has a single-node service graph, where the service node is a load balancer (application load
balancer, network load balancer, or third-party load balancer).
In this use case, the service EPG is the provider, and an external EPG is configured on the consumer side.
The service EPG can be in the hub or spoke VNets.
To configure this use case:
1. Create the external EPG on the consumer side.
See Creating an External EPG Using the Cisco Cloud APIC GUI, on page 59 for those procedures. Select
the infra tenant for this external EPG.
2. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
169
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, using
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure ApiManagement Services
would be a supported service type with a Cloud Native Managed deployment type.
• Deployment type: Cloud
• Access type: Public
Native Managed
and Private
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
Make the following selections:
• In the Create Device window, create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose Application Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created in the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the Application Load Balancer.
• In the Service Node window for the Application Load Balancer for the hub VNet, leave the boxes
unchecked for the Consumer Connector Type and the Provider Connector Type.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Two-Node Service Graph for Internet Inbound Traffic: Cloud Native Managed Service EPG as Provider
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Because this two-node service graph doesn't use redirect, SNAT+DNAT is performed on the firewall. The
DNATed address is assumed to be a network load balancer or an equivalent service. For this use case, the
service graph will only establish route reachability to the load balancer's subnet.
In this use case, the service EPG is the provider, and an external EPG is configured on the consumer side.
The service EPG can be in the hub or spoke VNets.
These actions take place in this use case, as shown in the following figure:
1. Traffic is destined to the network load balancer public VIP, which then load balances the traffic to the
firewall (DNAT).
2. SNAT+DNAT is performed on the firewall.
3. For the return traffic, Azure translates the source IP to the network load balancer public VIP.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
170
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
To configure this use case:
1. Create the external EPG on the consumer side.
See Creating an External EPG Using the Cisco Cloud APIC GUI, on page 59 for those procedures. Select
the infra tenant for this external EPG.
2. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, using
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure Kubernetes Services
(AKS) would be a supported service type with a Cloud Native Managed deployment type.
• Deployment type: Cloud
Native Managed
• Access type: Private
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
171
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer, leave the boxes unchecked for the
Consumer Connector Type and the Provider Connector Type.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT and DNAT when sending traffic to the internet in this use
case, in the Provider Connector Type field, place a check in the box next to the SNAT and
DNAT options.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Three-Node Service Graph for Internet Inbound Traffic: Cloud Native Managed Service EPG as Provider
This use case has a three-node service graph, where the service nodes are:
• First service device: Network load balancer in the hub VNet
• Second service device: Firewall in the hub VNet
• Third service device: Third-party load balancer in the hub VNet or spoke VNet
Because this three-node service graph doesn't use redirect, SNAT+DNAT is performed on the firewall. The
DNATed address is assumed to be a load balancer or an equivalent service.
In this use case, the service EPG is the provider, and an external EPG is configured on the consumer side.
The service EPG can be in the hub or spoke VNets.
These actions take place in this use case, as shown in the following figure:
1. Traffic is destined to the first service device, the network load balancer public VIP, which then load
balances the traffic to the firewall (DNAT).
2. SNAT+DNAT is performed on the firewall, which is the second service device.
3. Traffic moves to the third service device, the third-party load balancer, which has SNAT configured.
4. For the return traffic, Azure translates the source IP to the network load balancer public VIP.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
172
Deploying Layer 4 to Layer 7 Services
Example Use Cases Without Redirect
To configure this use case:
1. Create the external EPG on the consumer side.
See Creating an External EPG Using the Cisco Cloud APIC GUI, on page 59 for those procedures. Select
the infra tenant for this external EPG.
2. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure ApiManagement Services
would be a supported service type with a Cloud Native Managed deployment type.
• Deployment type: Cloud
Native Managed
• Access type: Private
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• For the first service device, choose Application Load Balancer as the Service Type, and
in the Subnets area, click Add Subnet, then choose the appropriate region, cloud context
profile, and the subnet created in the overlay-2 VRF.
• For the second service device, choose Third-Party Firewall as the Service Type, and in
the VRF field, choose the overlay-2 VRF.
• If the third service device is in the hub VNet, choose Third-Party Load Balancer as the
Service Type, and choose the VRF and set the interface(s) details by clicking Add
Interface.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
173
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• In the Create Device window, next create the service devices for the provider VNet, if necessary (if
the third service device is in the provider VNet):
• In the Tenant field, choose the provider tenant.
• In the Service Type field, choose Third-Party Load Balancer, and in the Subnets area, click
Add Subnet, then choose the appropriate region, cloud context profille, and the subnet for the
provider VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Application Load Balancer (for the hub VNet)
• Third-Party Firewall (for the hub VNet)
• Third-Party Load Balancer (for the hub or provider VNet)
• In the Service Node window for the Application Load Balancer for the hub VNet, leave the boxes
unchecked for the Consumer Connector Type and the Provider Connector Type.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT and DNAT when sending traffic to the internet in this use
case, in the Provider Connector Type field, place a check in the box next to the SNAT and
DNAT options.
• Ensure SNAT is configured on the third party load balancers.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Example Use Cases With Redirect
Following are several example use case for service graphs with cloud native and third-party services with
redirect.
You will be configuring cloud service EPGs as part of the process for each of these use cases. You must have
the NSG-per-subnet configuration enabled if you are configuring cloud service EPGs. See Security Groups,
on page 33 and Cloud Service Endpoint Groups, on page 27 for more information.
• Two-Node Service Graph for Internet Outbound, on page 175
• Two-Node Service Graph for East-West, on page 176
• Two-Node Service Graph for East-West with SNAT Option, on page 178
• Two-Node Service Graph for Inbound Traffic via Express Route Gateway, on page 180
• Two-Node Service Graph for Inbound Traffic via Express Route Gateway with SNAT Option, on page
182
• Three-Node Service Graph for Inbound Traffic via Express Route Gateway, on page 184
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
174
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
Two-Node Service Graph for Internet Outbound
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Redirect is enabled on the consumer side in this use case, and SNAT is enabled on the firewall.
In this use case, the service EPG is the consumer, and an external EPG is configured on the provider side.
Note
We recommend that you do not use 0.0.0.0/0 in an external EPG if the Layer 4 to Layer 7 service graph is
used for PaaS that uses its own UDR for internet reachability.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
2. SNAT is performed on the firewall.
3. The return traffic comes back to the firewall SNAT IP address.
4. At this point in the return direction, the return traffic doesn't go through the network load balancer.
To configure this use case:
1. Create the external EPG on the provider side.
See Creating an External EPG Using the Cisco Cloud APIC GUI, on page 59 for those procedures.
• Select the infra tenant for this external EPG.
• Do not configure the external EPG with the 0.0.0.0/0 subnet.
2. Create the service EPG on the consumer side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure Kubernetes Services
(AKS) would be a supported service type with a Cloud Native Managed deployment type.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
175
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• Deployment type: Cloud
Native Managed
• Access type: Private
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, leave the boxes unchecked.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT when sending traffic to the internet in this use case, in the
Provider Connector Type field, place a check in the box next to the SNAT option.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Two-Node Service Graph for East-West
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Redirect is enabled on both the consumer and the provider side in this use case.
In this use case, the consumer and provider could be cloud EPGs or service EPGs.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
176
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
2. SNAT is not performed on the firewall in this use case.
3. The return traffic is redirected to the network load balancer, which then load balances the traffic to the
firewall.
4. At this point in the return direction, the return traffic comes back to the consumer.
To configure this use case:
1. If you are using service EPGs for the consumer or provider, create the service EPG and assign the
appropriate deployment type and access type to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• The service EPG as the consumer could have the following settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud
Service Endpoint Groups, on page 27 for more information). For example, Azure Kubernetes
Services (AKS) would be a supported service type with a Cloud Native Managed deployment
type.
• Deployment type: Cloud
Native Managed
• Access type: Private
• The service EPG as the provider could have the following settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud
Service Endpoint Groups, on page 27 for more information). For example, Azure Storage
File would be a supported service type with a Cloud Native deployment type.
• Deployment type: Cloud
Native
• Access type: Private
2. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
177
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the hub NLB:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the provider side.
• In the Service Node window for the Third-Party Firewall, leave the boxes unchecked for the
Consumer Connector Type and the Provider Connector Type.
3. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Two-Node Service Graph for East-West with SNAT Option
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Redirect is enabled only on the consumer side and SNAT is enabled on the firewall in this use case.
In this use case, the consumer and provider could be cloud EPGs or service EPGs.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
2. SNAT is performed on the firewall.
3. The return traffic comes back to the firewall SNAT IP address.
4. At this point in the return direction, the return traffic doesn't go through the network load balancer.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
178
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
To configure this use case:
1. If you are using service EPGs for the consumer or provider, create the service EPG and assign the
appropriate deployment type and access type to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• The service EPG as the consumer could have the following settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud
Service Endpoint Groups, on page 27 for more information). For example, Azure Active
Directory Domain Services would be a supported service type with a Cloud Native Managed
deployment type.
• Deployment type: Cloud
Native Managed
• Access type: Private
• The service EPG as the provider could have the following settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud
Service Endpoint Groups, on page 27 for more information). For example, Azure Storage
File would be a supported service type with a Cloud Native deployment type.
• Deployment type: Cloud
Native
• Access type: Private
2. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
179
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, leave the boxes unchecked.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT when sending traffic to the internet in this use case, in the
Provider Connector Type field, place a check in the box next to the SNAT option.
3. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Two-Node Service Graph for Inbound Traffic via Express Route Gateway
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Redirect is enabled on both the consumer and the provider side in this use case.
In this use case, the service EPG is the provider, and the express route is on the consumer side.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
2. SNAT is not performed on the firewall in this use case.
3. The return traffic is redirected to the network load balancer, which then load balances the traffic to the
firewall.
4. At this point in the return direction, the return traffic comes back to the consumer.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
180
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
To configure this use case:
1. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure Active Directory Domain
Services would be a supported service type with a Cloud Native Managed deployment type.
• Deployment type: Cloud
Native Managed
• Access type: Private
2. Deploy the express route gateway on the consumer side.
See Deploying Express Route Gateway Using Redirect, on page 251 for those procedures.
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
181
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, leave the boxes unchecked.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT when sending traffic to the internet in this use case, in the
Provider Connector Type field, place a check in the box next to the SNAT option.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Two-Node Service Graph for Inbound Traffic via Express Route Gateway with SNAT Option
This use case has a two-node service graph, where the service nodes are a network load balancer and a firewall.
Redirect is enabled only on the consumer side and SNAT is enabled on the firewall in this use case.
In this use case, the service EPG is the provider, the express route is on the consumer side.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
2. SNAT is performed on the firewall.
3. The return traffic comes back to the firewall SNAT IP address.
4. At this point in the return direction, the return traffic doesn't go through the network load balancer.
To configure this use case:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
182
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
1. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Redis Cache would be a supported
service type with a Cloud Native Managed deployment type.
• Deployment type: Cloud
Native Managed
• Access type: Private
2. Deploy the express route gateway on the consumer side.
See Deploying Express Route Gateway Using Redirect, on page 251 for those procedures.
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profille, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer
• Third-Party Firewall
• In the Service Node window for the Network Load Balancer:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, leave the boxes unchecked.
• In the Service Node window for the Third-Party Firewall:
• In the Consumer Connector Type field, leave the boxes unchecked.
• Because the firewall performs SNAT when sending traffic to the internet in this use case, in the
Provider Connector Type field, place a check in the box next to the SNAT option.
4. Deploy the Layer 4 to Layer 7 services.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
183
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Three-Node Service Graph for Inbound Traffic via Express Route Gateway
This use case has a three-node service graph, where the service nodes are:
• First service device: Network load balancer in the hub VNet
• Second service device: Firewall in the hub VNet
• Third service device: Application load balancer in the hub or spoke VNet
Redirect is enabled on both the consumer and the provider side in this use case.
In this use case, the service EPG is the provider. The express route is on the consumer side, and the consumer
can could be a cloud EPG or a service EPG.
These actions take place in this use case, as shown in the following figure:
1. Traffic is redirected to the network load balancer, which then load balances the traffic to the firewall.
2. SNAT is not performed on the firewall in this use case.
3. Traffic moves to the third service device, the application load balancer, which has SNAT configured.
4. The return traffic is redirected to the network load balancer, which then load balances the traffic to the
firewall.
5. At this point in the return direction, the return traffic comes back to the consumer.
To configure this use case:
1. Create the service EPG on the provider side and assign the appropriate deployment type and access type
to the service EPG.
See Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66 for those procedures, with
these settings:
• Service Type: Any supported service type, depending on the deployment type (see Cloud Service
Endpoint Groups, on page 27 for more information). For example, Azure ApiManagement Services
would be a supported service type with a Cloud Native Managed deployment type.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
184
Deploying Layer 4 to Layer 7 Services
Example Use Cases With Redirect
• Deployment type: Cloud
Native Managed
• Access type: Private
2. Deploy the express route gateway on the consumer side.
See Deploying Express Route Gateway Using Redirect, on page 251 for those procedures.
3. Configure the service graph.
See Creating Service Devices Using The Cloud APIC GUI, on page 191 for those procedures.
As part of the redirect configuration for this use case, you would make the following selections:
• In the Create Device window, first create the service devices for the hub VNet:
• In the Tenant field, choose the infra tenant.
• Choose the type of service device in the Service Type field:
• Choose Network Load Balancer as the Service Type, and in the Subnets area, click Add
Subnet, then choose the appropriate region, cloud context profile, and the subnet created
in the overlay-2 VRF.
• Choose Third-Party Firewall as the Service Type, and in the VRF field, choose the
overlay-2 VRF.
• In the Create Device window, next create the service devices for the provider VNet:
• In the Tenant field, choose the provider tenant.
• In the Service Type field, choose Application Load Balancer, and in the Subnets area, click
Add Subnet, then choose the appropriate region, cloud context profille, and the subnet for the
provider VRF.
Note
A third party load balancer can be used in place of an internal NLB. Choose
Third Party Load Balancer as the Service Type. Choose the VRF and set the
interface(s) details by clicking Add Interface.
• In the Create Service Graph window, drag-and-drop the following service devices, in this order:
• Network Load Balancer (for the hub VNet)
• Third-Party Firewall (for the hub VNet)
• Application Load Balancer (for the provider VNet)
• In the Service Node window for the Network Load Balancer in the hub VNet:
• In the Consumer Connector Type field, place a check in the box next to the Redirect option
to enable the redirect function on the consumer side.
• In the Provider Connector Type field, place a check in the box next to the Redirect option to
enable the redirect function on the provider side.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
185
Deploying Layer 4 to Layer 7 Services
Guidelines and Limitations for Redirect
• In the Service Node window for the Third-Party Firewall, leave the boxes unchecked for the
Consumer Connector Type and the Provider Connector Type.
• In the Service Node window for the Network Load Balancer in the provider VNet, leave the boxes
unchecked for the Consumer Connector Type and the Provider Connector Type.
Note
Ensure SNAT is configured on the third party load balancers.
4. Deploy the Layer 4 to Layer 7 services.
See Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI, on page 199 for those
procedures. Attach the contract that exists between the consumer and provider to the service graph.
Guidelines and Limitations for Redirect
Following are the guidelines and limitations for redirect:
• All the Layer 4 to Layer 7 services devices should have their own dedicated subnet.
• Intra VRF Layer 4 to Layer 7 services redirection within a region:
• Layer 4 to Layer 7 services redirect is not supported for east-west deployment when the consumer
EPG and provider EPG are in the same VNet.
• Layer 4 to Layer 7 services redirect is supported for north-south deployment if the external EPG is
a provider EPG, regardless of whether the consumer EPG and provider EPG are in same VNet or
not.
• Intra-VRF Layer 4 to Layer 7 services redirection across regions:
• Inter-Region Layer 4 to Layer 7 services redirection are supported. However, the Consumer EPG
and the Provider EPG should not stretch.
• A region shouldn't have both a consumer EPG and a provider EPG in the same VRF. For example,
if region 1 has a consumer EPG only and region 2 has a provider EPG only, this is supported, but
region 1 can't have both the consumer EPG and the provider EPG.
• Consumer and Provider EPG should be a subnet-based EPG.
• For the inter-region service graphs with Layer 4 to Layer 7 services redirection, service devices should
be deployed in the provider EPG’s region. If provider EPG is stretched across regions, service devices
should be deployed in each region .
• For the external EPG as provider, service devices need to be deployed in the region local to consumer
EPG. If the consumer EPG is stretched across regions, service devices should be deployed in each region.
• Between a consumer VNet and a provider EPG, only one redirect device can be inserted through a service
graph. For example, if consumer EPG1 and consumer EPG2 are in a consumer VNet, and a provider
EPG3 is in a provider VNet, you must use the same redirect device for a contract between EPG1 and
EPG3, and a contract between EPG2 and EPG3.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
186
Deploying Layer 4 to Layer 7 Services
Guidelines and Limitations for Redirect
Note
The limitation is because of the cloud provider allows only one next hop for a
given destination in user-defined routes.
• The following table provides information on the specific redirect configurations that are supported or
unsupported, where:
• NLB stands for network load balancer
• ALB stands for application load balancer
• FW stands for firewall
Note
Redirection to a third party load balancer is not supported.
Service Chain Option
Spoke-to-Spoke
Spoke-to-External
External-to-Spoke
(consumer is spoke)
(consumer is external)
Intra-VNet
Inter-VNet
Intra-VNet
Inter-VNet
Intra-VNet
Inter-VNet
Supported
Supported
Not
supported
Not
supported
Supported
Supported
FW (no SNAT)2
Not
supported
Supported
Not
supported
Not
supported
Not
supported
Not
supported
FW (SNAT)3
Supported
Supported
Supported
Supported
Not
supported
Not
supported
Not
supported
Supported
Not
supported
Not
supported
Not
supported
Not
supported
Not
supported
Supported
Supported
Supported
Not
supported
Not
supported
NLB/ALB1-FW(SNAT+DNAT)6-NLB/ALB1 Supported
Supported
Not
Supported
Not
Supported
Supported
Supported
Supported
Not
Supported
Not
Supported
Supported
Supported
NLB/ALB1
1
LB(SNAT)
• NLB2-FW(no SNAT)1
• NLB2-FW(no SNAT)1-NLB/ALB1
• NLB2-FW(no SNAT)1-LB(SNAT)1
NLB4-FW(SNAT)5
NLB/ALB1-FW(ANT+DNAT)6-LB(SNAT)1
(No redirection)
NLB1-LB(SNAT)1
(No redirection)
Supported
1
Unchecked on both consumer and provider connector or options are not applicable for ALB.
Redirect is enabled on both consumer and provider connector.
3
Redirect is enabled on consumer connector. SNAT is enabled on provider connector.
2
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
187
Deploying Layer 4 to Layer 7 Services
Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI
4
Redirect is enabled on consumer connector. Unchecked on provider connector.
Unchecked on consumer connector. SNAT is enabled on provider connector.
6
Unchecked on consumer connector. SNAT+DNAT is enabled on provider connector.
5
Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI
After an installation, you will see overlay-1 and overlay-2 in the Cisco Cloud APIC. However, on the Azure
portal, you will only see overlay-1. This is because overlay-2 is simply a logical extension of overlay-1, and
is used to hold additional the CIDRs that you might need if you are deploying firewalls or load balancers on
the infra VNet. This section provides instructions for adding new CIDRs to overlay-2.
In some situations, you might have to disable VNet peering before adding new CIDRs or editing existing
CIDRs in overlay-2. This is due to a limitation in Azure, where you cannot update a CIDR on a VNet if it has
active VNet peerings. To add the CIDRs, you first have to remove VNet peerings for that VNet, then you can
update the CIDRs. Once you have updated the CIDRs, you can then re-enable the VNet peerings.
These procedures provide instructions for disabling Hub Network Peering, which removes all of the VNet
peerings associated with a particular infra VNet.
• If you have an additional CIDR already created on the infra VNet, but you simply need to add additional
subnets to that existing CIDR, you do not have to disable Hub Network Peering for that particular infra
VNet before adding those subnets. To add additional subnets to an existing CIDR:
1. Navigate to the appropriate cloud context profile in that case (Application Management > Cloud
Context Profiles).
2. Double-click the cloud context profile where you want to add a subnet to an existing CIDR, then go
to Step 10, on page 190 to add the new subnets to an existing CIDR.
• If you are adding a new CIDR in the infra VNet, or if you are deleting a CIDR or editing a CIDR in the
infra VNet in some other way (other than adding subnets), then you must disable Hub Network Peering
for that particular infra VNet. You will then re-enable Hub Network Peering again after you have added
the CIDR. The following procedure provides those instructions.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
188
Deploying Layer 4 to Layer 7 Services
Adding a New CIDR to Overlay-2 Using the Cloud APIC GUI
Note
If you are adding new CIDRs to overlay-2 and you have a multi-site deployment where you are running on
the following releases:
• Release 5.2(1) or later on the Cloud APIC
• Release 3.3 or later on the Multi-Site Orchestrator
After you have added the new CIDRs and re-enabled Hub Network Peering, wait at least five minutes for the
CIDRs to come up before refreshing the site on Multi-Site Orchestrator and deploying the infra configuration
from the Multi-Site Orchestrator. It will take time for the CIDRs to get deployed on Azure, so newly-added
CIDRs might not get propagated to the remote site through Multi-Site Orchestrator if you do not wait at least
minutes before refreshing the site and deploying the infra configuration from the Multi-Site Orchestrator.
If you see the following error message after you deploy the infra configuration from the Multi-Site Orchestrator:
Invalid configuration CT_Remotectx_cidr: Remote Site CIDR
This means that you did not wait long enough before deploying the infra configuration from the Multi-Site
Orchestrator and the newly-added CIDRs did not get propagated to the remote site. If this happens:
1. Disable Hub Network Peering on the Cloud APIC
2. Refresh the site on Multi-Site Orchestrator, then deploy the infra configuration from the Multi-Site
Orchestrator
3. Re-enable Hub Network Peering on the Cloud APIC
4. Wait at least five minutes (or a longer period than you waited for previously), then refresh the site and
deploy the infra configuration from the Multi-Site Orchestrator again
Step 1
Log in to the Cloud APIC, if you are not logged in already.
Step 2
In the left navigation bar, navigate to Application Management > Cloud Context Profiles.
The existing cloud context profiles are displayed.
Step 3
Double-click the cloud context profile where you want to disable Hub Network Peering.
The overview window for that cloud context profile appears. You should see Enabled in the Hub Network Peering
area in this overview window, which indicates that Hub Network Peering is enabled.
Step 4
Click the pencil icon to edit this cloud context profile.
The Edit Cloud Context Profile window appears.
Step 5
In the Edit Cloud Context Profile window, locate the Hub Network Peering field and click the check box to remove
the checkmark from the Enabled field.
Disabling the Hub Network Peering option does not remove VNet peering at the global level, but rather removes all
of the VNet peerings associated with this particular infra VNet.
Step 6
Click Save.
The overview window for that cloud context profile appears again. You should see Disabled in the Hub Network
Peering area in this overview window, which indicates that Hub Network Peering is now disabled.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
189
Deploying Layer 4 to Layer 7 Services
Deploying a Service Graph
Step 7
To add a new CIDR, click the pencil icon to edit this cloud context profile again.
The Edit Cloud Context Profile window appears again.
Step 8
Click Add CIDR.
The Add CIDR dialog box appears.
Step 9
Add the new CIDR in the CIDR Block Range field.
Do not click the box in the Primary field (do not put a check in the box next to yes in the Primary field).
Step 10
Click Add Subnet and enter the necessary subnet addresses in the Address field.
Continue to click Add Subnet for additional subnets, if necessary.
Step 11
When you have finished adding all of the necessary information in the Add CIDR window, click Add.
The Edit Cloud Context Profile window appears again.
Step 12
Confirm the information in the Edit Cloud Context Profile window, then click Save.
The overview window for that cloud context profile appears. You should now see the new CIDR listed in the CIDR
Block Range area.
Step 13
If you disabled Hub Network Peering at the beginning of these procedures, re-enable it at this time.
a) Click the pencil icon to edit this cloud context profile.
The Edit Cloud Context Profile window appears.
b) In the Edit Cloud Context Profile window, locate the Hub Network Peering field and click the check box to add
the checkmark in the Enabled field to re-enable VNet peerings for this particular infra VNet.
c) Click Save.
The overview window for that cloud context profile appears again. You should see Enabled in the Hub Network
Peering area in this overview window, which indicates that Hub Network Peering is now re-enabled again.
As described previously, if you were to go to the Azure portal at this point, you will see any additional CIDRs and
subnets that you added in these procedures in the overlay-1 VNet in Azure, which is the correct and expected behavior.
Deploying a Service Graph
The service graph enables you to define how traffic flows between devices, how the traffic comes into the
network, which devices the traffic passes through, and how the traffic leaves the network.
The Service graph can be deployed in two ways:
• Single node service graph: Only one device is deployed.
• Multinode service graph: Upto three nodes can be added to the service chain.
Before you can deploy a service graph in either a single node or multinode, you must configure the following:
1. A tenant
2. An application profile
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
190
Deploying Layer 4 to Layer 7 Services
Deploying a Service Graph Using the GUI
3. A consumer EPG
4. A provider EPG
5. A VRF
6. A cloud context profile
7. A contract with a filter
Deploying a Service Graph Using the GUI
The following sections describe how to deploy a service graph using the GUI.
Creating Service Devices Using The Cloud APIC GUI
Before you begin
This section explains how to create service devices that can be used in a service graph through the Cisco Cloud
APIC GUI.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Services > Devices > Create Device. The Create
Device dialog box appears.
Step 4
Enter the appropriate values in each field as listed in the following Create Device Dialog Box Fields table then continue.
Refer to the following tables for information specific to each type of service device.
• For an Application Load Balancer, see 4.a, on page 191.
• For a Network Load Balancer, see 4.b, on page 192.
• For a Third Party Load Balancer, see 4.c, on page 194.
• For a Third Party Firewall, see 4.d, on page 195.
a) Enter the necessary information for an Application Load Balancer:
Properties
Description
General
Name
Enter the name of the device.
Tenant
To choose a tenant:
1. Click Select Tenant. The Select Tenant dialog appears.
2. From the column on the left, click to choose a tenant.
3. Click Select. You return to the Create Device dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
191
Deploying Layer 4 to Layer 7 Services
Creating Service Devices Using The Cloud APIC GUI
Properties
Description
Settings
Service Type
Choose the device type:
• Application Load Balancer
ALB SKU
Choose from:
• Standard
• Standard V2
VM Instance Count Enter a number in the VM Instance Count text box.
Note
VM Instance Size
Click the radio button for the VM instance size you want to choose: large, medium, or
small.
Note
Scheme
This is applicable only for the Application Gateway.
This is applicable only for the Application Gateway.
Choose Internet Facing or Internal.
• Internet Facing— This is used for configuring a public IP for the balancer. This is
assigned by Azure.
• Internal—Click to choose either Dynamic or Static under IP Address Assignment.
• Dynamic—Dynamic IP addresses are assigned by Azure. Dynamic IP addresses
change each time the VMs boot up.
• Static—Enter an IP address based on the CIDRs defined in Cloud Context Profile
and check that the IP address is in the same subnet as the ALB.
ALB SKU Standard supports static and dynamic IP addresses. ALB SKU Standard
V2 support static IP addresses only.
Subnet
To choose a subnet:
1. Click Select Region. The Select Region dialog box appears. From the Select Region
dialog, click to choose a region in the left column then click Select.
2. Click Select Cloud Context Profile. The Select Cloud Context Profile dialog box
appears.
3. Click Select Subnet. The Select Subnet dialog box appears. The Static IP Addresses
text box is displayed. Enter the IP address of the load balancer. Click the tick mark on
the right to confirm.
4. To add additional subnets, repeat steps a-c.
b) Enter the necessary information for a Network Load Balancer:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
192
Deploying Layer 4 to Layer 7 Services
Creating Service Devices Using The Cloud APIC GUI
Table 34: Create Device Dialog Box Fields for Network Load Balancer
Properties
Description
General
Name
Enter the name of the load balancer.
Settings
Service Type
Choose the device type:
• Network Load Balancer
Allow All Traffic
Determine if you want to enable the Allow All Traffic option.
Enabling the Allow All Traffic option will allow all inbound and outbound access to the
subnet on which the interface belongs. See About Allow All Traffic Option, on page 146 for
more information.
Note
Ensure that this does not present a security risk before enabling this option.
• If you want to allow all traffic, in the Allow All Traffic area, click the box next to the
Enabled field.
• If you do not want to allow all traffic, in the Allow All Traffic area, leave the box
unchecked (unselected) next to the Enabled field.
Scheme
Choose Internet Facing or Internal.
• Internet Facing— This is used for configuring a public IP for the balancer. This is
assigned by Azure.
• Internal—Click to choose either Dynamic or Static under IP Address Assignment.
• Dynamic—Dynamic IP addresses are assigned by Azure. Dynamic IP addresses
change each time the VMs boot up.
• Static—Enter an IP address based on the CIDRs defined in Cloud Context Profile
and check that the IP address is in the same subnet as the NLB. Static IP addresses
are associated to load balancers.
Note
Cloud APIC creates standard SKU NLBs only.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
193
Deploying Layer 4 to Layer 7 Services
Creating Service Devices Using The Cloud APIC GUI
Properties
Description
Subnet
To choose a subnet:
1. Click Select Region. The Select Region dialog box appears. From the Select Region
dialog, click to choose a region in the left column then click Select.
2. Click Select Cloud Context Profile. The Select Cloud Context Profile dialog box
appears.
3. Click Select Subnet. The Select Subnet dialog box appears. The Static IP Addresses
text box is displayed. Enter the IP address of the load balancer. Click the tick mark on
the right to confirm.
4. To add additional subnets, repeat steps a-c.
c) Enter the necessary information for a Third Party Load Balancer:
Table 35: Create Device Dialog Box Fields for Third Party Load Balancer
Properties
Description
General
Name
Enter the name of the device.
Tenant
To choose a tenant:
1. Click Select Tenant. The Select Tenant dialog appears.
2. From the column on the left, click to choose a tenant.
3. Click Select. You return to the Create Device dialog box.
Settings
Service Type
Choose the device type:
• Third Party Load Balancer
Creation Mode
Select Selectors.
VRF and Interfaces fields are displayed.
VRF
Click Select VRF. In the Select VRF dialog box that opens, click to choose a VRF in the
left column. Click Select.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
194
Deploying Layer 4 to Layer 7 Services
Creating Service Devices Using The Cloud APIC GUI
Properties
Description
Interface
Click Add Interface. The Interfaces window is displayed.
1. Enter a name for the external interface in the Interface Settings field.
2. Click Add Interface selector.
3. In the Interface Selector Settings page, enter the name of the interface.
4. In the Match Expressions field, click Match Expression and select
• Key: This can be IP, region or a custom based tag selector.
• Operator: This can be equal, not equals, in, not in, has key, or does not have key.
• Value: IP address of the external or internal network of third party load balancer.
5. Click the tick mark to add the interface and then click Save (Interfaces window).
6. Click Save (Create Device window).
Click Add Interface and repeat steps a - e to add more interfaces.
Note
Third party load balancer interfaces should be configured with subnet-based
selectors when deployed in a multi-node service graph.
d) Enter the necessary information for a Third Party Firewall:
Table 36: Create Device Dialog Box Fields for Third Party Firewall
Properties
Description
General
Name
Enter the name of the device.
Settings
Service Type
Choose the device type:
• Third party firewall
Note
VRF
Third party firewall cannot be the first device in a multinode service graph.
To choose a VRF:
1. Click Select VRF. The Select VRF dialog box appears.
2. From the Select VRF dialog, click to choose a VRF in the left column then click Select.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
195
Deploying Layer 4 to Layer 7 Services
Creating a Service Graph Template Using the Cisco Cloud APIC GUI
Properties
Description
Interfaces
Click Add Interface.
The Settings page appears.
1. In the Name field, enter the name of the interface.
2. Determine if you want to enable the Allow All Traffic option.
Enabling the Allow All Traffic option will allow all inbound and outbound access to
the subnet on which the interface belongs. See About Allow All Traffic Option, on page
146 for more information.
Note
Ensure that this does not present a security risk before enabling this option.
• If you want to allow all traffic, in the Allow All Traffic area, click the box next to
the Enabled field.
• If you do not want to allow all traffic, in the Allow All Traffic area, leave the box
unchecked (unselected) next to the Enabled field.
3. Click Add Interface Selector.
4. Enter the name of the interface selector.
5. Click on Match Expressions and select
• Key: This can be IP, region or a custom based tag selector.
• Operator: This can be equal, not equals, in, not in, has key, or does not have key.
• Value: IP address of the app, web, internal network, management network, or
external network.
6. Click Add.
7. Repeat steps a - f to add more interfaces.
Step 5
Click Save when finished.
Step 6
The Create Service Graph dialog box appears. Click on the Create another Third Party Firewall to create another
device. The Create Device dialog box appears.
Note
The UI usually asks to create a previously created device. However, on clicking it we return back to the Create
Device page. Here we can choose the device that needs to be created. The first device should never be the Third
Party Firewall.
Creating a Service Graph Template Using the Cisco Cloud APIC GUI
This section explains how to configure a service graph template for a single node or a multinode, using the
Cisco Cloud APIC GUI .
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
196
Deploying Layer 4 to Layer 7 Services
Creating a Service Graph Template Using the Cisco Cloud APIC GUI
Before you begin
You have already created the devices.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Services > Service Graph > Create Service Graph.
The Create Service Graph pop-up appears. Click on Let's Get Started.
Step 4
Enter the appropriate values in each field as listed in the following Create Service Graph Dialog Box Fields table then
continue.
Table 37: Create Service Graph Dialog Box Fields (for single node)
Properties
Description
General
Name
Enter the name of service graph template.
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog appears.
b. From the column on the left, click to choose a tenant.
c. Click Select. You return to the Create Service Graph dialog box.
Description
Enter a description of the service graph template.
Settings
Select a Device
To choose a device:
a. Click Select Device. The Select Device dialog appears.
b. From the column on the left, click to choose a device. Drag and drop the device in the Drop
Device space below. This will open a small window where the actual device for this device
type can be selected.
c. Click Select. You return to the Create Service Graph dialog box.
Table 38: Create Service Graph Dialog Box Fields (for multinode)
Properties
Description
General
Name
Enter the name of service graph template.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
197
Deploying Layer 4 to Layer 7 Services
Creating a Service Graph Template Using the Cisco Cloud APIC GUI
Properties
Description
Tenant
To choose a tenant:
a. Click Select Tenant. The Select Tenant dialog appears.
b. From the column on the left, click to choose a tenant.
c. Click Select. You return to the Create Service Graph dialog box.
Description
Enter a description of the service graph template.
Settings: Based on the required topology, drag and drop the devices in the box below
Application Load
Balancer
a. Drag and drop the Application load balancer device into the box below.
b. In the Service node dialog box, click on the Select Application Load Balancer and click
to choose a Application Load Balancer in the left column then click Add.
Third Party Firewall a. Drag and drop the Third Party Firewall next to the device in the box below.
b. In the Service node dialog box, click on the Third Party Firewall and click to choose a
Third Party Firewall in the left column then click Add.
Note
Third Party Firewall cannot be the first node on the service graph.
c. If you want to enable the user-based redirect function on the consumer side of the Third
Party Firewall, in the Consumer Connector Type field, place a check in the box next to
the Redirect option.
d. If you want to enable the user-based redirect function on the provider side of the Third Party
Firewall, in the Provider Connector Type field, place a check in the box next to the
Redirect option.
e. In the Provider Connector Type, place a check next to the applicable option. Refer to
About Layer 4 to Layer 7 Service Redirect for information.
f.
Network Load
Balancer
Click Add.
a. Drag and drop the Network load balancer device into the box below.
b. In the Service node dialog box, click on the Select Network Load Balancer and click to
choose a Network Load Balancer in the left column then click Add.
c. If you want to enable the user-based redirect function on the consumer side of the network
load balancer, in the Consumer Connector Type field, place a check in the box next to
the Redirect option.
d. If you want to enable the user-based redirect function on the provider side of the network
load balancer, in the Provider Connector Type field, place a check in the box next to the
Redirect option.
e. Click Add.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
198
Deploying Layer 4 to Layer 7 Services
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI
Properties
Description
Third Party Load
Balancer
a. Drag and drop the third party load balancer device into the box below.
b. In the Service node dialog box, click Select Third Party Load Balancer and click to
choose a third party load balancer in the left column.
c. Click Select Consumer Interface. Select the interface marked as external.
d. Click Select Provider Interface. Select the interface marked as internal.
e. Click Add.
Step 5
Click Save when finished.
Step 6
The EPG Communication dialog box appears. Click on the Go to details to verify the Service Graph template.
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI
This section explains how to deploy Layer 4 to Layer 7 services. This procdure is applicable for single node
as well multinode deployments.
Before you begin
• You have configured the devices.
• You have configured a service graph.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Configuration.
A list of Configuration options appear in the Intent menu.
Step 3
From the Configuration list in the Intent menu, click EPG Communication. The EPG Communication dialog box
appears with the Consumer EPGs, Contract, and Provider EPGs information.
Step 4
To choose a contract:
a) Click Select Contract. The Select Contract dialog appears.
b) In the pane on the left side of the Select Contract dialog, click to choose a contract then click Select. The Select
Contract dialog box closes.
Step 5
To add a consumer EPG:
a) Click Add Consumer EPGs. The Select Consumer EPGs dialog appears.
b) In the pane on the left side of the Select Consumer EPGs dialog, click the check box to choose a cloud EPG (for
an internal facing load balancer) or a cloud external EPG (for an internet facing load balancer) then click Select.
The Select Consumer EPGs dialog box closes.
Step 6
To add a provider EPG:
a) Click Add Provider EPGs. The Select Provider EPGs dialog appears.
b) In the pane on the left side of the Select Provider EPGs dialog, click the check box to choose a provider EPG then
click Select. The Select Provider EPGs dialog box closes.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
199
Deploying Layer 4 to Layer 7 Services
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI
Step 7
To choose a service graph:
a) From the EPG Communication Configuration dialog, click Select Service Graph. The Select Service Graph
dialog box appears.
b) In the pane on the left side of the Select Service Graph dialog, click to choose a service graph then click Select.
The Select Service Graph dialog box closes.
Step 8
Under Service Graph Preview, click Add Cloud Load Balancer Listener. The Add Cloud Load Balancer Listener
dialog appears that enables you to add listeners.
Listeners are the ports and protocols that the device will work on.
Step 9
Enter the appropriate values in each field as listed in the following Add Cloud Load Balancer Listener Dialog Box
Fields table then continue.
Table 39: Add Cloud Load Balancer Listener Dialog Box Fields For Application Gateway
Properties
Description
Name
Enter the name of the listener.
Port
Enter the port that the device will accept traffic on.
Protocol
For Application Gateway, click to choose HTTP or HTTPS.
Security Policy
Click the drop-down list and choose a security policy (only available when HTTPS is chosen).
SSL Certificate
To choose an SSL certificate(only available when HTTPS is chosen):
a. Click Add SSL Certificates.
b. Click to place a check mark in the check box of the certificates you want to add.
c. Choose a key ring:
1. Click Select Key Ring. The Select Key Ring dialog appears.
2. From the Select Key Ring dialog, click to choose a key ring in the left column then
click Select. The Select Key Ring dialog box closes.
d. Click the Certificate Store drop-down list and choose a certificate.
Note
Add Rule
A listener can have multiple certificates.
To add rule settings to the device listener, click Add Rule. A new row appears in the Rules
list an the Rules Settings fields are enabled.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
200
Deploying Layer 4 to Layer 7 Services
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI
Properties
Description
Rule Settings
The Rule Settings pane contains the following options:
• Name—Enter a name for the rule.
• Host—Enter a hostname to create a host-based condition. When a request is made for
this hostname, the action you specify is taken.
• Path—Enter a path to create a path-based condition. When a request is made for this
path, the action you specify is taken.
• Type—The action type tells the device which action to take. The action type options:
• Return fixed response—Returns a response using the following options:
• Fixed Response Body—Enter a response message.
• Fixed Response Code—Enter a response code.
• Fixed response Content-Type—Choose a content type.
• Forward—Forwards traffic using the following options:
• Port—Enter the port that the device will accept traffic on.
• Protocol—Click to choose HTTP or HTTPS.
• Provider EPG—The EPG with the web server that handles the traffic.
• EPG—To choose an EPG:
a. Click Select EPG. The Select EPG dialog box appears.
b. From the Select EPG dialog ox, click to choose an EPG in the left column
then click Select. The Select EPG dialog box closes.
• Redirect—Redirects requests to another location using the following options:
• Redirect Code—Click the Redirect Code drop-down list and choose a code.
• Redirect Hostname—Enter a hostname for the redirect.
• Redirect Path—Enter a redirect path.
• Redirect Port—Enter the port that the device will accept traffic on.
• Redirect Protocol—Click to the Redirect Protocol drop-down list and choose
HTTP, HTTPS, or Inherit.
• Redirect Query—Enter a redirect query.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
201
Deploying Layer 4 to Layer 7 Services
Deploying Layer 4 to Layer 7 Services Using the Cisco Cloud APIC GUI
Properties
Description
Health Checks
The Application load balancer performs health checks on its backend pool targets for high
availability.This can be configured under health checks:
• Protocol-Click to choose HTTP or HTTPS.
• Path - Enter the path. Default is /
• Port-Enter a port on which health checks should be performed.
• Advanced SettingsUnhealthy Threshold-Configure this threshold to determine when a backend target is
advertised as unhealthy.
• Timeout - Enter the value for health check timeout.
• Interval-Enter a time in seconds to determine at what intervals checks should be
performed.
• Success Code - Enter the success code. Default is 200-399.
• Use host from rule - Click on the checkbox if the hostname needs to be picked from the
rule.
• Host - If Use host from rule is not checked, provide the hostname to be used for health
check.
Click Add Rule when finished.
Table 40: Add Cloud Load Balancer Listener Dialog Box Fields for Network Load Balancer
Properties
Description
Name
Enter the name of the listener.
Port
Enter the port that the device will accept traffic on.
Protocol
Click to choose TCP or UDP.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
202
Deploying Layer 4 to Layer 7 Services
Deploying a Service Graph Using the REST API
Properties
Description
Rule Settings
The Rule Settings pane contains the following options:
• Name—Enter a name for the rule.
• Port—Enter the port on which the backend pool servers will accept traffic from the load
balancer.
• Protocol-Click to choose TCP or UDP.
• Provider EPG-The EPG with the web servers handling traffic.
• Type
• Forward-The action type tells the device which action to take. The action type here is
always Forward. Here the traffic is forwarded to the Port for EPG selected using the
protocol chosen above.
• HA Port- If you want to load balance traffic incoming on all the ports, instead of adding
those many listeners a listener rule type ‘HA Ports’ can be configured for the same. This
is a feature of ONLY the internal-facing load balancer.
Health Checks
The load balancer performs health checks on its backend pool targets for high availability.
This can be configured here. ·
• Protocol-Click to choose TCP, HTTP or HTTPS.
• Port-Enter a port on which health checks should be performed.
• Advanced SettingsUnhealthy Threshold-Configure this threshold to determine when a backend target is
advertised as unhealthy.
• Interval-Enter a time in seconds to determine at what intervals checks should be
performed.
Click Add Rule when finished.
Step 10
Click Add when finished.
The service graph is deployed.
Deploying a Service Graph Using the REST API
The following sections describe how to deploy a service graph using the REST API.
Creating an Internal-Facing Load Balancer Using the REST API
This example demonstrates how to create an internal-facing load balancer using the REST API.
Step 1
To create an internal-facing load balancer for Application Gateway (Application Load Balancer):
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
203
Deploying Layer 4 to Layer 7 Services
Configuring an Internet-Facing Load Balancer Using the REST API
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<cloudLB scheme="internal" type="application" name="alb-151-15" status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn15/ctxprofile-cProfilewestus151/cidr-[15.151.0.0/16]/subnet-[15.151.2.0/24]"/>
</cloudLB>
</fvTenant>
</polUni>
Step 2
To create an internal-facing load balancer for Azure Load Balancing (Network Load Balancer):
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[subscription id]-vendor-azure" />
<cloudLB scheme="internal" type="network" name="nlb-151-15" status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn15/ctxprofile-cProfilewestus151/cidr-[15.151.0.0/16]/subnet-[15.151.2.0/24]" />
</cloudLB>
</fvTenant>
</polUni>
Step 3
To create an internal-facing load balancer for Azure Load Balancing (Network Load Balancer) using the Allow All
Traffic option described in About Allow All Traffic Option, on page 146:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[subscription id]-vendor-azure" />
<cloudLB scheme="internal" type="network" name="nlb-151-15" allowAll="true" status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn15/ctxprofile-cProfilewestus151/cidr-[15.151.0.0/16]/subnet-[15.151.2.0/24]" />
</cloudLB>
</fvTenant>
</polUni>
Configuring an Internet-Facing Load Balancer Using the REST API
This example demonstrates how to create an internet-facing load balancer using the REST API.
Step 1
To create an internet-facing load balancer for Application Gateway:
Example:
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
204
Deploying Layer 4 to Layer 7 Services
Creating a Third-Party Firewall Using the REST API
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<cloudLB scheme="internet" type="application" name="alb-151-15" status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn15/ctxprofile-cProfilewestus151/cidr-[15.151.0.0/16]/subnet-[15.151.2.0/24]"/>
</cloudLB>
</fvTenant>
</polUni>
Step 2
To create an internet-facing load balancer for Azure Load Balancing:
Example:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<fvRsCloudAccount tDn="uni/tn-infra/act-[<subscription id>]-vendor-azure" />
<cloudLB scheme="internet" type="network" name="nlb-151-15" status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn15/ctxprofile-cProfilewestus151/cidr-[15.151.0.0/16]/subnet-[15.151.2.0/24]" />
</cloudLB>
</fvTenant>
</polUni>
Creating a Third-Party Firewall Using the REST API
This example demonstrates how to create a third-party firewall using the REST API.
Step 1
To create a third-party firewall:
Example:
<cloudLDev name="HubFW" svcType="FW" status="">
<cloudRsLDevToCtx tDn="uni/tn-infra/ctx-overlay-2"/>
<cloudLIf name="provider">
<cloudEPSelector name="east" matchExpression="IP=='{{eastus_FwUntrustSubnet}}'" status=""/>
</cloudLIf>
<cloudLIf name="consumer">
<cloudEPSelector name="east" matchExpression="IP=='{{eastus_FwTrustSubnet}}'" status=""/>
</cloudLIf>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
205
Deploying Layer 4 to Layer 7 Services
Creating a Third Party Load Balancer Using the REST API
</cloudLDev>
Step 2
To create a third-party firewall using the Allow All Traffic option described in About Allow All Traffic Option, on page
146:
Example:
<cloudLDev name="HubFW" svcType="FW" status="">
<cloudRsLDevToCtx tDn="uni/tn-infra/ctx-overlay-2"/>
<cloudLIf name="provider" allowAll="true" status="">
<cloudEPSelector name="1" matchExpression="IP=='10.1.1.0/28'" status=""/>
</cloudLIf>
<cloudLIf name="consumer" allowAll="true" status="">
<cloudEPSelector name="east" matchExpression="IP=='10.1.2.0/28'" status=""/>
</cloudLIf>
</cloudLDev>
Creating a Third Party Load Balancer Using the REST API
This example demonstrates how to create a third party load balancer using the REST API.
This example demonstrates how to create a third party load balancer using the REST API:
Example:
<cloudLDev name="ThirdPartyLB" svcType="ADC" status="">
<cloudRsLDevToCtx tDn="uni/tn-infra/ctx-overlay-2"/>
<cloudLIf name="external">
<cloudEPSelector name="ExtInterfaceSelector" matchExpression="IP=='{{ExtInterfaceSubnet}}'"
status=""/>
</cloudLIf>
<cloudLIf name="internal">
<cloudEPSelector name="IntInterfaceSelector" matchExpression="IP=='{{IntInterfaceSubnet}}'"
status=""/>
</cloudLIf>
</cloudLDev>
Creating a Service Graph Using the REST API for an Application Gateway
This example demonstrates how to create a service graph using the REST API.
To create a service graph for an application gateway:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<vnsAbsGraph name="c15_g1" type="cloud" status="">
<vnsAbsTermNodeProv name="p1">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
206
Deploying Layer 4 to Layer 7 Services
Creating a Service Graph Using the REST API for Azure Load Balancer
<vnsAbsTermConn/>
</vnsAbsTermNodeProv>
<vnsAbsTermNodeCon name="c1">
<vnsAbsTermConn/>
</vnsAbsTermNodeCon>
<vnsAbsNode managed="yes" name="N1" funcType="GoTo">
<vnsRsNodeToCloudLDev tDn="uni/tn-tn15/clb-alb-151-15"/>
<vnsAbsFuncConn name="provider"/>
<vnsAbsFuncConn name="consumer"/>
</vnsAbsNode>
<vnsAbsConnection connDir="consumer" connType="external" name="con1">
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsTermNodeCon-c1/AbsTConn"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsNode-N1/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection connDir="provider" connType="internal" name="con2">
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsTermNodeProv-p1/AbsTConn"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsNode-N1/AbsFConn-provider"/>
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>
Creating a Service Graph Using the REST API for Azure Load Balancer
To create a service graph for an Azure load balancer:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<vnsAbsGraph name="c15_g1" type="cloud" status="">
<vnsAbsTermNodeProv name="p1">
<vnsAbsTermConn />
</vnsAbsTermNodeProv>
<vnsAbsTermNodeCon name="c1">
<vnsAbsTermConn />
</vnsAbsTermNodeCon>
<vnsAbsNode managed="yes" name="N1" funcType="GoTo">
<vnsRsNodeToCloudLDev tDn="uni/tn-tn15/clb-nlb-151-15" />
<vnsAbsFuncConn name="provider" />
<vnsAbsFuncConn name="consumer" />
</vnsAbsNode>
<vnsAbsConnection connDir="consumer" connType="external" name="con1">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
207
Deploying Layer 4 to Layer 7 Services
Creating a Service Graph Using the REST API for a Third Party Load Balancer
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsTermNodeCon-c1/AbsTConn" />
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsNode-N1/AbsFConn-consumer" />
</vnsAbsConnection>
<vnsAbsConnection connDir="provider" connType="internal" name="con2">
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsTermNodeProv-p1/AbsTConn" />
<vnsRsAbsConnectionConns tDn="uni/tn-tn15/AbsGraph-c15_g1/AbsNode-N1/AbsFConn-provider" />
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>
Creating a Service Graph Using the REST API for a Third Party Load Balancer
To create a service graph for a third party load balancer:
<polUni>
<fvTenant name="infra" >
<!-- Abs Graph Creation -->
<vnsAbsGraph name="{{graphName}}" uiTemplateType="UNSPECIFIED" type="cloud" status="">
<vnsAbsTermNodeProv name="T2">
<vnsOutTerm/>
<vnsInTerm />
<vnsAbsTermConn attNotify="no" name="1" />
</vnsAbsTermNodeProv>
<vnsAbsTermNodeCon name="T1" >
<vnsOutTerm/>
<vnsInTerm />
<vnsAbsTermConn attNotify="no" name="1" />
</vnsAbsTermNodeCon>
<vnsAbsNode funcTemplateType="ADC_TWO_ARM" name="{{F5Name}}" managed="no">
<vnsRsNodeToCloudLDev tDn="uni/tn-infra/cld-{{F5Name}}" />
<vnsAbsFuncConn attNotify="no" name="consumer" deviceLIfName="external"/>
<vnsAbsFuncConn attNotify="no" name="provider" deviceLIfName="internal"/>
</vnsAbsNode>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="ConsTermToF5">
<vnsRsAbsConnectionConns
tDn="uni/tn-infra/AbsGraph-{{graphName}}/AbsTermNodeCon-T1/AbsTConn"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-infra/AbsGraph-{{graphName}}/AbsNode-{{F5Name}}/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="F5ToProv">
<vnsRsAbsConnectionConns
tDn="uni/tn-infra/AbsGraph-{{graphName}}/AbsNode-{{F5Name}}/AbsFConn-provider" />
<vnsRsAbsConnectionConns
tDn="uni/tn-infra/AbsGraph-{{graphName}}/AbsTermNodeProv-T2/AbsTConn"/>
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
208
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph Using the REST API
Creating a Multi-Node Service Graph Using the REST API
This example demonstrates how to create a multi-node service graph using the REST API.
To create a multi-node service graph, enter a post such as the following example;
<polUni>
<fvTenant name="tn12_iar_iavpc" status="">
<fvRsCloudAccount tDn="uni/tn-infra/[SubscriptionId]-vendor-azure"/>
<fvCtx name="vrf50" status=""/>
<fvCtx name="vrf60" status=""/>
<cloudVpnGwPol name="VgwPol0"/>
<cloudCtxProfile name="c50" status="">
<cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-azure/region-westus"/>
<cloudRsToCtx tnFvCtxName="vrf50"/>
<cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
<cloudCidr addr="12.3.0.0/16" primary="true" status="">
<cloudSubnet ip="12.3.30.0/24" status="" name="GatewaySubnet" usage="gateway">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.3.2.0/24" status="" name="ALBSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.3.1.0/24" status="" name="FwMgmtSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.3.3.0/24" status="" name="FwUntrustSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.3.4.0/24" status="" name="FwTrustSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.3.5.0/24" status="" name="ConsumerSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
<cloudCtxProfile name="c60" status="">
<cloudRsCtxProfileToRegion tDn="uni/clouddomp/provp-azure/region-westus2"/>
<cloudRsToCtx tnFvCtxName="vrf60"/>
<cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
<cloudCidr addr="12.4.0.0/16" primary="true" status="">
<cloudSubnet ip="12.4.1.0/24" status="" name="ProviderSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus2/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.4.2.0/24" status="" name="NLBSubnet">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus2/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="12.4.30.0/24" status="" name="GatewaySubnet" usage="gateway">
<cloudRsZoneAttach tDn="uni/clouddomp/provp-azure/region-westus2/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
<cloudApp name="ap50" status="">
<cloudEPg name="ap50vrf50epg1" status="">
<cloudRsCloudEPgCtx tnFvCtxName="vrf50"/>
<fvRsCons tnVzBrCPName="con50"/>
<fvRsProv tnVzBrCPName="con60"/>
<cloudEPSelector matchExpression="IP=='12.3.5.0/24'" name="100"/>
</cloudEPg>
<cloudEPg name="ap50vrf50epg2" status="">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
209
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph Using the REST API
<cloudRsCloudEPgCtx tnFvCtxName="vrf50"/>
<fvRsProv tnVzBrCPName="con60"/>
<cloudEPSelector matchExpression="IP=='12.3.1.0/24'" name="100"/>
</cloudEPg>
<cloudExtEPg routeReachability="internet" name="ap50extepg1">
<cloudExtEPSelector name="1" subnet="0.0.0.0/0"/>
<cloudRsCloudEPgCtx tnFvCtxName="vrf50"/>
<fvRsCons tnVzBrCPName="con60"/>
</cloudExtEPg>
</cloudApp>
<cloudApp name="ap60" status="">
<cloudEPg name="ap60vrf60epg1" status="">
<cloudRsCloudEPgCtx tnFvCtxName="vrf60"/>
<fvRsProv tnVzBrCPName="con50"/>
<fvRsProv tnVzBrCPName="con70"/>
<cloudEPSelector matchExpression="IP=='12.4.1.0/24'" name="100"/>
</cloudEPg>
<cloudExtEPg routeReachability="internet" name="ap60extepg1">
<cloudExtEPSelector name="1" subnet="0.0.0.0/0"/>
<cloudRsCloudEPgCtx tnFvCtxName="vrf60"/>
<fvRsCons tnVzBrCPName="con70"/>
</cloudExtEPg>
</cloudApp>
<vzBrCP name="con50" scope="tenant" status="">
<vzSubj name="con50">
<vzRsSubjFiltAtt tnVzFilterName="f10"/>
<vzRsSubjGraphAtt tnVnsAbsGraphName="g1" status=""/>
</vzSubj>
</vzBrCP>
<vzBrCP name="con60" scope="tenant" status="">
<vzSubj name="con60">
<vzRsSubjFiltAtt tnVzFilterName="f20"/>
</vzSubj>
</vzBrCP>
<vzBrCP name="con70" scope="context" status="">
<vzSubj name="con70">
<vzRsSubjFiltAtt tnVzFilterName="f20"/>
</vzSubj>
</vzBrCP>
<vzFilter name="f10" status="">
<vzEntry etherT="ip" prot="icmp" name="f10entry1" status=""/>
<vzEntry etherT="ip" prot="udp" dFromPort="1" dToPort="65535" name="f10entry2" status=""/>
<vzEntry etherT="ip" prot="tcp" dFromPort="1" dToPort="65535" name="f10entry3" status=""/>
</vzFilter>
<vzFilter name="f20" status="">
<vzEntry etherT="ip" prot="tcp" dFromPort="http" dToPort="http" name="f20entry1" status=""/>
<vzEntry etherT="ip" prot="tcp" dFromPort="https" dToPort="https" name="f20entry2" status=""/>
<vzEntry etherT="ip" prot="tcp" dFromPort="22" dToPort="22" name="f20entry3" status=""/>
</vzFilter>
<cloudLB name="FrontALB" type="application" scheme="internal" >
<cloudRsLDevToCloudSubnet
tDn="uni/tn-tn12_iar_iavpc/ctxprofile-c50/cidr-[12.3.0.0/16]/subnet-[12.3.2.0/24]"/>
</cloudLB>
<cloudLDev name="FW" svcType="FW" status="">
<cloudRsLDevToCtx tDn="uni/tn-tn12_iar_iavpc/ctx-vrf50" />
<cloudLIf name="provider" >
<cloudEPSelector name="1" matchExpression="custom:tagp=='trustFW'"/>
</cloudLIf>
<cloudLIf name="consumer" >
<cloudEPSelector name="1" matchExpression="custom:tagp=='untrustFW'"/>
</cloudLIf>
</cloudLDev>
<cloudLB name="BackNLB" type="network" scheme="internal" >
<cloudRsLDevToCloudSubnet
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
210
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph Using the REST API
tDn="uni/tn-tn12_iar_iavpc/ctxprofile-c60/cidr-[12.4.0.0/16]/subnet-[12.4.2.0/24]"/>
</cloudLB>
<vnsAbsGraph name="g1" type="cloud" status="" >
<vnsAbsTermNodeProv name="Input1" >
<vnsAbsTermConn name="C1"/>
</vnsAbsTermNodeProv>
<vnsAbsTermNodeCon descr="" name="Output1" nameAlias="" ownerKey="" ownerTag="">
<vnsAbsTermConn name="C2" />
</vnsAbsTermNodeCon>
<vnsAbsNode funcType="GoTo" name="N1" managed="yes" funcTemplateType="ADC_ONE_ARM" >
<vnsRsNodeToCloudLDev tDn="uni/tn-tn12_iar_iavpc/clb-FrontALB" />
<vnsAbsFuncConn attNotify="no" descr="" name="provider" nameAlias="" ownerKey="" ownerTag=""/>
<vnsAbsFuncConn attNotify="no" descr="" name="consumer" nameAlias="" ownerKey="" ownerTag=""/>
<cloudSvcPolicy tenantName="tn12_iar_iavpc" contractName="con50" subjectName="con50" >
<cloudListener name="http_listener1" port="80" protocol="http">
<cloudListenerRule name="rule1" priority="20" default="yes" >
<cloudRuleAction type="forward" port="80" protocol="http"/>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
</vnsAbsNode>
<vnsAbsNode funcType="GoTo" name="N2" managed="no" funcTemplateType="ADC_TWO_ARM" >
<vnsRsNodeToCloudLDev tDn="uni/tn-tn12_iar_iavpc/cld-FW" />
<vnsAbsFuncConn attNotify="no" descr="" connType="snat_dnat" name="provider" nameAlias=""
ownerKey="" ownerTag=""/>
<vnsAbsFuncConn attNotify="no" descr="" connType="none" name="consumer" nameAlias="" ownerKey=""
ownerTag=""/>
</vnsAbsNode>
<vnsAbsNode funcType="GoTo" name="N3" managed="yes" funcTemplateType="ADC_ONE_ARM" >
<vnsRsNodeToCloudLDev tDn="uni/tn-tn12_iar_iavpc/clb-BackNLB" />
<vnsAbsFuncConn attNotify="no" descr="" name="provider" nameAlias="" ownerKey="" ownerTag=""/>
<vnsAbsFuncConn attNotify="no" descr="" name="consumer" nameAlias="" ownerKey="" ownerTag=""/>
<cloudSvcPolicy tenantName="tn12_iar_iavpc" contractName="con50" subjectName="con50" >
<cloudListener name="http_listener1" port="80" protocol="tcp">
<cloudListenerRule name="rule1" priority="20" default="yes" >
<cloudRuleAction type="forward" port="80" protocol="tcp"
epgdn="uni/tn-tn12_iar_iavpc/cloudapp-ap60/cloudepg-ap60vrf60epg1"/>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
</vnsAbsNode>
<vnsAbsConnection connDir="provider" connType="external" name="CON4">
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N3/AbsFConn-provider"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsTermNodeProv-Input1/AbsTConn"/>
</vnsAbsConnection>
<vnsAbsConnection connDir="consumer" connType="external" name="CON1">
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsTermNodeCon-Output1/AbsTConn"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N1/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection connDir="consumer" connType="external" name="CON2">
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N1/AbsFConn-provider"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N2/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection connDir="consumer" connType="external" name="CON3">
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N2/AbsFConn-provider"/>
<vnsRsAbsConnectionConns tDn="uni/tn-tn12_iar_iavpc/AbsGraph-g1/AbsNode-N3/AbsFConn-consumer"/>
</vnsAbsConnection>
</vnsAbsGraph>
</fvTenant>
</polUni>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
211
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph With Redirect Using the REST API
Creating a Multi-Node Service Graph With Redirect Using the REST API
This example demonstrates how to create a multi-node service graph with redirect using the REST API.
Step 1
To set up the infra tenant:
<polUni>
<fabricInst>
<commPol name="default">
<commSsh name="ssh" adminSt="enabled" passwordAuth="enabled" />
</commPol>
<dnsProfile name="default">
<dnsProv addr="172.23.136.143" preferred="yes" status=""/>
</dnsProfile>
</fabricInst>
<fvTenant name="infra">
<fvRsCloudAccount tDn="uni/tn-infra/act-[{{subscriptionId}}]-vendor-azure"/>
<cloudAccount name="insbu" id="{{subscriptionId}}" vendor="azure" accessType="credentials"
status="">
<cloudRsCredentials tDn="uni/tn-infra/credentials-cApicApp"/>
</cloudAccount>
<cloudCredentials name="cApicApp" keyId="{{accessKeyId}}" key="{{accessKey}}" httpProxy="">
<cloudRsAD tDn="uni/tn-infra/ad-{{adId}}"/>
</cloudCredentials>
<cloudAD name="CiscoINSBUAd" id="{{adId}}" />
<cloudApicSubnetPool subnet="10.10.1.0/24" />
<cloudtemplateInfraNetwork name="default" numRoutersPerRegion="2" vrfName="overlay-1"
numRemoteSiteSubnetPool="1" status="">
<cloudtemplateProfile name="default" routerUsername="cisco" routerPassword="ins3965" />
<cloudtemplateExtSubnetPool subnetpool="11.11.0.0/16" status=""/>
<cloudtemplateExtNetwork name="default" status="">
<cloudRegionName provider="azure" region="{{region}}" />
<cloudtemplateVpnNetwork name="default">
<cloudtemplateIpSecTunnel peeraddr="{{peerAddress}}"/>
<cloudtemplateOspf area="0.0.0.1" />
</cloudtemplateVpnNetwork>
</cloudtemplateExtNetwork>
<cloudtemplateIntNetwork name="default">
<cloudRegionName provider="azure" region="{{region}}"/>
</cloudtemplateIntNetwork>
</cloudtemplateInfraNetwork>
</fvTenant>
<cloudDomP>
<cloudBgpAsP asn="1111"/>
<cloudProvP vendor="azure">
<cloudRegion adminSt="managed" name="{{region}}">
<cloudZone name="default"/>
</cloudRegion>
</cloudProvP>
</cloudDomP>
</polUni>
Step 2
To configure the service device in the hub VNet:
<polUni>
<fvTenant name="infra">
<fvRsCloudAccount tDn="uni/tn-infra/act-[{{subscriptionId}}]-vendor-azure"/>
<cloudCtxProfile name="ct_ctxprofile_{{region}}" status="modified">
<cloudRsCtxProfileToRegion status="" tDn="uni/clouddomp/provp-azure/region-{{region}}"/>
<cloudCidr name="cidr1" addr="{{HubCidrSvc}}" primary="no" status="">
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
212
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph With Redirect Using the REST API
<cloudSubnet ip="{{HubNLBSubnet}}" name="HubNLBSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="{{HubFWSubnetInt}}" name="HubFWSubnetInt" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="{{HubFWSubnetExt}}" name="HubFWSubnetExt" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="{{HubFWMgmtSubnet}}" name="HubFWMgmtSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="{{ConsHubEPgSubnet}}" name="ConsHubEPgSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
<cloudLDev name="{{FWName}}" status="">
<cloudRsLDevToCtx tDn="uni/tn-infra/ctx-{{ServicevVNetName}}"/>
<cloudLIf name="external" >
<cloudEPSelector matchExpression="custom:EPG=='FwExt'" name="1"/>
</cloudLIf>
<cloudLIf name="internal" >
<cloudEPSelector matchExpression="custom:EPG=='FwInt'" name="1"/>
</cloudLIf>
</cloudLDev>
<cloudLB name="{{NLBName}}" type="network" scheme="internal" size="small" instanceCount="2"
status="">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-infra/ctxprofile-ct_ctxprofile_{{region}}/cidr-[{{HubCidrSvc}}]/subnet-[{{HubNLBSubnet}}]"
status=""/>
</cloudLB>
</fvTenant>
</polUni>
Step 3
To configure a provider and the graph in a spoke:
<polUni>
<fvTenant name="{{tnNameProv}}" status="" >
<fvRsCloudAccount tDn="uni/tn-infra/act-[{{subscriptionId}}]-vendor-azure"/>
<fvCtx name="{{ProviderVNetName}}"/>
<cloudCtxProfile name="{{ProviderVNetName}}" status="">
<cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
<cloudRsCtxProfileToRegion status="" tDn="uni/clouddomp/provp-azure/region-{{region}}"/>
<cloudRsToCtx tnFvCtxName="{{ProviderVNetName}}"/>
<cloudCidr name="cidr1" addr="{{VnetCidrProv}}" primary="yes" status="">
<cloudSubnet ip="{{ProviderSubnet}}" name="ProviderSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
<cloudSubnet ip="{{BackALBSubnet}}" name="BackALBSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
<!-- contract-->
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
213
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph With Redirect Using the REST API
<vzFilter descr="" name="HttpsFilter" ownerKey="" ownerTag="">
<vzEntry dFromPort="443" dToPort="443" etherT="ip" name="https" prot="tcp" status=""/>
<vzEntry dFromPort="80" dToPort="80" etherT="ip" name="http" prot="tcp" status=""/>
<vzEntry dFromPort="22" dToPort="22" etherT="ip" name="ssh" prot="tcp" status=""/>
</vzFilter>
<vzBrCP name="{{contractName}}" scope="global" status="">
<vzSubj name="Sub1" revFltPorts="yes">
<vzRsSubjGraphAtt directives="" tnVnsAbsGraphName="{{graphName}}"/>
<vzRsSubjFiltAtt tnVzFilterName="HttpsFilter"/>
</vzSubj>
</vzBrCP>
<!-- cloud App Profile-->
<cloudApp name="provApp" status="">
<cloudEPg name="App" status="">
<cloudRsCloudEPgCtx tnFvCtxName="{{ProviderVNetName}}"/>
<cloudEPSelector matchExpression="custom:EPG=='App'" name="1"/>
<fvRsProv status="" tnVzBrCPName="{{contractName}}"/>
<fvRsProv tnVzBrCPName="mgmt_common"/>
</cloudEPg>
</cloudApp>
<!-- Abs Graph Creation -->
<vnsAbsGraph name="{{graphName}}" uiTemplateType="UNSPECIFIED" type="cloud">
<vnsAbsTermNodeProv name="T2">
<vnsOutTerm/>
<vnsInTerm />
<vnsAbsTermConn attNotify="no" name="1" />
</vnsAbsTermNodeProv>
<vnsAbsTermNodeCon name="T1" >
<vnsOutTerm/>
<vnsInTerm />
<vnsAbsTermConn attNotify="no" name="1" />
</vnsAbsTermNodeCon>
<vnsAbsNode name="{{NLBName}}" managed="yes" >
<vnsRsNodeToCloudLDev tDn="uni/tn-infra/clb-{{NLBName}}" status=""/>
<cloudSvcPolicy tenantName="{{tnNameProv}}" contractName="{{contractName}}"
subjectName="Sub1" status="">
<cloudHealthProbe name="http_listener1-rule1" protocol="tcp" port=22 interval=15
unhealthyThreshold=2/>
<cloudListener name="http_listener1" port="80" protocol="tcp" status="">
<cloudListenerRule name="rule1" default="true">
<cloudRuleAction type="haPort" port="80" protocol="tcp"
healthProbe="http_listener1-rule1"/>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
<vnsAbsFuncConn attNotify="no" name="provider" connType="redir"/>
<vnsAbsFuncConn attNotify="no" name="consumer" connType="redir"/>
</vnsAbsNode>
<vnsAbsNode funcTemplateType="FW_ROUTED" name="{{FWName}}" managed="no">
<vnsRsNodeToCloudLDev tDn="uni/tn-infra/cld-{{FWName}}" />
<vnsAbsFuncConn attNotify="no" name="consumer" deviceLIfName="internal"/>
<vnsAbsFuncConn attNotify="no" name="provider" deviceLIfName="internal"/>
</vnsAbsNode>
<vnsAbsNode name="{{BackALBName}}" managed="yes">
<vnsRsNodeToCloudLDev tDn="uni/tn-{{tnNameProv}}/clb-{{BackALBName}}"/>
<cloudSvcPolicy tenantName="{{tnNameProv}}" contractName="{{contractName}}"
subjectName="Sub1" status="">
<cloudListener name="http_listener1" port="80" protocol="http" status="">
<cloudListenerRule name="rule1" default="true">
<cloudRuleAction type="forward" port="80" protocol="http"
epgdn="uni/tn-{{tnNameProv}}/cloudapp-provApp/cloudepg-App"/>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
214
Deploying Layer 4 to Layer 7 Services
Creating a Multi-Node Service Graph With Redirect Using the REST API
<vnsAbsFuncConn attNotify="no" name="provider"/>
<vnsAbsFuncConn attNotify="no" name="consumer"/>
</vnsAbsNode>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="ConsTermToNLB">
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsTermNodeCon-T1/AbsTConn"/>
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{NLBName}}/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="NLBToFW">
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{NLBName}}/AbsFConn-provider" />
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{FWName}}/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="FWToBackALB">
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{FWName}}/AbsFConn-provider" />
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{BackALBName}}/AbsFConn-consumer"/>
</vnsAbsConnection>
<vnsAbsConnection adjType="L3" connDir="provider" connType="external" directConnect="no"
name="BackALBToProv">
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsNode-{{BackALBName}}/AbsFConn-provider" />
<vnsRsAbsConnectionConns
tDn="uni/tn-{{tnNameProv}}/AbsGraph-{{graphName}}/AbsTermNodeProv-T2/AbsTConn"/>
</vnsAbsConnection>
</vnsAbsGraph>
<cloudLB name="{{BackALBName}}" type="application" scheme="internal" size="small"
instanceCount="2">
<cloudRsLDevToCloudSubnet
tDn="uni/tn-{{tnNameProv}}/ctxprofile-{{ProviderVNetName}}/cidr-[{{VnetCidrProv}}]/subnet-[{{BackALBSubnet}}]"
status=""/>
</cloudLB>
</fvTenant>
</polUni>
Step 4
To configure the consumer and import the contract defined in the provider:
<polUni>
<fvTenant name="{{tnNameCons}}" >
<fvRsCloudAccount tDn="uni/tn-infra/act-[{{subscriptionId}}]-vendor-azure"/>
<fvCtx name="{{ConsumerVNetName}}"/>
<cloudCtxProfile name="{{ConsumerVNetName}}" status="">
<cloudRsCtxProfileToGatewayRouterP tDn="uni/tn-infra/gwrouterp-default" status=""/>
<cloudRsCtxProfileToRegion status="" tDn="uni/clouddomp/provp-azure/region-{{region}}"/>
<cloudRsToCtx tnFvCtxName="{{ConsumerVNetName}}"/>
<cloudCidr name="cidr1" addr="{{VnetCidrCons}}" primary="yes" status="">
<cloudSubnet ip="{{ConsumerSubnet}}" name="ConsumerSubnet" status="">
<cloudRsZoneAttach status=""
tDn="uni/clouddomp/provp-azure/region-{{region}}/zone-default"/>
</cloudSubnet>
</cloudCidr>
</cloudCtxProfile>
<vzCPIf name="imported_{{contractName}}">
<vzRsIf tDn="uni/tn-{{tnNameProv}}/brc-{{contractName}}" />
</vzCPIf>
<!-- cloud App Profile-->
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
215
Deploying Layer 4 to Layer 7 Services
Attaching a Service Graph Using the REST API
<cloudApp name="consApp" status="">
<cloudEPg name="Web" status="">
<cloudRsCloudEPgCtx tnFvCtxName="{{ConsumerVNetName}}"/>
<cloudEPSelector matchExpression="custom:EPG=='Web'" name="1"/>
<fvRsConsIf tnVzCPIfName="imported_{{contractName}}"/>
<fvRsProv tnVzBrCPName="mgmt_common"/>
</cloudEPg>
</cloudApp>
</fvTenant>
</polUni>
Attaching a Service Graph Using the REST API
This example demonstrates how to attach a service graph using the REST API.
Step 1
To attach a service graph for Application Gateways:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<vzBrCP name="c1">
<vzSubj name="c1">
<vzRsSubjGraphAtt tnVnsAbsGraphName="c15_g1"/>
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>
Step 2
To attach a service graph for Azure Load Balancing:
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/node/mo/uni/.xml -->
<polUni>
<fvTenant name="tn15">
<vzBrCP name="c1">
<vzSubj name="c1">
<vzRsSubjGraphAtt tnVnsAbsGraphName="c15_g1" />
</vzSubj>
</vzBrCP>
</fvTenant>
</polUni>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
216
Deploying Layer 4 to Layer 7 Services
Configuring an HTTP Service Policy Using the REST API
Configuring an HTTP Service Policy Using the REST API
This example demonstrates how to create an HTTP service policy using the REST API.
Step 1
To create an HTTP service policy for Application Gateways:
<polUni>
<fvTenant name="t2">
<vnsAbsGraph name="CloudGraph" type="cloud" status="">
<vnsAbsNode funcType="GoTo" name="N1" managed="yes">
<cloudSvcPolicy tenantName="t2" contractName="httpFamily" subjectName="consubj">
<cloudListener name="http_listener1" port="80" protocol="http" status="">
<cloudListenerRule name="rule1" priority="10" default="yes" status="">
<cloudRuleAction type="forward" port="80" protocol="http"
epgdn="uni/tn-t2/cloudapp-ap/cloudepg-provEPG"/>
</cloudListenerRule>
<cloudListenerRule name="redirectRule" priority="20">
<cloudRuleCondition type="path" value="/img/*"/>
<cloudRuleAction type="redirect" RedirectPort="8080"/>
</cloudListenerRule>
<cloudListenerRule name="FixedRspRule" priority="30">
<cloudRuleCondition type="host" value="example.com"/>
<cloudRuleAction type="fixedResponse" FixedResponseCode="200"/>
</cloudListenerRule>
<cloudListenerRule name="redirectHPRule" priority="40" status="">
<cloudRuleCondition type="host" value="example.com"/>
<cloudRuleCondition type="path" value="/img/*"/>
<cloudRuleAction type="forward" port="80" protocol="http"
epgdn="uni/tn-t2/cloudapp-ap/cloudepg-provEPG"/>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
</vnsAbsNode>
</vnsAbsGraph>
</fvTenant>
</polUni>
Step 2
To create an HTTP service policy for Azure Load Balancing:
<?xml version="1.0" encoding="UTF-8"?>
<polUni>
<fvTenant name="tn15">
<vnsAbsGraph name="CloudGraph" type="cloud" status="">
<vnsAbsNode funcType="GoTo" name="N1" managed="yes">
<cloudSvcPolicy tenantName=" tn15" contractName="httpFamily" subjectName="consubj">
<cloudListener name="tcp_listener" port="80" protocol="tcp" status="">
<cloudListenerRule name="rule1" priority="10" default="yes" status="">
<cloudRuleAction type="forward" port="80" protocol="tcp" epgdn="uni/tntn15/cloudapp-ap/cloudepg-provEPG" />
</cloudListenerRule>
</cloudListener>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
217
Deploying Layer 4 to Layer 7 Services
Configuring a Key Ring Using the REST API
<cloudListener name="udp_listener" port="55" protocol="udp" status="">
<cloudListenerRule name="rule1" priority="10" default="yes" status="">
<cloudRuleAction type="forward" port="55" protocol="udp" epgdn="uni/tntn15/cloudapp-ap/cloudepg-provEPG" />
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
</vnsAbsNode>
</vnsAbsGraph>
</fvTenant>
</polUni>
Configuring a Key Ring Using the REST API
This example demonstrates how to configure a key ring using the REST API. For more information about
key ring configuration, see the Cisco APIC Basic Configuration Guide.
Note
This procedure is applicable only for Application Gateways.
To configure a key ring:
<polUni>
<fvTenant name="tn15" >
<cloudCertStore>
<pkiKeyRing status="" name="lbCert" tp="lbTP" key="-----BEGIN RSA PRIVATE KEY----MIIEpQIBAAKCAQEA4DGxaK+RHv/nToHLnmDBq2BfLimgX/zNJQC9bGuzr8Mj7dm0
XuHfQYGv0h1PtL4Pdxf5qjB0NbHjAVB1Gw8cDiErEgAXy9Km27ySo2foKryNqCRe
Ginn/CgF75QPIed568eScNDZPt/eMeHAuRX/PykKUatWWncGanjvHqc+SOLPF6TD
gQ5nwOHHFvyM2DY8bfdYWrWmGsO7JqZzbPMptA2QWblILsSoIrdkIIgf6ZfYy/EN
bH+nYN2rJT8lzYsxz0YmR0oRQHTiN2NiDY/ZV63yxCXfLg9qpNZCuD8KOfdCZPEq
8takiWBxiR5/HRPscWAdWQsoiKgG1k4NEbFA9QIDAQABAoIBAQDQqA9IslYrdtqN
q6mZ3s2BNfF/4kgb7gn0DWs+9EJJLCJNZVhFEo2ZxxyfPp6HRnjYS50W83/E1anD
+GD1bSucTuxqFWIQVh7r1ebYZIWk+NYSjr5yNVxux8U2hCNNV8WWVqkJjKcUqICB
Bm47FKj53LV46zE0gyCaibFrYxZJ9+farGneyBdnoV+3thmez7534KCi0t3J3Eri
lgSY3ql6hPXB2ZXAP4jdAoLgWDU4I1M6OqOiWopZM/QYIE/WtPYyJ0QzNCXObtc5
FboDcvedsgd4x5GlfV2A4xTBQMCTZUZJ9fYAcFogTZXD+UVqxorh47tf/mz+1fjq
f1XphEDlAoGBAPVlvKfGW46qqRnYovfryxxz4OMlsVSgcJpQTQtBQi2koJ8OwEZJ
2s+CX0r+oDqwP23go/QEVYVkcic9RGkJBNge1+dm/bTjzgMQYtqSCNtecTsZD5JN
y1jkciizznDkjcjReSZ2kh3dGXIbRiYk7ezp2z7EKfDrHe5x5ouGMgCnAoGBAOnh
buDEohv8KJaB+DiUfhtoa3aKNPBO+zWPCHp0HFGjPXshJcIYZc1GcycmuDKVNnDd
MxhE/yOnQHowi4T9FMLpz5yh5zuCUVqOBgB1P6MzbC5t5MtLrEYr/AqFN11CqyXQ
cVcT6iCW1OAFJRw3c/OiESwLMzchsl8RnbwOi6kDAoGBANVlzmPb07zB3eGTCU0t
KGiqwFLncUkVaDZZRFZYPpNwiRkoe73j9brkNbgCqxW+NLp5UjoeFry0N6y106q/
ZA4I7FnXryLBw2HYuw41Vixl+XOZ/HeO3RmFN1z717dGmaGbv43aKIB9x+X5n8wF
6z1NtBHmBk7yNwom1IRag1sbAoGAX0p4cJ/tJNXSe7AswHDQCL68uimJdDfZ5nKG
k83nE+Qc0qQozDJAmCiSFmuSNRnSep3FiafjBFXK0X4h+mdbJCc7bagRnI92Mh0X
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
218
Deploying Layer 4 to Layer 7 Services
Configuring a Key Ring Using the REST API
mOwsp4P2GdywkZwdbuHQ6UBp1Ferf9aztzTn+as6xKOUATEezy9DK9zMWzQhhtaY
m9yZTp0CgYEA1UtcpWjAzQbXODJGmxGdAAakPpeiKw/Da3MccrTdGJt88ezM1Oej
Pdoab0G2PcfgJZoTSGk7N4XArVKeq7pgZ0kwcYAshO6A2Hal+D1z/bGoZP+kmD/x
Ny82phxYOXCnEc5Vv92lU59+j7e067UFLAYJe6fu+oFImvofRnP4DIQ=
-----END RSA PRIVATE KEY-----" cert="-----BEGIN CERTIFICATE----MIIElTCCA32gAwIBAgIJAKWNjp//arBsMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRIwEAYDVQQK
EwlNeUNvbXBhbnkxDjAMBgNVBAsTBU15T3JnMRgwFgYDVQQDFA8qLmFtYXpvbmF3
cy5jb20xIDAeBgkqhkiG9w0BCQEWEXJhbXNoYWhAY2lzY28uY29tMB4XDTE4MTAw
MjIwNTMwNVoXDTE5MTAwMjIwNTMwNVowgY0xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxEjAQBgNVBAoTCU15Q29tcGFueTEOMAwG
A1UECxMFTXlPcmcxGDAWBgNVBAMUDyouYW1hem9uYXdzLmNvbTEgMB4GCSqGSIb3
DQEJARYRcmFtc2hhaEBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDgMbFor5Ee/+dOgcueYMGrYF8uKaBf/M0lAL1sa7OvwyPt2bRe4d9B
ga/SHU+0vg93F/mqMHQ1seMBUHUbDxwOISsSABfL0qbbvJKjZ+gqvI2oJF4aKef8
KAXvlA8h53nrx5Jw0Nk+394x4cC5Ff8/KQpRq1ZadwZqeO8epz5I4s8XpMOBDmfA
4ccW/IzYNjxt91hataYaw7smpnNs8ym0DZBZuUguxKgit2QgiB/pl9jL8Q1sf6dg
3aslPyXNizHPRiZHShFAdOI3Y2INj9lXrfLEJd8uD2qk1kK4Pwo590Jk8Sry1qSJ
YHGJHn8dE+xxYB1ZCyiIqAbWTg0RsUD1AgMBAAGjgfUwgfIwHQYDVR0OBBYEFBYq
K3b39+1oOr4IBSsePwcOpML7MIHCBgNVHSMEgbowgbeAFBYqK3b39+1oOr4IBSse
PwcOpML7oYGTpIGQMIGNMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNV
BAcTCFNhbiBKb3NlMRIwEAYDVQQKEwlNeUNvbXBhbnkxDjAMBgNVBAsTBU15T3Jn
MRgwFgYDVQQDFA8qLmFtYXpvbmF3cy5jb20xIDAeBgkqhkiG9w0BCQEWEXJhbXNo
YWhAY2lzY28uY29tggkApY2On/9qsGwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQsFAAOCAQEAe/RuzCheLIbHbrurGet6eaVx9DPYydNiKVBSAKO+5iuR84mQzhoT
nx5CN109xu5ml5baCYZZsSnn6D7usC092bPA/kRCGxt29gkjpWA74tJHqIhVWgbM
mOrLiSHoelewv+wRl0oVRChlTfKtXO68TUk6vrqpw76hKfOHIa7b2h1IIMdq6VA/
+A5FQ0xqYfqKdVd2RaINpzI8mqZiszqw+7E6j1PL5k4tftWEaYpfGPlVesFEyJEL
gHBUiPt8TIbaMYI8qUQmB/emnLXeKQ5PRxdRnleA3h8jfq3D1CQRTLjmDL3tpFwg
qopM6et5ZKqShX4T87BsgZIoiquzXqsuHg==
-----END CERTIFICATE-----">
</pkiKeyRing>
<pkiTP status="" name="lbTP" certChain="-----BEGIN CERTIFICATE----MIIElTCCA32gAwIBAgIJAKWNjp//arBsMA0GCSqGSIb3DQEBCwUAMIGNMQswCQYD
VQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNVBAcTCFNhbiBKb3NlMRIwEAYDVQQK
EwlNeUNvbXBhbnkxDjAMBgNVBAsTBU15T3JnMRgwFgYDVQQDFA8qLmFtYXpvbmF3
cy5jb20xIDAeBgkqhkiG9w0BCQEWEXJhbXNoYWhAY2lzY28uY29tMB4XDTE4MTAw
MjIwNTMwNVoXDTE5MTAwMjIwNTMwNVowgY0xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJDQTERMA8GA1UEBxMIU2FuIEpvc2UxEjAQBgNVBAoTCU15Q29tcGFueTEOMAwG
A1UECxMFTXlPcmcxGDAWBgNVBAMUDyouYW1hem9uYXdzLmNvbTEgMB4GCSqGSIb3
DQEJARYRcmFtc2hhaEBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDgMbFor5Ee/+dOgcueYMGrYF8uKaBf/M0lAL1sa7OvwyPt2bRe4d9B
ga/SHU+0vg93F/mqMHQ1seMBUHUbDxwOISsSABfL0qbbvJKjZ+gqvI2oJF4aKef8
KAXvlA8h53nrx5Jw0Nk+394x4cC5Ff8/KQpRq1ZadwZqeO8epz5I4s8XpMOBDmfA
4ccW/IzYNjxt91hataYaw7smpnNs8ym0DZBZuUguxKgit2QgiB/pl9jL8Q1sf6dg
3aslPyXNizHPRiZHShFAdOI3Y2INj9lXrfLEJd8uD2qk1kK4Pwo590Jk8Sry1qSJ
YHGJHn8dE+xxYB1ZCyiIqAbWTg0RsUD1AgMBAAGjgfUwgfIwHQYDVR0OBBYEFBYq
K3b39+1oOr4IBSsePwcOpML7MIHCBgNVHSMEgbowgbeAFBYqK3b39+1oOr4IBSse
PwcOpML7oYGTpIGQMIGNMQswCQYDVQQGEwJVUzELMAkGA1UECBMCQ0ExETAPBgNV
BAcTCFNhbiBKb3NlMRIwEAYDVQQKEwlNeUNvbXBhbnkxDjAMBgNVBAsTBU15T3Jn
MRgwFgYDVQQDFA8qLmFtYXpvbmF3cy5jb20xIDAeBgkqhkiG9w0BCQEWEXJhbXNo
YWhAY2lzY28uY29tggkApY2On/9qsGwwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0B
AQsFAAOCAQEAe/RuzCheLIbHbrurGet6eaVx9DPYydNiKVBSAKO+5iuR84mQzhoT
nx5CN109xu5ml5baCYZZsSnn6D7usC092bPA/kRCGxt29gkjpWA74tJHqIhVWgbM
mOrLiSHoelewv+wRl0oVRChlTfKtXO68TUk6vrqpw76hKfOHIa7b2h1IIMdq6VA/
+A5FQ0xqYfqKdVd2RaINpzI8mqZiszqw+7E6j1PL5k4tftWEaYpfGPlVesFEyJEL
gHBUiPt8TIbaMYI8qUQmB/emnLXeKQ5PRxdRnleA3h8jfq3D1CQRTLjmDL3tpFwg
qopM6et5ZKqShX4T87BsgZIoiquzXqsuHg==
-----END CERTIFICATE-----">
</pkiTP>
</cloudCertStore>
</fvTenant>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
219
Deploying Layer 4 to Layer 7 Services
Creating an HTTPS Service Policy Using the REST API
</polUni>
Creating an HTTPS Service Policy Using the REST API
This section demonstrates how to create an HTTPS service policy using the REST API.
Note
A listener can have multiple certificates. The certificate options are:
• ELBSecurityPolicy-2016-08 – The default when no security policy is chosen.
• ELBSecurityPolicy-FS-2018-06
• ELBSecurityPolicy-TLS-1-2-2017-01
• ELBSecurityPolicy-TLS-1-2-Ext-2018-06
• ELBSecurityPolicy-TLS-1-1-2017-01
• ELBSecurityPolicy-2015-05
• ELBSecurityPolicy-TLS-1-0-2015-04
If you use multiple certificates, you must specify the default certificate. The default is specified using the
defaultCert property in cloudRsListenerToCert.
Before you begin
You have already configured a key ring certificate.
Note
This is applicable only for the Application Gateways.
To create an HTTPS service policy:
<polUni>
<fvTenant name="t2">
<vnsAbsGraph name="CloudGraph" type="cloud" status="">
<vnsAbsNode funcType="GoTo" name="N1" managed="yes">
<cloudSvcPolicy tenantName="t2" contractName="httpFamily" subjectName="consubj">
<cloudListener name="https_listener" port="443" protocol="https"
secPolicy="eLBSecurityPolicy-2016-08" status="">
<cloudRsListenerToCert defaultCert="yes" certStore="default"
tDn="uni/tn-t2/certstore/keyring-lbCert" status=""/>
<cloudListenerRule name="defaultRule" default="yes" priority="100" status="">
<cloudRuleAction type="forward" port="80" protocol="http"
epgdn="uni/tn-t1/cloudapp-ap/cloudepg-ep1">
</cloudRuleAction>
</cloudListenerRule>
</cloudListener>
</cloudSvcPolicy>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
220
Deploying Layer 4 to Layer 7 Services
Creating an HTTPS Service Policy Using the REST API
</vnsAbsNode>
</vnsAbsGraph>
</fvTenant>
</polUni>
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
221
Deploying Layer 4 to Layer 7 Services
Creating an HTTPS Service Policy Using the REST API
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
222
CHAPTER
7
Cisco Cloud APIC Security
This chapter contains the following sections:
• Access, Authentication, and Accounting, on page 223
• Configuring TACACS+, RADIUS, LDAP and SAML Access, on page 224
• Configuring HTTPS Access, on page 231
Access, Authentication, and Accounting
Cisco Cloud Application Policy Infrastructure Controller (Cloud APIC) policies manage the authentication,
authorization, and accounting (AAA) functions. The combination of user privileges, roles, and domains with
access rights inheritance enables administrators to configure AAA functions at the managed object level in a
granular fashion. These configurations can be implemented using the REST API or the GUI.
Note
There is a known limitation where you cannot have more than 32 characters for the login domain name. In
addition, the combined number of characters for the login domain name and the user name cannot exceed 64
characters.
For more access, authentication, and accounting configuration information, see Cisco APIC Security
Configuration Guide, Release 4.0(1) at https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/
sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Configuration
The admin account is configured in the initial configuration script, and the admin is the only user when the
system starts.
Configuring a Local User
Refer to Creating a Local User Using the Cisco Cloud APIC GUI, on page 109 to configure a Local User and
associate it to the OTP, SSH Public Key, and X.509 User Certificate using the Cloud APIC GUI.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
223
Cisco Cloud APIC Security
Configuring TACACS+, RADIUS, LDAP and SAML Access
Configuring TACACS+, RADIUS, LDAP and SAML Access
The following topics describe how to configure TACACS+, RADIUS, LDAP and SAML access for the Cloud
APIC.
Overview
This topic provides step-by-step instructions on how to enable access to the Cloud APIC for RADIUS,
TACACS+, LDAP, and SAML users, including ADFS, Okta, and PingID.
For additional TACACS+, RADIUS, LDAP, and SAML information, see Cisco APIC Security Configuration
Guide, Release 4.0(1) at https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/
Cisco-APIC-Security-Configuration-Guide-401.html.
Configuring Cloud APIC for TACACS+ Access
Before you begin
• The Cloud Application Policy Infrastructure Controller (Cloud APIC) is online.
• The TACACS+ server host name or IP address, port, and key are available.
• The Cloud APIC management endpoint group is available.
Step 1
In the Cloud APIC, create the TACACS+ Provider.
a) On the menu bar, choose Administrative > Authentication.
b) In the Work pane, click on Providers tab and then click on the Actions drop-down and select Create Provider.
The Create Provider dialog box appears.
c)
d)
e)
f)
Step 2
In the Host Name/IP Address field, enter the Host Name/IP Address of the provider.
In the Description field, enter a description of the provider.
Click the Type drop-down list and choose TACACS+.
In Settings section, specify the Key, Port, Authentication Protocol, Timeout, Retries, Management EPG. Select
either Enabled or Disabled for Server Monitoring.
Create the Login Domain for TACACS+.
a) Click the Intent icon.
The Intent menu appears.
b) Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appear in the Intent menu.
c) From the Administrative list in the Intent menu, click Create Login Domain.
The Create Login Domain dialog box appears.
d) Enter the appropriate values in each field as listed in the following Create Login Domain Dialog Box Fields table
then continue.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
224
Cisco Cloud APIC Security
Configuring Cloud APIC for RADIUS Access
Properties
Description
General
Name
Enter the name of the Login Domain
Description
Enter the description of the Login Domain.
Settings
Realm
Choose TACACS+ from the dropdown menu
Providers
To choose a Provider(s):
1. Click Add Providers. The Select Providers dialog
appears.
2. Click to choose a provider(s) in the column on the
left.
3. Click Select. You return to the Create Login Domain
dialog box.
e) Click Save to save the configuration.
What to do next
This completes the APIC TACACS+ configuration steps. Next, if a RADIUS server will also be used, configure
the APIC for RADIUS.
Configuring Cloud APIC for RADIUS Access
Before you begin
• The Cloud Application Policy Infrastructure Controller (Cloud APIC) is online.
• The RADIUS server host name or IP address, port, and key are available.
• The Cloud APIC management endpoint group is available.
Step 1
In the Cloud APIC, create the RADIUS Provider.
a) On the menu bar, choose Administrative > Authentication.
b) In the Work pane, click on Providers tab and then click on the Actions drop-down and select Create Provider.
The Create Provider dialog box appears.
c) In the Host Name/IP Address field, enter the Host Name/IP Address of the provider.
d) In the Description field, enter a description of the provider.
e) Click the Type drop-down list and choose RADIUS.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
225
Cisco Cloud APIC Security
Configuring Cloud APIC for RADIUS Access
f) In the Settings section, specify the Key, Port, Authentication Protocol, Timeout, Retries, Management EPG.
Select either Enabled or Disabled for Server Monitoring.
Step 2
Create the Login Domain for RADIUS.
a) Click the Intent icon.
The Intent menu appears.
b) Click the drop-down arrow below the Intent search box and choose Administrative
A list of Administrative options appear in the Intent menu.
c) From the Administrative list in the Intent menu, click Create Login Domain.
The Create Login Domain dialog box appears.
d) Enter the appropriate values in each field as listed in the following Create Login Domain Dialog Box Fields table
then continue.
Properties
Description
General
Name
Enter the name of the Login Domain
Description
Enter the description of the Login Domain.
Settings
Realm
Choose RADIUS from the dropdown menu
Providers
To choose a Provider(s):
1. Click Add Providers. The Select Providers dialog
appears.
2. Click to choose a provider(s) in the column on the
left.
3. Click Select. You return to the Create Login Domain
dialog box.
e) Click Save to save the configuration.
What to do next
This completes the Cloud APIC RADIUS configuration steps. Next, configure the RADIUS server.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
226
Cisco Cloud APIC Security
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+ Access to the Cloud APIC
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+
Access to the Cloud APIC
Refer to the section Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+ Access to the APICin
the Cisco APIC Security Configuration Guide, Release 4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Configuring LDAP Access
There are two options for LDAP configurations:
• Configure a Cisco AVPair
• Configure LDAP group maps in the cloud APIC
The following sections contain instructions for both configuration options.
Configuring Windows Server 2008 LDAP for APIC Access with Cisco AVPair
Refer to the section Configuring Windows Server 2008 LDAP for APIC Access with Cisco AVPair in the Cisco APIC
Security Configuration Guide, Release 4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Configuring Cloud APIC for LDAP Access
Before you begin
• The Cloud Application Policy Infrastructure Controller (Cloud APIC) is online.
• The LDAP server host name or IP address, port, bind DN, Base DN, and password are available.
• The cloud APIC management endpoint group is available.
Step 1
In the Cloud APIC, create the LDAP Provider.
a) On the menu bar, choose Administrative > Authentication.
b) In the Work pane, click on Providers tab and then click on the Actions drop-down and select Create Provider.
The Create Provider dialog box appears.
c)
d)
e)
f)
In the Host Name/IP Address field, enter the Host Name/IP Address of the provider.
In the Description field, enter a description of the provider.
Click the Type drop-down list and choose LDAP.
Specify the Bind DN, Base DN, Password, Port, Attribute, Filter Type and Management EPG.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
227
Cisco Cloud APIC Security
Configuring Cloud APIC for LDAP Access
Note
• The bind DN is the string that the Cloud APIC uses to log in to the LDAP server. The Cloud APIC
uses this account to validate the remote user attempting to log in. The base DN is the container name
and path in the LDAP server where the Cloud APIC searches for the remote user account. This is
where the password is validated. Filter is used to locate the attribute that the Cloud APIC requests to
use for the cisco-av-pair. This contains the user authorization and assigned RBAC roles for use on
the Cloud APIC. The Cloud APIC requests the attribute from the LDAP server.
• Attribute field—Enter one of the following:
• For LDAP server configurations with a Cisco AVPair, enter CiscoAVPair.
• For LDAP server configurations with an LDAP group map, enter memberOf.
Step 2
Create the Login Domain for LDAP.
a) On the menu bar, choose Administrative > Authentication.
b) In the Work pane, click on Login Domains tab and then click on the Actions drop-down and select Create Login
Domain.
c) Enter the appropriate values in each field as listed in the following Create Login Domain Dialog Box Fields table
then continue.
Properties
Description
General
Name
Enter the name of the Login Domain
Description
Enter the description of the Login Domain.
Settings
Realm
Choose LDAP from the dropdown menu
Providers
To choose a Provider(s):
1. Click Add Providers. The Select Providers dialog
appears.
2. Click to choose a provider(s) in the column on the
left.
3. Click Select. You return to the Create Login Domain
dialog box.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
228
Cisco Cloud APIC Security
Configuring Cloud APIC for SAML Access
Properties
Description
Authentication Type
1. Select Cisco AV Pairs, if provider(s) was configured
with CiscoAVPair as the Attribute.
2. Select LDAP Group Map Rules, if provider(s) was
configured with memberOf as the Attribute.
a. Click Add LDAP Group Map Rule. The dialog
box appears.
b. Specify the map rule Name, Description
(optional), and Group DN.
c. Click the + next to Add Security Domain. The
dialog box appears.
d. Click the + to access the Role name and Role
Privilege Type (Read or Write) fields. Click
check mark.
e. Repeat step 4 to add more roles. Then click Add.
f.
Repeat step 3 to add more security domains. Then
click Add.
d) Click Save on Create Login Domain dialog box.
Configuring Cloud APIC for SAML Access
The following sections provide detailed information on configuring Cloud APIC for SAML access.
About SAML
Refer to the section About SAML in the Cisco APIC Security Configuration Guide, Release 4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Basic Elements of SAML
Refer to the section Basic Elements of SAML in the Cisco APIC Security Configuration Guide, Release
4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Supported IdPs and SAML Components
Refer to the section Supported IdPs and SAML Components in the Cisco APIC Security Configuration
Guide, Release 4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
229
Cisco Cloud APIC Security
Configuring Cloud APIC for SAML Access
Configuring Cloud APIC for SAML Access
Note
SAML based Authentication is only for Cloud APIC GUI and not for REST.
Before you begin
• The SAML server host name or IP address, and the IdP’s metadata URL are available.
• The Cloud APIC management endpoint group is available.
• Set up the following:
• Time Synchronization and NTP
• Configuring a DNS Provider Using the GUI
• Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Step 1
In the Cloud APIC, create the SAML Provider.
a)
b)
c)
d)
e)
f)
On the menu bar, choose Administrative > Authentication.
In the Work pane, click on Providers tab and then click on the Actions drop-down and select Create Provider.
In the Host Name/IP Address field, enter the Host Name/IP Address of the provider.
In the Description field, enter a description of the provider.
Click the Type drop-down list and choose SAML.
In Settings pane, perform following:
• Specify the IdP metadata URL:
• In case of AD FS, IdP Metadata URL is of the format https://<FQDN
ofADFS>/FederationMetadata/2007-06/FederationMetadata.xml.
• In case of Okta, to get the IdP Metadata URL, copy the link for Identity Provider Metadata in the Sign
On section of the corresponding SAML Application from the Okta server.
• Specify the Entity ID for the SAML-based service.
• Configure the HTTPS Proxy for Metadata URL if it is needed to access the IdP metadata URL.
• Select the Certificate Authority if IdP is signed by a Private CA.
• Select the Signature Algorithm Authentication User Requests from the drop-down.
• Select checkbox to enable Sign SAML Authentication Requests, Sign SAML Response Message, Sign
Assertions in SAML Response, Encrypt SAML Assertions.
g) Click Save to save the configuration.
Step 2
Create the login domain for SAML.
a) On the menu bar, choose Administrative > Authentication.
b) In the Work pane, click on the Login Domains tab and then click on the Actions drop-down and select Create Login
Domain.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
230
Cisco Cloud APIC Security
Setting Up a SAML Application in Okta
c) Enter the appropriate values in each field as listed in the following Create Login Domain Dialog Box Fields table
then continue.
Properties
Description
General
Name
Enter the name of the Login Domain
Description
Enter the description of the Login Domain.
Settings
Realm
Choose SAML from the dropdown menu
Providers
To choose a Provider(s):
1. Click Add Providers. The Select Providers dialog
appears.
2. Click to choose a provider(s) in the column on the
left.
3. Click Select. You return to the Create Login Domain
dialog box.
d) Click Save to save the configuration.
Setting Up a SAML Application in Okta
Refer to the section Setting Up a SAML Application in Okta of Cisco APIC Security Configuration Guide, Release
4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Setting Up a Relying Party Trust in AD FS
Refer to the section Setting Up a Relying Party Trust in AD FS in the Cisco APIC Security Configuration Guide, Release
4.0(1) at
https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/Cisco-APIC-Security-Configuration-Guide-401.html.
Configuring HTTPS Access
The following sections describe how to configure HTTPS access.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
231
Cisco Cloud APIC Security
About HTTPS Access
About HTTPS Access
This article provides an example of how to configure a custom certificate for HTTPS access when using Cisco
ACI.
For more information, see the section HTTPS Access in the Cisco APIC Security Configuration Guide,
Release 4.0(1) at https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/4-x/security/
Cisco-APIC-Security-Configuration-Guide-401.html.
Guidelines for Configuring Custom Certificates
• Wild card certificates (such as *.cisco.com, which is used across multiple devices) and its associated
private key generated elsewhere are not supported on the Cisco Cloud APIC as there is no support to
input the private key or password in the Cisco Cloud APIC. Also, exporting private keys for any
certificates, including wild card certificates, is not supported.
• You must download and install the public intermediate and root CA certificates before generating a
Certificate Signing Request (CSR). Although a root CA Certificate is not technically required to generate
a CSR, Cisco requires the root CA certificate before generating the CSR to prevent mismatches between
the intended CA authority and the actual one used to sign the CSR. The Cisco Cloud APIC verifies that
the certificate submitted is signed by the configured CA.
• To use the same public and private keys for a renewed certificate generation, you must satisfy the following
guidelines:
• You must preserve the originating CSR as it contains the public key that pairs with the private key
in the key ring.
• The same CSR used for the originating certificate must be resubmitted for the renewed certificate
if you want to re-use the public and private keys on the Cisco Cloud APIC.
• Do not delete the original key ring when using the same public and private keys for the renewed
certificate. Deleting the key ring will automatically delete the associated private key used with
CSRs.
• Only one Certificate Based Root can be active per pod.
• Client Certificate based authentication is not supported for this release.
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Determine from which authority you will obtain the trusted certification so that you can create the appropriate
Certificate Authority.
Before you begin
CAUTION: PERFORM THIS TASK ONLY DURING A MAINTENANCE WINDOW AS THERE IS A
POTENTIAL FOR DOWNTIME. Expect a restart of all web servers on Cloud APIC during this operation.
Step 1
On the menu bar, choose Administrative > Security.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
232
Cisco Cloud APIC Security
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Step 2
In the Work pane, click on Certificate Authorities tab and then click on the Actions drop-down and select Create
Certificate Authority.
Step 3
In the Create Certificate Authority dialog box, in the Name field, enter a name for the certificate authority and in the
Description field, enter a description.
Step 4
Select System in the Used for field.
Step 5
In the Certificate Chain field, copy the intermediate and root certificates for the certificate authority that will sign the
Certificate Signing Request (CSR) for the Cloud Application Policy Infrastructure Controller (APIC). The certificate
should be in Base64 encoded X.509 (CER) format. The intermediate certificate is placed before the root CA certificate.
It should look similar to the following example:
-----BEGIN CERTIFICATE----<Intermediate Certificate>
-----END CERTIFICATE---------BEGIN CERTIFICATE----<Root CA Certificate>
-----END CERTIFICATE-----
Step 6
Click Save.
Step 7
On the menu bar, choose Administrative > Security.
Step 8
In the Work pane, click on the Key Rings tab, then click on the Actions drop-down and select Create Key Ring.
Step 9
In the Create Key Ring dialog box, enter a name for the key ring in the Name field and a description in the Description
field.
Step 10
Select System in the Used for field.
Step 11
For the Certificate Authority field, click on Select Certificate Authorityand select the Certificate Authority that you
created earlier.
Step 12
Select either Generate New Key or Import Existing Key for the field Private Key. If you select Import Existing
Key, enter a private key in the Private Key text box.
Step 13
Select modulus from the Modulus drop-down. menu
Step 14
In the Certificate field, do not add any content.
Step 15
Click Save.
In the Work pane, in the Key Rings area, the Admin State for the key ring created displays Started.
Step 16
Double-click on the created Key Ring to open Key Ring key_ring_name dialog box from the Work pane.
Step 17
In the Work pane, click on Create Certificate Request.
Step 18
In the Subject field, enter the fully qualified domain name (FQDN) of the Cloud APIC.
Step 19
Fill in the remaining fields as appropriate.
Step 20
Click Save.
The Key Ring key_ring_name dialog box appears.
Step 21
Copy the contents from the field Request to submit to the Certificate Authority for signing.
Step 22
From the Key Ring key_ring_name dialog box, click on edit icon to display the Key Ring key_ring_name dialog box.
Step 23
In the Certificate field, paste the signed certificate that you received from the certificate authority.
Step 24
Click Save to return to the Key Rings work pane.
The key is verified, and in the Work pane, the Admin State changes to Completed and is now ready for use in the
HTTPs policy.
Step 25
Navigate to Infrastructure > System Configuration, then click the Management Access tab.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
233
Cisco Cloud APIC Security
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Step 26
Click the edit icon on the HTTPS work pane to display the HTTPS Settings dialog box.
Step 27
Click on Admin Key Ring and associate the Key Ring that you created earlier.
Step 28
Click Save.
All web servers restart. The certificate is activated, and the non-default key ring is associated with HTTPS access.
What to do next
You must remain aware of the expiration date of the certificate and take action before it expires. To preserve
the same key pair for the renewed certificate, you must preserve the CSR, as it contains the public key that
pairs with the private key in the key ring. Before the certificate expires, the same CSR must be resubmitted.
Do not delete or create a new key ring, as deleting the key ring will delete the private key stored internally
on the Cloud APIC.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
234
CHAPTER
8
Restricting Access
• Restricting Access by Domains, on page 235
• RBAC Roles, on page 235
• RBAC Rules, on page 239
• Guidelines and Limitations for Restricted Domains , on page 240
• Creating an RBAC Rule Using the Cisco Cloud APIC GUI, on page 240
Restricting Access by Domains
A restricted security domain allows a fabric administrator to prevent a group of users, such as Tenant A, from
viewing or modifying any objects created by a group of users in a different security domain, such as Tenant
B, when users in both groups have the same assigned privileges. For example, a tenant administrator in Tenant
A's restricted security domain will not be able to see policies, profiles, or users configured in Tenant B's
security domain. Unless Tenant B's security domain is also restricted, Tenant B will be able to see policies,
profiles, or users configured in Tenant A. Note that a user will always have read-only visibility to system-created
configurations for which the user has proper privileges.
For example, consider a user in a restricted security domain is associated to Tenant A. Tenant A includes two
application profiles, application profile 1 created by the user and application profile 2 created by an
administrator. The user can view only application profile 1 although application profile 2 is also with the same
tenant. When a user is in a restricted security domain, even profiles created by administrators are not visible.
In the above example, an unrestricted user (user not in a restricted security domain), can view both, application
profile 1 and application profile 2, although application profile 2 was created by another user (administrator).
RBAC Roles
The Cloud Application Policy Infrastructure Controller (cAPIC) provides access according to a user’s role
through role-based access control (RBAC). A fabric user is associated with the following:
• A set of roles
• For each role, a privilege type: no access, read-only, or read-write
• One or more security domain tags that identify the portions of the management information tree (MIT)
that a user can access
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
235
Restricting Access
RBAC Roles
The Cloud APIC manages access privileges at the managed object (MO) level. A privilege is an MO that
enables or restricts access to a particular function within the system. For example, fabric-equipment is a
privilege bit. This bit is set by the cAPIC on all objects that correspond to equipment in the physical fabric.
A role is a collection of privilege bits. For example, because an “admin” role is configured with privilege bits
for “fabric-equipment” and “tenant-security,” the “admin” role has access to all objects that correspond to
equipment of the fabric and tenant security.
A security domain is a tag associated with a certain subtree in the cAPIC object hierarchy. For example, the
default tenant “common” has a domain tag common. Similarly, the special domain tag all includes the entire
MIT object tree. An administrator can assign custom domain tags to the MIT object hierarchy.
Creating a user and assigning a role to that user does not enable access rights. It is necessary to also assign
the user to one or more security domains. By default, the cAPIC fabric includes two special pre-created
domains:
• All—allows access to the entire MIT
• Infra—allows access to fabric infrastructure objects/subtrees, such as fabric access policies
Cisco Cloud APIC supports the following AAA roles and privileges:
Privilege
Description
Role: admin
admin
Provides full access to all of the features of the fabric.
The admin privilege can be considered to be a union
of all other privileges.
Role: aaa
aaa
Used for configuring authentication, authorization,
accounting, and import/export policies.
Role: access-admin
access-connectivity
Used for Layer 1-3 configuration under infra, static
route configurations under a tenant's L3Out,
management infra policies, and tenant ERSPAN
policies.
access-equipment
Used for access port configuration.
access-protocol
Used for Layer 1-3 protocol configurations under
infra, fabric-wide policies for NTP, SNMP, DNS, and
image management, and operations-related access
policies such as cluster policy and firmware policies.
access-qos
Used for changing CoPP and QoS-related policies.
Role: fabric-admin
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
236
Restricting Access
RBAC Roles
Privilege
Description
fabric-connectivity
Used for Layer 1-3 configuration under the fabric,
firmware and deployment policies for raising warnings
for estimating policy deployment impact, and atomic
counter, diagnostic, and image management policies
on leaf switches and spine switches.
fabric-equipment
Used for atomic counter, diagnostic, and image
management policies on leaf switches and spine
switches.
fabric-protocol
Used for Layer 1-3 protocol configurations under the
fabric, fabric-wide policies for NTP, SNMP, DNS,
and image management, ERSPAN and health score
policies, and firmware management traceroute and
endpoint tracking policies.
Role: nw-svc-admin
nw-svc-policy
Used for managing Layer 4 to Layer 7 service devices
and network service orchestration.
Role: nw-svc-params
nw-svc-params
Used for managing Layer 4 to Layer 7 service policies.
Role: ops
ops
Used for viewing the policies configured including
troubleshooting policies.
Role: port-mgmt
port-mgmt
Used for assigning a node to a security domain. A
user in a security domain with a Node Rule must also
be assigned to domain all with the role of port-mgmt.
Role: tenant-admin
aaa
Used for configuring authentication, authorization,
accouting and import/export policies.
access-connectivity
Used for Layer 1-3 configuration under infra, static
route configurations under a tenant's L3Out,
management infra policies, and tenant ERSPAN
policies.
access-equipment
Used for access port configuration.
access-protocol
Used for Layer 1-3 protocol configurations under
infra, fabric-wide policies for NTP, SNMP, DNS, and
image management, and operations-related access
policies such as cluster policy and firmware policies.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
237
Restricting Access
RBAC Roles
Privilege
Description
access-qos
Used for changing CoPP and QoS-related policies.
fabric-connectivity
Used for Layer 1-3 configuration under the fabric,
firmware and deployment policies for raising warnings
for estimating policy deployment impact, and atomic
counter, diagnostic, and image management policies
on leaf switches and spine switches.
fabric-equipment
Used for atomic counter, diagnostic, and image
management policies on leaf switches and spine
switches.
fabric-protocol
Used for Layer 1-3 protocol configurations under the
fabric, fabric-wide policies for NTP, SNMP, DNS,
and image management, ERSPAN and health score
policies, and firmware management traceroute and
endpoint tracking policies.
nw-svc-policy
Used for managing Layer 4 to Layer 7 service devices
and network service orchestration.
tenant-network-profile
Used for managing tenant configurations, such as
deleting and creating network profiles, and deleting
and creating endpoint groups.
tenant-protocol
Used for managing configurations for Layer 1-3
protocols under a tenant, for tenant traceroute policies,
and as write access for firmware policies.
tenant-qos
Used for QoS-related configurations for a tenant.
tenant-security
Used for contract-related configurations for a tenant.
Role: tenant-ext-admin
tenant-connectivity
Used for Layer 1-3 connectivity changes, including
bridge domains, subnets, and VRFs; for atomic
counter, diagnostic, and image management policies
on leaf switches and spine switches; tenant in-band
and out-of-band management connectivity
configurations; and debugging/monitoring policies
such as atomic counters and health score.
tenant-epg
Used for managing tenant configurations such as
deleting/creating endpoint groups, VRFs, and bridge
domains.
tenant-ext-connectivity
Used for write access firmware policies; managing
tenant L2Out and L3Out configurations; and
debugging/monitoring/observer policies.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
238
Restricting Access
RBAC Rules
Privilege
Description
tenant-ext-protocol
Used for managing tenant external Layer 1-3
protocols, including BGP, OSPF, PIM, and IGMP,
and for debugging/monitoring/observer policies such
as traceroute, ping, oam, and eptrk. Generally only
used for write access for firmware policies.
tenant-network-profile
Used for managing tenant configurations, such as
deleting and creating network profiles, and deleting
and creating endpoint groups.
tenant-protocol
Used for managing configurations for Layer 1-3
protocols under a tenant, for tenant traceroute policies,
and as write access for firmware policies.
tenant-qos
Used for QoS-related configurations for a tenant.
tenant-security
Used for contract-related configurations for a tenant.
Custom privileges can be assigned to any MO Class. Twenty-two custom privileges are displayed in the Cisco
Cloud APIC GUI. If one of these custom privileges is assigned to any class, that MO’s access will include
the newly added custom privilege. One custom privilege can be associated with one or more MO classes.
Note
Although custom privileges are displayed by the Cisco Cloud APIC GUI, they are currently not supported.
A set of predefined managed object classes can be associated with domains. These classes should not have
overlapping containment. Examples of classes that support domain association are as follows:
• Layer 2 and Layer 3 network managed objects
• Network profiles (such as physical, Layer 2, Layer 3, management)
• QoS policies
When an object that can be associated with a domain is created, the user must assign domain(s) to the object
within the limits of the user's access rights. Domain assignment can be modified at any time.
RBAC Rules
RBAC rules selectively expose resources (such as, application profiles, EPGs, contracts) to users that are
otherwise inaccessible because they are in a different security domain. An RBAC rule comprises two parts:
the distinguished name (DN) that locates the object to be accessed and the name of the security domain that
contains the user who will access the object.
There are two types of RBAC rules:
• Implicit—a user inherits a rule or permission based on RBAC hierarchy
• Explicit—a rule is directly assigned to the user based on certain policies
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
239
Restricting Access
Guidelines and Limitations for Restricted Domains
Both restricted and unrestricted security domains are supported.
Note
While an RBAC rule exposes an object to a user in a different part of the management information tree, it is
not possible to use the CLI to navigate to such an object by traversing the structure of the tree. However, as
long as the user knows the DN of the object included in the RBAC rule, the user can use the CLI to locate it
via an MO find command.
Guidelines and Limitations for Restricted Domains
The following are the guidelines and restrictions for the users of restricted domains:
• If a user from one security domain is assigned another security domain, the user gets access to the
configurations associated with the new domain.
• A user can be part of one or more security domains which are marked “restricted”.
• Restricted domain users have read-only access to system created configurations.
• For a user with multiple security domains, the combined length of all security domains cannot exceed
1024 characters. If the length exceeds 1024, the user will have policy creation issues.
• Restricted domain on the Cloud APIC is not supported on the cloud resources. This means, a user of one
restricted domain will be able to see cloud resources created by a user of another restricted domain.
Creating an RBAC Rule Using the Cisco Cloud APIC GUI
This section explains how to create an RBAC rule using the GUI.
Note
You can configure RBAC rules, however the Cloud APIC GUI does not support the configurations. The DN
configured using this procedure (step 4) can be queried using API.
Before you begin
Create a security domain. For the detailed task, see Creating a Security Domain Using the Cisco Cloud APIC
GUI.
Step 1
Click the Intent icon. The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Administrative.
A list of Administrative options appears in the Intent menu.
Step 3
From the Administrative list in the Intent menu, click Security > RBAC Rules > Create RBAC Rule. The Create
RBAC Rule dialog box appears.
Step 4
In the DN field, enter the DN for the rule.
For creating an explicit RBAC rule, locate the DN for the application in ObjectStore. Use that DN value here.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
240
Restricting Access
Creating an RBAC Rule Using the Cisco Cloud APIC GUI
Step 5
Choose a security domain:
a) Click Select Security Domain. The Select Security Domain dialog box appears.
b) From the Select Security Domain dialog box, click to choose a security domain from the column on the left then
click Select. You return to the Create RBAC Rule dialog box.
Step 6
From the Allow Writes field, click Yes to allow writes or No to not allow writes.
Step 7
Click Save when finished.
Note
After creating an explicit RBAC rule, a user assigned to a security domain will be able to only see the application
and its children that were defined earlier (from ObjectStore).
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
241
Restricting Access
Creating an RBAC Rule Using the Cisco Cloud APIC GUI
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
242
CHAPTER
9
Configuration Drifts
• Configuration Drift Notifications and Faults, on page 243
• Enabling Configuration Drift Detection, on page 244
• Checking for Missing Contracts Configuration, on page 245
• Configuration Drift Troubleshooting, on page 248
Configuration Drift Notifications and Faults
When you deploy Cisco ACI in a public cloud, you will perform most of the fabric configuration from the
Cloud APIC. However, there may be cases where you or another cloud administrator changes the deployed
configuration directly in the cloud provider's GUI using the tools provided by AWS or Azure. In these cases,
the intended configuration you deployed from the Cloud APIC and the actual configuration in the cloud site
may become out of sync, we call this a configuration drift.
Starting with Release 5.0(2), Cloud APIC provides visibility into any security policy (contracts) configuration
discrepancy between what you deploy from the Cloud APIC and what is actually configured in the cloud site.
Future releases will provide the configuration drift visibility into the other Cloud APIC objects as well as
information about extraneous configurations deployed in the cloud but not defined in the Cloud APIC.
There are two aspects to analyzing configuration drift:
• Have all the fabric elements configured in the Cloud APIC and intended to be deployed in the cloud
fabric been properly deployed?
This scenario can occur due to user configuration errors in Cloud APIC that could not be deployed in
the cloud, connection or API issues on the cloud provider end, or if a cloud administrator manually deletes
or modifies security rules directly in the cloud provider's UI. Any intended but missing configurations
may present an issue for the Cloud APIC fabric.
• Are there any additional configurations that exist in the cloud but were not intended to be deployed from
the Cloud APIC?
Similarly to the previous scenario, this can occur if there are connection or API issues or if a cloud
administrator manually creates additional security rules directly in the cloud provider's UI. Any existing
but not intended configuration may present issues.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
243
Configuration Drifts
Enabling Configuration Drift Detection
Enabling Configuration Drift Detection
In this release, configuration drift detection is in beta stage, as such it is disabled by default. This section
describes how to enable configuration drift detection in your Cloud APIC user preferences.
Step 1
Log in to your Cloud APIC GUI.
Step 2
Open the User Preferences dialog.
a) In the top right corner of the screen, click the user icon.
b) From the menu, select User Preferences.
Step 3
In the User Preferences dialog, enable Configuration Drift Detection.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
244
Configuration Drifts
Checking for Missing Contracts Configuration
a) Check the Enabled checkbox.
b) Click Done to save the change.
Checking for Missing Contracts Configuration
This section describes how to check for any contract settings you have configured from the Cloud APIC, but
which have not been properly deployed to the cloud fabric.
Step 1
Log in to your Cloud APIC GUI.
Step 2
Navigate to the Configuration Drifts screen.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
245
Configuration Drifts
Checking for Missing Contracts Configuration
a) In the Navigation sidebar, expand the Application Management category.
b) From the Application Management category, select Contracts.
c) In the Contracts screen, select the Configuration Drifts tab.
In the Configuration Drifts tab, you can see a summary of any configuration issues with the contracts in your fabric.
For each contract with a drift, you will see the number of missing configurations and the severity of the issue.
You can refresh the information by clicking the refresh button in the top right of the main window.
Step 3
In the Configuration Drifts screen, click the name of a contract to view its details, including the configuration drift
issues.
Step 4
In the Contract details view that opens, select the Cloud Mapping tab.
The Cloud Mapping view displays all the information about the contract and the cloud resources it uses.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
246
Configuration Drifts
Checking for Missing Contracts Configuration
The screen is divided into three sections, Detection Summary, Configuration Drifts, and Mapped Cloud Resources.
Each section contains a table that lists the respective information about the contract you selected.
The Detection Summary table provides an overview of how many configuration drifts were detected, number of intended
and actual cloud resources configured, and the time when this information was last updated. If the inventory update
timestamp is out of date, you can refresh the information by clicking the Refresh icon in the top right corner of this
screen.
The Configuration Drifts table lists all the issues with the contract rules. Specifically, all the contract rules that were
intended to be deployed but are missing in the actual fabric configuration. The table contains detailed information, such
as the protocol used, port ranges, source and destination IP or group, consumer and provider EPGs, description of the
issue, and the recommended action to resolve it. For each configuration drift, the Status field will indicate the severity
and recommended action:
• Transient (low): drifts that are likely due to recent configuration changes. We recommend waiting for the fabric
to stabilize and the drift will likely resolve on its own after the next configuration refresh.
• Presumed (medium): drifts that may or may not be transient. We recommend monitoring the status and troubleshoot
the configuration should the drift persist.
(high): critical drifts. We recommend verifying the configuration on Cloud APIC and checking for any
associated faults. Redeploying the configuration may help resolve communication issues between the Cloud APIC
and cloud services. If the issue persists, check the tech-support logs.
Raised
The Mapped Cloud Resources table shows the information about all the resources that were properly configured in your
cloud. This table is designed to provide you with better visibility into what rules are configured in your cloud for a specific
contract.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
247
Configuration Drifts
Configuration Drift Troubleshooting
Configuration Drift Troubleshooting
This section provides a few useful command to verify that the configuration drift processes are up and running
on your Cloud APIC, check the application logs, and if necessary generate tech support information.
Step 1
Log in to the Cisco Cloud APIC via console as a root user.
Step 2
Check the status of the configuration drift application.
ACI-Cloud-Fabric-1# moquery -d pluginContr/plugin-Cisco_CApicDrift | egrep "dn |pluginSt |operSt
|version"
dn: pluginContr/plugin-Cisco_CApicDrift
operSt: active
pluginSt: active
Verison: 5.1.0
Step 3
Check the status of the application container.
ACI-Cloud-Fabric-1# docker ps | grep drift
CONTAINER ID
IMAGE
COMMAND
CREATED
NAMES
649af6feb72c
a5ea08bbf541
"/opt/bin/conit.bi..." 13 hours ago
hours
drift-api-b703e569-0aa6-859f-c538-a5fecbc5708f
Step 4
STATUS
Up 13
Check memory consumed by all Docker containers.
Total amount of memory consumed must be under 12GB.
ACI-Cloud-Fabric-1# systemctl status ifc-scheduler_allocations.slice| grep Memory
Step 5
If necessary, collect the tech support logs.
Logs will be saved in the /data/techsupport directory on the controller.
ACI-Cloud-Fabric-1# trigger techsupport controllers application CApicDrift
ACI-Cloud-Fabric-1# trigger techsupport controllers application CApicDrift vendorName Cisco
Step 6
Check the application logs.
The logs for configuration drift process are stored in the /data2/logs/Cisco_CApicDrift directory.
The runhist.log file provides information about each time the application was started, for example:
# cat runhist.log
1 - Thu Jun 11 23:55:59 UTC 2020
2 - Fri Jun 12 01:19:41 UTC 2020
The drift.log file is the application log file and can be used to view the number of times configuration drift was updated
and how long each update took.
# cat drift.log | grep ITER
{"file":"online_snapshot.go:178","func":"Wait","level":"info","msg":"ITER# 109
ENDED === RDFGEN TIME: 1m40.383751649s, MODEL UPLOAD TIME 5m54.245550374s; TOTAL
TIME:: 7m34.629447083s","time":"2020-06-12T19:53:13Z"}
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
248
CHAPTER
10
Express Route Gateway
• About Express Route Gateway, on page 249
• About Deploying Express Route Gateway Using Redirect, on page 249
• About Deploying Express Route Gateway Without Redirect, on page 252
About Express Route Gateway
Beginning with Release 5.1(2), support is now available for express route gateway deployment, where you
can deploy an express route gateway in the hub VNet using redirect or without using redirect. The express
route gateway is used to provide connectivity between a Cloud APIC-managed cloud site and a non-ACI
remote site. The external EPG for the non-ACI remote site (in this case, connected by an express route gateway)
has a contract with the cloud EPG in the hub or spoke VNet.
About Deploying Express Route Gateway Using Redirect
In situations where you are deploying a connection between a cloud endpoint and an external network through
an express route gateway, you can insert a service device between them using redirect.
For this use case, the external EPG connected by the express route gateway has a contract with the cloud EPG
in either the hub or the spoke VNet. In this situation:
• The redirect is configured on the gateway subnet route table by the Cloud APIC. The traffic destined to
the provider cloud EPG is redirected to the service device deployed in the hub VNet as the next hop.
• You should have the service device that is used in the redirect in the same VNet as the external EPG
connected by the express route gateway (in this case, in the hub VNet).
• Having the provider cloud EPG stretched across regions is supported in this case.
The following figure shows an example of a redirect for express route gateway to the provider EPG in the
hub VNet.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
249
Express Route Gateway
About Deploying Express Route Gateway Using Redirect
The following figure shows an example of a redirect for express route gateway to the provider EPG in the
spoke VNet.
The following table describes how redirect is programmed.
Consumer
Provider
External EPG connected Cloud EPG with
by the express route
subnet-based endpoint
gateway
selector
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
250
Redirect on Gateway
Subnet Route Table
Redirect on Provider VNet
Redirect for the
consumer-to-provider
traffic using the subnets
of the provider
Redirect for the
provider-to-consumer
traffic using the subnets
of the external EPG
Express Route Gateway
Deploying Express Route Gateway Using Redirect
Deploying Express Route Gateway Using Redirect
Before you begin
Review the information provided in About Deploying Express Route Gateway Using Redirect, on page 249
before proceeding with these procedures.
Step 1
Enable VNet peering on your Cloud APIC.
Refer to Configuring VNET Peering for Cloud APIC for Azure for those instructions.
The gateway subnet in the hub VNet that is required for the express route gateway is deployed by the Cloud APIC when
VNet peering is enabled. This is done to prepare the hub VNet for the deployment of the express route gateway.
Step 2
Create an external EPG in the hub VNet that represents the network for the non-ACI remote site.
• To create an external EPG using the GUI, see Creating an External EPG Using the Cisco Cloud APIC GUI, on page
59.
In the Route Reachability field for the external EPG, select External-Site.
• To create an external EPG using the REST API, see Creating an External Cloud EPG Using the REST API, on page
125.
Create an external cloud EPG with the type site-external.
Step 3
Through the Azure portal, deploy the express route gateway in the hub VNet using the gateway subnet that you configured
in Step 1, on page 251.
Depending on the number of regions that you selected when you enabled VNet peering in Step 1, on page 251, if you
need express route gateway access on multiple regions that the Cloud APIC will manage, deploy express route gateways
in each of those regions separately.
a) In the Azure portal, navigate to the Resource Manager virtual network where you want to create a virtual network
gateway.
b) On the left side, select Create a resource, and type Virtual Network Gateway in search.
c) Locate Virtual network gateway in the search return and click the entry.
d) On the Virtual network gateway page, choose Create.
e) On the Create virtual network gateway page, enter the appropriate information for these fields:
• Subscription: Verify that the correct subscription is selected.
• Resource Group: The resource group will automatically be chosen once you choose the virtual network.
• Name: The name of your express route gateway.
• Region: Change the Region field to point to the location where your virtual network is located. If the location
isn't pointing to the region where your virtual network is, the virtual network won't appear in the Choose a
virtual network dropdown.
• Gateway type: Choose ExpressRoute.
• SKU: Choose the gateway SKU from the dropdown.
• Virtual network: Choose the virtual network that was created by the Cloud APIC in Step 1, on page 251.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
251
Express Route Gateway
About Deploying Express Route Gateway Without Redirect
• Public IP address: Choose Create new.
• Public IP address name: Provide a name for the public IP address.
f) Select Review + Create, and then Create to begin creating the gateway.
The settings are validated and the gateway deploys. Creating virtual network gateway can take up to 45 minutes to
complete.
To verify that the express route gateway was deployed successfully, navigate to the network gateways page in the
Azure portal and verify that a network gateway with the type express route was created.
If you need express route gateway access on additional regions, repeat these steps for each of those regions.
Step 4
Configure the service device for the redirect.
To configure a service device for redirect using the GUI or REST API, see Deploying Layer 4 to Layer 7 Services, on
page 141.
Step 5
Configure a contract between the cloud EPG and the external EPG connected by the express route gateway.
• To create a contract using the GUI, see Creating a Contract Using the Cisco Cloud APIC GUI, on page 77.
• To configure a contract using the REST API, see Creating a Contract Using the REST API, on page 121.
About Deploying Express Route Gateway Without Redirect
For this type of deployment, route propagation to the spoke VNet is automatically enabled by the Cloud APIC.
This allows your non-ACI remote site subnet routes to be available to the spoke VNet through the hub VNet
using VNet peering with gateway transit (also referred to as transit peering). VNet peering with gateway
transit is also automatically enabled by the Cloud APIC in this situation.
As part of this configuration, you will deploy the express route gateway in the hub VNet. When the Cloud
APIC detects that the express route gateway has been configured in the hub VNet, it automatically sets the
transit peering properties, one for the hub → spoke peering and the other for the spoke → hub peering, in the
Azure portal:
• Hub VNet: Automatically set to Use this virtual network's gateway
• Spoke VNet: Automatically set to Use remote virtual network's gateway in the spoke VNet that is
managed by the Cloud APIC
In order to have the route propagation enabled for the egress route table of the spoke VNet, you must configure
a contract between the cloud EPG in the spoke VNet and the external EPG connecting to the non-ACI remote
site.
The following figure shows an example of this type of deployment.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
252
Express Route Gateway
Deploying Express Route Gateway Without Redirect
In this example:
• The following configurations are done automatically by the Cloud APIC:
• The spoke VNet uses VNet peering with gateway transit (transit peering)
• The VPN gateway in the hub VNet is connected to an on-premises non-ACI remote site
• When the Cloud APIC detects that the express route gateway is deployed in the hub VNet, the transit
peering properties are automatically set on each side of the peering (hub → spoke and spoke →
hub):
• Hub VNet: Automatically set to Use this virtual network's gateway
• Spoke VNet: Automatically set to Use remote virtual network's gateway in the spoke VNet
that is managed by the Cloud APIC
• The on-premises non-ACI routes learned by the VPN gateway are available to the spoke VNet if the
EPG in the spoke VNet has a contract with the external EPG
• The hub VNet allows traffic from the EPG in the spoke VNet destined to the on-premises non-ACI remote
site through the VPN gateway
Deploying Express Route Gateway Without Redirect
Before you begin
Review the information provided in About Deploying Express Route Gateway Without Redirect, on page 252
before proceeding with these procedures.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
253
Express Route Gateway
Deploying Express Route Gateway Without Redirect
Step 1
Enable VNet peering on your Cloud APIC.
Refer to Configuring VNET Peering for Cloud APIC for Azure for those instructions.
The gateway subnet in the hub VNet that is required for the express route gateway is deployed by the Cloud APIC when
VNet peering is enabled. This is done to prepare the hub VNet for the deployment of the express route gateway.
Step 2
Create an external EPG in the hub VNet that represents the network for the non-ACI remote site.
• To create an external EPG using the GUI, see Creating an External EPG Using the Cisco Cloud APIC GUI, on page
59.
In the Route Reachability field for the external EPG, select External-Site.
• To create an external EPG using the REST API, see Creating an External Cloud EPG Using the REST API, on page
125.
Create an external cloud EPG with the type site-external.
Step 3
Through the Azure portal, deploy the express route gateway in the hub VNet using the gateway subnet that you configured
in Step 1, on page 254.
Depending on the number of regions that you selected when you enabled VNet peering in Step 1, on page 254, if you
need express route gateway access on multiple regions that the Cloud APIC will manage, deploy express route gateways
in each of those regions separately.
a) In the Azure portal, navigate to the Resource Manager virtual network where you want to create a virtual network
gateway.
b) On the left side, select Create a resource, and type Virtual Network Gateway in search.
c) Locate Virtual network gateway in the search return and click the entry.
d) On the Virtual network gateway page, choose Create.
e) On the Create virtual network gateway page, enter the appropriate information for these fields:
• Subscription: Verify that the correct subscription is selected.
• Resource Group: The resource group will automatically be chosen once you choose the virtual network.
• Name: The name of your express route gateway.
• Region: Change the Region field to point to the location where your virtual network is located. If the location
isn't pointing to the region where your virtual network is, the virtual network won't appear in the Choose a
virtual network dropdown.
• Gateway type: Choose ExpressRoute.
• SKU: Choose the gateway SKU from the dropdown.
• Virtual network: Choose the virtual network that was created by the Cloud APIC in Step 1, on page 254.
• Public IP address: Choose Create new.
• Public IP address name: Provide a name for the public IP address.
f) Select Review + Create, and then Create to begin creating the gateway.
The settings are validated and the gateway deploys. Creating virtual network gateway can take up to 45 minutes to
complete.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
254
Express Route Gateway
Deploying Express Route Gateway Without Redirect
To verify that the express route gateway was deployed successfully, navigate to the network gateways page in the
Azure portal and verify that a network gateway with the type express route was created.
If you need express route gateway access on additional regions, repeat these steps for each of those regions.
Step 4
Configure a contract between the cloud EPG and the external EPG connected by the express route gateway.
• To create a contract using the GUI, see Creating a Contract Using the Cisco Cloud APIC GUI, on page 77.
• To configure a contract using the REST API, see Creating a Contract Using the REST API, on page 121.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
255
Express Route Gateway
Deploying Express Route Gateway Without Redirect
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
256
APPENDIX
A
Cisco Cloud APIC Error Codes
• Cisco Cloud APIC Error Codes, on page 257
Cisco Cloud APIC Error Codes
This section describes the Cisco Cloud APIC error codes.
Table 41: Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_INFRANETWORK_COUNT
The count of
cloudtemplateInfraNetwork
MO is at most 1
cloud-template
CT_INFRANETWORK_VRF
In the
cloudtemplateInfraNetwork
MO, the vrfName must be
overlay-1
cloud-template
CT_INFRANETWORK_PARENT
For the
cloudtemplateInfraNetworkMO,
the parent MO must be
uni/tn-infra
cloud-template
CT_INFRANETWORK_NUMROUTERSPERREGION_MINIMUM In the
cloudtemplateInfraNetwork
MO, for the attribute
numRoutersPerRegion,
the
minimum allowed value is 2
cloud-template
CT_INFRANETWORK_NUMROUTERSPERREGION_MAXIMUM In the
cloudtemplateInfraNetwork
MO, for the attribute
numRoutersPerRegion,
the
maximum allowed value is 4
cloud-template
CT_INTNETWORK_COUNT
The count of
cloudtemplateIntNetwork MO
is at most 1
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
257
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_EXTNETWORK_COUNT
The count of
cloudtemplateExtNetwork MO
is at most 1
cloud-template
CT_VPNNETWORK_COUNT
The count of
cloudtemplateVpnNetwork MO
is at most 1
cloud-template
CT_OSPF_COUNT
The count of
cloudtemplateOspf
MO is at
most 1
cloud-template
CT_INTNETWORK_REGION_MATCH
The regions specified by
cloudRegionName under
cloudtemplateIntNetwork must
have a corresponding
cloudRegion under cloudProvP
cloud-template
CT_INTNETWORK_REGION_MANAGED
The regions specified by the
cloudRegionName children of
cloudtemplateIntNetwork must
have corresponding
cloudRegion with adminSt as
managed
cloud-template
CT_INTNETWORK_REGION_MAXIMUM
The maximum number of
regions (cloudRegionName)
specified under
cloudtemplateIntNetwork
cloud-template
CT_EXTNETWORK_REGION_SUBSET
is 4
The regions specified by the
cloudRegionName children of
cloudtemplateExtNetwork must
also be specified by
cloudRegionName children under
cloudtemplateIntNetwork
cloud-template
CT_EXTNETWORK_REQUIRES_EXTSUBNETPOOL
The presence of
cloudtemplateExtNetwork
requires presence of
cloudtemplateExtSubnetPool
cloud-template
CT_EXTSUBNETPOOL_COUNT
The count of
cloudtemplateExtSubnetPool
is at most 1
cloud-template
CT_EXTSUBNETPOOL_SUBNETPOOL_ADDRESS
In
cloudtemplateExtSubnetPool,
the subnetpool must contain a
network address.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
258
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_EXTSUBNETPOOL_SUBNETPOOL_IP_VERSION
In
cloudtemplateExtSubnetPool,
the subnetpool must contain an
IPv4 address.
cloud-template
CT_EXTSUBNETPOOL_SUBNETPOOL_ADDRESS_TYPE
In
cloudtemplateExtSubnetPool,
the subnetpool IP address must
not from multicast or loopback
address space
cloud-template
CT_EXTSUBNETPOOL_SUBNETPOOL_MINIMUM_SIZE
In
cloudtemplateExtSubnetPool,
the subnetpool must be at least
/22 (i.e. the netmask must be 22
or less).
cloud-template
CT_EXTSUBNETPOOL_AND_REMOTESITE
The
cloudtemplateExtSubnetPool
needs to be big enough to have
at least one
cloudtemplateRemoteSiteSubnetPool
for each
cloudtemplateRemoteSite.
cloud-template
CT_INTNETWORK_MISSING_HOME
If there are any
cloudRegionName under
cloudtemplateIntNetwork, then
one of the cloudRegonName must
be associated to a region that is
the home region of the cAPIC
(capicDeployed).
cloud-template
CT_CLOUD_APICSUBNETPOOL_INSUFFICIENT
There must be enough
cloudApicSubnetPool MOs to
generate cloudApicSubnet MOs
so that all the cloudRegionName
MOs specified under
can
be associated to a unique
cloudApicSubnet MO. The
subnets from the
cloudApicSubnet MOs are used
as the CIDRs in the
cloudCtxProfile of the
corresponding region.
cloudtemplateIntNetwork
cloud-template
CT_IPSECTUNNEL_PEERADDR_IP_VERSION
In cloudtemplateIpSecTunnel,
the peeraddr must contain a IPv4
address.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
259
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_IPSECTUNNEL_PEERADDR_IS_HOST
In cloudtemplateIpSecTunnel,
the peeraddr must be host
address (i.e. /32)
cloud-template
CT_PROFILE_COUNT
The count of
cloudtemplateProfile
MO is
at most 1
cloud-template
CT_PROFILE_DELETE
The cloudtemplateProfile MO
cannot be deleted unless its
parent
cloudtemplateInfraNetwork is
also deleted.
cloud-template
CT_AZURE_PROFILE_ROUTERUSERNAME_INVALID
In Azure, some usernames are
not valid (admin, root, ...) and
must not end with a period.
cloud-template
CT_AZURE_PROFILE_ROUTERUSERNAME_TOO_LONG
In Azure, username is restricted
to max 20 characters.
cloud-template
CT_PROFILE_ROUTERUSERNAME_NONEMPTY
In cloudtemplateProfile, the
routerUsername must be
non-empty.
cloud-template
CT_PROFILE_ROUTERPASSWORD_NONEMPTY
In cloudtemplateProfile, the
routerLicenseToken must not
contain invalid charactors.
cloud-template
CT_PROFILE_ROUTERTHROUGHPUT_MODIFY
In cloudtemplateProfile, the
routerThroughput cannot be
modified when there are routers
deployed in any region, i.e. any
cloudRegionName under
cloudtemplateIntNetwork.
(The modofication is allowed
when there are no router
deployments in any region.)
cloud-template
CT_PROFILE_ROUTERLICENSETOKEN_INVALID_CHARACTER In cloudtemplateProfile, the
routerPassword must be
non-empty.
cloud-template
CT_APICSUBNET_INVALID_HOME_REGION
In a cloudApicSubnet MO, the
region marked for
capicDeployed must be a valid
region
cloud-template
CT_APICSUBNET_REPEATED_REGION
In a cloudApicSubnet MO, a
region can be associated with at
most 1 subnet
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
260
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_APICSUBNET_MULTIPLE_HOME_REGION
In cloudApicSubnet MOs, at
most 1 region may have
capicDeployed as true.
cloud-template
CT_HUBNETWORK_COUNT
The count of
cloudtemplateHubNetwork MO
is at most 1
cloud
CLOUD_APICSUBNETPOOL_CREATEDBY_USER
In cloudApicSubnetPool, the
createdBy attribute must be
USER
cloud
CLOUD_APICSUBNETPOOL_SUBNET_IP_VERSION
In cloudApicSubnetPool, the
subnet must contain a IPv4
address.
cloud
CLOUD_APICSUBNETPOOL_SUBNET_SIZE
In cloudApicSubnetPool, the
subnet must be /24.
cloud
CLOUD_APICSUBNETPOOL_DELETE_USAGE
A cloudApicSubnetPool cannot
be deleted if at least one of its
cloudApicSubnet child is in use
by a region.
cloud
CLOUD_APICSUBNETPOOL_DELETE_CREATEDBY
A cloudApicSubnetPool whose
createdBy attribute is not USER
cannot be deleted.
cloud
CLOUD_AZURE_CTXPROFILE_SUBNET_RENAME
cloudSubnet
name cannot be
modified
cloud
CLOUD_AZURE_CTXPROFILE_SUBNET_DUPLICATE
Two cloudSubnet in the same
cloudCtxProfile cannot have
the same name
cloud
CLOUD_CAPIC_IP_EXT_EPG_SELECTOR_MAXIMUM
There can be maximum 1
cloudExtEpSelector in the
cloudExtEPg corresponding to
Cloud APIC IP
cloud
CLOUD_AZURE_ACCOUNT_IN_USE
The association between the
account and the tenant cannot be
updated or deleted while the
account is in use and context
profiles are deployed
cloud
CLOUD_AZURE_INFRA_ACCOUNT_CHANGE
The account for the tenant infra
cannot be modified or deleted
cloud
CLOUD_SOURCE_PORT_NOT_SUPPORTED
Source port range is not allowed
on Cloud APIC
cloud
CLOUD_ONLY_PERMIT_ACTION_SUPPORTED
Actions different from 'permit'
are not supported on Cloud
APIC
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
261
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud
CLOUD_CIDR_OVERLAP
The subnets of cloudCidrs
cannot overlap
cloud
CLOUD_SUBNET_USAGE
There can be at most 1 gateway
subnet for a given zone and each
user subnet should have exactly
1 gateway subnet in the same
user subnet's zone
cloud
CLOUD_AZURE_ACCOUNT_CRED_CROSS_TENANT
The cloudCredentials used by
the cloudAccount must be in the
same tenant
cloud
CLOUD_AZURE_ACCOUNT_AD_CROSS_TENANT
The cloudAd used by the
cloudAccount must be in the
same tenant
cloud-template
CT_CLOUD_APICSUBNETPOOL_INSUFFICIENT_HUBNETWORK There must be enough
cloudApicSubnetPool MOs to
generate cloudApicSubnet MOs
so that all the cloudRegionName
MOs specified under
can
be associated to a unique
cloudApicSubnet MO. The
subnets from the
cloudApicSubnet MOs are used
as the CIDRs in the
cloudCtxProfile of the
corresponding region. With
HubNetworking enabled, there
must be as many
cloudApicSubnetPool as the
cloudRegionName under
cloudtemplateIntNetwork.
cloudtemplateIntNetwork
cloud
CLOUD_SYSTEM_MO_IS_IMMUTABLE
Instances created by the system
are immutable
cloud-template
CT_BGPEVPN_PEERADDR_IP_VERSION
In cloudtemplateBgpEvpn, the
peeraddr must contain a IPv4
address.
cloud-template
CT_BGPEVPN_PEERADDR_ADDRESS_TYPE
In cloudtemplateBgpEvpn, the
peeraddr IP address must be a
host address
cloud
CLOUD_APICSUBNETPOOL_SUBNET_HOST_PART
In cloudApicSubnetPool subnet,
the host part must be 0.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
262
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Component
Error Code
Constraint
cloud-template
CT_EXTSUBNETPOOL_CLOUD_APICSUBNETPOOL_OVERLAP There is a subnet overlap
between
cloudtemplateExtSubnetPool
and cloudApicSubnetPool.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
263
Cisco Cloud APIC Error Codes
Cisco Cloud APIC Error Codes
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
264
APPENDIX
B
Service EPG Configuration Examples
For more information on service EPGs, see:
• Cloud Service Endpoint Groups, on page 27
• Creating a Service EPG Using the Cisco Cloud APIC GUI, on page 66
• Creating a Service EPG Using the REST API, on page 126
The following sections provide configuration examples for service EPGs.
• Azure Kubernetes Services (AKS) Service EPG Configuration Example, on page 265
Azure Kubernetes Services (AKS) Service EPG Configuration
Example
This section provides procedures for configuring an example service EPG with the following settings:
• Service Type: Azure Kubernetes Services (AKS)
• Azure Kubernetes Services (AKS) requires access to other services.
• Cisco Cloud APIC automates the programming of the rules listed here:
https://docs.microsoft.com/en-us/azure/aks/
limit-egress-traffic#required-outbound-network-rules-and-fqdns-for-aks-clusters
• Deployment type: Cloud Native Managed. In this type of deployment, the service is instantiated in your
VNet or subnet (created through the Cisco Cloud APIC). For example, an Azure Kubernetes Services
(AKS) service could be deployed in a subnet that is managed by the Cisco Cloud APIC.
• Access type: Private
The procedures to configure this example service EPG for AKS are provided in the following sections.
Creating a Subnet in the Cloud Context Profile
These procedures describe how to create a subnet in a cloud context profile to be used by the Azure Kubernetes
Services (AKS) service EPG. You will be making configurations through the Cisco Cloud APIC GUI in these
procedures.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
265
Service EPG Configuration Examples
Service EPG Configuration Examples
Before you begin
• In one browser window, log into your Cisco Cloud APIC GUI.
• In another browser window, log into your Azure account for the Cisco Cloud APIC infra tenant and go
to the Azure management portal:
https://portal.azure.com/#home
Step 1
In the Cisco Cloud APIC GUI, click the Intent icon.
The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create Cloud Context Profile.
The Create Cloud Context Profile window appears.
Step 4
Enter the following information in the Create Cloud Context Profile window.
• Name: Enter the name of the cloud context profile. For example, ct_ctxprofile_eastus.
• Tenant: Click Select Tenant, choose a tenant for the cloud context profile for this use case, then click Select.
• Region: Click Select Region, choose the region (for example, eastus), then click Select.
• VRF: Click Select VRF, select the appropriate VRF, then click Select.
• Add CIDR: Enter the CIDR information.
a. Click Add CIDR.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
266
Service EPG Configuration Examples
Creating the Cloud Service EPG for AKS
b. Enter the address in the CIDR Block Range field.
For example, 30.1.0.0/16.
c. Uncheck (disable) the Primary check box.
d. Click Add Subnet and enter the subnet address in the Address field.
For example, 30.1.0.0/17. Note that AKS cluster requires 338 addresses.
e. Click Add.
• VNet Gateway Router: Leave the box unchecked (unselected) for this field.
• VNet Peering: Check this box to enable VNet peering.
Step 5
Click Save when finished.
What to do next
Go to Creating the Cloud Service EPG for AKS, on page 267.
Creating the Cloud Service EPG for AKS
These procedures describe how to create the cloud service EPG with the Azure Kubernetes Services (AKS)
service type. You will be making configurations through the Cisco Cloud APIC GUI in these procedures.
Before you begin
Complete the procedures in Creating a Subnet in the Cloud Context Profile, on page 265 before proceeding
with these procedures.
Step 1
In the Cisco Cloud APIC GUI, click the Intent icon.
The Intent menu appears.
Step 2
Click the drop-down arrow below the Intent search box and choose Application Management.
A list of Application Management options appear in the Intent menu.
Step 3
From the Application Management list in the Intent menu, click Create EPG.
The Create EPG window appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
267
Service EPG Configuration Examples
Service EPG Configuration Examples
Step 4
Enter the following information in the Create EPG window.
• Name: Enter the name of the cloud service EPG. For example, svc-Hub-AzureAKS.
• Tenant: Click Select Tenant, choose a tenant for the cloud service EPG for this use case, then click Select.
• Application Profile: Click Select Application Profile, choose the application profile, then click Select.
• Type: Choose Service as the EPG type.
• VRF: Click Select VRF, select the appropriate VRF, then click Select.
• Service Type : Choose the Azure Kubernetes Services (AKS) service type.
• Deployment Type: Choose the Cloud Native Managed deployment type.
• Access Type: Choose the Private access type.
Step 5
Click Add Endpoint Selector.
The Add Endpoint Selector window appears.
For this use case, we will be creating an endpoint selector where the IP address matches the subnet information configured
in the previous step, 30.1.0.0/17. Having the IP address in the endpoint selector match the subnet in the previous step
allows the Cisco Cloud APIC to program the NSG to allow all of the required rules for this service type.
Step 6
In the Add Endpoint Selector window, enter a name in the Name field.
Step 7
Click the Key drop-down list to choose a key.
At this time, IP is the only option available as a key for this access type.
Step 8
Click the Operator drop-down list and choose equals.
Step 9
In the Value field, enter 30.1.0.0/17, then click the check mark to validate the entry.
Step 10
Click Add.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
268
Service EPG Configuration Examples
Verifying the Outbound Security Rules
Step 11
Click Save when finished.
What to do next
Go to Verifying the Outbound Security Rules, on page 269.
Verifying the Outbound Security Rules
These procedures describe how to verify that the necessary outbound security rules are getting configured
correctly. The Cisco Cloud APIC configures all of the outbound security rules in Azure that are needed for
AKS to be deployed in the Azure portal.
Before you begin
Complete the procedures in Creating the Cloud Service EPG for AKS, on page 267 before proceeding with
these procedures.
Step 1
In the Azure portal, navigate to the network security group for the subnet that was automatically created:
a) Navigate to appropriate resource group.
b) Select the subnet that was used for the AKS service EPG.
c) Locate the necessary outbound security group.
Step 2
Locate the Outbound security rules area in the page and verify that the outbound security rules for the NSG are configured
correctly.
For more information on the outbound security rules, see:
https://docs.microsoft.com/en-us/azure/aks/limit-egress-traffic
What to do next
Go to Creating a Kubernetes Service, on page 269.
Creating a Kubernetes Service
These procedures describes how to create a Kubernetes service. You will be making configurations through
the Azure portal in these procedures.
Note
The following procedure describes how to create a Kubernetes service through the Azure portal. An alternative
method for creating a Kubernetes service is also provided in the Using Azure Kubernetes Service with Cisco
Cloud APIC document.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
269
Service EPG Configuration Examples
Service EPG Configuration Examples
Before you begin
Complete the procedures in Verifying the Outbound Security Rules, on page 269 before proceeding with these
procedures.
Step 1
In the Azure portal, search for the term Kubernetes
Service by Microsoft
and click on the search result.
The Kubernetes Service page appears.
Step 2
Click Create in the Kubernetes Service page.
The Create Kubernetes cluster page appears.
Step 3
In the Basics tab, configure the following areas:
• Subscription: Select the appropriate subscription.
• Resource Group: Select the appropriate resource group.
• Kubernetes cluster name: Enter a unique name for this Kubernetes cluster.
• Region: Select the appropriate region.
• Kubernetes version: Leave the default selection as-is.
• Node size: Leave the default selection as-is.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
270
Service EPG Configuration Examples
Service EPG Configuration Examples
• Node count: Verify that the scroll bar is all the way to the left so that the entry for this field is 1.
Step 4
Click Next: Node pools. Leave the default entries as-is and click Next: Authentication to advance to the Authentication
tab.
Step 5
In the Authentication tab, configure the following areas:
• Authentication method: Choose Service principal.
The Service principal field appears.
• Service principal: Click Configure service principal.
In the Configure service principal window, configure the following areas:
• Service principal: Choose either Create new or Use existing.
If you choose Use existing, enter the following information for the existing service principal:
• Service principal client ID
• Service principal client secret
Note
Make a note of the entries that you enter in these two fields. You will be using the entries in these fields
later in these procedures.
Click OK to return to the Authentication tab in the Create Kubernetes cluster window.
• Role-based acces control (RBAC): Choose Enabled.
• AKS-managed Azure Active Directory: Choose Disabled.
• Encryption type: Leave the default selection as-is.
Step 6
Click Next: Networking to advance to the Networking tab.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
271
Service EPG Configuration Examples
Service EPG Configuration Examples
Step 7
In the Networking tab, configure the following areas:
• Network configuration: Choose Azure CNI.
• Virtual network: Choose the corresponding virtual network.
• Cluster subnet: Choose the Cisco Cloud APIC-managed subnet.
• Kubernetes service address range: Leave the default selection as-is, or change the entry, if necessary.
• Kubernetes DNS service IP address: Leave the default selection as-is, or change the entry, if necessary.
• Docker Bridge address: Leave the default selection as-is, or change the entry, if necessary.
• DNS name prefix: Leave the default selection as-is, or change the entry, if necessary.
• Load balancer: Standard
• Enable HTTP application routing: Leave the default selection as-is (not enabled), or change the entry, if necessary.
• Enable Private cluster: Leave the default selection as-is (not enabled), or change the entry, if necessary.
Step 8
Click Next: Integration, then Next: Tags, to advance through those screens without changing any of the default entries,
then click Next: Review+Create.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
272
Service EPG Configuration Examples
Verifying the New Kubernetes Service
Step 9
In the Review+Create window, click Create, then click Create again after the validations pass to create the Kubernetes
cluster.
You will see the message Deployment
is in progress and the Overview screen for the Kubernetes service will appear.
Wait until the Kubernetes service is deployed successfully before proceeding (the amount of time it takes to deploy
varies). Once this process is completed, the main AKS service will be in your original resource group. Azure will also
create an additional resource group specifically for the Kubernetes service, with all of the agentpools VM scales set.
What to do next
Go to Verifying the New Kubernetes Service, on page 273.
Verifying the New Kubernetes Service
These procedures describe how to verify that the new Kubernetes service is in the resource group that was
created specifically for the Kubernetes service.
Before you begin
Complete the procedures in Creating a Kubernetes Service, on page 269 before proceeding with these procedures.
Step 1
In the Azure portal, click on Resource groups in the left nav bar to navigate to the resource groups page.
Step 2
In the Resource groups page, locate the resource group that was created specifically for the Kubernetes service and click
the link for that resource group.
The resource group created specifically for the Kubernetes service will have the following format:
MC_resourcegroupname_clustername_region
Where:
• resourcegroupname is the name of the resource group created specifically for the Kubernetes service (MC_aks is the
resource group name used by default by Azure)
• clustername is the Kubernetes cluster name that you provided in Step 3, on page 270 in Creating a Kubernetes Service,
on page 269.
• region is the region that you selected in Step 3, on page 270 in Creating a Kubernetes Service, on page 269.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
273
Service EPG Configuration Examples
Service EPG Configuration Examples
For example:
MC_aks_acme-aks-cluster_centralus
The Overview page for the Kubernetes service resource group appears.
Step 3
Locate the line for the Virtual machine scale set and click on that link.
This is where the AKS agent is running.
Step 4
In the left nav bar, click on Instances to display the virtual machine instances for this Kubernetes service resource group.
Step 5
Click on any of the three instances in this window, then verify that the IP address shown in the Private IP address field
matches your hub subnet IP address.
All three instances shown in this window should have an IP address from the subnet that you selected in Step 7, on page
272 in Creating a Kubernetes Service, on page 269.
Step 6
Navigate back to the Overview page for the Kubernetes service resource group, then locate the kubernetes entry, shown
with Load balancer as the Type, and click that link.
The Overview page for the Kubernetes load balancer appears.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
274
Service EPG Configuration Examples
Installing the Azure and AKS CLI
Step 7
In the left nav bar, click Backend pools to view the AKS agents.
Step 8
If a virtual machine was created as part of the process of configuring the contract (for example, if a virtual machine was
created for the consumer), and if you have AKS as the provider, verify that the rules were configured correctly.
a) In the Azure portal, navigate back to the infra resource group.
b) Choose Group by type for the records shown in the Overview page for the infra resource group.
c) Scroll down until you see the Virtual machine area and click on the virtual machine for the consumer in your contract.
The Overview window for that virtual machine appears.
d) In the left nav bar, under Settings, click Networking.
The Networking window for that virtual machine appears, with information on the inbound and outbound port rules.
e) Click on the Outbound port rules tab, then click on one of the outbound port rules listed in the table.
A window slides in from the right, displaying additional information on these outbound port rules. For example, the
entry in the Destination IP addresses/CIDR ranges area provides information on the addresses that are associated
with the AKS cluster.
What to do next
Go to Installing the Azure and AKS CLI, on page 275.
Installing the Azure and AKS CLI
These procedures describe how to install the Azure and AKS CLI.
Before you begin
Complete the procedures in Verifying the New Kubernetes Service, on page 273 before proceeding with these
procedures.
Step 1
On the consumer VM that has internet access, install the Azure CLI.
For more information, see:
https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-linux
For example, to install the Azure CLI in an Ubuntu Linux VM in Azure:
# curl -sL https://aka.ms/InstallAzureCliDeb | sudo bash
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
275
Service EPG Configuration Examples
Service EPG Configuration Examples
Step 2
Download and install kubectl, the Kubernetes command-line tool, and kubelogin, a client-go credential (exec) plugin
implementing azure authentication:
# az aks install-cli
Step 3
Log in with the service principle information that you entered in Step 5, on page 271 in Creating a Kubernetes Service,
on page 269 in these procedures:
# az login --service-principal --username <service_principal_client_id>
--password '<service_principal_client_secret>' --tenant <tenant_ID>
Where:
• <service_principal_client_id> is the entry from the Service principal client ID field in Step 5, on page 271 in
Creating a Kubernetes Service, on page 269.
• <service_principal_client_secret> is the entry from the Service principal client secret field in Step 5, on page 271
in Creating a Kubernetes Service, on page 269.
• <tenant_ID> is the tenant associated with the service principal (the Azure Active Directory tenant ID). To locate
the tenant ID information for this command:
a. Sign in to the Azure portal.
b. Select Azure Active Directory.
c. Select Properties.
d. Scroll down to the Tenant ID field. Your tenant ID is displayed in the box.
For more information, see:
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant
For example:
# az login --service-principal --username 12a3b456-7c89-1234-5de6-7f89012gh3i4
--password 'secretkey12341234!' --tenant 98765zy4-xwv-3ut2-1uts-rq0pon98m765
Step 4
Set a subscription to be the current active subscription.
# az account set --subscription <AKS_rg_subscription_ID>
Where <AKS_rg_subscription_ID> is the subscription ID of the resource group that Azure created for the Kubernetes
service in Verifying the New Kubernetes Service, on page 273.
For example:
# az account set --subscription 56klm789n-o0p1-234q-5r6s-7t890123u4v5
Step 5
From the consumer VM, enter the following to log in and connect to AKS.
root@hub-vm:/home/capic# az aks get-credentials --resource-group <resource_group> --name
<AKS_cluster_name> --admin
Where:
• <resource_group> is the name of the infra resource group
• <AKS_cluster_name> is the name for the Kubernetes cluster that was entered in Step 3, on page 270 in Creating a
Kubernetes Service, on page 269
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
276
Service EPG Configuration Examples
Service EPG Configuration Examples
For example:
root@hub-vm:/home/capic# az aks get-credentials --resource-group capic_infra_westus --name azureaksclus
--admin
A message similar to the following appears:
Merged "azureaksclus-admin" as current context in /root/.kube/config
Step 6
Check the internal IP addresses of each of the nodes.
root@hub-vm:/home/capic# kubectl get nodes -o wide
Output similar to the following appears:
The IP addresses listed in the INTERNAL-IP column are in your hub subnet.
Note
Step 7
In the example output above, the entries in the EXTERNAL-IP column are shown as <none> because the Access
Type was set to Private in Step 4, on page 268 in Creating the Cloud Service EPG for AKS, on page 267. IP
addresses would be displayed in the EXTERNAL-IP column if the Access Type is set to Public and Private.
(Optional) Assign an admin role to a new user, if necessary.
a) In the Azure portal, navigate back to the infra resource group.
b) In the records area in the page, scroll down until you find the Kubernetes service entries.
c) Click on the Kubernetes service that you configured.
The Overview page for that Kubernetes service is displayed.
d) In the left nav bar, click on Access Control (IAM).
The Access Control (IAM) for that Kubernetes service is displayed.
e) Click + Add, then select Add role assignment from the drop-down menu.
f) In the Add role assignment page, make the following selections:
• In the Role field, select Azure Kubernetes Service Cluster Admin Role from the drop-down menu.
• In the Assign access to field, select User, group, or service principal.
• Select the appropriate key.
g) Click Save at the bottom of the screen.
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
277
Service EPG Configuration Examples
Service EPG Configuration Examples
Cisco Cloud APIC for Azure User Guide, Release 5.2(x)
278

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project