Management

APIC Overview

There are a number of fundamental differences between the operations of traditional networking hardware and an Cisco Application Centric Infrastructure (ACI) fabric. These differences serve to simplify the management greatly, reduce the number of touch points, and decouple the switching hardware from the desired configuration intent. These changes include:

Single point of management controller-based architecture
Stateless hardware
Desired state-driven eventual consistency model

The single point of management within the 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 uniformly approached through a graphical user interface (GUI), command line interface (CLI), and API, with no risk of inconsistency between the various data interfaces. This results in a clean and predictable transition between the interfaces. The underlying interface for all access methods is provided through a REST-based API, which modifies the contents of a synchronized database that is replicated across APICs in a cluster and provides an abstraction layer between all of the interfaces.

This controller-based architecture also makes possible a stateless configuration model that decouples the hardware from the configuration running on it. This translates to an APIC cluster that manages individual fabric nodes of leaf and spine switches that derive their identity from what the controller defines as being the desired intent, and not from the serial number of the chassis, nor from a configuration file residing on the devices. Each node receives a unique node identifier, which allows for the device to download the correct configuration attributes from the controller. The device can also be substituted in a stateless fashion, meaning that hardware swaps can be faster, topology changes are less impactful, and network management is simplified.

The desired state model for configuration further complements these concepts of controller-based management and statelessness by taking advantage of a concept known as declarative control-based management, based on a concept known as the promise theory. Declarative control dictates that each object is asked to achieve a desired state and makes a "promise" to reach this state without being told precisely how to do so. This stands in contrast with the traditional model of imperative control, where each managed element must be told precisely what to do, be told how to do it, and take into account the specific situational aspects that will impact its ability to get from its current state to the configured state. A system based on declarative control is able to scale much more efficiently than an imperative-based system, since each entity within the domain is responsible for knowing its current state and the steps required to get to the desired state, dictated by the managing controller.

For information about new APIC features, see the Cisco Application Policy Infrastructure Controller Release Notes for your release of the software:

http://www.cisco.com/c/en/us/support/cloud-systems-management/application-policy-infrastructure-controller-apic/ tsd-products-support-series-home.html

Configuring Management Protocols

For the optimization of ACME's Cisco Application Centric Infrastructure (ACI) fabric, the network team created the following management protocol policies:

Cisco Discovery Protocol (CDP) - These policies are primarily consumed by the network team, as CDP is the standard for their existing network equipment.
Link Layer Discovery Protocol (LLDP) - Discovery protocols are no longer limited to just network devices. LLDP is a standards-based protocol for discovering topology relationships. ACME is deploying LLDP on servers, Layer 4 to Layer 7 services devices, and storage arrays. Therefore, these policies will be available for consumption by all of the teams.
Network Time Protocol (NTP) - Maintaining accurate time across the application logs and infrastructure components is extremely important for being able to correlate events. ACME has existing NTP servers and will leverage them for maintaining time in their ACI fabric deployment. With ACI, maintaining accurate time is of increased importance as accurate time is a prerequisite for features such as atomic counters.
Domain Name Services (DNS) - providing name resolution to fabric components consistent with the application and server teams. In addition to be able to resolve names within the fabric, the important ACI components are also registered with ACME's DNS server so teams can easily access them in their management tasks.

Creating a Cisco Discovery Protocol Policy Using the GUI

Cisco Discovery Protocol (CDP) is a valuable source of information in troubleshooting physical and data-link layer issues. In the course of ACI operations, there may be times when you must provision a particular host-facing port manually with a CDP on or off policy. By default, the ACI fabric provides a default policy where CDP is disabled. As a recommended practice, manually create a "CDP-ENABLED" policy with CDP enabled, as well as a "CDP-DISABLED" policy with CDP disabled that can be referenced throughout all interface policy configurations.

To create CDP policies:

On the menu bar, choose Fabric > Access Policies.
In the Navigation pane, choose Interface Policies > Policies > CDP Interface.
In the Work pane, choose Actions > Create CDP Interface Policy.
In the Create CDP Interface Policy dialog box, perform the following actions:
1. In the Name field enter the name of the policy, such as "CDP-ENABLED".
2. For the Admin State radio buttons, click Enabled.
3. Click Submit.
In the Work pane, choose Actions > Create CDP Interface Policy.
In the Create CDP Interface Policy dialog box, perform the following actions:
1. In the Name field enter the name of the policy, such as "CDP-DISABLED".
2. For the Admin State radio buttons, click Disabled.
3. Click Submit.

