null  null
Cisco APIC Basic Configuration Guide, Release 2.x
First Published: 2016-06-29
Last Modified: 2017-05-19
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.
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: http://
www.cisco.com/go/trademarks. 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. (1110R)
© 2016-2017
Cisco Systems, Inc. All rights reserved.
CONTENTS
Preface
Preface xi
Audience xi
Document Conventions xi
Related Documentation xiii
Documentation Feedback xiv
Obtaining Documentation and Submitting a Service Request xiv
CHAPTER 1
New and Changed Information 1
New and Changed Information 1
CHAPTER 2
About Cisco ACI/APIC Interfaces 5
About ACI/APIC Interfaces 5
CHAPTER 3
User Access, Authentication, and Accounting 7
Access Rights Workflow Dependencies 7
User Access, Authorization, and Accounting 8
Multiple Tenant Support 8
User Access: Roles, Privileges, and Security Domains 8
Configuring a Local User 9
Configuring a Local User Using the GUI 9
Configuring SSH Public Key Authentication Using the GUI 10
Configuring a Local User Using the NX-OS Style CLI 11
Configuring a Local User Using the REST API 12
Configuring a Remote User 12
AV Pair on the External Authentication Server 12
Best Practice for Assigning AV Pairs 13
Configuring an AV Pair on the External Authentication Server 13
Cisco APIC Basic Configuration Guide, Release 2.x
iii
Contents
Configuring APIC for TACACS+ Access 14
Configuring APIC for RADIUS Access 15
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+ Access to
the APIC 16
Configuring Windows Server 2008 LDAP for APIC Access 17
Configuring APIC for LDAP Access 19
Changing the Default Behavior for Remote Users with Missing or Bad Cisco AV Pairs 20
Changing Default Behavior for Remote Users with Missing or Bad Cisco AV Pairs Using the
NX-OS Style CLI 20
About Signature-Based Transactions 21
Guidelines and Limitations 21
Generating an X.509 Certificate and a Private Key 22
Configuring a Local User 23
Creating a Local User and Adding a User Certificate Using the GUI 23
Creating a Local User and Adding a User Certificate Using the REST API 24
Creating a Local User Using Python SDK 25
Using a Private Key to Calculate a Signature 27
Accounting 28
Routed Connectivity to External Networks as a Shared Service Billing and Statistics 29
CHAPTER 4
Management 31
Management Workflows 31
ACI Management Access Workflows 31
Adding Management Access 33
Adding Management Access in the GUI 33
IPv4/IPv6 Addresses and In-Band Policies 34
IPv4/IPv6 Addresses in Out-of-Band Policies 34
IPv6 Table Modifications to Mirror the Existing IP Tables Functionality 34
Configuring In-Band Management Access Using the Basic GUI 35
Configuring In-Band Management Access Using the Advanced GUI 36
Configuring In-Band Management Access Using the NX-OS Style CLI 39
Configuring In-Band Management Access Using the REST API 40
Configuring Out-of-Band Management Access Using the Basic GUI 43
Configuring Out-of-Band Management Access Using the Advanced GUI 43
Configuring Out-of-Band Management Access Using the NX-OS Style CLI 45
Cisco APIC Basic Configuration Guide, Release 2.x
iv
Contents
Configuring Out-of-Band Management Access Using the REST API 45
Exporting Tech Support, Statistics, and Core Files 47
About Exporting Files 47
File Export Guidelines and Restrictions 47
Creating a Remote Location for Exporting Files 48
Sending an On-Demand Techsupport File Using the GUI 48
Sending an On-Demand Techsupport File Using the NX-OS Style CLI 49
Sending an On-Demand TechSupport File Using the REST API 50
Overview 50
Configuration File Encryption 51
Configuring a Remote Location Using the GUI 52
Configuring a Remote Location Using the NX-OS Style CLI 52
Configuring a Remote Location Using the REST API 53
Configuring an Export Policy Using the GUI 54
Configuring an Export Policy Using the NX-OS Style CLI 54
Configuring an Export Policy Using the REST API 55
Configuring an Import Policy Using the GUI 56
Configuring an Import Policy Using the NX-OS Style CLI 56
Configuring an Import Policy Using the REST API 57
Encrypting Configuration Files Using the GUI 58
Encrypting Configuration Files Using the NX-OS Style CLI 60
Encrypting Configuration Files Using the REST API 60
Backing up, Restoring, and Rolling Back Controller Configuration 61
Backing Up, Restoring, and Rolling Back Configuration Files Workflow 61
About the fileRemotePath Object 62
Configuration Export to Controller 62
Configuration Import to Controller 64
Snapshots 67
Snapshot Manager Policy 67
Rollback 68
Using Syslog 70
About Syslog 70
Creating a Syslog Destination and Destination Group 71
Creating a Syslog Source 72
Enabling Syslog to Display in NX-OS CLI Format, Using the REST API 73
Cisco APIC Basic Configuration Guide, Release 2.x
v
Contents
Using Atomic Counters 74
About Atomic Counters 74
Atomic Counters Guidelines and Restrictions 75
Configuring Atomic Counters 76
Using SNMP 77
About SNMP 77
SNMP Access Support in ACI 77
Configuring SNMP 77
Configuring the SNMP Policy Using the GUI 77
Configuring an SNMP Trap Destination Using the GUI 79
Configuring an SNMP Trap Source Using the GUI 80
Monitoring the System Using SNMP 80
Using SPAN 81
About SPAN 81
SPAN Guidelines and Restrictions 81
Configuring a SPAN Session 81
Using Traceroute 82
About Traceroute 82
Traceroute Guidelines and Restrictions 82
Performing a Traceroute Between Endpoints 83
CHAPTER 5
Provisioning Core ACI Fabric Services 85
Time Synchronization and NTP 85
In-Band and Out-of-Band Management NTP 86
NTP over IPv6 86
Configuring NTP Using the Basic GUI 86
Configuring NTP Using the Advanced GUI 87
Configuring NTP Using the NX-OS Style CLI 88
Configuring NTP Using the REST API 90
Verifying NTP Operation Using the GUI 91
Verifying NTP Policy Deployed to Each Node Using the NX-OS Style CLI 91
Configuring a DHCP Relay Policy 91
Configuring a DHCP Server Policy for the APIC Infrastructure Using the GUI 92
Configuring a DHCP Server Policy for the APIC Infrastructure Using the NX-OS Style
CLI 93
Cisco APIC Basic Configuration Guide, Release 2.x
vi
Contents
Configuring a DHCP Server Policy for the APIC Infrastructure Using the REST API 93
Configuring a DNS Service Policy 94
Configuring External Destinations with an In-Band DNS Service Policy 94
Dual Stack IPv4 and IPv6 DNS Servers 96
Dual-Stack IPv4 and IPv6 Environment 96
Policy for Priority of IPv4 or IPv6 in a DNS Profile 96
Configuring a DNS Service Policy to Connect with DNS Providers Using the Basic GUI 97
Configuring a DNS Service Policy to Connect with DNS Providers Using the Advanced
GUI 98
Configuring a DNS Service Policy to Connect with DNS Providers Using the NX-OS Style
CLI 99
Configuring a DNS Service Policy to Connect with DNS Providers Using the REST API 99
Verifying that the DNS Profile is Configured and Applied to the Fabric Controller Switches
Using the NX-OS Style CLI 100
Configuring Custom Certificate Guidelines 101
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI 101
CHAPTER 6
Basic User Tenant Configuration 105
Tenants 105
Routing Within the Tenant 106
Layer 3 VNIDs Facilitate Transporting Inter-subnet Tenant Traffic 107
Router Peering and Route Distribution 109
Bridged Interface to an External Router 110
Configuring Route Reflectors 110
Configuring External Connectivity for Tenants 111
Configuring an MP-BGP Route Reflector Using the Basic GUI 111
Configuring an MP-BGP Route Reflector Using the Advanced GUI 111
Configuring an MP-BGP Route Reflector for the ACI Fabric 112
Configuring an MP-BGP Route Reflector Using the REST API 112
Verifying the MP-BGP Route Reflector Configuration 113
Creating OSPF External Routed Network for Management Tenant Using Basic
GUI 114
Creating an OSPF External Routed Network for Management Tenant Using the
Advanced GUI 115
Creating an OSPF External Routed Network for a Tenant Using the NX-OS CLI 117
Cisco APIC Basic Configuration Guide, Release 2.x
vii
Contents
Creating Tenants, VRF, and Bridge Domains 119
Tenants Overview 119
Tenant Creation 119
VRF and Bridge Domains 119
Creating a Tenant, VRF, and Bridge Domain Using the Advanced GUI 119
Deploying an Application Policy 120
Security Policy Enforcement 120
Contracts Contain Security Policy Specifications 121
Three-Tier Application Deployment 124
Parameters to Create a Filter for http 125
Parameters to Create Filters for rmi and sql 125
Example Application Profile Database 126
Deploying an Application Profile Using the GUI 126
Creating a Filter Using the GUI 126
Creating a Contract Using the GUI 127
Creating an Application Profile Using the GUI 127
Creating EPGs Using the GUI 128
Consuming and Providing Contracts Using the GUI 128
Statically Deploying an EPG on a Specific Port 129
Deploying an EPG on a Specific Port with APIC Using the GUI 129
Deploying an EPG on a Specific Port with APIC Using the NX-OS Style CLI 130
Deploying an EPG on a Specific Port with APIC Using the REST API 131
Creating Domains, Attach Entity Profiles, and VLANs to Deploy an EPG on a Specific
Port 131
Creating Domains, and VLANS to Deploy an EPG on a Specific Port Using the GUI 132
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using the NX-OS
Style CLI 133
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using the REST
API 134
Deploying an Application EPG through an AEP or Interface Policy Group to Multiple
Ports 135
Deploying an EPG through an AEP to Multiple Interfaces Using the APIC Advanced GUI
136
Deploying an EPG through an Interface Policy Group to Multiple Interfaces Using the
NX-OS Style CLI 137
Cisco APIC Basic Configuration Guide, Release 2.x
viii
Contents
Deploying an EPG through an AEP to Multiple Interfaces Using the REST API 138
Using Microsegmentation with Network-based Attributes on Bare Metal 139
Configuring Network-based Microsegmented EPGs in a Bare-Metal environment Using the
GUI 140
Configuring a Network-Based Microsegmented EPG in a Bare-Metal Environment Using the
NX-OS Style CLI 142
Configuring a Network-Based Microsegmented EPG in a Bare-Metal Environment Using the
REST API 143
IP Address-Based Microsegmented EPG as a Shared Resource 144
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the GUI 144
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the NX-OS
CLI 146
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the REST API 147
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the GUI 147
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the NX-OS Style
CLI 148
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the REST
API 149
Cisco APIC Basic Configuration Guide, Release 2.x
ix
Contents
Cisco APIC Basic Configuration Guide, Release 2.x
x
Preface
This preface includes the following sections:
• Audience, page xi
• Document Conventions, page xi
• Related Documentation, page xiii
• Documentation Feedback, page xiv
• Obtaining Documentation and Submitting a Service Request, page xiv
Audience
This guide is intended primarily for data center administrators with responsibilities and expertise in one or
more of the following:
• Virtual machine installation and administration
• Server administration
• Switch and network administration
Document Conventions
Command descriptions use the following conventions:
Convention
Description
bold
Bold text indicates the commands and keywords that you enter literally
as shown.
Italic
Italic text indicates arguments for which the user supplies the values.
[x]
Square brackets enclose an optional element (keyword or argument).
Cisco APIC Basic Configuration Guide, Release 2.x
xi
Preface
Document Conventions
Convention
Description
[x | y]
Square brackets enclosing keywords or arguments separated by a vertical
bar indicate an optional choice.
{x | y}
Braces enclosing keywords or arguments separated by a vertical bar
indicate a required choice.
[x {y | z}]
Nested set of square brackets or braces indicate optional or required
choices within optional or required elements. Braces and a vertical bar
within square brackets indicate a required choice within an optional
element.
variable
Indicates a variable for which you supply values, in context where italics
cannot be used.
string
A nonquoted set of characters. Do not use quotation marks around the
string or the string will include the quotation marks.
Examples use the following conventions:
Convention
Description
screen font
Terminal sessions and information the switch displays are in screen font.
boldface screen font
Information you must enter is in boldface screen font.
italic screen font
Arguments for which you supply values are in italic screen font.
<>
Nonprinting characters, such as passwords, are in angle brackets.
[]
Default responses to system prompts are in square brackets.
!, #
An exclamation point (!) or a pound sign (#) at the beginning of a line
of code indicates a comment line.
This document uses the following conventions:
Note
Caution
Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Means reader be careful. In this situation, you might do something that could result in equipment damage
or loss of data.
Cisco APIC Basic Configuration Guide, Release 2.x
xii
Preface
Related Documentation
Warning
IMPORTANT SAFETY INSTRUCTIONS
This warning symbol means danger. You are in a situation that could cause bodily injury. Before you
work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with
standard practices for preventing accidents. Use the statement number provided at the end of each warning
to locate its translation in the translated safety warnings that accompanied this device.
SAVE THESE INSTRUCTIONS
Related Documentation
Application Policy Infrastructure Controller (APIC) Documentation
Companion documents for APIC, Cisco APIC Getting Started Guide, Cisco APIC Basic Configuration Guide,
Cisco APIC Layer 2 Networking Configuration Guide, Cisco APIC Layer 3 Networking Configuration Guide,
Cisco APIC NX-OS Style Command-Line Interface Configuration Guide, Cisco APIC REST API Configuration
Guide, Cisco APIC Layer 4 to Layer 7 Services Deployment Guide, and Cisco ACI Virtualization Guide are
available at the following URL: http://www.cisco.com/c/en/us/support/cloud-systems-management/
application-policy-infrastructure-controller-apic/tsd-products-support-series-home.html
Cisco Application Centric Infrastructure (ACI) Documentation
The broader ACI documentation is available at the following URL: http://www.cisco.com/c/en/us/support/
cloud-systems-management/application-policy-infrastructure-controller-apic/
tsd-products-support-series-home.html.
Cisco Application Centric Infrastructure (ACI) Simulator Documentation
The Cisco ACI Simulator documentation is available at http://www.cisco.com/c/en/us/support/
cloud-systems-management/application-centric-infrastructure-simulator/tsd-products-support-series-home.html.
Cisco Nexus 9000 Series Switches Documentation
The Cisco Nexus 9000 Series Switches documentation is available at http://www.cisco.com/c/en/us/support/
switches/nexus-9000-series-switches/tsd-products-support-series-home.html.
Cisco Application Virtual Switch Documentation
The Cisco Application Virtual Switch (AVS) documentation is available at http://www.cisco.com/c/en/us/
support/switches/application-virtual-switch/tsd-products-support-series-home.html.
Cisco Application Centric Infrastructure (ACI) Integration with OpenStack Documentation
Cisco ACI integration with OpenStack documentation is available at http://www.cisco.com/c/en/us/support/
cloud-systems-management/application-policy-infrastructure-controller-apic/
tsd-products-support-series-home.html.
Cisco APIC Basic Configuration Guide, Release 2.x
xiii
Preface
Documentation Feedback
Documentation Feedback
To provide technical feedback on this document, or to report an error or omission, please send your comments
to [email protected] We appreciate your feedback.
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, using the Cisco Bug Search Tool (BST), submitting a service
request, and gathering additional information, see What's New in Cisco Product Documentation at: http://
www.cisco.com/c/en/us/td/docs/general/whatsnew/whatsnew.html
Subscribe to What’s New in Cisco Product Documentation, which lists all new and revised Cisco technical
documentation as an RSS feed and delivers content directly to your desktop using a reader application. The
RSS feeds are a free service.
Cisco APIC Basic Configuration Guide, Release 2.x
xiv
CHAPTER
1
New and Changed Information
This chapter contains the following sections:
• New and Changed Information, page 1
New and Changed Information
The following tables provide an overview of the significant changes to 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: Changed Features in this Document
Changed Feature
Description
Where Documented
Chapter moved to new guide
ACI Fabric Access Layer 2
Cisco APIC Layer 2 Configuration
Connectivity chapter moved to new Guide
configuration guide
Chapter moved to new guide
ACI Fabric Access Layer 3 Outside Cisco APIC Layer 3 Configuration
Connectivity chapter moved to new Guide
configuration guide
Table 2: New Features and Changed Behavior in Cisco APIC 2.2(2e) Release
Feature or Change
Description
Where Documented
Name Change
Changed name of "Layer 3 EVPN Cisco ACI GOLF in ACI Fabric
Services for Fabric WAN" to
Layer 3 Outside Connectivity
"Cisco ACI GOLF
Cisco APIC Basic Configuration Guide, Release 2.x
1
New and Changed Information
New and Changed Information
Table 3: New Features and Changed Behavior in Cisco APIC 2.2 (1n) Release
Feature
Description
Where Documented
FCoE over FEX
You can now configure FCoE over Supporting Fibre Channel over
FEX ports.
Ethernet Traffic on the ACI Fabric
Table 4: New Features and Changed Bahavior in Cisco APIC 2.1(1h) Release
Feature
Description
Distribute EVPN Type-2 Host
Routes
In this release, for optimal traffic Distributing BGP EVPN Type-2
forwarding in an EVPN topology, Host Routes in Configuring Layer
you can enable fabric spines to
3 EVPN Services over Fabric WAN
advertise host routes using EVPN
type-2 (MAC-IP) routes to the
DCIG along with public BD
subnets in the form of BGP EVPN
type-5 (IP Prefix) routes.
Configuring network-based
microsegmented EPGs in a
bare-metal environment
In this release you can configure Using Microsegmentation with
microsegmented EPGs with IP
Network-based Attributes on
address attributes or MAC address Bare-Metal
attributes for physical endpoint
devices.
Configuring IP address-based
EPGs as shared resources
In this release you can configure a Configuring IP Address-based
IP address-based microsegmented Microsegmented EPGs as a shared
EPG as a resource that can be
resource
access and shared by devices on
VRFs other than the one on which
the EPG is native.
Global in-band/out-of-band default In this release, you can toggle
management connectivity toggle between In-band and out-of-band
as the default management
connectivity mode between the
APIC server and external
management devices.
Where Documented
Configuring In-Band Management
Access Using the Advanced GUI,
Configuring In-Band Management
Access Using the NX-OS Style CLI,
and Configuring In-Band
Management Access Using the
REST API
Table 5: New Features and Changed Behavior in Cisco APIC 2.0(2f) Release
Feature
No significant changes occurred in
the release.
Cisco APIC Basic Configuration Guide, Release 2.x
2
Description
Where Documented
New and Changed Information
New and Changed Information
Table 6: New Features and Changed Behavior in Cisco APIC and Document Reorganization
Cisco APIC Release Feature
Version
Description
Release 2.0(1m)
Notice that
OSPF support for import and export
enabling import
controls is inserted in the following
and export controls topics:
now applies to
• Configuring a Layer 3 Outside for
OSPF as well as
Tenant Networks Using the GUI
BGP.
200
Import control policy
support -- for OSPF
available for inbound
filtering.
Where Documented
• Configuring Layer 3 Outside for
Tenant Networks Using the REST
API 202
• Configuring a Route Control
Protocol to Use Import and Export
Controls, With the GUI 225
• Configuring a Route Control
Protocol to Use Import and Export
Controls, With the REST API 227
• Configuring a Route Control
Protocol to Use Import and Export
Controls, With the NX-OS Style
CLI 228
• Transit Route Control 241
Release 2.0(1m)
–
The contents of this –
guide was
reorganized.
Several GUI, REST
API, and CLI tasks
that were in the
Cisco APIC Getting
Started Guide in
earlier releases are
now migrated in
this guide.
Cisco APIC Basic Configuration Guide, Release 2.x
3
New and Changed Information
New and Changed Information
Cisco APIC Release Feature
Version
Description
Where Documented
Release 2.0(1m)
An overview and
configuration
topics for
implementing
FCoE connectivity
over the ACI
fabric.
FCoE concepts and APIC configuration
are described in the ACI Fabric Layer
2 Connectivity chapter in the following
topics.
Fibre Channel over
Ethernet (FCoE)
support
• FCoE Basic GUI Configuration
122
• FCoE Advanced GUI
Configuration 129
• Configuring FCoE Connectivity
Using the NX-OS Style CLI 147
• Configuring FCoE Connectivity
Using the REST API 155
Release 2.0(1m)
Layer 3 EVPN
Services Over Fabric
WAN
An overview and
configuration
topics for
implementing
Layer 3 EVPN
Services over the
Fabric WAN
Layer 3 Services Over Fabric WAN
concepts and APIC configuration are
described in the ACI Fabric Layer 3
Outside Connectivity chapter in the
following topics.
• Layer 3 EVPN Services Over
Fabric WAN 191
• Configuring Layer 3 EVPN for
WAN Services Using the GUI 208
• Configuring Layer 3 EVPN for
WAN Services Using the NX-OS
Style CLI 210
• Configuring Layer 3 EVPN for
WAN Services Using the REST
API 211
Cisco APIC Basic Configuration Guide, Release 2.x
4
CHAPTER
2
About Cisco ACI/APIC Interfaces
• About ACI/APIC Interfaces, page 5
About ACI/APIC Interfaces
The single point of management within the Cisco Application Centric Infrastructure (ACI) architecture is
known as the Application Policy Infrastructure Controller (APIC). This controller provides access to all
configuration, management, monitoring, and health functions. Having a centralized controller with an application
programming interface (API) means that all functions configured or accessed through the fabric can be
approached through the following interfaces:
• APIC GUI
The APIC GUI is a browser-based graphical interface to the APIC that communicates internally with
the APIC engine by exchanging REST API messages. It includes two modes:
◦Advanced—Used for large scale configurations, deployments, and operations; enables granular
policy controls such as in switch profiles, interface profiles, policy groups, or access entity profiles
(AEPs) for automating mass fabric configuration and deployment.
◦Basic—A simple interface to enable common workflows, the GUI operational mode enables
administrators to get started easily with ACI with a minimal knowledge of the object model. The
simplified GUI allows the configuration of leaf ports and tenants without the need to configure
advanced policies.
For more information about the APIC GUI, see Cisco APIC Getting Started Guide, Release 2.x and
Cisco APIC Basic Configuration Guide, Release 2.x.
• NX-OS Style CLI—The NX-OS style Command-Line Interface (CLI) can be used for APIC configuration,
deployment, and operation. It is organized in a hierarchy of command modes with EXEC mode as the
root, containing a tree of configuration submodes beginning with global configuration mode. The
commands available to you depend on the mode you are in.
For more information about the NX-OS style CLI, see the Cisco APIC NX-OS Style Command-Line
Interface Configuration Guide.
• APIC REST API—The REST API is responsible for accepting configuration, as well as providing access
to management functions for the controller. This interface is a crucial component for the GUI and CLI,
Cisco APIC Basic Configuration Guide, Release 2.x
5
About Cisco ACI/APIC Interfaces
About ACI/APIC Interfaces
and also provides a touch point for automation tools, provisioning scripts and third party monitoring
and management tools.
The APIC REST API is a programmatic interface that uses REST architecture. The API accepts and
returns HTTP (not enabled by default) or HTTPS messages that contain JavaScript Object Notation
(JSON) or Extensible Markup Language (XML) documents. You can use any programming language
to generate the messages and the JSON or XML documents that contain the API methods or MO
descriptions.
For more information about the REST API, see the Cisco APIC REST API Configuration Guide.
Caution
Changes made through the APIC Basic GUI can be seen, but cannot be modified in the Advanced GUI,
and changes made in the Advanced GUI cannot be rendered in the Basic GUI. The Basic GUI is kept
synchronized with the NX-OS style CLI, so that if you make a change from the NX-OS style CLI, these
changes are rendered in the Basic GUI, and changes made in the Basic GUI are rendered in the NX-OS
style CLI, but the same synchronization does not occur between the Advanced GUI and the NX-OS style
CLI. See the following examples:
• Do not mix Basic and Advanced GUI modes. If you apply an interface policy to two ports using
Advanced mode and then change the settings of one port using Basic mode, your changes might be
applied to both ports.
• Do not mix the Advanced GUI and the CLI, when doing per-interface configuration on APIC.
Configurations performed in the GUI, may only partially work in the NX-OS CLI.
For example, if you configure a switch port in the GUI at Tenants > tenant-name > Application
Profiles > application-profile-name > Application EPGs > EPG-name > Static Ports > Deploy
Static EPG on PC, VPC, or Interface
Then you use the show running-config command in the NX-OS style CLI, you receive output such
as:
leaf 102
interface ethernet 1/15
switchport trunk allowed vlan 201 tenant t1 application ap1 epg ep1
exit
exit
If you use these commands to configure a static port in the NX-OS style CLI, the following error
occurs:
apic1(config)# leaf 102
apic1(config-leaf)# interface ethernet 1/15
apic1(config-leaf-if)# switchport trunk allowed vlan 201 tenant t1 application ap1
epg ep1
No vlan-domain associated to node 102 interface ethernet1/15 encap vlan-201
This occurs because the CLI has validations that are not performed by the APIC GUI. For the
commands from the show running-config command to function in the NX-OS CLI, a vlan-domain
must have been previously configured. The order of configuration is not enforced in the GUI.
• Do not make changes with the Basic GUI or the NX-OS CLI before using the Advanced GUI. This
may also inadvertantly cause objects to be created (with names prepended with _ui_) which cannot
be changed or deleted in the Advanced GUI.
For the steps to remove such objects, see Troubleshooting Unwanted _ui_ Objects in the APIC Troubleshooting
Guide.
Cisco APIC Basic Configuration Guide, Release 2.x
6
CHAPTER
3
User Access, Authentication, and Accounting
This chapter contains the following sections:
• Access Rights Workflow Dependencies, page 7
• User Access, Authorization, and Accounting, page 8
• Configuring a Local User, page 9
• Configuring a Remote User, page 12
• Configuring Windows Server 2008 LDAP for APIC Access, page 17
• Configuring APIC for LDAP Access, page 19
• Changing the Default Behavior for Remote Users with Missing or Bad Cisco AV Pairs, page 20
• Changing Default Behavior for Remote Users with Missing or Bad Cisco AV Pairs Using the NX-OS
Style CLI, page 20
• About Signature-Based Transactions, page 21
• Accounting, page 28
• Routed Connectivity to External Networks as a Shared Service Billing and Statistics, page 29
Access Rights Workflow Dependencies
The Cisco Application Centric Infrastructure (ACI) RBAC rules enable or restrict access to some or all of the
fabric. For example, in order to configure a leaf switch for bare metal server access, the logged in administrator
must have rights to the infra domain. By default, a tenant administrator does not have rights to the infra
domain. In this case, a tenant administrator who plans to use a bare metal server connected to a leaf switch
could not complete all the necessary steps to do so. The tenant administrator would have to coordinate with
a fabric administrator who has rights to the infra domain. The fabric administrator would set up the switch
configuration policies that the tenant administrator would use to deploy an application policy that uses the
bare metal server attached to an ACI leaf switch.
Cisco APIC Basic Configuration Guide, Release 2.x
7
User Access, Authentication, and Accounting
User Access, Authorization, and Accounting
User Access, Authorization, and Accounting
Application Policy Infrastructure Controller (APIC) policies manage the authentication, authorization, and
accounting (AAA) functions of the Cisco Application Centric Infrastructure (ACI) fabric. 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, the CLI, or the GUI.
Multiple Tenant Support
A core Application Policy Infrastructure Controller (APIC) internal data access control system provides
multitenant isolation and prevents information privacy from being compromised across tenants. Read/write
restrictions prevent any tenant from seeing any other tenant's configuration, statistics, faults, or event data.
Unless the administrator assigns permissions to do so, tenants are restricted from reading fabric configuration,
policies, statistics, faults, or events.
User Access: Roles, Privileges, and Security Domains
The APIC provides access according to a user’s role through role-based access control (RBAC). An Cisco
Application Centric Infrastructure (ACI) 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
The ACI fabric 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 Application Policy Infrastructure Controller (APIC) 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 ACI MIT 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. For
example, an administrator could assign the “solar” domain tag to the tenant named solar. Within the MIT, only
certain objects can be tagged as security domains. For example, a tenant can be tagged as a security domain
but objects within a tenant cannot.
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 ACI 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 APIC Basic Configuration Guide, Release 2.x
8
User Access, Authentication, and Accounting
Configuring a Local User
Note
For read operations to the managed objects that a user's credentials do not allow, a "DN/Class Not Found"
error is returned, not "DN/Class Unauthorized to read." For write operations to a managed object that a
user's credentials do not allow, an HTTP 401 Unauthorized error is returned. In the GUI, actions that a
user's credentials do not allow, either they are not presented, or they are grayed out.
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.
If a virtual machine management (VMM) domain is tagged as a security domain, the users contained in the
security domain can access the correspondingly tagged VMM domain. For example, if a tenant named solar
is tagged with the security domain called sun and a VMM domain is also tagged with the security domain
called sun, then users in the solar tenant can access the VMM domain according to their access rights.
Configuring a Local User
In the initial configuration script, the admin account is configured and the admin is the only user when the
system starts. The APIC supports a granular, role-based access control system where user accounts can be
created with various roles including non-admin users with fewer privileges.
Configuring a Local User Using the GUI
Before You Begin
• The ACI fabric is installed, APIC controllers are online, and the APIC cluster is formed and healthy.
• As appropriate, the security domain(s) that the user will access are defined. For example, if the new use
account will be restricted to accessing a tenant, the tenant domain is tagged accordingly.
• An APIC user account is available that will enable the following:
◦Creating the TACACS+ and TACACS+ provider group.
◦Creating the local user account in the target security domain(s). If the target domain is all, the
login account used to create the new local user must be a fabric-wide administrator that has access
to all. If the target domain is a tenant, the login account used to create the new local user must be
a tenant administrator that has full read write access rights to the target tenant domain.
Cisco APIC Basic Configuration Guide, Release 2.x
9
User Access, Authentication, and Accounting
Configuring SSH Public Key Authentication Using the GUI
Procedure
Step 1
Step 2
On the menu bar, choose ADMIN > AAA.
In the Navigation pane, click AAA Authentication.
Step 3
In the Work pane, verify that in the default Authentication field, the Realm field displays as Local.
Step 4
In the Navigation pane, expand Security Management > Local Users.
The admin user is present by default.
Step 5
In the Navigation pane, right-click Create Local User.
Step 6
In the Security dialog box, choose the desired security domain for the user, and click Next.
Step 7
In the Roles dialog box, click the radio buttons to choose the roles for your user, and click Next.
You can provide read-only or read/write privileges.
Step 8
In the User Identity dialog box, perform the following actions:
a) In the Login ID field, add an ID.
b) In the Password field, enter the password.
At the time a user sets their password, the APIC validates it against the following criteria:
• Minimum password length is 8 characters.
• Maximum password length is 64 characters.
• Has fewer than three consecutive repeated characters.
• Must have characters from at least three of the following characters types: lowercase, uppercase,
digit, symbol.
• Does not use easily guessed passwords.
• Cannot be the username or the reverse of the username.
• Cannot be any variation of cisco, isco or any permutation of these characters or variants obtained by
changing the capitalization of letters therein.
c) In the Confirm Password field, confirm the password.
d) Click Finish.
Step 9
In the Navigation pane, click the name of the user that you created. In the Work pane, expand the + sign next
to your user in the Security Domains area.
The access privileges for your user are displayed.
Configuring SSH Public Key Authentication Using the GUI
Before You Begin
• Create a local user account in the target security domain(s). If the target domain is all, the login account
used to create the new local user must be a fabric-wide administrator that has access to all. If the target
domain is a tenant, the login account used to create the new local user must be a tenant administrator
that has full read write access rights to the target tenant domain.
Cisco APIC Basic Configuration Guide, Release 2.x
10
User Access, Authentication, and Accounting
Configuring a Local User Using the NX-OS Style CLI
• Generate a public key using the Unix command ssh-keygen.
Procedure
Step 1
Step 2
On the menu bar, choose ADMIN > Security Management > Local Users.
In the Navigation pane, click the name of the user that you previously created.
Step 3
In the Work pane, expand the SSH Keys table, and insert the following information:
a) In the Name field, enter a name for the key.
b) In the Key field, insert the public key previously created. Click Update.
Configuring a Local User Using the NX-OS Style CLI
Procedure
Step 1
In the NX-OS CLI, start in configuration mode, shown as follows:
Example:
apic1# configure
apic1(config)#
Step 2
Create a new user, shown as follows:
Example:
apic1(config)# username
WORD
User name (Max Size 28)
admin
cli-user
jigarshah
test1
testUser
apic1(config)# username test
apic1(config-username)#
account-status
Set The status of the locally-authenticated user account.
certificate
Create AAA user certificate in X.509 format.
clear-pwd-history
Clears the password history of a locally-authenticated user
domain
Create the AAA domain to which the user belongs.
email
Set The email address of the locally-authenticated user.
exit
Exit from current mode
expiration
If expires enabled, Set expiration date of locally-authenticated user
account.
expires
Enable expiry for locally-authenticated user account
fabric
show fabric related information
first-name
Set the first name of the locally-authenticated user.
last-name
Set The last name of the locally-authenticated user.
no
Negate a command or set its defaults
password
Set The system user password.
phone
Set The phone number of the locally-authenticated user.
pwd-lifetime
Set The lifetime of the locally-authenticated user password.
pwd-strength-check Enforces the strength of the user password
show
Show running system information
ssh-key
Update ssh key for the user for ssh authentication
Cisco APIC Basic Configuration Guide, Release 2.x
11
User Access, Authentication, and Accounting
Configuring a Local User Using the REST API
where
show the current mode
apic1(config-username)# exit
Configuring a Local User Using the REST API
Procedure
Create a local user.
Example:
URL: https://apic-ip-address/api/policymgr/mo/uni/userext.xml
POST CONTENT:
<aaaUser name="operations" phone="" pwd="<strong_password>" >
<aaaUserDomain childAction="" descr="" name="all" rn="userdomain-all" status="">
<aaaUserRole childAction="" descr="" name="Ops" privType="writePriv"/>
</aaaUserDomain>
</aaaUser>
Configuring a Remote User
Instead of configuring local users, you can point the APIC at the centralized enterprise credential datacenter.
The APIC supports Lightweight Directory Access Protocol (LDAP), active directory, RADIUS, and TACACS+.
Note
When an APIC is in minority (disconnected from the cluster), remote logins can fail because the ACI is
a distributed system and the user information is distributed across APICS. Local logins, however, continue
to work because they are local to the APIC.
To configure a remote user authenticated through an external authentication provider, you must meet the
following prerequisites:
• The DNS configuration should have already been resolved with the hostname of the RADIUS server.
• You must configure the management subnet.
AV Pair on the External Authentication Server
The Cisco APIC requires that an administrator configure a Cisco AV Pair on an external authentication server.
The Cisco AV pair specifies the APIC required RBAC roles and privileges for the user. The Cisco AV Pair
format is the same for RADIUS, LDAP, or TACACS+.
To configure a Cisco AV Pair on an external authentication server, an administrator adds a Cisco AV pair to
the existing user record. The Cisco AV pair format is as follows:
shell:domains =
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
shell:domains =
Cisco APIC Basic Configuration Guide, Release 2.x
12
User Access, Authentication, and Accounting
AV Pair on the External Authentication Server
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,
domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(16003)
The first av-pair format has no UNIX user ID, while the second one does. Both are correct if all remote users
have the same role and mutual file access is acceptable. If the UNIX user ID is not specified, ID 23999 is
applied by the APIC system, and more than one role/read privilege is specified to any AV Pair user. This can
cause users to have higher or lower permissions than configured through the group settings.
Note
The APIC Cisco AV-pair format is compatible and can co-exist with other Cisco AV-pair formats. APIC
will pick up the first matching AV-pair from all the AV-pairs.
The APIC supports the following regexes:
shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$
shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$
Examples:
• Example 1: A Cisco AV Pair that contains a single Login domain with only writeRoles:
shell:domains=domainA/writeRole1|writeRole2/
• Example 2: A Cisco AV Pair that contains a single Login domain with only readRoles:
shell:domains=domainA//readRole1|readRole2
Note
The "/" character is a separator between writeRoles and readRoles per Login domain and is required even
if only one type of role is to be used.
The Cisco AVpair string is case sensitive. Although a fault may not be seen, using mismatching cases for
the domain name or roles could lead to unexpected privileges being given.
An example configuration for an open RADIUS server (/etc/raddb/users) is as follows:
aaa-network-admin Cleartext-Password := "<password>"
Cisco-avpair = "shell:domains = all/aaa/read-all(16001)"
Best Practice for Assigning AV Pairs
As best practice, Cisco recommends that you assign unique UNIX user ids in the range 16000-23999 for the
AV Pairs that are assigned to users when in bash shell (using SSH, Telnet or Serial/KVM consoles). If a
situation arises when the Cisco AV Pair does not provide a UNIX user id, the user is assigned a user id of
23999 or similar number from the range that also enables the user's home directories, files, and processes
accessible to remote users with a UNIX ID of 23999.
Configuring an AV Pair on the External Authentication Server
The numerical value within the parentheses in the attribute/value (AV) pair string is used as the UNIX user
ID of the user who is logged in using Secure Shell (SSH) or Telnet.
Cisco APIC Basic Configuration Guide, Release 2.x
13
User Access, Authentication, and Accounting
Configuring APIC for TACACS+ Access
Procedure
Configure an AV pair on the external authentication server.
The Cisco AV pair definition is as follows (Cisco supports AV pairs with and without UNIX user IDs specified):
Example:
* shell:domains =
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2
* shell:domains =
domainA/writeRole1|writeRole2|writeRole3/readRole1|readRole2,domainB/writeRole1|writeRole2|writeRole3/readRole1|readRole2(8101)
These are the boost regexes supported by APIC:
uid_regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})(\\(\\d+\\))$");
regex("shell:domains\\s*[=:]\\s*((\\S+?/\\S*?/\\S*?)(,\\S+?/\\S*?/\\S*?){0,31})$");
The following is an example:
shell:domains = coke/tenant-admin/read-all,pepsi//read-all(16001)
Configuring APIC for TACACS+ Access
Before You Begin
• The Cisco Application Centric Infrastructure (ACI) fabric is installed, Application Policy Infrastructure
Controllers (APICs) are online, and the APIC cluster is formed and healthy.
• The TACACS+ server host name or IP address, port, and key are available.
• The APIC management endpoint group is available.
Procedure
Step 1
In the APIC, create the TACACS+ Provider.
a)
b)
c)
d)
Step 2
On the menu bar, choose Admin > AAA.
In the Navigation pane, choose TACACS+ Managment > TACACS+ Providers.
In the Work pane, choose Actions > Create TACACS+ Provider.
Specify the TACACS+ host name (or IP address), port, authorization protocol, key, and management
endpoint group.
Note
If the APIC is configured for in-band management connectivity, choosing an out-of-band
management endpoint group for TACACS+ access does not take effect. Alternatively, an
out-of-band over an in-band management endpoint group can connect a TACACS+ server, but
requires configuring a static route for the TACACS+ server. The Cisco ACS sample configuration
procedure below uses an APIC in-band IP address.
Create the TACACS+ Provider Group.
a) In the Navigation pane, choose TACACS+ Managment > TACACS+ Provider Groups.
b) In the Work pane, choose Actions > Create TACACS+ Provider Group.
c) Specify the TACACS+ provider group name, description, and providers as appropriate.
Step 3
Create the Login Domain for TACACS+.
a) In the Navigation pane, choose AAA Authentication > Login Domains.
b) In the Work pane, choose Actions > Create Login Domain.
Cisco APIC Basic Configuration Guide, Release 2.x
14
User Access, Authentication, and Accounting
Configuring APIC for RADIUS Access
c) Specify the login domain name, description, realm, and provider group as appropriate.
What to Do Next
This completes the APIC TACACS+ configuration steps. Next, if a RAIDUS server will also be used, configure
the APIC for RADIUS. If only a TACACS+ server will be used, go to the ACS server configuration topic
below.
Configuring APIC for RADIUS Access
Before You Begin
• The ACI fabric is installed, Application Policy Infrastructure Controllers (APICs) are online, and the
APIC cluster is formed and healthy.
• The RADIUS server host name or IP address, port, authorization protocol, and key are available.
• The APIC management endpoint group is available.
Procedure
Step 1
In the APIC, create the RADIUS provider.
a) On the menu bar, choose Admin > AAA.
b) In the Navigation pane, choose RADIUS Managment > RADIUS Providers.
c) In the Work pane, choose Actions > Create RADIUS Provider.
d) Specify the RADIUS host name (or IP address), port, protocol, and management endpoint group.
Note
If the APIC is configured for in-band management connectivity, choosing an out-of-band
management endpoint group for RADIUS access does not take effect. Alternatively, an out-of-band
over an in-band management endpoint group can connect a RADIUS server but requires
configuring a static route for the RADIUS server. The Cisco ACS sample configuration procedure
below uses an APIC in-band IP address.
Step 2
Create the RADIUS provider group.
a) In the Navigation pane, choose RADIUS Managment > RADIUS Provider Groups.
b) In the Work pane, choose Actions > Create RADIUS Provider Group.
c) Specify the RADIUS Provider Group name, description, and providers as appropriate.
Step 3
Create the login domain for RADIUS.
a) In the Navigation pane, choose AAA Authentication > Login Domains.
b) In the Work pane, choose Actions > Create Login Domain.
c) Specify the login domain name, description, realm, and provider group as appropriate.
What to Do Next
This completes the APIC RADIUS configuration steps. Next, configure the RADIUS server.
Cisco APIC Basic Configuration Guide, Release 2.x
15
User Access, Authentication, and Accounting
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+ Access to the APIC
Configuring a Cisco Secure Access Control Server for RADIUS and TACACS+
Access to the APIC
Before You Begin
• The Cisco Secure Access Control Server (ACS) version 5.5 is installed and online.
Note
ACS v5.5 was used to document these steps. Other versions of ACS might support this
task but the GUI procedures might vary accordingly.
• The Cisco Application Policy Infrastructure Controller (Cisco APIC) RADIUS or TACACS+ keys are
available (or keys for both if both will be configured).
• The Cisco APICs are installed and online; the Cisco APIC cluster is formed and healthy.
• The RADIUS or TACACS+ port, authorization protocol, and key are available.
Procedure
Step 1
Log in to the ACS server to configure the Cisco APIC as a client.
a) Navigate to Network Resources > Network Devices Groups > Network Devices and AAA Clients.
b) Specify the client name, the Cisco APIC in-band IP address, select the TACACS+ or RADIUS (or both)
authentication options.
Note
If the only RADIUS or TACACS+ authentication is needed, select only the needed option.
c) Specify the authentication details such as Shared Secret (key), and port as appropriate for the authentication
option(s).
Note
The Shared Secret(s) must match the Cisco APIC Provider key(s).
Step 2
Create the Identity Group.
a) Navigate to Users and Identity Stores > Internal Groups option.
b) Specify the Name, and Parent Group as appropriate.
Step 3
Map users to the Identity Group.
a) In the Navigation pane, click the Users and Identity Stores > Internal Identity Stores > Users option.
b) Specify the user Name, and Identity Group as appropriate.
Step 4
Create the Policy Element.
a) Navigate to the Policy Elements option.
b) For RADIUS, specify the Authorization and Permissions > Network Access > Authorization Profiles
Name. For TACACS+, specify the Authorization and Permissions > Device Administration > Shell Profile
Name as appropriate.
c) For RADIUS, specify the Attribute as cisco-av-pair, Type as string, and the Value as shell:domains
= <domain>/<role>/,<domain>// role as appropriate. For TACACS+, specify the Attribute as
cisco-av-pair, Requirement as Mandatory, and the Value as shell:domains =
<domain>/<role>/,<domain>// role as appropriate.
Cisco APIC Basic Configuration Guide, Release 2.x
16
User Access, Authentication, and Accounting
Configuring Windows Server 2008 LDAP for APIC Access
For example, if the cisco-av-pair has a value of shell:domains = solar/admin/,common//
read-all(16001), then solar is the security domain, admin is the role for this user that gives write
privileges to this user in the security domain called solar, common is the Cisco Application Centric
Infrastructure (Cisco ACI) tenant common, and read-all(16001) is the role with read privileges that
gives this user read privileges to all of the Cisco ACI tenant common.
Step 5
Create a service selection rule.
a) For RADIUS, create a service selection rule to associate the Identity Group with the Policy Element by
navigating to Access Policies > Default Device Network Access Identity > Authorization and specifying
the rule Name, Status, and Conditions as appropriate, and Add the Internal Users:UserIdentityGroup
in ALL Groups:<identity group name>.
b) For TACACS+, create a service selection rule to associate the Identity Group with the Shell Profile by
navigating to Access Policies > Default Device Admin Identity > Authorization. Specify the rule Name,
Conditions, and Select the Shell Profile as appropriate.
What to Do Next
Use the newly created RADIUS and TACACS+ users to log in to the Cisco APIC. Verify that the users have
access to the correct Cisco APIC security domain according to the assigned RBAC roles and privileges. The
users should not have access to items that have not been explicitly permitted. Read and write access rights
should match those configured for that user.
Configuring Windows Server 2008 LDAP for APIC Access
Before You Begin
• First, configure the LDAP server, then configure the Cisco Application Policy Infrastructure Controller
(Cisco APIC) for LDAP access.
• The Microsoft Windows Server 2008 is installed and online.
• The Microsoft Windows Server 2008 Server Manager ADSI Edit tool is installed. To install ADSI Edit,
follow the instructions in the Windows Server 2008 Server Manager help.
• AciCiscoAVPair attribute specifications: Common Name = AciCiscoAVPair, LDAP Display Name =
AciCiscoAVPair, Unique X500 Object ID = 1.3.6.1.4.1.9.22.1, Description = AciCiscoAVPair, Syntax
= Case Sensitive String.
Note
For LDAP configurations, best practice is to use AciCiscoAVPair as the attribute string.
This avoids problems related to the limitation of common LDAP servers that do not
allow overlapping object identifiers (OID); that is, the ciscoAVPair OID is already in
use.
• A Microsoft Windows Server 2008 user account is available that will enable the following:
◦Running ADSI Edit to add the AciCiscoAVPair attribute to the Active Directory (AD) Schema.
◦Configuring an Active Directory LDAP user to have AciCiscoAVPair attribute permissions.
Cisco APIC Basic Configuration Guide, Release 2.x
17
User Access, Authentication, and Accounting
Configuring Windows Server 2008 LDAP for APIC Access
Procedure
Step 1
Step 2
Log in to an Active Directory (AD) server as a domain administrator.
Add the AciCiscoAVPair attribute to the AD schema.
a) Navigate to Start > Run, type mmc and press Enter.
The Microsoft Management Console (MMC) opens.
b) Navigate to File > Add/Remove Sanp-in > Add.
c) In the Add Standalonee Snap-in dialog box, select the Active Directory Schema and click Add.
The MMC Console opens.
d) Right-click the Attributes folder, select the Create Attribute option.
The Create New Attribute dialog box opens.
e) Enter AciCiscoAVPair for the Common Name , AciCiscoAVPair for the LDAP Display Name,
1.3.6.1.4.1.9.22.1 for the Unique X500 Object ID, and select Case Sensitive String for the Syntax.
f) Click OK to save the attribute.
Step 3
Update the User Properties class to include the CiscoAVPair attribute.
a) In the MMC Console, expand the Classes folder, right-click the user class, and choose Properties.
The user Properties dialog box opens.
b) Click the Attributes tab, select CiscoAVPair from the Optional list, and click Add.
The Select Schema Object dialog box opens.
c) In the Select a schema object: list, choose CiscoAVPair, and click Apply.
d) In the MMC Console, right-click the Active Directory Schema, and select Reload the Schema.
Step 4
Configure the AciCiscoAVPair attribute permissions.
Now that the LDAP includes the AciCiscoAVPair attributes, LDAP users need to be granted Cisco APIC
permission by assigning them Cisco APIC RBAC roles.
a) In the ADSI Edit dialog box, locate a user who needs access to the Cisco APIC.
b) Right-click on the user name, and choose Properties.
The <user> Properties dialog box opens.
c) Click the Attribute Editor tab, select the AciCiscoAVPair attribute, and enter the Value as shell:domains
= <domain>/<role>/,<domain>// role.
For example, if the AciCiscoAVPair has a value of shell:domains = solar/admin/,common//
read-all(16001), then solar is the security domain, admin is the role for this user that gives write
privileges to this user in the security domain called solar, common is the Cisco Application Centric
Infrastructure (Cisco ACI) tenant common, and read-all(16001) is the role with read privileges that
gives this user read privileges to all of the Cisco ACI tenant common.
d) Click OK to save the changes and close the <user> Properties dialog box.
The LDAP server is configured to access the Cisco APIC.
What to Do Next
Configure the Cisco APIC for LDAP access.
Cisco APIC Basic Configuration Guide, Release 2.x
18
User Access, Authentication, and Accounting
Configuring APIC for LDAP Access
Configuring APIC for LDAP Access
Before You Begin
• The Cisco Application Centric Infrastructure (ACI) fabric is installed, Application Policy Infrastructure
Controllers (APICs) are online, and the APIC cluster is formed and healthy.
• The LDAP server host name or IP address, port, bind DN, Base DN, and password are available.
• The APIC management endpoint group is available.
Procedure
Step 1
In the APIC, configure the LDAP Provider.
a)
b)
c)
d)
On the menu bar, choose Admin > AAA.
In the Navigation pane, choose LDAP Managment > LDAP Providers.
In the Work pane, choose Actions > Create LDAP Provider.
Specify the LDAP host name (or IP address), port, bind DN, base DN, password, and management endpoint
group.
The bind DN is the string that the APIC uses to log in to the LDAP server. The 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 APIC searches for the remote user account. This is where the password is validated. Filter
is used to locate the attribute that the APIC requests to use for the cisco-av-pair. This contains the user
authorization and assigned RBAC roles for use on the APIC. The APIC requests the attribute from the
LDAP server.
Note
If the APIC is configured for in-band management connectivity, choosing an out-of-band
management endpoint group for LDAP access does not take effect. Alternatively, an out-of-band
over an in-band management endpoint group can connect a LDAP server, but requires configuring
a static route for the LDAP server. The sample configuration procedures in this document use an
APIC in-band management endpoint group.
Step 2
In the APIC, configure the LDAP Provider Group.
a) In the Navigation pane, choose LDAP Managment > LDAP Provider Groups.
b) In the Work pane, choose Actions > Create LDAP Provider Group.
c) Specify the LDAP provider group name, description, and providers as appropriate.
Step 3
On the APIC, configure the login domain for LDAP.
a) In the Navigation pane, choose AAA Authentication > Login Domains.
b) In the Work pane, choose Actions > Create Login Domain.
c) Specify the login domain name, description, realm, and provider group as appropriate.
What to Do Next
This completes the APIC LDAP configuration steps. Next, test the APIC LDAP login access.
Cisco APIC Basic Configuration Guide, Release 2.x
19
User Access, Authentication, and Accounting
Changing the Default Behavior for Remote Users with Missing or Bad Cisco AV Pairs
Changing the Default Behavior for Remote Users with Missing
or Bad Cisco AV Pairs
Procedure
Step 1
Step 2
On the menu bar, click ADMIN > AAA.
In the Navigation pane, click AAA Authentication.
Step 3
In the Work pane, in the Properties area, from the Remote user login policy drop-down list, choose Assign
Default Role.
The default value is No Login. The Assign Default Role option assigns the minimal read-only privileges to
users that have missing or bad Cisco AV Pairs. Bad AV Pairs are those AV Pairs that fail the parsing rules.
Changing Default Behavior for Remote Users with Missing or
Bad Cisco AV Pairs Using the NX-OS Style CLI
The Cisco APIC requires that an administrator configure a Cisco AV Pair on an external authentication server.
To do so, an administrator adds a Cisco AV pair to the existing user record. The Cisco AV pair specifies the
APIC required RBAC roles and privileges for the user. The Cisco AV Pair format is the same for RADIUS,
LDAP, or TACACS+. One AV pair format contains a Cisco UNIX user ID and one does not. Both are correct
if all remote users have the same role and mutual file access is acceptable. If the UNIX user ID is not specified,
ID 23999 is applied by the APIC system, and more than one role/read privilege is specified to any AV Pair
user. This can cause users to have higher or lower permissions than configured through the group settings.
This topic explains how to change the bahavior if that is not acceptable.
To change the default behavior for remote users with missing or bad Cisco AV pairs using the NX-OS CLI:
Procedure
Step 1
In the NX-OS CLI, start in Configuration mode.
Example:
apic1#
apic1# configure
Step 2
Configure the aaa user default role.
Example:
apic1(config)# aaa user default-role
assign-default-role assign-default-role
no-login
no-login
Step 3
Configure the aaa authentication login methods.
Cisco APIC Basic Configuration Guide, Release 2.x
20
User Access, Authentication, and Accounting
About Signature-Based Transactions
Example:
apic1(config)# aaa authentication
login Configure methods for login
apic1(config)# aaa authentication login
console Configure console methods
default Configure default methods
domain
Configure domain methods
apic1(config)# aaa authentication login console
<CR>
apic1(config)# aaa authentication login domain
WORD
Login domain name
fallback
About Signature-Based Transactions
The APIC controllers in a Cisco ACI fabric offer different methods to authenticate users.
The primary authentication method uses a username and password and the APIC REST API returns an
authentication token that can be used for future access to the APIC. This may be considered insecure in a
situation where HTTPS is not available or enabled.
Another form of authentication that is offered utilizes a signature that is calculated for every transaction. The
calculation of that signature uses a private key that must be kept secret in a secure location. When the APIC
receives a request with a signature rather than a token, the APIC utilizes an X.509 certificate to verify the
signature. In signature-based authentication, every transaction to the APIC must have a newly calculated
signature. This is not a task that a user should do manually for each transaction. Ideally this function should
be utilized by a script or an application that communicates with the APIC. This method is the most secure as
it requires an attacker to crack the RSA/DSA key to forge or impersonate the user credentials.
Note
Additionally, you must use HTTPS to prevent replay attacks.
Before you can use X.509 certificate-based signatures for authentication, verify that the following pre-requisite
tasks are completed:
1 Create an X.509 certificate and private key using OpenSSL or a similar tool.
2 Create a local user on the APIC. (If a local user is already available, this task is optional).
3 Add the X.509 certificate to the local user on the APIC.
Guidelines and Limitations
Follow these guidelines and limitations:
• Local users are supported. Remote AAA users are not supported.
• The APIC GUI does not support the certificate authentication method.
Cisco APIC Basic Configuration Guide, Release 2.x
21
User Access, Authentication, and Accounting
Generating an X.509 Certificate and a Private Key
• WebSockets and eventchannels do not work for X.509 requests.
• Certificates signed by a third party are not supported. Use a self-signed certificate.
Generating an X.509 Certificate and a Private Key
Procedure
Step 1
Enter an OpenSSL command to generate an X.509 certificate and private key.
Example:
$ openssl req -new -newkey rsa:1024 -days 36500 -nodes -x509 -keyout userabc.key -out
userabc.crt -subj '/CN=User ABC/O=Cisco Systems/C=US'
Note
• Once the X.509 certificate is generated, it will be added to the users profile on the APIC, and
it is used to verify signatures. The private key is used by the client to generate the signatures.
• The certificate contains a public key but not the private key. The public key is the primary
information used by the APIC to verify the calculated signature. The private key is never stored
on the APIC. You must keep it secret.
Step 2
Display the fields in the certificate using OpenSSL.
Example:
$ openssl x509 -text -in userabc.crt
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
c4:27:6c:4d:69:7c:d2:b6
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=User ABC, O=Cisco Systems, C=US
Validity
Not Before: Jan 12 16:36:14 2015 GMT
Not After : Dec 19 16:36:14 2114 GMT
Subject: CN=User ABC, O=Cisco Systems, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:92:35:12:cd:2b:78:ef:9d:ca:0e:11:77:77:3a:
99:d3:25:42:94:b5:3e:8a:32:55:ce:e9:21:2a:ff:
e0:e4:22:58:6d:40:98:b1:0d:42:21:db:cd:44:26:
50:77:e5:fa:b6:10:57:d1:ec:95:e9:86:d7:3c:99:
ce:c4:7f:61:1d:3c:9e:ae:d8:88:be:80:a0:4a:90:
d2:22:e9:1b:25:27:cd:7d:f3:a5:8f:cf:16:a8:e1:
3a:3f:68:0b:9c:7c:cb:70:b9:c7:3f:e8:db:85:d8:
98:f6:e3:70:4e:47:e2:59:03:49:01:83:8e:50:4a:
5f:bc:35:d2:b1:07:be:ec:e1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
0B:E4:11:C7:23:46:10:4F:D1:10:4C:C1:58:C2:1E:18:E8:6D:85:34
X509v3 Authority Key Identifier:
keyid:0B:E4:11:C7:23:46:10:4F:D1:10:4C:C1:58:C2:1E:18:E8:6D:85:34
DirName:/CN=User ABC/O=Cisco Systems/C=US
serial:C4:27:6C:4D:69:7C:D2:B6
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
Cisco APIC Basic Configuration Guide, Release 2.x
22
User Access, Authentication, and Accounting
Configuring a Local User
8f:c4:9f:84:06:30:59:0c:d2:8a:09:96:a2:69:3d:cf:ef:79:
91:ea:cd:ae:80:16:df:16:31:3b:69:89:f7:5a:24:1f:fd:9f:
d1:d9:b2:02:41:01:b9:e9:8d:da:a8:4c:1e:e5:9b:3e:1d:65:
84:ff:e8:ad:55:3e:90:a0:a2:fb:3e:3e:ef:c2:11:3d:1b:e6:
f4:5e:d2:92:e8:24:61:43:59:ec:ea:d2:bb:c9:9a:7a:04:91:
8e:91:bb:9d:33:d4:28:b5:13:ce:dc:fe:c3:e5:33:97:5d:37:
cc:5f:ad:af:5a:aa:f4:a3:a8:50:66:7d:f4:fb:78:72:9d:56:
91:2c
[snip]
Configuring a Local User
Creating a Local User and Adding a User Certificate Using the GUI
Procedure
Step 1
Step 2
On the menu bar, choose ADMIN > AAA.
In the Navigation pane, click AAA Authentication.
Step 3
In the Work pane, verify that in the default Authentication field, the Realm field displays as Local.
Step 4
In the Navigation pane, expand Security Management > Local Users.
The admin user is present by default.
Step 5
In the Navigation pane, right-click Local Users and click Create Local User.
Step 6
In the Security dialog box, choose the desired security domain for the user, and click Next.
Step 7
In the Roles dialog box, click the radio buttons to choose the roles for your user, and click Next.
You can provide read-only or read/write privileges.
Step 8
In the User Identity dialog box, perform the following actions:
a)
b)
c)
d)
In the Login ID field, add an ID.
In the Password field, enter the password.
In the Confirm Password field, confirm the password.
Click Finish.
Step 9
In the Navigation pane, click the name of the user that you created. In the Work pane, expand the + sign next
to your user in the Security Domains area.
The access privileges for your user are displayed.
Step 10 In the Work pane, in the User Certificates area, click the user certificates + sign, and in the Create X509
Certificate dialog box, perform the following actions:
a) In the Name field, enter a certificate name.
b) In the Data field, enter the user certificate details.
c) Click Submit.
The X509 certificate is created for the local user.
Cisco APIC Basic Configuration Guide, Release 2.x
23
User Access, Authentication, and Accounting
Configuring a Local User
Creating a Local User and Adding a User Certificate Using the REST API
Procedure
Create a local user and add a user certificate.
Example:
method: POST
url: http://apic/api/node/mo/uni/userext/user-userabc.json
payload:
{
"aaaUser": {
"attributes": {
"name": "userabc",
"firstName": "Adam",
"lastName": "BC",
"phone": "408-525-4766",
"email": "[email protected]",
},
"children": [{
"aaaUserCert": {
"attributes": {
"name": "userabc.crt",
"data": "-----BEGIN CERTIFICATE-----\nMIICjjCCAfegAwIBAgIJAMQnbE
<snipped content> ==\n-----END CERTIFICATE-----",
},
"children": []
},
"aaaUserDomain": {
"attributes": {
"name": "all",
},
"children": [{
"aaaUserRole": {
"attributes": {
"name": "aaa",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "access-admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "fabric-admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
Cisco APIC Basic Configuration Guide, Release 2.x
24
User Access, Authentication, and Accounting
Configuring a Local User
"name": "nw-svc-admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "ops",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "read-all",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "tenant-admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "tenant-ext-admin",
"privType": "writePriv",
},
"children": []
}
}, {
"aaaUserRole": {
"attributes": {
"name": "vmm-admin",
"privType": "writePriv",
},
"children": []
}
}]
}
}]
}
}
Creating a Local User Using Python SDK
Procedure
Create a local user.
Example:
#!/usr/bin/env python
from cobra.model.pol import
from cobra.model.aaa import
from cobra.model.aaa import
from cobra.model.aaa import
from cobra.model.aaa import
Uni as PolUni
UserEp as AaaUserEp
User as AaaUser
UserCert as AaaUserCert
UserDomain as AaaUserDomain
Cisco APIC Basic Configuration Guide, Release 2.x
25
User Access, Authentication, and Accounting
Configuring a Local User
from
from
from
from
cobra.model.aaa import UserRole as AaaUserRole
cobra.mit.access import MoDirectory
cobra.mit.session import LoginSession
cobra.internal.codec.jsoncodec import toJSONStr
APIC = 'http://10.10.10.1'
username = ‘admin’
password = ‘[email protected]$$w0rd’
session = LoginSession(APIC, username, password)
modir = MoDirectory(session)
modir.login()
def readFile(fileName=None, mode="r"):
if fileName is None:
return ""
fileData = ""
with open(fileName, mode) as aFile:
fileData = aFile.read()
return fileData
#
#
#
#
Use a dictionary to define the domain and a list of tuples to define
our aaaUserRoles (roleName, privType)
This can further be abstracted by doing a query to get the valid
roles, that is what the GUI does
userRoles = {'all': [
('aaa', 'writePriv'),
('access-admin', 'writePriv'),
('admin', 'writePriv'),
('fabric-admin', 'writePriv'),
('nw-svc-admin', 'writePriv'),
('ops', 'writePriv'),
('read-all', 'writePriv'),
('tenant-admin', 'writePriv'),
('tenant-ext-admin', 'writePriv'),
('vmm-admin', 'writePriv'),
],
}
uni = PolUni('') # '' is the Dn string for topRoot
aaaUserEp = AaaUserEp(uni)
aaaUser = AaaUser(aaaUserEp, 'userabc', firstName='Adam',
email='[email protected]')
aaaUser.lastName = 'BC'
aaaUser.phone = '555-111-2222'
aaaUserCert = AaaUserCert(aaaUser, 'userabc.crt')
aaaUserCert.data = readFile("/tmp/userabc.crt")
# Now add each aaaUserRole to the aaaUserDomains which are added to the
# aaaUserCert
for domain,roles in userRoles.items():
aaaUserDomain = AaaUserDomain(aaaUser, domain)
for roleName, privType in roles:
aaaUserRole = AaaUserRole(aaaUserDomain, roleName,
privType=privType)
print toJSONStr(aaaUser, prettyPrint=True)
cr = ConfigRequest()
cr.addMo(aaaUser)
modir.commit(cr)
# End of Script to create a user
Cisco APIC Basic Configuration Guide, Release 2.x
26
User Access, Authentication, and Accounting
Using a Private Key to Calculate a Signature
Using a Private Key to Calculate a Signature
Before You Begin
You must have the following information available:
• HTTP method - GET, POST, DELETE
• REST API URI being requested, including any query options
• For POST requests, the actual payload being sent to the APIC
• The private key used to generate the X.509 certificate for the user
• The distinguished name for the user X.509 certificate on the APIC
Procedure
Step 1
Concatenate the HTTP method, REST API URI, and payload together in this order and save them to a file.
This concatenated data must be saved to a file for OpenSSL to calculate the signature. In this example, we
use a filename of payload.txt. Remember that the private key is in a file called userabc.key.
Example:
GET example:
GET http://10.10.10.1/api/class/fvTenant.json?rsp-subtree=children
POST example:
POST http://10.10.10.1/api/mo/tn-test.json{"fvTenant": {"attributes": {"status": "deleted",
"name": "test"}}}
Step 2
Calculate a signature using the private key and the payload file using OpenSSL.
Example:
openssl dgst -sha256 -sign userabc.key payload.txt > payload_sig.bin
Step 3
The resulting file has the signature printed on multiple lines.
Strip the signature of the new lines using Bash.
Example:
$ tr -d '\n' < payload_sig.base64
P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8fIXXl4V79Zl7
Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f7q
IcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=
This is the signature that will be sent to the APIC for this specific request. Other requests will require
to have their own signatures calculated.
Place the signature inside a string to enable the APIC to verify the signature against the payload.
This complete signature is sent to the APIC as a cookie in the header of the request.
Note
Step 4
Example:
APIC-Request-Signature=P+OTqK0CeAZjl7+Gute2R1Ww8OGgtzE0wsLlx8f
IXXl4V79Zl7Ou8IdJH9CB4W6CEvdICXqkv3KaQszCIC0+Bn07o3qF//BsIplZmYChD6gCX3f
7qIcjGX+R6HAqGeK7k97cNhXlWEoobFPe/oajtPjOu3tdOjhf/9ujG6Jv6Ro=;
APIC-Certificate-Algorithm=v1.0; APIC-Certificate-Fingerprint=fingerprint;
APIC-Certificate-DN=uni/userext/user-userabc/usercert-userabc.crt
Cisco APIC Basic Configuration Guide, Release 2.x
27
User Access, Authentication, and Accounting
Accounting
The DN used here must match the DN of the user certified object containing the x509 certificate in
the next step.
Use the CertSession class in the Python SDK to communicate with an APIC using signatures.
The following script is an example of how to use the CertSession class in the ACI Python SDK to make
requests to an APIC using signatures.
Note
Step 5
Example:
#!/usr/bin/env python
# It is assumed the user has the X.509 certificate already added to
# their local user configuration on the APIC
from cobra.mit.session import CertSession
from cobra.mit.access import MoDirectory
def readFile(fileName=None, mode="r"):
if fileName is None:
return ""
fileData = ""
with open(fileName, mode) as aFile:
fileData = aFile.read()
return fileData
pkey = readFile("/tmp/userabc.key")
csession = CertSession("https://ApicIPOrHostname/",
"uni/userext/user-userabc/usercert-userabc.crt", pkey)
modir = MoDirectory(csession)
resp = modir.lookupByDn('uni/fabric')
pring resp.dn
# End of script
Note
The DN used in the earlier step must match the DN of the user certified object containing the x509
certificate in this step.
Accounting
ACI fabric accounting is handled by these two managed objects (MO) that are processed by the same mechanism
as faults and events:
• The aaaSessionLR MO tracks user account login and logout sessions on the APIC and switches, and
token refresh. The ACI fabric session alert feature stores information such as the following:
◦Username
◦IP address initiating the session
◦Type (telnet, https, REST etc.)
◦Session time and length
◦Token refresh – a user account login event generates a valid active token which is required in order
for the user account to exercise its rights in the ACI fabric.
Note
Token expiration is independent of login; a user could log out but the token expires
according to the duration of the timer value it contains.
Cisco APIC Basic Configuration Guide, Release 2.x
28
User Access, Authentication, and Accounting
Routed Connectivity to External Networks as a Shared Service Billing and Statistics
• The aaaModLR MO tracks the changes users make to objects and when the changes occurred.
• If the AAA server is not pingable, it is marked unavailable and a fault is seen.
Both the aaaSessionLR and aaaModLR event logs are stored in APIC shards. Once the data exceeds the pre-set
storage allocation size, it overwrites records on a first-in first-out basis.
Note
In the event of a destructive event such as a disk crash or a fire that destroys an APIC cluster node, the
event logs are lost; event logs are not replicated across the cluster.
The aaaModLR and aaaSessionLR MOs can be queried by class or by distinguished name (DN). A class query
provides all the log records for the whole fabric. All aaaModLR records for the whole fabric are available from
the GUI at the Fabric > Inventory > POD > History > Audit Log section, The APIC GUI History > Audit
Log options enable viewing event logs for a specific object identified in the GUI.
The standard syslog, callhome, REST query, and CLI export mechanisms are fully supported for aaaModLR
and aaaSessionLR MO query data. There is no default policy to export this data.
There are no pre-configured queries in the APIC that report on aggregations of data across a set of objects or
for the entire system. A fabric administrator can configure export policies that periodically export aaaModLR
and aaaSessionLR query data to a syslog server. Exported data can be archived periodically and used to
generate custom reports from portions of the system or across the entire set of system logs.
Routed Connectivity to External Networks as a Shared Service
Billing and Statistics
The APIC can be configured to collect byte count and packet count billing statistics from a port configured
for routed connectivity to external networks (an l3extInstP EPG) as a shared service. Any EPG in any tenant
can share an l3extInstP EPG for routed connectivity to external networks. Billing statistics can be collected
for each EPG in any tenant that uses an l3extInstP EPG as a shared service. The leaf switch where the
l3extInstP is provisioned forwards the billing statistics to the APIC where they are aggregated. Accounting
policies can be configured to periodically export these billing statics to a server.
Cisco APIC Basic Configuration Guide, Release 2.x
29
User Access, Authentication, and Accounting
Routed Connectivity to External Networks as a Shared Service Billing and Statistics
Cisco APIC Basic Configuration Guide, Release 2.x
30
CHAPTER
4
Management
This chapter contains the following sections:
• Management Workflows, page 31
• Adding Management Access, page 33
• Exporting Tech Support, Statistics, and Core Files, page 47
• Overview, page 50
• Backing up, Restoring, and Rolling Back Controller Configuration, page 61
• Using Syslog, page 70
• Using Atomic Counters, page 74
• Using SNMP, page 77
• Using SPAN, page 81
• Using Traceroute, page 82
Management Workflows
ACI Management Access Workflows
This workflow provides an overview of the steps required to configure management connectivity to switches
in the ACI fabric.
Cisco APIC Basic Configuration Guide, Release 2.x
31
Management
ACI Management Access Workflows
In-band management access
Out-of-band management access
1. Prerequisites
• Ensure that you have read/write access privileges to the infra security domain.
• Ensure that the target leaf switches with the necessary interfaces are available.
2. Configure the ACI Leaf Switch Access Ports
Choose which of these management access scenarios you will use:
• For in-band management, follow the suggested topics for in-band configuration.
• For out-of-band management, follow the suggested topics for out-of-band configuration.
Suggested topics
For additional information, see the following topics:
• Configuring In-Band Management Access Using the Advanced GUI, on page 36
• Configuring In-Band Management Access Using the NX-OS Style CLI, on page 39
• Configuring In-Band Management Access Using the REST API, on page 40
• Configuring Out-of-Band Management Access Using the Advanced GUI, on page 43
• Configuring Out-of-Band Management Access Using the NX-OS Style CLI, on page 45
• Configuring Out-of-Band Management Access Using the REST API, on page 45
Cisco APIC Basic Configuration Guide, Release 2.x
32
Management
Adding Management Access
Adding Management Access
An APIC controller has two routes to reach the management network, one is by using the in-band management
interface and the other is by using the out-of-band management interface.
• In-band management access—You can configure in-band management connectivity to the APIC and
the ACI fabric. You first configure the VLANs that will be used by APIC when the APIC is
communicating with the leaf switches, and then you configure the VLANs that the VMM servers will
use to communicate with the leaf switches.
• Out-of-band management access—You can configure out-of-band management connectivity to the APIC
and the ACI fabric. You configure an out-of-band contract that is associated with an out-of-band endpoint
group (EPG), and attach the contract to the external network profile.
Note
The APIC out-of-band management connection link must be 1 Gbps.
The APIC controller always selects the in-band management interface over the out-of-band management
interface, if the in-band management interface is configured. The out-of-band management interface is used
only when the in-band management interface is not configured, or if the destination address is on the same
subnet as the out-of-band management subnet of the APIC. This behavior cannot be changed or reconfigured.
The APIC management interface does not support an IPv6 address and cannot connect to an external IPv6
server through this interface.
Configuring the external management instance profile under the management tenant for in-band or out-of-band
has no effect on the protocols that are configured under the fabric-wide communication policies. The subnets
and contracts specified under the external management instance profile do not affect HTTP/HTTPS or
SSH/Telnet.
Adding Management Access in the GUI
An APIC controller has two routes to reach the management network, one is by using the in-band management
interface and the other is by using the out-of-band management interface.
The in-band management network allows APIC to communicate with the leaf switches and with the outside
using the ACI fabric, and it makes it possible for external management devices to communicate with the APIC
or the leaf switches and spine switches using the fabric itself.
The out-of-band management network configuration defines the configuration of the management port on the
controllers, the leaf switches and the spine switches.
The APIC controller always selects the in-band management interface over the out-of-band management
interface, if the in-band management interface is configured. The out-of-band management interface is used
only when the in-band management interface is not configured or if the destination address is on the same
subnet as the out-of-band management subnet of the APIC. This behavior cannot be changed or reconfigured.
The APIC management interface does not support an IPv6 address and cannot connect to an external IPv6
server through this interface.
The APIC out-of-band management connection link must be 1 Gbps.
Cisco APIC Basic Configuration Guide, Release 2.x
33
Management
IPv4/IPv6 Addresses and In-Band Policies
IPv4/IPv6 Addresses and In-Band Policies
In-band management addresses can be provisioned on the APIC controller only through a policy (Postman
REST API, NX-OS Style CLI, or GUI). Additionally, the in-band management addresses must be configured
statically on each node.
IPv4/IPv6 Addresses in Out-of-Band Policies
Out-of-band management addresses can be provisioned on the APIC controller either at the time of bootstrap
or by using a policy (Postman REST API, NX-OS Style CLI, GUI). Additionally, the out-of-band management
addresses must be configured statically on each node or by specifying a range of addresses (IPv4/IPv6) to the
entire cluster. IP addresses are randomly assigned from a range to the nodes in the cluster.
IPv6 Table Modifications to Mirror the Existing IP Tables Functionality
All IPv6 tables mirror the existing IP tables functionality, except for Network Address Translation (NAT).
Existing IP Tables
1 Earlier, every rule in the IPv6 tables were executed one at a time and a system call was made for every
rule addition or deletion.
2 Whenever a new policy was added, rules were appended to the existing IP tables file and no extra
modifications were done to the file.
3 When a new source port was configured in the out-of-band policy, it added source and destination rules
with the same port number.
Modifications to IP Tables
1 When IP tables are created, they are first written into hash maps that are then written into intermediate
file IP tables-new which are restored. When saved, a new IP tables file is created in the /etc/sysconfig/
folder. You can find both these files at the same location. Instead of making a system call for every rule,
you must make a system call only while restoring and saving the file.
2 When a new policy is added instead of appending it to the file, an IP table is created from scratch, that is
by loading default policies into the hashmaps, checking for new policies, and adding them to hashmaps.
Later, they are written to the intermediate file (/etc/sysconfig/iptables-new) and saved.
3 It is not possible to configure source ports alone for a rule in out-of-band policy. Either destination port
or source port along with a destination port can be added to the rules.
4 When a new policy is added, a new rule will be added to the IP tables file. This rule changes the access
flow of IP tables default rules.
-A INPUT -s <OOB Address Ipv4/Ipv6> -j apic-default
5 When a new rule is added, it presents in the IP tables-new file and not in the IP tables file, and it signifies
that there is some error in the IP tables-new file. Only if the restoration is successful, the file is saved and
new rules are seen in the IP tables file.
Cisco APIC Basic Configuration Guide, Release 2.x
34
Management
Configuring In-Band Management Access Using the Basic GUI
Note
• If only IPv4 is enabled, do not configure an IPv6 policy.
• If only IPv6 is enabled, do not configure an IPv4 policy.
• If both IPv4 and IPv6 are enabled and a policy is added, it will be configured to both the versions .
So when you add an IPv4 subnet, it will be added to IP tables and similarly an IPv6 subnet is added
to IPv6 tables.
Configuring In-Band Management Access Using the Basic GUI
Note
IPv4 and IPv6 addresses are supported for in-band management access. IPv6 configurations are supported
using static configurations (for both in-band and out-of-band). IPv4 and IPv6 dual in-band and out-of-band
configurations are supported only through static configuration. For more information, see the KB article,
Configuring Static Management Access in Cisco APIC.
Procedure
Step 1
Step 2
Login to the Basic Mode in the APIC GUI, and on the menu bar, click System > In Band & Out Of Band.
In the Navigation pane, choose InBand Management Configuration.
Step 3
(Optional) In the Encap field, enter a new value to change the default VLAN that is used for in-band
management, if desired.
Expand Nodes and perform the following actions:
a) In the Nodes field, choose the appropriate node to associate the in-band address.
b) In the IP address field, enter the desired IPv4 or IPv6 address.
c) In the Gateway field, enter the desired IPv4 or IPv6 gateway address. Click Submit.
Note
The default gateway IP address will be the pervasive gateway of the ACI fabric on the VRF for
the inband management.
Step 4
Step 5
Click the L2 Connectivity tab, expand Ports, and perform the following actions:
a) In the Path field, from the drop-down list, choose the port that is connected to a server for management
or to the outside.
b) In the Encap field, specify a VLAN to use on this port.
Step 6
Expand Gateway IP Address for External Connectivity and in the IP address fields, list the desired gateway
IPv4 and Pv6 address for external connectivity.
Expand ACLs, and add the desired ports that you want to connect to the inband management network. Click
Submit.
Step 7
The in-band management access is now established.
Cisco APIC Basic Configuration Guide, Release 2.x
35
Management
Configuring In-Band Management Access Using the Advanced GUI
Configuring In-Band Management Access Using the Advanced GUI
Note
IPv4 and IPv6 addresses are supported for in-band management access. IPv6 configurations are supported
using static configurations (for both in-band and out-of-band). IPv4 and IPv6 dual in-band and out-of-band
configurations are supported only through static configuration. For more information, see the KB
article,Configuring Static Management Access in Cisco APIC.
Procedure
Step 1
Step 2
On the menu bar, choose FABRIC > Access Policies. In the Navigation pane, expand Interface Policies.
In the Navigation pane, right-click Switch Policies and choose Configure Interface, PC and VPC.
Step 3
In the Configure Interface, PC, and VPC dialog box, to configure switch ports connected to APICs, perform
the following actions:
a) Click the large + icon next to the switch diagram to create a new profile and configure VLANs for the
APIC.
b) From the Switches field drop-down list, check the check boxes for the switches to which the APICs are
connected. (leaf1 and leaf2).
c) In the Switch Profile Name field, enter a name for the profile (apicConnectedLeaves).
d) Click the + icon to configure the ports.
A dialog box similar to the following image is displayed for the user to enter the content:
e)
f)
g)
h)
i)
Verify that in the Interface Type area, the Individual radio button is selected.
In the Interfaces field, enter the ports to which APICs are connected.
In the Interface Selector Name field, enter the name of the port profile (apicConnectedPorts).
In the Interface Policy Group field, click the Create One radio button.
In the Attached Device Type field, choose the appropriate device type to configure the domain (Bare
Metal).
j) In the Domain field, click the Create One radio button.
k) In the Domain Name field, enter the domain name. (inband)
Cisco APIC Basic Configuration Guide, Release 2.x
36
Management
Configuring In-Band Management Access Using the Advanced GUI
l) In the VLAN field, choose the Create One radio button.
m) In the VLAN Range field, enter the VLAN range. Click Save, and click Save again. Click Submit.
Step 4
In the Navigation pane, right-click Switch Policies and choose Configure Interface, PC and VPC.
Step 5
In the Configure Interface, PC, and VPC dialog box, perform the following actions:
a) Click the large + icon next to the switch diagram to create a new profile and configure VLANs for the
server.
b) In the Switches field, from drop-down list, check the check boxes for the switches to which the servers
are connected. (leaf1).
c) In the Switch Profile Name field, enter a name for the profile (vmmConnectedLeaves).
d) Click the + icon to configure the ports.
A dialog box similar to the following image is displayed for the user to enter the content:
e)
f)
g)
h)
i)
j)
k)
l)
m)
Verify that in the Interface Type area, the Individual radio button is selected.
In the Interfaces field, enter the ports to which the servers are connected (1/40).
In the Interface Selector Name field, enter the name of the port profile.
In the Interface Policy Group field, click the Create One radio button.
In the Attached Device Type field, choose the appropriate device type to configure the domain (Bare
Metal).
In the Domain field, from the drop-down list click the Choose One radio button
From the Physical Domain drop-down list, choose the domain created earlier.
In the Domain Name field, enter the domain name.
Click Save, and click Save again.
Step 6
In the Configure Interface, PC, and VPC dialog box, click Submit.
Step 7
On the menu bar, click TENANTS > mgmt. In the Navigation pane, expand Tenant mgmt > Networking
> Bridge Domains to configure the bridge domain on the in-band connection.
Expand the in-band bridge domain (inb). Right-click Subnets. Click Create Subnet and perform the following
actions to configure the in-band gateway:
a) In the Create Subnet dialog box, in the Gateway IP field, enter the in-band management gateway IP
address and mask.
Step 8
Cisco APIC Basic Configuration Guide, Release 2.x
37
Management
Configuring In-Band Management Access Using the Advanced GUI
b) Click Submit.
Step 9
In the Navigation pane, expand Tenant mgmt > Node Management EPGs. Right-click Node Management
EPGs and choose Create In-Band Management EPG. Perform the following actions to set the VLAN on
the in-band EPG used to communicate with the APIC:
a) In the Name field, enter the in-band management EPG name.
b) In the Encap field, enter the VLAN (vlan-10).
c) From the Bridge Domain drop-down field, choose the bridge domain. Click Submit.
d) In the Navigation pane, choose the newly created in-band EPG.
e) Expand Provided Contracts. In the Name field, from the drop-down list, choose the default contract to
enable EPG to provide the default contract that will be consumed by the EPGs on which the VMM servers
are located.
f) Click Update, and click Submit.
A dialog box similar to the following image is displayed:
Step 10 In the Navigation pane, right-click Node Management Addresses and click Create Node Management
Addresses, and perform the following actions to configure the IP addresses to be assigned to APIC controllers
in the fabric:
a) In the Create Node Management Addresses dialog box, in the Policy Name field, enter the policy name
(apicInb).
b) In the Nodes field, Select column, check the check boxes for the nodes that will be part of this fabric
(apic1, apic2, apic3).
c) In the Config field, check the In-Band Addresses check box.
d) In the Node Range fields, enter the range.
e) In the In-Band IP Addresses area, in the In-Band Management EPG field, from the drop-down list,
choose default. This associates the default in-band Management EPG.
f) In the In-Band IP Addresses and Gateway fields, enter the IPv4 or IPv6 addresses as desired.
Cisco APIC Basic Configuration Guide, Release 2.x
38
Management
Configuring In-Band Management Access Using the NX-OS Style CLI
g) Click Submit. The IP addresses for the APICs are now configured.
Step 11 In the Navigation pane, right-click Node Management Addresses. Click Create Node Management
Addresses, and perform the following actions to configure the IP addresses for the leaf and spine switches
in the fabric:
a) In the Create Node Management Addresses dialog box, in the Policy Name field, enter the policy name
(switchInb).
b) In the Nodes field, Select column, check the check boxes next to the nodes that will be part of this fabric
(leaf1, leaf2, spine1, spine2).
c) In the Config field, click the In-Band Addresses checkbox.
d) In the Node Range fields, enter the range.
e) In the In-Band IP Addresses area, in the In-Band Management EPG field, from the drop-down list,
choose default. The default in-band management EPG is now associated.
f) In the In-Band IP Addresses and Gateway fields, enter the IPv4 or IPv6 addresses as desired.
g) Click Submit. In the Confirm dialog box, click Yes. The IP addresses for the leaf and spine switches are
now configured.
Step 12 In the Navigation pane, under Node Management Addresses, click the APIC policy name (apicInb) to verify
the configurations. In the Work pane, the IP addresses assigned to various nodes are displayed.
Step 13 In the Navigation pane, under Node Management Addresses, click the switches policy name (switchInb).
In the Work pane, the IP addresses that are assigned to switches and the gateway addresses they are using
are displayed.
Note
You can make out-of-band management access the default management connectivity mode for the
APIC server by clicking Fabric > Fabric Policies > Global Policies > Connectivity Preferences.
Then on the Connectivity Preferences page, click inband.
Configuring In-Band Management Access Using the NX-OS Style CLI
Procedure
Step 1
Assign a VLAN for the APIC inband management, as shown in the following example:
Example:
apic1(config)#
apic1(config)# vlan-domain inband-mgmt
apic1(config-vlan) vlan 10
apic1(config-vlan) exit
Step 2
Provide external connectivity to the inband management ports, as shown in the following example:
Example:
Cisco APIC Basic Configuration Guide, Release 2.x
39
Management
Configuring In-Band Management Access Using the REST API
Note
In this step, the controller is connected to a port on a leaf switch. You must add a VLAN domain
member on that port. In this example, in leaf 101, the port ethernet 1/2 is connected to controller 1.
You are configuring the VLAN domain member "inband management". This is one part of the
connection. The other part is that the management station is connected to leaf 102, interface ethernet
1/3. A controller is one machine connected one port on the leaf switch, which in this case is leaf 102.
The machine is trying to connect to the controller from the outside (ethernet 1/3).
apic1(config)#
apic1(config)# leaf 101
apic1(config-leaf) internet ethernet 1/2
apic1(config-leaf-if)# vlan-domain member inband-mgmt
apic1(config-leaf-if)# exit
apic1(config)# leaf 102
apic1(config-leaf) internet ethernet 1/3
apic1(config-leaf-if)# vlan-domain member inband-mgmt
apic1(config-leaf-if)# switchport trunk allowed vlan
apic1(config-leaf-if)# exit
Note
You can make in-band management access the default management connectivity mode for the APIC
server using the following CLI command sequence:
apic1# configure
apic1(config)# mgmt_connectivity pref inband
Configuring In-Band Management Access Using the REST API
IPv4 and IPv6 addresses are supported for in-band management access. IPv6 configurations are supported
using static configurations (for both in-band and out-of-band). IPv4 and IPv6 dual in-band and out-of-band
configurations are supported only through static configuration. For more information, see the KB
article,Configuring Static Management Access in Cisco APIC.
Procedure
Step 1
Create a VLAN namespace.
Example:
POST
https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/uni.xml -->
<polUni>
<infraInfra>
<!-- Static VLAN range -->
<fvnsVlanInstP name="inband" allocMode="static">
<fvnsEncapBlk name="encap" from="vlan-10" to="vlan-11"/>
</fvnsVlanInstP>
</infraInfra>
</polUni>
Step 2
Create a physical domain.
Example:
POST
https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/uni.xml -->
Cisco APIC Basic Configuration Guide, Release 2.x
40
Management
Configuring In-Band Management Access Using the REST API
<polUni>
<physDomP name="inband">
<infraRsVlanNs tDn="uni/infra/vlanns-inband-static"/>
</physDomP>
</polUni>
Step 3
Create selectors for the in-band management.
Example:
POST
https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/.xml -->
<polUni>
<infraInfra>
<infraNodeP name="vmmNodes">
<infraLeafS name="leafS" type="range">
<infraNodeBlk name="single0" from_="101" to_="101"/>
</infraLeafS>
<infraRsAccPortP tDn="uni/infra/accportprof-vmmPorts"/>
</infraNodeP>
<!-- Assumption is that VMM host is reachable via eth1/40. -->
<infraAccPortP name="vmmPorts">
<infraHPortS name="portS" type="range">
<infraPortBlk name="block1"
fromCard="1" toCard="1"
fromPort="40" toPort="40"/>
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accportgrp-inband" />
</infraHPortS>
</infraAccPortP>
<infraNodeP name="apicConnectedNodes">
<infraLeafS name="leafS" type="range">
<infraNodeBlk name="single0" from_="101" to_="102"/>
</infraLeafS>
<infraRsAccPortP tDn="uni/infra/accportprof-apicConnectedPorts"/>
</infraNodeP>
<!-- Assumption is that APIC is connected to eth1/1. -->
<infraAccPortP name="apicConnectedPorts">
<infraHPortS name="portS" type="range">
<infraPortBlk name="block1"
fromCard="1" toCard="1"
fromPort="1" toPort="3"/>
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accportgrp-inband" />
</infraHPortS>
</infraAccPortP>
<infraFuncP>
<infraAccPortGrp name="inband">
<infraRsAttEntP tDn="uni/infra/attentp-inband"/>
</infraAccPortGrp>
</infraFuncP>
<infraAttEntityP name="inband">
<infraRsDomP tDn="uni/phys-inband"/>
</infraAttEntityP>
</infraInfra>
</polUni>
Step 4
Configure an in-band bridge domain and endpoint group (EPG).
Example:
POST https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/.xml -->
Cisco APIC Basic Configuration Guide, Release 2.x
41
Management
Configuring In-Band Management Access Using the REST API
<polUni>
<fvTenant name="mgmt">
<!-- Configure the in-band management gateway address on the
in-band BD. -->
<fvBD name="inb">
<fvSubnet ip="10.13.1.254/24"/>
</fvBD>
<mgmtMgmtP name="default">
<!-- Configure the encap on which APICs will communicate on the
in-band network. -->
<mgmtInB name="default" encap="vlan-10">
<fvRsProv tnVzBrCPName="default"/>
</mgmtInB>
</mgmtMgmtP>
</fvTenant>
</polUni>
Step 5
Create an address pool.
Example:
POST
https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/.xml -->
<polUni>
<fvTenant name="mgmt">
<!-- Adresses for APIC in-band management network -->
<fvnsAddrInst name="apicInb" addr="10.13.1.254/24">
<fvnsUcastAddrBlk from="10.13.1.1" to="10.13.1.10"/>
</fvnsAddrInst>
<!-- Adresses for switch in-band management network -->
<fvnsAddrInst name="switchInb" addr="10.13.1.254/24">
<fvnsUcastAddrBlk from="10.13.1.101" to="10.13.1.120"/>
</fvnsAddrInst>
</fvTenant>
</polUni>
Dynamic address pools for IPv6 is not
supported.
Create management groups.
Note
Step 6
Example:
POST
https://apic-ip-address/api/mo/uni.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- api/policymgr/mo/.xml -->
<polUni>
<infraInfra>
<!-- Management node group for APICs -->
<mgmtNodeGrp name="apic">
<infraNodeBlk name="all" from_="1" to_="3"/>
<mgmtRsGrp tDn="uni/infra/funcprof/grp-apic"/>
</mgmtNodeGrp>
<!-- Management node group for switches-->
<mgmtNodeGrp name="switch">
<infraNodeBlk name="all" from_="101" to_="104"/>
<mgmtRsGrp tDn="uni/infra/funcprof/grp-switch"/>
</mgmtNodeGrp>
<!-- Functional profile -->
<infraFuncP>
<!-- Management group for APICs -->
<mgmtGrp name="apic">
<!-- In-band management zone -->
<mgmtInBZone name="default">
Cisco APIC Basic Configuration Guide, Release 2.x
42
Management
Configuring Out-of-Band Management Access Using the Basic GUI
<mgmtRsInbEpg tDn="uni/tn-mgmt/mgmtp-default/inb-default"/>
<mgmtRsAddrInst tDn="uni/tn-mgmt/addrinst-apicInb"/>
</mgmtInBZone>
</mgmtGrp>
<!-- Management group for switches -->
<mgmtGrp name="switch">
<!-- In-band management zone -->
<mgmtInBZone name="default">
<mgmtRsInbEpg tDn="uni/tn-mgmt/mgmtp-default/inb-default"/>
<mgmtRsAddrInst tDn="uni/tn-mgmt/addrinst-switchInb"/>
</mgmtInBZone>
</mgmtGrp>
</infraFuncP>
</infraInfra>
</polUni>
Note
Dynamic address pools for IPv6 is not
supported.
Configuring Out-of-Band Management Access Using the Basic GUI
Note
IPv4 and IPv6 addresses are supported for out-of-band management access.
Procedure
Step 1
Step 2
Log in to the Basic Mode of the APIC GUI, and on the menu bar, choose System > In Band & Out Of Band.
In the Navigation pane, click Out-of-Band EPG - default.
Step 3
In the Work pane, under Properties, expand Nodes and associate the appropriate nodes with an IPv4 or IPv6
address and a default gateway. Click Update.
Expand Access Restrictions, and add the list of desired external subnets that will communicate with the
out-of-band management address of the ACI fabric nodes.
Expand ACLs for external subnets and enter the appropriate information for the L4 ports that you want to
allow for management of the ACI fabric nodes.
The out-of-band management access is now configured.
Step 4
Step 5
Configuring Out-of-Band Management Access Using the Advanced GUI
Note
IPv4 and IPv6 addresses are supported for out-of-band management access.
Before You Begin
The APIC out-of-band management connection link must be 1 Gbps.
Cisco APIC Basic Configuration Guide, Release 2.x
43
Management
Configuring Out-of-Band Management Access Using the Advanced GUI
Procedure
Step 1
On the menu bar, choose TENANTS > mgmt. In the Navigation pane, expand Tenant mgmt.
Step 2
Step 3
Right-click Node Management Addresses, and click Create Node Management Addresses.
In the Create Node Management Addresses dialog box, perform the following actions:
Step 4
a) In the Policy Name field, enter a policy name (switchOob).
b) In the Nodes field, check the check boxes next to the appropriate leaf and spine switches (leaf1, leaf2,
spine1).
c) In the Config field, check the check box for Out of-Band Addresses.
Note
The Out-of-Band IP addresses area is
displayed.
d) In the Out-of-Band Management EPG field, choose the EPG from the drop-down list (default).
e) In the Out-of-Band IP Addresses and Out-of-Band Gateway fields, enter the desired IPv4 or IPv6 addresses
that will be assigned to the switches. Click OK.
The node management IP addresses are configured. You must configure out-of-band management access
addresses for the leaf and spine switches as well as for APIC.
In the Navigation pane, expand Node Management Addresses, and click the policy that you created.
In the Work pane, the out-of-band management addresses are displayed against the switches.
Step 5
In the Navigation pane, expand Security Policies > Out-of-Band Contracts.
Step 6
Step 7
Right-click Out-of-Band Contracts, and click Create Out-of-Band Contract.
In the Create Out-of-Band Contract dialog box, perform the following tasks:
a) In the Name field, enter a name for the contract (oob-default).
b) Expand Subjects. In the Create Contract Subject dialog box, in the Name field, enter a subject name
(oob-default).
c) Expand Filters, and in the Name field, from the drop-down list, choose the name of the filter (default).
Click Update, and click OK.
d) In the Create Out-of-Band Contract dialog box, click Submit.
Step 8
An out-of-band contract that can be applied to the out-of-band EPG is created.
In the Navigation pane, expand Node Management EPGs > Out-of-Band EPG - default.
Step 9
In the Work pane, expand Provided Out-of-Band Contracts.
Step 10 In the OOB Contract column, from the drop-down list, choose the out-of-band contract that you created
(oob-default). Click Update, and click Submit.
The contract is associated with the node management EPG.
Step 11 In the Navigation pane, right-click External Network Instance Profile, and click Create External
Management Entity Instance.
Step 12 In the Create External Management Entity Instance dialog box, perform the following actions:
a) In the Name field, enter a name (oob-mgmt-ext).
b) Expand the Consumed Out-of-Band Contracts field. From the Out-of-Band Contract drop-down list,
choose the contract that you created (oob-default). Click Update.
Choose the same contract that was provided by the out-of-band management.
c) In the Subnets field, enter the subnet address. Click Submit.
Only the subnet addresses you choose here will be used to manage the switches. The subnet addresses that
are not included cannot be used to manage the switches.
Cisco APIC Basic Configuration Guide, Release 2.x
44
Management
Configuring Out-of-Band Management Access Using the NX-OS Style CLI
The node management EPG is attached to the external network instance profile. The out-of-band management
connectivity is configured.
Note
You can make out-of-band management access the default management connectivity mode for the
APIC server by clicking Fabric > Fabric Policies > Global Policies > Connectivity Preferences.
Then on the Connectivity Preferences page, click ooband.
Configuring Out-of-Band Management Access Using the NX-OS Style CLI
Before You Begin
The APIC out-of-band management connection link must be 1 Gbps.
Procedure
Provide access control for out-of-band management interface to external management subnets as follows:
Example:
apic1(config-tenant)# external-l3 epg default oob-mgmt
apic1(config-tenant-l3ext-epg)#match ip 10.0.0.0/8
apic1(config-tenant-l3ext-epg)# exit
apic1(config)# exit
Note
You can make out-of-band management access the default management connectivity mode for the
APIC server using the following CLI command sequence:
apic1 # configure
apic1(config)# mgmt_connectivity pref ooband
Configuring Out-of-Band Management Access Using the REST API
IPv4 and IPv6 addresses are supported for out-of-band management access.
Before You Begin
The APIC out-of-band management connection link must be 1 Gbps.
Procedure
Step 1
Create an out-of-band contract.
Example:
POST https://apic-ip-address/api/mo/uni.xml
<polUni>
<fvTenant name="mgmt">
<!-- Contract -->
<vzOOBBrCP name="oob-default">
<vzSubj name="oob-default">
<vzRsSubjFiltAtt tnVzFilterName="default" />
</vzSubj>
</vzOOBBrCP>
Cisco APIC Basic Configuration Guide, Release 2.x
45
Management
Configuring Out-of-Band Management Access Using the REST API
</fvTenant>
</polUni>
Step 2
Associate the out-of-band contract with an out-of-band EPG.
Example:
POST https://apic-ip-address/api/mo/uni.xml
<polUni>
<fvTenant name="mgmt">
<mgmtMgmtP name="default">
<mgmtOoB name="default">
<mgmtRsOoBProv tnVzOOBBrCPName="oob-default" />
</mgmtOoB>
</mgmtMgmtP>
</fvTenant>
</polUni>
Step 3
Associate the out-of-band contract with an external management EPG.
Example:
POST https://apic-ip-address/api/mo/uni.xml
<polUni>
<fvTenant name="mgmt">
<mgmtExtMgmtEntity name="default">
<mgmtInstP name="oob-mgmt-ext">
<mgmtRsOoBCons tnVzOOBBrCPName="oob-default" />
<!-- SUBNET from where switches are managed -->
<mgmtSubnet ip="10.0.0.0/8" />
</mgmtInstP>
</mgmtExtMgmtEntity>
</fvTenant>
</polUni>
Step 4
Create a management address pool.
Example:
POST https://apic-ip-address/api/mo/uni.xml
<polUni>
<fvTenant name="mgmt">
<fvnsAddrInst name="switchOoboobaddr" addr="172.23.48.1/21">
<fvnsUcastAddrBlk from="172.23.49.240" to="172.23.49.244"/>
</fvnsAddrInst>
</fvTenant>
</polUni>
Step 5
Create node management groups.
Example:
POST https://apic-ip-address/api/mo/uni.xml
<polUni>
<infraInfra>
<infraFuncP>
<mgmtGrp name="switchOob">
<mgmtOoBZone name="default">
<mgmtRsAddrInst tDn="uni/tn-mgmt/addrinst-switchOoboobaddr" />
<mgmtRsOobEpg tDn="uni/tn-mgmt/mgmtp-default/oob-default" />
</mgmtOoBZone>
</mgmtGrp>
</infraFuncP>
<mgmtNodeGrp name="switchOob">
<mgmtRsGrp tDn="uni/infra/funcprof/grp-switchOob" />
Cisco APIC Basic Configuration Guide, Release 2.x
46
Management
Exporting Tech Support, Statistics, and Core Files
<infraNodeBlk name="default" from_="101" to_="103" />
</mgmtNodeGrp>
</infraInfra>
</polUni>
Note
You can configure the APIC server to use out-of-band management connectivity as the default
connectivity mode.
POST https://apic-ip-address/api/node/mo/.xml
<polUni>
<fabricInst>
<mgmtConnectivityPrefs interfacePref=“ooband"/>
</fabricInst>
</polUni>
Exporting Tech Support, Statistics, and Core Files
About Exporting Files
An administrator can configure export policies in the APIC to export statistics, technical support collections,
faults and events, to process core files and debug data from the fabric (the APIC as well as the switch) to any
external host. The exports can be in a variety of formats, including XML, JSON, web sockets, secure copy
protocol (SCP), or HTTP. You can subscribe to exports in streaming, periodic, or on-demand formats.
An administrator can configure policy details such as the transfer protocol, compression algorithm, and
frequency of transfer. Policies can be configured by users who are authenticated using AAA. A security
mechanism for the actual transfer is based on a username and password. Internally, a policy element handles
the triggering of data.
File Export Guidelines and Restrictions
• HTTP export and the streaming API format is supported only with statistics information. Core and Tech
Support data are not supported.
• The destination IP for exported files cannot be an IPv6 address.
Note
Do not trigger Tech Support from more than five nodes simultaneously, especially if they are to be
exported into the APIC or to an external server with insufficient bandwidth and compute resources.
In order to collect Tech Support from all the nodes in the fabric periodically, you must create multiple
policies. Each policy must cover a subset of the nodes and should be scheduled to trigger in a staggered
way (at least 30 minutes apart).
Cisco APIC Basic Configuration Guide, Release 2.x
47
Management
Creating a Remote Location for Exporting Files
Creating a Remote Location for Exporting Files
This procedure configures the host information and file transfer settings for a remote host that will receive
exported files.
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Admin.
In the submenu bar, click Import/Export.
In the Navigation pane, expand Export Policies.
Step 4
Step 5
Right-click Remote Locations and choose Create Remote Path of a File.
In the Create Remote Path of a File dialog box, perform the following actions:
a)
b)
c)
d)
e)
f)
g)
In the Name field, enter a name for the remote location.
In the Host Name/IP field, enter an IP address or a fully qualified domain name for the destination host.
In the Protocol field, click the radio button for the desired file transfer protocol.
In the Remote Path field, type the path where the file will be stored on the remote host.
Enter a username and password for logging in to the remote host and confirm the Password.
From the Management EPG drop-down list, choose the management EPG.
Click Submit.
Sending an On-Demand Techsupport File Using the GUI
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Admin.
In the submenu bar, click Import/Export.
In the Navigation pane, expand Export Policies.
Step 4
Right-click On-demand TechSupport and choose Create On-demand TechSupport.
The Create On-demand TechSupport dialog box appears.
Step 5
Enter the appropriate values in the fields of the Create On-demand TechSupport dialog box.
Note
For an explanation of a field, click the information (i) icon in the Create On-demand TechSupport
dialog box. The help file opens to a properties description page.
Click Submit to send the techsupport file.
Note
On-demand tech support files can be saved to another APIC to balance storage and CPU requirements.
To verify the location, click on the On-demand TechSupport policy in the Navigation pane, then
click the OPERATIONAL tab in the Work pane. The controller is displayed in the EXPORT
LOCATION field.
Right-click the policy name and choose Collect Tech Support.
Choose Yes to begin collecting tech support information.
Step 6
Step 7
Step 8
Cisco APIC Basic Configuration Guide, Release 2.x
48
Management
Sending an On-Demand Techsupport File Using the NX-OS Style CLI
Sending an On-Demand Techsupport File Using the NX-OS Style CLI
Note
Do not trigger techsupport file collection from more than five nodes simultaneously, especially if they are
to be exported into the APIC or to an external server with insufficient bandwidth and compute resources.
To avoid excessive storage usage in APIC, remove locally-stored techsupport files promptly.
Before You Begin
Configure a remote path for exporting the techsupport file.
Procedure
Step 1
Command or Action
Purpose
trigger techsupport {all | controllers
switch node-id} [remotename
remote-path-name]
Triggers the export of a techsupport file from the
controllers, switches, or all to the remote path. For
switches, you can specify a range or a
comma-separated list. If no remote host is specified,
the file is collected in the controller itself.
Example:
apic1# trigger techsupport switch
101,103 remotename remote5
Step 2
trigger techsupport host host-id
Example:
Triggers the export of a techsupport file from the
specified host to the remote host. If no remote host is
specified, the file is collected in the controller itself.
apic1# trigger techsupport host
Step 3
trigger techsupport local
Example:
Triggers the export of a local techsupport file to the
remote host. If no remote host is specified, the file is
collected in the controller itself.
apic1# trigger techsupport local
Step 4
show techsupport {all | controllers switch After a techsupport file is triggered, this command
shows the status of the techsupport report.
node-id} status
Example:
apic1# show techsupport switch 101
status
Examples
This example shows how to trigger a techsupport file for switch 101, to be stored locally on the apic1 controller.
apic1# trigger techsupport switch 101
Triggering techsupport for Switch 101 using policy supNode101, setting filters to default
value
Cisco APIC Basic Configuration Guide, Release 2.x
49
Management
Sending an On-Demand TechSupport File Using the REST API
Triggered on demand tech support successfully for Switch 101, will be available at:
/data/techsupport on
the controller. Use 'show techsupport' with your options to check techsupport status.
Sending an On-Demand TechSupport File Using the REST API
Procedure
Step 1
Set the remote destination for a technical support file using the REST API, by sending a POST with XML
such as the following example:
Example:
<fileRemotePath userName="" remotePort="22" remotePath="" protocol="sftp" name="ToSupport"
host="192.168.200.2"
dn="uni/fabric/path-ToSupport" descr="">
<fileRsARemoteHostToEpg tDn="uni/tn-mgmt/mgmtp-default/oob-default"/>
</fileRemotePath>
Step 2
Generate an on-demand technical support file using the REST API by sending a POST with XML such as the
following:
Example:
<dbgexpTechSupOnD upgradeLogs="no" startTime="unspecified" name="Tech_Support_9-20-16"
exportToController="no"
endTime="unspecified" dn="uni/fabric/tsod-Tech_Support_9-20-16" descr="" compression="gzip"
category="forwarding" adminSt="untriggered">
<dbgexpRsExportDest tDn="uni/fabric/path-ToSupport"/>
<dbgexpRsTsSrc tDn="topology/pod-1/node-102/sys"/>
<dbgexpRsTsSrc tDn="topology/pod-1/node-103/sys"/>
<dbgexpRsTsSrc tDn="topology/pod-1/node-101/sys"/>
<dbgexpRsData tDn="uni/fabric/tscont"/>
</dbgexpTechSupOnD>
Overview
This topic provides information on:
• How to use configuration Import and Export to recover configuration states to the last known good state
using the Cisco APIC
• How to encrypt secure properties of Cisco APIC configuration files
You can do both scheduled and on-demand backups of user configuration. Recovering configuration states
(also known as "roll-back") allows you to go back to a known state that was good before. The option for that
is called an Atomic Replace. The configuration import policy (configImportP) supports atomic + replace
Cisco APIC Basic Configuration Guide, Release 2.x
50
Management
Configuration File Encryption
(importMode=atomic, importType=replace). When set to these values, the imported configuration overwrites
the existing configuration, and any existing configuration that is not present in the imported file is deleted.
As long as you do periodic configuration backups and exports, or explicitly trigger export with a known good
configuration, then you can later restore back to this configuration using the following procedures for the CLI,
REST API, and GUI.
For more detailed conceptual information about recovering configuration states using the Cisco APIC, please
refer to the Cisco Application Centric Infrastructure Fundamentals Guide.
The following section provides conceptual information about encrypting secure properties of configuration
files:
Configuration File Encryption
As of release 1.1(2), the secure properties of APIC configuration files can be encrypted by enabling AES-256
encryption. AES encryption is a global configuration option; all secure properties conform to the AES
configuration setting. It is not possible to export a subset of the ACI fabric configuration such as a tenant
configuration with AES encryption while not encrypting the remainder of the fabric configuration. See the
Cisco Application Centric Infrastructure Fundamentals Appendix K: Secure Properties for the list of secure
properties.
The APIC uses a 16 to 32 character passphrase to generate the AES-256 keys. The APIC GUI displays a hash
of the AES passphrase. This hash can be used to see if the same passphrases was used on two ACI fabrics.
This hash can be copied to a client computer where it can be compared to the passphrase hash of another ACI
fabric to see if they were generated with the same passphrase. The hash cannot be used to reconstruct the
original passphrase or the AES-256 keys.
Observe the following guidelines when working with encrypted configuration files:
• Backward compatibility is supported for importing old ACI configurations into ACI fabrics that use the
AES encryption configuration option.
Note
Reverse compatibility is not supported; configurations exported from ACI fabrics that
have enabled AES encryption cannot be imported into older versions of the APIC
software.
• Always enable AES encryption when performing fabric backup configuration exports. Doing so will
assure that all the secure properties of the configuration will be successfully imported when restoring
the fabric.
Note
If a fabric backup configuration is exported without AES encryption enabled, none of
the secure properties will be included in the export. Since such an unencrypted backup
would not include any of the secure properties, it is possible that importing such a file
to restore a system could result in the administrator along with all users of the fabric
being locked out of the system.
• The AES passphrase that generates the encryption keys cannot be recovered or read by an ACI
administrator or any other user. The AES passphrase is not stored. The APIC uses the AES passphrase
to generate the AES keys, then discards the passphrase. The AES keys are not exported. The AES keys
cannot be recovered since they are not exported and cannot be retrieved via the REST API.
Cisco APIC Basic Configuration Guide, Release 2.x
51
Management
Configuring a Remote Location Using the GUI
• The same AES-256 passphrase always generates the same AES-256 keys. Configuration export files
can be imported into other ACI fabrics that use the same AES passphrase.
• For troubleshooting purposes, export a configuration file that does not contain the encrypted data of the
secure properties. Temporarily turning off encryption before performing the configuration export removes
the values of all secure properties from the exported configuration. To import such a configuration file
that has all secure properties removed, use the import merge mode; do not use the import replace mode.
Using the import merge mode will preserve the existing secure properties in the ACI fabric.
• By default, the APIC rejects configuration imports of files that contain fields that cannot be decrypted.
Use caution when turning off this setting. Performing a configuration import inappropriately when this
default setting is turned off could result in all the passwords of the ACI fabric to be removed upon the
import of a configuration file that does not match the AES encryption settings of the fabric.
Note
Failure to observe this guideline could result in all users, including fabric administrations,
being locked out of the system.
Configuring a Remote Location Using the GUI
This procedure explains how to create a remote location using the APIC GUI.
Procedure
Step 1
Step 2
On the menu bar, choose ADMIN > Import/Export.
In the navigation pane, right-click Remote Locations and choose Create Remote Location.
The Create Remote Location dialog appears.
Step 3
Enter the appropriate values in the Create Remote Location dialog fields.
Note
For an explanation of a field, click the 'i' icon to display the help
file.
When finished entering values in the Create Remote Location dialog fields, click Submit.
You have now created a remote location for backing up your data.
Step 4
Configuring a Remote Location Using the NX-OS Style CLI
In the ACI fabric, you can configure one or more remote destinations for exporting techsupport or configuration
files.
Cisco APIC Basic Configuration Guide, Release 2.x
52
Management
Configuring a Remote Location Using the REST API
Procedure
Step 1
Command or Action
Purpose
configure
Enters global configuration mode.
Example:
apic1# configure
Step 2
[no] remote path remote-path-name
Enters configuration mode for a remote path.
Example:
apic1(config)# remote path myFiles
Step 3
user username
Sets the user name for logging in to the
remote server. You are prompted for a
password.
Example:
apic1(config-remote)# user admin5
Step 4
path {ftp | scp | sftp} host[ :port ]
[remote-directory ]
Sets the path and protocol to the remote
server. You are prompted for a password.
Example:
apic1(config-remote)# path sftp
filehost.example.com:21 remote-directory
/reports/apic
Examples
This example shows how to configure a remote path for exporting files.
apic1# configure
apic1(config)# remote path myFiles
apic1(config-remote)# user admin5
You must reset the password when modifying the path:
Password:
Retype password:
apic1(config-remote)# path sftp filehost.example.com:21 remote-directory /reports/apic
You must reset the password when modifying the path:
Password:
Retype password:
Configuring a Remote Location Using the REST API
This procedure explains how to create a remote location using the REST API.
<fileRemotePath name="local" host=“host or ip" protocol=“ftp|scp|sftp" remotePath=“path to
folder" userName=“uname" userPasswd=“pwd" />
Cisco APIC Basic Configuration Guide, Release 2.x
53
Management
Configuring an Export Policy Using the GUI
Configuring an Export Policy Using the GUI
This procedure explains how to configure an Export policy using the APIC GUI. Follow these steps to trigger
a backup of your data:
Procedure
Step 1
Step 2
On the menu bar, choose Admin > Import/Export.
In the navigation pane, right-click Export Policies and choose Create Configuration Export Policy.
The Create Configuration Export Policy dialog appears.
Step 3
Enter the appropriate values in the Create Configuration Export Policy dialog fields.
Note
For an explanation of a field, click the 'i' icon to display the help
file.
When finished entering values in the Create Configuration Export Policy dialog fields, click Submit.
You have now created a backup. You can view this under the Configuration tab. (The backup file will show
in the Configuration pane on the right side). There's an Operational tab where you can see if it's running,
successful, or failed. If you didn't trigger it yet, it is empty. If you created a backup, it creates a file that is
shown in the Operational view of the backup file that was created. If you want to then import that data, you
must create an Import policy.
Step 4
Configuring an Export Policy Using the NX-OS Style CLI
Before You Begin
If you want to export snapshots according to a schedule, configure a scheduler before configuring the export
policy.
Procedure
Step 1
Command or Action
Purpose
configure
Enters global configuration mode.
Example:
apic1# configure
Step 2
[no] snapshot export policy-name
Creates a policy for exporting snapshots.
Example:
apic1(config)# snapshot export
myExportPolicy
Step 3
format {xml | json}
Example:
apic1(config-export)# format json
Cisco APIC Basic Configuration Guide, Release 2.x
54
Specifies the data format for the exported
configuration file.
Management
Configuring an Export Policy Using the REST API
Step 4
Command or Action
Purpose
[no] schedule schedule-name
(Optional)
Specifies an existing scheduler for exporting
snapshots.
Example:
apic1(config-export)# schedule
EveryEightHours
Step 5
[no] target [infra | fabric | tenant-name]
Example:
apic1(config-export)# target
tenantExampleCorp
Step 6
[no] remote path remote-path-name
apic1(config-export)# remote path
myBackupServer
(Optional)
Specifies the name of a configured remote path to
which the file will be sent. If no remote path is
specified, the file is exported locally to a folder in
the controller. The default is no remote path.
end
Returns to EXEC mode.
Example:
Step 7
(Optional)
Assigns the target of the export, which can be
fabric, infra, a specific tenant, or none. If no target
is specified, all configuration information is
exported. The default is no target.
Example:
apic1(config-export)# end
Step 8
trigger snapshot export policy-name
Executes the snapshot export task. If the export
policy is configured with a scheduler, this step is
unnecessary unless you want an immediate export.
Example:
apic1# trigger snapshot export
myExportPolicy
Examples
This example shows how to configure the periodic export of a JSON-format snapshot file for a specific tenant
configuration.
apic1# configure
apic1(config)# snapshot export myExportPolicy
apic1(config-export)# format json
apic1(config-export)# target tenantExampleCorp
apic1(config-export)# schedule EveryEightHours
Configuring an Export Policy Using the REST API
To configure an export policy using the REST API:
POST
https://<ip-of-apic>/api/mo/uni/fabric.xml
<fabricInst dn="uni/fabric">
<configExportP name="export" format="xml" adminSt="triggered">
<configRsExportDestination tnFileRemotePathName="backup" />
</configExportP>
<fileRemotePath name="backup" host="10.10.10.1" protocol="scp"
Cisco APIC Basic Configuration Guide, Release 2.x
55
Management
Configuring an Import Policy Using the GUI
remotePath="/home/user" userName="user" userPasswd="pass" />
</fabricInst>
Configuring an Import Policy Using the GUI
This procedure explains how to configure an Import policy using the APIC GUI. Follow these steps to import
your backed up data:
Procedure
Step 1
Step 2
On the menu bar, choose ADMIN > Import/Export.
In the navigation pane, right-click Import Policies and click Create Configuration Import Policy.
The Create Configuration Import Policy dialog appears.
Step 3
Enter the appropriate values in the Create Configuration Import Policy dialog fields.
Note
For an explanation of a field, click the 'i' icon to display the help file. For more detailed information
on import types and modes including (Replace, Merge, Best Effort, and Atomic), refer to the Cisco
Application Centric Infrastructure Fundamentals Guide .
When finished entering values in the Create Configuration Import Policy dialog fields, click Submit.
Step 4
Configuring an Import Policy Using the NX-OS Style CLI
To configure an import policy using the NX-OS Style CLI, enter the following:
Procedure
Step 1
Command or Action
Purpose
configure
Enters global configuration mode.
Example:
apic1# configure
Step 2
[no] snapshot import policy-name
Creates a policy for importing snapshots.
Example:
apic1(config)# snapshot import myImportPolicy
Step 3
file filename
Specifies the name of the file to be
imported.
Example:
apic1(config-import)# file
ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
Step 4
action {merge | replace}
Example:
apic1(config-import)# action replace
Cisco APIC Basic Configuration Guide, Release 2.x
56
Specifies whether the imported
configuration settings will be merged with
the current settings or whether the
imported configuration will completely
replace the current configuration.
Management
Configuring an Import Policy Using the REST API
Step 5
Command or Action
Purpose
[no] mode {atomic | best-effort}
Specifies how the import process handles
configuration errors when applying the
imported settings. The best-effort import
mode allows skipping individual
configuration errors in the archive, while
atomic mode cancels the import upon any
configuration error.
Example:
apic1(config-import)# mode atomic
Step 6
[no] remote path remote-path-name
(Optional)
Specifies the name of a configured remote
path from which the file will be imported.
If no remote path is specified, the file is
imported locally from a folder in the
controller. The default is no remote path.
Example:
apic1(config-import)# remote path
myBackupServer
Step 7
Returns to EXEC mode.
end
Example:
apic1(config-import)# end
Step 8
trigger snapshot import policy-name
Executes the snapshot import task.
Example:
apic1# trigger snapshot import myImportPolicy
Examples
This example shows how to configure and execute the importing of a snapshot file to replace the current
configuration.
apic1# show snapshot files
File
: ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
Created : 2015-11-21T01:00:21.167+00:00
Root
:
Size
: 22926
apic1# configure
apic1(config)# snapshot import myImportPolicy
apic1(config-import)# file ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
apic1(config-import)# action replace
apic1(config-import)# mode atomic
apic1(config-import)# end
apic1# trigger snapshot import myImportPolicy
Configuring an Import Policy Using the REST API
To configure an import policy using the REST API:
POST
https://<ip-of-apic>/api/mo/uni/fabric.xml
Cisco APIC Basic Configuration Guide, Release 2.x
57
Management
Encrypting Configuration Files Using the GUI
<fabricInst dn="uni/fabric">
<configImportP name="imp" fileName="aa.tar.gz" adminSt="triggered" importType="replace"
importMode="best-effort">
<configRsImportSource tnFileRemotePathName="backup" />
</configImportP>
<fileRemotePath name="backup" host="10.10.10.1" protocol="scp"
remotePath="/home/user" userName="user" userPasswd="pass" />
</fabricInst>
Encrypting Configuration Files Using the GUI
AES-256 encryption is a global configuration option. When enabled, all secure properties conform to the AES
configuration setting. A portion of the ACI fabric configuration can be exported using configuration export
with a specific targetDn. However, it is not possible to use REST API to export just a portion of the ACI
fabric such as a tenant configuration with secure properties and AES encryption. The secure properties do not
get included during REST API requests.
This section explains how to enable AES-256 encryption.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
On the menu bar, choose ADMIN > AAA.
In the navigation pane, click AES Encryption Passphrase and Keys for Config Export (and Import).
The Global AES Encryption Settings for all Configurations Import and Export window appears in the
right pane.
Create a passphrase, which can be between 16 and 32 characters long. There are no restrictions on the type
of characters used.
Click SUBMIT.
Note
Once you have created and posted the passphrase, the keys are then generated in the back-end and
the passphrase is not recoverable. Therefore, your passphrase is not visible to anyone because the
key is automatically generated then deleted. Your backup only works if you know the passphrase
(no one else can open it).
The Key Configured field now shows yes. You now see an encrypted hash (which is not the actual passphrase,
but just a hash of it) in the Encrpyted Passphrase field.
After setting and confirming your passphrase, check the check box next to Enable Encryption to turn the
AES encryption feature on (checked).
The Global AES Encryption Settings field in your export and import policies will now be enabled by default.
Cisco APIC Basic Configuration Guide, Release 2.x
58
Management
Encrypting Configuration Files Using the GUI
Note
• Be sure that the Fail Import if secure fields cannot be decrypted check box is checked (which
is the default selection) in your import and export policies. We highly recommend that you do
not uncheck this box when you import configurations. If you uncheck this box, the system
attempts to import all the fields However, any fields that it cannot encrypt are blank/missing.
As a result, you could lock yourself out of the system because the admin passwords could go
blank/missing (if you lock yourself out of the system, refer to Cisco APIC Troubleshooting
Guide). Unchecking the box launches a warning message. If the box is checked, there are security
checks that prevent lockouts and the configuration does not import.
• When the Enable Encryption check box is unchecked (off), encryption is disabled and all
exported configurations (exports) are missing the secure fields (such as passwords and
certificates). When this box is checked (on), encryption is enabled and all exports show the
secure fields.
• After enabling encryption, you cannot configure a passphrase when creating a new import or
export policy. The passphrase you previously set is now global across all configurations in this
box and across all tenants. If you export a configuration from this tab (you have configured a
passphrase and enabled encryption) you get a complete backup file. If encryption is not enabled,
you get a backup file with the secure properties removed. These backup files are useful when
exporting to TAC support engineers, for example, because all the secure fields are missing. This
is true for any secure properties in the configuration. There is also a clear option that clears the
encryption key.
Note the list of the configuration import behaviors and associated results in the following table:
Configuration Import Behavior Scenario
Result
Old configuration from previous release
Import of configurations from old
releases is fully supported and
successfully imports all secure fields
stored in old configurations.
Configuration import when AES encryption is not configured If the import is for a configuration
without secure fields, it is successful
with the behavior previously
described. If the imported
configuration has secure fields, it is
rejected.
Configuration import when AES passphrases do not match If the import is for a configuration
without secure fields, it is successful
with the behavior previously
described. If the imported
configuration has secure fields, it is
rejected.
Configuration import when AES passphrases match
Import is successful
Configuration import when AES passphrases do not match This specific case occurs when you
for copy/pasted fields
have copied and pasted secure fields
from other configurations that were
exported with a different passphrase.
Cisco APIC Basic Configuration Guide, Release 2.x
59
Management
Encrypting Configuration Files Using the NX-OS Style CLI
Configuration Import Behavior Scenario
Result
During the first pass parsing of the
imported backup file, if any property
fails to decrypt correctly, the import
fails without importing any shards.
Therefore, if a shard fails to decrypt
all properties, all shards are rejected.
Encrypting Configuration Files Using the NX-OS Style CLI
To encrypt a configuration file using the NX-OS Style CLI:
apic1# configure
apic1(config)# crypto
<CR>
apic1(config)# crypto
apic1(config-aes)#
clear-encryption-key
encryption
no
passphrase
aes
aes
Clears AES encryption key
Enable AES Encryption
Negate a command or set its defaults
Configure passphrase for AES encryption
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric
show fabric related information
show
Show running system information
where
show the current mode
apic1(config-aes)# encryption
<CR>
apic1(config-aes)# encryption
apic1(config-aes)#
clear-encryption-key Clears AES encryption key
encryption
Enable AES Encryption
no
Negate a command or set its defaults
passphrase
Configure passphrase for AES encryption
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric
show fabric related information
show
Show running system information
where
show the current mode
apic1(config-aes)# passphrase
WORD Passphrase for AES encryption (Range of chars: 16-32) in quotes
apic1(config-aes)# passphrase "abcdefghijklmnopqrstuvwxyz"
apic1(config-aes)#
Encrypting Configuration Files Using the REST API
Procedure
To encrypt a configuration file using the REST API, send a post with XML such as the following example:
Cisco APIC Basic Configuration Guide, Release 2.x
60
Management
Backing up, Restoring, and Rolling Back Controller Configuration
Example:
https://apic-ip-address/api/mo/uni/fabric.xml
<pkiExportEncryptionKey passphrase="abcdefghijklmnopqrstuvwxyz"
strongEncryptionEnabled="true"/>
Backing up, Restoring, and Rolling Back Controller
Configuration
This section describes the set of features for backing up (creating snapshots), restoring, and rolling back a
controller configuration.
Backing Up, Restoring, and Rolling Back Configuration Files Workflow
This section describes the workflow of the features for backing up, restoring, and rolling back configuration
files. All of the features described in this document follow the same workflow pattern. Once the corresponding
policy is configured, admintSt must be set to triggered in order to trigger the job.
Once triggered, an object of type configJob (representing that run) is created under a container object of type
configJobCont. (The naming property value is set to the policy DN.) The container's lastJobName field can
be used to determine the last job that was triggered for that policy.
Note
Up to five configJob objects are kept under a single job container at a time, with each new job triggered.
The oldest job is removed to ensure this.
The configJob object contains the following information:
• Execution time
• Name of the file being processed/generated
• Status, as follows:
◦Pending
◦Running
◦Failed
◦Fail-no-data
◦Success
◦Success-with-warnings
• Details string (failure messages and warnings)
• Progress percentage = 100 * lastStepIndex/totalStepCount
• Field lastStepDescr indicating what was being done last
Cisco APIC Basic Configuration Guide, Release 2.x
61
Management
About the fileRemotePath Object
About the fileRemotePath Object
The fileRemotePath object holds the following remote location-path parameters:
• Hostname or IP
• Port
• Protocol: FTP, SCP, and others
• Remote directory (not file path)
• Username
• Password
Note
The password must be resubmitted every time changes are made.
Sample Configuration
The following is a sample configuration:
Under fabricInst (uni/fabric), enter:
<fileRemotePath name="path-name" host="host name or ip" protocol="scp"
remotePath="path/to/some/folder" userName="user-name" userpasswd="password" />
Configuration Export to Controller
The configuration export extracts user-configurable managed object (MO) trees from all thirty-two shards in
the cluster, writes them into separate files, then compresses them into a tar gzip. The configuration export
then uploads the tar gzip to a pre-configured remote location (configured via configRsRemotePath pointing
to a fileRemotePath object) or stores it as a snapshot on the controller(s).
Note
See the Snapshots section for more details.
The configExportP policy is configured as follows:
• name - policy name
• format - format in which the data is stored inside the exported archive (xml or json)
• targetDn - the domain name (DN) of the specific object you want to export (empty means everything)
• snapshot - when true, the file is stored on the controller, no remote location configuration is needed
• includeSecureFields - Set to true by default, indicates whether the encrypted fields (passwords, etc.)
should be included in the export archive.
Cisco APIC Basic Configuration Guide, Release 2.x
62
Management
Configuration Export to Controller
Note
The configSnapshot object is created holding the information about this snapshot (see the Snapshots
section).
Scheduling Exports
An export policy can be linked with a scheduler, which triggers the export automatically based on a
pre-configured schedule. This is done via the configRsExportScheduler relation from the policy to a
trigSchedP object (see the following Sample Configuration section).
Note
A scheduler is optional. A policy can be triggered at any time by setting the adminSt to triggered.
Troubleshooting
If you get an error message indicating that the generated archive could not be uploaded to the remote location,
refer to the Connectivity Issues section.
Sample Configuration Using the NX-OS Style CLI
The following is a sample configuration using the NX-OS Style CLI:
apic1(config)# snapshot
download Configuration snapshot download setup mode
export
Configuration export setup mode
import
Configuration import setup mode
rollback Configuration rollback setup mode
upload
Configuration snapshot upload setup mode
apic1(config)# snapshot export policy-name
apic1(config-export)#
format
Snapshot format: xml or json
no
Negate a command or set its defaults
remote
Set the remote path configuration will get exported to
schedule Schedule snapshot export
target
Snapshot target
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric
show fabric related information
show
Show running system information
where
show the current mode
apic1(config-export)# format xml
apic1(config-export)# no remote path
[If no remote path is specified, the file
is exported locally to a folder in the controller]
apic1(config-export)# target
[Assigns the target of the export, which
can be fabric, infra, a specific tenant, or none. If no target is specified, all configuration
information is exported.]
WORD infra, fabric or tenant-x
apic1(config-export)#
apic1# trigger snapshot export policy-name
[Executes the snapshot export task]
apic1# ls /data2
[If no remote path is specified, the
configuration export file is saved locally to the controller under the folder data2]
ce_Dailybackup.tgz
Sample Configuration Using the GUI
The following is a sample configuration using the GUI:
1 On the menu bar, click the ADMIN tab.
Cisco APIC Basic Configuration Guide, Release 2.x
63
Management
Configuration Import to Controller
2 Select IMPORT/EXPORT.
3 Under Export Policies, select Configuration.
4 Under Configuration, click the configuration that you would like to roll back to. For example, you can
click defaultOneTime, which is the default.
5 Next to Format, select a button for either JSON or XML format.
6 Next to Start Now, select a button for either No or Yes to indicate whether you want to trigger now or
trigger based on a schedule. (The easiest method is to choose to trigger immediately.)
7 For the Target DN field, enter the name of the tenant configuration you are exporting.
8 If you want to store the configuration on the controller itself, check the Snapshot option. If you want to
configure a remote location, uncheck this option.
9 For the Scheduler field, you have the option to create a scheduler instructing when and how often to export
the configuration.
10 For the Encryption field, you have the option to enable or disable the encryption
of your configuration file.
11 When you have finished your configuration, click Start Now.
12 Click SUBMIT to trigger your configuration export.
Sample Configuration Using REST API
The following is a sample configuration using the REST API:
<configExportP name="policy-name" format="xml" targetDn="/some/dn or empty which means
everything"
snapshot="false" adminSt="triggered">
<configRsRemotePath tnFileRemotePathName="some remote path name" />
<configRsExportScheduler tnTrigSchedPName="some scheduler name" />
</configExportP>
Note
When providing a remote location, if you set the snapshot to True, the backup ignores the remote path
and stores the file on the controller.
Configuration Import to Controller
Configuration import downloads, extracts, parses, analyzes and applies the specified, previously exported
archive one shard at a time in the following order: infra, fabric, tn-common, then everything else. The
fileRemotePath configuration is performed the same way as for export (via configRsRemotePath). Importing
snapshots is also supported.
The configImportP policy is configured as follows:
• name - policy name
• fileName - name of the archive file (not the path file) to be imported
• importMode
◦Best-effort mode: each MO is applied individually, and errors only cause the invalid MOs to be
skipped.
Cisco APIC Basic Configuration Guide, Release 2.x
64
Management
Configuration Import to Controller
Note
If the object is not present on the controller, none of the children of the object get
configured. Best-effort mode attempts to configure the children of the object.
◦Atomic mode: configuration is applied by whole shards. A single error causes whole shard to be
rolled back to its original state.
• importType
◦replace - Current system configuration is replaced with the contents or the archive being imported
(only atomic mode is supported)
◦merge - Nothing is deleted, archive content is applied on top the existing system configuration.
• snapshot - when true, the file is taken from the controller and no remote location configuration is needed.
• failOnDecryptErrors - (true by default) the file fails to import if the archive was encrypted with a
different key than the one that is currently set up in the system.
Troubleshooting
The following scenarios may need troubleshooting:
• If the generated archive could not be downloaded from the remote location, refer to the Connectivity
Issues section.
• If the import succeeded with warnings, check the details.
• If a file could not be parsed, refer to the following scenarios:
◦If the file is not a valid XML or JSON file, check whether or not the files from the exported archive
were manually modified.
◦If an object property has an unknown property or property value, it may be because:
◦The property was removed or an unknown property value was manually entered
◦The model type range was modified (non-backward compatible model change)
◦The naming property list was modified
• If an MO could not be configured, note the following:
◦Best-effort mode logs the error and skips the MO
◦Atomic mode logs the error and skips the shard
Sample Configuration Using the NX-OS Style CLI
The following is a sample configuration using the NX-OS Style CLI:
apic1# configure
apic1(config)# snapshot
download Configuration snapshot download setup mode
export
Configuration export setup mode
import
Configuration import setup mode
Cisco APIC Basic Configuration Guide, Release 2.x
65
Management
Configuration Import to Controller
rollback Configuration rollback setup mode
upload
Configuration snapshot upload setup mode
apic1(config)# snapshot import
WORD
Import configuration name
default
rest-user
apic1(config)# snapshot import policy-name
apic1(config-import)#
action Snapshot import action merge|replace
file
Snapshot file name
mode
Snapshot import mode atomic|best-effort
no
Negate a command or set its defaults
remote Set the remote path configuration will get imported from
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric show fabric related information
show
Show running system information
where
show the current mode
apic1(config-import)# file < from "show snapshot files" >
apic1(config-import)# no remote path
apic1(config-import)#
apic1# trigger snapshot import policy-name
[Executes the snapshot import task]
Sample Configuration Using the GUI
The following is a sample configuration using the GUI:
1 On the menu bar, click the ADMIN tab.
2 Select IMPORT/EXPORT.
3 Under Import Policies, select Configuration.
4 Under Configuration, select Create Configuration Import Policy. The CREATE CONFIGURATION
IMPORT POLICY window appears.
5 In the Name field, the file name must match whatever was backed up and will have a very specific format.
The file name is known to whoever did the backup.
6 The next two options relate to recovering configuration states (also known as "roll-back"). The options
are Input Type and Input Mode. When you recover a configuration state, you want to roll back to a
known state that was good before. The option for that is an Atomic Replace.
7 If you want to store the configuration on the controller itself, check the Snapshot option. If you want to
configure a remote location, uncheck this option.
8 In the Import Source field, specify the same remote location that you already created.
9 For the Encryption field, you have the option to enable or disable the encryption
of your configuration file.
10 Click SUBMIT to trigger your configuration import.
Sample Configuration Using the REST API
The following shows a sample configuration using the REST API:
<configImportP name="policy-name" fileName="someexportfile.tgz" importMode="atomic"
importType="replace" snapshot="false" adminSt="triggered">
<configRsRemotePath tnFileRemotePathName="some remote path name" />
</configImportP>
Cisco APIC Basic Configuration Guide, Release 2.x
66
Management
Snapshots
Snapshots
Snapshots are configuration backup archives, stored (and replicated) in a controller managed folder. To create
one, an export can be performed with the snapshot property set to true. In this case, no remote path
configuration is needed. An object of configSnapshot type is created to expose the snapshot to the user.
configSnapshot objects provide the following:
• file name
• file size
• creation date
• root DN indicating what the snapshot is of (fabric, infra, specific tenant, and so on)
• ability to remove a snapshot (by setting the retire field to true)
To import a snapshot, set the import policy snapshot property to true and provide the name of the snapshot
file (from configSnapshot).
Snapshot Manager Policy
The configSnapshotManagerP policy allows you to create snapshots from remotely stored export archives.
You can attach a remote path to the policy, provide the file name (same as with configImportP), set the mode
to download, and trigger. The manager downloads the file, analyzes it to make sure the archive is valid, stores
it on the controller, and creates the corresponding configSnapshot object. The snapshot manager also allow
you to upload a snapshot archive to a remote location. In this case, the mode must be set to upload.
Troubleshooting
For troubleshooting, refer to the Connectivity Issues section.
Snapshot Upload from Controller to Remote Path Using the NX-OS CLI
apic1(config)# snapshot upload policy-name
apic1(config-upload)#
file
Snapshot file name
no
Negate a command or set its defaults
remote Set the remote path configuration will get uploaded to
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric show fabric related information
show
Show running system information
where
show the current mode
apic1(config-upload)# file <file name from "show snapshot files">
apic1(config-upload)# remote path remote-path-name
apic1# trigger snapshot upload policy-name
[Executes the snapshot upload task]
Snapshot Download from Controller to Remote Path Using the NX-OS CLI
apic1(config)# snapshot download policy-name
apic1(config-download)#
file
Snapshot file name
no
Negate a command or set its defaults
remote Set the remote path configuration will get downloaded from
Cisco APIC Basic Configuration Guide, Release 2.x
67
Management
Rollback
bash
bash shell for unix commands
end
Exit to the exec mode
exit
Exit from current mode
fabric show fabric related information
show
Show running system information
where
show the current mode
apic1(config-download)# file < file from remote path>
apic1(config-download)# remote path remote-path-name
apic1# trigger snapshot download policy-name
[Executes the snapshot download task]
Snapshot Upload and Download Using the GUI
To upload a snapshot file to a remote location:
1 Right-click on the snapshot file listed in the Config Rollbacks pane, and select the Upload to Remote
Location option. The Upload snapshot to remote location box appears.
2 Click SUBMIT.
To download a snapshot file from a remote location:
1 Click the import icon on the upper right side of the screen. The Import remotely stored export archive
to snapshot box appears.
2 Enter the file name in the File Name field.
3 Select a remote location from the Import Source pull-down, or check the box next to Or create a new
one to create a new remote location.
4 Click SUBMIT.
Snapshot Upload and Download Using the REST API
<configSnapshotManagerP name="policy-name" fileName="someexportfile.tgz"
mode="upload|download" adminSt="triggered">
<configRsRemotePath tnFileRemotePathName="some remote path name" />
</configSnapshotManagerP>
Rollback
The configRollbackP policy is used to undo the changes made between two snapshots. Objects are processed
as follows:
• Deleted MOs are recreated
• Created MOs are deleted
• Modified MOs are reverted
Note
The rollback feature only operates on snapshots. Remote archives are not supported. To use one, the
snapshot manager can be used to create a snapshot from it for the rollback. The policy does not require a
remote path configuration. If one is provided, it will be ignored.
Cisco APIC Basic Configuration Guide, Release 2.x
68
Management
Rollback
Rollback Workflow
The policy snapshotOneDN and snapshotTwoDn fields must be set and the first snapshot (S1) must precede
snapshot two (S2). Once triggered, snapshots are extracted and analyzed, and the difference between them is
calculated and applied.
MOs are located that are:
• Present in S1 but not present in S2 - these MOs are deleted and rollback re-creates them
• Not present in S1 but not present in S2 - these MOs are created after S1 and rollback deletes them if:
◦These MOs are not modified after S2 is taken
◦None of the MO's descendants are created or modified after S2 is taken
• Present in both S1 and S2, but with different property values - these MO properties are reverted to S1,
unless the property was modified to a diffferent value after S2 is taken. In this case, it is left as is.
The rollback feature also generates a diff file that contains the confiuration generated as a result of these
calculations. Applying this configuration is the last step of the rollback process. The content of this file
can be retrieved via a special REST API called readiff:
apichost/mqapi2/snapshots.readiff.xml?jobdn=SNAPSHOT_JOB_DN.
Rollback (which is difficult to predict) also has a preview mode (set preview to true), which prevents
rollback from making any actual changes. It calculates and generates the diff file, allowing you to preview
what exactly is going to happen once the rollback is actually performed.
Diff Tool
Another special REST API is available, which provides diff functionality between two snapshots:
apichost/mqapi2/snapshots.diff.xml?s1dn=SNAPSHOT_ONE_DN&s2dn=SNAPSHOT_TWO_DN.
Sample Configuration Using the NX-OS Style CLI
This example shows how to configure and execute a rollback using the NX-OS Style CLI:
apic1# show snapshot files
File
: ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
Created : 2015-11-21T01:00:21.167+00:00
Root
:
Size
: 22926
File
Created
Root
Size
: ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
: 2015-11-21T09:00:24.025+00:00
:
: 23588
apic1# configure
apic1(config)# snapshot
apic1(config-rollback)#
apic1(config-rollback)#
apic1(config-rollback)#
apic1(config-rollback)#
apic1# trigger snapshot
rollback myRollbackPolicy
first-file ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
second-file ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
preview
end
rollback myRollbackPolicy
Sample Configuration Using the GUI
This example shows how to configure and execute a rollback using the GUI:
1 On the menu bar, click the Admin tab.
2 Click Config Rollbacks, located under the Admin tab.
Cisco APIC Basic Configuration Guide, Release 2.x
69
Management
Using Syslog
3 Select the first configuration file from the Config Rollbacks list (in the left-side pane).
4 Select the second configuration file in the Configuration for selected snapshot pane (in the right-side
pane).
5 Click the Compare with previous snapshot drop-down menu (at the bottom of the right-side pane), then
select the second configuration file from that list. A diff file is then generated so that you can compare the
differences between the two snapshots.
Note
After the file generates, there is an option to undo these changes.
Sample Configuration Using the REST API
This example shows how to configure and execute a rollback using the REST API:
<configRollbackP name="policy-name" snapshotOneDn="dn/of/snapshot/one"
snapshotOneDn="dn/of/snapshot/two" preview="false" adminSt="triggered" />
Using Syslog
About Syslog
During operation, a fault or event in the Cisco Application Centric Infrastructure (ACI) system can trigger
the sending of a system log (syslog) message to the console, to a local file, and to a logging server on another
system. A system log message typically contains a subset of information about the fault or event. A system
log message can also contain audit log and session log entries.
Note
For a list of syslog messages that the APIC and the fabric nodes can generate, see http://www.cisco.com/
c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/syslog/guide/aci_syslog/ACI_SysMsg.html.
Many system log messages are specific to the action that a user is performing or the object that a user is
configuring or administering. These messages can be the following:
• Informational messages, providing assistance and tips about the action being performed
• Warning messages, providing information about system errors related to an object, such as a user account
or service profile, that the user is configuring or administering
In order to receive and monitor system log messages, you must specify a syslog destination, which can be the
console, a local file, or one or more remote hosts running a syslog server. In addition, you can specify the
minimum severity level of messages to be displayed on the console or captured by the file or host. The local
file for receiving syslog messages is /var/log/external/messages.
A syslog source can be any object for which an object monitoring policy can be applied. You can specify the
minimum severity level of messages to be sent, the items to be included in the syslog messages, and the syslog
destination.
You can change the display format for the Syslogs to NX-OS style format.
Cisco APIC Basic Configuration Guide, Release 2.x
70
Management
Creating a Syslog Destination and Destination Group
Additional details about the faults or events that generate these system messages are described in the Cisco
APIC Faults, Events, and System Messages Management Guide, and system log messages are listed in the
Cisco ACI System Messages Reference Guide.
Note
Not all system log messages indicate problems with your system. Some messages are purely informational,
while others may help diagnose problems with communications lines, internal hardware, or the system
software.
Creating a Syslog Destination and Destination Group
This procedure configures syslog data destinations for logging and evaluation. You can export syslog data to
the console, to a local file, or to one or more syslog servers in a destination group.
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Admin.
In the submenu bar, click External Data Collectors.
In the Navigation pane, expand Monitoring Destinations.
Step 4
Step 5
Right-click Syslog and choose Create Syslog Monitoring Destination Group.
In the Create Syslog Monitoring Destination Group dialog box, perform the following actions:
a) In the group and profile Name field, enter a name for the monitoring destination group and profile.
b) In the group and profile Admin State drop-down list, choose enabled.
c) To enable sending of syslog messages to a local file, choose enabled from the Local File Destination
Admin State drop-down list and choose a minimum severity from the Local File Destination Severity
drop-down list.
The local file for receiving syslog messages is /var/log/external/messages.
Step 6
d) To enable sending of syslog messages to the console, choose enabled from the Console Destination Admin
State drop-down list and choose a minimum severity from the Console Destination Severity drop-down
list.
e) Click Next.
f) In the Create Remote Destinations area, click + to add a remote destination.
Caution
Risk of hostname resolution failure for remote Syslog destinations, if the DNS server used is
configured to be reachable over in-band connectivity. To avoid the issue, configure the Syslog
server using the IP address, or if you use a hostname, ensure that the DNS server is reachable over
an out-of-band interface.
In the Create Syslog Remote Destination dialog box, perform the following actions:
a) In the Host field, enter an IP address or a fully qualified domain name for the destination host.
b) (Optional) In the Name field, enter a name for the destination host.
c) In the Admin State field, click the enabled radio button.
d) (Optional) Choose a minimum severity Severity, a Port number, and a syslog Forwarding Facility.
e) From the Management EPG drop-down list, choose the management endpoint group.
Cisco APIC Basic Configuration Guide, Release 2.x
71
Management
Creating a Syslog Source
f) Click OK.
Step 7
Step 8
(Optional) To add more remote destinations to the remote destination group, click + again and repeat the
steps in the Create Syslog Remote Destination dialog box
Click Finish.
Creating a Syslog Source
A syslog source can be any object for which an object monitoring policy can be applied.
Before You Begin
Create a syslog monitoring destination group.
Procedure
Step 1
From the menu bar and the navigation frame, navigate to a Monitoring Policies menu for the area of interest.
You can configure monitoring policies for tenants, fabric, and access.
Step 2
Expand Monitoring Policies, then select and expand a monitoring policy.
Under Fabric > Fabric Policies > Monitoring Policies > Common Policy is a basic monitoring policy that
applies to all faults and events and is automatically deployed to all nodes and controllers in the fabric.
Alternatively, you can specify an existing policy with a more limited scope.
Step 3
Step 4
Under the monitoring policy, click Callhome/SNMP/Syslog.
In the Work pane, choose Syslog from the Source Type drop-down list.
Step 5
From the Monitoring Object list, choose a managed object to be monitored.
If the desired object does not appear in the list, follow these steps:
a)
b)
c)
d)
Step 6
Click the Edit icon to the right of the Monitoring Object drop-down list.
From the Select Monitoring Package drop-down list, choose an object class package.
Select the checkbox for each object that you want to monitor.
Click Submit.
In a tenant monitoring policy, if you select a specific object instead of All, a Scope selection appears.
In the Scope field, select a radio button to specify the system log messages to send for this object:
• all—Send all events and faults related to this object
• specific event—Send only the specified event related to this object. From the Event drop-down list,
choose the event policy.
• specific fault—Send only the specified fault related to this object. From the Fault drop-down list, choose
the fault policy.
Step 7
Step 8
Click + to create a syslog source.
In the Create Syslog Source dialog box, perform the following actions:
a) In the Name field, enter a name for the syslog source.
b) From the Min Severity drop-down list, choose the minimum severity of system log messages to be sent.
Cisco APIC Basic Configuration Guide, Release 2.x
72
Management
Enabling Syslog to Display in NX-OS CLI Format, Using the REST API
c) In the Include field, check the checkboxes for the type of messages to be sent.
d) From the Dest Group drop-down list, choose the syslog destination group to which the system log messages
will be sent.
e) Click Submit.
Step 9
(Optional) To add more syslog sources, click + again and repeat the steps in the Create Syslog Source dialog
box
Enabling Syslog to Display in NX-OS CLI Format, Using the REST API
By default the Syslog format is RFC 5424 compliant. You can change the default display of Syslogs to NX-OS
type format, similar to the following example:
apic1# moquery -c "syslogRemoteDest"
Total Objects shown: 1
# syslog.RemoteDest
host
:
adminState
:
childAction
:
descr
:
dn
:
epgDn
:
format
:
forwardingFacility :
ip
:
lcOwn
:
modTs
:
monPolDn
:
name
:
operState
:
port
:
rn
:
severity
:
status
:
uid
:
vrfId
:
vrfName
:
172.23.49.77
enabled
uni/fabric/slgroup-syslog-mpod/rdst-172.23.49.77
nxos
local7
local
2016-05-17T16:51:57.231-07:00
uni/fabric/monfab-default
syslog-dest
unknown
514
rdst-172.23.49.77
information
15374
0
To enable the Syslogs to display in NX-OS type format, perform the following steps, using the REST API.
Procedure
Step 1
Enable the Syslogs to display in NX-OS type format, as in the following example:
POST https://192.168.20.123/api/node/mo/uni/fabric.xml
<syslogGroup name="DestGrp77" format="nxos">
<syslogRemoteDest name="slRmtDest77" host="172.31.138.20" severity="debugging"/>
</syslogGroup>
The syslogGroup is the Syslog monitoring destination group, the sysLogRemoteDest is the name you previously
configured for your Syslog server, and the host is the IP address for the previously configured Syslog server.
Cisco APIC Basic Configuration Guide, Release 2.x
73
Management
Using Atomic Counters
Step 2
Set the Syslog format back to the default RFC 5424 format, as in the following example:
POST https://192.168.20.123/api/node/mo/uni/fabric.xml
<syslogGroup name="DestGrp77" format="aci">
<syslogRemoteDest name="slRmtDest77" host="172.31.138.20" severity="debugging"/>
</syslogGroup>
Using Atomic Counters
About Atomic Counters
Atomic counters allow you to gather statistics about traffic between flows. Using atomic counters, you can
detect drops and misrouting in the fabric, enabling quick debugging and isolation of application connectivity
issues. For example, an administrator can enable atomic counters on all leaf switches to trace packets from
endpoint 1 to endpoint 2. If any leaf switches have nonzero counters, other than the source and destination
leaf switches, an administrator can drill down to those leafs.
In conventional settings, it is nearly impossible to monitor the amount of traffic from a bare metal NIC to a
specific IP address (an endpoint) or to any IP address. Atomic counters allow an administrator to count the
number of packets that are received from a bare metal endpoint without any interference to its data path. In
addition, atomic counters can monitor per-protocol traffic that is sent to and from an endpoint or an application
group.
Leaf-to-leaf (TEP-to-TEP) atomic counters can provide the following:
• Counts of sent, received, dropped, and excess packets
◦Sent packets: The sent number reflects how many packets were sent from the source TEP (tunnel
endpoint) to the destination TEP.
◦Received packets: The received number reflects how many packets the destination TEP received
from the source TEP.
◦Dropped packets: The dropped number reflects how many packets were dropped during transmission.
This number is the difference in the amount of packets sent and the amount of packets received.
◦Excess packets: The excess number reflects how many extra packets were received during
transmission. This number is the amount of packets that were unexpectedly received due to a
forwarding mismatch or a misrouting to the wrong place.
• Short-term data collection such as the last 30 seconds, and long-term data collection such as 5 minutes,
15 minutes, or more
• A breakdown of per-spine traffic (available when the number of TEPs, leaf or VPC, is less than 64)
• Ongoing monitoring
Cisco APIC Basic Configuration Guide, Release 2.x
74
Management
Atomic Counters Guidelines and Restrictions
Note
Leaf-to-leaf (TEP to TEP) atomic counters are cumulative and cannot be cleared. However, because
30-second atomic counters reset at 30-second intervals, they can be used to isolate intermittent or recurring
problems. Atomic counters require an active fabric Network Time Protocol (NTP) policy.
Tenant atomic counters can provide the following:
• Application-specific counters for traffic across the fabric, including sent, received, dropped, and excess
packets
• Modes include the following:
◦EPtoEP (endpoint to endpoint)
◦EPGtoEPG (endpoint group to endpoint group)
Note
For EPGtoEPG, the options include ipv4 only, ipv6 only, and ipv4, ipv6. Any time there
is an ipv6 option, you use twice the TCAM entries, which means the scale numbers may
be less than expected for pure ipv4 policies.
◦EPGtoEP (endpoint group to endpoint)
◦EPtoAny (endpoint to any)
◦AnytoEP (any to endpoint)
◦EPGtoIP (endpoint group to IP, used only for external IP address)
◦EPtoExternalIP (endpoint to external IP address)
Atomic Counters Guidelines and Restrictions
• Use of atomic counters is not supported when the endpoints are in different tenants or in different contexts
(VRFs) within the same tenant.
• In pure layer 2 configurations where the IP address is not learned (the IP address is 0.0.0.0),
endpoint-to-EPG and EPG-to-endpoint atomic counter policies are not supported. In these cases,
endpoint-to-endpoint and EPG-to-EPG policies are supported. External policies are virtual routing and
forwarding (VRF)-based, requiring learned IP addresses, and are supported.
• When the atomic counter source or destination is an endpoint, the endpoint must be dynamic and not
static. Unlike a dynamic endpoint (fv:CEp), a static endpoint (fv:StCEp) does not have a child object
(fv:RsCEpToPathEp) that is required by the atomic counter.
• In a transit topology, where leaf switches are not in full mesh with all spine switches, then leaf-to-leaf
(TEP to TEP) counters do not work as expected.
• For leaf-to-leaf (TEP to TEP) atomic counters, once the number of tunnels increases the hardware limit,
the system changes the mode from trail mode to path mode and the user is no longer presented with
per-spine traffic.
• The atomic counter does not count spine proxy traffic.
Cisco APIC Basic Configuration Guide, Release 2.x
75
Management
Configuring Atomic Counters
• Packets dropped before entering the fabric or before being forwarded to a leaf port are ignored by atomic
counters.
• Packets that are switched in the hypervisor (same Port Group and Host) are not counted.
• Atomic counters require an active fabric Network Time Protocol (NTP) policy.
• Atomic counters work for IPv6 sources and destinations but configuring source and destination IP
addresses across IPv4 and IPv6 addresses is not allowed.
• An atomic counter policy configured with fvCEp as the source and/or destination counts only the traffic
that is from/to the MAC and IP addresses that are present in the fvCEp managed objects (MOs). If the
fvCEp MO has an empty IP address field, then all traffic to/from that MAC address would be counted
regardless of the IP address. If the APIC has learned multiple IP addresses for an fvCEp, then traffic
from only the one IP address in the fvCEp MO itself is counted as previously stated. In order to configure
an atomic counter policy to/from a specific IP address, use the fvIp MO as the source and/or destination.
• If there is an fvIp behind an fvCEp, you must add fvIP-based policies and not fvCEp-based policies.
Configuring Atomic Counters
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Tenants.
In the submenu bar, click the desired tenant.
In the Navigation pane, expand the tenant and expand Troubleshoot Policies.
Step 4
Under Troubleshoot Policies, expand Atomic Counter Policy and choose a traffic topology.
You can measure traffic between a combination of endpoints, endpoint groups, external interfaces, and IP
addresses.
Step 5
Right-click the desired topology and choose Add topology Policy to open an Add Policy dialog box.
In the Add Policy dialog box, perform the following actions:
a) In the Name field, enter a name for the policy.
b) choose or enter the identifying information for the traffic source.
The required identifying information differs depending on the type of source (endpoint, endpoint group,
external interface, or IP address).
c) choose or enter the identifying information for the traffic destination.
d) (Optional) (Optional) In the Filters table, click the + icon to specify filtering of the traffic to be counted.
In the resulting Create Atomic Counter Filter dialog box, you can specify filtering by the IP protocol
number (TCP=6, for example) and by source and destination IP port numbers.
e) Click Submit to save the atomic counter policy.
Step 6
Step 7
In the Navigation pane, under the selected topology, choose the new atomic counter policy.
The policy configuration is displayed in the Work pane.
Step 8
In the Work pane, click the Operational tab and click the Traffic subtab to view the atomic counter statistics.
Cisco APIC Basic Configuration Guide, Release 2.x
76
Management
Using SNMP
Using SNMP
About SNMP
The Cisco Application Centric Infrastructure (ACI) provides extensive SNMPv1, v2, and v3 support, including
Management Information Bases (MIBs) and notifications (traps). The SNMP standard allows any third-party
applications that support the different MIBs to manage and monitor the ACI fabric.
SNMPv3 provides extended security. Each SNMPv3 device can be selectively enabled or disabled for SNMP
service. In addition, each device can be configured with a method of handling SNMPv1 and v2 requests.
For more information about using SNMP, see the Cisco ACI MIB Quick Reference.
SNMP Access Support in ACI
SNMP support in ACI is as follows:
• SNMP read queries (Get, Next, Bulk, Walk) are supported by leaf and spine switches and by APIC.
• SNMP write commands (Set) are not supported by leaf and spine switches or by APIC.
• SNMP traps (v1, v2c, and v3) are supported by leaf and spine switches and by APIC.
Note
ACI supports a maximum of 10 trap receivers.
• SNMPv3 is supported by leaf and spine switches and by APIC.
Table 7: SNMP Support Changes by Cisco APIC Release
Release
Description
1.2(2)
IPv6 support is added for SNMP trap destinations.
1.2(1)
SNMP support for the APIC controller is added. Previous releases support SNMP
only for leaf and spine switches.
For the complete list of MIBs supported in ACI, see http://www.cisco.com/c/en/us/td/docs/switches/datacenter/
aci/apic/sw/1-x/mib/list/mib-support.html.
Configuring SNMP
Configuring the SNMP Policy Using the GUI
This procedure configures and enables the SNMP policy on ACI switches.
Cisco APIC Basic Configuration Guide, Release 2.x
77
Management
Configuring SNMP
Before You Begin
To allow SNMP communications, you must configure the following:
• Configure an out-of-band contract allowing SNMP traffic. SNMP traffic typically uses UDP port 161
for SNMP requests.
• Configure the APIC out-of-band IP addresses in the 'mgmt' tenant. Although the out-of-band addresses
are configured during APIC setup, the addresses must be explicitly configured in the 'mgmt' tenant
before the out-of-band contract will take effect.
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Fabric.
In the submenu bar, click Fabric Policies.
In the Navigation pane, expand Pod Policies.
Step 4
Step 5
Under Pod Policies, expand Policies.
Right-click SNMP and choose Create SNMP Policy.
As an alternative to creating a new SNMP policy, you can edit the default policy fields in the same manner
as described in the following steps.
Step 6
In the SNMP policy dialog box, perform the following actions:
a) In the Name field, enter an SNMP policy name.
b) In the Admin State field, select Enabled.
c) In the Community Policies table, click the + icon, enter a Name (do not include the @ symbol) and click
Update.
d) (Optional) In the SNMP v3 Users table, click the + icon, enter a Name, enter the user's authentication
data, and click Update.
This step is needed only if SNMPv3 access is required.
Step 7
To configure allowed SNMP management stations, perform the following actions in the SNMP policy dialog
box:
a) In the Client Group Policies table, click the + icon to open the Create SNMP Client Group Profile
dialog box.
b) In the Name field, enter an SNMP client group profile name.
c) From the Associated Management EPG drop-down list, choose the management EPG.
d) In the Client Entries table, click the + icon.
e) Enter a client's name in the Name field, enter the client's IP address in the Address field, and click Update.
Note
When an SNMP management station connects with APIC using SNMPv3, APIC does not enforce
the client IP address specified in the SNMP client group profile. For SNMPv3, the management
station must exist in the Client Entries list, but the IP address need not match, as the SNMPv3
credentials alone are sufficient for access.
Step 8 Click OK.
Step 9 Click Submit.
Step 10 Under Pod Policies, expand Policy Groups and choose a policy group or right-click Policy Groups and
choose Create POD Policy Group.
You can create a new pod policy group or you can use an existing group. The pod policy group can contain
other pod policies in addition to the SNMP policy.
Cisco APIC Basic Configuration Guide, Release 2.x
78
Management
Configuring SNMP
Step 11 In the pod policy group dialog box, perform the following actions:
a) In the Name field, enter a pod policy group name.
b) From the SNMP Policy drop-down list, choose the SNMP policy that you configured and click Submit.
Step 12 Under Pod Policies, expand Profiles and click default.
Step 13 In the Work pane, from the Fabric Policy Group drop-down list, choose the pod policy group that you
created.
Step 14 Click Submit.
Step 15 Click OK.
Configuring an SNMP Trap Destination Using the GUI
This procedure configures the host information for an SNMP manager that will receive SNMP trap notifications.
Note
ACI supports a maximum of 10 trap receivers. If you configure more than 10, some will not receive
notifications.
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Admin.
In the submenu bar, click External Data Collectors.
In the Navigation pane, expand Monitoring Destinations.
Step 4
Step 5
Right-click SNMP and choose Create SNMP Monitoring Destination Group.
In the Create SNMP Monitoring Destination Group dialog box, perform the following actions:
a) In the Name field, enter an SNMP destination name and click Next.
b) In the Create Destinations table, click the + icon to open the Create SNMP Trap Destination dialog
box.
c) In the Host Name/IP field, enter an IP address or a fully qualified domain name for the destination host.
Note
Cisco APIC Release 1.2(2) and later releases support IPv6 SNMP trap destinations.
d) Choose the Port number and SNMP Version for the destination.
e) For SNMP v1 or v2c destinations, enter one of the configured community names as the Security Name
and choose noauth as v3 Security Level.
SNMP community names cannot contain the @ symbol.
f) For SNMP v3 destinations, enter one of the configured SNMP v3 user names as Security Name and
choose the desired v3 Security Level.
g) From the Management EPG drop-down list, choose the management EPG.
h) Click OK.
i) Click Finish.
Cisco APIC Basic Configuration Guide, Release 2.x
79
Management
Configuring SNMP
Configuring an SNMP Trap Source Using the GUI
This procedure selects and enables a source object within the fabric to generate SNMP trap notifications.
Procedure
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
In the menu bar, click Fabric.
In the submenu bar, click Fabric Policies.
In the Navigation pane, expand Monitoring Policies.
You can create an SNMP source in the Common Policy, the default policy, or you can create a new monitoring
policy.
Expand the desired monitoring policy and choose Callhome/SNMP/Syslog.
If you chose the Common Policy, right-click Common Policy, choose Create SNMP Source, and follow
the instructions below for that dialog box.
In the Work pane, from the Monitoring Object drop-down list, choose ALL.
From the Source Type drop-down list, choose SNMP.
In the table, click the + icon to open the Create SNMP Source dialog box.
In the Create SNMP Source dialog box, perform the following actions:
a) In the Name field, enter an SNMP policy name.
b) From the Dest Group drop-down list, choose an existing destination for sending notifications or choose
Create SNMP Monitoring Destination Group to create a new destination.
The steps for creating an SNMP destination group are described in a separate procedure.
c) Click Submit.
Monitoring the System Using SNMP
You can remotely monitor individual hosts (APIC or another host) and find out the state of any particular
node.
You can check the system's CPU and memory usage using SNMP to find out if the CPU is spiking or not.
The SNMP, a network management system, uses an SNMP client and accesses information over the APIC
and retrieves information back from it.
You can remotely access the system to figure out if the information is in the context of the network management
system and you can learn whether or not it is taking too much CPU or memory, or if there are any system or
performance issues. Once you learn the source of the issue, you can check the system health and verify whether
or not it is using too much memory or CPU.
Refer to the Cisco ACI MIB Quick Reference Manual for additional information.
Cisco APIC Basic Configuration Guide, Release 2.x
80
Management
Using SPAN
Using SPAN
About SPAN
You can use the Switched Port Analyzer (SPAN) utility to perform detailed troubleshooting or to take a sample
of traffic from a particular application host for proactive monitoring and analysis.
SPAN copies traffic from one or more ports, VLANs, or endpoint groups (EPGs) and sends the copied traffic
to one or more destinations for analysis by a network analyzer. The process is nondisruptive to any connected
devices and is facilitated in the hardware, which prevents any unnecessary CPU load.
You can configure SPAN sessions to monitor traffic received by the source (ingress traffic), traffic transmitted
from the source (egress traffic), or both. By default, SPAN monitors all traffic, but you can configure filters
to monitor only selected traffic.
Multinode SPAN
APIC traffic monitoring policies can SPAN policies at the appropriate places to track members of each
application group and where they are connected. If any member moves, APIC automatically pushes the policy
to the new leaf switch. For example, when an endpoint VMotions to a new leaf switch, the SPAN configuration
automatically adjusts.
SPAN Guidelines and Restrictions
• Use SPAN for troubleshooting. SPAN traffic competes with user traffic for switch resources. To minimize
the load, configure SPAN to copy only the specific traffic that you want to analyze.
• You cannot specify an l3extLIfP layer 3 subinterface as a SPAN source. You must use the entire port
for monitoring traffic from external sources.
• Tenant and access SPAN use the encapsulated remote extension of SPAN (ERSPAN) type I, while fabric
SPAN uses ERSPAN type II. For information regarding ERSPAN headers, refer to the IETF Internet
Draft at this URL: https://tools.ietf.org/html/draft-foschiano-erspan-00.
• ERSPAN destination IPs must be learned in the fabric as an endpoint.
• SPAN supports IPv6 traffic but the destination IP for the ERSPAN cannot be an IPv6 address.
• See the Verified Scalability Guide for Cisco ACI document for SPAN-related limits, such as the maximum
number of active SPAN sessions.
Configuring a SPAN Session
This procedure shows how to configure a SPAN policy to forward replicated source packets to a remote traffic
analyzer.
Cisco APIC Basic Configuration Guide, Release 2.x
81
Management
Using Traceroute
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Tenants.
In the submenu bar, click the tenant that contains the source endpoint.
In the Navigation pane, expand the tenant, expand Troubleshooting Policies, and expand SPAN.
Step 4
Under SPAN, right-click SPAN Destination Groups and choose Create SPAN Destination Group.
The Create SPAN Destination Group dialog appears.
Enter the appropriate values in the required fields of the Create SPAN Destination Group dialog box then
click OK and Submit.
Note
For a description of a field, click the information icon (i) at the top-right corner of the dialog box to
display the help file.
Under SPAN, right-click SPAN Source Groups and choose Create SPAN Source Group.
The Create SPAN Source Group dialog appears.
Step 5
Step 6
Step 7
Enter the appropriate values in the required fields of the Create SPAN Source Group dialog box then click
OK and Submit.
Note
For a description of a field, click the information icon (i) at the top-right corner of the dialog box to
display the help file.
What to Do Next
Using a traffic analyzer at the SPAN destination, you can observe the data packets from the SPAN source
EPG to verify the packet format, addresses, protocols, and other information.
Using Traceroute
About Traceroute
The traceroute tool is used to discover the routes that packets actually take when traveling to their destination.
Traceroute identifies the path taken on a hop-by-hop basis and includes a time stamp at each hop in both
directions. You can use traceroute to test the connectivity of ports along the path between the generating
device and the device closest to the destination. If the destination cannot be reached, the path discovery traces
the path up to the point of failure.
A traceroute that is initiated from the tenant endpoints shows the default gateway as an intermediate hop that
appears at the ingress leaf switch.
Traceroute supports a variety of modes, including endpoint-to-endpoint, and leaf-to-leaf (tunnel endpoint, or
TEP to TEP). Traceroute discovers all paths across the fabric, discovers point of exits for external endpoints,
and helps to detect if any path is blocked.
Traceroute Guidelines and Restrictions
• When the traceroute source or destination is an endpoint, the endpoint must be dynamic and not static.
Unlike a dynamic endpoint (fv:CEp), a static endpoint (fv:StCEp) does not have a child object
(fv:RsCEpToPathEp) that is required for traceroute.
Cisco APIC Basic Configuration Guide, Release 2.x
82
Management
Performing a Traceroute Between Endpoints
• Traceroute works for IPv6 source and destinations but configuring source and destination IP addresses
across IPv4 and IPv6 addresses is not allowed.
• See the Verified Scalability Guide for Cisco ACI document for traceroute-related limits.
Performing a Traceroute Between Endpoints
Procedure
Step 1
Step 2
Step 3
In the menu bar, click Tenants.
In the submenu bar, click the tenant that contains the source endpoint.
In the Navigation pane, expand the tenant and expand Troubleshoot Policies.
Step 4
Under Troubleshoot Policies, right-click Endpoint-to-Endpoint Traceroute Policies and choose Create
Endpoint-to-Endpoint Traceroute Policy.
Enter the appropriate values in the Create Endpoint-to-Endpoint Traceroute Policy dialog box fields and
click Submit.
Note
For the description of a field, click the information icon (i) in the top-right corner of the Create
Endpoint-to-Endpoint Traceroute Policy dialog box.
In the Navigation pane or the Traceroute Policies table, click the traceroute policy.
The traceroute policy is displayed in the Work pane.
Step 5
Step 6
Step 7
In the Work pane, click the Operational tab, click the Source End Points tab, and click the Results tab.
Step 8
In the Traceroute Results table, verify the path or paths that were used in the trace.
Note
• More than one path might have been traversed from the source node to the destination
node.
• For readability, you can increase the width of one or more columns, such as the Name
column.
Cisco APIC Basic Configuration Guide, Release 2.x
83
Management
Performing a Traceroute Between Endpoints
Cisco APIC Basic Configuration Guide, Release 2.x
84
CHAPTER
5
Provisioning Core ACI Fabric Services
This chapter contains the following sections:
• Time Synchronization and NTP, page 85
• Configuring a DHCP Relay Policy, page 91
• Configuring a DNS Service Policy, page 94
• Configuring Custom Certificate Guidelines, page 101
• Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI, page 101
Time Synchronization and NTP
Within the Cisco Application Centric Infrastructure (ACI) fabric, time synchronization is a crucial capability
upon which many of the monitoring, operational, and troubleshooting tasks depend. Clock synchronization
is important for proper analysis of traffic flows as well as for correlating debug and fault time stamps across
multiple fabric nodes.
An offset present on one or more devices can hamper the ability to properly diagnose and resolve many
common operational issues. In addition, clock synchronization allows for the full utilization of the atomic
counter capability that is built into the ACI upon which the application health scores depend. Nonexistent or
improper configuration of time synchronization does not necessarily trigger a fault or a low health score. You
should configure time synchronization before deploying a full fabric or applications so as to enable proper
usage of these features. The most widely adapted method for synchronizing a device clock is to use Network
Time Protocol (NTP).
Prior to configuring NTP, consider what management IP address scheme is in place within the ACI fabric.
There are two options for configuring management of all ACI nodes and Application Policy Infrastructure
Controllers (APICs), in-band management and/or out-of-band management. Depending upon which management
option is chosen for the fabric, configuration of NTP will vary. Another consideration in deploying time
synchronization is where the time source is located. The reliability of the source must be carefully considered
when determining if you will use a private internal clock or an external public clock.
Cisco APIC Basic Configuration Guide, Release 2.x
85
Provisioning Core ACI Fabric Services
In-Band and Out-of-Band Management NTP
In-Band and Out-of-Band Management NTP
• Make sure the Management EPG is configured for the NTP servers, otherwise the servers will not
get configured on the switches.
Note
• See the Adding Management Access section in this guide for information about in-band management
access and out-of-band management access.
• Out-of-band management NTP—When an ACI fabric is deployed with out-of-band management, each
node of the fabric, inclusive of spines, leaves, and all members of the APIC cluster, is managed from
outside the ACI fabric. This IP reachability will be leveraged so that each node can individually query
the same NTP server as a consistent clock source. To configure NTP, a Date and Time policy must be
created that references an out-of-band management endpoint group. Date and Time policies are confined
to a single pod and must be deployed across all pods provisioned in the ACI fabric. Currently only one
pod per ACI fabric is allowed.
• In-Band Management NTP—When an ACI fabric is deployed with in-band management, consider the
reachability of the NTP server from within the ACI in-band management network. In-band IP addressing
used within the ACI fabric is not reachable from anywhere outside the fabric. To leverage an NTP server
external to the fabric with in-band management, construct a policy to enable this communication. The
steps used to configure in-band management policies are identical to those used to establish an out-of-band
management policy. The distinction is around how to allow the fabric to connect to the NTP server.
NTP over IPv6
NTP over IPv6 addresses is supported in hostnames and peer addresses. The gai.conf can also be set up to
prefer the IPv6 address of a provider or a peer over an IPv4 address. The user can provide a hostname that
can be resolved by providing an IP address (both IPv4 or IPv6, depending on the installation or preference).
Configuring NTP Using the Basic GUI
Before You Begin
Procedure
Step 1
Step 2
On the menu bar, choose System > System Settings.
In the Navigation pane, click NTP.
Step 3
In the Work pane, the default NTP policy properties are displayed.
Step 4
In the NTP Servers field, expand the + sign to display the Create Providers dialog box.
Step 5
In the Create Providers dialog box, enter all relevant information, including the following fields: Name,
Description, Minimum Polling Intervals, and Maximum Polling Intervals.
• If you are creating multiple providers, check the Preferred check box for the most reliable NTP source.
Cisco APIC Basic Configuration Guide, Release 2.x
86
Provisioning Core ACI Fabric Services
Configuring NTP Using the Advanced GUI
• In the Management EPG drop-down list, if the NTP server is reachable by all nodes on the fabric through
out-of-band management, choose Out-of-Band. If you have deployed in-band management, see the
details about In-Band Management NTP. Click OK.
Configuring NTP Using the Advanced GUI
Procedure
Step 1
Step 2
On the menu bar, choose FABRIC > Fabric Policies.
In the Navigation pane, choose Pod Policies > Policies.
Step 3
In the Work pane, choose Actions > Create Date and Time Policy.
Step 4
In the Create Date and Time Policy dialog box, perform the following actions:
a) Enter a name for the policy to distinguish between the different NTP configurations in your environment.
Click Next.
b) Click the + sign to specify the NTP server information (provider) to be used.
c) In the Create Providers dialog box, enter all relevant information, including the following fields: Name,
Description, Minimum Polling Intervals, and Maximum Polling Intervals.
• If you are creating multiple providers, check the Preferred check box for the most reliable NTP
source.
• In the Management EPG drop-down list, if the NTP server is reachable by all nodes on the fabric
through out-of-band management, choose Out-of-Band. If you have deployed in-band management,
see the details about In-Band Management NTP. Click OK.
Repeat the steps for each provider that you want to create.
Step 5
In the Navigation pane, choose Pod Policies > Policy Groups.
Step 6
In the Work pane, choose Actions > Create Pod Policy Group.
Step 7
In the Create Pod Policy Group dialog box, perform the following actions:
a) Enter a name for the policy group.
b) In the Date Time Policy field, from the drop down list, choose the NTP policy that you created earlier.
Click Submit.
The pod policy group is created. Alternatively, you can use the default pod policy group.
Step 8
In the Navigation pane, choose Pod Policies > Profiles.
Step 9
In the Work pane, double-click the desired pod selector name.
Step 10 In the Properties area, from the Fabric Policy Group drop down list, choose the pod policy group you created.
Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
87
Provisioning Core ACI Fabric Services
Configuring NTP Using the NX-OS Style CLI
Configuring NTP Using the NX-OS Style CLI
When an ACI fabric is deployed with out-of-band management, each node of the fabric is managed from
outside the ACI fabric. You can configure an out-of-band management NTP server so that each node can
individually query the same NTP server as a consistent clock source.
Procedure
Step 1
configure
Enters configuration mode.
Example:
apic1# configure
Step 2
template ntp-fabric ntp-fabric-template-name
Specifies the NTP template (policy) for the fabric.
Example:
apic1(config)# template ntp-fabric pol1
Step 3
[no] server dns-name-or-ipaddress [prefer] [use-vrf {inband-mgmt | oob-default}] [key key-value]
Configures an NTP server for the active NTP policy. To make this server the preferred server for the active
NTP policy, include the prefer keyword. If NTP authentication is enabled, specify a reference key ID. To
specify the in-band or out-of-band management access VRF, include the use-vrf keyword with the inb-default
or oob-default keyword.
Example:
apic1(config-template-ntp-fabric)# server 192.0.20.123 prefer use-vrf oob-mgmt
Step 4
[no] authenticate
Enables (or disables) NTP authentication.
Example:
apic1(config-template-ntp-fabric)# no authenticate
Step 5
[no] authentication-key key-value
Configures an authentication NTP authentication. The range is 1 to 65535.
Example:
apic1(config-template-ntp-fabric)# authentication-key 12345
Step 6
[no] trusted-key key-value
Configures a trusted NTP authentication. The range is 1 to 65535.
Example:
apic1(config-template-ntp-fabric)# trusted-key 54321
Step 7
exit
Returns to global configuration mode
Cisco APIC Basic Configuration Guide, Release 2.x
88
Provisioning Core ACI Fabric Services
Configuring NTP Using the NX-OS Style CLI
Example:
apic1(config-template-ntp-fabric)# exit
Step 8
template pod-group pod-group-template-name
Configures a pod-group template (policy).
Example:
apic1(config)# template pod-group allPods
Step 9
inherit ntp-fabric ntp-fabric-template-name
Configures the NTP fabric pod-group to use the previously configured NTP fabric template (policy).
Example:
apic1(config-pod-group)# inherit ntp-fabric pol1
Step 10 exit
Returns to global configuration mode
Example:
apic1(config-template-pod-group)# exit
Step 11 pod-profile pod-profile-name
Configures a pod profile.
Example:
apic1(config)# pod-profile all
Step 12 pods {pod-range-1-255 | all}
Configures a set of pods.
Example:
apic1(config-pod-profile)# pods all
Step 13 inherit pod-group pod-group-name
Associates the pod-profile with the previously configured pod group.
Example:
apic1(config-pod-profile-pods)# inherit pod-group allPods
Step 14 end
Returns to EXEC mode.
Example:
apic1(config-pod-profile-pods)# end
Examples
This example shows how to configure a preferred out-of-band NTP server and how to verify the configuration
and deployment.
apic1# configure t
apic1(config)# template ntp-fabric pol1
apic1(config-template-ntp-fabric)# server 192.0.20.123 use-vrf oob-default
Cisco APIC Basic Configuration Guide, Release 2.x
89
Provisioning Core ACI Fabric Services
Configuring NTP Using the REST API
apic1(config-template-ntp-fabric)# no authenticate
apic1(config-template-ntp-fabric)# authentication-key 12345
apic1(config-template-ntp-fabric)# trusted-key 12345
apic1(config-template-ntp-fabric)# exit
apic1(config)# template pod-group allPods
apic1(config-pod-group)# inherit ntp-fabric pol1
apic1(config-pod-group)# exit
apic1(config)# pod-profile all
apic1(config-pod-profile)# pods all
apic1(config-pod-profile-pods)# inherit pod-group allPods
apic1(config-pod-profile-pods)# end
apic1#
apic1# show ntpq
nodeid
remote
refid
st
t
when
poll
reach
delay
offset
jitter
----
-u
----27
----64
----377
-----76.427
-----0.087
-----0.067
u
u
3
3
64
64
377
377
75.932
75.932
0.001
0.001
0.021
0.021
-----1
*
-----------192.0.20.123
-----.GPS.
2
3
*
*
192.0.20.123
192.0.20.123
.GPS.
.GPS.
Configuring NTP Using the REST API
Procedure
Step 1
Configure NTP.
Example:
POST url: https://APIC-IP/api/node/mo/uni/fabric/time-test.xml
<imdata totalCount="1">
<datetimePol adminSt="enabled" authSt="disabled" descr="" dn="uni/fabric/time-CiscoNTPPol"
name="CiscoNTPPol" ownerKey="" ownerTag="">
<datetimeNtpProv descr="" keyId="0" maxPoll="6" minPoll="4" name="10.10.10.11"
preferred="yes">
<datetimeRsNtpProvToEpg tDn="uni/tn-mgmt/mgmtp-default/inb-default"/>
</datetimeNtpProv>
</datetimePol>
</imdata>
Step 2
Add the default Date Time Policy to the pod policy group.
Example:
POST url: https://APIC-IP/api/node/mo/uni/fabric/funcprof/podpgrp-calo1/rsTimePol.xml
POST payload: <imdata totalCount="1">
<fabricRsTimePol tnDatetimePolName=“CiscoNTPPol”>
</fabricRsTimePol>
</imdata>
Step 3
Add the pod policy group to the default pod profile.
Example:
POST url:
https://APIC-IP/api/node/mo/uni/fabric/podprof-default/pods-default-typ-ALL/rspodPGrp.xml
payload: <imdata totalCount="1">
<fabricRsPodPGrp tDn="uni/fabric/funcprof/podpgrp-calo1" status="created">
Cisco APIC Basic Configuration Guide, Release 2.x
90
Provisioning Core ACI Fabric Services
Verifying NTP Operation Using the GUI
</fabricRsPodPGrp>
</imdata>
Verifying NTP Operation Using the GUI
Procedure
Step 1
Step 2
On the menu bar, choose FABRIC > Fabric Policies.
In the Navigation pane, choose Pod Policies > Policies > Date and Time > ntp_policy > server_name.
The ntp_policy is the previously created policy. An IPv6 address is supported in the Host Name/IP address
field. If you enter a hostname and it has an IPv6 address set, you must implement the priority of IPv6 address
over IPv4 address.
Step 3
In the Work pane, verify the details of the server.
Verifying NTP Policy Deployed to Each Node Using the NX-OS Style CLI
Procedure
Step 1
Step 2
Log onto an APIC controller in the fabric using the SSH protocol.
Attach to a node and check the NTP peer status, shown as follows:
apic1# fabric
Step 3
node_name show ntp peer-status
Repeat step 2 for different nodes in the fabric.
Configuring a DHCP Relay Policy
A DHCP relay policy may be used when the DHCP client and server are in different subnets. If the client is
on an ESX hypervisor with a deployed vShield Domain profile, then the use of a DHCP relay policy
configuration is mandatory.
When a vShield controller deploys a Virtual Extensible Local Area Network (VXLAN), the hypervisor hosts
create a kernel (vmkN, virtual tunnel end-point [VTEP]) interface. These interfaces need an IP address in the
infrastructure tenant that uses DHCP. Therefore, you must configure a DHCP relay policy so that the APIC
can act as the DHCP server and provide these IP addresses.
When an ACI fabric acts as a DHCP relay, it inserts the DHCP Option 82 (the DHCP Relay Agent Information
Option) in DHCP requests that it proxies on behalf of clients. If a response (DHCP offer) comes back from
a DHCP server without Option 82, it is silently dropped by the fabric. Therefore, when the ACI fabric acts
as a DHCP relay, DHCP servers providing IP addresses to compute nodes attached to the ACI fabric must
support Option 82.
Cisco APIC Basic Configuration Guide, Release 2.x
91
Provisioning Core ACI Fabric Services
Configuring a DHCP Server Policy for the APIC Infrastructure Using the GUI
Configuring a DHCP Server Policy for the APIC Infrastructure Using the GUI
• The port and the encapsulation used by the application Endpoint Group must belong to a physical or
VM Manager (VMM) domain. If no such association with a domain is established, the APIC continues
to deploy the EPG but raises a fault.
• Cisco APIC supports DHCP relay for both IPv4 and IPv6 tenant subnets. DHCP server addresses can
be IPv4 or IPv6. DHCPv6 relay will occur only if IPv6 is enabled on the fabric interface and one or
more DHCPv6 relay servers are configured.
Deploying DHCP Relay Policy for an Endpoint Group
Before You Begin
Make sure that Layer 2 or Layer 3 management connectivity is configured.
Procedure
Step 1
Step 2
Step 3
On the menu bar, choose TENANTS > infra. In the Navigation pane, under Tenant infra, expand Networking
> Protocol Policies > DHCP > Relay Policies.
Right-click Relay Policies and click Create DHCP Relay Policy.
In the Create DHCP Relay Policy dialog box, perform the following actions:
Step 4
a) In the Name field, enter the DHCP relay profile name (DhcpRelayP).
b) Expand Providers. In the Create DHCP Provider dialog box, in the EPG Type field, click the appropriate
radio button depending upon where the DHCP server is connected.
c) In the Application EPG area, in the Tenant field, from the drop-down list, choose the tenant. (infra)
d) In the Application Profile field, from the drop-down list, choose the application. (access)
e) In the EPG field, from the drop-down list, choose the EPG. (default)
f) In the DHCP Server Address field, enter the IP address for the infra DHCP server. Click Update.
Note
The infra DHCP IP address is the infra IP address of APIC1. You must enter the default IP address
of 10.0.0.1 if deploying for vShield controller configuration.
g) Click Submit.
The DHCP relay policy is created.
In the Navigation pane, expand Networking > Bridge Domains > default > DHCP Relay Labels.
Step 5
Step 6
Right-click DHCP Relay Labels, and click Create DHCP Relay Label.
In the Create DHCP Relay Label dialog box, perform the following actions:
a) In the Scope field, click the tenant radio button.
This action displays, in the Name field drop-down list, the DHCP relay policy created earlier.
b) In the Name field, from the drop-down list, choose the name of the DHCP policy created (DhcpRelayP)
or create a new relay policy by choosing Create DHCP Relay Policy.
c) In the DHCP Option Policy, select an existing option policy, or create a new one by choosing Create
DHCP Option Policy.
d) Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
92
Provisioning Core ACI Fabric Services
Configuring a DHCP Server Policy for the APIC Infrastructure Using the NX-OS Style CLI
Step 7
The DHCP server is associated with the bridge domain.
In the Navigation pane, expand Networking > Bridge Domains > default > DHCP Relay Labels to view
the DHCP server created.
Configuring a DHCP Server Policy for the APIC Infrastructure Using the NX-OS
Style CLI
• The port and the encapsulation used by the application Endpoint Group must belong to a physical or
VM Manager (VMM) domain. If no such association with a domain is established, the APIC continues
to deploy the EPG but raises a fault.
• Cisco APIC supports DHCP relay for both IPv4 and IPv6 tenant subnets. DHCP server addresses can
be IPv4 or IPv6. DHCPv6 relay will occur only if IPv6 is enabled on the fabric interface and one or
more DHCPv6 relay servers are configured.
Before You Begin
Ensure that Layer 2 or Layer 3 connectivity is configured to reach the DHCP server address.
Procedure
Configure DHCP server policy settings for the APIC infrastructure traffic.
Example:
DHCP Relay Policy for an Endpoint Group
apic1(config)# tenant infra
apic1(config-tenant)# template dhcp relay policy DhcpRelayP
apic1(config-tenant-template-dhcp-relay)# ip address 10.0.0.1 tenant
infra application access epg
default
apic1(config-tenant-template-dhcp-relay)# exit
apic1(config-tenant)# interface bridge-domain default
apic1(config-tenant-interface)# dhcp relay policy tenant
apic1(config-tenant-interface)# exit
DhcpRelayP
Configuring a DHCP Server Policy for the APIC Infrastructure Using the REST
API
• This task is a prerequisite for users who want to create a vShield Domain Profile.
• The port and the encapsulation used by the application Endpoint Group must belong to a physical or
VM Manager (VMM) domain. If no such association with a domain is established, the APIC continues
to deploy the EPG but raises a fault.
• Cisco APIC supports DHCP relay for both IPv4 and IPv6 tenant subnets. DHCP server addresses can
be IPv4 or IPv6. DHCPv6 relay will occur only if IPv6 is enabled on the fabric interface and one or
more DHCPv6 relay servers are configured.
Cisco APIC Basic Configuration Guide, Release 2.x
93
Provisioning Core ACI Fabric Services
Configuring a DNS Service Policy
Before You Begin
Make sure that Layer 2 or Layer 3 management connectivity is configured.
Procedure
Configure the APIC as the DHCP server policy for the infrastructure tenant.
Note
This relay policy will be pushed to all the leaf ports that are connected hypervisors using the attach
entity profile configuration. For details about configuring with attach entity profile, see the examples
related to creating VMM domain profiles.
Example:
DHCP Relay Policy for EPG
<!-- api/policymgr/mo/.xml -->
<polUni>
POST https://apic-ip-address/api/mo/uni.xml
<fvTenant name="infra">
<dhcpRelayP name="DhcpRelayP" owner="tenant">
<dhcpRsProv tDn="uni/tn-infra/ap-access/epg-default" addr="10.0.0.1" />
</dhcpRelayP>
<fvBD name="default">
<dhcpLbl name="DhcpRelayP" owner="tenant"/>
</fvBD>
</fvTenant>
</polUni>
Configuring a DNS Service Policy
A DNS policy is required to connect to external servers, for example AAA, RADIUS, vCenter, and services
by hostname. A DNS service policy is a shared policy, so any tenant and VRF that uses this service must be
configured with the specific DNS profile label. To configure a DNS policy for the ACI fabric, you must
complete the following tasks:
• Ensure that the management EPG is configured for the DNS policy, otherwise this policy will not take
into effect on the switches.
• Create a DNS profile (default) that contains the information about DNS providers and DNS domains.
• Associate the DNS profile (default or another DNS profile) name to a DNS label under the required
tenant.
It is possible to configure a per-tenant, per-VRF DNS profile configuration. Additional DNS profiles can be
created and applied to specific VRFs of specific tenants using the appropriate DNS label. For example, if you
create a DNS profile with a name of acme, you can add a DNS label of acme to the appropriate Networking
> VRF policy configuration in the tenants configuration.
Configuring External Destinations with an In-Band DNS Service Policy
Configure the external destinations for the services as follows:
Cisco APIC Basic Configuration Guide, Release 2.x
94
Provisioning Core ACI Fabric Services
Configuring External Destinations with an In-Band DNS Service Policy
Source
In-Band Management
Out-of-Band Management External Server Location
APIC
IP address or Fully
Qualified domain name
(FQDN)
IP address or FQDN
Anywhere
Leaf switches
IP address
IP address or FQDN
Anywhere
Note
Spine switches
IP address
The DNS policy
must specify the
out-of-band
management
EPG for
reachability of
the DNS server.
IP address or FQDN
Note
Directly connected to a
The DNS policy leaf switch
must specify the
out-of-band
management
EPG for
reachability of
the DNS server.
The following is a list of external servers:
• Call Home SMTP server
• Syslog server
• SNMP Trap destination
• Statistics Export destination
• Configuration Export destination
• Techsupport Export destination
• Core Export destination
The recommended guidelines are as follows:
• The external servers must be atatched to the leaf access ports.
• Use in-band connectivity for the leaf switches to avoid extra cabling for the management port.
• Use out-of-band management connectivity for the spine switches. Connect this out-of-band network for
spine switches to one of the leaf ports with in-band management virtual routing and forwarding (VRF)
so that the spine switches and the leaf switches can reach the same set of external servers.
• Use IP addresses for the external servers.
Cisco APIC Basic Configuration Guide, Release 2.x
95
Provisioning Core ACI Fabric Services
Dual Stack IPv4 and IPv6 DNS Servers
Dual Stack IPv4 and IPv6 DNS Servers
DNS servers have primary DNS records which can be A records (IPV4) or AAAA records (IPV6). Both A
and AAAA records associate domain name with a specific IP address (IPv4 or IPv6).
The ACI fabric can be configured to use reputable public DNS servers that run on IPv4. These servers are
able to resolve and respond with A record (IPv4) or AAAA record (IPv6).
In a pure IPv6 environment, the system administrators must use IPv6 DNS servers. The IPv6 DNS servers
are enabled by adding them to /etc/resolv.conf.
A more common environment is to have dual-stack IPv4 and IPv6 DNS servers. In the dual-stack case, both
IPv4 and IPv6 name servers are listed in /etc/resolv.conf. However, in a dual-stack environment, simply
appending the IPv6 DNS servers to the list may cause a large delay in DNS resolutions. This is because the
IPv6 protocol takes precedence by default, and it is unable to connect to the IPv4 DNS servers (if they are
listed first in /etc/resolv.conf). The solution is to list IPv6 DNS servers ahead of IPv4 DNS servers. Also add
“options single-request-reopen” to enable the same socket to be used for both IPv4 and IPv6 lookups.
Here is an example of resolv.conf in dual-stack IPv4 and IPv6 DNS servers where the IPv6 DNS servers are
listed first. Also note the “single-request-reopen” option:
options single-request-reopen
nameserver 2001:4860:4680::8888
nameserver 2001:4860:4680::8844
nameserver 8.8.8.8
nameserver 8.8.4.4
Dual-Stack IPv4 and IPv6 Environment
If the management network in the ACI fabric supports both IPv4 and IPv6, the Linux system application
(glibc) will use the IPv6 network by default because getaddrinfo() will return IPv6 first.
Under certain conditions however, an IPv4 address may be preferred over an IPv6 address. The Linux IPv6
stack has a feature which allows an IPv4 address mapped as an IPv6 address using IPv6 mapped IPv4 address
(::ffff/96). This allows an IPv6 capable application to use only a single socket to accept or connect both IPv4
and IPv6. This is controlled by the glibc IPv6 selection preference for getaddrinfo() in /etc/gai.conf.
In order to allow glibc to return multiple addresses when using /etc/hosts, “multi on” should be added to the
/etc/hosts file. Otherwise, it may return only the first match.
If an application is not aware whether both IPv4 and IPv6 exist, it may not perform fallback attempts using
different address families. Such applications may require a fallback implementation.
Policy for Priority of IPv4 or IPv6 in a DNS Profile
The DNS profile supports version preference choices between IPv4 and IPv6. Using the user interface, you
can enable your preference. IPv4 is the default.
The following is an example of a policy based configuration using Postman REST API:
<?xml version="1.0" encoding="UTF-8”?>
<!— api/node/mo/uni/fabric/dnsp-default.xml —>
<dnsProfile dn="uni/fabric/dnsp-default" IPVerPreference="IPv6" childAction="" descr="" >
</dnsProfile>
The gai.conf settings control destination address selection. The file has a label table, precedence table, and
an IPv4 scopes table. The changes for prioritizing IPv4 or IPv6 over the other need to go into the precedence
Cisco APIC Basic Configuration Guide, Release 2.x
96
Provisioning Core ACI Fabric Services
Configuring a DNS Service Policy to Connect with DNS Providers Using the Basic GUI
table entries. Given below are sample contents of the standard file as it is used in Linux systems for many
flavors. A single line of precedence label in the file overrides any default settings.
The following is an example of a gai.conf to prioritize IPv4 over IPv6:
# Generated by APIC
label ::1/128
0
label ::/0
1
label 2002::/16
2
label ::/96
3
label ::ffff:0:0/96 4
precedence ::1/128
50
precedence ::/0
40
precedence 2002::/16
30
precedence ::/96
20
# For APICs prefering IPv4 connections, change the value to 100.
precedence ::ffff:0:0/96 10
Configuring a DNS Service Policy to Connect with DNS Providers Using the
Basic GUI
Before You Begin
Make sure that Layer 2 or Layer 3 management connectivity is configured.
Procedure
Step 1
Step 2
Step 3
On the menu bar, choose System > System Settings. In the Navigation pane, expand System Settings >
DNS, and click the default DNS profile.
In the Work pane, in the Management EPG field, from the drop-down list, choose the appropriate management
EPG (default (Out-of-Band)).
Expand DNS Providers, and perform the following actions:
a) In the Address field, enter the provider address.
b) In the Preferred column, check the check box if you want to have this address as the preferred provider.
You can have only one preferred provider.
c) Click Update.
d) (Optional) To add a secondary DNS provider, expand DNS Providers, and in the Address field, type the
provider address. Click Update.
Step 4
Expand DNS Domains, and perform the following actions:
a) In the Name field, enter the domain name (cisco.com).
b) In the Default column, check the check box to make this domain the default domain.
You can have only one domain name as the default.
c) Click Update.
d) (Optional) To add a secondary DNS domain, expand DNS Domains. In the Address field, enter the
secondary domain name. Click Update.
Step 5
Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
97
Provisioning Core ACI Fabric Services
Configuring a DNS Service Policy to Connect with DNS Providers Using the Advanced GUI
Step 6
Step 7
Step 8
The DNS server is configured.
On the menu bar, click Tenants > mgmt.
In the Navigation pane, expand Networking > VRFs > oob.
In the Work pane, under Properties, in the DNS labels field, enter the appropriate DNS label (default). Click
Submit.
The DNS profile label is now configured on the tenant and VRF.
Configuring a DNS Service Policy to Connect with DNS Providers Using the
Advanced GUI
Before You Begin
Make sure that Layer 2 or Layer 3 management connectivity is configured.
Procedure
Step 1
Step 2
Step 3
On the menu bar, choose FABRIC > Fabric Policies. In the Navigation pane, expand Global Policies >
DNS Profiles, and click the default DNS profile.
In the Work pane, in the Management EPG field, from the drop-down list, choose the appropriate management
EPG (default (Out-of-Band)).
Expand DNS Providers, and perform the following actions:
a) In the Address field, enter the provider address.
b) In the Preferred column, check the check box if you want to have this address as the preferred provider.
You can have only one preferred provider.
c) Click Update.
d) (Optional) To add a secondary DNS provider, expand DNS Providers, and in the Address field, type the
provider address. Click Update.
Step 4
Expand DNS Domains, and perform the following actions:
a) In the Name field, enter the domain name (cisco.com).
b) In the Default column, check the check box to make this domain the default domain.
You can have only one domain name as the default.
c) Click Update.
d) (Optional) To add a secondary DNS domain, expand DNS Domains. In the Address field, enter the
secondary domain name. Click Update.
Step 5
Click Submit.
The DNS server is configured.
On the menu bar, click TENANTS > mgmt.
In the Navigation pane, expand Networking > VRF > oob, and click oob.
Step 6
Step 7
Step 8
In the Work pane, under Properties, in the DNS labels field, enter the appropriate DNS label (default). Click
Submit.
The DNS profile label is now configured on the tenant and VRF.
Cisco APIC Basic Configuration Guide, Release 2.x
98
Provisioning Core ACI Fabric Services
Configuring a DNS Service Policy to Connect with DNS Providers Using the NX-OS Style CLI
Configuring a DNS Service Policy to Connect with DNS Providers Using the
NX-OS Style CLI
Procedure
Step 1
In the NX-OS CLI, get into configuration mode, shown as follows:
Example:
apic1# configure
apic1(config)#
Step 2
Configure a DNS server policy.
Example:
apic1(config)# dns
apic1(config-dns)#
apic1(config-dns)#
apic1(config-dns)#
apic1(config-dns)#
Step 3
address 172.21.157.5 preferred
address 172.21.157.6
domain company.local default
use-vrf oob-default
Configure a DNS profile label on any VRF where you want to use the DNS profile.
Example:
apic1(config)# tenant mgmt
apic1(config-tenant)# vrf context oob
apic1(config-tenant-vrf)# dns label default
Configuring a DNS Service Policy to Connect with DNS Providers Using the
REST API
Before You Begin
Make sure that Layer 2 or Layer 3 management connectivity is configured.
Procedure
Step 1
Configure the DNS service policy.
Example:
POST URL :
https://apic-IP-address/api/node/mo/uni/fabric.xml
<dnsProfile name="default">
Cisco APIC Basic Configuration Guide, Release 2.x
99
Provisioning Core ACI Fabric Services
Verifying that the DNS Profile is Configured and Applied to the Fabric Controller Switches Using the NX-OS Style
CLI
<dnsProv addr="172.21.157.5" preferred="yes"/>
<dnsProv addr="172.21.157.6"/>
<dnsDomain name="cisco.com" isDefault="yes"/>
<dnsRsProfileToEpg tDn="uni/tn-mgmt/mgmtp-default/oob-default"/>
</dnsProfile>
Step 2
Configure the DNS label under the out-of-band management tenant.
Example:
POST URL: https://apic-IP-address/api/node/mo/uni/tn-mgmt/ctx-oob.xml
<dnsLbl name="default" tag="yellow-green"/>
Verifying that the DNS Profile is Configured and Applied to the Fabric Controller
Switches Using the NX-OS Style CLI
Procedure
Step 1
Verify the configuration for the default DNS profile.
Example:
apic1# show running-config dns
# Command: show running-config dns
# Time: Sat Oct 3 00:23:52 2015
dns
address 172.21.157.5 preferred
address 172.21.157.6
domain company.local default
use-vrf oob-default
exit
Step 2
Verify the configurations for the DNS labels.
Example:
apic1# show running-config tenant mgmt vrf context oob
# Command: show running-config tenant mgmt vrf context oob
# Time: Sat Oct 3 00:24:36 2015
tenant mgmt
vrf context oob
dns label default
exit
exit
Step 3
Verify that the applied configuration is operating on the fabric controllers.
Example:
apic1# cat /etc/resolv.conf
# Generated by IFC
Cisco APIC Basic Configuration Guide, Release 2.x
100
Provisioning Core ACI Fabric Services
Configuring Custom Certificate Guidelines
nameserver 172.21.157.5
nameserver 172.21.157.6
Configuring Custom Certificate Guidelines
• Wildcard certificates (such as *.cisco.com, which is used across multiple devices) and its associated
private key generated elsewhere are not supported on the APIC as there is no support to input the private
key or password in the APIC. Also, exporting private keys for any certificates, including wildcard
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 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 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.
Configuring a Custom Certificate for Cisco ACI HTTPS Access
Using the GUI
CAUTION: PERFORM THIS TASK ONLY DURING A MAINTENANCE WINDOW AS THERE IS A
POTENTIAL FOR DOWNTIME. The downtime affects access to the APIC cluster and switches from external
users or systems and not the APIC to switch connectivity. The NGINX process on the switches will also be
impacted but that will be only for external connectivity and not for the fabric data plane. Access to the APIC,
configuration, management, troubleshooting and such will be impacted. Expect a restart of all web servers in
the fabric during this operation.
Before You Begin
Determine from which authority you will obtain the trusted certification so that you can create the appropriate
Certificate Authority.
Cisco APIC Basic Configuration Guide, Release 2.x
101
Provisioning Core ACI Fabric Services
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Procedure
Step 1
Step 2
On the menu bar, choose Admin > AAA.
In the Navigation pane, choose Public Key Management > Certificate Authorities.
Step 3
In the Work pane, choose Actions > Create Certificate Authority.
Step 4
In the Create Certificate Authority dialog box, in the Name field, enter a name for the certificate authority.
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 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
Step 7
Click Submit.
In the Navigation pane, choose Public Key Management > Key Rings.
Step 8
In the Work pane, choose Actions > Create Key Ring.
Step 9
In the Create Key Ring dialog box, in the Name field, enter a name.
Step 10 In the Certificate field, do not add any content.
Step 11 In the Modulus field, click the radio button for the desired key strength.
Step 12 In the Certificate Authority field, from the drop-down list, choose the certificate authority that you created
earlier. Click Submit.
Note
Do not delete the key ring. Deleting the key ring will automatically delete the associated private key
used with CSRs.
In the Work pane, in the Key Rings area, the Admin State for the key ring created displays Started.
Step 13 In the Navigation pane, choose Public Key Management > Key Rings > key_ring_name.
Step 14 In the Work pane, choose Actions > Create Certificate Request.
Step 15 In the Subject field, enter the fully qualified domain name (FQDN) of the APIC.
Step 16 Fill in the remaining fields as appropriate.
Note
Check the online help information available in the Create Certificate Request dialog box for a
description of the available parameters.
Step 17 Click Submit.
The object is created and displayed in the Navigation pane under the key ring you created earlier. In the
Navigation pane, click the object and in the Work pane, in the Properties area, in the Request field the CSR
is displayed. Copy the contents from the field to submit to the Certificate Authority.
Step 18 In the Navigation pane, choose Public Key Management > Key Rings > key_ring_name.
Step 19 In the Work pane, in the Certificate field, paste the signed certificate that you received from the certificate
authority.
Step 20 Click Submit.
Note
If the CSR was not signed by the Certificate Authority indicated in the key ring, or if the certificate
has MS-DOS line endings, an error message is displayed and the certificate is not accepted. Remove
the MS-DOS line endings.
Cisco APIC Basic Configuration Guide, Release 2.x
102
Provisioning Core ACI Fabric Services
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
The key is verified, and in the Work pane, the Admin State changes to Completed and is now ready for use
in the HTTP policy.
Step 21 On the menu bar, choose Fabric > Fabric Policies.
Step 22 In the Navigation pane, choose Pod Policies > Policies > Management Access > default.
Step 23 In the Work pane, in the Admin Key Ring drop-down list, choose the desired key ring.
Step 24 Click Submit.
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 APIC.
Cisco APIC Basic Configuration Guide, Release 2.x
103
Provisioning Core ACI Fabric Services
Configuring a Custom Certificate for Cisco ACI HTTPS Access Using the GUI
Cisco APIC Basic Configuration Guide, Release 2.x
104
CHAPTER
6
Basic User Tenant Configuration
This chapter contains the following sections:
• Tenants, page 105
• Routing Within the Tenant, page 106
• Creating Tenants, VRF, and Bridge Domains, page 119
• Deploying an Application Policy, page 120
• Statically Deploying an EPG on a Specific Port, page 129
• Creating Domains, Attach Entity Profiles, and VLANs to Deploy an EPG on a Specific Port, page 131
• Deploying an Application EPG through an AEP or Interface Policy Group to Multiple Ports, page 135
• Using Microsegmentation with Network-based Attributes on Bare Metal, page 139
• IP Address-Based Microsegmented EPG as a Shared Resource, page 144
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
Cisco APIC Basic Configuration Guide, Release 2.x
105
Basic User Tenant Configuration
Routing Within the Tenant
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 1: Tenants
Tenants can be isolated from one another or can share resources. The primary elements that the tenant contains
are filters, contracts, outside networks, bridge domains, Virtual Routing and Forwarding (VRF) instances,
and application profiles that contain endpoint groups (EPGs). Entities in the tenant inherit its policies. VRFs
are also known as contexts; each VRF can be associated with multiple bridge domains.
Note
In the APIC GUI under the tenant navigation path, a VRF (context) is called a private network.
Tenants are logical containers for application policies. The fabric can contain multiple tenants. You must
configure a tenant before you can deploy any Layer 4 to Layer 7 services. The ACI fabric supports IPv4, IPv6,
and dual-stack configurations for tenant networking.
Routing Within the Tenant
The Application Centric Infrastructure (ACI) fabric provides tenant default gateway functionality and routes
between the fabric virtual extensible local area (VXLAN) networks. For each tenant, the fabric provides a
virtual default gateway or Switched Virtual Interface (SVI) whenever a subnet is created on the APIC. This
spans any switch that has a connected endpoint for that tenant subnet. Each ingress interface supports the
default gateway interface and all of the ingress interfaces across the fabric share the same router IP address
and MAC address for a given tenant subnet.
Cisco APIC Basic Configuration Guide, Release 2.x
106
Basic User Tenant Configuration
Layer 3 VNIDs Facilitate Transporting Inter-subnet Tenant Traffic
Layer 3 VNIDs Facilitate Transporting Inter-subnet Tenant Traffic
The ACI fabric provides tenant default gateway functionality that routes between the ACI fabric VXLAN
networks. For each tenant, the fabric provides a virtual default gateway that spans all of the leaf switches
assigned to the tenant. It does this at the ingress interface of the first leaf switch connected to the endpoint.
Each ingress interface supports the default gateway interface. All of the ingress interfaces across the fabric
share the same router IP address and MAC address for a given tenant subnet.
The ACI fabric decouples the tenant endpoint address, its identifier, from the location of the endpoint that is
defined by its locator or VXLAN tunnel endpoint (VTEP) address. Forwarding within the fabric is between
VTEPs. The following figure shows decoupled identity and location in ACI.
Figure 2: ACI Decouples Identity and Location
VXLAN uses VTEP devices to map tenant end devices to VXLAN segments and to perform VXLAN
encapsulation and de-encapsulation. Each VTEP function has two interfaces:
• A switch interface on the local LAN segment to support local endpoint communication through bridging
• An IP interface to the transport IP network
The IP interface has a unique IP address that identifies the VTEP device on the transport IP network known
as the infrastructure VLAN. The VTEP device uses this IP address to encapsulate Ethernet frames and transmit
the encapsulated packets to the transport network through the IP interface. A VTEP device also discovers the
remote VTEPs for its VXLAN segments and learns remote MAC Address-to-VTEP mappings through its IP
interface.
The VTEP in ACI maps the internal tenant MAC or IP address to a location using a distributed mapping
database. After the VTEP completes a lookup, the VTEP sends the original data packet encapsulated in
VXLAN with the destination address of the VTEP on the destination leaf switch. The destination leaf switch
de-encapsulates the packet and sends it to the receiving host. With this model, ACI uses a full mesh, single
hop, loop-free topology without the need to use the spanning-tree protocol to prevent loops.
The VXLAN segments are independent of the underlying network topology; conversely, the underlying IP
network between VTEPs is independent of the VXLAN overlay. It routes the encapsulated packets based on
the outer IP address header, which has the initiating VTEP as the source IP address and the terminating VTEP
as the destination IP address.
Cisco APIC Basic Configuration Guide, Release 2.x
107
Basic User Tenant Configuration
Layer 3 VNIDs Facilitate Transporting Inter-subnet Tenant Traffic
The following figure shows how routing within the tenant is done.
Figure 3: Layer 3 VNIDs Transport ACI Inter-subnet Tenant Traffic
For each tenant VRF in the fabric, ACI assigns a single L3 VNID. ACI transports traffic across the fabric
according to the L3 VNID. At the egress leaf switch, ACI routes the packet from the L3 VNID to the VNID
of the egress subnet.
Traffic arriving at the fabric ingress that is sent to the ACI fabric default gateway is routed into the Layer 3
VNID. This provides very efficient forwarding in the fabric for traffic routed within the tenant. For example,
with this model, traffic between 2 VMs belonging to the same tenant, on the same physical host, but on
different subnets, only needs to travel to the ingress switch interface before being routed (using the minimal
path cost) to the correct destination.
To distribute external routes within the fabric, ACI route reflectors use multiprotocol BGP (MP-BGP). The
fabric administrator provides the autonomous system (AS) number and specifies the spine switches that
become route reflectors.
Cisco APIC Basic Configuration Guide, Release 2.x
108
Basic User Tenant Configuration
Router Peering and Route Distribution
Router Peering and Route Distribution
As shown in the figure below, when the routing peer model is used, the leaf switch interface is statically
configured to peer with the external router’s routing protocol.
Figure 4: Router Peering
The routes that are learned through peering are sent to the spine switches. The spine switches act as route
reflectors and distribute the external routes to all of the leaf switches that have interfaces that belong to the
same tenant. These routes are longest prefix match (LPM) summarized addresses and are placed in the leaf
switch's forwarding table with the VTEP IP address of the remote leaf switch where the external router is
connected. WAN routes have no forwarding proxy. If the WAN routes do not fit in the leaf switch's forwarding
table, the traffic is dropped. Because the external router is not the default gateway, packets from the tenant
endpoints (EPs) are sent to the default gateway in the ACI fabric.
Cisco APIC Basic Configuration Guide, Release 2.x
109
Basic User Tenant Configuration
Bridged Interface to an External Router
Bridged Interface to an External Router
As shown in the figure below, when the leaf switch interface is configured as a bridged interface, the default
gateway for the tenant VNID is the external router.
Figure 5: Bridged External Router
The ACI fabric is unaware of the presence of the external router and the APIC statically assigns the leaf switch
interface to its EPG.
Configuring Route Reflectors
The ACI fabric route reflectors use multiprotocol BGP (MP-BGP) to distribute external routes within the
fabric. To enable route reflectors in the ACI fabric, the fabric administrator must select the spine switches
that will be the route reflectors, and provide the autonomous system (AS) number. Once route reflectors are
enabled in the ACI fabric, administrators can configure connectivity to external networks as described in the
following sections.
To connect external routers to the ACI fabric, the fabric infrastructure administrator configures spine nodes
as Border Gateway Protocol (BGP) route reflectors. For redundancy purposes, more than one spine is configured
as a router reflector node (one primary and one secondary reflector).
When a tenant needs to attach a WAN router to the ACI fabric, the infrastructure administrator configures
the leaf node (as described below) to which the WAN router is being connected as WAN top of rack (ToR)
and pairs this WAN ToR with one of the route reflector nodes as a BGP peer. When route reflectors are
configured on the WAN ToR, they are able to advertise the tenant routes into the fabric.
Each leaf node can store up to 4000 routes. If a WAN router has to advertise more than 4000 routes, it should
peer with multiple leaf nodes. The infrastructure administrator configures each of the paired leaf nodes with
the routes (or route prefixes) that it can advertise.
The infrastructure administrator must configure an external WAN router connected to the fabric as follows:
1 Configure up to two spine nodes as route reflectors. For redundancy, configure primary and secondary
route reflectors.
2 On WAN ToRs, configure the primary and secondary route reflector nodes.
Cisco APIC Basic Configuration Guide, Release 2.x
110
Basic User Tenant Configuration
Configuring Route Reflectors
3 On WAN ToRs, configure the routes that the ToR is responsible for advertising. This is optional and needs
to be done only when the tenant router is known to advertise more than 4000 routes.
Configuring External Connectivity for Tenants
Before you can distribute the static route to the other leaf switches on the Application Centric Infrastructure
(ACI) fabric, a multiprotocol BGP (MP-BGP) process must first be operating, and the spine switches must
be configured as BGP route reflectors.
To integrate the ACI fabric into an external routed network, you can configure Open Shortest Path First
(OSPF) for management tenant Layer 3 connectivity.
Configuring an MP-BGP Route Reflector Using the Basic GUI
Procedure
Step 1
Step 2
Step 3
Step 4
On the menu bar, choose System > System Settings.
In the Navigation pane, expand System Settings > BGP Route Reflector, right-click BGP Route Reflector,
and click Create Route Reflector Node Policy EP.
In the Create Route Reflector Node Policy EP dialog box, from the Spine Node drop-down list, choose the
appropriate spine node. Click Submit.
Note
Repeat the above steps to add additional spine nodes as
required.
The spine switch is marked as the route reflector node.
In the Autonomous System Number field, choose the appropriate number. Click Submit.
Note
The autonomous system number must match the leaf connected router configuration if Border Gateway
Protocol (BGP) is configured on the router. If you are using routes learned using static or Open
Shortest Path First (OSPF), the autonomous system number value can be any valid value.
Configuring an MP-BGP Route Reflector Using the Advanced GUI
Procedure
Step 1
Step 2
Step 3
Step 4
On the menu bar, choose FABRIC > Fabric Policies.
In the Navigation pane, expand Pod Policies > Policies > BGP Route Reflector default, right-click BGP
Route Reflector default, and click Create Route Reflector Node Policy EP.
In the Create Route Reflector Node Policy EP dialog box, from the Spine Node drop-down list, choose the
appropriate spine node. Click Submit.
Note
Repeat the above steps to add additional spine nodes as
required.
The spine switch is marked as the route reflector node.
In the BGP Route Reflector default properties area, in the Autonomous System Number field, choose the
appropriate number. Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
111
Basic User Tenant Configuration
Configuring Route Reflectors
The autonomous system number must match the leaf connected router configuration if Border Gateway
Protocol (BGP) is configured on the router. If you are using routes learned using static or Open
Shortest Path First (OSPF), the autonomous system number value can be any valid value.
In the Navigation pane, expand and right-click Policy Groups, and click Create POD Policy Group.
Note
Step 5
Step 6
Step 7
Step 8
In the Create POD Policy Group dialog box, in the Name field, enter the name of a pod policy group.
In the BGP Route Reflector Policy drop-down list, choose the appropriate policy (default). Click Submit.
The BGP route reflector policy is associated with the route reflector pod policy group, and the BGP process
is enabled on the leaf switches.
In the Navigation pane, choose Pod Policies > Profiles > default. In the Work pane, from the Fabric Policy
Group drop-down list, choose the pod policy that was created earlier. Click Submit.
The pod policy group is now applied to the fabric policy group.
Configuring an MP-BGP Route Reflector for the ACI Fabric
To distribute routes within the ACI fabric, an MP-BGP process must first be operating, and the spine switches
must be configured as BGP route reflectors.
The following is an example of an MP-BGP route reflector configuration:
Note
In this example, the BGP fabric ASN is 100. Spine switches 104 and 105 are chosen as MP-BGP
route-reflectors.
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 100
apic1(config-bgp-fabric)# route-reflector spine 104,105
Configuring an MP-BGP Route Reflector Using the REST API
Procedure
Step 1
Mark the spine switches as route reflectors.
Example:
POST https://apic-ip-address/api/policymgr/mo/uni/fabric.xml
<bgpInstPol name="default">
<bgpAsP asn="1" />
<bgpRRP>
<bgpRRNodePEp id=“<spine_id1>”/>
<bgpRRNodePEp id=“<spine_id2>”/>
</bgpRRP>
</bgpInstPol>
Step 2
Set up the pod selector using the following post.
Example:
Cisco APIC Basic Configuration Guide, Release 2.x
112
Basic User Tenant Configuration
Configuring Route Reflectors
For the FuncP setup—
POST https://apic-ip-address/api/policymgr/mo/uni.xml
<fabricFuncP>
<fabricPodPGrp name="bgpRRPodGrp”>
<fabricRsPodPGrpBGPRRP tnBgpInstPolName="default" />
</fabricPodPGrp>
</fabricFuncP>
Example:
For the PodP setup—
POST https://apic-ip-address/api/policymgr/mo/uni.xml
<fabricPodP name="default">
<fabricPodS name="default" type="ALL">
<fabricRsPodPGrp tDn="uni/fabric/funcprof/podpgrp-bgpRRPodGrp"/>
</fabricPodS>
</fabricPodP>
Verifying the MP-BGP Route Reflector Configuration
Procedure
Step 1
Verify the configuration by performing the following actions:
a) Use secure shell (SSH) to log in as an administrator to each leaf switch as required.
b) Enter the show processes | grep bgp command to verify the state is S.
If the state is NR (not running), the configuration was not successful.
Step 2
Verify that the autonomous system number is configured in the spine switches by performing the following
actions:
a) Use the SSH to log in as an administrator to each spine switch as required.
b) Execute the following commands from the shell window
Example:
cd /mit/sys/bgp/inst
Example:
grep asn summary
The configured autonomous system number must be displayed. If the autonomous system number value
displays as 0, the configuration was not successful.
Cisco APIC Basic Configuration Guide, Release 2.x
113
Basic User Tenant Configuration
Configuring Route Reflectors
Creating OSPF External Routed Network for Management Tenant Using Basic GUI
Before You Begin
• You must verify that the router ID and the logical interface profile IP address are different and do not
overlap.
• The following steps are for creating an OSPF external routed network for a management tenant. To
create an OSPF external routed network for a tenant, you must choose a tenant and create a VRF for the
tenant.
• For more details, see Cisco APIC and Transit Routing.
Procedure
Step 1
Step 2
Step 3
On the menu bar, click Fabric > Inventory. In the Navigation pane, click the leaf switch where you want to
deploy the VRF.
Right-click and click Configure VRF.
In the Configure VRF dialog box, perform the following actions:
a) From the Tenant field drop-down list, choose a tenant.
In this case it is the mgmt tenant.
b)
c)
d)
e)
f)
From the VRF field drop-down list, choose the VRF.
In the Router ID field, enter the router ID.
In the Protocols area, check the check box for OSPF.
In the Route Maps area that gets displayed, click the + sign.
In the Create Route Map dialog box, in the Name field, enter a name for the route map.
Step 4
Expand the Prefix List area.
a) In the Create Prefix List dialog box, in the Prefix Name field, enter an area ID.
b) In the IP Prefixes field, enter at least one prefix.
c) Enter additional details in the dialog box as required.
d) In the Prefix List dialog box, click OK.
Step 5
In the Configure VRF with Leaf dialog box, expand the OSPF Configuration area.
a)
b)
c)
d)
In the Configure OSPF dialog box, in the Area ID field, enter an area ID.
In the Area Type field, choose the desired type.
From the Route Map field drop-down list, choose the appropriate route map. Click OK.
In the Configure VRF dialog box, click Submit.
In the Navigation pane under VRFs, the VRF is deployed.
Step 6
In the Navigation pane, expand Interfaces > Physical Interfaces.
Step 7
Choose the desired interface where you want to configure Layer 3 and perform the following actions:
a) Click the Convert to L3 button. Click Yes in the Warning dialog box for "L2 configuration will be
deleted. Do you want to continue?"
b) In the Subinterface field click the Off button.
c) From the Tenant field drop-down list, choose the appropriate tenant (mgmt).
d) From the VRF field drop-down list, choose the appropriate VRF.
Cisco APIC Basic Configuration Guide, Release 2.x
114
Basic User Tenant Configuration
Configuring Route Reflectors
e) In the IPv4 Address field, enter an IP address for the interface.
f) In the Protocols field, check the check box for OSPF.
In the top right corner of the dialog box, the OSPF tab is displayed.
g) Click the OSPF tab.
h) In the Work pane, in the IP V4 OSPF Area ID field, from the drop-down list, choose the desired area
ID.
i) In the Policy Name field, choose the default policy.
Alternatively, choose the authentication type, authentication key, policy name in this area. Click Submit.
This creates the management interface. The OSPF is deployed in the
VRF.
j) In the Navigation pane, when you click on the OSPF deployed in the VRF, the Work pane displays the
statistics.
Note
The OSPF external routed network for the management tenant is created.
Creating an OSPF External Routed Network for Management Tenant Using the Advanced GUI
• You must verify that the router ID and the logical interface profile IP address are different and do not
overlap.
• The following steps are for creating an OSPF external routed network for a management tenant. To
create an OSPF external routed network for a tenant, you must choose a tenant and create a VRF for the
tenant.
• For more details, see Cisco APIC and Transit Routing.
Procedure
Step 1
Step 2
On the menu bar, choose TENANTS > mgmt.
In the Navigation pane, expand Networking > External Routed Networks.
Step 3
Step 4
Right-click External Routed Networks, and click Create Routed Outside.
In the Create Routed Outside dialog box, perform the following actions:
a)
b)
c)
d)
e)
f)
g)
In the Name field, enter a name (RtdOut).
Check the OSPF check box.
In the OSPF Area ID field, enter an area ID.
In the OSPF Area Control field, check the appropriate check box.
In the OSPF Area Type field, choose the appropriate area type.
In the OSPF Area Cost field, choose the appropriate value.
In the VRF field, from the drop-down list, choose the VRF (inb).
Note
This step associates the routed outside with the in-band
VRF.
h) From the External Routed Domain drop-down list, choose the appropriate domain.
i) Click the + icon for Nodes and Interfaces Protocol Profiles area.
Step 5
In the Create Node Profile dialog box, perform the following actions:
a) In the Name field, enter a name for the node profile. (borderLeaf).
Cisco APIC Basic Configuration Guide, Release 2.x
115
Basic User Tenant Configuration
Configuring Route Reflectors
b)
c)
d)
e)
In the Nodes field, click the + icon to display the Select Node dialog box.
In the Node ID field, from the drop-down list, choose the first node. (leaf1).
In the Router ID field, enter a unique router ID.
Uncheck the Use Router ID as Loopback Address field.
Note
By default, the router ID is used as a loopback address. If you want them to be different, uncheck
the Use Router ID as Loopback Address check box.
f) Expand Loopback Addresses, and enter the IP address in the IP field. Click Update, and click OK.
Enter the desired IPv4 or IPv6 IP address.
g) In the Nodes field, expand the + icon to display the Select Node dialog box.
Note
You are adding a second node
ID.
h) In the Node ID field, from the drop-down list, choose the next node. (leaf2).
i) In the Router ID field, enter a unique router ID.
j) Uncheck the Use Router ID as Loopback Address field.
Note
By default, the router ID is used as a loopback address. If you want them to be different, uncheck
the Use Router ID as Loopback Address check box.
k) Expand Loopback Addresses, and enter the IP address in the IP field. Click Update, and click OK. Click
OK.
Enter the desired IPv4 or IPv6 IP address.
Step 6
Step 7
In the Create Node Profile dialog box, in the OSPF Interface Profiles area, click the + icon.
In the Create Interface Profile dialog box, perform the following tasks:
a) In the Name field, enter the name of the profile (portProf).
b) In the Interfaces area, click the Routed Interfaces tab, and click the + icon.
c) In the Select Routed Interfaces dialog box, in the Path field, from the drop-down list, choose the first
port (leaf1, port 1/40).
d) In the IP Address field, enter an IP address and mask. Click OK.
e) In the Interfaces area, click the Routed Interfaces tab, and click the + icon.
f) In the Select Routed Interfaces dialog box, in the Path field, from the drop-down list, choose the second
port (leaf2, port 1/40).
g) In the IP Address field, enter an IP address and mask. Click OK.
Note
This IP address should be different from the IP address you entered for leaf1 earlier.
h) In the Create Interface Profile dialog box, click OK.
Step 8
The interfaces are configured along with the OSPF interface.
In the Create Node Profile dialog box, click OK.
Step 9
In the Create Routed Outside dialog box, click Next.
The Step 2 External EPG Networks area is displayed.
Step 10 In the External EPG Networks area, click the + icon.
Step 11 In the Create External Network dialog box, perform the following actions:
a) In the Name field, enter a name for the external network (extMgmt).
b) Expand Subnet and in the Create Subnet dialog box, in the IP address field, enter an IP address and
mask for the subnet.
c) In the Scope field, check the desired check boxes. Click OK.
d) In the Create External Network dialog box, click OK.
e) In the Create Routed Outside dialog box, click Finish.
Cisco APIC Basic Configuration Guide, Release 2.x
116
Basic User Tenant Configuration
Configuring Route Reflectors
Note
In the Work pane, in the External Routed Networks area, the external routed network icon
(RtdOut) is now displayed.
Creating an OSPF External Routed Network for a Tenant Using the NX-OS CLI
Configuring external routed network connectivity involves the following steps:
1 Create a VRF under Tenant.
2 Configure L3 networking configuration for the VRF on the border leaf switches, which are connected to
the external routed network. This configuration includes interfaces, routing protocols (BGP, OSPF, EIGRP),
protocol parameters, route-maps.
3 Configure policies by creating external-L3 EPGs under tenant and deploy these EPGs on the border leaf
switches. External routed subnets on a VRF which share the same policy within the ACI fabric form one
"External L3 EPG" or one "prefix EPG".
Configuration is realized in two modes:
• Tenant mode: VRF creation and external-L3 EPG configuration
• Leaf mode: L3 networking configuration and external-L3 EPG deployment
The following steps are for creating an OSPF external routed network for a tenant. To create an OSPF external
routed network for a tenant, you must choose a tenant and then create a VRF for the tenant.
Note
The examples in this section show how to provide external routed connectivity to the "web" epg in the
"OnlineStore" application for tenant "exampleCorp".
Procedure
Step 1
Configure the VLAN domain.
Example:
apic1(config)# vlan-domain dom_exampleCorp
apic1(config-vlan)# vlan 5-1000
apic1(config-vlan)# exit
Step 2
Configure the tenant VRF and enable policy enforcement on the VRF.
Example:
apic1(config)# tenant exampleCorp
apic1(config-tenant)# vrf context
exampleCorp_v1
apic1(config-tenant-vrf)# contract enforce
apic1(config-tenant-vrf)# exit
Step 3
Configure the tenant BD and mark the gateway IP as “public”. The entry "scope public" makes this gateway
address available for advertisement through the routing protocol for external-L3 network.
Cisco APIC Basic Configuration Guide, Release 2.x
117
Basic User Tenant Configuration
Configuring Route Reflectors
Example:
apic1(config-tenant)# bridge-domain exampleCorp_b1
apic1(config-tenant-bd)# vrf member exampleCorp_v1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# interface bridge-domain exampleCorp_b1
apic1(config-tenant-interface)# ip address 172.1.1.1/24 scope public
apic1(config-tenant-interface)# exit
Step 4
Configure the VRF on a leaf.
Example:
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf exampleCorp_v1
Step 5
Configure the OSPF area and add the route map.
Example:
apic1(config-leaf)# router ospf default
apic1(config-leaf-ospf)# vrf member tenant exampleCorp vrf exampleCorp_v1
apic1(config-leaf-ospf-vrf)# area 0.0.0.1 route-map map100 out
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit
Step 6
Assign the VRF to the interface (sub-interface in this example) and enable the OSPF area.
Example:
Note
For the sub-interface configuration, the main interface (ethernet 1/11 in this example) must be
converted to an L3 port through “no switchport” and assigned a vlan-domain (dom_exampleCorp in
this example) that contains the encapsulation VLAN used by the sub-interface. In the sub-interface
ethernet1/11.500, 500 is the encapsulation VLAN.
apic1(config-leaf)# interface ethernet 1/11
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vlan-domain member dom_exampleCorp
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 1/11.500
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf exampleCorp_v1
apic1(config-leaf-if)# ip address 157.10.1.1/24
apic1(config-leaf-if)# ip router ospf default area 0.0.0.1
Step 7
Configure the external-L3 EPG policy. This includes the subnet to match for identifying the external subnet
and consuming the contract to connect with the epg "web".
Example:
apic1(config)# tenant t100
apic1(config-tenant)# external-l3 epg l3epg100
apic1(config-tenant-l3ext-epg)# vrf member v100
apic1(config-tenant-l3ext-epg)# match ip 145.10.1.0/24
apic1(config-tenant-l3ext-epg)# contract consumer web
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)#exit
Step 8
Deploy the external-L3 EPG on the leaf switch.
Example:
apic1(config)# leaf 101
Cisco APIC Basic Configuration Guide, Release 2.x
118
Basic User Tenant Configuration
Creating Tenants, VRF, and Bridge Domains
apic1(config-leaf)# vrf context tenant t100 vrf v100
apic1(config-leaf-vrf)# external-l3 epg l3epg100
Creating Tenants, VRF, and Bridge Domains
Tenants Overview
• A tenant contains policies that enable qualified users domain-based access control. Qualified users can
access privileges such as tenant administration and networking administration.
• A user requires read/write privileges for accessing and configuring policies in a domain. A tenant user
can have specific privileges into one or more domains.
• In a multitenancy environment, a tenant provides group user access privileges so that resources are
isolated from one another (such as for endpoint groups and networking). These privileges also enable
different users to manage different tenants.
Tenant Creation
A tenant contains primary elements such as filters, contracts, bridge domains, and application profiles that
you can create after you first create a tenant.
VRF and Bridge Domains
You can create and specify a VRF and a bridge domain for the tenant. The defined bridge domain element
subnets reference a corresponding Layer 3 context.
For details about enabling IPv6 Neighbor Discovery seeIPv6 and Neighbor Discovery in Cisco APIC Layer
3 Networking Guide.
Creating a Tenant, VRF, and Bridge Domain Using the Advanced GUI
If you have a public subnet when you configure the routed outside, you must associate the bridge domain
with the outside configuration.
Procedure
Step 1
Step 2
On the menu bar, click TENANT > Add Tenant.
In the Create Tenant dialog box, perform the following tasks:
a) In the Name field, enter a name.
b) Click the Security Domains + icon to open the Create Security Domain dialog box.
c) In the Name field, enter a name for the security domain. Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
119
Basic User Tenant Configuration
Deploying an Application Policy
d) In the Create Tenant dialog box, check the check box for the security domain that you created, and click
Submit.
Step 3
In the Navigation pane, expand Tenant-name > Networking, and in the Work pane, drag the VRF icon to
the canvas to open the Create VRF dialog box, and perform the following tasks:
a) In the Name field, enter a name.
b) Click Submit to complete the VRF configuration.
Step 4
In the Networking pane, drag the BD icon to the canvas while connecting it to the VRF icon. In the Create
Bridge Domain dialog box that displays, perform the following tasks:
a) In the Name field, enter a name.
b) Click the L3 Configurations tab.
c) Expand Subnets to open the Create Subnet dialog box, enter the subnet mask in the Gateway IP field
and click OK.
d) Click Submit to complete bridge domain configuration.
Step 5
In the Networks pane, drag the L3 icon down to the canvas while connecting it to the VRF icon. In the Create
Routed Outside dialog box that displays, perform the following tasks:
a) In the Name field, enter a name.
b) Expand Nodes And Interfaces Protocol Profiles to open the Create Node Profile dialog box.
c) In the Name field, enter a name.
d) Expand Nodes to open the Select Node dialog box.
e) In the Node ID field, choose a node from the drop-down list.
f) In the Router ID field, enter the router ID.
g) Expand Static Routes to open the Create Static Route dialog box.
h) In the Prefix field, enter the IPv4 or IPv6 address.
i) Expand Next Hop Addresses and in the Next Hop IP field, enter the IPv4 or IPv6 address.
j) In the Preference field, enter a number, then click UPDATE and then OK.
k) In the Select Node dialog box, click OK.
l) In the Create Node Profile dialog box, click OK.
m) Check the BGP, OSPF, or EIGRP check boxes if desired, and click NEXT. Click OK to complete the
Layer 3 configuration.
To confirm L3 configuration, in the Navigation pane, expand Networking > VRFs.
Deploying an Application Policy
Security Policy Enforcement
As traffic enters the leaf switch from the front panel interfaces, the packets are marked with the EPG of the
source EPG. The leaf switch then performs a forwarding lookup on the packet destination IP address within
the tenant space. A hit can result in any of the following scenarios:
1 A unicast (/32) hit provides the EPG of the destination endpoint and either the local interface or the remote
leaf switch VTEP IP address where the destination endpoint is present.
Cisco APIC Basic Configuration Guide, Release 2.x
120
Basic User Tenant Configuration
Contracts Contain Security Policy Specifications
2 A unicast hit of a subnet prefix (not /32) provides the EPG of the destination subnet prefix and either the
local interface or the remote leaf switch VTEP IP address where the destination subnet prefix is present.
3 A multicast hit provides the local interfaces of local receivers and the outer destination IP address to use
in the VXLAN encapsulation across the fabric and the EPG of the multicast group.
Note
Multicast and external router subnets always result in a hit on the ingress leaf switch. Security policy
enforcement occurs as soon as the destination EPG is known by the ingress leaf switch.
A miss result in the forwarding table causes the packet to be sent to the forwarding proxy in the spine switch.
The forwarding proxy then performs a forwarding table lookup. If it is a miss, the packet is dropped. If it is
a hit, the packet is sent to the egress leaf switch that contains the destination endpoint. Because the egress leaf
switch knows the EPG of the destination, it performs the security policy enforcement. The egress leaf switch
must also know the EPG of the packet source. The fabric header enables this process because it carries the
EPG from the ingress leaf switch to the egress leaf switch. The spine switch preserves the original EPG in
the packet when it performs the forwarding proxy function.
On the egress leaf switch, the source IP address, source VTEP, and source EPG information are stored in the
local forwarding table through learning. Because most flows are bidirectional, a return packet populates the
forwarding table on both sides of the flow, which enables the traffic to be ingress filtered in both directions.
Contracts Contain Security Policy Specifications
In the ACI security model, contracts contain the policies that govern the communication between EPGs. The
contract specifies what can be communicated and the EPGs specify the source and destination of the
communications. Contracts link EPGs, as shown below.
EPG 1 --------------- CONTRACT --------------- EPG 2
Endpoints in EPG 1 can communicate with endpoints in EPG 2 and vice versa if the contract allows it. This
policy construct is very flexible. There can be many contracts between EPG 1 and EPG 2, there can be more
than two EPGs that use a contract, and contracts can be reused across multiple sets of EPGs, and more.
There is also directionality in the relationship between EPGs and contracts. EPGs can either provide or consume
a contract. An EPG that provides a contract is typically a set of endpoints that provide a service to a set of
client devices. The protocols used by that service are defined in the contract. An EPG that consumes a contract
is typically a set of endpoints that are clients of that service. When the client endpoint (consumer) tries to
connect to a server endpoint (provider), the contract checks to see if that connection is allowed. Unless
otherwise specified, that contract would not allow a server to initiate a connection to a client. However, another
contract between the EPGs could easily allow a connection in that direction.
This providing/consuming relationship is typically shown graphically with arrows between the EPGs and the
contract. Note the direction of the arrows shown below.
EPG 1 <-------consumes-------- CONTRACT <-------provides-------- EPG 2
Cisco APIC Basic Configuration Guide, Release 2.x
121
Basic User Tenant Configuration
Contracts Contain Security Policy Specifications
The contract is constructed in a hierarchical manner. It consists of one or more subjects, each subject contains
one or more filters, and each filter can define one or more protocols.
Figure 6: Contract Filters
Cisco APIC Basic Configuration Guide, Release 2.x
122
Basic User Tenant Configuration
Contracts Contain Security Policy Specifications
The following figure shows how contracts govern EPG communications.
Figure 7: Contracts Determine EPG to EPG Communications
For example, you may define a filter called HTTP that specifies TCP port 80 and port 8080 and another filter
called HTTPS that specifies TCP port 443. You might then create a contract called webCtrct that has two sets
of subjects. openProv and openCons are the subjects that contain the HTTP filter. secureProv and secureCons
are the subjects that contain the HTTPS filter. This webCtrct contract can be used to allow both secure and
non-secure web traffic between EPGs that provide the web service and EPGs that contain endpoints that want
to consume that service.
These same constructs also apply for policies that govern virtual machine hypervisors. When an EPG is placed
in a virtual machine manager (VMM) domain, the APIC downloads all of the policies that are associated with
the EPG to the leaf switches with interfaces connecting to the VMM domain. For a full explanation of VMM
domains, see the Virtual Machine Manager Domains chapter of Application Centric Infrastructure
Fundamentals. When this policy is created, the APIC pushes it (pre-populates it) to a VMM domain that
specifies which switches allow connectivity for the endpoints in the EPGs. The VMM domain defines the set
of switches and ports that allow endpoints in an EPG to connect to. When an endpoint comes on-line, it is
associated with the appropriate EPGs. When it sends a packet, the source EPG and destination EPG are derived
from the packet and the policy defined by the corresponding contract is checked to see if the packet is allowed.
If yes, the packet is forwarded. If no, the packet is dropped.
Contracts consist of 1 or more subjects. Each subject contains 1 or more filters. Each filter contains 1 or more
entries. Each entry is equivalent to a line in an Access Control List (ACL) that is applied on the Leaf switch
to which the endpoint within the endpoint group is attached.
In detail, contracts are comprised of the following items:
• Name—All contracts that are consumed by a tenant must have different names (including contracts
created under the common tenant or the tenant itself).
• Subjects—A group of filters for a specific application or service.
Cisco APIC Basic Configuration Guide, Release 2.x
123
Basic User Tenant Configuration
Three-Tier Application Deployment
• Filters—Used to classify traffic based upon layer 2 to layer 4 attributes (such as Ethernet type, protocol
type, TCP flags and ports).
• Actions—Action to be taken on the filtered traffic. The following actions are supported:
◦Permit the traffic (regular contracts, only)
◦Mark the traffic (DSCP/CoS) (regular contracts, only)
◦Redirect the traffic (regular contracts, only, through a service graph)
◦Copy the traffic (regular contracts, only, through a service graph or SPAN)
◦Block the traffic (taboo contracts, only)
◦Log the traffic (taboo contracts, only)
• Aliases—(Optional) A changeable name for an object. Although the name of an object, once created,
cannot be changed, the Alias is a property that can be changed.
Thus, the contract allows more complex actions than just allow or deny. The contract can specify that traffic
that matches a given subject can be re-directed to a service, can be copied, or can have its QoS level modified.
With pre-population of the access policy in the concrete model, endpoints can move, new ones can come
on-line, and communication can occur even if the APIC is off-line or otherwise inaccessible. The APIC is
removed from being a single point of failure for the network. Upon packet ingress to the ACI fabric, security
policies are enforced by the concrete model running in the switch.
Three-Tier Application Deployment
A filter specifies the data protocols to be allowed or denied by a contract that contains the filter. A contract
can contain multiple subjects. A subject can be used to realize uni- or bidirectional filters. A unidirectional
filter is a filter that is used in one direction, either from consumer-to-provider (IN) or from provider-to-consumer
(OUT) filter. A bidirectional filter is the same filter that is used in both directions. It is not reflexive.
Contracts are policies that enable inter-End Point Group (inter-EPG) communication. These policies are the
rules that specify communication between application tiers. If no contract is attached to the EPG, inter-EPG
communication is disabled by default. No contract is required for intra-EPG communication because intra-EPG
communication is always allowed.
Application profiles enable you to model application requirements that the APIC then automatically renders
in the network and data center infrastructure. The application profiles enable administrators to approach the
resource pool in terms of applications rather than infrastructure building blocks. The application profile is a
container that holds EPGs that are logically related to one another. EPGs can communicate with other EPGs
in the same application profile and with EPGs in other application profiles.
To deploy an application policy, you must create the required application profiles, filters, and contracts.
Typically, the APIC fabric hosts a three-tier application within a tenant network. In this example, the application
is implemented by using three servers (a web server, an application server, and a database server). See the
following figure for an example of a three-tier application.
The web server has the HTTP filter, the application server has the Remote Method Invocation (RMI) filter,
and the database server has the Structured Query Language (SQL) filter. The application server consumes the
SQL contract to communicate with the database server. The web server consumes the RMI contract to
communicate with the application server. The traffic enters from the web server and communicates with the
Cisco APIC Basic Configuration Guide, Release 2.x
124
Basic User Tenant Configuration
Parameters to Create a Filter for http
application server. The application server then communicates with the database server, and the traffic can
also communicate externally.
Figure 8: Three-Tier Application Diagram
Parameters to Create a Filter for http
The parameters to create a filter for http in this example is as follows:
Parameter Name
Filter for http
Name
http
Number of Entries
2
Entry Name
Dport-80
Dport-443
Ethertype
IP
Protocol
tcp
tcp
Destination Port
http
https
Parameters to Create Filters for rmi and sql
The parameters to create filters for rmi and sql in this example are as follows:
Parameter Name
Filter for rmi
Filter for sql
Name
rmi
sql
Cisco APIC Basic Configuration Guide, Release 2.x
125
Basic User Tenant Configuration
Example Application Profile Database
Parameter Name
Filter for rmi
Filter for sql
Number of Entries
1
1
Entry Name
Dport-1099
Dport-1521
Ethertype
IP
IP
Protocol
tcp
tcp
Destination Port
1099
1521
Example Application Profile Database
The application profile database in this example is as follows:
EPG
Provided Contracts
Consumed Contracts
web
web
rmi
app
rmi
sql
db
sql
--
Deploying an Application Profile Using the GUI
Creating a Filter Using the GUI
Create three separate filters. In this example they are HTTP, RMI, SQL. This task shows how to create the
HTTP filter. The task is identical for creating the other filters.
Before You Begin
Verify that the tenant, network, and bridge domain have been created.
Procedure
Step 1
On the menu bar, choose TENANTS. In the Navigation pane, expand the tenant > Security Policies,
right-click Filters, and click Create Filter.
Note
In the Navigation pane, you expand the tenant where you want to add filters.
Step 2
In the Create Filter dialog box, perform the following actions:
a) In the Name field, enter the filter name (http).
b) Expand Entries, and in the Name field, enter the name (Dport-80).
c) From the EtherType drop-down list, choose the EtherType (IP).
Cisco APIC Basic Configuration Guide, Release 2.x
126
Basic User Tenant Configuration
Deploying an Application Profile Using the GUI
d) From the IP Protocol drop-down list, choose the protocol (tcp).
e) From the Destination Port/Range drop-down lists, choose http in the From and To fields. (http)
f) Click Update, and click Submit.
The newly added filter appears in the Navigation pane and in the Work pane.
Step 3
Step 4
Expand Entries in the Name field. Follow the same process to add another entry with HTTPS as the
Destination port, and click Update.
This new filter rule is added.
Follow the same process in the earlier steps to create two more filters (rmi and sql) and use the parameters
provided in Parameters to Create Filters for rmi and sql, on page 125.
Creating a Contract Using the GUI
Procedure
Step 1
Step 2
Step 3
On the menu bar, choose TENANTS and the tenant name on which you want to operate. In the Navigation
pane, expand the tenant > Security Policies.
Right-click Contracts > Create Contract.
In the Create Contract dialog box, perform the following tasks:
a)
b)
c)
d)
In the Name field, enter the contract name (web).
Click the + sign next to Subjects to add a new subject.
In the Create Contract Subject dialog box, enter a subject name in the Name field. (web)
Note
This step associates the filters created that were earlier with the contract subject.
In the Filter Chain area, click the + sign next to Filters.
e) In the dialog box, from the drop-down menu, choose the filter name (http), and click Update.
Step 4
In the Create Contract Subject dialog box, click OK.
Step 5
Create two more contracts for rmi and for sql following the same steps in this procedure. For the rmi contract,
choose the rmi subject and for sql, choose the sql subject.
Creating an Application Profile Using the GUI
Procedure
Step 1
On the menu bar, choose TENANTS. In the Navigation pane, expand the tenant, right-click Application
Profiles, and click Create Application Profile.
Step 2
In the Create Application Profile dialog box, in the Name field, add the application profile name (OnlineStore).
Cisco APIC Basic Configuration Guide, Release 2.x
127
Basic User Tenant Configuration
Deploying an Application Profile Using the GUI
Creating EPGs Using the GUI
The port the EPG uses must belong to one of the VM Managers (VMM) or physical domains associated with
the EPG.
Procedure
Step 1
Step 2
Step 3
On the menu bar, choose Tenants and the tenant where you want to create an EPG.
In the navigation pane, expand the folder for the tenant, the Application Profiles folder, and the folder for
the application profile.
Right-click the Application EPG folder, and in the Create Application EPG dialog box, perform the following
actions:
a) In the Name field, add the EPG name (db).
b) In the Bridge Domain field, choose the bridge domain from the drop-down list (bd1).
c) Check the Associate to VM Domain Profiles check box. Click Next.
d) In the Step 2 for Specify the VM Domains area, expand Associate VM Domain Profiles and from the
drop-down list, choose the desired VMM domain.
e) (Optional) In the Delimiter field, enter one of the following symbols: |, ~, !, @, ^, +, or =.
If you do not enter a symbol, the system will use the default | delimiter in the VMware portgroup name.
f) If you have Cisco AVS, from the Encap Mode drop-down list, choose an encapsulation mode.
You can choose one of the following encap modes:
• VXLAN—This overrides the domain's VLAN configuration, and the EPG will use VXLAN
encapsulation. However, a fault will be triggered for the EPG if a multicast pool is not configured
on the domain.
• VLAN—This overrides the domain's VXLAN configuration, and the EPG will use VLAN
encapsulation. However, a fault will be triggered for the EPG if a VLAN pool is not configured on
the domain.
• Auto—This causes the EPG to use the same encapsulation mode as the VMM domain. This is the
default configuration.
g) Click Update and then click FINISH.
Step 4
In the Create Application Profile dialog box, create two more EPGs. The three EPGs should be db, app, and
web in the same bridge domain and data center.
Consuming and Providing Contracts Using the GUI
You can associate contracts that were created earlier to create policy relationships between the EPGs.
When you name the provided and consumed contracts, verify that you give the same name for both provided
and consumed contracts.
Cisco APIC Basic Configuration Guide, Release 2.x
128
Basic User Tenant Configuration
Statically Deploying an EPG on a Specific Port
Procedure
Step 1
Note
Step 2
In the Name field, from the drop-down list, choose sql contract. Click OK.
This step enables the db EPG to provide the sql contract and the app EPG to consume the sql contract.
Click and drag across the APIC GUI screen from the app ePG to the web EPG.
The Add Consumed Contract dialog box is displayed.
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
The db, app, and web EPGs are displayed as
icons.
Click and drag across the APIC GUI window from the db EPG to the app EPG.
The Add Consumed Contract dialog box is displayed.
In the Name field, from the drop-down list, choose rmi contract. Click OK.
This step enables the app EPG to provide the rmi contract and the web EPG to consume the rmi contract.
Click the web EPG icon, and click the + sign in the Provided Contracts area.
The Add Provided Contract dialog box is displayed.
In the Name field, from the drop-down list, choose web contract. Click OK. Click Submit.
You have created a three-tier application profile called OnlineStore.
To verify, in the Navigation pane, navigate to and click OnlineStore under Application Profiles.
In the Work pane, you can see the three EPGs app, db, and web are displayed.
In the Work pane, choose Operational > Contracts.
You can see the EPGs and contracts displayed in the order that they are consumed and provided.
Statically Deploying an EPG on a Specific Port
This topic provides a typical example of how to statically deploy an EPG on a specific port when using Cisco
APIC.
Deploying an EPG on a Specific Port with APIC Using the GUI
Before You Begin
The tenant where you deploy the EPG is already created.
Procedure
Step 1
On the menubar, click TENANTS.
Step 2
In the Navigation pane, expand the appropriate Tenant_name > Application Profiles.
Step 3
Step 4
Right-click Application Profiles and click Create Application Profile.
In the Create Application Profile dialog box, perform the following actions:
a) In the Name field, enter a name for the application profile.
b) Expand EPGs.
c) In the Create Application EPG dialog box, in the Name field, enter an EPG name.
Cisco APIC Basic Configuration Guide, Release 2.x
129
Basic User Tenant Configuration
Deploying an EPG on a Specific Port with APIC Using the NX-OS Style CLI
d) In the Statically Link with Leaves/Paths field, check the checkbox for Statically Link with Leaves/Paths.
(this is selected to specify on which port the EPG is required to be deployed). Click Next.
e) In the Leaves/Paths area, expand Paths.
In this example we are deploying the EPG on the port of a node. Alternatively, you could choose to deploy
the EPG on a node.
f)
g)
h)
i)
j)
k)
From the Path drop-down list, choose the appropriate node and port.
In the Deployment Immediacy field drop-down list, choose the preferred deployment time.
In the Mode field, choose the appropriate mode.
In the Port Encap field, enter the secondary VLAN to be deployed.
In the Primary Encap field, enter the primary VLAN to be deployed.
Click Update, and click Finish.
Step 5
In the Navigation pane, expand Application Profiles to view the new application profile.
Step 6
Step 7
Expand Application EPGs, to view the new EPG.
Expand the EPG and click Static Bindings (Paths), and in the Properties pane, view the details of the static
binding paths that are established.
Deploying an EPG on a Specific Port with APIC Using the NX-OS Style CLI
Procedure
Step 1
Configure a VLAN domain:
Example:
apic1(config)# vlan-domain dom1
apic1(config-vlan)# vlan 10-100
Step 2
Create a tenant:
Example:
apic1# configure
apic1(config)# tenant t1
Step 3
Create a private network/VRF:
Example:
apic1(config-tenant)# vrf context ctx1
apic1(config-tenant-vrf)# exit
Step 4
Create a bridge domain:
Example:
apic1(config-tenant)# bridge-domain bd1
apic1(config-tenant-bd)# vrf member ctx1
apic1(config-tenant-bd)# exit
Cisco APIC Basic Configuration Guide, Release 2.x
130
Basic User Tenant Configuration
Deploying an EPG on a Specific Port with APIC Using the REST API
Step 5
Create an application profile and an application EPG:
Example:
apic1(config-tenant)# application AP1
apic1(config-tenant-app)# epg EPG1
apic1(config-tenant-app-epg)# bridge-domain member bd1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 6
Associate the EPG with a specific port:
Example:
apic1(config)# leaf 1017
apic1(config-leaf)# interface ethernet 1/13
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# switchport trunk allowed vlan 20 tenant t1 application AP1 epg EPG1
Note
The vlan-domain and vlan-domain member commands mentioned in the above example are a
pre-requisite for deploying an EPG on a port.
Deploying an EPG on a Specific Port with APIC Using the REST API
Before You Begin
The tenant where you deploy the EPG is created.
Procedure
Deploy an EPG on a specific port.
Example:
<fvTenant name="<tenant_name>" dn="uni/tn-test1" >
<fvCtx name="<network_name>" pcEnfPref="enforced" knwMcastAct="permit"/>
<fvBD name="<bridge_domain_name>" unkMcastAct="flood" >
<fvRsCtx tnFvCtxName="<network_name>"/>
</fvBD>
<fvAp name="<application_profile>" >
<fvAEPg name="<epg_name>" >
<fvRsPathAtt tDn="topology/pod-1/paths-1017/pathep-[eth1/13]" mode="regular"
instrImedcy="immediate" encap="vlan-20"/>
</fvAEPg>
</fvAp>
</fvTenant>
Creating Domains, Attach Entity Profiles, and VLANs to Deploy
an EPG on a Specific Port
This topic provides a typical example of how to create physical domains, Attach Entity Profiles (AEP), and
VLANs that are mandatory to deploy an EPG on a specific port.
Cisco APIC Basic Configuration Guide, Release 2.x
131
Basic User Tenant Configuration
Creating Domains, and VLANS to Deploy an EPG on a Specific Port Using the GUI
Note
All endpoint groups (EPGs) require a domain. Interface policy groups must also be associated with Attach
Entity Profile (AEP), and the AEP must be associated with a domain, if the AEP and EPG have to be in
same domain. Based on the association of EPGs to domains and of interface policy groups to domains,
the ports and VLANs that the EPG uses are validated. The following domain types associate with EPGs:
• Application EPGs
• Layer 3 external outside network instance EPGs
• Layer 2 external outside network instance EPGs
• Management EPGs for out-of-band and in-band access
The APIC checks if an EPG is associated with one or more of these types of domains. If the EPG is not
associated, the system accepts the configuration but raises a fault. The deployed configuration may not
function properly if the domain association is not valid. For example, if the VLAN encapsulation is not
valid for use with the EPG, the deployed configuration may not function properly.
Creating Domains, and VLANS to Deploy an EPG on a Specific Port Using the
GUI
Before You Begin
• The tenant where you deploy the EPG is already created.
• An EPG is statically deployed on a specific port.
Procedure
Step 1
Step 2
On the menu bar, click FABRIC > Access Policies.
In the Navigation pane, click Quick Start.
Step 3
In the Work pane, click Configure an interface, PC, and vPC.
Step 4
In the Configure Interface, PC, and vPC dialog box, click the + icon to select switches and perform the
following actions:
a) From the Switches drop-down list, check the check box for the desired switch.
b) In the Switch Profile Name field, a switch name is automatically populated.
Note
Optionally, you can enter a modified
name.
c) Click the + icon to configure the switch interfaces.
d) In the Interface Type field, click the Individual radio button.
e) In the Interfaces field, enter the range of desired interfaces.
f) In the Interface Selector Name field, an interface name is automatically populated.
Note
Optionally, you can enter a modified
name.
g) In the Interface Policy Group field, choose the Create One radio button.
Cisco APIC Basic Configuration Guide, Release 2.x
132
Basic User Tenant Configuration
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using the NX-OS Style CLI
h) From the Link Level Policy drop-down list, choose the appropriate link level policy.
Note
Create additional policies as desired, otherwise the default policy settings are available.
i)
j)
k)
l)
m)
n)
Step 5
From the Attached Device Type field, choose the appropriate device type.
In the Domain field, click the Create One radio button.
In the Domain Name field, enter a domain name.
In the VLAN field, click the Create One radio button.
In the VLAN Range field, enter the desired VLAN range. Click Save, and click Save again.
Click Submit.
On the menu bar, click TENANTS. In the Navigation pane, expand the appropriate Tenant_name >
Application Profiles > Domains (VMs and Bare-Metals) > EPG_name and perform the following actions:
a) Right-click Domains (VMs and Bare-Metals), and click Add Physical Domain Association.
b) In the Add Physical Domain Association dialog box, from the Physical Domain Profile drop-down list,
choose the appropriate domain.
c) In the Deploy Immediacy field, click the desired radio button.
d) In the Resolution Immediacy field, click the desired radio button. Click Submit.
The AEP is associated with a specific port on a node and with a domain. The physical domain is associated
with the VLAN pool and the Tenant is associated with this physical domain.
The switch profile and the interface profile are created. The policy group is created in the port block under
the interface profile. The AEP is automatically created, and it is associated with the port block and with the
domain. The domain is associated with the VLAN pool and the Tenant is associated with the domain.
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using
the NX-OS Style CLI
Before You Begin
• The tenant where you deploy the EPG is already created.
• An EPG is statically deployed on a specific port.
Procedure
Step 1
Create a VLAN domain and assign VLAN ranges:
Example:
apic1(config)# vlan-domain domP
apic1(config-vlan)# vlan 10
apic1(config-vlan)# vlan 25
apic1(config-vlan)# vlan 50-60
apic1(config-vlan)# exit
Step 2
Create an interface policy group and assign a VLAN domain to the policy group:
Cisco APIC Basic Configuration Guide, Release 2.x
133
Basic User Tenant Configuration
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using the REST API
Example:
apic1(config)# template policy-group PortGroup
apic1(config-pol-grp-if)# vlan-domain member domP
Step 3
Create a leaf interface profile, assign an interface policy group to the profile, and assign the interface IDs on
which the profile will be applied:
Example:
apic1(config)# leaf-interface-profile InterfaceProfile1
apic1(config-leaf-if-profile)# leaf-interface-group range
apic1(config-leaf-if-group)# policy-group PortGroup
apic1(config-leaf-if-group)# interface ethernet 1/11-13
apic1(config-leaf-if-profile)# exit
Step 4
Create a leaf profile, assign the leaf interface profile to the leaf profile, and assign the leaf IDs on which the
profile will be applied:
Example:
apic1(config)# leaf-profile SwitchProfile-1019
apic1(config-leaf-profile)# leaf-interface-profile InterfaceProfile1
apic1(config-leaf-profile)# leaf-group range
apic1(config-leaf-group)# leaf 1019
apic1(config-leaf-group)#
Creating AEP, Domains, and VLANs to Deploy an EPG on a Specific Port Using
the REST API
Before You Begin
• The tenant where you deploy the EPG is already created.
• An EPG is statically deployed on a specific port.
Procedure
Step 1
Create the interface profile, switch profile and the Attach Entity Profile (AEP).
Example:
<infraInfra>
<infraNodeP
name="<switch_profile_name>" dn="uni/infra/nprof-<switch_profile_name>"
>
<infraLeafS name="SwitchSeletor" descr="" type="range">
<infraNodeBlk name="nodeBlk1" descr="" to_="1019" from_="1019"/>
</infraLeafS>
<infraRsAccPortP tDn="uni/infra/accportprof-<interface_profile_name>"/>
</infraNodeP>
<infraAccPortP name="<interface_profile_name>"
dn="uni/infra/accportprof-<interface_profile_name>" >
<infraHPortS name="portSelector" type="range">
Cisco APIC Basic Configuration Guide, Release 2.x
134
Basic User Tenant Configuration
Deploying an Application EPG through an AEP or Interface Policy Group to Multiple Ports
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accportgrp-<port_group_name>"
fexId="101"/>
<infraPortBlk name="block2"
fromCard="1"/>
</infraHPortS>
</infraAccPortP>
toPort="13" toCard="1" fromPort="11"
<infraAccPortGrp name="<port_group_name>"
dn="uni/infra/funcprof/accportgrp-<port_group_name>" >
<infraRsAttEntP tDn="uni/infra/attentp-<attach_entity_profile_name>"/>
<infraRsHIfPol tnFabricHIfPolName="1GHifPol"/>
</infraAccPortGrp>
<infraAttEntityP name="<attach_entity_profile_name>"
dn="uni/infra/attentp-<attach_entity_profile_name>" >
<infraRsDomP tDn="uni/phys-<physical_domain_name>"/>
</infraAttEntityP>
<infraInfra>
Step 2
Create a domain.
Example:
<physDomP name="<physical_domain_name>" dn="uni/phys-<physical_domain_name>">
<infraRsVlanNs tDn="uni/infra/vlanns-[<vlan_pool_name>]-static"/>
</physDomP>
Step 3
Create a VLAN range.
Example:
<fvnsVlanInstP name="<vlan_pool_name>" dn="uni/infra/vlanns-[<vlan_pool_name>]-static"
allocMode="static">
<fvnsEncapBlk name="" descr="" to="vlan-25" from="vlan-10"/>
</fvnsVlanInstP>
Step 4
Associate the EPG with the domain.
Example:
<fvTenant name="<tenant_name>" dn="uni/tn-" >
<fvAEPg prio="unspecified" name="<epg_name>" matchT="AtleastOne"
dn="uni/tn-test1/ap-AP1/epg-<epg_name>" descr="">
<fvRsDomAtt tDn="uni/phys-<physical_domain_name>" instrImedcy="immediate"
resImedcy="immediate"/>
</fvAEPg>
</fvTenant>
Deploying an Application EPG through an AEP or Interface
Policy Group to Multiple Ports
Through the APIC Advanced GUI and REST API, you can associate attached entity profiles directly with
application EPGs. By doing so, you deploy the associated application EPGs to all those ports associated with
the attached entity profile in a single configuration.
Through the APIC REST API or the NX-OS style CLI, you can deploy an application EPG to multiple ports
through an Interface Policy Group.
Cisco APIC Basic Configuration Guide, Release 2.x
135
Basic User Tenant Configuration
Deploying an EPG through an AEP to Multiple Interfaces Using the APIC Advanced GUI
Deploying an EPG through an AEP to Multiple Interfaces Using the APIC
Advanced GUI
You can quickly associate an application with an attached entity profile to quickly deploy that EPG over all
the ports associated with that attached entity profile.
Before You Begin
• The target application EPG is created.
• The VLAN pools has been created containing the range of VLANs you wish to use for EPG Deployment
on the AEP.
• The physical domain has been created and linked to the VLAN Pool and AEP.
• The target attached entity profile is created and is associated with the ports on which you want to deploy
the application EPG.
Procedure
Step 1
Navigate to the target attached entity profile.
a) Open the page for the attached entity profile to use. In the Advanced GUI, click Fabric > Access Policies
> Global Policies > Attachable Access Entity Profiles.
b) Click the target attached entity profile to open its Attachable Access Entity Profile window.
Step 2
Click the Show Usage button to view the leaf switches and interfaces associated with this attached entity
profile.
the application EPGs associated with this attached entity profile are deployed to all the ports on all the switches
associated with this attached entity profile.
Step 3
Use the Application EPGs table to associate the target application EPG with this attached entity profile. Click
+ to add an application EPG entry. Each entry contains the following fields:
Field
Action
Application EPGs
Use the drop down to choose the associated Tenant, Application Profile, and target
application EPG.
Encap
Enter the name of the VLAN over which the target application EPG will
communicate.
Primary Encap
If the application EPG requires a primary VLAN, enter the name of the primary
VLAN.
Cisco APIC Basic Configuration Guide, Release 2.x
136
Basic User Tenant Configuration
Deploying an EPG through an Interface Policy Group to Multiple Interfaces Using the NX-OS Style CLI
Field
Action
Mode
Use the drop down to specify the mode in which data is transmitted:
• Trunk -- Choose if traffic from the host is tagged with a VLAN ID.
• Access -- Choose if traffic from the host is tagged with an 802.1p tag.
• Access Untagged -- Choose if the traffic from the host is untagged.
Step 4
Click Submit.
the application EPGs associated with this attached entity profile are deployed to all the ports on all the switches
associated with this attached entity profile.
Deploying an EPG through an Interface Policy Group to Multiple Interfaces
Using the NX-OS Style CLI
In the NX-OS CLI, an attached entity profile is not explicitly defined to associate with an EPG for rapid
deployment; instead the interface policy group is defined, assigned a domain, applied to all the ports associated
with a VLAN and configured to include the application EPG to be deployed over that VLAN.
Before You Begin
• The target application EPG is created.
• The VLAN pools has been created containing the range of VLANs you wish to use for EPG Deployment
on the AEP.
• The physical domain has been created and linked to the VLAN Pool and AEP.
• The target attached entity profile is created and is associated with the ports on which you want to deploy
the application EPG.
Procedure
Step 1
Associate the target EPG with the interface policy group.
The sample command sequence specifies an interface policy group pg3 associated with VLAN domain,
domain1, and with VLAN 1261. The application EPG, epg47 is deployed to all interfaces associated with
this policy group.
Example:
apic1# configure terminal
apic1(config)# template policy-group pg3
apic1(config-pol-grp-if)# vlan-domain member domain1
apic1(config-pol-grp-if)# switchport trunk allowed vlan 1261 tenant tn10 application pod1-AP
Cisco APIC Basic Configuration Guide, Release 2.x
137
Basic User Tenant Configuration
Deploying an EPG through an AEP to Multiple Interfaces Using the REST API
epg epg47
Step 2
Check the target ports to ensure deployment of the policies of the interface policy group associated with
application EPG.
The output of the sample show command sequence indicates that policy group pg3 is deployed on Ethernet
port 1/20 on leaf switch 1017.
Example:
apic1# show run leaf 1017 int eth 1/20
# Command: show running-config leaf 1017 int eth 1/20
# Time: Mon Jun 27 22:12:10 2016
leaf 1017
interface ethernet 1/20
policy-group pg3
exit
exit
ifav28-ifc1#
Deploying an EPG through an AEP to Multiple Interfaces Using the REST API
The interface selectors in the AEP enable you to configure multiple paths for an AEPg. The following can be
selected:
1 A node or a group of nodes
2 An interface or a group of interfaces
The interfaces consume an interface policy group (and so an infra:AttEntityP).
3 The infra:AttEntityP is associated to the AEPg, thus specifying the VLANs to use.
An infra:AttEntityP can be associated with multiple AEPgs with different VLANs.
When you associate the infra:AttEntityP with the AEPg, as in 3, this deploys the AEPg on the nodes selected
in 1, on the interfaces in 2, with the VLAN provided by 3.
In this example, the AEPg uni/tn-Coke/ap-AP/epg-EPG1 is deployed on interfaces 1/10, 1/11, and 1/12 of
nodes 101 and 102, with vlan-102.
Before You Begin
• Create the target application EPG (AEPg).
• Create the VLAN pool containing the range of VLANs you wish to use for EPG deployment with the
Attached Entity Profile (AEP).
• Create the physical domain and link it to the VLAN pool and AEP.
Procedure
To deploy an AEPg on selected nodes and interfaces, send a post with XML such as the following:
Cisco APIC Basic Configuration Guide, Release 2.x
138
Basic User Tenant Configuration
Using Microsegmentation with Network-based Attributes on Bare Metal
Example:
<infraInfra dn="uni/infra">
<infraNodeP name=“NodeProfile">
<infraLeafS name=“NodeSelector" type="range">
<infraNodeBlk name=“NodeBlok" from_="101" to_=“102”/>
<infraRsAccPortP tDn="uni/infra/accportprof-InterfaceProfile"/>
</infraLeafS>
</<infraNodeP>
<infraAccPortP name="InterfaceProfile">
<infraHPortS name="InterfaceSelector" type="range">
<infraPortBlk name=“ InterfaceBlock" fromCard="1" toCard="1" fromPort="10"
toPort=“12"/>
<infraRsAccBaseGrp tDn="uni/infra/funcprof/accportgrp-PortGrp" />
</infraHPortS>
</infraAccPortP>
<infraFuncP>
<infraAccPortGrp name="PortGrp”>
<infraRsAttEntP tDn="uni/infra/attentp-AttEntityProfile"/>
</infraAccPortGrp>
</infraFuncP>
<infraAttEntityP name=“AttEntityProfile” >
<infraGeneric name=“default” >
<infraRsFuncToEpg tDn=“uni/tn-Coke/ap-AP/epg-EPG1” encap=“vlan-102"/>
</infraGeneric>
</infraAttEntityP>
</infraInfra>
Using Microsegmentation with Network-based Attributes on
Bare Metal
You can use Cisco APIC to configure Microsegmentation with Cisco ACI to create a new, attribute-based
EPG using a network-based attribute, a MAC address or one or more IP addresses. You can configure
Microsegmentation with Cisco ACI using network-based attributes to isolate VMs or physical endpoints
within a single base EPG or VMs or physical endpoints in different EPGs.
Using an IP-based Attribute
You can use an IP-based filter to isolate a single IP address, a subnet, or multiple of noncontiguous IP addresses
in a single microsegment. You might want to isolate physical endpoints based on IP addresses as a quick and
simply way to create a security zone, similar to using a firewall.
Using a MAC-based Attribute
You can use a MAC-based filter to isolate a single MAC address or multiple MAC addresses. You might
want to do this if you have a server sending bad traffic int he network. By creating a microsegment with a
MAC-based filter, you can isolate the server.
Cisco APIC Basic Configuration Guide, Release 2.x
139
Basic User Tenant Configuration
Configuring Network-based Microsegmented EPGs in a Bare-Metal environment Using the GUI
Configuring Network-based Microsegmented EPGs in a Bare-Metal
environment Using the GUI
You can use Cisco APIC to configure microsegmentation to put physical endpoint devices that belong to
different base EPGs or the same EPG into a new attribute-based EPG.
Caution: Cisco recommends that you do not mix configuration modes (Advanced or Basic). When you make
a configuration in either mode and change the configuration using the other mode, unintended changes can
occur. For example, if you apply an interface policy to two ports using Advanced mode and then change the
settings of one port using Basic mode, your changes might be applied to both ports.
Note
The procedure for configuring Microsegmentation for Cisco ACI is the same in Advanced mode and Basic
mode.
Procedure
Step 1
Step 2
Step 3
Step 4
Log into the Cisco APIC, choosing Advanced or Basic mode.
Choose TENANTS and then choose the tenant within which you want to create a microsegment.
In the tenant navigation pane, expand the tenant folder, the Application Profiles folder, the profile folder,
and the Application EPGs folder.
Take one of the following actions:
• If you want to put physical endpoint devices from the same base EPG into a new, attribute-based EPG,
click the base EPG containing the physical endpoint devices.
• If you want to put physical endpoint devices from different base EPGs into a new, attribute-based EPG,
click one of the base EPG containing the physical endpoint devices.
The properties for the base EPG appear in the work pane.
In the work pane, click the OPERATIONAL tab at the top right of the screen.
Below the OPERATIONAL tab, ensure that the Client End-Points tab is active.
The work pane displays all the physical endpoints that belong to the base EPG.
Step 7 Note the IP address or MAC address for the endpoint device or endpoint devices that you want to put into a
new microsegment.
Step 8 If you want to put endpoint devices from different base EPGs into a new attribute-based EPG, repeat Step 4
through Step 7 for each of the base EPGs.
Step 9 In the tenant navigation pane, right-click the uSeg EPGs folder, and then choose Create uSeg EPG.
Step 10 Complete the following series of steps to begin creation of an attribute-based EPG for one of the groups of
endpoint devices:
a) In the Create uSeg EPG dialog box, in the Name field, enter a name.
We recommend that you choose a name that indicates that the new attribute-based EPG is a microsegment.
Step 5
Step 6
b) In the intra-EPG isolation field, select enforced or unenforced.
If you select enforced, ACI prevents all communication between the endpoint devices within this uSeg
EPG.
Cisco APIC Basic Configuration Guide, Release 2.x
140
Basic User Tenant Configuration
Configuring Network-based Microsegmented EPGs in a Bare-Metal environment Using the GUI
c) In the Bridge Domain area, choose a bridge domain from the drop-down list.
d) In the uSeg Attributes area, choose IP Address Filter or MAC Address Filter from the + drop-down
list on the right side of the dialog box.
Step 11 Complete one of the following series of steps to configure the filter.
If you want to use...
An IP-based attribute
Then...
1 In the Create IP Attribute dialog box, in the Name field, enter a name.
We recommend that you choose a name that reflects the filter's function.
2 In the IP Address field, enter an IP address or a subnet with the appropriate
subnet mask.
3 Click OK.
4 (Optional) Create a second IP Address filter by repeating Step 10 c through
Step 11 c.
You might want to do this to include discontinuous IP addresses in the
microsegment.
5 In the Create uSeg EPG dialog box, click SUBMIT.
A MAC-based attribute
1 In the Create MAC Attribute dialog box, in the Name field, enter a name.
We recommend that you choose a name that reflects the filter's function.
2 In the MAC Address field, enter a MAC address.
3 Click OK.
4 In the Create uSeg EPG dialog box, click SUBMIT.
Step 12 Complete the following steps to associate the uSeg EPG with a physical domain.
a) In the navigation pane, ensure that the uSeg EPG folder is open and then open the container for the
microsegment that you just created.
b) Click the folder Domains (VMs and Bare-Metals).
c) On the right side of the work pane, click ACTIONS and then choose Add Physical Domain Association
from the drop-down list.
d) In the Add Physical Domain Association dialog box, choose a profile from the Physical Domain Profile
drop-down list.
e) In the Deploy Immediacy area, accept the default On Demand.
f) In the Resolution Immediacy area, accept the default On Demand.
g) Click SUBMIT.
Step 13 Associate the uSeg EPG with the appropriate leaf switch.
a) In the navigation pane, ensure the uSeg EPG folder is open then click Static Leafs.
b) In the Static Leafs window, click Actions > Statically Link with Node
c) In the Statically Link With Node dialog, select the leaf node and mode.
d) Click Submit.
Step 14 Repeat Step 9 through Step 13 for any other network attribute-based EPGs that you want to create.
Cisco APIC Basic Configuration Guide, Release 2.x
141
Basic User Tenant Configuration
Configuring a Network-Based Microsegmented EPG in a Bare-Metal Environment Using the NX-OS Style CLI
What to Do Next
Verify that the attribute-based EPG was created correctly.
If you configured an IP-based or MAC-based attribute, make sure that traffic is running on the end pont
devices that you put into the new microsegments.
Configuring a Network-Based Microsegmented EPG in a Bare-Metal
Environment Using the NX-OS Style CLI
This section describes how to configure microsegmentation with Cisco ACI using network-based attributes
(IP address or MAC address) within a base EPG in a bare-metal environment.
Procedure
Command or Action
Step 1
In the CLI, enter configuration mode:
Example:
apic1# configure
apic1(config)#
Step 2
Create the microsegment:
Example:
This example uses a filter based on an IP address.
apic1(config)# tenant cli-ten1
apic1(config-tenant)# application cli-a1
apic1(config-tenant-app)# epg cli-uepg1 type micro-segmented
apic1(config-tenant-app-uepg)# bridge-domain member cli-bd1
apic1(config-tenant-app-uepg)# attribute cli-upg-att match ip <X.X.X.X>
#Schemes to express the ip
A.B.C.D
IP Address
A.B.C.D/LEN IP Address and mask
Example:
This example uses a filter based on a MAC address.
apic1(config)# tenant cli-ten1
apic1(config-tenant)# application cli-a1
apic1(config-tenant-app)# epg cli-uepg1 type micro-segmented
apic1(config-tenant-app-uepg)# bridge-domain member cli-bd1
apic1(config-tenant-app-uepg)# attribute cli-upg-att match mac
<FF-FF-FF-FF-FF-FF>
#Schemes to express the mac
E.E.E MAC address (Option 1)
EE-EE-EE-EE-EE-EE MAC address (Option 2)
EE:EE:EE:EE:EE:EE MAC address (Option 3)
EEEE.EEEE.EEEE MAC address (Option 4)
Example:
This example uses a filter based on a MAC address and enforces intra-EPG isolation
between all members of this uSeg EPG:
apic1(config)# tenant cli-ten1
apic1(config-tenant)# application cli-a1
apic1(config-tenant-app)# epg cli-uepg1 type micro-segmented
Cisco APIC Basic Configuration Guide, Release 2.x
142
Purpose
Basic User Tenant Configuration
Configuring a Network-Based Microsegmented EPG in a Bare-Metal Environment Using the REST API
Command or Action
Purpose
apic1(config-tenant-app-uepg)# isolation enforced
apic1(config-tenant-app-uepg)# bridge-domain member cli-bd1
apic1(config-tenant-app-uepg)# attribute cli-upg-att match mac
<FF-FF-FF-FF-FF-FF>
#Schemes to express the mac
E.E.E MAC address (Option 1)
EE-EE-EE-EE-EE-EE MAC address (Option 2)
EE:EE:EE:EE:EE:EE MAC address (Option 3)
EEEE.EEEE.EEEE MAC address (Option 4)
Step 3
Deploy the EPG.
Example:
This example deploys the EPG and bids to the leaf.
apic1(config)# leaf 101
apic1(config-leaf)# deploy-epg tenant cli-ten1 application cli-a1 epg
cli-uepg1 type micro-segmented
Step 4
Verify the microsegment creation:
Example:
apic1(config-tenant-app-uepg)# show running-config
# Command: show running-config tenant cli-ten1 application cli-app1 epg
cli-uepg1 type micro-segmented
# Time: Thu Oct 8 11:54:32 2015
tenant cli-ten1
application cli-app1
epg cli-esx1bu type micro-segmented
bridge-domain cli-bd1
attribute cli-uepg-att match mac 00:11:22:33:44:55
exit
exit
exit
Configuring a Network-Based Microsegmented EPG in a Bare-Metal
Environment Using the REST API
This section describes how to configure network attribute microsegmentation with Cisco ACI in a bare-metal
environment using the REST API.
Procedure
Step 1
Step 2
Log in to the Cisco APIC.
Post the policy to https://apic-ip-address/api/node/mo/.xml.
Example:
A: The following example configures a microsegment named 41-subnet using an IP-based attribute.
<polUni>
<fvTenant dn="uni/tn-User-T1" name="User-T1">
<fvAp dn="uni/tn-User-T1/ap-Base-EPG" name="Base-EPG">
<fvAEPg dn="uni/tn-User-T1/ap-Base-EPG/epg-41-subnet" name="41-subnet"
pcEnfPref="enforced” isAttrBasedEPg="yes" >
Cisco APIC Basic Configuration Guide, Release 2.x
143
Basic User Tenant Configuration
IP Address-Based Microsegmented EPG as a Shared Resource
<fvRsBd tnFvBDName="BD1" />
<fvCrtrn name="Security1">
<fvIpAttr name="41-filter" ip="12.41.0.0/16"/>
</fvCrtrn>
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>
Example:
This example is for base EPG for Example A: .
<polUni>
<fvTenant dn="uni/tn-User-T1" name="User-T1">
<fvAp dn="uni/tn-User-T1/ap-Base-EPG" name="Base-EPG">
<fvAEPg dn="uni/tn-User-T1/ap-Base-EPG/baseEPG” name=“baseEPG” pcEnfPref="enforced”
>
<fvRsBd tnFvBDName="BD1" />
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>
Example:
B: The following example configures a microsegment named useg-epg using a MAC-based attribute.
<polUni>
<fvTenant name="User-T1">
<fvAp name="customer">
<fvAEPg name="useg-epg" isAttrBasedEPg="true">
<fvRsBd tnFvBDName="BD1"/>
<fvRsDomAtt instrImedcy="immediate" resImedcy="immediate" tDn="uni/phys-phys"
/>
<fvRsNodeAtt tDn="topology/pod-1/node-101" instrImedcy="immediate" />
<fvCrtrn name="default">
<fvMacAttr name="mac" mac="00:11:22:33:44:55" />
</fvCrtrn>
</fvAEPg>
</fvAp>
</fvTenant>
</polUni>
IP Address-Based Microsegmented EPG as a Shared Resource
You can configure an IP address-based microsegemented EPG as a resource that can be accessed from both
within and without the VRF on which it is located. The method of doing so is to configure an existing IP
address-based microsegmented EPG with a subnet (assigned a unicast IP address) and enable that subnet for
being advertised and shared by devices located on VRFs other than the one on which this EPG is native. Then
you define an IP attribute with an option enabled that associates the EPG with the IP address of the shared
subnet.
Configuring an IP-based Microsegmented EPG as a Shared Resource Using
the GUI
You can configure a microsegmented EPG with an IP-Address with 32 bit mask as a shared service, accessible
by clients outside of the VRF and the current fabric.
Cisco APIC Basic Configuration Guide, Release 2.x
144
Basic User Tenant Configuration
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the GUI
Before You Begin
The following GUI description of configuring assumes the preconfiguration of an IP address-based
microsegmented EPG configured whose subnet mask is /32.
Note
• For directions on configuring an IP address based EPG in a physical environment, see Using
Microsegmentation with Network-based Attributes on Bare Metal, on page 139
• For directions on configuring an IP address based EPG in a virtual environment, see Configuring
Microsegmentation with Cisco ACI in the Cisco ACI Virtualization Guide.
Procedure
Step 1
Navigate to the target IP-address-based EPG.
a) In the APIC GUI, click Tenant > tenant_name > uSeg EPGs > uSeg_epg_name to display the EPG's
Properties dialog.
Step 2
For the target EPG, configure an IP attribute to match the EPG subnet address.
a) In the Properties dialog, locate the uSeg Attributes table, and click +. When prompted, choose IP Address
Filter to display the Create IP Attribute dialog.
b) Enter a name in the Name field
c) Check the box for Use FV Subnet.
Enabling this option, indicates that the IP attribute value matches the IP address of a shared subnet.
d) Click Submit.
Step 3
Create a shared subnet for the target EPG.
a) With the folder for the target IP address-based uSeg EPG still open in the APIC navigation pane, right-click
the Subnets folder and select Create EPG Subnets.
b) In the Default Gateway field, enter the IP address/mask of the IP address-based microsegmented EPG.
Note
• In all cases the subnet mask must be /32.
• In the context of an IP address-based EPG, you are not actually entering the default address
for a gateway, rather you are entering the IP address for the shared EPG subnet.
c) Select Treat as a virtual IP address.
d) Under Scope select Advertised Externally and Shared between VRFs.
e) Click Submit.
Cisco APIC Basic Configuration Guide, Release 2.x
145
Basic User Tenant Configuration
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the NX-OS CLI
Configuring an IP-based Microsegmented EPG as a Shared Resource Using
the NX-OS CLI
Before You Begin
The following GUI description of configuring assumes the preconfiguration of an IP address-based
microsegmented EPG configured whose subnet mask is /32.
Procedure
Command or Action
Purpose
Step 1 Enable the IP address microsegmented EPG for In this example, microsegmented EPG, cli-epg, is
shared service by associating the EPG with the IP configured with the ip-use-epg-subnet option
address of its subnet.
(useFvSubnet), thus associating the EPG with the
IP address of its subnet. APIC then advertises that
subnet address, thus making the EPG accessible as
Example:
apic-1(config)# tenant t0
a service to devices on VRFs other than the one on
apic-1(config-tenant-app)# epg cli-epg
which the EPG is native.
type micro-segmented
apic-1(config-tenant-app-uepg)#
bridge-domain member b0
apic-1(config-tenant-app-uepg)# attribute
ip match ip-use-epg-subnet
apic-1(config-tenant-app-uepg)# show run
# Command: show running-config tenant t0
application a0 epg cli-epg type
micro-segmented
# Time: Thu Sep 22 00:17:07 2016
tenant t0
application a0
epg cli-epg type micro-segmented
bridge-domain member b0
attribute ip match
ip-use-epg-subnet
exit
exit
Exit
Step 2 Deploy the EPG to a leaf.
In this example, microsegmented EPG, cli-epg, is
deployed to leaf 102.
apic-1(config)# leaf 102
apic-1(config-leaf)# deploy-epg tenant t0
application a0 epg cli-epg type
micro-segmented
apic-1(config-leaf)# show run
# Command: show running-config leaf 102
# Time: Thu Sep 22 00:18:46 2016
leaf 102
deploy-epg tenant t0 application a0 epg
cli-epg type micro-segmented
Cisco APIC Basic Configuration Guide, Release 2.x
146
Basic User Tenant Configuration
Configuring an IP-based Microsegmented EPG as a Shared Resource Using the REST API
Configuring an IP-based Microsegmented EPG as a Shared Resource Using
the REST API
You can configure a microsegmented EPG with an IP-Address with 32 bit mask as a shared service, accessible
by clients outside of the VRF and the current fabric.
Procedure
To configure an IP address-attribute microsegmented EPG epg3 with a shared subnet, with an IP address and
32-bit mask, send a post with XML such as the following example. In the IP attributes, the attribute usefvSubnet
is set to "yes."
Example:
<fvAEPg descr="" dn="uni/tn-t0/ap-a0/epg-epg3" fwdCtrl=""
isAttrBasedEPg="yes" matchT="AtleastOne" name="epg3" pcEnfPref="unenforced"
prefGrMemb="exclude"prio="unspecified">
<fvRsCons prio="unspecified" tnVzBrCPName="ip-epg"/>
<fvRsNodeAtt descr="" encap="unknown" instrImedcy="immediate" mode="regular"
tDn="topology/pod-2/node-106"/>
<fvSubnet ctrl="" descr="" ip="56.4.0.2/32" name="" preferred="no"
scope="public,shared" virtual="no"/>
<fvRsDomAtt classPref="encap" delimiter="" encap="unknown" encapMode="auto"
instrImedcy="immediate"
primaryEncap="unknown" resImedcy="immediate" tDn="uni/phys-vpc"/>
<fvRsCustQosPol tnQosCustomPolName=""/>
<fvRsBd tnFvBDName="b2"/>
<fvCrtrn descr="" match="any" name="default" ownerKey="" ownerTag="" prec="0">
<fvIpAttr descr="" ip="1.1.1.3" name="ipv4" ownerKey="" ownerTag=""
usefvSubnet="yes”/>
</fvCrtrn>
<fvRsProv matchT="AtleastOne" prio="unspecified" tnVzBrCPName="ip-epg"/>
<fvRsProv matchT="AtleastOne" prio="unspecified" tnVzBrCPName="shared-svc"/>
</fvAEPg>
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using
the GUI
When you unconfigure an IP address-Based microsegmented EPG as a shared service, you must remove the
shared subnet and also disable the option to use that subnet as a shared resource.
Before You Begin
Before you unconfigure an IP address-based microsegmented EPG as a shared service, you should know the
following:
• Know which subnet is configured as a shared service address for the IP address-based microsegmented
EPG.
• Know which IP attribute is configured with the Use FV Subnet option enabled.
Procedure
Step 1
Remove subnet from the IP addressed-based microsegmented EPG.
Cisco APIC Basic Configuration Guide, Release 2.x
147
Basic User Tenant Configuration
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the NX-OS Style CLI
a) In the APIC GUI, click Tenant > tenant_name > Application Profiles > epg_name > uSeg EPGs >
uSeg EPGs > uSeg_epg_name.
b) With the folder for the target IP address-based uSeg EPG still open in the APIC navigation pane, click the
Subnets folder.
c) In the Subnets window, select the subnet that is advertised and shared with other VRFs and click Actions
> Delete. then
d) Click Yes to confirm the deletion.
Step 2
Disable the Use FV Subnet option.
a) With the folder for the target IP address-based uSeg EPG still open in the APIC navigation pane, click the
name of the micro-segmented EPG to display the to display the EPG's Properties dialog.
b) In the Properties dialog, locate the uSeg Attributes table, and locate the IP attribute item with the Use
FV Subnet option enabled.
c) Double-click that item to display the Edit IP Attribute dialog.
d) In the Edit IP Attribute dialog, deselect the Use FV Subnet option.
e) Assign another IP address attribute in the IP Address field.
Note
This address must be a unicast address with a 32 bit mask (for example: 124.124.124.123/32).
f) Click Submit.
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using
the NX-OS Style CLI
To unconfigure an IP address-based microsegmented EPG as a shared service, disable the ip-use-epg-subnet
option for that EPG.
Before You Begin
Procedure
Step 1
Command or Action
Purpose
Disable the ip-use-epg-subnet option.
The example code disables the
ip-use-epg-subnet option for the
microsegmented EPG cli-epg.
Example:
apic-1(config)# tenant t0
apic-1(config-tenant-app)# epg cli-epg type
micro-segmented
apic-1(config-tenant-app-uepg)# no attribute ip
match ip-use-epg-subnet
apic-1(config-tenant-app-uepg)# exit
apic-1(config-tenant-app)# exit
Cisco APIC Basic Configuration Guide, Release 2.x
148
Basic User Tenant Configuration
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the REST API
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using
the REST API
You can disable an IP address-based microsegmented EPG by setting the usefvSubnet property to "no."
Procedure
In the API structure for the microsegmented EPG currently configured as a shared service, change the value
of the usefvSubnet property from "yes" to "no."
In the example, the IP address-based microsegmented EPG, epg3, is disabled as a shared service.
Example:
<fvAEPg descr="" dn="uni/tn-t0/ap-a0/epg-epg3" fwdCtrl="" isAttrBasedEPg="yes"
matchT="AtleastOne" name="epg3" pcEnfPref="unenforced" prefGrMemb="exclude"prio="unspecified">
<fvRsCons prio="unspecified" tnVzBrCPName="ip-epg"/>
<fvRsNodeAtt descr="" encap="unknown" instrImedcy="immediate" mode="regular"
tDn="topology/pod-2/node-106"/>
<fvSubnet ctrl="" descr="" ip="56.4.0.2/32" name="" preferred="no" scope="public,shared"
virtual="no"/>
<fvRsDomAtt classPref="encap" delimiter="" encap="unknown" encapMode="auto"
instrImedcy="immediate" primaryEncap="unknown" resImedcy="immediate" tDn="uni/phys-vpc"/>
<fvRsCustQosPol tnQosCustomPolName=""/>
<fvRsBd tnFvBDName="b2"/>
<fvCrtrn descr="" match="any" name="default" ownerKey="" ownerTag="" prec="0">
<fvIpAttr descr="" ip="1.1.1.3" name="ipv4" ownerKey="" ownerTag="" usefvSubnet="no”/>
</fvCrtrn>
<fvRsProv matchT="AtleastOne" prio="unspecified" tnVzBrCPName="ip-epg"/>
<fvRsProv matchT="AtleastOne" prio="unspecified" tnVzBrCPName="shared-svc"/>
</fvAEPg>
Cisco APIC Basic Configuration Guide, Release 2.x
149
Basic User Tenant Configuration
Unconfiguring an IP-based Microsegmented EPG as a Shared Resource Using the REST API
Cisco APIC Basic Configuration Guide, Release 2.x
150
INDEX
(enabling) NX-OS Format 73
(enabling) Syslog 73
A
application policy 124
application profile 124
assign 13
AV Pairs 13
atomic counters 74, 75, 76
about 74
configuring 76
guidelines and restrictions 75
AV pair 12, 13
B
Backing up, restoring, rolling back controller configuration 61
bad Cisco AV pairs 20
best practice 13
AV Pairs 13
bridge domain 119
configuring export policy 54, 58
configuring with GUI 54, 58
Configuring Import policy 56
configuring with GUI 56
contract 124
core files 47
creating 14, 15, 16, 17, 19, 115, 117, 132, 133, 134
ACS 16
APIC 14, 15, 16, 19
attach entity profiles 133, 134
cisco-av-pair 17
domains 132, 133
external routed network 117
LDAP 17, 19
OSPF external routed network 115
physical domains 134
RADIUS 15, 16
TACACS+ 14, 16
VLANS 132, 133, 134
Windows Server 17
D
deploying 129, 130, 131
EPG on a port 130, 131
EPG on a specific port 129
C
certificate authority 101
configuring 9, 11, 12, 24, 35, 36, 39, 40, 43, 45, 86, 87, 90, 92, 93, 97, 98,
99, 101, 111, 112, 113
custom certificate 101
DHCP server policy 92, 93
DNS server policy 97, 98, 99
in-band management access 35, 36, 39, 40
local user 9, 11, 12, 24
MP-BGP route reflector 111, 112, 113
NTP 86, 87, 90
out-of-band management access 43, 45
configuring an import policy 57
configuring with REST API 57
E
export policy using API 55, 60
configuring export policy with REST API 55, 60
exporting files 47, 48
about 47
creating destination 48
external authentication server 12, 13
external connectivity 111
external destinations 94
Cisco APIC Basic Configuration Guide, Release 2.x
IN-1
Index
SPAN (continued)
configuring 81
guidelines and restrictions 81
syslog 70, 71, 72
about 70
destination 71
source 72
F
filter 124
L
local user 9
T
M
management access 33
missing Cisco AV pairs 20
R
remote user 12
S
techsupport file 48
sending 48
techsupport files 47
tenant 119
three-tier application 124
traceroute 82, 83
about 82
configuring 83
guidelines and restrictions 82
V
SNMP 77, 79, 80
about 77
configuring policy 77
configuring trap destination 79
configuring trap source 80
SPAN 81
about 81
Cisco APIC Basic Configuration Guide, Release 2.x
IN-2
verifying 91, 100
DNS profile 100
NTP operation 91
Verifying NTP Policy 91
VRF 119
Was this manual useful for you? yes no
Thank you for your participation!

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

Download PDF

advertisement