Your CDP policy is now ready to be assigned to an Interface Policy Group.

Creating a Link Layer Discovery Protocol Policy Using the GUI

Link Layer Discovery Protocol (LLDP) is a valuable source of information for troubleshooting physical and data-link layer issues. In the course of ACI operations, by default, the LLDP feature is enabled on the fabric. There might be times in the operation of the ACI fabric in which you must manually adjust the LLDP protocol to conform with interoperability requirements of end-host devices. For example, when connecting to Cisco Unified Computing System (UCS) Blade servers, you must disable LLDP.

Cisco recommends that you pre-provision LLDP enable and disable protocol policies to make future interface policy deployment decisions streamlined and easily configured.

To create an LLDP policy:

On the menu bar, choose Fabric > Access Policies.
In the Navigation pane, choose Interface Policies > Policies > LLDP Interface.
In the Work pane, choose Actions > Create LLDP Interface Policy.
In the Create LLDP Interface Policy dialog box, perform the following actions:
1. In the Name field, enter "LLDP-TX-ON-RX-ON".
2. For the Receive State radio buttons, click Enabled.
3. For the Transmit State radio buttons, click Enabled.
4. Click Submit.
In the Work pane, choose Actions > Create LLDP Interface Policy.
In the Create LLDP Interface Policy dialog box, perform the following actions:
1. In the Name field, enter "LLDP-TX-ON-RX-OFF".
2. For the Receive State radio buttons, click Disabled.
3. For the Transmit State radio buttons, click Enabled.
4. Click Submit.
In the Work pane, choose Actions > Create LLDP Interface Policy.
In the Create LLDP Interface Policy dialog box, perform the following actions:
1. In the Name field, enter "LLDP-TX-OFF-RX-ON".
2. For the Receive State radio buttons, click Enabled.
3. For the Transmit State radio buttons, click Disabled.
4. Click Submit.
In the Create LLDP Interface Policy dialog box, perform the following actions:
1. In the Name field, enter "LLDP-TX-OFF-RX-OFF".
2. For the Receive State radio buttons, click Disabled.
3. For the Transmit State radio buttons, click Disabled.
4. Click Submit.

Your LLDP policies are now ready to be leverage as part of an Interface Policy Group.

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, including the following tasks:

The Application Policy Infrastructure Controllers (APICs) and fabric switches use certificates to establish encrypted communication channels between themselves. If the time difference between the APIC and switches is significantly large (greater than 7 hours), the switch might tear down existing communication channels or never create new communication channels with the APIC, which isolates the switch from the fabric until the time is manually set on the switch.
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 diagnose properly 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.

While you should configure time synchronization before deploying a full fabric or applications so as to enable proper usage of these features, nonexistent or improper configuration of time synchronization does not necessarily trigger a fault or a low health score. The most widely adopted method for synchronizing a device clock is to use Network Time Protocol (NTP). For more information on atomic counters, see Atomic Counters.

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 APICs, in-band management and/or out-of-band management. Depending on which management option was chosen for the fabric, configuration of NTP will vary.

Another consideration in deploying time synchronization 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.

Configuring Out-of-Band Management NTP Using the GUI

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. As of the publishing of this document, only one pod per ACI fabric is allowed.

To configure NTP using the GUI:

On the menu bar, choose Fabric > Fabric Policies.
In the Navigation pane, choose Pod Policies > Policies.
In the Work pane, choose Actions > Create Date and Time Policy.
In the Create Date and Time Policy dialog box, perform the following actions:
1. Provide a name for the policy to easily distinguish between your environment's different NTP configurations, such as "Production-NTP".
2. Click Next.
3. Click the + sign to specify the NTP server information (provider) to be used.
4. In the Create Providers dialog box, enter all relevant information, including the following fields: Name, Description, and Minimum Polling Intervals, and Maximum Polling Intervals.
  1. If you are creating multiple providers, click the Preferred check box for the most reliable NTP source.
  2. 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 "In-Band Management NTP" section.
  3. Click OK.
5. Repeat steps c and d for each provider that you want to create.

Your NTP policy is now ready for deployment to the ACI fabric nodes.

Configuring Out-of-Band Management NTP Using the NX-OS-Style CLI

You can configure the NTP server for POD 1, the default POD for the fabric, by using the NX-OS-style CLI.

Procedure

Step 1	SSH to an APIC in the fabric. `# ssh admin@node_name`
Step 2	Enter the configure mode: `apic1# configure`
Step 3	Enter the configure mode for POD 1: `apic1(config)# pod 1`
Step 4	Enter the NTP configure mode: `apic1(config-pod)# ntp`
Step 5	Configure the NTP server: `apic1(config-ntp)# server 192.168.29.35 prefer use-vrf oob-mgmt` This configuration prefers IP address 192.168.29.35 as an NTP source and uses VRF oob-mgmt (out-of-band management) to reach it.

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, that is from a source that is reachable through the front panel leaf ports. To leverage an NTP server external to the fabric with in-band management, you must 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.

Once you have established a policy to allow communication, you can create the NTP policy as established in the "Out-of-Band Management NTP" section.

Verifying NTP Operation Using the GUI

Full verification of NTP functionality is best accomplished by leveraging both the Cisco Application Centric Infrastructure (ACI) CLI and the Application Policy Infrastructure Controller (APIC) GUI. Start verifying time synchronization configuration by ensuring that all policies are configured properly inside of the APIC GUI. Policy configuration can be verified by using the following procedure:

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.
In the Work pane, verify the details of the server.

Verifying the NTP Policy Configuration Using the NX-OS-Style CLI

You can verify the NTP policy configuration using the NX-OS-style CLI.

Procedure

Step 1	SSH to an APIC in the fabric. `# ssh admin@node_name`
Step 2	Enter the configure mode: `apic1# configure`
Step 3	Show the configuration of POD 1: `apic1(config)# show running pod 1 ntp # Command: show running-config pod 1 ntp # Time: Mon Nov 9 17:17:18 2015`
Step 4	Enter the configure mode for POD 1: `apic1(config)# pod 1`
Step 5	Enter the NTP configure mode: `apic1(config-pod)# ntp`
Step 6	Configure the NTP server: `apic1(config-ntp)# server 192.168.29.35 prefer use-vrf oob-mgmt`
Step 7	Exit to the configure mode: `apic1(config-ntp)# exit apic1(config-pod)# exit`

Verifying that the NTP Policy is Deployed on Each Fabric Switch Using the NX-OS-Style CLI

To verify that the policy has been successfully deployed on each fabric switch, you should use the NX-OS Virtual Shell that is present in the APIC. To access the NX-OS Virtual Shell, open an SSH session to the out-of-band management IP interface of any of the APIC nodes. From this prompt, execute the "version" command to obtain a consolidated list of node hostnames.

Procedure

Step 1	SSH to an APIC in the fabric. `# ssh admin@node_name`
Step 2	Look for the switches that the APIC knows about: `apic1# show switch ID Address In-Band Address OOB Address Version Flags Serial Number Name --- ----------- --------------- -------------- ------------ ----- ------------- ------ 101 10.0.136.64 192.168.1.14 10.122.254.241 n9000-11.2(1 aliv ABC1234DEF5 Leaf-1 k) ...`
Step 3	Connect to a switch: `apic1# ssh admin@Leaf-1`
Step 4	Check the NTP peer status: `Leaf-1# show ntp peer-status Total peers : 1 * - selected for sync, + - peer mode(active), - - peer mode(passive), = - polled in client mode remote local st poll reach delay vrf ----------------------------------------------------------------------------- 192.168.129.235 0.0.0.0 3 64 377 0.00142 management` A reachable NTP server has its IP address prefixed by an asterisk (), and the delay is a non-zero value.
Step 5	Repeat steps 3 and 4 for each node on the fabric.

Verifying that the NTP Policy is Deployed on Each Fabric Switch Using the Object Model CLI

Procedure

Step 1	SSH to an APIC in the fabric. `# ssh admin@node_name`
Step 2	Switch to the object model CLI: `apic1# bash admin@apic1:~>`
Step 3	Press the Tab key twice after the entering the attach command to list all of the available node names: `admin@apic1:~> attach <Tab> <Tab> Leaf-1 Node name Leaf-2 Node name Spine-1 Node name apic-1 Node name apic-2 Node name apic-3 Node name`
Step 4	Log in to one of the nodes using the same password that you used to access the APIC: `admin@apic1:~> attach Leaf-1 # Executing command: ssh Fab2-Leaf1 ...`
Step 5	Check the NTP peer status: `Leaf-1# show ntp peer-status Total peers : 1 * - selected for sync, + - peer mode(active), - - peer mode(passive), = - polled in client mode remote local st poll reach delay vrf ----------------------------------------------------------------------------- 192.168.129.235 0.0.0.0 3 64 377 0.00142 management` A reachable NTP server has its IP address prefixed by an asterisk (), and the delay is a non-zero value.
Step 6	Repeat steps 3 and 4 for each node on the fabric.

Verifying that the NTP Policy is Deployed on Each APIC Using the NX-OS-Style CLI

You can use the NX-OS-style CLI to verify that the policy has been successfully deployed on each Application Policy Infrastructure Controller (APIC).

Procedure

Step 1

SSH to an APIC in the fabric.

# ssh admin@node_name

Step 2

Execute the show ntpq command to obtain a list of NTP servers and their statuses:

apic1# show ntpq
 nodeid   remote         refid     st    t   when   poll   reach    delay   offset   jitter
 ------ - -------------  --------  ----  --  -----  -----  -------  ------  -------  -------
 1      * 192.168.38.65  .GPS.     u     27  64     377    76.427   0.087   0.067
 2      * 192.168.38.66  .GPS.     u     3   64     377    75.932   0.001   0.021

Verifying that the NTP Policy is Deployed on Each APIC Using the Object Model CLI

You can use the object model CLI to verify that the policy has been successfully deployed on each APIC.

Procedure

Step 1

SSH to an APIC in the fabric.

# ssh admin@node_name

Step 2

Switch to the object model CLI:

apic1# bash
admin@apic1:~>

Step 3

Execute the ntpq -p command to obtain a list of NTP servers and their status:

admin@apic1:~> ntpq -p
remote          	refid  	      st t when poll reach delay offset jitter
=======================================================================
*adc-mtv5-c1-1.c 192.168.1.5   3  u 58   64   377	  1.712 6.180  5.170

Use the man ntpq command on the APIC to see additional commands.

Domain Name Services (DNS)

Setting up a DNS server allows the APIC to resolve various hostnames to IP addresses. This is useful when integrating VMM domains or other Layer 4 to Layer 7 devices and the hostname is referenced.

Verifying DNS Operation Using the Object Model CLI

Procedure

Step 1	SSH to an APIC in the fabric. `# ssh admin@node_name`
Step 2	Switch to the object model CLI: `apic1# bash admin@apic1:~>`
Step 3	Check the resolv.conf file: `admin@apic1:~> cat /etc/resolv.conf # Generated by IFC search acme.com nameserver 192.168.168.183 nameserver 192.168.131.10`
Step 4	Ping a host by DNS name that will be reachable from the APIC out-of-band management: `admin@apic1:~> ping acme.com PING acme.com (192.168.4.161) 56(84) bytes of data. 64 bytes from www.acme.com (192.168.4.161): icmp_seq=1 ttl=241 time=42.7 ms 64 bytes from www.acme.com (192.168.4.161): icmp_seq=2 ttl=241 time=42.4 ms 64 bytes from www.acme.com (192.168.4.161): icmp_seq=3 ttl=241 time=43.9 ms ^C --- acme.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2102ms rtt min/avg/max/mdev = 42.485/43.038/43.903/0.619 ms admin@apic1:~>`

Viewing Control Plane Policing Using the NX-OS-Style CLI

You can use the show system internal aclqos brcm copp entries unit 0 command to view the control plane policing for the protocols that are listed on a leaf or spine switch. The output from the command helps you to understand the default behavior of the switch and to monitor switch performance issues due to unnecessary control plane load. You can use this command for ad hoc monitoring of these parameters to find any discrepancies in network behavior.

The following example shows output from the command:

module-1# show system internal aclqos brcm copp entries unit 0
Protocol  CPUQ  Entry-ID  Priority  Counter-ID  Rate  Burst  GreenPkts
OSPF      1     603       0         603         2000  2000   2584133
EIGRP     30    575       0         575         2000  2000   0

GreenBytes  RedPkts  RedBytes
373659784   0        0
0           0        0

Role-Based Access Control

Role-based access control (RBAC) and tenancy are important concepts to master when operating a Cisco Application Centric Infrastructure (ACI) fabric. Role-based access and the concept of tenancy are two core foundations upon which the ACI management and policy models are built.

In an ACI fabric, the Cisco Application Policy Infrastructure Controller (APIC) grants access to all objects based on a user's established role in the configuration. Each user can be assigned to a set of roles, a privilege type, and a security domain. Think of this in terms of Who, What, and Where. The role is the Who (logical collection of privileges), privileges define What functions a user can perform, and the security domain defines Where the user can perform these actions. When combining these objects, you can implement very granular access control in the system.

The role classification is an established grouping of permissions. For example, a fabric-admin can have access to the entire fabric as well as to assigning other user roles and associate them to security domains, whereas a tenant-admin can only have access to the components within the tenant to which they're associated, and is unable to manage other user roles at a fabric wide level. ACME's IT organization fits perfectly into this access control model.

The APIC provides access according to a user's role through RBAC. An ACI fabric user is associated with the following:

A set of roles
For each role, privileges and privilege types (which can be "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

Figure 1. Authenticated user creation lifecycle

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 flag. This flag is set by the APIC on all objects that correspond to equipment in the physical fabric.

APIC policies manage the access, authentication, and accounting (AAA) functions of the Cisco ACI fabric. The combination of user privileges, roles, and security domains with access rights inheritance enables administrators to configure AAA functions at the managed object level in a very granular fashion. These configurations can be implemented using the REST API, CLI, or GUI.

Multiple Tenant Support

A core APIC internal data access control system provides multi-tenant 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.

If a virtual machine management (VMM) domain is tagged with a security domain, the users contained in the security domain can access the corresponding 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.

Viewing the User Roles Using the GUI

You can view the built-in user roles as well as create custom roles to meet specific requirements.

On the menu bar, choose Admin > AAA.
In the Navigation pane, choose Security Management Roles. From here, you can see each built-in role and the associated privileges. Additionally, you can create a custom role from the Actions menu.

Security Domains

The security domain concept is crucial to proper operation of the ACI fabric. By using security domains, users can be organized into various permission structures, most commonly applied to tenants. Using the tenancy capabilities of the ACI fabric in conjunction with properly configured security domains, it will be possible to completely separate configuration of application workloads while only providing access to those who need it.

A key concept to keep in mind when configuring security domains is that the configuration only applies at a tenant level. The policies cannot currently be applied to individual objects despite references at the object level inside of the RBAC screen in the APIC.

Cisco recommends that you configure security domains and access levels prior to deployment of tenants. Cisco does not recommend that you provide user access configuration by modifing permissions of the "all" domain. Changes in the "all" domain will affect access permissions for all users. If you need to make selective changes to allow access outside of a user's security domain, be sure to set up a discrete user access policy just for that communication.

Creating a Security Domain Using the GUI

There are three security domains that are provisioned by default on the ACI fabric: "all", "common", and "mgmt". The "all" security domain usually includes access to everything within the management information tree (MIT). "Common" is usually used when there is a need for shared resources between tenants, such as DNS or directory services. The "mgmt" security domain is for management traffic policies. You can add security domains as necessary. For example, for a multi-tenant environment, a security domain would be created for each tenant. Users are then created and assigned to certain security domains, or tenants.

For more information about the MIT, see the document at the following URL:

http://www.cisco.com/c/en/us/products/collateral/cloud-systems-management/aci-fabric-controller/white-paper-c11-729586.html

To create a security domain:

On the menu bar, choose Admin > AAA.
In the Navigation pane, choose Security Management > Security Management.
In the Work pane, choose Actions > Create a Security Domain.
In the Create a Security Domain dialog box, perform the following actions:
1. Give the security domain a name and an optional description.

Adding Users Using the GUI

You might need to add new users within the ACI fabric. ACI can have local users manually entered by an admin, or use something such as LDAP, RADIUS, Active Directory, or TACACS+ to specify users that will be allowed to manage certai,n parts of the ACI network.

Configure Local Users:

On the menu bar, choose Admin > AAA.
In the Navigation pane, choose AAA Authentication.
In the Work pane, in the Realm drop-down list, choose Local and click Submit if Local is not already chosen.
In the Navigation pane, choose Security Management.
In the Work pane, choose Actions > Create Local User.
In the Create Local User dialog box, perform the following actions:
1. Specify any security information that is necessary and click Next.
2. Select the roles to be given to this user, such as Read/Write for admin or tenant admin, and click Next.
3. Specify login information for the user.
Click Finish.

Import and Export Policies

All of the stakeholders at ACME involved in the deployment and administration of the new mobile application platform need to know that they will be able to easily recover from any loss of configuration quickly and easily. Since all APIC policies and configuration data can be exported to create backups and tech support files for Disaster Recovery, troubleshooting, and offline analysis, ACI is a good choice on this front as well. As with all things APIC, a policy needs to be configured to export or backup the configuration policies. This can be done from any active and fully fit APIC within the ACI fabric. The backup and restore process does not require backup of individual components.

Backups are configurable through an export policy that allows either scheduled or immediate backups to a remote server (preferred) or, in the case where an external SCP/FTP server is not available, backups to be written to the local APIC file system.

Backup/export policies can be configured to be run on-demand or based on a recurring schedule. Cisco recommends that a current Backup be performed before making any major system configuration changes or applying software updates. Configuration Import policies (policy restore) will be discussed later in this section.

By default, all policies and tenants are backed up, but the administrator can optionally specify only a specific subtree of the management information tree. This is useful in multi-tenant deployments where individual tenants wish to backup or restore their respective policies.

Another Export policy required on occasion is for gathering technical support information. If issues are encountered within the system, you might need to contact the Cisco Technical Assistance Center (TAC). Providing a technical support bundle will give Cisco support engineers the information needed to help identify and suggest remediation to issues. Technical support export policies can be configured to run on-demand or scheduled for recurring purposes. Technical support bundles are configured very similar to configuration export policies, and so the bundles will not be covered in detail here. For details on technical support export policies, see the Cisco APIC Troubleshooting Guide that is referenced in the Appendix of this book.

Configuration Export (Backup)

Since ACI is policy driven, more than a backup job is required. First, a remote location is created (the external server to which you want to export information), then an Export policy task, and optionally a Scheduler (for recurring tasks). The procedure below details how to create a remote location and export policy in ACI to transfer the configuration file bundle to an SCP server. The individual XML files can be extracted and viewed after the configuration bundle is transferred to the desktop. An extraction utility is needed to decompress the tar.gz file that is created.

Adding a Remote Location (SCP) Using the GUI

On the menu bar, choose Admin > Import/Export.
In the Navigation pane, choose Remote Locations.
In the Work pane, choose Actions > Create Remote Location.
In the Create Remote Location dialog box, perform the following actions:
1. Enter a remote location name.
2. Enter a hostname/IP address.
3. Choose a protocol.
4. Enter a remote path.
5. Enter a remote port.
6. Enter a username.
7. Enter a password.
8. Choose a management EPG. The default is Out-of-Band.
Click Submit.

Creating a One Time Export Policy Using the GUI

The procedure below details a configuration export policy, but the procedure for a technical support export policy is similar.

On the menu bar, choose Admin > Import/Export.
In the Navigation pane, choose Export Policies > Configuration.
In the Work pane, choose Actions > Create Configuration Export Policy.
In the Create Configuration Export Policy dialog box, perform the following actions:
1. Name = Export_Policy_Name
2. Format = XML
3. Start Now = Yes
4. Export Destination = Choose_the_Remote_location_created_above
Click Submit.

Two optional configurations are applying a scheduler policy if you want to setup a recurring operation, and specifying a specific Distinguished Name (DN) if you want to backup only a subset of the Management Information Tree (MIT).

Verifing That Exporting a Policy was Successful Using the GUI

On the menu bar, choose Admin > Import/Export.
In the Navigation pane, choose Export Policies > Configuration > Export_Name.
In the Work pane, choose the Operational tab.
1. The State should change from "pending" to "success" when the export completes correctly.
2. (Optional) Confirm on the SCP server that the backup filename exists.

Extracting and Viewing Configuration Files Using the GUI

A configuration export task exports a compressed bundle of individual XML files. These XML configuration files can be extracted and viewed on another workstation.

From the workstation where the exported bundle has been copied, select the archive utility of choice.
Navigate to the folder where the config export is located (tar.gz), highlight the file, and then select Extract.
Double-click one of the XML files to view the contents in a browser.
Examine the various XML configuration files for parameters that have been configured.

Importing a Configuration (Restoring/Merging) Using the GUI

You must have a remote location to import a configuration. If the remote location does not exist, create a remote location as per the "Adding a Remote Location (SCP)" section.

To restore a configuration from a previous backup:

On the menu bar, choose Admin > Import/Export.
In the Navigation pane, choose Import Policies > Configuration.
In the Work pane, choose Actions > Create Import Configuration Policy.
In the Create Import Configuration Policy dialog box, perform the following actions:
1. Enter a name and the filename for the import policy, such as "backup-file.tar.gz". Do not include the file path.
2. Choose the import type:
  - Merge - Will merge backup configuration with existing running configurations. Will not overrite any existing policies.
  - Replace - Will replace all configurations with those only from the backup file.
3. The import mode must be specified when you attempt to perform a Merge import. The configuration data is imported per shard with each shard holding a certain part of the system configuration objects. The default is best-effort. The Replace Import Mode can be either:
  - best-effort - Each shard is imported, skipping any invalid objects.
  - atomic - Attempts to import each shard, skipping those which contain an invalid configuration. A shard's entire configuration must be valid to be imported in this mode.
4. Choose Start Now.
5. Choose the Remote Location that was previously created in the "Adding a Remote Location (SCP)" section.

Rolling Back a Configuration Using the GUI

You can take a configuration snapshot of the APIC. This allows for faster rollback of any unwanted configuration changes. The configuration rollback can be manual or set as a recurring policy. The difference between a configuration export and configuration rollback is that configuration rollbacks can remain on the APIC. Configuration exports require an external location, such as an SCP/FTP/SFTP server. Configuration snapshots can be taken at the fabric or tenant level.

ACME Inc. has decide to configure a daily fabric-wide snapshot of their configuration as a protective measure in addition to their daily configuration export policy.

Procedure

Step 1	On the menu bar, choose Admin > Config Rollbacks.
Step 2	In the Work pane, click the recurring snapshot policy icon along the top right.
Step 3	In the Automatic Snapshot dialog box, ensure the policy is enabled. Click to toggle Enable/Disable.
Step 4	In the Automatic Snapshot dialog box, select the Days of the Week and Time for the recurring snapshot to run. By default, the snapshots will remain stored on the APICs.
Step 5	(Optional) If you prefer for the snapshots be saved to a remote location, you can choose the Remote Location, or create a new one.
Step 6	Click Submit to save your changes.

Operating Cisco Application Centric Infrastructure

Results

Chapter: Management

Management

APIC Overview

Configuring Management Protocols

Creating a Cisco Discovery Protocol Policy Using the GUI

Creating a Link Layer Discovery Protocol Policy Using the GUI

Time Synchronization and NTP

Configuring Out-of-Band Management NTP Using the GUI

Configuring Out-of-Band Management NTP Using the NX-OS-Style CLI

Procedure

In-Band Management NTP

Verifying NTP Operation Using the GUI

Verifying the NTP Policy Configuration Using the NX-OS-Style CLI

Procedure

Verifying that the NTP Policy is Deployed on Each Fabric Switch Using the NX-OS-Style CLI

Procedure

Verifying that the NTP Policy is Deployed on Each Fabric Switch Using the Object Model CLI

Procedure

Verifying that the NTP Policy is Deployed on Each APIC Using the NX-OS-Style CLI

Procedure

Verifying that the NTP Policy is Deployed on Each APIC Using the Object Model CLI

Procedure

Domain Name Services (DNS)

Verifying DNS Operation Using the Object Model CLI

Procedure

Viewing Control Plane Policing Using the NX-OS-Style CLI

Role-Based Access Control

Multiple Tenant Support

Viewing the User Roles Using the GUI

Security Domains

Creating a Security Domain Using the GUI

Adding Users Using the GUI

Import and Export Policies

Configuration Export (Backup)

Adding a Remote Location (SCP) Using the GUI

Creating a One Time Export Policy Using the GUI

Verifing That Exporting a Policy was Successful Using the GUI

Extracting and Viewing Configuration Files Using the GUI

Importing a Configuration (Restoring/Merging) Using the GUI

Rolling Back a Configuration Using the GUI

Procedure

Was this Document Helpful?

Contact Cisco

Related Cisco Community Discussions