B APIC NXOS CLI User Guide
B APIC NXOS CLI User Guide
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of
the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network
topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional
and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: 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. (1721R)
© 2015–2019 Cisco Systems, Inc. All rights reserved.
Please send general FSF & GNU inquiries to [email protected]. There are also other ways to contact the FSF. Please send broken links and other corrections or suggestions to [email protected].
Please see the Translations README for information on coordinating and submitting translations of this article.
Copyright © 2007, 2009, 2011 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided
this notice, and the copyright notice, are preserved. Updated: Date: 2011/06/28 02:44:32
© 2015–2019 Cisco Systems, Inc. All rights reserved.
CONTENTS
Pre-Registration Verifications 36
Verification Checklist for CSSM Configurations 36
Verification Checklist for Smart Licensing and APIC Configurations 36
Registering for Smart Licensing Using the CLI 36
Configuring FC Connectivity Without Policies or Profiles Using the NX-OS CLI 104
Configuring FC Connectivity With Policies or Profiles Using the NX-OS CLI 106
Configuring 802.1Q Tunnels 108
About ACI 802.1Q Tunnels 108
Configuring 802.1Q Tunnels Using the NX-OS Style CLI 110
Example: Configuring an 802.1Q Tunnel Using Ports with the NX-OS Style CLI 111
Example: Configuring an 802.1Q Tunnel Using Port-Channels with the NX-OS Style CLI 112
Example: Configuring an 802.1Q Tunnel Using Virtual Port-Channels with the NX-OS Style
CLI 113
Configuring Dynamic Breakout Ports 113
Configuration of Dynamic Breakout Ports 113
Configuring Dynamic Breakout Ports Using the NX-OS Style CLI 114
Configuring Port Profiles 118
Configuring Port Profiles 118
Port Profile Configuration Summary 120
Configuring a Port Profile Using the NX-OS Style CLI 122
Verifying Port Profile Configuration and Conversion Using the NX-OS Style CLI 123
Microsegmentation on Virtual Switches 124
Configuring Microsegmentation on Virtual Switches 124
Configuring Microsegmentation with Cisco ACI Using the NX-OS-Style CLI 125
Configuring Microsegmentation on Bare-Metal 127
Configuring Shared Layer 3 Out Inter-VRF Leaking Using the NX-OS Style CLI - Implicit Example
183
Configuration Tasks to Configure Cisco ACI GOLF Services Using the NX-OS Style CLI 296
Configuring a Spine and the Infra Tenant for BGP EVPN, Using the NX-OS Style CLI 296
APIC GOLF Connections Shared by Multi-Site Sites 299
Recommended Shared GOLF Configuration Using the NX-OS Style CLI 300
Configuring BGP to Support BGP EVPN on a Spine, Using the NX-OS Style CLI 301
Configuring a Tenant for BGP EVPN Using the NX-OS Style CLI 302
Configuring a Route Map 304
Enabling Distributing BGP EVPN Type-2 Host Routes to a DCIG Using the NX-OS Style CLI 306
Cisco ACI GOLF Configuration Example, Using the NX-OS Style CLI 307
Troubleshooting EVPN Type-2 Route Distribution to a DCIG 309
Multipod_Fabric 311
About Multipod Fabric 311
Assigning Switches in a Multipod Fabric 311
Configuring Fabric-External Connectivity for a Multipod Fabric 312
Configuring Spine Interfaces and OSPF for a Multipod Fabric 315
Remote Leaf Switches 318
About Remote Leaf Switches in the ACI Fabric 318
Remote Leaf Switch Hardware Requirements 319
Restrictions and Limitations 320
WAN Router and Remote Leaf Switch Configuration Guidelines 321
Configure Remote Leaf Switches Using the NX-OS Style CLI 322
Transit Routing 325
Transit Routing in the ACI Fabric 325
Transit Routing Related Topics 326
Transit Routing Overview 326
Guidelines for Transit Routing 328
Configure Transit Routing Using the NX-OS Style CLI 333
Example: Transit Routing 336
Overview 447
Configuring Cisco Tetration Analytics Using the NX-OS Style CLI 447
Configuring a NetFlow Exporter Policy for Virtual Machine Networking Using the NX-OS-Style CLI
452
Configuring NetFlow and Tetration Analytics Feature Priority Through Node Control Policy Using
NX-OS-Style CLI 452
Configuring NetFlow Node Policy Using the NX-OS-Style CLI 453
Configuring NetFlow Infra Selectors Using the NX-OS-Style CLI 453
Configuring NetFlow Overrides Using the NX-OS-Style CLI 456
Configuring NetFlow Tenant Hierarchy Using the NX-OS-Style CLI 456
Consuming a NetFlow Exporter Policy Under a VMM Domain Using the NX-OS-Style CLI for VMware
VDS 460
Enabling or Disabling NetFlow on an Endpoint Group Using the NX-OS-Style CLI for VMware
VDS 460
CHAPTER 21 Applying the show running config Output to Another Cisco APIC 517
About Import and Export Configurations 517
Import and Export Configuration Guidelines and Limitations 517
Audience
This guide is intended for network and systems administrators who configure and maintain the Application
Centric Infrastructure fabric.
Smart Licensing Smart Licensing is enabled in the Cisco ACI Smart Licensing, on
Cisco ACI fabric and by extension page 35
in the Cisco APIC as a Cisco Smart
Licensing-enabled product.
Layer 3 Routed and Sub-Interface Support for layer 3 port channels is #unique_7
Port Channels added.
Fibre Channel NPV Support for FC traffic over the Configuring Layer 2 External
Fabric. Connectivity, on page 75
Rogue Endpoint Control Support is added for global Rogue Configuring Global Policies, on
Endpoint Detection, to detect page 419
unauthorized EPs.
Enhanced Port Profile Support on Support is added on the Configuring Layer 2 External
N9K-C93180YC-FX Switches N9K-C93180YC-FX switch for Connectivity, on page 75
port profiles to change ports from
uplink to downlink or downlink to
uplink.
Enhanced Breakout Support on Support is added for 100 Gigabit Configuring Layer 2 External
Profiled QSFP Ports on (Gb) (4X25Gb) and 40Gb Connectivity, on page 75
N9K-C93180YC-FX Switches (4X10Gb) dynamic breakouts on
profiled QSFP ports on the
N9K-C93180YC-FX switch (in
ACI mode).
Contract and Subject Exceptions Contracts between EPGs are Configuring Tenants, on page 41
enhanced to include exceptions to
subjects or contracts. This enables
a subset of EPGs to be excluded in
contract filtering. For example, a
provider EPG can communicate
with all consumer EPGs except
those that match criteria configured
in a Subject Exception in the
contract governing their
communication.
Mixing the NX-OS style CLI and Cautions are added about mixing Using the APIC CLI, on page 1
the APIC GUI the two interfaces to configure the
fabric.
Forwarding Scale Profile Policy The High LPM scale option is Configuring a Forwarding Scale
added to the forwarding scale Profile Policy, on page 521
profile policy. High longest prefix
match (LPM) provides scalability
similar to the dual-stack policy,
except that the LPM scale is
128,000 and the policy scale is
8,000.
Scale improvements in the other
forwarding scale options are also
added in this release.
QoS for L3Out QoS policy enforcement on L3Out Configuring Cisco ACI QoS
ingress traffic is enhanced. To
configure QoS policies in an
L3Out, the VRF must be set in
egress mode (Policy Control
Enforcement Direction = “egress”)
with policy control enabled (Policy
Control Enforcement Preference =
“Enforced”). You must configure
the QoS class priority or DSCP
setting in the contract that governs
the Layer 3 External network.
Neighbor Discovery Router RS/RA packets are used for auto Configuring Layer 3 External
Advertisement on Layer 3 Out configuration and are configurable Connectivity
on Layer 3 interfaces including
routed interface, Layer 3 sub
interface, and SVI.
Configuring Flood in Encapsulation Beginning with Cisco ACI Release Configuring Flood in
3.1(1) on the Cisco ACI switches Encapsulation
with the Application Spine Engine
(ASE), all protocols are flooded in
encapsulation. Multiple EPGs are
now supported under one bridge
domain with an external switch.
When two EPGs share the same BD
and the Flood in Encapsulation
option is turned on, the EPG
flooding traffic does not reach the
other EPG. It overcomes the
challenges of using the Cisco ACI
switches with the Virtual Connect
(VC) tunnel network.
CoPP per interface per protocol Support for configuring CoPP on a Configuring Control Plane Policing
per interface per protocol basis.
Remote Leaf Switches With an ACI fabric deployed, you Remote Leaf Switches in
can extend ACI services and APIC Configuring Layer 3 External
management to remote datacenters Connectivity
with Cisco ACI leaf switches that
have no local spine switch or APIC
attached.
New Hardware Support for Multipod and GOLF are supported Cisco ACI GOLF and Multipod
Multipod and GOLF by all Cisco Nexus 9300 platform Fabric in Configuring Layer 3
ACI-mode switches and all of the External Connections
Cisco Nexus 9500 platform
ACI-mode switch line cards and
fabric modules. With Cisco APIC,
release 3.1(x) and higher, this
includes the N9K-C9364C switch.
Using Shared GOLF Connections Guidelines were added to avoid Cisco ACI GOLF in Configuring
Between Multi-Site Sites inter-VRF traffic issues for APIC Layer 3 External Connections
Sites in a Multi-Site topology, if
stretched VRFs share GOLF
connections.
SVI Auto State Allows for the SVI auto state in Configuring Layer 3 External
Switch Virtual Interface behavior Connectivity
to be enabled. This allows the SVI
state to be in the down state when
all the ports in the VLAN go down.
This feature is available in the
APIC Release 2.2(3x) release and
going forward with APIC Release
3.1(1). It is not supported in APIC
Release 3.0(x).
BFD support for spine switch Support for Bidirectional Configuring Bi-Directional Route
Forwarding Detection (BFD) spine Forwarding (BFD)
switch is added.
SNMP Trap Aggregation Enables SNMP traps from the Configuring SNMP
SNMP Trap Aggregation fabric
nodes to be delivered to one of the
APICs in the cluster.
Note The APIC Release 2.2(3x) feature is only available in this specific release. It is not supported in APIC Release
3.0(x) or Release 3.1(x).
SVI Auto State Allows for the SVI auto state in Configuring Layer 3 External
Switch Virtual Interface behavior Connectivity
to be enabled. This allows the SVI
state to be in the down state when
all the ports in the VLAN go down.
Forwarding Scale Profile Policy The forwarding scale profile policy Configuring a Forwarding Scale
enables you to choose between Profile Policy
Dual Stack (the default profile) and
IPv4 Scale. A forwarding scale
profile policy that is set to Dual
Stack provides scalability of up to
6K endpoints for IPv6
configurations and up to 12K
endpoints for IPv4 configurations.
The IPv4 Scale option enables
systems with no IPv6
configurations to increase
scalability with up to 24K IPv4
endpoints.
Graceful Insertion and Removal The Graceful Insertion and Removing a Switch to Maintenance
(GIR) Mode Removal (GIR) mode or Mode Using the CLI
maintenance mode allows you to
isolate a switch from the network
with minimum service disruption.
Q-in-Q Encapsulation Mapping for Using Cisco APIC, you can map Configuring Q-in-Q Encapsulation
EPGs double-tagged VLAN traffic Mapping for EPGs in Configuring
ingressing on a regular interface, Layer 2 External Connectivity
PC, or VPC to an EPG. When this
feature is enabled, when
double-tagged traffic enters the
network for an EPG, both tags are
processed individually in the fabric
and restored to double-tags when
egressing the ACI switch.
Ingressing single-tagged and
untagged traffic is dropped.
802.1x Port Authentication With this release, you can configure Configuring 802.1x Port
an 802.1x Port Authentication Authentication Policy and
policy or 802.1x Node Configuring 802.1x Node
Authentication Policy. Authentication Policy in
Configuring Layer 2 Connectivity
First Hop Security Enables better IPv4 and IPv6 link Configuring First Hop Security in
security and management over the Configuring Security
layer 2 links.
Cisco APIC Quota Management Creates, deletes, and updates a Creating Quota Management
quota management configuration
which enables the admin to limit
what managed objects that can be
added under a given tenant or
globally across tenants.
802.1Q Tunnel Enhancements Now you can configure ports on Configuring Layer 2 External
core-switches for use in Dot1q Connectivity
Tunnels for multiple customers.
You can also define access VLANs
to distinguish between customers
consuming the corePorts. You can
also disable MAC learning on
Dot1q Tunnels.
Control Plane Policing Protects the control plane and Configuring Security
separates it from the data plane,
which ensures network stability,
reachability, and packet delivery.
Encapsulation scope for SVI across With this release you can configure See Configuring Layer 3 External
Layer 3 Outside networks the encapsulation scope for SVI Connectivity
across Layer 3 Outside networks.
Reflective relay (802.1Qbg) Reflective relay transfers switching See Configuring Fabric and
for virtual machines out of the host Interfaces
server to an external network
switch. It provides connectivity
between VMs on the same physical
server and the rest of the network.
It allows policies that you configure
on the Cisco APIC to apply to
traffic between the VMs on the
same server.
Table 7: New Features and Changed Behavior in Cisco APIC 2.2(2e) Release
Per VRF per node BGP timer With this release, you can define Configuring Layer 3 External
and associate BGP timers on a per Connectivity
VRF per node basis.
Layer 3 Out to Layer 3 Out With this release, shared Layer 3 Configuring Layer 3 External
Inter-VRF Leaking Outs in different VRFs can Connectivity
communicate with each other using
a contract.
Multiple BGP communities With this release, multiple BGP Configuring Layer 3 External
assigned per route prefix communities can now be assigned Connectivity
per route prefix using the BGP
protocol.
Apply the show running config Two new CLI commands, export About Import and Export
command output to another Cisco config and import config, were Configurations in
APIC added to enable running the output
Applying the show running config
for the show running-config
Output to Another Cisco APIC
command on another Cisco APIC.
Name change Changed name of "Layer 3 EVPN Cisco ACI GOLF and Multipod in
Services for Fabric WAN" to Configuring Layer 3 External
"Cisco ACI GOLF Connectivity
Table 8: New Features and Changed Behavior in Cisco APIC 2.2(1n) Release
802.1Q Tunnels You can configure 802.1Q tunnels Configuring 802.1Q Tunnels in
to enable point-to-multi-point Configuring Layer 2 External
tunneling of Ethernet frames in the Connectivity
fabric, with Quality of Service
(QoS) priority settings.
APIC Cluster High Availability Support is added to operate the APIC High Availability
APICs in a cluster in an
Active/Standby mode. In an APIC
cluster, the designated active APICs
share the load and the designated
standby APICs can act as an
replacement for any of the APICs
in an active cluster.
Contract Preferred Groups Support is added for contract Configuring Contract Preferred
preferred groups that enable greater Groups in Configuring Tenants
control of communication between
EPGs in a VRF. If most of the
EPGs in the VRF should have open
communication, but a few should
only have limited communication
with the other EPGs, you can
configure a combination of a
contract preferred group and
contracts with filters to control
communication precisely.
Dynamic Breakout Ports Support is added for connecting a Configuring Dynamic Breakout
40 Gigabit Ethernet (GE) leaf Ports in Configuring Layer 2
switch port to 4-10GE capable External Connectivity
(downlink) devices (with Cisco
40-Gigabit to 4X10-Gigabit
breakout cables).
FCoE over FEX You can now configure FCoE over Support Fibre Channel over
FEX ports. Ethernet Traffic on the ACI Fabric
CDP supported in policies on In this release, support is added for Configuring Fabric and Interfaces
interfaces to FEX devices CDP on interfaces to FEX devices.
Table 9: New Features and Changed Behavior in Cisco APIC 2.1(1h) Release
Creating a route map/profile using In this release, the explicit prefix Creating a Route Map
explicit prefix list using a new list is supported through a new
match type. match type that is called match
route destination.
Configure FIPS In this release, support for FIPS. Configuring FIPS for Cisco APIC
FIPS specifies certain
cryptographic algorithms as secure,
and it also identifies which
algorithms should be used for a
module to be FIPS compliant.
Distribute EVPN Type-2 Host In this release, for optimal traffic Enabling Distributing EVPN
Routes forwarding in an EVPN topology, Type-2 Host Routes Using the
you can enable fabric spines to NX-OS in Configuring Layer 3
advertise host routes using EVPN EVPN Services over Fabric WAN
type-2 (MAC-IP) routes to the
DCIG along with public BD
subnets in the form of BGP EVPN
type-5 (IP Prefix) routes.
Configure IGMP snoop layer 2 In this release, IGMP snoop support Enabling IGMP Snoop Static Port
multicast support is implemented which allows a Groups and Enabling IGMP Snoop
network switch to monitor IGMP Access Groups in Configuring
traffic and filter multicasts from Layer 2 IGMP Snoop Multicast
flooding layer 2 traffic. Among the
features implemented is static port
group configuration and access
group configuration.
Translating QoS CoS Settings In this release, you can enable the Translating QoS CoS Settings
ACI Fabric to classify the traffic Using the NX-OS CLI
for devices that classify the traffic
based only on the CoS value.
Table 10: New Features and Changed Behavior in Cisco APIC 2.0(2f) release
Proxy ARP Proxy ARP in Cisco ACI is added About Proxy ARP, on page 144
to enable endpoints within a
network or subnet to communicate
with other endpoints without
knowing the real MAC address of
the endpoints.
Multipod QoS Support for Preserving CoS and Preserving QoS Priority Settings in
DSCP settings is added for a Multipod Fabric
Multipod topologies.
Layer 3 EVPN Services Over More detail was added on how to Configuration Tasks to Configure
Fabric WAN configure Layer 3 EVPN services. Cisco ACI GOLF Services Using
the NX-OS Style CLI, on page 296
2.0(1) Layer 3 EVPN Services Over Fabric WAN Cisco ACI GOLF , on
page 294
2.0(1) Multipod Fabric About Multipod Fabric,
on page 311
2.0(1) Verified Scalability Using the CLI Verified Scalability Using
the CLI, on page 527
1.2(2) BFD About BFD, on page 234
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.
Convention Description
[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.
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.
Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the manual.
Caution Means reader be careful. In this situation, you might do something that could result in equipment damage or
loss of data.
Related Documentation
Cisco Application Centric Infrastructure (ACI) Documentation
The 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.
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.
Note From Cisco APIC Release 1.0 until Release 1.2, the default CLI was a Bash shell with commands to directly
operate on managed objects (MOs) and properties of the Management Information Model. Beginning with
Cisco APIC Release 1.2, the default CLI is a NX-OS style CLI. The object model CLI is available by typing
the bash command at the initial CLI prompt.
Procedure
Step 1 From a secure shell (SSH) client, open an SSH connection to APIC at username @ ip-address .
Use the administrator login name and the out-of-band management IP address that you configured during the
initial setup. For example, [email protected].
What to do next
When you enter the NX-OS style CLI, the initial command level is the EXEC level. From this level, you can
reach these configuration modes:
• To continue in the NX-OS style CLI, you can stay in EXEC mode or you can type configure to enter
global configuration mode.
For information about NX-OS style CLI commands, see the Cisco APIC NX-OS Style CLI Command
Reference.
• To reach the object model CLI, type bash .
For information about object mode CLI commands, see the Cisco APIC Command-Line Interface User
Guide, APIC Releases 1.0 and 1.1.
EXEC From the APIC prompt, enter To exit to the login prompt, use
apic#
execsh. the exit command.
apic1# configure
apic1(config)# dns
apic1(config-dns)# ?
address Configure the ip address for dns servers
domain Configure the domains for dns servers
exit Exit from current mode
fabric Show fabric related information
no Negate a command or set its defaults
show Show running system information
use-vrf Configure the management vrf for dns servers
where Show the current mode
apic1(config-dns)# end
apic1#
Each submode places you further down in the prompt hierarchy. To view the hierarchy for the current mode,
use the configure command, as shown in this example:
apic1# configure
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# where
configure t; bgp-fabric
apic1(config-bgp-fabric)#
To leave the current level and return to the previous level, type exit . To return directly to the EXEC level,
type end .
apic1(config-dns)# ?
address Configure the ip address for dns servers
domain Configure the domains for dns servers
exit Exit from current mode
fabric Show fabric related information
no Negate a command or set its defaults
show Show running system information
use-vrf Configure the management vrf for dns servers
where Show the current mode
apic1(config-dns)# end
apic1#
To see a list of commands that begin with a particular character sequence, type those characters followed by
a question mark (?). Do not include a space before the question mark.
apic1(config)# sh ?
aaa Show AAA information
access-list Show Access-list Information
accounting Show accounting information
acllog Show acllog information
. . .
apic1# qu<TAB>
apic1# quota
To list keywords or arguments, enter a question mark in place of a keyword or argument. Include a space
before the question mark. This form of help is called command syntax help because it reminds you which
keywords or arguments are applicable based on the commands, keywords, and arguments you have already
entered.
apic1(config-dns)# use-vrf ?
inband-mgmt Configure dns on inband
oob-mgmt Configure dns on out-of-band
apic1(config-dns)#
You can also abbreviate a command if the abbreviation is unambiguous. In this example, the configure
command is abbreviated.
apic1# conf
apic1(config)#
You can execute a bash command from any mode or submode in the NX-OS style CLI.
Caution Configurations done through the NX-OS style CLI are rendered in the APIC GUI. They can be seen, but
sometimes may not be editable in the GUI. Also changes made in the APIC GUI may be seen in the NX-OS
style CLI, but may only partially work. See the following examples:
• Do not mix the 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.
For the steps to remove such objects, see Troubleshooting Unwanted _ui_ Objects in the APIC Troubleshooting
Guide.
In either case, the configuration should be considered read-only in the incompatible UI.
• Implicit mode—the naming of the container is implicit and does not appear in the CLI commands. The
CLI creates and maintains these objects internally.
• Named mode—the naming is provided by the user. CLI commands in the Named Mode have an additional
l3Out field. To configure the named L3Out correctly and avoid faults, the user is expected to understand
the API object model for external Layer 3 configuration.
Note Except for the procedures in the Configuring Layer 3 External Connectivity Using the Named Mode section,
this guide describes Implicit mode procedures.
• Layer 3 external network objects (l3extOut) created using the Implicit mode CLI procedures are identified
by names starting with “__ui_” and are marked as read-only in the GUI. The CLI partitions these
external-l3 networks by function, such as interfaces, protocols, route-map, and EPG. Configuration
modifications performed through the REST API can break this structure, preventing further modification
through the CLI.
For the steps to remove such objects, see Troubleshooting Unwanted _ui_ Objects in the APIC Troubleshooting
Guide.
Note Configuring FEX connections with FEX IDs 165 to 199 is not supported in the APIC GUI. To use one of
these FEX IDs, configure the profile using the NX-OS style CLI. For more information, see Configuring FEX
Connections Using Interface Profiles with the NX-OS Style CLI.
As of Cisco APIC, Release 3.0(1k), connections to FEX modules can be configured as profiles.
FEX Port-channel interface port-channel name fex interface port-channel foo fex 101
fex-id
vPC over FEX interface vpc name fex fex-a fex-b interface vpc foo fex 101 102
Important Notes
• Upgrading or downgrading a switch in maintenance mode is not supported.
• While the switch is in maintenance mode, the Ethernet port module stops propagating the interface related
notifications. As a result, if the remote switch is rebooted or the fabric link is flapped during this time,
the fabric link will not come up afterward unless the switch is manually rebooted (using the acidiag
touch clean command), decommissioned, and recommissioned.
• For multi-pod, IS-IS metric for redistributed routes should be set to less than 63. To set the IS-IS
metric for redistributed routes, choose Fabric > Fabric Policies > Pod Policies > IS-IS Policy.
• Existing GIR supports all Layer 3 traffic diversion. With LACP, all the Layer 2 traffic is also diverted
to the redundant node. Once a node goes into maintenance mode, LACP running on the node immediately
informs neighbors that it can no longer be aggregated as part of port-channel. All traffic is then diverted
to the vPC peer node.
• For a GIR upgrade, Cisco Application Policy Infrastructure Controller (Cisco APIC)-connected leaf
switches must be put into different maintenance groups such that the Cisco APIC-connected leaf switches
get upgraded one at a time.
Procedure
Procedure
Procedure
Step 3 interface type Specifies the interface that you are configuring.
You can specify the interface type and identity.
Example:
For an Ethernet port, use “ethernet slot / port.”
apic1(config-leaf)# interface ethernet
1/2
The following table shows the interface settings that can be configured at this point.
Command Purpose
[no] lldp receive Set the LLDP receive for physical interface
Examples
Configure one port in a leaf node. The following example shows how to configure the interface
eth1/2 in leaf 101 for the following properties: speed, cdp, and admin state.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/2
apic1(config-leaf-if)# speed 10G
apic1(config-leaf-if)# cdp enable
apic1(config-leaf-if)# no shut
Configure multiple ports in multiple leaf nodes. The following example shows the configuration of
speed for interfaces eth1/1-10 for each of the leaf nodes 101-103.
Attach a FEX to a leaf node. The following example shows how to attach a FEX module to a leaf
node. Unlike in NX-OS, the leaf port Eth1/5 is implicitly configured as fabric port and a FEX fabric
port-channel is created internally with the FEX uplink port(s). In ACI, the FEX fabric port-channels
use default configuration and no user configuration is allowed.
Note This step is required before creating a port-channel using FEX ports, as described in the next example.
Configure FEX ports attached to leaf nodes. This example shows configuration of speed for interfaces
eth1/1-10 in FEX module 101 attached to each of the leaf nodes 102-103. The FEX ID 101 is included
in the port identifier. FEX IDs start with 101 and are local to a leaf.
• N+1 instances per leaf of port-channel foo are possible when each leaf is connected to N FEX nodes.
• Leaf ports and FEX ports cannot be part of the same port-channel instance.
• Each FEX node can have only one instance of port-channel foo.
Procedure
Step 3 [no] switchport access vlan vlan-id tenant Deploys the EPG with the VLAN on all ports
tenant-name application application-name epg with which the port-channel is associated.
epg-name
Example:
Step 9 (Optional) lacp port-priority priority This setting and other per-port LACP properties
can be applied to member ports of a
Example:
port-channel at this point.
apic1(config-leaf-if)# lacp port-priority
The following table shows various commands for global configurations of port channel properties in the ACI
model. These commands can also be used for configuring overrides for port channels in a specific leaf in the
(config-leaf-if) CLI mode. The configuration made on the port-channel is applied to all member ports.
[no] link debounce time <time> Set Link Debounce for port-channel
[no] channel-mode { active | passive | on| mac-pinning LACP mode for the link in port-channel l
}
[no] lacp fast-select-hot-standby LACP fast select for hot standby ports
Examples
Configure a port channel (global configuration). A logical entity foo is created that represents a
collection of policies with two configurations: speed and channel mode. More properties can be
configured as required.
Note The channel mode command is equivalent to the mode option in the channel group command in
NX-OS. In ACI, however, this supported for the port-channel (not on member port).
Configure ports to a port-channel in a FEX. In this example, port channel foo is assigned to ports
Ethernet 1/1-2 in FEX 101 attached to leaf node 102 to create an instance of port channel foo. The
leaf node will auto-generate a number, say 1002 to identify the port channel in the switch. This port
channel number would be unique to the leaf node 102 regardless of how many instance of port
channel foo are created.
Note The configuration to attach the FEX module to the leaf node must be done before creating port
channels using FEX ports.
In Leaf 102, this port channel interface can be referred to as interface port-channel foo FEX 101.
apic1(config)# leaf 102
apic1(config-leaf)# interface port-channel foo fex 101
apic1(config-leaf)# shut
Configure ports to a port channel in multiple leaf nodes. In this example, port channel foo is assigned
to ports Ethernet 1/1-2 in each of the leaf nodes 101-103. The leaf nodes will auto generate a number
unique in each node (which may be same or different among nodes) to represent the port-channel
interfaces.
apic1(config)# leaf 101-103
apic1(config-leaf)# interface ethernet 1/1-2
apic1(config-leaf-if)# channel-group foo
Add members to port channels. This example would add two members eth1/3-4 to the port-channel
in each leaf node, so that port-channel foo in each node would have members eth 1/1-4.
Remove members from port channels. This example would remove two members eth1/2, eth1/4 from
the port channel foo in each leaf node, so that port channel foo in each node would have members
eth 1/1, eth1/3.
apic1(config)# leaf 101-103
apic1(config-leaf)# interface eth 1/2,1/4
apic1(config-leaf-if)# no channel-group foo
Configure port-channel with different members in multiple leaf nodes. This example shows how to
use the same port-channel foo policies to create a port-channel interface in multiple leaf nodes with
different member ports in each leaf. The port-channel numbers in the leaf nodes may be same or
different for the same port-channel foo. In the CLI, however, the configuration will be referred as
interface port-channel foo. If the port-channel is configured for the FEX ports, it would be referred
to as interface port-channel foo fex <fex-id>.
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/1-2
apic1(config-leaf-if)# channel-group foo
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# leaf 102
apic1(config-leaf)# interface ethernet 1/3-4
apic1(config-leaf-if)# channel-group foo
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# leaf 103
apic1(config-leaf)# interface ethernet 1/5-8
apic1(config-leaf-if)# channel-group foo
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 101/1/1-2
apic1(config-leaf-if)# channel-group foo
Configure per port properties for LACP. This example shows how to configure member ports of a
port-channel for per-port properties for LACP.
Note In ACI model, these commands are allowed only after the ports are member of a port channel. If a
port is removed from a port channel, configuration of these per-port properties would be removed
as well.
Configure admin state for port channels. In this example, a port-channel foo is configured in each
of the leaf nodes 101-103 using the channel-group command. The admin state of port-channel(s) can
be configured in each leaf using the port-channel interface. In ACI model, the admin state of the
port-channel cannot be configured in the global scope.
Override config is very helpful to assign specific vlan-domain, for example, to the port-channel
interfaces in each leaf while sharing other properties.
// configure a port channel global config
apic1(config)# interface port-channel foo
apic1(config-if)# speed 1G
apic1(config-if)# channel-mode active
This example shows how to change port channel assignment for ports using the channel-group
command. There is no need to remove port channel membership before assigning to other port
channel.
apic1(config)# leaf 101-103
apic1(config-leaf)# interface ethernet 1/3-4
apic1(config-leaf-if)# channel-group foo
apic1(config-leaf-if)# channel-group bar
Note When creating a vPC domain between two leaf switches, both switches must be in the same switch generation,
one of the following:
• Generation 1 - Cisco Nexus N9K switches without “EX” on the end of the switch name; for example,
N9K-9312TX
• Generation 2 – Cisco Nexus N9K switches with “EX” on the end of the switch model name; for example,
N9K-93108TC-EX
Switches such as these two are not compatible vPC peers. Instead, use switches of the same generation.
The ACI model does not require a peer link and vPC configuration can be done globally for both the upstream
leaf nodes. A global configuration mode called vpc context is introduced in ACI and vPC interfaces are
represented using a type interface vpc that allows global configuration applicable to both leaf nodes.
Two different topologies are supported for vPC in the ACI model: vPC using leaf ports and vPC over FEX
ports. It is possible to create many vPC interfaces between a pair of leaf nodes and similarly, many vPC
interfaces can be created between a pair of FEX modules attached to the leaf node pairs in a straight-through
topology.
vPC considerations include:
• The vPC name used is unique between leaf node pairs. For example, only one vPC 'corp' can be created
per leaf pair (with or without FEX).
• Leaf ports and FEX ports cannot be part of the same vPC.
• Each FEX module can be part of only one instance of vPC corp.
• vPC context allows configuration
• The vPC context mode allows configuration of all vPCs for a given leaf pair. For vPC over FEX, the
fex-id pairs must be specified either for the vPC context or along with the vPC interface, as shown in
the following two alternative examples.
or
In the ACI model, vPC configuration is done in the following steps (as shown in the examples below).
Note A VLAN domain is required with a VLAN range. It must be associated with the port-channel template.
Procedure
Step 2 vlan-domain name[dynamic] [type Configures a VLAN domain for the virtual
domain-type] port-channel (here with a port-channel
template).
Example:
apic1(config)# vlan-domain dom1 dynamic
Step 4 vpc domain explicit domain-id leaf node-id1 Configures a vPC domain between a pair of
node-id2 leaf nodes. You can specify the vPC domain
ID in the explicit mode along with the leaf
Example:
node pairs.
apic1(config)# vpc domain explicit 1
leaf 101 102 Alternative commands to configure a vPC
domain are as follows:
• vpc domain [consecutive | reciprocal]
The consecutive and reciprocal options
allow auto configuration of a vPC domain
across all leaf nodes in the ACI fabric.
• vpc domain consecutive domain-start
leaf start-node end-node
This command configures a vPC domain
consecutively for a selected set of leaf
node pairs.
Step 5 peer-dead-interval interval Configures the time delay the Leaf switch
waits to restore the vPC before receiving a
Example:
response from the peer. If it does not receive
Step 8 vlan-domain member vlan-domain-name Associates the port channel template with the
previously configured VLAN domain.
Example:
vlan-domain member dom1
Step 9 switchport access vlan vlan-id tenant Deploys the EPG with the VLAN on all ports
tenant-name application application-name with which the port-channel is associated.
epg epg-name
Example:
apic1(config-po-ch-if)# switchport
access vlan 4 tenant ExampleCorp
application Web epg webEpg
Step 14 [no] channel-group channel-name vpc Assigns the interface or range of interfaces to
the port-channel. Use the keyword no to
Example:
remove the interface from the port-channel.
apic1(config-leaf-if)# channel-group To change the port-channel assignment on an
corp vpc
interface, you can enter the channel-group
command without first removing the interface
from the previous port-channel.
Note The vpc keyword in this command
makes the port-channel a vPC. If
the vPC does not already exist, a
vPC ID is automatically generated
and is applied to all member leaf
nodes.
Step 15 exit
Example:
apic1(config-leaf-if)# exit
Step 16 exit
Example:
apic1(config-leaf)# exit
Step 17 vpc context leaf node-id1 node-id2 The vPC context mode allows configuration
of vPC to be applied to both leaf node pairs.
Example:
apic1(config)# vpc context leaf 101
102
Example
This example shows how to configure a basic vPC.
apic1# configure
apic1(config)# vlan-domain dom1 dynamic
apic1(config-vpc)# exit
apic1(config)# template port-channel corp
apic1(config-po-ch-if)# vlan-domain member dom1
apic1(config-po-ch-if)# exit
apic1(config)# leaf 101-102
apic1(config-leaf)# interface ethernet 1/3-4
apic1(config-leaf-if)# channel-group corp vpc
apic1(config-leaf-if)# exit
apic1(config)# vpc context leaf 101 102
Note Configuring FEX connections with FEX IDs 165 to 199 is not supported in the APIC GUI. To use one of
these FEX IDs, configure the profile using the following commands.
Procedure
Step 4 fex associate fex-id [template template-type Attaches a FEX module to a leaf node. Use the
fex-template-name] optional template keyword to specify a template
to be used. If it does not exist, the system
Example:
creates a template with the name and type you
apic1(config-leaf-if-group)# fex specified.
associate 101
Example
This merged example configures a leaf interface profile for FEX connections with ID 101.
apic1# configure
apic1(config)# leaf-interface-profile fexIntProf1
apic1(config-leaf-if-profile)# leaf-interface-group leafIntGrp1
apic1(config-leaf-if-group)# fex associate 101
Cisco APIC Release 2.3(1) release does not support the IEE standard 802.1Qbg S-tagged approach with
multichannel technology.
• Physical domains.
Virtual domains are not supported.
• Physical ports, port channels (PCs), and virtual port channels (vPCs).
Cisco Fabric Extender (FEX) and blade servers are not supported. If reflective relay is enabled on an
unsupported interface, a fault is raised, and the last valid configuration is retained. Disabling reflective
relay on the port clears the fault.
• Cisco Nexus 9000 series switches with EX or FX at the end of their model name.
Procedure
Example:
This example enables reflective relay on multiple ports using a template:
apic1(config)# template policy-group grp1
apic1(config-pol-grp-if)# switchport vepa enabled
apic1(config-pol-grp-if)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/2-4
apic1(config-leaf-if)# policy-group grp1
Example:
This example enables reflective relay on a port channel:
apic1(config)# leaf 101
apic1(config-leaf)# interface port-channel po2
apic1(config-leaf-if)# switchport vepa enabled
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)#
Example:
This example enables reflective relay on multiple port channels:
apic1(config)# template port-channel po1
apic1(config-if)# switchport vepa enabled
apic1(config-if)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/3-4
apic1(config-leaf-if)# channel-group po1
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
Example:
This example enables reflective relay on a virtual port channel:
apic1(config)# vpc domain explicit 1 leaf 101 102
apic1(config-vpc)# exit
apic1(config)# template port-channel po4
apic1(config-if)# exit
apic1(config)# leaf 101-102
apic1(config-leaf)# interface eth 1/11-12
apic1(config-leaf-if)# channel-group po4 vpc
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# interface vpc po4
apic1(config-vpc-if)# switchport vepa enabled
Procedure
Step 2 template policy-group policy-group-name Creates a new policy group or edits an existing
policy group.
Example:
apic1(config)# template policy-group pg1
apic1(config-pol-grp-if)# switchport
access vlan 4 tenant ExampleCorp
application Web epg webEpg
Step 4 (Apply configuration commands) The table at the end of these steps shows various
commands for configurations of policy-group
Example:
for interfaces.
apic1(config-pol-grp-if)# speed 10G
apic1(config-pol-grp-if)# cdp enable
Step 8 [no] policy-group policy-group-name [force] Applies the policy-group to the interface or
range of interfaces. Use the keyword no to
Example:
remove the policy-group from the interface. Use
apic1(config-leaf-if)# policy-group pg1 the keyword force to delete any override
configurations on the interfaces.
If the specified policy-group was not configured
prior to this command, this command would
not implicitly create the policy-group. However,
the policy-group would take effect on the
interface after the policy-group has been
configured in the global scope.
To change the policy-group assignment on an
interface, you can enter the policy-group
command without first removing the previous
policy-group from the interface.
The following table shows various commands for configurations of policy-group for interfaces.
[no] link debounce time <time> Set link debounce for Physical Interface
[no] lldp transmit Set the LLDP transmit for Physical Interface
[no] lldp receive Set the LLDP receive for Physical Interface
Example
This example shows how to configure a policy-group and apply it to a range of ports in each of the
leaf nodes 101-103. Each of the ports sharing the policy-group in each leaf will have the same
configuration as defined in the policy-group pg1.
apic1# configure
apic1(config)# template policy-group pg1
apic1(config-pol-grp-if)# switchport access vlan 4 tenant ExampleCorp application Web epg
webEpg
apic1(config-pol-grp-if)# speed 10G
apic1(config-pol-grp-if)# cdp enable
apic1(config-pol-grp-if)# exit
apic1(config)# leaf 101-103
apic1(config-leaf)# interface ethernet 1/1-24
apic1(config-leaf-if)# policy-group pg1
Procedure
Examples
This example shows how to apply a policy-group and then override the speed configuration for port
eth1/1 in leaf node 101. In the ACI model, speed is part of a policy that also contains properties
autoneg and link debounce time. As a result, those properties are copied from the speed policy-group
when the override of pg1 is configured.
apic1# configure
apic1(config)# interface policy-group pg1
apic1(config-pol-grp-if)# speed 10G
apic1(config-pol-grp-if)# cdp enable
apic1(config-pol-grp-if)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/1-2
apic1(config-leaf-if)# policy-group pg1
apic1(config-pol-grp-if)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/1
apic1(config-leaf-if)# speed 1G
apic1(config-leaf-if)# show running-config
leaf 101
interface ethernet 1/1
policy-group pg1
speed 1G
autoneg on
link debounce time 100
This example shows how to remove the override configuration from port eth1/1 in leaf node 101.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/1
apic1(config-leaf-if)# policy-group pg1 force
apic1(config-leaf-if)# show running-config
leaf 101
interface ethernet 1/1
policy-group pg1
Note FEC is only configurable on the front port and not on fabric ports.
Step 3 Specify the interface and port. Specifies the interface and port.
Example:
apic1(config-leaf)# int eth 1/4
The following URLs provide you with additional information about Smart Licensing:
• The customer log in URL to access your CSSM account: https://software.cisco.com/
• Cisco Smart Accounts URL: https://www.cisco.com/c/en/us/products/software/smart-accounts.html
The following URLs are additional resources that you can refer:
• Training Materials and Resources
• Smart Accounts and Smart Licensing
Pre-Registration Verifications
Verification Checklist for CSSM Configurations
The following is a user checklist for readiness and configurations required with CSSM.
1. Verify that you have the appropriate Smart Account and Virtual Accounts created.
2. If you have purchased smart-enabled licenses from Cisco Commerce, then verify that your user-purchased
licenses are populated.
3. As you begin the APIC Smart Licensing registration, work with your Cisco TAC engineer to ensure that
you are ready with the appropriate CSSM items.
Procedure
Step 3 license smart register idtoken id token from Registers with the CSSM account using the
cssm account token from the account.
Example:
apic1(config)# license smart register
idtoken <id token from cssm account>
Registering for Smart Licensing with Transport Gateway Using the CLI
Procedure
Step 2 license smart transport-mode satellite url Configures the Transport Gateway mode and
http(s)://10.0.0.0:8080/Transportgateway/services/DeviceRequestHandler URL.
Example:
apic1(config)# license smart
transport-mode satellite url
http(s)://<ip address|hostname of
transport gateway>:<http(s)
port>/Transportgateway/services/DeviceRequestHandler
Step 3 license smart register idtoken id token from Registers with the CSSM using the token from
cssm account the CSSM Smart account or the CSSM Virtual
account.
Example:
apic1(config)# license smart register
idtoken <id token from cssm account>
Registering for Smart Licensing with Smart Software Manager Satellite Using the CLI
Procedure
Step 3 license smart register idtoken id token from Registers with the Satellite using the token from
smart software manager satellite the Smart Software Manager Satellite account.
Example: Note Note : Do not use the token from the
apic1(config)# license smart register CSSM account.
idtoken <id token from smart software
manager satellite>
Registering for Smart Licensing with HTTP or HTTPS Proxy Using the CLI
Procedure
Step 2 license smart transport-mode proxy Configures the proxy mode, the IP address or
ip-address ip address port port number hostname and the http(s) port.
Example:
apic1(config)# license smart
transport-mode proxy ip-address
10.0.0.248 port 4440
Step 3 license smart register idtoken id token from Registers with the CSSM account using the
cssm account token from the CSSM smart account or the
CSSM virtual account.
Example:
apic1(config)# license smart register
idtoken <id token from cssm account>
• After switching over a standby APIC to active, if it was the only standby, you must configure a new
standby.
• The following limitations are observed for retaining out of band address for standby APIC after a fail
over.
• Standby (new active) APIC may not retain its out of band address if more than 1 active APICs are
down or unavailable.
• Standby (new active) APIC may not retain its out of band address if it is in a different subnet than
active APIC. This limitation is only applicable for APIC release 2.x.
• Standby (new active) APIC may not retain its IPv6 out of band address. This limitation is not
applicable starting from APIC release 3.1x.
• Standby (new active) APIC may not retain its out of band address if you have configured non Static
OOB Management IP address policy for replacement (old active) APIC.
Note In case you observe any of the limitations, in order to retain standby APICs out
of band address, you must manually change the OOB policy for replaced APIC
after the replace operation is completed successfully.
• We recommend keeping standby APICs in same POD as the active APICs it may replace.
• There must be three active APICs in order to add a standby APIC.
• The standby APIC does not participate in policy configuration or management.
• No information is replicated to standby controllers, including admin credentials.
Procedure
Step 2 replace-controller reset ID number Resets fail over status of the active controller.
Example:
apic1# replace-controller reset 2
Do you want to reset failover status of
APIC 2? (Y/n): Y
Procedure
Step 2 tenant tenant-name Creates a tenant if it does not exist and enters
the tenant configuration mode.
Example:
apic1(config)# tenant exampleCorp
Step 4 [no] vrf context vrf-name Creates a private network (VRF) for the tenant.
A tenant can have one or more VRFs
Example:
configured.
apic1(config-tenant)# vrf context
exampleCorp_v1
Step 5 [no] contract {provider | consumer} Provide or consume contracts for all the EPGs
contract-name under the VRF.
Example:
apic1(config-tenant-vrf)# contract
provider web
Step 7 [no] bridge-domain bd-name Creates or deletes a bridge domain under the
tenant. Enters bridge domain configuration
Example:
mode.
apic1(config-tenant)# bridge-domain
exampleCorp_b1
Step 11 [no] {ip | ipv6} address address/mask-length Assigns or removes the gateway IP address of
[scope {private | public}] [secondary] the bridge domain and enters the IP address
mode to configure optional IP address
Example:
properties.
apic1(config-tenant-if)# ip address The scope of the gateway address can be one
172.1.1.1/24 of the following:
apic1(config-tenant-if)# ipv6 address
2001:1:1::1/64
Examples
This example shows the basic configuration of a tenant including assignment to a security domain,
creation of a VRF with contracts, and creation of a bridge domain.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# security domain exampleCorp_dom1
apic1(config-tenant)# vrf context exampleCorp_v1
apic1(config-tenant-vrf)# contract enforce
apic1(config-tenant-vrf)# contract provider web
apic1(config-tenant-vrf)# contract consumer db
apic1(config-tenant-vrf)# contract provider icmp
apic1(config-tenant-vrf)# contract consumer icmp
apic1(config-tenant-vrf)# exit
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
apic1(config-tenant-interface)# ipv6 address 2001:1:1::1/64
apic1(config-tenant-interface)# exit
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context exampleCorp_v1 tenant exampleCorp
apic1(config-leaf-vrf)# ip route 1.2.3.4 5.6.7.8
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# int eth 1/1
apic1(config-leaf-if)# vrf member exampleCorp_v1 tenant exampleCorp
What to do next
Add an application profile, create an application endpoint group (EPG), and associate the EPG to the bridge
domain.
Procedure
Step 4 (Optional) mac-address mac-address Configures the MAC address to be used in the
ARP reply for the pervasive gateway
Example:
functionality.
apic(config-tenant-interface)#
mac-address 1234.5678.abcd
Step 6 (Optional) [no] ip dhcp relay address tenant Sets or removes a DHCP relay address for the
tenant-name dhcp-address {application bridge-domain along with any supported
app-name epg epg-name | external-l2 options.
l2-epg-name | external-l3 l3-epg-name}
Example:
apic(config-tenant-interface)# ip dhcp
relay address 192.0.20.1 tenant
exampleCorp application app1 epg epg1
Step 7 (Optional) [no] {ip | ipv6} shared address Route leaking is allowed across VRFs to
address/mask-length provider application provide common services like DHCP, DNS for
app-name epg epg-name multiple tenant VRFs. Shared service is enabled
Step 8 (Optional) [no] {ip | ipv6} shared address See the previous step.
address/mask-length consumer application
any epg any
Example:
apic(config-tenant-interface)# ip shared
address 3.2.3.4/24 consumer application
any epg any
Examples
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# interface bridge-domain exampleCorp_bd1
apic1(config-tenant-interface)# mac-address 1234.5678.abcd
apic(config-tenant-interface)# ip dhcp relay address 192.0.20.1 tenant exampleCorp application
app1 epg epg1
apic1(config-tenant-interface)# ip shared address 1.2.3.4/24 provider application any
apic1(config-tenant-interface)# ip shared address 3.2.3.4/24 consumer application any epg
any
apic1(config-tenant-interface)# exit
apic1(config-tenant)# exit
apic1(config)# tenant my_dhcp_provider
apic1(config-tenant)# interface bridge-domain bd_dhcp
apic1(config-tenant-interface)# ip shared address 7.8.9.1/24 provider application app2 epg
epg2
Note • The exception IP addresses can ping all of the BD gateways across all of your VRFs.
• A loopback interface configured for an L3 out does not enforce reachability to the IP address that is
configured for the subject loopback interface.
• When an eBGP peer IP address exists in a different subnet than the subnet of the L3out interface, the
peer subnet must be added to the allowed exception subnets.
Otherwise, eBGP traffic is blocked because the source IP address exists in a different subnet than the
L3out interface subnet.
Note • The exception IP addresses can ping all of the BD gateways across all of your VRFs.
• A loopback interface configured for an L3 out does not enforce reachability to the IP address that is
configured for the subject loopback interface.
• When an eBGP peer IP address exists in a different subnet than the subnet of the L3out interface, the
peer subnet must be added to the allowed exception subnets.
Otherwise, eBGP traffic is blocked because the source IP address exists in a different subnet than the
L3out interface subnet.
Procedure
You can confirm if the enforced bridge domain is operational using the following type of command:
apic1# show running-config all | grep bd-enf
bd-enforce enable
bd-enf-exp-ip add 1.2.3.4/24
Example
The following command removes the subnet from the exception list:
apic1(config)# no bd-enf-exp-ip 1.2.3.4/24
apic1(config)#tenant coke
apic1(config-tenant)#vrf context cokeVrf
What to do next
To disable the enforced bridge domain run the following command:
apic1(config-tenant-vrf)# no bd-enforce enable
Procedure
Step 4 [no] epg epg-name Creates (or deletes) an EPG in the application
profile and enters EPG configuration mode.
Example:
apic1(config-tenant-app)# epg
exampleCorp_webepg1
Step 5 [no] bridge-domain member epg-name Associates the EPG to the bridge domain.
Every EPG must belong to a BD.
Example:
apic1(config-tenant-app-epg)#
bridge-domain member exampleCorp_b1
Step 10 interface type Specifies the interface that you are configuring.
For an Ethernet port, use “ethernet slot / port.”
Example:
apic1(config-leaf)# interface eth 1/2
Step 12 vlan-domain member domain-name Associates the interface with a VLAN domain.
Example:
Step 13 switchport trunk allowed vlan vlan-id tenant Deploys the EPG on the interface and identifies
tenant-name app app-name epg epg-name the EPG through EPG-to-VLAN mapping.
This configuration applies only to static EPG
Example:
deployment. If the VLAN is in use for another
apic1(config-leaf-if)# switchport trunk EPG or external SVI, you must delete the
allowed vlan 10 tenant exampleCorp
application OnlineStore epg
VLAN configuration before using it for this
exampleCorp_webepg1 EPG.
Note The interface must be associated
with a VLAN domain or this
command is rejected.
Examples
This example shows how to create an application EPG deployed to a layer 2 port.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# application OnlineStore
apic1(config-tenant-app)# epg exampleCorp_webepg1
apic1(config-tenant-app-epg)# bridge-domain member exampleCorp_b1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
What to do next
Map a VLAN on a port to the EPG.
Procedure
configure
Step 4 [no] legacy forwarding vlan vlan-id Maps the VLAN to the bridge domain.
vlan-domain vlan-domain-name
Example:
apic1(config-tenant-bd)#
legacy-forwarding vlan 50 vlan-domain
dom1
Step 8 interface type Specifies the interface that you are configuring.
For an Ethernet port, use ethernet slot/port .
Example:
apic1(config-leaf)# interface eth 1/1
Examples
This example shows how to configure legacy forwarding mode for forwarding between bridge
domains.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# bridge-domain exampleCorp_b1
apic1(config-tenant-bd)# legacy-forwarding vlan 50 vlan-domain dom1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# bridge-domain exampleCorp_b2
apic1(config-tenant-bd)# legacy-forwarding vlan 60 vlan-domain dom1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# exit
Configuring Contracts
Contracts are configured under a tenant with the following tasks:
• Define filters as access lists
• Define the contract and subjects
• Link the contract to an EPG
The tasks need not follow this order. For example, you can link a contract name to an EPG before you have
defined the contract.
Note Filters (ACLs) in APIC use match instead of permit | deny as in the traditional NX-OS ACL. The purpose
of a filter entry is only to match a given traffic flow. The traffic will be permitted or denied when the ACL is
applied on a contract or on a taboo contract.
Procedure
Step 2 tenant tenant-name Creates a tenant if it does not exist and enters
the tenant configuration mode.
Example:
tenant exampleCorp
Step 3 access-list acl-name Creates an access list (filter) that can be used
in a contract.
Example:
apic1(config-tenant)# access-list
http_acl
Step 4 (Optional) match {arp | icmp | ip} Creates a rule to match traffic of the selected
protocol.
Example:
apic1(config-tenant-acl)# match arp
Step 5 (Optional) match {tcp | udp} [src from[-to]] Creates a rule to match TCP or UDP traffic.
[dest from[-to]]
Example:
Step 6 (Optional) match raw options Creates a rule to match a raw vzEntry.
Example:
apic1(config-tenant-acl)#
Step 11 (Optional) [no] label name label-name Adds (removes) a provider or consumer label
{provider | consumer} to the subject.
Example:
apic1(config-tenant-contract-subj)#
Step 12 (Optional) [no] label match {provider | Specifies the match type for the provider or
consumer} [any | one | all | none] consumer label:
Example: • any —Match if any label is found in the
apic1(config-tenant-contract-subj)# contract relation.
• one —Match if exactly one label is found
in the contract relation.
• all —Match if all labels are found in the
contract relation.
• none —Match if no labels are found in
the contract relation.
Step 17 bridge-domain member bd-name Specifies the bridge domain for this EPG.
Example:
Step 18 contract provider provider-contract-name Specifies the provider contract for this EPG.
Communication with this EPG can be initiated
Example:
from other EPGs as long as the communication
apic1(config-tenant-app-epg)# contract complies with this provider contract.
provider web80
Step 19 contract consumer consumer-contract-name Specifies the consumer contract for this EPG.
The endpoints in this EPG may initiate
Example:
communication with any endpoint in an EPG
apic1(config-tenant-app-epg)# contract that is providing this contract.
consumer rmi99
Examples
This example shows how to create and apply contracts to an EPG.
apic1# configure
apic1(config)# tenant exampleCorp
# CREATE FILTERS
apic1(config-tenant)# access-list http_acl
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# match tcp dest 443
apic1(config-tenant-acl)# exit
This example shows a simpler method for defining a contract by declaring the filters inline in the
contract itself.
apic1# configure
Contract Inheritance
About Contract Inheritance
To streamline associating contracts to new EPGs, you can now enable an EPG to inherit all the (provided and
consumed) contracts associated directly to another EPG in the same tenant. Contract inheritance can be
configured for application, microsegmented, L2Out, and L3Out EPGs.
With Release 3.x, you can also configure contract inheritance for Inter-EPG contracts, both provided and
consumed. Inter-EPG contracts are supported on Cisco Nexus 9000 Series switches with EX or FX at the end
of their model name or later models.
You can enable an EPG to inherit all the contracts associated directly to another EPG, using the APIC GUI,
NX-OS style CLI, and the REST API.
Figure 3: Contract Inheritance
In the diagram above, EPG A is configured to inherit Provided-Contract 1 and 2 and Consumed-Contract 3
from EPG B (contract master for EPG A).
For information about configuring Contract Inheritance and viewing inherited and standalone contracts, see
Cisco APIC Basic Configuration Guide.
Procedure
Step 4 epg epg-name [type micro-segmented] Creates or specifies the application or uSeg
EPG to be configured and enters into EPG
Example:
configuration mode. For uSeg EPGs add the
apic1(config-tenant-app)# epg AEPg403 type.
In this example, this is the application EPG
contract master.
Step 5 bridge-domain member bd-name Associates the EPG with the bridge domain.
Example:
apic1(config-tenant-app-epg)#
bridge-domain member T1BD1
Step 7 contract provider [label label] Adds a contract to be provided by this EPG,
including an optional list of subject or EPG
Example:
labels (must be previously configured).
apic1(config-tenant-app-epg)# contract
provider T1ctrl_cif
Step 9 epg epg-name [type micro-segmented] Creates or specifies the application or uSeg
EPG to be configured and enters into EPG
Example:
configuration mode. For uSeg EPGs add the
apic1(config-tenant-app)# epg AEPg404 type.
In this example, this is the EPG inheriting
contracts.
Step 10 bridge-domain member bd-name Associates the EPG with the bridge domain.
Example:
apic1(config-tenant-app-epg)#
bridge-domain member T1BD1
Step 13 epg epg-name [type micro-segmented] Creates or specifies the application or uSeg
EPG to be configured and enters into EPG
Example:
configuration mode.
apic1(config-tenant-app)# epg
uSeg1_403_10 type micro-segmented In this example, this is the uSeg EPG contract
master.
Step 14 bridge-domain member bd-name Associates the EPG with the bridge domain.
Example:
apic1(config-tenant-app-epg)#
bridge-domain member T1BD1
Step 15 contract provider [label label] Adds a contract to be provided by this EPG,
including an optional list of subject or EPG
Example:
labels (must be previously configured).
apic1(config-tenant-app-epg)# contract
provider T1ctrl_uSeg_l3out
Step 18 epg epg-name [type micro-segmented] Creates or specifies the application or uSeg
EPG to be configured and enters into EPG
Example:
configuration mode.
apic1(config-tenant-app)# epg
uSeg1_403_30 type micro-segmented In this example, this is the uSeg EPG that
inherits contracts from the EPG contract
master.
Step 19 bridge-domain member bd-name Associates the EPG with the bridge domain.
Example:
apic1(config-tenant-app-epg)#
bridge-domain member T1BD1
Example
ifav90-ifc1# show running-config tenant Tn1 application AP1
# Command: show running-config tenant Tn1 application AP1
# Time: Fri Apr 28 17:28:32 2017
tenant Tn1
application AP1
epg AEPg403
bridge-domain member T1BD1
contract consumer cctr5 imported
contract provider T1ctr1_cif
exit
epg AEPg404
bridge-domain member T1BD1
inherit-from-epg application AP1 epg AEPg403
exit
epg uSeg1_403_10 type micro-segmented
bridge-domain member T1BD1
contract provider T1Ctr1_uSeg_l3out
Configuring L2Out EPG Contract Inheritance Using the NX-OS Style CLI
To configure contract inheritance for an external L2Out EPG, use the following commands:
Procedure
Step 4 bridge-domain member bd-name Associates the L2Out EPG with a bridge
domain.
Example:
apic1(config-tenant-l2ext-epg)#
bridge-domain member T1BD1
Step 5 contract provider contract-name [label label] Adds a contract to be provided by this EPG.
Example:
apic1(config-tenant-l2ext-epg)# contract
provider T1ctr_tcp
Step 8 bridge-domain member bd-name Associates the L2out EPG with the bridge
domain.
Example:
apic1(config-tenant-l2ext-epg)#
bridge-domain member T1BD1
Example
The steps above are taken from the following example:
apic1# show running-config tenant Tn1 external-l2
# Command: show running-config tenant Tn1 external-l2
# Time: Thu May 11 13:10:14 2017
tenant Tn1
external-l2 epg l2out1:l2Ext1
bridge-domain member T1BD1
contract provider T1ctr_tcp
exit
external-l2 epg l2out10:l2Ext10
bridge-domain member T1BD10
contract provider T1ctr_tcp
exit
external-l2 epg l2out11:l2Ext11
bridge-domain member T1BD11
contract provider T1ctr_udp
exit
external-l2 epg l2out12:l2Ext12
bridge-domain member T1BD12
inherit-from-epg epg l2out1:l2Ext1
inherit-from-epg epg l2out10:l2Ext10
inherit-from-epg epg l2out11:l2Ext11
inherit-from-epg epg l2out2:l2Ext2
inherit-from-epg epg l2out3:l2Ext3
inherit-from-epg epg l2out4:l2Ext4
inherit-from-epg epg l2out5:l2Ext5
inherit-from-epg epg l2out6:l2Ext6
inherit-from-epg epg l2out7:l2Ext7
inherit-from-epg epg l2out8:l2Ext8
Configuring External L3Out EPG Contract Inheritance Using the NX-OS Style
CLI
To configure contract inheritance for an external L3Out EPG, use the following commands:
Procedure
Step 3 external-l3 epg external-l3-epg-name l3out Configures an external L3Out EPG. In this
l3out-name example, this is the L3out contract master.
Example:
apic1(config-tenant-app)# external-l3
epg l3Ext108 l3out T1L3out1
Step 4 vrf member vrf-name Associates the L3out with the VRF.
Example:
apic1(tenant-l3out)# vrf member T1ctx1
Step 6 contract provider contract-name [label label] Adds a contract to be provided by this EPG.
Example:
apic1(config-tenant-l3ext-epg)# contract
provider T1ctrl-L3out
Step 8 external-l3 epg external-l3-epg-name l3out Configures an external L3Out EPG. In this
l3out-name example, this is the EPG that inherits contracts
from the L3out contract master.
Example:
apic1(config-tenant-app)# external-l3
epg l3Ext110 l3out T1L3out1
Step 9 vrf member vrf-name Associates the L3out with the VRF.
Example:
apic1(tenant-l3out)# vrf member T1ctx1
Example
ifav90-ifc1# show running-config tenant Tn1 external-l3 epg l3Ext110
# Command: show running-config tenant Tn1 external-l3 epg l3Ext110
# Time: Fri Apr 28 17:36:15 2017
tenant Tn1
external-l3 epg l3Ext108 l3out T1L3out1
vrf member T1ctx1
match ip 192.168.110.0/24 shared
contract provider T1ctrl-L3out
exit
external-l3 epg l3Ext110 l3out T1L3out1
vrf member T1ctx1
match ip 192.168.112.0/24 shared
inherit-from-epg epg l3Ext108
exit
exit
The contract preferred group feature enables greater control of communication between EPGs in a VRF. If
most of the EPGs in the VRF should have open communication, but a few should only have limited
communication with the other EPGs, you can configure a combination of a contract preferred group and
contracts with filters to control inter-EPG communication precisely.
EPGs that are excluded from the preferred group can only communicate with other EPGs if there is a contract
in place to override the source-any-destination-any-deny default rule.
Limitations
The following limitations apply to contract preferred groups:
• In topologies where an L3Out and application EPG are configured in a Contract Preferred Group, and
the EPG is deployed only on a VPC, you may find that only one leaf switch in the VPC has the prefix
entry for the L3Out. In this situation, the other leaf switch in the VPC does not have the entry, and
therefore drops the traffic.
To workaround this issue, you can do one of the following:
• Disable and reenable the contract group in the VRF
• Delete and recreate the prefix entries for the L3Out EPG
• Also, where the provider or consumer EPG in a service graph contract is included in a contract group,
the shadow EPG can not be excluded from the contract group. The shadow EPG will be permitted in the
contract group, but it does not trigger contract group policy deployment on the node where the shadow
EPG is deployed. To download the contract group policy to the node, you deploy a dummy EPG within
the contract group .
Procedure
Step 6 vrf member vrf-name Associates the VRF with the bridge-domain
and returns to teanant configuration mode.
Example:
apic1(config-tenant-bd)# vrf member
vrf64
apic1(config-tenant-bd)# exit
Step 9 bridge-domain member bd-name Associates the EPG with the bridge-domain .
Example:
apic1(config-tenant-app-epg)#
bridge-domain member bd64
Example
The following example creates a contract preferred group for vrf64 and includes epg-ldap in it.
apic1# configure
apic1(config)# tenant tenant64
apic1(config-tenant)# vrf context vrf64
apic1(config-tenant-vrf)# whitelist-blacklist-mix
apic1(config-tenant-vrf)# exit
Procedure
Step 3 contract contract-name Enters the contract configuration mode for the
contract to be exported.
Example:
apic1(config-tenant)# contract web80
Step 4 scope {application | exportable | tenant | vrf} Configures how the contract can be shared.
The scope can be:
Example:
apic1(config-tenant-contract)# scope • application —Can be shared among the
exportable EPGs of the same application.
• exportable —Can be shared across
tenants.
• tenant —Can be shared among the EPGs
of the same tenant.
• vrf —Can be shared among the EPGs of
the same VRF.
Step 5 export to tenant other-tenant-name as Exports the contract to the other tenant. You
new-contract-name can use the same contract name or you can
rename it.
Example:
apic1(config-tenant-contract)# export
to tenant BlueCorp as webContract1
Step 8 tenant tenant-name Enters the tenant configuration mode for the
importing tenant.
Example:
tenant BlueCorp
Step 11 contract consumer consumer-contract-name Specifies the imported consumer contract for
imported this EPG. The endpoints in this EPG may
initiate communication with any endpoint in
Example:
an EPG that is providing this contract.
apic1(config-tenant-app-epg)# contract
consumer webContract1 imported
Examples
This example shows how to export a contract from the tenant RedCorp to the tenant BlueCorp, where
it will be a consumer contract.
apic# configure
apic1(config)# tenant RedCorp
apic1(config-tenant)# contract web80
apic1(config-tenant-contract)# scope exportable
apic1(config-tenant-contract)# export to tenant BlueCorp as webContract1
apic1(config-tenant-contract)# exit
apic1(config-tenant)# exit
apic1(config)# tenant BlueCorp
apic1(config-tenant)# application BlueStore
apic1(config-tenant-application)# epg BlueWeb
apic1(config-tenant-application-epg)# contract consumer webContract1 imported
When adding filters to subjects, you can set the action of the filter (to permit or deny objects that match the
filter criteria). Also for Deny filters, you can set the priority of the filter. Permit filters always have the default
priority. Marking the subject-to-filter relation to deny automatically applies to each pair of EPGs where there
is a match for the subject. Contracts and subjects can include multiple subject-to-filter relationships that can
be independently set to permit or deny the objects that match the filters.
Exception Types
Contract and subject exceptions can be based on the following types and include regular expressions, such as
the * wildcard:
Procedure
Step 1 Configure filters for HTTP and HTTPS, using commands as in the following example:
Example:
apic1(config)# tenant t2
apic1(config-tenant)# access-list ac1
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# exit
apic1(config-tenant)# access-list ac2
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 443
Step 2 Configure a contract that excludes EPg01 from consuming it and EPg03 from providing it.
Example:
Procedure
Syntax:
where <className> is the managed object className such as fvBD or fvCtx etc. All the eligible classes
accordingly to the presence of the quota flag in the model are accepted.
where <maxValue> is the value after which the <exceed-action> is applied.
where <exceed-action> is the action to be taken after the <maxValue> is exceeded, can either be:
• fail: when you want to fail the transaction exceeding the limit.
• fault: raise a fault.
where <containerDn> is the tree under which the limit will be enforced. "uni" will be across the whole ACI
policy model, "tenant green" will be for the tenant green.
Caution Do not mix the 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
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.
The configuration for Layer2 external connectivity is similar to a static application EPG, where you map a
VLAN on a node port to an EPG and map the EPG to a bridge-domain to provide/consume contracts.
Procedure
Step 3 [no] external-l2 epg epg-name Create (or delete ) an external layer 2 EPG.
Example:
apic1(config-tenant)# external-l2 epg
extendBD1
Step 11 Assigns a VLAN on the leaf port and maps the Note The interface must be associated
VLAN to a layer 2 external EPG, with the with a VLAN domain or this
switchport trunk allowed vlan vlan-id tenant command is rejected.
tenant-name external-l2 epg epg-name
command.
Example:
apic1(config-leaf-if)# switchport trunk
allowed vlan 10 tenant exampleCorp
external-l2 epg extendBD1
Step 12 Assign a VLAN on the leaf port and map the Note The interface must be associated
VLAN to an external SVI with the switchport with a VLAN domain or this
{trunk allowed | trunk native | access} vlan command is rejected.
vlan-id tenant tenant-name external-svi
command.
Example:
apic1(config-leaf-if)# switchport trunk
allowed vlan 10 tenant exampleCorp
external-svi
Examples
This example shows how to deploy a layer 2 port for external connectivity.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# external-l2 epg extendBD1
apic1(config-tenant-extl2epg)# bridge-domain member bd1
apic1(config-tenant-extl2epg)# exit
apic1(config-tenant)# exit
This example shows how to deploy a layer 2 port channel or vPC for external connectivity.
...
These examples show how to configure SVI on a layer 2 interface for external connectivity.
The fabric administrator can update any configuration in these steps even after VLAN domains are assigned
to tenants and are in use by tenant applications.
Note Multiple Spanning Tree (MST) is not supported on interfaces configured with the Per Port VLAN feature
(configuring multiple EPGs on a leaf switch using the same VLAN ID with localPort scope).
Step 2 [no] vlan-domain domain-name [dynamic] Creates a VLAN domain or edits an existing
domain. Include the dynamic keyword to
Example:
create a dynamic VLAN pool. The default is
static.
apic1(config)# vlan-domain dom2 dynamic
Examples
This example shows how to configure basic VLAN domains.
apic1# configure
apic1(config)# vlan-domain dom1
apic1(config-vlan)# vlan 1000-1999,4001
apic1(config-vlan)# exit
apic1(config)# vlan-domain dom2 dynamic
apic1(config-vlan)# vlan 101-200
apic1(config-vlan)# vlan 301-400 dynamic
Step 2 [no] vlan-domain domain-name [dynamic] Creates a VLAN domain or edits an existing
[type {phys | l2ext | l3ext}] domain. Include the dynamic keyword to
create a dynamic VLAN pool. The default is
Example:
static.
apic1(config)# vlan-domain dom1 type phys The type option is visible and mandatory if
one or more of the following conditions exist:
• If all three vlan-domain types are not
present for this domain name
• If the three vlan-domain types have
different VLAN pools
• If the three vlan-domain types share the
same VLAN pool but if the pool name
differs from the vlan-domain name
Examples
This example shows how to configure a VLAN domain with a VLAN pool.
apic1# configure
(config)# vlan-domain dom1 type phys
(config-vlan-domain)# vlan-pool myVlanPool3
(config-vlan-domain)# vlan 1000-1999, 4001
Step 4 [no] vlan-domain member domain-name Assigns the specified ports to the VLAN
domain.
Example:
apic1(config-leaf-if)# vlan-domain member
dom1
Step 7 show vlan-domain [name domain-name] [vlan Displays vlan-domain usage for applications
vlan-id] [leaf leaf-id] such as App-EPG, external SVI, and
external-L2.
Example:
apic1(config-leaf-if)# show vlan-domain
name dom1 vlan 1002 leaf 102
Examples
This example shows how to associate a VLAN domain to ports.
apic1# configure
(config) # leaf 101-102
(config-leaf) # int eth 1/1-24
(config-leaf-if) # vlan-domain member dom1
Step 4 [no] vlan-domain member domain-name Assigns the specified port-channel to the VLAN
domain.
Example:
apic1(config-leaf-if)# vlan-domain member
dom1
Examples
apic1# configure
apic1(config)# leaf 101-102
apic1(config-leaf)# int port-channel pc1
apic1(config-leaf-if)# vlan-domain member dom1
Step 3 [no] vlan-domain member domain-name Assigns the specified template policy-group to
the VLAN domain.
Example:
apic1(config-pol-grp-if)# vlan-domain
member dom1
Examples
apic1# configure
apic1(config)# template policy-group myPolGp5
apic1(config-pol-grp-if)# vlan-domain member dom1
Step 3 [no] vlan-domain member domain-name Assigns the specified template port-channel to
the VLAN domain.
Example:
apic1(config-if)# vlan-domain member dom1
Examples
apic1# configure
apic1(config)# template port-channel myPC7
apic1(config-po-ch-if)# vlan-domain member dom1
Step 3 interface vpc vpc-name [fex fex-id1 fex-id2] Specifies a port-channel to be associated with
the VLAN domain.
Example:
apic1(config-vpc)# int vpc vpc1
Step 4 [no] vlan-domain member domain-name Assigns the specified VPC to the VLAN
domain.
Example:
apic1(config-vpc-if)# vlan-domain member
dom1
Examples
apic1# configure
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# int vpc vpc1
apic1(config-vpc-if)# vlan-domain member dom1
Mapping EPGs to Q-in-Q Encapsulated Leaf Interfaces Using the NX-OS Style
CLI
Enable an interface for Q-in-Q encapsulation and associate the interface with an EPG.
Procedure
Step 5 switchport trunk qinq outer-vlan Associates the interface with an EPG.
vlan-number inner-vlan vlan-number tenant
tenant-name application application-name epg
epg-name
Example:
apic1(config-leaf-if)# switchport trunk
qinq outer-vlan 202 inner-vlan 203
tenant tenant64 application AP64 epg
EPG64
Example
The following example enables Q-in-Q encapsulation (with outer-VLAN ID 202 and inner-VLAN
ID 203) on the leaf interface 101/1/25, and associates the interface with EPG64.
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/25
apic1(config-leaf-if)#switchport mode dot1q-tunnel doubleQtagPort
apic1(config-leaf-if)# switchport trunk qinq outer-vlan 202 inner-vlan 203 tenant tenant64
application AP64 epg EPG64
Note In the FCoE topology, the role of the ACI leaf switch is to provide a path for FCoE traffic between the locally
connected SAN hosts and a locally connected FCF device. The leaf switch does not perform local switching
between SAN hosts, and the FCoE traffic is not forwarded to a spine switch.
• One or more ACI leaf switches configured through FC SAN policies to function as an NPV backbone.
• Selected interfaces on the NPV-configured leaf switches configured to function as virtual F ports, which
accommodate FCoE traffic to and from hosts running SAN management or SAN-consuming applications.
• Selected interfaces on the NPV-configured leaf switches configured to function as virtual NP ports, which
accommodate FCoE traffic to and from a Fibre Channel Forwarding (FCF) bridge.
The FCF bridge receives FC traffic from fibre channel links typically connecting SAN storage devices and
encapsulates the FC packets into FCoE frames for transmission over the ACI fabric to the SAN management
or SAN Data-consuming hosts. It receives FCoE traffic and repackages it back to FC for transmission over
the fibre channel network.
Note In the above ACI topology, FCoE traffic support requires direct connections between the hosts and virtual F
ports and direct connections between the FCF device and the virtual NP port.
APIC servers enable an operator to configure and monitor the FCoE traffic through the APIC GUI, the APIC
NX-OS style CLI, or through application calls to the APIC REST API.
• N2K-B22IBM-P
• N2K-B22DELL-P-FI
The vlan used for FCoE should have vlanScope set to Global. vlanScope set to portLocal is not supported for
FCoE. The value is set via the L2 Interface Policy l2IfPol.
Procedure
Step 2 Under the same tenant, associate the target EPG The sample command sequence creates EPG
with the FCoE-configured bridge domain. e1 and associates that EPG with the
FCoE-configured bridge domain b1.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# application a1
apic1(config-tenant-app)# epg e1
apic1(config-tenant-app-epg)#
bridge-domain member b1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 3 Create a VSAN domain, VSAN pools, VLAN In Example A, the sample command sequence
pools and VSAN to VLAN mapping. creates VSAN domain, dom1 with VSAN pools
and VLAN pools, maps VSAN 1 to VLAN 1
Example:
and maps VSAN 2 to VLAN 2
A
In Example B, an alternate sample command
apic1(config)# vsan-domain dom1
sequence creates a reusable VSAN attribute
apic1(config-vsan)# vsan 1-10
apic1(config-vsan)# vlan 1-10 template pol1 and then creates VSAN domain
Example:
B
apic1(config)# template vsan-attribute
pol1
apic1(config-vsan-attr)# fcoe vsan 2
vlan 12 loadbalancing src-dst-ox-id
apic1(config-vsan-attr)# fcoe vsan 3
vlan 13 loadbalancing src-dst-ox-id
apic1(config-vsan-attr)# exit
apic1(config)# vsan-domain dom1
apic1(config-vsan)# vsan 1-10
apic1(config-vsan)# vlan 1-10
apic1(config-vsan)# inherit
vsan-attribute pol1
apic1(config-vsan)# exit
Step 4 Create the physical domain to support the FCoE In the example, the command sequence creates
Initialization (FIP) process. a regular VLAN domain, fipVlanDom, which
includes VLAN 120 to support the FIP process.
Example:
Step 5 Under the target tenant configure a regular In the example, the command sequence creates
bridge domain. bridge domain fip-bd.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# vrf context v2
apic1(config-tenant-vrf)# exit
apic1(config-tenant)# bridge-domain
fip-bd
apic1(config-tenant-bd)# vrf member v2
apic1(config-tenant-bd)# exit
apic1(config-tenant)# exit
Step 6 Under the same tenant, associate this EPG with In the example, the command sequence
the configured regular bridge domain. associates EPG epg-fip with bridge domain
fip-bd.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# application a1
apic1(config-tenant-app)# epg epg-fip
apic1(config-tenant-app-epg)#
bridge-domain member fip-bd
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 7 Configure a VFC interface with F mode. In example A the command sequence enables
interface 1/2 on leaf switch 101 to function as
Example:
Example:
C
apic1(config)# leaf 101
apic1(config-leaf)# interface vfc-po pc1
apic1(config-leaf-if)# vsan-domain member
dom1
apic1(config-leaf-if)# switchport vsan
2 tenant t1 application a1 epg e1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet
1/2
Step 8 Configure a VFC interface with NP mode. The sample command sequence enables
interface 1/4 on leaf switch 101 to function as
Example:
an NP port and associates that interface with
apic1(config)# leaf 101
VSAN domain dom1.
apic1(config-leaf)# interface vfc 1/4
apic1(config-leaf-if)# switchport mode
np
apic1(config-leaf-if)# vsan-domain member
dom1
Step 9 Assign the targeted FCoE-enabled interfaces a Each of the targeted interfaces must be assigned
VSAN. one (and only one) VSAN in native mode. Each
interface may be assigned one or more
Example:
additional VSANs in regular mode.
apic1(config-leaf-if)# switchport trunk
allowed vsan 1 tenant t1 application a1 The sample command sequence assigns the
epg e1 target interface to VSAN 1 and associates it
apic1(config-leaf-if)# switchport vsan
2 tenant t4 application a4 epg e4
with EPG e1 and application a1 under tenant
t1. "trunk allowed" assigns vsan 1 regular mode
status. The command sequence also assigns the
interface a required native mode VSAN 2. As
this example shows, it is permissible for
different VSANs to provide different EPGs
running under different tenants access to the
same interfaces.
Configuring FCoE Connectivity With Policies and Profiles Using the NX-OS
Style CLI
The following sample NX-OS style CLI sequences create and use policies to configure FCoE connectivity
for EPG e1 under tenant t1.
Procedure
apic1(config-tenant-bd)# fc
apic1(config-tenant-bd)# vrf member v1
apic1(config-tenant-bd)# exit
Step 2 Under the same tenant, associate your target The sample command sequence creates EPG
EPG with the FCoE configured bridge domain. e1 associates that EPG with FCoE-configured
bridge domain b1.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# application a1
apic1(config-tenant-app)# epg e1
apic1(config-tenant-app-epg)#
bridge-domain member b1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
apic1(config)#
Step 3 Create a VSAN domain, VSAN pools, VLAN In Example A, the sample command sequence
pools and VSAN to VLAN mapping. creates VSAN domain, dom1 with VSAN
pools and VLAN pools, maps VSAN 1 VLAN
Example:
1 and maps VSAN 2 to VLAN 2
A
In Example B, an alternate sample command
apic1(config)# vsan-domain dom1
sequence creates a reusable vsan attribute
apic1(config-vsan)# vsan 1-10
apic1(config-vsan)# vlan 1-10 template pol1 and then creates VSAN domain
apic1(config-vsan)# fcoe vsan 1 vlan 1 dom1, which inherits the attributes and
loadbalancing mappings from that template.
src-dst-ox-id
apic1(config-vsan)# fcoe vsan 2 vlan 2
Example:
B
apic1(config)# template vsan-attribute
pol1
apic1(config-vsan-attr)# fcoe vsan 2
vlan 12
loadbalancing
src-dst-ox-id
apic1(config-vsan-attr)# fcoe vsan 3
vlan 13
loadbalancing
src-dst-ox-id
apic1(config-vsan-attr)# exit
apic1(config)# vsan-domain dom1
apic1(config-vsan)# inherit
vsan-attribute pol1
apic1(config-vsan)# exit
Step 6 Create a Fibre Channel node policy. The sample command sequence creates Fibre
Channel node policy flp1 to specify a
Example:
combination of disruptive load-balancing
apic1(config)# template fc-leaf-policy enablement and FIP keep-alive values. These
flp1
apic1(config-fc-leaf-policy)# fcoe values also apply to all the FCoE-enabled
fka-adv-period 44 interfaces on a target leaf switch.
apic1(config-fc-leaf-policy)# exit
Step 7 Create Node Policy Group. The sample command sequence creates a Node
Policy group, lpg1, which combines the values
Example:
of the Fibre Channel SAN policy ffp1 and
apic1(config)# template
Fibre Channel node policy, flp1. The combined
leaf-policy-group lpg1
apic1(config-leaf-policy-group)# inherit values of this node policy group can be applied
fc-fabric-policy ffp1 to Node profiles configured later.
apic1(config-leaf-policy-group)# inherit
fc-leaf-policy flp1
apic1(config-leaf-policy-group)# exit
apic1(config)# exit
apic1#
Step 8 Create a Node Profile. The sample command sequence creates node
profile lp1 associates it with node policy group
Example:
lpg1, node group lg1, and leaf switch 101.
apic1(config)# leaf-profile lp1
apic1(config-leaf-profile)# leaf-group
lg1
apic1(config-leaf-group)# leaf 101
apic1(config-leaf-group)#
leaf-policy-group lpg1
Step 9 Create an interface policy group for F port The sample command sequence creates
interfaces. interface policy group ipg1 and assigns a
combination of values that determine priority
Example:
flow control enablement, F port enablement,
apic1(config)# template policy-group and slow-drain policy values for any interface
ipg1
apic1(config-pol-grp-if)# that this policy group is applied to.
priority-flow-control mode auto
apic1(config-pol-grp-if)# switchport
mode f
apic1(config-pol-grp-if)# slow-drain
pause timeout 111
Step 10 Create an interface policy group for NP port The sample command sequence creates
interfaces. interface policy group ipg2 and assigns a
combination of values that determine priority
Example:
flow control enablement, NP port enablement,
apic1(config)# template policy-group and slow-drain policy values for any interface
ipg2
apic1(config-pol-grp-if)# that this policy group is applied to.
priority-flow-control mode auto
apic1(config-pol-grp-if)# switchport
mode np
apic1(config-pol-grp-if)# slow-drain
pause timeout 111
apic1(config-pol-grp-if)# slow-drain
congestion-timeout count 55
apic1(config-pol-grp-if)# slow-drain
congestion-timeout action log
Step 11 Create an interface profile for F port interfaces. The sample command sequence creates an
interface profile lip1 for F port interfaces,
Example:
associates the profile with F port specific
apic1# configure interface policy group ipg1, and specifies the
apic1(config)# leaf-interface-profile
lip1 interfaces to which this profile and its
apic1(config-leaf-if-profile)# associated policies applies.
description 'test description lip1'
apic1(config-leaf-if-profile)#
leaf-interface-group lig1
apic1(config-leaf-if-group)# description
'test description lig1'
apic1(config-leaf-if-group)#
policy-group ipg1
apic1(config-leaf-if-group)# interface
ethernet 1/2-6, 1/9-13
Step 12 Create an interface profile for NP port The sample command sequence creates an
interfaces. interface profile lip2 for NP port interfaces,
associates the profile with NP port specific
Example:
interface policy group ipg2, and specifies the
apic1# configure
interface to which this profile and its associated
apic1(config)#
leaf-interface-profile lip2 policies applies.
apic1(config-leaf-if-profile)#
description 'test description lip2'
apic1(config-leaf-if-profile)#
leaf-interface-group lig2
apic1(config-leaf-if-group)#
description 'test description lig2'
apic1(config-leaf-if-group)#
policy-group ipg2
apic1(config-leaf-if-group)# interface
ethernet 1/14
Procedure
Step 3 Configure FCoE over FEX per port, port-channel, and VPC:
Example:
apic1(config-leaf)# interface vfc 111/1/2
apic1(config-leaf-if)# vsan-domain member dom1
apic1(config-leaf-if)# switchport vsan 2 tenant t1 application a1 epg e1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface vfc-po pc1 fex 111
apic1(config-leaf-if)# vsan-domain member dom1
apic1(config-leaf-if)# switchport vsan 2 tenant t1 application a1 epg e1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 111/1/3
apic1(config-leaf-if)# channel-group pc1
apic1(config-leaf-if# exit
apic1(config-leaf)# exit
apic1(config)# vpc domain explicit 12 leaf 101 102
apic1(config-vpc)# exit
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# interface vpc vpc1 fex 111 111
apic1(config-vpc-if)# vsan-domain member dom1
apic1(config-vpc-if)# switchport vsan 2 tenant t1 application a1 epg e1
apic1(config-vpc-if)# exit
apic1(config-vpc)# exit
apic1(config)# leaf 101-102
apic1(config-leaf)# interface ethernet 1/2
apic1(config-leaf-if)# fex associate 111
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 111/1/2
apic1(config-leaf-if)# channel-group vpc1 vpc
apic1(config-leaf-if)# exit
vsan : 1-100
vlan : 1-100
Procedure
Use the show vsan-domain command to verify FCoE is enabled on the target switch.
The command example confirms FCoE enabled on the listed leaf switches and its FCF connection details.
Example:
App: iPost1
Epg: iPost1
App: iPost1
Epg: iPost1
Epg: iPost4
Epg: e1
Procedure
Step 1 List the attributes of the leaf port interface, set its mode setting to default, and then remove its EPG deployment
and domain association.
The example sets the port mode setting of interface vfc 1/2 to default and then removes the deployment of
EPG e1 and the association with VSAN Domain dom1 from that interface.
Example:
Step 2 List and remove the VSAN/VLAN mapping and the VLAN and VSAN pools.
The example removes the VSAN/VLAN mapping for vsan 2, VLAN pool 1-10, and VSAN pool 1-10 from
VSAN domain dom1.
Example:
apic1(config)# vsan-domain dom1
apic1(config-vsan)# show run
# Command: show running-config vsan-domain dom1
# Time: Tue Jul 26 09:43:47 2016
vsan-domain dom1
vsan 1-10
vlan 1-10
fcoe vsan 2 vlan 2
exit
apic1(config-vsan)# no fcoe vsan 2
apic1(config-vsan)# no vlan 1-10
apic1(config-vsan)# no vsan 1-10
apic1(config-vsan)# exit
#################################################################################
NOTE: To remove a template-based VSAN to VLAN mapping use an alternate sequence:
#################################################################################
Step 4 You can delete the associated tenant, EPG, and selectors if you do not need them.
FC NPV Benefits
FC NPV provides the following:
• Increased number of hosts that connect to the fabric without adding domain IDs in the fabric
• Connection of FC and FCoE hosts and targets to SAN fabrics using FC interfaces
• Automatic traffic mapping
• Static traffic mapping
• Disruptive automatic load balancing
FC NPV Mode
Feature-set fcoe-npv in ACI will be enabled automatically by default when first FCoE/FC configuration is
pushed.
FC Topology
The topology of a typical configuration supporting FC traffic over the ACI fabric consists of the following
components:
feature npiv
feature fport-channel-trunk
• To use an 8G uplink speed, you must configure the IDLE fill pattern on the core switch.
Note Following is an example of configuring IDLE fill pattern on a Cisco MDS switch:
interface fc2/3
switchport speed 8000
switchport mode NP
switchport fill-pattern IDLE speed 8000
no shutdown
• In the Cisco APIC 4.1(1) release and later, Fibre Channel NPV support is limited to the Cisco
N9K-C93180YC-FX switch.
• You can use ports 1 through 48 for Fibre Channel configuration. Ports 49 through 54 cannot be Fibre
Channel ports.
• If you convert a port from Ethernet to Fibre Channel or the other way around, you must reload the switch.
Currently, you can convert only one contiguous range of ports to Fibre Channel ports, and this range
must be a multiple of 4, ending with a port number that is a multiple of 4. For example, 1-4, 1-8, or 21-24.
• Fibre Channel Uplink (NP) connectivity to Brocade Port Blade Fibre Channel 16-32 is not supported
when a Cisco N9K-93180YC-FX leaf switch port is configured in 8G speed.
• The selected port speed must be supported by the SFP. For example, because a 32G SFP supports
8/16/32G, a 4G port speed requires an 8G or 16G SFP. Because a 16G SFP supports 4/8/16G, a 32G
port speed requires a 32G SFP.
• Speed autonegotiation is supported. The default speed is 'auto'.
• You cannot use Fibre Channel on 40G and breakout ports.
• FEX cannot be directly connected to FC ports.
• FEX HIF ports cannot be converted to FC.
Procedure
Step 2 Under the same tenant, associate the target EPG with the FCoE-configured bridge domain. The sample
command sequence below creates EPG e1 and associates that EPG with the FCoE-configured bridge domain
b1:
Example:
apic1(config)# tenant t1
apic1(config-tenant)# application a1
apic1(config-tenant-app)# epg e1
apic1(config-tenant-app-epg)# bridge-domain member b1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 3 The following example creates vsan domain dom1 with vsans 1-10:
Example:
apic1(config)# vsan-domain dom1
apic1(config-vsan)# vsan 1-10
Step 4 Convert range of ports from Ethernet to FC mode. The following example converts port 1/1-4 on switch 101
to FC:
Example:
apic1# config
apic1(config)# leaf 101
apic1(config-leaf)# slot 1
apic1(config-leaf-slot)# port 1 4 type fc
apic1(config-leaf-slot)# exit
apic1(config-leaf)# exit
Note Port conversion from Ethernet to FC and vice versa requires reload of switch.
Step 5 Configure FC interface in NP mode. The following example sets various interface properties on interface fc
1/10 and associates that interface with VSAN domain dom1. Each of the targeted interfaces must be assigned
one (and only one) VSAN in native mode. The sample command sequence associates the target interface 1/10
with VSAN 10 as a native VSAN and associates it with EPG e1 and application a1 under tenant t1.
Example:
apic1(config-leaf)# interface fc 1/10
apic1(config-leaf-fc-if)# switchport mode [f | np]
apic1(config-leaf-fc-if)# switchport rxbbcredit <16-64>
apic1(config-leaf-fc-if)# switchport speed [16G | 32G | 4G | 8G | auto | unknown]
apic1(config-leaf-fc-if)# vsan-domain member dom1
apic1(config-leaf-fc-if)# switchport vsan 10 tenant t1 application a1 epg e1
Step 6 Create traffic map to pin server ports to uplink ports. The following example creates Traffic map for vFC 1/47
server interface pinned to FC 1/7 uplink interface:
Example:
apic1# config
apic1(config)# leaf 101
apic1(config-leaf)# npv traffic-map server-interface vfc 1/47 label label1 tenant tenant1
application app1 epg epg1
apic1(config-leaf)# npv traffic-map external-interface fc 1/7 tenant tenant1 label label1
Procedure
Step 2 Under the same tenant, associate the target EPG with the FCoE-configured bridge domain. The sample
command sequence below creates EPG e1 and associates that EPG with the FCoE-configured bridge domain
b1:
Example:
apic1(config)# tenant t1
apic1(config-tenant)# application a1
apic1(config-tenant-app)# epg e1
apic1(config-tenant-app-epg)# bridge-domain member b1
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 3 Create a VSAN domain. The following example creates vsan domain dom1 with vsans 1-10:
Example:
apic1(config)# vsan-domain dom1
apic1(config-vsan)# vsan 1-10
Step 4 Create an interface policy group for NP port interfaces. The sample command sequence creates FC interface
policy group ipg2 and assigns a combination of values that determine values for any interface that this policy
group is applied to:
Example:
apic1(config)# template fc-policy-group ipg1
apic1(config-fc-pol-grp-if)# switchport ?
fill-pattern Configure fill pattern for fc interface
mode Configure port mode for fc interface
rxbbcredit Configure rxBBCredit for fc interface
speed Configure speed for fc interface
trunk-mode Configure trunk-mode for fc interface
apic1(config-fc-pol-grp-if)# switchport fill-pattern [ARBFF | IDLE]
apic1(config-fc-pol-grp-if)# switchport mode [f | np]
apic1(config-fc-pol-grp-if)# switchport rxbbcredit <16-64>
apic1(config-fc-pol-grp-if)# switchport speed [16G | 32G | 4G | 8G | auto | unknown]
apic1(config-fc-pol-grp-if)# vsan-domain member dom1
Step 5 Create an interface profile for FC port interfaces. The sample command sequence creates an interface profile
lip1 for FC port interfaces, associates the profile with FC interface policy group ipg1, and specifies the
interfaces to which this profile and its associated policies applies:
Example:
apic1# configure
apic1(config)# leaf-interface-profile lip1
apic1(config-leaf-if-profile)# description 'test description lip1'
apic1(config-leaf-if-profile)# leaf-interface-group lig1
apic1(config-leaf-if-group)# description 'test description lig1'
apic1(config-leaf-if-group)# fc-policy-group ipg1
apic1(config-leaf-if-group)# interface fc 1/1-4
Step 6 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 lp103
apic1(config-leaf-profile)# leaf-interface-profile lip1
apic1(config-leaf-profile)# leaf-group range
apic1(config-leaf-group)# leaf 103
apic1(config-leaf-group)#
Note After associating leaf interface profile to leaf, reload of leaf is required to bring up these ports as
FC ports.
With Cisco ACI and Cisco APIC Release 2.2(1x) and higher, you can configure 802.1Q tunnels on edge
(tunnel) ports to enable point-to-multi-point tunneling of Ethernet frames in the fabric, with Quality of Service
(QoS) priority settings. A Dot1q Tunnel transports untagged, 802.1Q tagged, and 802.1ad double-tagged
frames as-is across the fabric. Each tunnel carries the traffic from a single customer and is associated with a
single bridge domain. ACI front panel ports can be part of a Dot1q Tunnel. Layer 2 switching is done based
on Destination MAC (DMAC) and regular MAC learning is done in the tunnel. Edge-port Dot1q Tunnels
are supported on second-generation (and later) Cisco Nexus 9000 series switches with "EX" on the end of the
switch model name.
With Cisco ACI and Cisco APIC Release 2.3(x) and higher, you can also configure multiple 802.1Q tunnels
on the same core port to carry double-tagged traffic from multiple customers, each distinguished with an
access encapsulation configured for each 802.1Q tunnel. You can also disable MAC Address Learning on
802.1Q tunnels. Both edge ports and core ports can belong to an 802.1Q tunnel with access encapsulation and
disabled MAC Address Learning. Both edge ports and core ports in Dot1q Tunnels are supported on
third-generation Cisco Nexus 9000 series switches with "FX" on the end of the switch model name.
Terms used in this document may be different in the Cisco Nexus 9000 Series documents.
• Layer 2 tunneling of VTP, CDP, LACP, LLDP, and STP protocols is supported with the following
restrictions:
• Link Aggregation Control Protocol (LACP) tunneling functions as expected only with point-to-point
tunnels using individual leaf interfaces. It is not supported on port-channels (PCs) or virtual
port-channels (vPCs).
• CDP and LLDP tunneling with PCs or vPCs is not deterministic; it depends on the link it chooses
as the traffic destination.
• To use VTP for Layer 2 protocol tunneling, CDP must be enabled on the tunnel.
• STP is not supported in an 802.1Q tunnel bridge domain when Layer 2 protocol tunneling is enabled
and the bridge domain is deployed on Dot1q Tunnel core ports.
• ACI leaf switches react to STP TCN packets by flushing the end points in the tunnel bridge domain
and flooding them in the bridge domain.
• CDP and LLDP tunneling with more than two interfaces flood packets on all interfaces.
• With Cisco APIC Release 2.3(x) or higher, the destination MAC address of Layer 2 protocol packets
tunneled from edge to core ports is rewritten as 01-00-0c-cd-cd-d0 and the destination MAC address
of Layer 2 protocol packets tunneled from core to edge ports is rewritten with the standard default
MAC address for the protocol.
• If a PC or vPC is the only interface in a Dot1q Tunnel and it is deleted and reconfigured, remove the
association of the PC/VPC to the Dot1q Tunnel and reconfigure it.
• With Cisco APIC Release 2.2(x) the Ethertypes for double-tagged frames must be 0x9100 followed by
0x8100.
However, with Cisco APIC Release 2.3(x) and higher, this limitation no longer applies for edge ports,
on third-generation Cisco Nexus switches with "FX" on the end of the switch model name.
• For core ports, the Ethertypes for double-tagged frames must be 0x8100 followed by 0x8100.
• You can include multiple edge ports and core ports (even across leaf switches) in a Dot1q Tunnel.
• An edge port may only be part of one tunnel, but a core port can belong to multiple Dot1q tunnels.
• With Cisco APIC Release 2.3(x) and higher, regular EPGs can be deployed on core ports that are used
in 802.1Q tunnels.
• L3Outs are not supported on interfaces enabled for Dot1q Tunnels.
• FEX interfaces are not supported as members of a Dot1q Tunnel.
• Interfaces configured as breakout ports do not support 802.1Q tunnels.
• Interface-level statistics are supported for interfaces in Dot1q Tunnels, but statistics at the tunnel level
are not supported.
Note You can use ports, port-channels, or virtual port channels for interfaces included in a Dot1q Tunnel. Detailed
steps are included for configuring ports. See the examples below for the commands to configure edge and
core port-channels and virtual port channels.
Create a Dot1q Tunnel and configure the interfaces for use in the tunnel using the NX-OS Style CLI, with
the following steps:
Note Dot1q Tunnels must include 2 or more interfaces. Repeat the steps (or configure two interfaces together), to
mark each interface for use in a Dot1q Tunnel. In this example, two interfaces are configured as edge-switch
ports, used by a single customer.
Use the following steps to configure a Dot1q Tunnel using the NX-OS style CLI:
1. Configure at least two interfaces for use in the tunnel.
2. Create a Dot1q Tunnel.
3. Associate all the interfaces with the tunnel.
Procedure
Step 5 switchport mode dot1q-tunnel {edgePort | Marks the interfaces for use in an 802.1Q
corePort} tunnel, and then leaves the configuration mode.
Step 8 interface ethernet slot/port Returns to the interfaces included in the tunnel.
Example:
Step 9 switchport tenant tenant-name dot1q-tunnel Associates the interfaces to the tunnel and exits
tunnel-name the configuration mode.
Example:
apic1(config-leaf-if)# switchport
tenant tenant64 dot1q-tunnel
vrf64_edgetunnel
apic1(config-leaf-if)# exit
Example: Configuring an 802.1Q Tunnel Using Ports with the NX-OS Style CLI
The example marks two ports as edge port interfaces to be used in a Dot1q Tunnel, marks two more ports to
be used as core port interfaces, creates the tunnel, and associates the ports with the tunnel.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/13-14
apic1(config-leaf-if)# switchport mode dot1q-tunnel edgePort
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)leaf 102
apic1(config-leaf)# interface ethernet 1/10, 1/21
apic1(config-leaf-if)# switchport mode dot1q-tunnel corePort
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config-tenant-tunnel)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/13-14
apic1(config-leaf-if)# switchport tenant tenant64 dot1q-tunnel vrf64_tunnel
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# leaf 102
apic1(config-leaf)# interface ethernet 1/10, 1/21
apic1(config-leaf-if)# switchport tenant tenant64 dot1q-tunnel vrf64_tunnel
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
Example: Configuring an 802.1Q Tunnel Using Port-Channels with the NX-OS Style CLI
The example marks two port-channels as edge-port 802.1Q interfaces, marks two more port-channels as
core-port 802.1Q interfaces, creates a Dot1q Tunnel, and associates the port-channels with the tunnel.
apic1# configure
apic1(config)# tenant tenant64
apic1(config-tenant)# dot1q-tunnel vrf64_tunnel
apic1(config-tenant-tunnel)# l2protocol-tunnel cdp
apic1(config-tenant-tunnel)# l2protocol-tunnel lldp
apic1(config-tenant-tunnel)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface port-channel pc1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 1/2-3
apic1(config-leaf-if)# channel-group pc1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface port-channel pc1
apic1(config-leaf-if)# switchport mode dot1q-tunnel edgePort
apic1(config-leaf-if)# switchport tenant tenant64 dot1q-tunnel vrf64_tunnel
apic1(config-tenant-tunnel)# exit
apic1(config-tenant)# exit
Example: Configuring an 802.1Q Tunnel Using Virtual Port-Channels with the NX-OS Style CLI
The example marks two virtual port-channels (vPCs) as edge-port 802.1Q interfaces for theDot1q Tunnel,
marks two more vPCs as core-port interfaces for the tunnel, creates the tunnel, and associates the virtual
port-channels with the tunnel.
apic1# configure
apic1(config)# vpc domain explicit 1 leaf 101 102
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# interface vpc vpc1
apic1(config-vpc-if)# switchport mode dot1q-tunnel edgePort
apic1(config-vpc-if)# exit
apic1(config-vpc)# exit
apic1(config)# vpc domain explicit 1 leaf 103 104
apic1(config)# vpc context leaf 103 104
apic1(config-vpc)# interface vpc vpc2
apic1(config-vpc-if)# switchport mode dot1q-tunnel corePort
apic1(config-vpc-if)# exit
apic1(config-vpc)# exit
apic1(config)# tenant tenant64
apic1(config-tenant)# dot1q-tunnel vrf64_tunnel
apic1(config-tenant-tunnel)# l2protocol-tunnel cdp
apic1(config-tenant-tunnel)# l2protocol-tunnel lldp
apic1(config-tenant-tunnel)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 103
apic1(config-leaf)# interface ethernet 1/6
apic1(config-leaf-if)# channel-group vpc1 vpc
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# leaf 104
apic1(config-leaf)# interface ethernet 1/6
apic1(config-leaf-if)# channel-group vpc1 vpc
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config-vpc)# interface vpc vpc1
apic1(config-vpc-if)# switchport tenant tenant64 dot1q-tunnel vrf64_tunnel
apic1(config-vpc-if)# exit
Breakout enables a 40 Gigabit (Gb) port to be split into four independent and logical 10Gb ports or a 100Gb
port to be split into four independent and logical 25Gb ports.
Before you configure breakout ports, connect a 40Gb port to four 10Gb ports or a 100Gb port to four 25Gb
ports with one of the following cables:
• Cisco QSFP-4SFP10G
• Cisco QSFP-4SFP25G
The 40Gb to 10Gb dynamic breakout feature is supported on the access facing ports of the following switches:
• N9K-C9332PQ
• N9K-C93180LC-EX
• N9K-C9336C-FX
The 100Gb to 25Gb breakout feature is supported on the access facing ports of the following switches:
• N9K-C93180LC-EX
• N9K-C9336C-FX2
Procedure
Step 2 leaf ID Selects the leaf switch where the breakout port
will be located and enters leaf configuration
Example:
mode.
apic1(config)# leaf 101
Step 4 breakout 10g-4x | 25g-4x Enables the selected interface for breakout.
Example: Note For switch support for the Dynamic
apic1(config-leaf-if)# breakout 10g-4x Breakout Port feature, see
Configuration of Dynamic Breakout
Ports, on page 113.
Step 6 tenant tenant-name Selects or creates the tenant that will consume
the breakout ports and enters tenant
Example:
configuration mode.
apic1(config)# tenant tenant64
Step 7 vrf context vrf-name Creates or identifies the Virtual Routing and
Forwarding (VRF) instance associated with
Example:
the tenant and exits the configuration mode.
apic1(config-tenant)# vrf context vrf64
apic1(config-tenant-vrf)# exit
Step 11 epg epg-name Creates or identifies the EPG and enters into
EPG configuration mode.
Example:
apic1(config-tenant)# epg epg64
Step 12 bridge-domain member bridge-domain-name Associates the EPG with the bridge domain
and returns to global configuration mode.
Example:
apic1(config-tenant-app-epg)# Configure the sub ports as desired, for
bridge-domain member bd64 example, use the speed command in leaf
apic1(config-tenant-app-epg)# exit interface mode to configure a sub port.
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
Step 14 speed interface-speed Enters leaf interface mode, sets the speed of
an interface, and exits the configuration mode.
Example:
The port on leaf 101 at interface 1/16 is confirmed enabled for breakout with sub ports 1/16/1, 1/16/2, 1/16/3,
and 1/16/4.
Example
This example configures the port for breakout:
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/16
apic1(config-leaf-if)# breakout 10g-4x
This example sets the speed for the breakout sub ports to 10G.
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/16/1
apic1(config-leaf-if)# speed 10G
apic1(config-leaf-if)# exit
This example shows the four sub ports connected to leaf 101, interface 1/16.
apic1#(config-leaf)# show run
# Command: show running-config leaf 101
# Time: Fri Dec 2 00:51:08 2016
leaf 101
interface ethernet 1/16/1
speed 10G
negotiate auto
link debounce time 100
exit
interface ethernet 1/16/2
speed 10G
negotiate auto
Restrictions
Fast Link Failover policies and port profiles are not supported on the same port. If port profile is enabled,
Fast Link Failover cannot be enabled or vice versa.
The last 2 uplink ports of supported TOR switches cannot be converted to downlink ports (they are reserved
for uplink connections.)
Up to Cisco APIC Release 3.2, port profiles and breakout ports are not supported on the same ports.
Guidelines
In converting uplinks to downlinks and downlinks to uplinks, consider the following guidelines.
Subject Guideline
Decommissioning nodes If a decommissioned node has the Port Profile feature deployed on it, the port
with port profiles conversions are not removed even after decommissioning the node. It is
necessary to manually delete the configurations after decommission, for the
ports to return to the default state. To do this, log onto the switch, run the
setup-clean-config.sh script, and wait for it to run. Then, enter the reload
command.
FIPS When you enable or disable Federal Information Processing Standards (FIPS)
on a Cisco ACI fabric, you must reload each of the switches in the fabric for
the change to take effect. The configured scale profile setting is lost when you
issue the first reload after changing the FIPS configuration. The switch remains
operational, but it uses the default scale profile. This issue does not happen on
subsequent reloads if the FIPS configuration has not changed.
FIPS is supported on Cisco NX-OS release 13.1(1) or later.
If you must downgrade the firmware from a release that supports FIPS to a
release that does not support FIPS, you must first disable FIPS on the Cisco
ACI fabric and reload all the switches in the fabric for the FIPS configuration
change.
Maximum uplink port limit When the maximum uplink port limit is reached and ports 25 and 27 are
converted from uplink to downlink and back to uplink on Cisco 93180LC-EX
switches:
On Cisco 93180LC-EX Switches, ports 25 and 27 are the native uplink ports.
Using the port profile, if you convert port 25 and 27 to downlink ports, ports
29, 30, 31, and 32 are still available as four native uplink ports. Because of the
threshold on the number of ports (which is maximum of 12 ports) that can be
converted, you can convert 8 more downlink ports to uplink ports. For example,
ports 1, 3, 5, 7, 9, 13, 15, 17 are converted to uplink ports and ports 29, 30, 31
and 32 are the 4 native uplink ports (the maximum uplink port limit on Cisco
93180LC-EX switches).
When the switch is in this state and if the port profile configuration is deleted
on ports 25 and 27, ports 25 and 27 are converted back to uplink ports, but
there are already 12 uplink ports on the switch (as mentioned earlier). To
accommodate ports 25 and 27 as uplink ports, 2 random ports from the port
range 1, 3, 5, 7, 9, 13, 15, 17 are denied the uplink conversion and this situation
cannot be controlled by the user.
Therefore, it is mandatory to clear all the faults before reloading the leaf node
to avoid any unexpected behavior regarding the port type. It should be noted
that if a node is reloaded without clearing the port profile faults, especially
when there is a fault related to limit-exceed, the port might not be in an expected
operational state.
Breakout Limitations
N9K-C9332PQ Cisco APIC 2.2 (1n) and • 40Gb dynamic breakouts into 4X10Gb ports
higher are supported.
• Ports 13 and 14 do not support breakouts.
• Port profiles and breakouts are not supported
on the same port.
N9K-C93180LC-EX Cisco APIC 3.1(1i) and • 40Gb and 100Gb dynamic breakouts are
higher supported on ports 1 through 24 on odd
numbered ports.
• When the top ports (odd ports) are broken out,
then the bottom ports (even ports) are error
disabled.
• Port profiles and breakouts are not supported
on the same port.
N9K-C9336C-FX2 Cisco APIC 3.1(2m) and • 40Gb and 100Gb dynamic breakouts are
higher supported on ports 1 through 30.
• Port profiles and breakouts are not supported
on the same port.
Switch Model Default Links Max Uplinks (Fabric Max Downlinks Release
Ports) (Server Ports) Supported
Switch Model Default Links Max Uplinks (Fabric Max Downlinks Release
Ports) (Server Ports) Supported
6 x 40/100-Gbps 2 x 40/100-Gbps
QSFP28 uplinks QSFP28 uplinks
Switch Model Default Links Max Uplinks (Fabric Max Downlinks Release
Ports) (Server Ports) Supported
12 x 40/100-Gbps 2 x 40/100-Gbps
QSFP28 uplinks QSFP28 uplinks
• An APIC fabric administrator account is available that will enable creating or modifying the necessary
fabric infrastructure configurations.
• The target leaf switches are registered in the ACI fabric and available.
Procedure
Step 1 configure
Enters global configuration mode.
Example:
apic1# configure
Example:
apic1(config-leaf-if)# port-direction downlink
Step 5 Log on to the leaf switch where the port is located and enter the setup-clean-config.sh -k command, then the
reload command.
Verifying Port Profile Configuration and Conversion Using the NX-OS Style CLI
You can verify the configuration and the conversion of the ports using the show interface brief CLI command.
Note Port profile can be deployed only on the top ports of a Cisco N9K-C93180LC-EX switch, for example, 1, 3,
5, 7, 9, 11, 13, 15, 17, 19, 21, and 23. When the top port is converted using the port profile, the bottom ports
are hardware disabled. For example, if Eth 1/1 is converted using the port profile, Eth 1/2 is hardware disabled.
Procedure
Step 1 This example displays the output for converting an uplink port to downlink port. Before converting an uplink
port to downlink port, the output is displayed in the example. The keyword routed denotes the port as uplink
port.
Example:
Step 2 After configuring the port profile and reloading the switch, the output is displayed in the example. The keyword
trunk denotes the port as downlink port.
Example:
See the Cisco ACI Virtualization Guide for information about how Microsegmentation with Cisco ACI
works, prerequisites, guidelines, and scenarios.
Procedure
Example:
(Optional) This example sets match EPG precedence for the uSeg EPG:
apic1(config)# tenant Coke
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)# match-precedence 10
Example:
This example uses a filter based on the attribute VM Name.
Example:
This example uses a filter based on an IP address.
Example:
This example uses a filter based on a MAC address.
Example:
This example uses the operator AND to match all attributes and the operator OR to match any attribute.
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)# attribute-logical-expression 'hv equals host-123 OR (guest-os
equals "Ubuntu Linux (64-bit)" AND domain contains fex)'
Example:
This example uses a filter based on the attribute VM-Custom Attribute.
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-logical-expression 'custom <Custom Attribute Name>
equals <Custom Attribute value>'
Step 3 (Cisco ACI Virtual Edge only): Attach the uSeg EPG to a Cisco ACI Virtual Edge VMM domain, specifying
the switching and encapsulation modes:
Example:
vmware-domain member AVE-CISCO
switching-mode AVE
encap-mode vxlan
exit
Procedure
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
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)
bridge-domain cli-bd1
attribute cli-uepg-att match mac
00:11:22:33:44:55
exit
exit
exit
Note You can use vzAny to enable protocols such as IGMP Snooping for all the EPGs in a VRF. For more
information about vzAny, see Use vzAny to Automatically Apply Communication Rules to all EPGs in a
VRF.
To use vzAny, navigate to Tenants > tenant-name > Networking > VRFs > vrf-name > EPG Collection
for VRF.
Procedure
Step 2 Modify the snooping policy as necessary. The example NX-OS style CLI sequence:
Example: • Specifies a custom value for the
query-interval value in the IGMP Snooping
apic1(config-tenant-template-ip-igmp-snooping)# policy named cookieCut1.
ip igmp snooping query-interval 300
apic1(config-tenant-template-ip-igmp-snooping)# • Confirms the modified IGMP Snooping
show run all value for the policy cookieCut1.
# Command: show running -config all
tenant foo template ip igmp snooping
policy cookieCut1
#Time: Thu Oct 13 18:26:03 2016
tenant foo
template ip igmp snooping policy
cookieCut1
ip igmp snooping
no ip igmp snooping fast-leave
ip igmp snooping
last-member-query-interval 1
no ip igmp snooping querier
ip igmp snooping query-interval
300
ip igmp snooping
query-max-response-time 10
ip igmp snooping
stqrtup-query-count 2
ip igmp snooping
startup-query-interval 31
no description
exit
exit
apic1(config-tenant-template-ip-igmp-snooping)#
exit
apic1(config--tenant)#
Step 3 Assign the policy to a bridge domain. The example NX-OS style CLI sequence:
Example: • Navigates to bridge domain, BD3. for the
query-interval value in the IGMP Snooping
apic1(config-tenant)# int bridge-domain policy named cookieCut1.
bd3
apic1(config-tenant-interface)# ip igmp • Assigns the IGMP Snooping policy with
snooping policy cookieCut1 a modified IGMP Snooping value for the
policy cookieCut1.
What to do next
You can assign the IGMP Snooping policy to multiple bridge domains.
Enabling IGMP Snooping and Multicast on Static Ports in the NX-OS Style CLI
You can enable IGMP snooping and multicast on ports that have been statically assigned to an EPG. Then
you can create and assign access groups of users that are permitted or denied access to the IGMP snooping
and multicast traffic enabled on those ports.
The steps described in this task assume the pre-configuration of the following entities:
• Tenant: tenant_A
• Application: application_A
• EPG: epg_A
• Bridge Domain: bridge_domain_A
• vrf: vrf_A -- a member of bridge_domain_A
• VLAN Domain: vd_A (configured with a range of 300-310)
• Leaf switch: 101 and interface 1/10
The target interface 1/10 on switch 101 is associated with VLAN 305 and statically linked with tenant_A,
application_A, epg_A
• Leaf switch: 101 and interface 1/11
The target interface 1/11 on switch 101 is associated with VLAN 309 and statically linked with tenant_A,
application_A, epg_A
Note For details on static port assignment, see Deploying an EPG on a Specific Port
with APIC Using the NX-OS Style CLI in the Cisco APIC Layer 2 Networking
Configuration Guide.
• Identify the IP addresses that you want to be recipients of IGMP snooping multicast traffic.
Procedure
apic1# conf t
apic1(config)# tenant tenant_A;
application application_A; epg epg_A
apic1(config-tenant-app-epg)# ip igmp
snooping static-group 227.1.1.1 leaf 101
interface ethernet 1/11 vlan 309
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
Enabling Group Access to IGMP Snooping and Multicast using the NX-OS
Style CLI
After you have enabled IGMP snooping and multicast on ports that have been statically assigned to an EPG,
you can then create and assign access groups of users that are permitted or denied access to the IGMP snooping
and multicast traffic enabled on those ports.
The steps described in this task assume the pre-configuration of the following entities:
• Tenant: tenant_A
• Application: application_A
• EPG: epg_A
• Bridge Domain: bridge_domain_A
• vrf: vrf_A -- a member of bridge_domain_A
• VLAN Domain: vd_A (configured with a range of 300-310)
• Leaf switch: 101 and interface 1/10
The target interface 1/10 on switch 101 is associated with VLAN 305 and statically linked with tenant_A,
application_A, epg_A
Note For details on static port assignment, see Deploying an EPG on a Specific Port with APIC Using the NX-OS
Style CLI in the Cisco APIC Layer 2 Networking Configuration Guide.
Procedure
Step 3 Specify the access group connection path. The example sequences configure:
Example: • Route-map-access group "foobroker"
apic1(config-tenant)# application connected through leaf switch 101,
application_A interface 1/10, and VLAN 305.
apic1(config-tenant-app)# epg epg_A
Deploying an EPG on a Specific Port with APIC Using the NX-OS Style CLI
Procedure
apic1# configure
apic1(config)# tenant t1
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.
Step 2 [no] template policy-group policy-group-name Creates (or deletes) a policy group template.
Example:
apic1(config)#
template policy-group
PortSecGrp1
apic1(config-pol-grp-if)# switchport
access vlan 4 tenant ExampleCorp
application Web epg webEpg
Step 4 [no] switchport port-security maximum Sets the maximum number of secure MAC
number-of-addresses addresses for the port. The range is 0 to 12000
addresses. The default is 1 address.
Example:
apic1(config-pol-grp-if)#
switchport port-security maximum
1
Step 5 [no] switchport port-security violation Sets the action to be taken when a security
protect violation is detected. The protect action drops
packets with unknown source addresses until
Example:
you remove a sufficient number of secure MAC
apic1(config-pol-grp-if)# addresses to drop below the maximum value.
switchport port-security
violation protect
Example
This example shows how to create a port security policy group template.
apic1# configure
apic1(config)# template policy-group PortSecGrp1
apic1(config-pol-grp-if)# switchport port-security maximum 20
apic1(config-pol-grp-if)# switchport port-security violation protect
apic1(config-pol-grp-if)# exit
What to do next
Apply the port security template to an interface.
Procedure
Step 4 [no] policy-group policy-group-name Applies the policy group template to the port
or range of ports.
Example:
apic1(config-leaf-if)# policy-group
PortSecGrp1
Example
This example shows how to apply a port security policy group template to a range of Ethernet ports.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/2-4
apic1(config-leaf-if)# policy-group PortSecGrp1
This example shows how to configure port security on a port channel using a template.
apic1# configure
apic1(config)# template port-channel po1
apic1(config-if)# switchport port-security maximum 10
apic1(config-if)# switchport port-security violation protect
apic1(config-if)# exit
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/3-4
apic1(config-leaf-if)# channel-group po1
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
Step 4 [no] switchport port-security maximum Sets the maximum number of secure MAC
number-of-addresses addresses for the interface. The range is 0 to
12000 addresses. The default is 1 address.
Example:
apic1(config-leaf-if)# switchport
port-security maximum 1
Step 5 [no] switchport port-security violation Sets the action to be taken when a security
protect violation is detected. The protect action drops
packets with unknown source addresses until
Example:
you remove a sufficient number of secure MAC
apic1(config-leaf-if)# switchport addresses to drop below the maximum value.
port-security violation protect
Example
This example shows how to configure port security on an Ethernet interface.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/2
apic1(config-leaf-if)# switchport port-security maximum 10
apic1(config-leaf-if)# switchport port-security violation protect
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface port-channel po2
apic1(config-leaf-if)# switchport port-security maximum 10
apic1(config-leaf-if)# switchport port-security violation protect
This example shows how to configure port security on a virtual port channel (VPC).
apic1# configure
apic1(config)# vpc domain explicit 1 leaf 101 102
apic1(config-vpc)# exit
apic1(config)# template port-channel po4
apic1(config-if)# exit
apic1(config)# leaf 101-102
apic1(config-leaf)# interface eth 1/11-12
apic1(config-leaf-if)# channel-group po4 vpc
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# vpc context leaf 101 102
apic1(config-vpc)# interface vpc po4
apic1(config-vpc-if)# switchport port-security maximum 10
apic1(config-vpc-if)# switchport port-security violation protect
Procedure
Step 4 Configure host mode (two modes are supported: multi-host and single-host - single being the default setting):
Example:
apic1(config-port-authentication)# host-mode multi-host
apic1(config-port-authentication)# no shutdown
apic1(config-port-authentication)# exit
apic1(config-pol-grp-if)# exit
apic1(config)#
Step 7 Configure a policy group for the leaf switch interface profile:
Example:
apic1(config-leaf-if-profile)#leaf-interface-group mygroup
Step 11 Configure the leaf policy group and specify leaf switch nodes for the group:
Example:
apic1(config-leaf-profile)# leaf-group myleafgrp
apic1(config-leaf-group)# leaf 101
apic1(config-leaf-group)# exit
Procedure
apic1# configure
apic1(config)#
Step 6 Configure policy group and specify port authentication policy in the group:
Example:
apic1(config)#template leaf-policy-group lpg2
apic1(config-leaf-policy-group)# port-authentication mydot1x
apic1(config-leaf-policy-group)#exit
Step 8 Configure a group for the leaf switch profile and specify the policy group:
Example:
apic1(config-leaf-profile)#leaf-group mylg2
apic1(config-leaf-group)# leaf-policy-group lpg2
apic1(config-leaf-group)#exit
Proxy ARP within the Cisco ACI fabric is different from the traditional proxy ARP. As an example of the
communication process, when proxy ARP is enabled on an EPG, if an endpoint A sends an ARP request for
endpoint B and if endpoint B is learned within the fabric, then endpoint A will receive a proxy ARP response
from the bridge domain (BD) MAC. If endpoint A sends an ARP request for endpoint B, and if endpoint B
is not learned within the ACI fabric already, then the fabric will send a proxy ARP request within the BD.
Endpoint B will respond to this proxy ARP request back to the fabric. At this point, the fabric does not send
a proxy ARP response to endpoint A, but endpoint B is learned within the fabric. If endpoint A sends another
ARP request to endpoint B, then the fabric will send a proxy ARP response from the BD MAC.
The following example describes the proxy ARP resolution steps for communication between clients VM1
and VM2:
1. VM1 to VM2 communication is desired.
Device State
VM1 IP = * MAC = *
VM2 IP = * MAC = *
Device State
VM2 IP = * MAC = *
3. The ACI fabric floods the proxy ARP request within the bridge domain (BD).
Figure 10: ACI Fabric Floods the Proxy ARP Request within the BD
Device State
Device State
5. VM2 is learned.
Figure 12: VM2 is Learned
Device State
Device State
Device State
• Intra-EPG isolation must be enabled on the EPG where proxy ARP has to be enabled.
Procedure
apic1(config-tenant)# application
Tenant1-App
Step 4 epg application-profile-EPG-name Creates an EPG and enter the EPG mode.
Example:
apic1(config-tenant-app)# epg
Tenant1-epg1
Examples
This example shows how to configure proxy ARP.
apic1# conf t
apic1(config)# tenant Tenant1
apic1(config-tenant)# application Tenant1-App
apic1(config-tenant-app)# epg Tenant1-epg1
apic1(config-tenant-app-epg)# proxy-arp enable
apic1(config-tenant-app-epg)#
apic1(config-tenant)#
Procedure
Step 4 epg application-profile-EPG-name Creates an EPG and enter the EPG mode.
Example:
apic1(config)# epg Tenant1-epg1
• Beginning with the APIC Release 4.2(1), support is now available for triggering SNMP traps from Cisco
ACI when storm control thresholds are met, with the following restrictions:
• There are two actions associated with storm control: drop and shutdown. With the shutdown action,
interface traps will be raised, but the storm control traps to indicate that the storm is active or clear
is not determined by the shutdown action. Storm control traps with the shutdown action on the
policy should therefore be ignored.
• If the ports flap with the storm control policy on, clear and active traps are seen together when the
stats are collected. Clear and active traps are typically not seen together, but this is expected behavior
in this case.
• For port channels and virtual port channels, the storm control values (packets per second or percentage)
apply to all individual members of the port channel. Do not configure storm control on interfaces that
are members of a port channel.
Note On switch hardware starting with the APIC 1.3(x) and switch 11.3(x) release, for
port channel configurations, the traffic suppression on the aggregated port may
be up to two times the configured value. The new hardware ports are internally
subdivided into these two groups: slice-0 and slice-1. To check the slicing map,
use the vsh_lc command show platform internal hal l2 port gpd and look
for slice 0 or slice 1 under the Sl column. If port-channel members fall on
both slice-0 and slice-1, allowed storm control traffic may become twice the
configured value because the formula is calculated based on each slice.
• When configuring by percentage of available bandwidth, a value of 100 means no traffic storm control
and a value of 0.01 suppresses all traffic.
• Due to hardware limitations and the method by which packets of different sizes are counted, the level
percentage is an approximation. Depending on the sizes of the frames that make up the incoming traffic,
the actual enforced level might differ from the configured level by several percentage points.
Packets-per-second (PPS) values are converted to percentage based on 256 bytes.
• Maximum burst is the maximum accumulation of rate that is allowed when no traffic passes. When traffic
starts, all the traffic up to the accumulated rate is allowed in the first interval. In subsequent intervals,
traffic is allowed only up to the configured rate. The maximum supported is 65535 KB. If the configured
rate exceeds this value, it is capped at this value for both PPS and percentage.
• The maximum burst that can be accumulated is 512 MB.
• On an egress leaf switch in optimized multicast flooding (OMF) mode, traffic storm control will not be
applied.
• On an egress leaf switch in non-OMF mode, traffic storm control will be applied.
• On a leaf switch for FEX, traffic storm control is not available on host-facing interfaces.
• Traffic storm control unicast/multicast differentiation is not supported on Cisco Nexus C93128TX,
C9396PX, C9396TX, C93120TX, C9332PQ, C9372PX, C9372TX, C9372PX-E, or C9372TX-E switches.
• SNMP traps for traffic storm control are not supported on Cisco Nexus C93128TX, C9396PX, C9396TX,
C93120TX, C9332PQ, C9372PX, C9372TX, C9372PX-E, C9372TX-E switches.
• Traffic storm control traps is not supported on Cisco Nexus C93128TX, C9396PX, C9396TX, C93120TX,
C9332PQ, C9372PX, C9372TX, C9372PX-E, or C9372TX-E switches.
• Storm Control Action is supported only on physical Ethernet interfaces and port-channel interfaces.
Starting with release 4.1(1), Storm Control Shutdown option is supported. When the shutdown action
is selected for an interface with the default Soak Instance Count, the packets exceeding the threshold are
dropped for 3 seconds and the port is shutdown on the 3rd second. The default action is Drop. When
Shutdown action is selected, the user has the option to specify the soaking interval. The default soaking
interval is 3 seconds. The configurable range is from 3 to 10 seconds.
• Starting with release 4.1(1), Error Disable Recovery option for storm-control is supported for the ports
which are in-error-disabled state due to storm shutdown action.
Configuring a Traffic Storm Control Policy Using the NX-OS Style CLI
Procedure
sd-tb2-ifc1(config-leaf)# interface
ethernet 1/19
sd-tb2-ifc1(config-leaf-if)#
storm-control unicast level 35 burst-rate
45
sd-tb2-ifc1(config-leaf-if)#
storm-control broadcast level 36
burst-rate 36
sd-tb2-ifc1(config-leaf-if)#
storm-control broadcast level 37
burst-rate 38
sd-tb2-ifc1(config-leaf-if)#
sd-tb2-ifc1(config-leaf)# interface
ethernet 1/19
sd-tb2-ifc1(config-leaf-if)#
storm-control broadcast pps 5000
burst-rate 6000
Configuring MACsec
About MACsec
MACsec is an IEEE 802.1AE standards based Layer 2 hop-by-hop encryption that provides data confidentiality
and integrity for media access independent protocols.
MACsec, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption
keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the
required encryption keys.
The 802.1AE encryption with MKA is supported on all types of links, that is, host facing links (links between
network access devices and endpoint devices such as a PC or IP phone), or links connected to other switches
or routers.
MACsec encrypts the entire data except for the Source and Destination MAC addresses of an Ethernet packet.
The user also has the option to skip encryption up to 50 bytes after the source and destination MAC address.
To provide MACsec services over the WAN or Metro Ethernet, service providers offer Layer 2 transparent
services such as E-Line or E-LAN using various transport layer protocols such as Ethernet over Multiprotocol
Label Switching (EoMPLS) and L2TPv3.
The packet body in an EAP-over-LAN (EAPOL) Protocol Data Unit (PDU) is referred to as a MACsec Key
Agreement PDU (MKPDU). When no MKPDU is received from a participants after 3 hearbeats (each hearbeat
is of 2 seconds), peers are deleted from the live peer list. For example, if a client disconnects, the participant
on the switch continues to operate MKA until 3 heartbeats have elapsed after the last MKPDU is received
from the client.
A node can have multiple policies deployed for more than one fabric link. When this happens, the per fabric
interface keychain and policy are given preference on the affected interface. The auto generated keychain and
associated MACsec policy are then given the least preference.
APIC MACsec supports two security modes. The MACsec must secure only allows encrypted traffic on the
link while the should secure allows both clear and encrypted traffic on the link. Before deploying MACsec
in must secure mode, the keychain must be deployed on the affected links or the links will go down. For
example, a port can turn on MACsec in must secure mode before its peer has received its keychain resulting
in the link going down. To address this issue the recommendation is to deploy MACsec in should secure
mode and once all the links are up then change the security mode to must secure.
Note Any MACsec interface configuration change will result in packet drops.
MACsec policy definition consists of configuration specific to keychain definition and configuration related
to feature functionality. The keychain definition and feature functionality definitions are placed in separate
policies. Enabling MACsec per Pod or per interface involves deploying a combination of a keychain policy
and MACsec functionality policy.
Note Using internal generated keychains do not require the user to specify a keychain.
• For PC/vPC interface, MACsec can be deployed via policy groups per PC/vPC interface. Port selectors
are used to deploy the policies to a particular set of ports. Therefore, it is the user’s responsibility to
create the right port selector corresponding to the L3Out interfaces.
• It is recommended that MACsec polices be configured to should-secure mode before a configuration is
exported.
• All the links on a spine are considered fabric links. However, if a spine link is used for IPN connectivity,
then this link will be treated as an access link. This means that MACsec access policy needs to be used
to deploy MACsec on these links.
• If a remote leaf fabric link is used for IPN connectivity, then this link will be treated as an access link.
A MACsec access policy needs to be used to deploy MACsec on these links.
• Improper deployment of must-secure mode on remote leaf fabric links can result in loss of connectivity
to the fabric. Follow the instructions provided in Deploying must-secure mode, on page 157 to prevent
such issues.
• MACSEC Sessions may take up to a minute to form or tear down when a new key is added to an empty
keychain or an active key is deleted from keychain.
• The following procedure should be followed to disable/remove a MACsec policy deployed in must-secure
mode:
• Change the MACsec policy to should-secure.
• Verify that the affected interfaces are using should-secure mode.
• Disable/remove the MACsec policy.
Keychain Definition
• There should be one key in the keychain with a start time of now. If must-secure is deployed with a
keychain that doesn’t have a key that is immediately active then traffic will be blocked on that link until
the key becomes current and a MACsec session is started. If should-secure mode is being used then
traffic will be unencrypted until the key becomes current and a MACsec session has started.
• There should be one key in the keychain with an end time of infinite. When a keychain expires, then
traffic is blocked on affected interfaces which are configured for must-secure mode. Interfaces configured
for should-secure mode transmit unencrypted traffic.
• There should be overlaps in the end time and start time of keys that are used sequentially to ensure the
MACsec session stays up when there is a transition between keys.
Example:
apic1# configure
apic1(config)# template macsec access keychain acckeychainpol1
apic1(config-macsec-keychain)# description 'macsec key chain kc1'
apic1(config-macsec-keychain)# key 12ab
apic1(config-macsec-keychain-key)# life-time start 2017-09-19T12:03:15 end
2017-12-19T12:03:15
apic1(config-macsec-keychain-key)# psk-string 123456789a223456789a323456789abc
apic1(config-macsec-keychain-key)# exit
apic1(config-macsec-keychain)# key ab12
apic1(config-macsec-keychain-key)# life-time start now end infinite
apic1(config-macsec-keychain-key)# life-time start now end infinite
apic1(config-macsec-keychain-key)# psk-string
Enter PSK string: 123456789a223456789a323456789abc
apic1(config-macsec-keychain-key)# exit
apic1(config-macsec-keychain)# exit
apic1(config)#
Step 4 Associate MACsec interface policy to access interfaces on leaf (or spine):
Example:
apic1# configure
apic1(config)# template macsec access interface-policy accmacsecifpol1
apic1(config-macsec-if-policy)# inherit macsec security-policy accmacsecpol1 keychain
acckeychainpol1
apic1(config-macsec-if-policy)# exit
apic1(config)
Example:
apic1# configure
apic1(config)# template macsec fabric security-policy fabmacsecpol1
apic1(config-macsec-param)# cipher-suite gcm-aes-xpn-128
apic1(config-macsec-param)# description 'description for mac sec parameters'
apic1(config-macsec-param)# window-size 1
apic1(config-macsec-param)# sak-expiry-time 100
apic1(config-macsec-param)# security-mode must-secure
apic1(config-macsec-param)# exit
apic1(config)# template macsec fabric keychain fabkeychainpol1
apic1(config-macsec-keychain)# description 'macsec key chain kc1'
apic1(config-macsec-keychain)# key 12ab
apic1(config-macsec-keychain-key)# psk-string 123456789a223456789a323456789abc
apic1(config-macsec-keychain-key)# life-time start 2016-09-19T12:03:15 end
2017-09-19T12:03:15
apic1(config-macsec-keychain-key)# exit
apic1(config-macsec-keychain)# key cd78
apic1(config-macsec-keychain-key)# psk-string
Step 7 Associate MACsec interface policy to fabric interfaces on leaf (or spine):
Example:
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# fabric-interface ethernet 1/52-53
apic1(config-leaf-if)# inherit macsec interface-policy fabmacsecifpol2
apic1(config-leaf-if)# exit
apic1(config-leaf)#
• Implicit mode, a simpler mode, is not compatible with the APIC GUI or the REST API.
• Named (or Explicit) mode is compatible with the APIC GUI and the REST API.
In either case, the configuration should be considered read-only in the incompatible UI.
Note Except for the procedures in the Configuring Layer 3 External Connectivity Using the Named Mode section,
this guide describes Implicit mode procedures.
• Layer 3 external network objects (l3extOut) created using the Implicit mode CLI procedures are identified
by names starting with “__ui_” and are marked as read-only in the GUI. The CLI partitions these
external-l3 networks by function, such as interfaces, protocols, route-map, and EPG. Configuration
modifications performed through the REST API can break this structure, preventing further modification
through the CLI.
For the steps to remove such objects, see Troubleshooting Unwanted _ui_ Objects in the APIC Troubleshooting
Guide.
The steps for configuring layer 3 external connectivity can be summarized as follows:
1. Create a VRF under a tenant.
2. Configure and deploy the VRF on the border leaf switch.
3. Configure layer 3 interfaces on the border leaf Interfaces.
4. Configure route-maps on the leaf switch.
5. Configure routing protocols (BGP, OSPF, EIGRP) under leaf and leaf-interface.
6. Create and configure an external-L3 EPG under a tenant.
7. Deploy the external-L3 EPG on the border leaf switch.
Note For guidelines and cautions for configuring and maintaining Layer 3 outside connections, see Guidelines for
Routed Connectivity to Outside Networks, on page 165.
For information about the types of L3Outs, see External Layer 3 Outside Connection Types, on page 167.
A Layer 3 external outside network (l3extOut object) includes the routing protocol options (BGP, OSPF, or
EIGRP or supported combinations) and the switch-specific and interface-specific configurations. While the
l3extOut contains the routing protocol (for example, OSPF with its related Virtual Routing and Forwarding
(VRF) and area ID), the Layer 3 external interface profile contains the necessary OSPF interface details. Both
are needed to enable OSPF.
The l3extInstP EPG exposes the external network to tenant EPGs through a contract. For example, a tenant
EPG that contains a group of web servers could communicate through a contract with the l3extInstP EPG
according to the network configuration contained in the l3extOut. The outside network configuration can
easily be reused for multiple nodes by associating the nodes with the L3 external node profile. Multiple nodes
that use the same profile can be configured for fail-over or load balancing. Also, a node can be added to
multiple l3extOuts resulting in VRFs that are associated with the l3extOuts also being deployed on that node.
For scalability information, refer to the current Verified Scalability Guide for Cisco ACI.
Updates through CLI For Layer 3 external networks created through the API or GUI and
updated through the CLI, protocols need to be enabled globally on
the external network through the API or GUI, and the node profile
for all the participating nodes needs to be added through the API or
GUI before doing any further updates through the CLI.
Loopbacks for Layer 3 networks on When configuring two Layer 3 external networks on the same node,
same node the loopbacks need to be configured separately for both Layer 3
networks.
Ingress-based policy enforcement Starting with Cisco APIC release 1.2(1), ingress-based policy
enforcement enables defining policy enforcement for Layer 3 Outside
(L3Out) traffic for both egress and ingress directions. The default is
ingress. During an upgrade to release 1.2(1) or higher, existing L3Out
configurations are set to egress so that the behavior is consistent with
the existing configuration. You do not need any special upgrade
sequence. After the upgrade, you change the global property value
to ingress. When it has been changed, the system reprograms the
rules and prefix entries. Rules are removed from the egress leaf and
installed on the ingress leaf, if not already present. If not already
configured, an Actrl prefix entry is installed on the ingress leaf.
Direct server return (DSR), and attribute EPGs require ingress based
policy enforcement. vzAny and taboo contracts ignore ingress based
policy enforcement. Transit rules are applied at ingress.
Bridge Domains with L3Outs A bridge domain in a tenant can contain a public subnet that is
advertised through an l3extOut provisioned in the common tenant.
Bridge domain route advertisement For When both OSPF and EIGRP are enabled on the same VRF on a
OSPF and EIGRP node and if the bridge domain subnets are advertised out of one of
the L3Outs, it will also get advertised out of the protocol enabled on
the other L3Out.
For OSPF and EIGRP, the bridge domain route advertisement is per
VRF and not per L3Out. The same behavior is expected when
multiple OSPF L3Outs (for multiple areas) are enabled on the same
VRF and node. In this case, the bridge domain route will be
advertised out of all the areas, if it is enabled on one of them.
BGP Maximum Prefix Limit Starting with Cisco APIC release 1.2(1x), tenant policies for BGP
l3extOut connections can be configured with a maximum prefix
limit, that enables monitoring and restricting the number of route
prefixes received from a peer. Once the maximum prefix limit has
been exceeded, a log entry is recorded, and further prefixes are
rejected. The connection can be restarted if the count drops below
the threshold in a fixed interval, or the connection is shut down. Only
one option can be used at a time. The default setting is a limit of
20,000 prefixes, after which new prefixes are rejected. When the
reject option is deployed, BGP accepts one more prefix beyond the
configured limit, before the APIC raises a fault.
MTU Cisco ACI does not support IP fragmentation. Therefore, when you
configure Layer 3 Outside (L3Out) connections to external routers,
or multipod connections through an Inter-Pod Network (IPN), it is
critical that the interface MTU is set appropriately on both ends of
a link. On some platforms, such as Cisco ACI, Cisco NX-OS, and
Cisco IOS, the configurable MTU value does not take into account
the ethernet headers (matching IP MTU, and excluding the 14-18
ethernet header size), while other platforms, such as IOS-XR, include
the ethernet header in the configured MTU value. A configured value
of 9000 results in a max IP packet size of 9000 bytes in Cisco ACI,
Cisco NX-OS, and Cisco IOS, but results in a max IP packet size of
8986 bytes for an IOS-XR untagged interface.
For the appropriate MTU values for each platform, see the relevant
configuration guides.
Cisco highly recommends that you test the MTU with CLI-based
commands. For example, on the Cisco NX-OS CLI, use a command
such as ping 1.1.1.1 df-bit packet-size 9000
source-interface ethernet 1/1.
Layer 4 to Layer 7 When you are using a multinode service graph, you must have the
two EPGs in separate VRF instances. For these functions, the system
must do a Layer 3 lookup, so the EPGs must be in separate VRFs.
This limitation follows legacy service insertion, based on Layer 2
and Layer 3 lookups.
QoS for L3Outs To configure QoS policies for an L3Out and enable the policies to
be enforced on the BL switch where the L3Out is located, use the
following guidelines:
• The VRF Policy Control Enforcement Direction must be set
toEgress.
• The VRF Policy Control Enforcement Preference must be set
to Enabled.
• When configuring the contract that controls communication
between the EPGs using the L3Out, include the QoS class or
Target DSCP in the contract or subject of the contract.
The External Layer 3 Outside connections are supported on the following interfaces:
• Layer 3 Routed Interface
• Subinterface with 802.1Q tagging - With subinterface, you can use the same physical interface to provide
a Layer 2 outside connection for multiple private networks.
• Switched Virtual Interface (SVI) - With an SVI interface, the same physical interface that supports Layer
2 and Layer 3 and the same physical interface can be used for a Layer 2 outside connection and a Layer
3 outside connection.
The managed objects that are used for the L3Outside connections are:
• External Layer 3 Outside (L3ext): Routing protocol options (OSPF area type, area, EIGRP autonomous
system, BGP), private network, External Physical domain.
• Logical Node Profile: Profile where one or more nodes are defined for the External Layer 3 Outside
connections. The configurations of the router-IDs and the loopback interface are defined in the profile.
Note Use the same router-ID for the same node across multiple External Layer 3 Outside
connections.
Note Within a single L3Out, a node can only be part of one Logical Node Profile.
Configuring the node to be a part of multiple Logical Node Profiles in a single
L3Out might result in unpredictable behavior, such as having a loopback address
pushed from one Logical Node Profile but not from the other. Use more path
bindings under the existing Logical Interface Profiles or create a new Logical
Interface Profile under the existing Logical Node Profile instead.
• Logical Interface Profile: IP interface configuration for IPv4 and IPv6 interfaces. It is supported on the
Route Interfaces, Routed subinterfaces, and SVIs. The SVIs can be configured on physical ports,
port-channels, or vPCs.
• OSPF Interface Policy: Includes details such as OSPF Network Type and priority.
• EIGRP Interface Policy: Includes details such as Timers and split horizon.
• BGP Peer Connectivity Profile: The profile where most BGP peer settings, remote-as, local-as, and BGP
peer connection options are configured. You can associate the BGP peer connectivity profile with the
logical interface profile or the loopback interface under the node profile. This determines the update-source
configuration for the BGP peering session.
• External Network Instance Profile (EPG) (l3extInstP): The external EPG is also referred to as the
prefix-based EPG or InstP. The import and export route control policies, security import policies, and
contract associations are defined in this profile. You can configure multiple external EPGs under a single
L3Out. You may use multiple external EPGs when a different route or a security policy is defined on a
single External Layer 3 Outside connections. An external EPG or multiple external EPGs combine into
a route-map. The import/export subnets defined under the external EPG associate to the IP prefix-list
match clauses in the route-map. The external EPG is also where the import security subnets and contracts
are associated. This is used to permit or drop traffic for this L3out.
• Action Rules Profile: The action rules profile is used to define the route-map set clauses for the L3Out.
The supported set clauses are the BGP communities (standard and extended), Tags, Preference, Metric,
and Metric type.
• Route Control Profile: The route-control profile is used to reference the action rules profiles. This can
be an ordered list of action rules profiles. The Route Control Profile can be referenced by a tenant BD,
BD subnet, external EPG, or external EPG subnet.
There are more protocol settings for BGP, OSPF, and EIGRP L3Outs. These settings are configured per tenant
in the ACI Protocol Policies section in the GUI.
Note When configuring policy enforcement between external EPGs (transit routing case), you must configure the
second external EPG (InstP) with the default prefix 0/0 for export route control, aggregate export, and external
security. In addition, you must exclude the preferred group, and you must use an any contract (or desired
contract) between the transit InstPs.
Configuring a Layer 3 Outside for Tenant Networks Using the NX-OS Style CLI
These steps describe how to configure a Layer 3 outside network for tenant networks. This example shows
how to deploy a node and L3 port for tenant VRF external L3 connectivity using the NX-OS CLI.
This example is broken into steps for clarity. For a merged example, see NX-OS Style CLI Example: L3Out,
on page 173.
• Configure a BGP route reflector policy to propagate the routed within the fabric.
For an example using the commands for these prerequisites, see NX-OS Style CLI Example: L3Out
Prerequisites, on page 173.
Procedure
Example:
apic1(config)# leaf 103
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# router-id 11.11.11.103
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# interface ethernet 1/3
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant t1 vrf v1
apic1(config-leaf-if)# ip address 12.12.12.3/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
Example:
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# route-map rp1
apic1(config-leaf-vrf-route-map)# match bridge-domain bd1 tenant t1
apic1(config-leaf-vrf-route-map-match)# exit
apic1(config-leaf-vrf-route-map)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# exit
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 100
apic1(config-bgp-fabric)# route-reflector spine 104,105
apic1(config-route-group)# exit
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# route-map rp1
apic1(config-leaf-vrf-route-map)# match route group match-rule1 order 0
apic1(config-leaf-vrf-route-map-match)# exit
apic1(config-leaf-vrf-route-map)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# router bgp 100
apic1(config-leaf-bgp)# vrf member tenant t1 vrf v1
apic1(config-leaf-bgp-vrf)# neighbor 15.15.15.2
apic1(config-leaf-bgp-vrf-neighbor)# route-map rp1 in
apic1(config-leaf-bgp-vrf-neighbor)#exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf-bgp)# exit
apic1(config-leaf)# exit
apic1(config)# tenant t1
apic1(config-tenant)# bridge-domain bd1
apic1(config-tenant-bd)# vrf member v1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# interface bridge-domain bd1
apic1(config-tenant-interface)# ip address 44.44.44.1/24 scope public
apic1(config-tenant-interface)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# route-map map1
apic1(config-leaf-vrf-route-map)# match bridge-domain bd1 tenant t1
apic1(config-leaf-vrf-route-map-match)# exit
apic1(config-leaf-vrf-route-map)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# exit
apic1(config)# tenant t1
apic1(config-tenant)# application app1
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
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/3
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# switchport trunk allowed vlan 2011 tenant t1 application app1 epg
epg1
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# tenant t1
apic1(config-tenant)# access-list http-filter
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# exit
apic1(config-tenant)# contract httpCtrct
apic1(config-tenant-contract)# scope vrf
apic1(config-tenant-contract)# subject subj1
apic1(config-tenant-contract-subj)# access-group http-filter both
apic1(config-tenant-contract-subj)# exit
apic1(config-tenant-contract)# exit
apic1(config-tenant)# external-l3 epg extnw1
apic1(config-tenant-l3ext-epg)# vrf member v1
apic1(config-tenant-l3ext-epg)# contract provider httpCtrct
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# application app1
apic1(config-tenant-app)# epg epg1
apic1(config-tenant-app-epg)# contract consumer httpCtrct
apic1(config-tenant-app-epg)# exit
apic1(config-tenant-app)# exit
apic1(config-tenant)# exit
apic1(config)#
Note Layer 3 routed and sub-interface port channels on border leaf switches are supported only on new generation
switches, which are switch models with "EX", "FX" or "FX2" at the end of the switch name.
Procedure
Step 3 interface port-channel channel-name Enters the interface configuration mode for the
specified port channel.
Example:
Step 5 vrf member vrf-name tenant tenant-name Associates this port channel to this virtual
routing and forwarding (VRF) instance and L3
Example:
outside policy, where:
apic1(config-leaf-if)# vrf member v1
tenant t1 • vrf-name is the VRF name. The name can
be any case-sensitive, alphanumeric string
up to 32 characters.
• tenant-name is the tenant name. The name
can be any case-sensitive, alphanumeric
string up to 32 characters.
Step 6 vlan-domain member vlan-domain-name Associates the port channel template with the
previously configured VLAN domain.
Example:
apic1(config-leaf-if)# vlan-domain
member dom1
Step 7 ip address ip-address/subnet-mask Sets the IP address and subnet mask for the
specified interface.
Example:
apic1(config-leaf-if)# ip address
10.1.1.1/24
Step 8 ipv6 address sub-bits/prefix-length preferred Configures an IPv6 address based on an IPv6
general prefix and enables IPv6 processing on
Example:
an interface, where:
apic1(config-leaf-if)# ipv6 address
2001::1/64 preferred • sub-bits is the subprefix bits and host bits
of the address to be concatenated with the
prefixes provided by the general prefix
specified with the prefix-name argument.
The sub-bits argument must be in the
form documented in RFC 2373 where the
address is specified in hexadecimal using
16-bit values between colons.
• prefix-length is the length of the IPv6
prefix. A decimal value that indicates how
many of the high-order contiguous bits
of the address comprise the prefix (the
network portion of the address). A slash
mark must precede the decimal value.
Step 11 mtu mtu-value Sets the MTU for this class of service.
Example:
apic1(config-leaf-if)# mtu 1500
Example
This example shows how to configure a basic Layer 3 port channel.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface port-channel po1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member v1 tenant t1
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# ip address 10.1.1.1/24
apic1(config-leaf-if)# ipv6 address 2001::1/64 preferred
apic1(config-leaf-if)# ipv6 link-local fe80::1
apic1(config-leaf-if)# mac-address 00:44:55:66:55::01
apic1(config-leaf-if)# mtu 1500
Procedure
Step 3 vrf member vrf-name tenant tenant-name Associates this port channel to this virtual
routing and forwarding (VRF) instance and L3
Example:
outside policy, where:, where:
apic1(config-leaf-if)# vrf member v1
tenant t1 • vrf-name is the VRF name. The name can
be any case-sensitive, alphanumeric string
up to 32 characters.
• tenant-name is the tenant name. The name
can be any case-sensitive, alphanumeric
string up to 32 characters.
Step 4 vlan-domain member vlan-domain-name Associates the port channel template with the
previously configured VLAN domain.
Example:
apic1(config-leaf-if)# vlan-domain
member dom1
Step 5 ip address ip-address / subnet-mask Sets the IP address and subnet mask for the
specified interface.
Example:
apic1(config-leaf-if)# ip address
10.1.1.1/24
Step 6 ipv6 address sub-bits / prefix-length Configures an IPv6 address based on an IPv6
preferred general prefix and enables IPv6 processing on
an interface, where:
Example:
apic1(config-leaf-if)# ipv6 address • sub-bits is the subprefix bits and host bits
2001::1/64 preferred of the address to be concatenated with the
prefixes provided by the general prefix
specified with the prefix-name argument.
The sub-bits argument must be in the
form documented in RFC 2373 where the
address is specified in hexadecimal using
16-bit values between colons.
• prefix-length is the length of the IPv6
prefix. A decimal value that indicates how
many of the high-order contiguous bits
of the address comprise the prefix (the
network portion of the address). A slash
mark must precede the decimal value.
Step 9 mtu mtu-value Sets the MTU for this class of service.
Example:
apic1(config-leaf-if)# mtu 1500
Step 11 interface port-channel channel-name Enters the interface configuration mode for the
specified port channel.
Example:
apic1(config-leaf)# interface
port-channel po1
Step 12 vlan-domain member vlan-domain-name Associates the port channel template with the
previously configured VLAN domain.
Example:
apic1(config-leaf-if)# vlan-domain
member dom1
Step 14 interface port-channel channel-name.number Enters the interface configuration mode for the
specified sub-interface port channel.
Example:
apic1(config-leaf)# interface
port-channel po1.2001
Step 15 vrf member vrf-name tenant tenant-name Associates this port channel to this virtual
routing and forwarding (VRF) instance and L3
Example:
outside policy, where:, where:
apic1(config-leaf-if)# vrf member v1
tenant t1 • vrf-name is the VRF name. The name can
be any case-sensitive, alphanumeric string
up to 32 characters.
• tenant-name is the tenant name. The name
can be any case-sensitive, alphanumeric
string up to 32 characters.
Example
This example shows how to configure a basic Layer 3 sub-interface port-channel.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface vlan 2001
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member v1 tenant t1
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# ip address 10.1.1.1/24
apic1(config-leaf-if)# ipv6 address 2001::1/64 preferred
apic1(config-leaf-if)# ipv6 link-local fe80::1
apic1(config-leaf-if)# mac-address 00:44:55:66:55::01
apic1(config-leaf-if)# mtu 1500
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface port-channel po1
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface port-channel po1.2001
apic1(config-leaf-if)# vrf member v1 tenant t1
apic1(config-leaf-if)# exit
Procedure
Step 3 interface Ethernet slot/port Enters interface configuration mode for the
interface you want to configure.
Example:
apic1(config-leaf)# interface Ethernet
1/1-2
Example
This example shows how to add ports to a Layer 3 port-channel.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface Ethernet 1/1-2
apic1(config-leaf-if)# channel-group p01
In the following figure, there are two Layer 3 Outs with a shared subnet. There is a contract between the Layer
3 external instance profile (l3extInstP) in both the VRFs. In this case, the Shared Layer 3 Out for VRF1 can
communicate with the Shared Layer 3 Out for VRF2.
Configuring Shared Layer 3 Out Inter-VRF Leaking Using the NX-OS Style CLI
- Named Example
Procedure
Configuring Shared Layer 3 Out Inter-VRF Leaking Using the NX-OS Style CLI
- Implicit Example
Procedure
Starting with Cisco APIC release 2.3, it is now possible to choose the behavior when deploying two (or more)
Layer 3 Outs using the same external encapsulation (SVI).
The encapsulation scope can now be configured as Local or VRF:
• Local scope (default): The example behavior is displayed in the figure titled Local Scope Encapsulation
and Two Layer 3 Outs.
• VRF scope: The ACI fabric configures the same bridge domain (VXLAN VNI) across all the nodes and
Layer 3 Out where the same external encapsulation (SVI) is deployed. See the example in the figure
titled VRF Scope Encapsulation and Two Layer 3 Outs.
The mapping among the CLI, API, and GUI syntax is as follows:
Note The CLI commands to configure encapsulation scope are only supported when the VRF is configured through
a named Layer 3 Out configuration.
Procedure
Step 3 Create the VLAN interface. Creates the VLAN interface. The VLAN range
is 1-4094.
Example:
apic1(config-leaf)# interface vlan 2001
Note This feature is available in the APIC Release 2.2(3x) release and going forward with APIC Release 3.1(1). It
is not supported in APIC Release 3.0(x).
The Switch Virtual Interface (SVI) represents a logical interface between the bridging function and the routing
function of a VLAN in the device. SVI can have members that are physical ports, direct port channels, or
virtual port channels. The SVI logical interface is associated with VLANs, and the VLANs have port
membership.
The SVI state does not depend on the members. The default auto state behavior for SVI in Cisco APIC is that
it remains in the up state when the auto state value is disabled. This means that the SVI remains active even
if no interfaces are operational in the corresponding VLAN/s.
If the SVI auto state value is changed to enabled, then it depends on the port members in the associated VLANs.
When a VLAN interface has multiple ports in the VLAN, the SVI goes to the down state when all the ports
in the VLAN go down.
Procedure
Step 3 Create the VLAN interface. Creates the VLAN interface. The VLAN range
is 1-4094.
Example:
apic1(config-leaf)# interface vlan 2001
Procedure
Step 3 [no] vrf context tenant tenant-name vrf Configures a tenant VRF on the node.
vrf-name
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf v1
Step 4 (Optional) [no] router-id ipv4-address Assigns a router ID for routing protocols
running on the VRF. If you do not assign a
Example:
router ID, an ID is generated internally that is
apic1(config-leaf-vrf)# router-id unique to each leaf switch.
1.2.3.4
Step 5 [no] {ip | ipv6} route ip-prefix/masklen Configures static route information for the
next-hop-address [preferred] VRF.
Example:
apic1(config-leaf-vrf)# ip route
21.1.1.1/32 32.1.1.1
apic1(config-leaf-vrf)# ipv6 route
5001::1/128 6002::1
Step 8 vlan-domain member domain-name Assign a VLAN domain to the interface. The
VLAN domain must have already been created
Example:
using the vlan-domain command in the
apic1(config-leaf-if)# vlan-domain global configuration mode.
member dom1
Step 10 vrf member tenant tenant-name vrf vrf-name Attaches the interface to the tenant VRF.
Example:
apic1(config-leaf-if)# vrf member tenant
exampleCorp vrf v1
Step 11 [no] {ip | ipv6} address ip-prefix/masklen Configures IP addresses on the interface. The
[eui64] [secondary] [preferred] specified address can be declared as either:
Example: • preferred —The default source address
for traffic from the interface.
apic1(config-leaf-if)# ip address
10.1.1.1/24 • secondary —The secondary address of
apic1(config-leaf-if)# ipv6 address the interface.
2001::1/64 preferred
With the optional eui64 keyword, the host
can assign itself a 64-bit Extended Unique
Identifier (EUI).
In this mode, you can also configure ipv6
link-local , mac address , mtu , and other
layer 3 properties on the interface.
Step 12 [[no]] ip dhcp relay address tenant Sets or removes a DHCP relay address for the
tenant-name dhcp-address{application external interface along with any supported
app-name epg epg-name|external-12 options.
12-epg-name|external-13 13-epg-name}
Example:
Examples
This example shows how to deploy a layer 3 port for external connectivity.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf v1
apic1(config-leaf-vrf)# router-id 1.2.3.4
apic1(config-leaf-vrf)# ip route 21.1.1.1/32 32.1.1.1
apic1(config-leaf-vrf)# ipv6 route 5001::1/128 6002::1 preferred
apic1(config-leaf-vrf)# exit
This example shows how to configure a layer 3 subinterface port for external connectivity. In this
example, the subinterface ID (the "100" in 1/2.100) is actually the VLAN encapsulation instead of
an ID. All properties supported on a layer 3 port are available on the subinterface as well.
apic1# configure
apic1(config)# leaf 101
# SAME VRF CONTEXT CONFIGURATION AS PREVIOUS EXAMPLE
This example shows the methods to configure a switched virtual interface (SVI) for external
connectivity. Each external SVI is uniquely identified by its encap VLAN denoted in the SVI ID.
apic1# configure
apic1(config)# leaf 101
# SAME VRF CONTEXT CONFIGURATION AS PREVIOUS EXAMPLE
Note An external SVI must be configured on each of the participating nodes. This allows you to configure
different IP addresses on each of the nodes for the same SVI. If the vPC is part of an external SVI,
you must individually create an SVI on each of the participating vPC peers and you can provide
different IP addresses on each SVI.
OSPF Configuration
Configuring OSPF
OSPF can operate in one of the following modes in an area:
• When OSPF is used as the main routing protocol for the tenant VRF in the node, OSPF will import and
export routes defined in the route-map configured in the OSPF area. The route-map contains the export
routes.
• When OSPF is used as a connectivity protocol for BGP, OSPF advertises the loopback address which is
used as the source of the BGP session. Note that the loopback IP address and not the loopback ID is used.
In this case, a BGP session relying on OSPF will use the same loopback IP address in its update-source
command.
There is no need for separate configuration of OSPF and OSPFv3. The router OSPF mode handles both
OSPFv2 and OSPFv3 implicitly for the areas running under OSPF.
OSPF sessions are supported on all types of layer 3 Interfaces in the leaf, including:
• Layer 3 ports
• Subinterfaces
• External SVI
Procedure
Step 4 vrf member tenant tenant-name vrf vrf-name Enables a VRF in the OSPF session.
Example:
apic1(config-leaf-ospf)# vrf member
tenant exampleCorp vrf v100
Step 5 (Optional) default-information originate Causes the switch to generate a default route.
[always]
Example:
apic1(config-leaf-ospf-vrf)#
default-information originate
Step 8 area area-id default-cost cost Sets OSPF default area cost to a value between
0 and 16777215.
Example:
apic1(config-leaf-ospf-vrf)# area 17
default-cost 20
Step 9 area area-id route-map map-name out Specifies a route-map for outbound filtering.
Example:
apic1(config-leaf-ospf-vrf)# area 17
route-map ospf-to-eigrp out
Step 10 area area-id loopback loopback-address When OSPF is used as a connectivity protocol
for BGP, OSPF advertises the loopback
Example:
address which is used as the source of the BGP
apic1(config-leaf-ospf-vrf)# area 17 session. Note that the loopback IP address and
loopback 192.0.20.11/32
not the loopback ID is used. In this case, a
BGP session relying on OSPF will use the
same loopback IP address in its update-source
command.
Step 13 area area-id range address-range cost cost Configures inter-area route summarization,
which summarizes the networks between areas.
Example:
apic1(config-leaf-ospf-vrf)# area 17 The range is the summary route to be
range 192.0.20.0/24 cost 20 advertised in areas. The cost is a value
between 0 and 16777215.
Step 16 interface slot/port Specifies a port for the OSPF interface. The
interface could also be specified as interface
Example:
slot/port.vlan-id or interface vlan vlan-id .
apic1(config-leaf)# interface eth 1/2
Step 17 {ip | ipv6} router ospf default area area-id Creates an OSPF routing process and enters
OSPF policy configuration.
Example:
apic1(config-leaf-if)# ip router ospf
default area 17
Step 18 {ip | ipv6} ospf inherit interface-policy Inherits the OSPF interface template policy
if-policy-name tenant tenant-name under this tenant.
Example:
apic1(config-leaf-if)# ip ospf inherit
interface-policy ifPolicy3 tenant
exampleCorp
Step 19 [no] {ip | ipv6} ospf prefix-suppression Prevents OSPF from advertising all IP prefixes
{enable | disable | inherit} that belong to a specific interface, except for
prefixes that are associated with secondary IP
Example:
addresses.
apic1(config-leaf-if)# ip ospf
prefix-suppression enable
Step 21 [no] ip ospf authentication {md5 | none | Specifies the authentication type.
simple}
Example:
apic1(config-leaf-if)# ip ospf
authentication md5
Examples
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router ospf default
apic1(config-leaf-ospf)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-ospf-vrf)# area 0 nssa
apic1(config-leaf-ospf-vrf)# area 17 stub
apic1(config-leaf-ospf-vrf)# area 17 default-cost 20
apic1(config-leaf-ospf-vrf)# area 17 route-map ospf-to-eigrp out
apic1(config-leaf-ospf-vrf)# area 17 loopback 192.0.20.11/32
apic1(config-leaf-ospf-vrf)# inherit ipv4 ospf vrf-policy vrfTemplate2
apic1(config-leaf-ospf-vrf)# summary-address 182.1.20.0/24
apic1(config-leaf-ospf-vrf)# area 17 range 192.0.20.0/24 cost 20
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit
apic1(config-leaf)# interface eth 1/3
apic1(config-leaf-if)# ip router ospf default area 17
apic1(config-leaf-if)# ip ospf inherit interface-policy ifPolicy3 tenant exampleCorp
apic1(config-leaf-if)# ip ospf prefix-suppression enable
apic1(config-leaf-if)# ip ospf passive-interface
apic1(config-leaf-if)# ip ospf authentication md5
apic1(config-leaf-if)# ip ospf authentication-key c1$c0123
Step 3 template ospf vrf-policy vrf-policy-name Creates the OSPF VRF policy template under
tenant tenant-name the specified tenant.
Example:
apic1(config-leaf)# template ospf
vrf-policy vrfTemplate3 tenant
exampleCorp
Step 4 timers throttle lsa start-time hold-interval Sets the start-interval, hold-interval, and
max-time max-interval for link-state advertisements
(LSA).
Example:
apic1(config-vrf-policy)# timers
throttle lsa 200 10000 45000
Step 5 timers lsa-group-pacing seconds Sets the interval in which LSAs are grouped
and refreshed, checksummed, or aged.
Example:
apic1(config-vrf-policy)# timers
lsa-group-pacing 240
Step 6 timers lsa-arrival milliseconds Sets the minimum interval between the arrival
of each LSA.
Example:
apic1(config-vrf-policy)# timers
lsa-arrival 1000
Step 7 timers throttle spf spf-start spf-hold Sets the SPF init-interval, hold-interval, and
spf-max-wait max-interval for LSA.
Example:
apic1(config-vrf-policy)# timers
throttle spf 5 1000 90000
Step 15 template ospf interface-policy if-policy-name Creates the OSPF interface policy template
tenant tenant-name under the specified tenant.
Example:
apic1(config-leaf)# template ospf
interface-policy ifTemplate5 tenant
exampleCorp
Step 17 [no] cost if-cost Sets the OSPF cost for the interface. The range
is 0 to 65535.
Example:
apic1(config-interface-policy)# cost
300
Step 18 [no] dead-interval seconds Sets the interval in seconds at which hello
packets must not be seen before neighbors
Example:
declare the router down. The range is 1 to
apic1(config-interface-policy)# 65535 seconds.
dead-interval 60
Step 21 [no] network {bcast | p2p | unspecified} Sets the OSPF interface policy network type,
which can be broadcast or point-to-point.
Example:
apic1(config-interface-policy)# network
p2p
Step 23 [no] priority priority Sets OSPF interface priority, which is used to
determine the designated router (DR) on a
Example:
specific network. The range is 0 to 255.
apic1(config-interface-policy)# priority
4
Step 25 [no] transmit-delay seconds Sets the estimated time required to send a
link-state update packet on the interface. The
Example:
range is from 1 to 450 seconds.
apic1(config-interface-policy)#
transmit-delay 2
Examples
This example shows how to configure a VRF template and an interface template.
apic1# configure
apic1(config)# leaf 101
BGP Configuration
Configuring BGP
Procedure
Examples
apic1# configure
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 100
apic1(config-bgp-fabric)# route-reflector spine 105
What to do next
Configure BGP address family and counters.
Step 3 template bgp timers timer-policy-name Creates the BGP timers policy template under
tenant tenant-name the specified tenant.
Example:
apic1(config-leaf)# template bgp timers
bgpTimers tenant exampleCorp
This template will be available on all
leaves
where tenant exampleCorp has a VRF
deployment
Step 5 graceful-restart stalepath-time seconds Sets the maximum time that BGP keeps stale
routes from the restarting BGP peer. The range
is 1 to 3600 seconds.
apic1(config-bgp-timers)#
graceful-restart stalepath-time 3600
Step 6 timers bgp keep-alive-seconds hold-seconds Sets the keep-alive timer and hold timer values.
The range for both is 1 to 3600 seconds.
Step 8 template bgp address-family family-name Creates the BGP address family template under
tenant tenant-name the specified tenant.
Example:
apic1(config-leaf)# template bgp
address-family bgpAf1 tenant exampleCorp
This template will be available on all
leaves
where tenant exampleCorp has a VRF
deployment
Step 9 distance ebgp-distance ibgp-distance Sets the administrative distance for eBGP
local-distance routes, iBGP routes, and local routes. The
range is 1 to 255.
apic1(config-bgp-af)# distance 250 240
230
Examples
This example shows how to create a BGP timer template and an address family template.
apic1# configure
apic1(config)# leaf 101
Procedure
Step 4 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent address family configuration mode
Example:
commands.
apic1(config-bgp)# vrf member tenant
exampleCorp vrf v100
Step 6 address-family {ipv4 | ipv6} unicast Declares neighbors with whom we want to
exchange normal IPv4 unicast routes.
Example:
apic1(config-leaf-bgp-vrf)#
address-family ipv4 unicast
Step 7 inherit bgp address-family family-name Adds the specified address family to this
address family.
Example:
apic1(config-leaf-bgp-vrf-af)# inherit
bgp address-family ipv4-af-pol
This template will be inherited on all
leaves where VRF v100 has been deployed
Step 8 exit
Example:
apic1(config-leaf-bgp-vrf-af)# exit
Examples
This example shows how to inherit a BGP timer configuration and IPv4 and IPv6 address families.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-bgp-vrf)# inherit bgp timer bgpTimers
This template will be inherited on all leaves where VRF v100 has been deployed
apic1(config-leaf-bgp-vrf)# address-family ipv4 unicast
apic1(config-leaf-bgp-vrf-af)# inherit bgp address-family ipv4-af-pol
This template will be inherited on all leaves where VRF v100 has been deployed
apic1(config-leaf-bgp-vrf-af)# exit
apic1(config-leaf-bgp-vrf)# address-family ipv6 unicast
apic1(config-leaf-bgp-vrf-af)# inherit bgp address-family ipv6-af-pol
This template will be inherited on all leaves where VRF v100 has been deployed
apic1(config-leaf-bgp-vrf-af)# exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf)# exit
Step 4 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent policy configuration mode
Example:
commands.
apic1(config-bgp)# vrf member tenant
exampleCorp vrf v100
Step 7 address-family {ipv4 | ipv6} unicast Declares neighbors with whom we want to
exchange normal IPv4 unicast routes.
Example:
apic1(config-leaf-bgp-vrf-neighbor)#
address-family ipv4 unicast
Step 8 [no] maximum-prefix count [action {log | Sets the maximum number of prefixes from
shut | restart [restart-time minutes]}] this neighbor. the range is 1 to 300000
[threshold percent] prefixes. Other optional settings are:
Example: • action — The action to be performed
apic1(config-leaf-bgp-vrf-neighbor-af)# when the maximum prefix limit is
maximum-prefix 10 threshold 10 action reached. If the action is restart , you
restart restart-time 10 can optionally specify the restart-time
, which is the period of time in minutes
before restarting the peer when the
maximum prefix limit is reached. The
range is 1 to 65535 minutes.
• threshold — The threshold percentage
of the maximum number of prefixes
before a warning is issued. The range is
1 to 100 percent.
Step 9 exit
Example:
apic1(config-leaf-bgp-vrf-neighbor-af)#
exit
Step 10 update-source {loopback ip-address | if the neighbor address is being learned through
ethernet ip-address | vlan vlan-id} OSPF, specify the same loopback address as
being used under OSPF.
Example:
apic1(config-leaf-bgp-vrf-neighbor)#
update-source loopback 192.0.2.230
The following table shows the interface settings that can be configured at this point.
Command Purpose
Examples
This example shows how to configure an IPv4 BGP neighbor.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-bgp-vrf)# aggregate-address 192.0.10.0/24 as-set
apic1(config-leaf-bgp-vrf)# neighbor 192.0.2.229/32
apic1(config-leaf-bgp-vrf-neighbor)# address-family ipv4 unicast
apic1(config-leaf-bgp-vrf-neighbor-af)# maximum-prefix 10 threshold 10 action restart
restart-time 10
apic1(config-leaf-bgp-vrf-neighbor-af)# exit
apic1(config-leaf-bgp-vrf-neighbor)# allow-self-as
apic1(config-leaf-bgp-vrf-neighbor)# allowed-self-as-count 2
apic1(config-leaf-bgp-vrf-neighbor)# disable-connected-check
apic1(config-leaf-bgp-vrf-neighbor)# disable-peer-as-check
apic1(config-leaf-bgp-vrf-neighbor)# ebgp-multihop 4
apic1(config-leaf-bgp-vrf-neighbor)# local-as 100
apic1(config-leaf-bgp-vrf-neighbor)# next-hop-self
apic1(config-leaf-bgp-vrf-neighbor)# password abcdef
apic1(config-leaf-bgp-vrf-neighbor)# remote-as 200
apic1(config-leaf-bgp-vrf-neighbor)# send-community extended
apic1(config-leaf-bgp-vrf-neighbor)# update-source vlan 601
apic1(config-leaf-bgp-vrf-neighbor)# update-source ethernet 1/15
apic1(config-leaf-bgp-vrf-neighbor)# update-source loopback 192.0.2.230
Warning: BGP Configuration changed. Please re-configure BGP Password if it was enabled
apic1(config-leaf-bgp-vrf-neighbor)# local-as 100 no-prepend replace-as dual-as
apic1(config-leaf-bgp-vrf-neighbor)# route-map rMapT3 out
apic1(config-leaf-bgp-vrf-neighbor)# weight 2000
apic1(config-leaf-bgp-vrf-neighbor)# private-as-control
apic1(config-leaf-bgp-vrf-neighbor)# exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf)# exit
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-bgp-vrf)# neighbor 2001:80:1:2::229
apic1(config-leaf-bgp-vrf-neighbor)# address-family ipv6 unicast
apic1(config-leaf-bgp-vrf-neighbor-af)# maximum-prefix 100
apic1(config-leaf-bgp-vrf-neighbor-af)# exit
apic1(config-leaf-bgp-vrf-neighbor)# allow-self-as
apic1(config-leaf-bgp-vrf-neighbor)# allowed-self-as-count 2
apic1(config-leaf-bgp-vrf-neighbor)# disable-connected-check
apic1(config-leaf-bgp-vrf-neighbor)# disable-peer-as-check
apic1(config-leaf-bgp-vrf-neighbor)# ebgp-multihop 4
apic1(config-leaf-bgp-vrf-neighbor)# local-as 100
apic1(config-leaf-bgp-vrf-neighbor)# next-hop-self
apic1(config-leaf-bgp-vrf-neighbor)# password abcdef
apic1(config-leaf-bgp-vrf-neighbor)# remote-as 200
apic1(config-leaf-bgp-vrf-neighbor)# send-community extended
apic1(config-leaf-bgp-vrf-neighbor)# update-source vlan 601
apic1(config-leaf-bgp-vrf-neighbor)# update-source ethernet 1/15
apic1(config-leaf-bgp-vrf-neighbor)# update-source loopback 2001:80:1:2::230/128
Warning: BGP Configuration changed. Please re-configure BGP Password if it was enabled
apic1(config-leaf-bgp-vrf-neighbor)# local-as 100 no-prepend replace-as dual-as
apic1(config-leaf-bgp-vrf-neighbor)# route-map rMapT3 out
apic1(config-leaf-bgp-vrf-neighbor)# weight 2000
apic1(config-leaf-bgp-vrf-neighbor)# private-as-control
apic1(config-leaf-bgp-vrf-neighbor)# exit
apic1(config-leaf-bgp-vrf-af)# exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf)# exit
Configuring a Per VRF Per Node BGP Timer Policy Using the NX-OS Style CLI
Procedure
Step 2 Create a timer policy. The specific values are provided as examples
only.
Example:
apic1# config
apic1(config)# leaf 101
apic1(config-leaf)# template bgp timers
pol7 tenant tn1
This template will be available on all
nodes where tenant tn1 has a VRF
deployment
apic1(config-bgp-timers)# timers bgp 120
240
apic1(config-bgp-timers)#
graceful-restart stalepath-time 500
apic1(config-bgp-timers)# maxas-limit
300
apic1(config-bgp-timers)# exit
apic1(config-leaf)# exit
apic1(config)# exit
apic1#
exit
exit
exit
apic1#
The two properties which enable you to configure more paths are maxEcmp and maxEcmpIbgp in the
bgpCtxAfPol object. After you configure these two properties, they are propagated to the rest of your
implementation.
Use the following commands when logged in to BGP:
maximum-paths [ibgp]
no maximum-paths [ibgp]
Example Configuration:
Procedure
Example:
apic1(config)# leaf 101
apic1(config-leaf)# template bgp address-family newAf tenant t1
This template will be available on all nodes where tenant t1 has a VRF deployment
apic1(config-bgp-af)# maximum-paths ?
<1-16> Maximum number of equal-cost paths for load sharing. The default is 16.
ibgp Configure multipath for IBGP paths
apic1(config-bgp-af)# maximum-paths 10
apic1(config-bgp-af)# maximum-paths ibpg 8
apic1(config-bgp-af)# end
apic1#
no maximum-paths [ibgp]
Prepend Appends the specified AS number to the AS path of the route matched by
the route map.
Note • You can configure more than one AS number.
• 4 byte AS numbers are supported.
• You can prepend a total 32 AS numbers. You must specify
the order in which the AS Number is inserted into the AS
Path attribute.
Prepend-last-as Prepends the last AS numbers to the AS path with a range between 1 and 10.
The following table describes the selection criteria for implementation of AS Path Prepend:
Procedure
To modify the autonomous system path (AS Path) for Border Gateway Protocol (BGP) routes, you can use
the set as-path command. The set as-path command takes the form of
apic1(config-leaf-vrf-template-route-profile)# set as-path {'prepend as-num [ ,... as-num ]
| prepend-last-as num}
Example:
apic1(config)# leaf 103
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# template route-profile rp1
apic1(config-leaf-vrf-template-route-profile)# set as-path ?
prepend Prepend to the AS-Path
prepend-last-as Prepend last AS to the as-path
apic1(config-leaf-vrf-template-route-profile)# set as-path prepend 100, 101, 102, 103
apic1(config-leaf-vrf-template-route-profile)# set as-path prepend-last-as 8
apic1(config-leaf-vrf-template-route-profile)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# exit
What to do next
To disable AS Path prepend, use the no form of the shown command:
apic1(config-leaf-vrf-template-route-profile)# [no] set
as-path { prepend as-num [ ,... as-num ] | prepend-last-as num}
Procedure
Step 3 template route-profile profile-name tenant Creates a route-profile template under tenant
tenant-name for BGP dampening and route redistribution.
Example:
apic1(config-leaf)# template
route-profile map_eigrp tenant
exampleCorp
Step 4 Required: [no] set tag name Sets the tag value. The name parameter is an
unsigned integer.
Example:
apic1(config-leaf-template-route-profile)#
set tag 200
Step 6 template route-profile profile-name tenant Creates a route-profile template under tenant
tenant-name for BGP dampening and route redistribution.
Example:
apic1(config-leaf)# template
route-profile map_ospf tenant exampleCorp
Step 7 Required: [no] set tag name Sets the tag value. The name parameter is an
unsigned integer.
Example:
apic1(config-leaf-template-route-profile)#
set tag 100
Example
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# template route-profile map_eigrp tenant exampleCorp
apic1(config-leaf-template-route-profile)# set tag 200
apic1(config-leaf-template-route-profile)# exit
apic1(config-leaf)# template route-profile map_ospf tenant exampleCorp
apic1(config-leaf-template-route-profile)# set tag 100
apic1(config-leaf-template-route-profile)# exit
What to do next
Configure a redistribute route-profile under BGP for OSPF and EIGRP using one of the route-profiles created
in this procedure.
Procedure
Step 4 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent policy configuration mode
Example:
commands.
apic1(config-bgp)# vrf member tenant
exampleCorp vrf v100
Example
This example configures a redistribute route-profile under BGP for OSPF and EIGRP using the
route-profiles created in the example in Creating a Route-Profile with Tenant Scope. The redistribute
route-map allows (permits) all routes and applies the route-profile for the route-control actions. In
this example, all EIGRP learned routes will be redistributed into BGP with tag 200 and OSPF routes
will be redistributed into BGP with tag 100.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v1
apic1(config-leaf-bgp-vrf)# redistribute eigrp route-map map_eigrp
apic1(config-leaf-bgp-vrf)# redistribute ospf route-map map_ospf
Procedure
Step 3 template route-profile profile-name tenant Creates a route-profile template under tenant
tenant-name for BGP dampening and route redistribution.
Example:
apic1(config-leaf)# template
route-profile damp_rp tenant exampleCorp
Step 4 Required: [no] set dampening half-life reuse Configures route flap dampening behavior.
suppress max-suppress-time The parameters are:
Step 7 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent policy configuration mode
Example:
commands.
apic1(config-bgp)# vrf member tenant
exampleCorp vrf v100
Step 8 neighbor ip-address [/masklength] Specifies the IP address of the neighbor. The
mask length must be 32.
Example:
apic1(config-leaf-bgp-vrf)# neighbor
192.0.2.229/32
Step 9 address-family {ipv4 | ipv6} unicast Declares neighbors with whom we want to
exchange normal IPv4 unicast routes.
Example:
apic1(config-leaf-bgp-vrf-neighbor)#
address-family ipv4 unicast
Step 11 exit
Example:
apic1(config-leaf-bgp-vrf-neighbor-af)#
exit
Step 12 exit
Example:
apic1(config-leaf-bgp-vrf-neighbor)#
exit
Step 13 address-family {ipv4 | ipv6} unicast Declares neighbors with whom we want to
exchange normal IPv4 unicast routes.
Example:
apic1(config-leaf-bgp-vrf)#
address-family ipv4 unicast
Step 15 exit
Example:
apic1(config-leaf-bgp-vrf-af)# exit
Example
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# template route-profile damp_rp tenant exampleCorp
apic1(config-leaf-template-route-profile)# set dampening 15 750 2000 60
apic1(config-leaf-template-route-profile)# exit
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-bgp-vrf)# neighbor 192.0.2.229/32
apic1(config-leaf-bgp-vrf-neighbor)# address-family ipv4 unicast
apic1(config-leaf-bgp-vrf-neighbor-af)# inherit bgp dampening damp_rp
apic1(config-leaf-bgp-vrf-neighbor-af)# exit
apic1(config-leaf-bgp-vrf)# address-family ipv6 unicast
apic1(config-leaf-bgp-vrf-af)# inherit bgp dampening damp_rp
apic1(config-leaf-bgp-vrf-af)# exit
EIGRP Configuration
Creating EIGRP VRF and Interface Templates
Procedure
Step 3 template eigrp vrf-policy vrf-policy-name Creates the EIGRP VRF policy template under
tenant tenant-name the specified tenant.
Example:
apic1(config-leaf)# template eigrp
vrf-policy vrfTemplate3 tenant
exampleCorp
This template will be available on all
leaves where tenant exampleCorp has a
VRF deployment
Step 5 maximum-paths limit Sets EIGRP Maximum Path Limit for the VRF
policy template. The limit can be 1 to 32.
Example:
apic1(config-template-eigrp-vrf-pol)#
maximum-paths 8
Step 6 metric version 64bit Sets EIGRP metric style to wide metric (64
bits).
Example:
apic1(config-template-eigrp-vrf-pol)#
metric version 64bit
Step 7 timers active-time minutes Sets EIGRP active timer interval. The range
is 1 to 65535 minutes.
Example:
apic1(config-template-eigrp-vrf-pol)#
timers active-time 1
Step 9 ip hello-interval eigrp default seconds Sets EIGRP hello interval time. The range is
1 to 65535 seconds.
Example:
apic1(config-template-eigrp-if-pol)# ip
hello-interval eigrp default 10
Step 10 ip hold-interval eigrp default seconds Sets EIGRP hold interval time. The range is 1
to 65535 seconds.
Example:
apic1(config-template-eigrp-if-pol)# ip
hold-interval eigrp default 10
Examples
apic1# configure
apic1(config)# leaf 101
This template will be available on all leaves where tenant exampleCorp has a VRF deployment
apic1(config-template-eigrp-vrf-pol)# distance 2 5
apic1(config-template-eigrp-vrf-pol)# maximum-paths 8
apic1(config-template-eigrp-vrf-pol)# metric version 64bit
apic1(config-template-eigrp-vrf-pol)# timers active-time 1
apic1(config-template-eigrp-vrf-pol)# exit
What to do next
Configure EIGRP address family and counters.
Step 4 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent address family configuration mode
Example:
commands.
apic1(config-eigrp)# vrf member tenant
exampleCorp vrf v100
Step 8 maximum-paths limit Sets EIGRP Maximum Path Limit for the VRF
policy template. The limit can be 1 to 32.
Example:
apic1(config-address-family)#
maximum-paths 8
Step 9 metric version 64bit Sets EIGRP metric style to wide metric (64
bits).
Example:
apic1(config-address-family)# metric
version 64bit
Step 10 timers active-time minutes Sets EIGRP active timer interval. The range
is 1 to 65535 minutes.
Example:
apic1(config-address-family)# timers
active-time 1
Step 11 inherit eigrp vrf-policy vrf-policy-name Applies an EIGRP VRF policy to this address
family.
Example:
apic1(config-address-family)# inherit
eigrp vrf-policy vrfTemplate3
Examples
This example shows how to configure an EIGRP address family and inherit an EIGRP VRF policy.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router eigrp default
apic1(config-eigrp)# vrf member tenant exampleCorp vrf v100
apic1(config-eigrp-vrf)# autonomous-system 300
apic1(config-eigrp-vrf)# address-family ipv4 unicast
This configuration will affect all leaves where VRF v100 has been deployed
apic1(config-address-family)# distance 2 5
This configuration will affect all leaves where VRF v100 has been deployed
apic1(config-address-family)# maximum-paths 8
This configuration will affect all leaves where VRF v100 has been deployed
apic1(config-address-family)# metric version 64bit
This configuration will affect all leaves where VRF v100 has been deployed
apic1(config-address-family)# timers active-time 1
This configuration will affect all leaves where VRF v100 has been deployed
Step 5 [no] vlan-domain member vlan-id Creates and enters the configuration mode for
the VLAN domain.
Example:
apic1(config-leaf-if)# vlan-domain
member dom1
Step 6 [no] vrf member tenant exampleCorp vrf Associates the interface with a VRF.
vrf-name
Example:
apic1(config-leaf-if)# vrf member tenant
exampleCorp vrf v100
Step 7 [no] {ip | ipv6} address Sets an IP address for the interface.
ip-address/mask-length
Example:
apic1(config-leaf-if)# ip address
181.12.12.1/24
Step 9 [no] {ip | ipv6} distribute-list eigrp default EIGRP advertises routes that are matched in
route-map map-name out the route-map specified in the distribute-list
command. The route prefixes mentioned in the
Example:
prefix-list in the route-map can be learned from
apic1(config-leaf-if)# ip other protocol sources like BGP, OSPF, Static,
distribute-list eigrp default route-map
rMapT5 out
Connected. Redistribute route-maps are
automatically created based on the
distribute-list command. Note that prefixes
learned from an EIGRP session running on an
another interface on the same switch will not
be filtered by the distribute-list and will always
be advertised out.
Step 10 [no] {ip | ipv6} hello-interval eigrp default Sets EIGRP hello interval time. The range is
seconds 1 to 65535 seconds.
Example:
apic1(config-leaf-if)# ip hello-interval
eigrp default 10
Step 11 [no] {ip | ipv6} hold-interval eigrp default Sets EIGRP hold interval time. The range is 1
seconds to 65535 seconds.
Example:
apic1(config-leaf-if)# ip hold-interval
eigrp default 10
Step 12 [no] {ip | ipv6} next-hop-self eigrp default Sets EIGRP next-hop-self flag.
Example:
apic1(config-leaf-if)# ip next-hop-self
eigrp default
Step 13 [no] {ip | ipv6} passive-interface eigrp Set EIGRP passive-interface flag.
default
Example:
apic1(config-leaf-if)# ip
passive-interface eigrp default
Step 14 [no] {ip | ipv6} split-horizon eigrp default Sets EIGRP split-horizon flag.
Example:
apic1(config-leaf-if)# ip split-horizon
eigrp default
Step 16 [no] ip summary-address eigrp default Configures route summarization for EIGRP.
ip-prefix A summary address can be configured to
advertise an aggregated prefix on an EIGRP
Example:
session.
apic1(config-leaf-if)# ip
summary-address eigrp default Note A summary address enabled on one
172.10.1.0/24 interface will also be applied on
apic1(config-leaf-if)# ip other EIGRP enabled interfaces on
summary-address eigrp default 2001::/64 the same VRF on the switch.
Examples
This example shows how to configure an EIGRP interface.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/21
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-if)# ip address 181.12.12.1/24
apic1(config-leaf-if)# ip router eigrp default
apic1(config-leaf-if)# ip distribute-list eigrp default route-map rMapT5 out
distribute list will be updated on all EIGRP interfaces on node 1021 VRF exampleCorp/v100
apic1(config-leaf-if)# ip hello-interval eigrp default 5
apic1(config-leaf-if)# ip hold-interval eigrp default 10
apic1(config-leaf-if)# ip next-hop-self eigrp default
apic1(config-leaf-if)# ip passive-interface eigrp default
apic1(config-leaf-if)# ip split-horizon eigrp default
apic1(config-leaf-if)# inherit eigrp ip interface-policy ifTemplate5
apic1(config-leaf-if)# ip summary-address eigrp default 172.10.1.0/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# exit
Configuring Route-Maps
Configuring Templates
About Route Profiles
A route profile specifies the route-control set actions used in import, export, and redistribute route-maps.
Route profile templates can be defined either under the tenant or under the tenant VRF.
Procedure
Step 4 Required: [no] set community {regular | Sets the BGP community attribute.
extended} value {none | replace | additive}
Example:
apic1(config-leaf-template-route-profile)#
set community extended 20:22 additive
Step 5 Required: [no] set dampening half-life reuse Configures route flap dampening behavior.
suppress max-suppress-time The parameters are:
Example:
Step 6 Required: [no] set local-preference value Sets the BGP local preference value. The range
is from 0 to 4294967295.
Example:
apic1(config-leaf-template-route-profile)#
set local-preference 64
Step 7 Required: [no] set metric value Sets the metric for the destination routing
protocol.
Example:
apic1(config-leaf-template-route-profile)#
set metric 128
Step 8 Required: [no] set metric-type {type-1 | The options are as follows:
type-2}
• type-1 —OSPF external type 1 metric
Example:
• type-2 —OSPF external type 2 metric
apic1(config-leaf-template-route-profile)#
set metric-type type-2
Step 9 Required: [no] set tag name Sets the tag value for the destination routing
protocol. The name parameter is an unsigned
Example:
integer.
apic1(config-leaf-template-route-profile)#
set tag 1111
Step 10 Required: [no] set weight weight Sets the tag value for the destination routing
protocol. The weight parameter is an unsigned
Example:
integer.
apic1(config-leaf-template-route-profile)#
set weight 20
Examples
This example shows how to configure a tenant-scoped route profile.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# template route-profile rp1 tenant exampleCorp
This template will be available on all leaves where tenant exampleCorp has a VRF deployment
apic1(config-leaf-template-route-profile)# set community extended 20:22 additive
apic1(config-leaf-template-route-profile)# set dampening 15 750 2000 60
apic1(config-leaf-template-route-profile)# set local-preference 64
apic1(config-leaf-template-route-profile)# set metric 128
apic1(config-leaf-template-route-profile)# set metric-type type-2
apic1(config-leaf-template-route-profile)# set tag 1111
apic1(config-leaf-template-route-profile)# set weight 20
Note VRF-scoped route profiles name default-export and default-import values, which are automatically
applied on the match statements on the respective export/import route-maps used in the same tenant VRF.
Procedure
Step 3 [no] vrf context tenant tenant-name vrf Enables VRF on the leaf and enters VRF
vrf-name configuration mode.
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf vrf1
Step 5 Required: [no] set community {regular | Sets the BGP community attribute.
extended} {no-advertise| no-export|value
{none | replace | additive}
Example:
apic1(config-leaf-vrf-template-route-profile)#
set community extended 20:22 additive
Step 6 Required: [no] set local-preference value Sets the BGP local preference value. The range
is from 0 to 4294967295.
Example:
apic1(config-tenant-vrf-route-profile)#
set local-preference 64
Step 7 Required: [no] set metric value Sets the metric for the destination routing
protocol.
Example:
apic1(config-tenant-vrf-route-profile)#
set metric 128
Step 8 Required: [no] set metric-type {type-1 | The options are as follows:
type-2}
• type-1 —OSPF external type 1 metric
Example:
• type-2 —OSPF external type 2 metric
apic1(config-tenant-vrf-route-profile)#
set metric-type type-2
Step 9 Required: [no] set tag name Sets the tag value for the destination routing
protocol. The name parameter is an unsigned
Example:
integer.
apic1(config-tenant-vrf-route-profile)#
set tag 1111
Step 10 Required: [no] set weight weight Sets the tag value for the destination routing
protocol. The weight parameter is an unsigned
Example:
integer.
apic1(config-tenant-vrf-route-profile)#
set weight 20
Examples
This example shows how to configure a VRF-scoped route profile.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf vrf1
apic1(config-leaf-vrf)# template route-profile default-export
apic1(config-leaf-vrf-template-route-profile)# set community extended 20:22 additive
Creating a Route-Map
Route-maps are created with a prefix-list on a per-tenant basis to indicate the bridge domain public subnets
to be advertised to external routers. In addition, a prefix-list must be created to allow all transit routes to be
advertised to an external router. The prefix-list for transit routes are configured by an administrator. The
default behavior is to deny all transit route advertisement to an external router.
Procedure
Step 3 [no] vrf context tenant tenant-name vrf Configures a tenant VRF on the node.
vrf-name
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf v1
Step 4 (Optional) [no] router-id ipv4-address Assigns a router ID for routing protocols
running on the VRF. If you do not assign a
Example:
router ID, an ID is generated internally that is
apic1(config-leaf-vrf)# router-id unique to each leaf switch.
1.2.3.4
Step 5 Required: [no] route-map name Creates a route-map and enters route-map
configuration.
Example:
apic1(config-leaf-vrf)# route-map bgpMap
Step 6 Required: [no] ip prefix-list list-name permit Creates a prefix-list under the route-map.
prefix/masklen [le {32 | 128}]
Example:
Step 7 Required: [no] match prefix-list list-name Matches a prefix-list that has already been
created and enters the match mode to configure
Example:
the route-control profile for the prefix-list.
apic1(config-leaf-vrf-route-map)# match
prefix-list list1
Step 8 Required: [no] set metric value Sets the metric for the destination routing
protocol.
Example:
apic1(config-leaf-vrf-route-map-match)#
set metric 128
Step 9 Required: [no] set metric-type {type-1 | The options are as follows:
type-2}
• type-1 —OSPF external type 1 metric
Example:
• type-2 —OSPF external type 2 metric
apic1(config-leaf-vrf-route-map-match)#
set metric-type type-2
Step 10 Required: [no] set local-preference value Sets the BGP local preference value. The range
is from 0 to 4294967295.
Example:
apic1(config-leaf-vrf-route-map-match)#
set local-preference 64
Step 11 Required: [no] set community {regular | Sets the community attribute for a BGP route
extended} value {none | replace | additive} update. Specify the community-value in
aa:nn format. Specify the action as one of the
Example:
following:
apic1(config-leaf-vrf-route-map-match)#
set community extended 20:22 additive • additive —Add to existing community
• replace —Replace existing community
• none —Do not change community
Step 12 Required: [no] set tag name Sets the tag value for the destination routing
protocol. The name parameter is an unsigned
Example:
integer.
apic1(config-leaf-vrf-route-map-match)#
set tag 1111
Step 13 Required: [no] set weight value Specifies the BGP weight for the routing table.
Example:
apic1(config-leaf-vrf-route-map-match)#
set weight 32
Step 14 Required: [no] contract {provider| consumer Add contract, required to leak routes (matching
} contract-name [imported] this prefix list) from the VRF.
Example:
Step 15 Required: [no] match route group Matches a route group that has already been
group-name [order number ] created and enters the match mode to configure
the route-map.
Example:
apic1(config-leaf-vrf-route-map)# match Repeat the steps 8-13 or only step 18 to
route group g1 order 1 configure the route map for the route group.
See step 17 to inherit the route map instead of
inline set actions.
Step 16 Required: [no] match bridge-domain Matches a bridge domain in order to export its
bd-name public subnets through the protocol.
Example:
apic1(config-leaf-vrf-route-map)#
bridge-domain bd1
Step 17 Required: [no] inherit route-profile Configures route map for bridge domain.
profile-name
Note The route map was already created
Example: using the command template
apic1(config-leaf-vrf-route-map-match)# route-profile.
inherit route-profile rp1
Step 18 Required: [no] bridge-domain-match Configures route map for bridge domain.
Example: Note Disables the bridge domain (BD)
apic1(config-leaf-vrf-route-map)# no match in a route map, eliminating
bridge-domain-match the need to delete the BD
configuration from the route map.
This is required if there are BDs
matched in a route map, and the
route map is used to filter out the
BD subnets using route
group/explicit prefix list.
Examples
This example shows how to create a route-map and add/match a prefix-list, a community-list, and a
bridge-domain.
# CREATE A ROUTE-MAP
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf v1
apic1(config-leaf-vrf)# route-map bgpMap
# CREATE A PREFIX-LIST
apic1(config-leaf-vrf-route-map)# ip prefix-list list1 permit 13.13.13.0/24
apic1(config-leaf-vrf-route-map)# ip prefix-list list1 permit 14.14.14.0/24
# CREATE A BRIDGE-DOMAIN
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# vrf context v1
apic1(config-tenant-vrf)# exit
apic1(config-tenant)# bridge-domain bd1
apic1(config-tenant-bd)# vrf member v1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# interface bridge-domain bd1
apic1(config-tenant-interface)# ip address 13.13.13.1/24 scope public
apic1(config-tenant-interface)# exit
apic1(config-tenant)# exit
Examples
This example shows how to configure a route-map in BGP, OSPF and EIGRP.
# BGP
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v1
# OSPF
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router ospf default
apic1(config-leaf-ospf)# vrf member tenant exampleCorp vrf v1
apic1(config-leaf-ospf-vrf)# area 0.0.0.1 route-map map1 out
apic1(config-leaf-ospf-vrf)# area 0.0.0.1 route-map map2 in
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit
apic1(config-leaf)# exit
#EIGRP
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface ethernet 1/3
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v1
apic1(config-leaf-if)# ip address 13.13.13.13/24
apic1(config-leaf-if)# ip router eigrp default
apic1(config-leaf-if)# ip distribute-list eigrp default route-map map1 out
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
Procedure
Step 4 [no] export map map-name Configures route-map in this VRF to export
(leak) routes from this VRF into consumer
Example:
VRFs.
apic1(config-leaf-vrf)# export map
shared-route-map1
Examples
This example shows how to create and export a route-map.
# CREATE A ROUTE-MAP
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf v1
apic1(config-leaf-vrf)# router-id 1.2.3.4
apic1(config-leaf-vrf)# route-map shared-route-map1
apic1(config-leaf-vrf-route-map)# ip prefix-list list1 permit 13.13.13.0/24
apic1(config-leaf-vrf-route-map)# match prefix-list list1
apic1(config-leaf-vrf-route-map-match)# contract provider prov1
apic1(config-leaf-vrf-route-map-match)# exit
apic1(config-leaf-vrf-route-map)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# exit
Procedure
Step 2 [no] template bfd {ip | ipv6} Creates a BFD policy template.
global-policy-name
Example:
apic1(config)# template bfd ip
bfd_global
Step 3 [no] echo-address ip-address Specifies the IP address to use as the source
address for BFD echo packets.
Example:
apic1(config-bfd)# echo-address
192.0.20.123
apic1(config-bfd)# echo-address 34::1/64
Step 4 [no] slow-timer milliseconds Configures the slow timer used in the echo
function. This value determines how fast BFD
Example:
starts up a new sessions and at what speed the
apic1(config-bfd)# slow-timer 2000 asynchrounous sessions use for BFD control
packets when the echo function is enabled. The
slow-timer value is used as the new control
packet interval, while the echo packets use the
configured BFD intervals. The echo packets
are used for link failure detection, while the
control packets at the slower rate maintain the
BFD session. The range is from 1000 to 30000
milliseconds.
Step 5 [no] min-tx milliseconds Specifies the interval at which this device
wants to send BFD hello messages. The range
Example:
is 50 to 999 milliseconds.
apic1(config-bfd)# min-tx 100
Step 7 [no] multiplier policy-name Specifies the number of missing BFD hello
messages from another BFD device before this
Example:
local device detects a fault in the forwarding
apic1(config-bfd)# multiplier 3 path. The range is 1 to 50.
Step 11 [no] inherit bfd {ip | ipv6} Inherits the previously created BFD global
global-policy-name policies.
Example:
apic1(config-leaf-policy-group)# inherit
bfd ip bfd_global
Step 15 [no] leaf-policy-group leaf-policy-name Specifies the previously created leaf policy
group to be associated to the leaf switches.
Example:
Step 16 [no] leaf leaf-range Adds one or more leaf switches to the leaf
switch group.
Example:
apic1(config-leaf-group)# leaf 101-102
Examples
This example shows how to configure BFD globally and apply it to a group of leaf switches.
# CONFIGURE AN ACCESS LEAF POLICY GROUP AND INHERIT BFD GLOBAL POLICIES
apic1(config)# template leaf-policy-group leaf_pg1
apic1(config-leaf-policy-group)# inherit bfd ip bfd_global
apic1(config-leaf-policy-group)# exit
Configuring BFD Globally on Leaf Switch Using the NX-OS Style CLI
Procedure
Step 1 To configure the BFD IPV4 global configuration (bfdIpv4InstPol) using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template bfd ip bfd_ipv4_global_policy
apic1(config-bfd)# [no] echo-address 1.2.3.4
apic1(config-bfd)# [no] slow-timer 2500
apic1(config-bfd)# [no] min-tx 100
apic1(config-bfd)# [no] min-rx 70
apic1(config-bfd)# [no] multiplier 3
apic1(config-bfd)# [no] echo-rx-interval 500
apic1(config-bfd)# exit
Step 2 To configure the BFD IPV6 global configuration (bfdIpv6InstPol) using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template bfd ipv6 bfd_ipv6_global_policy
apic1(config-bfd)# [no] echo-address 34::1/64
apic1(config-bfd)# [no] slow-timer 2500
apic1(config-bfd)# [no] min-tx 100
apic1(config-bfd)# [no] min-rx 70
apic1(config-bfd)# [no] multiplier 3
apic1(config-bfd)# [no] echo-rx-interval 500
apic1(config-bfd)# exit
Step 3 To configure access leaf policy group (infraAccNodePGrp) and inherit the previously created BFD global
policies using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template leaf-policy-group test_leaf_policy_group
apic1(config-leaf-policy-group)# [no] inherit bfd ip bfd_ipv4_global_policy
apic1(config-leaf-policy-group)# [no] inherit bfd ipv6 bfd_ipv6_global_policy
apic1(config-leaf-policy-group)# exit
Step 4 To associate the previously created leaf policy group onto a leaf using the NX-OS CLI:
Example:
Configuring BFD Globally on Spine Switch Using the NX-OS Style CLI
Use this procedure to configure BFD globally on spine switch using the NX-OS style CLI.
Procedure
Step 1 To configure the BFD IPV4 global configuration (bfdIpv4InstPol) using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template bfd ip bfd_ipv4_global_policy
apic1(config-bfd)# [no] echo-address 1.2.3.4
apic1(config-bfd)# [no] slow-timer 2500
apic1(config-bfd)# [no] min-tx 100
apic1(config-bfd)# [no] min-rx 70
apic1(config-bfd)# [no] multiplier 3
apic1(config-bfd)# [no] echo-rx-interval 500
apic1(config-bfd)# exit
Step 2 To configure the BFD IPV6 global configuration (bfdIpv6InstPol) using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template bfd ipv6 bfd_ipv6_global_policy
apic1(config-bfd)# [no] echo-address 34::1/64
apic1(config-bfd)# [no] slow-timer 2500
apic1(config-bfd)# [no] min-tx 100
apic1(config-bfd)# [no] min-rx 70
apic1(config-bfd)# [no] multiplier 3
apic1(config-bfd)# [no] echo-rx-interval 500
apic1(config-bfd)# exit
Step 3 To configure spine policy group and inherit the previously created BFD global policies using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# template spine-policy-group test_spine_policy_group
apic1(config-spine-policy-group)# [no] inherit bfd ip bfd_ipv4_global_policy
apic1(config-spine-policy-group)# [no] inherit bfd ipv6 bfd_ipv6_global_policy
apic1(config-spine-policy-group)# exit
Step 4 To associate the previously created spine policy group onto a spine switch using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# spine-profile test_spine_profile
apic1(config-spine-profile)# spine-group test_spine_group
apic1(config-spine-group)# spine-policy-group test_spine_policy_group
apic1(config-spine-group)# spine 103-104
apic1(config-leaf-group)# exit
Procedure
Step 7 [no] vrf context tenant tenant-name vrf Configures a tenant VRF on the node.
vrf-name
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf vrf1
Step 12 [no] template bfd template-name tenant Configures a BFD interface policy.
tenant-name
Example:
apic1(config-leaf)# template bfd
bfdIfPol1 tenant exampleCorp
Step 13 [no] echo-mode enable Enables or disables the sending of BFD echo
packets in addition to BFD control packets.
Example:
apic1(config-template-bfd-pol)#
echo-mode enable
Step 15 [no] min-tx milliseconds Specifies the interval at which this device
sends BFD hello messages. The range is 50 to
Example:
999 milliseconds.
apic1(config-template-bfd-pol)# min-tx
100
Step 16 [no] min-rx milliseconds Specifies the minimum interval at which this
device can accept BFD hello messages from
Example:
another BFD device. The range is 50 to 999
apic1(config-template-bfd-pol)# min-rx milliseconds.
70
Step 17 [no] multiplier policy-name Specifies the number of missing BFD hello
messages from another BFD device before this
Example:
local device detects a fault in the forwarding
apic1(config-template-bfd-pol)# path. The range is 1 to 50.
multiplier 5
Examples
This example shows how to configure a BFD override policy and apply it to an interface.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# vrf context vrf1
apic1(config-tenant-vrf)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf vrf1
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# interface eth 1/18
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf vrf1
apic1(config-leaf-if)# exit
Procedure
Step 5 [no] vrf member tenant tenant-name vrf Attaches the interface to the tenant VRF.
vrf-name
Note This command is used only if the
Example: interface is a VLAN interface.
apic1(config-leaf-if)# vrf member tenant
exampleCorp vrf vrf1
Step 6 bfd {ip | ipv6} tenant mode Enables BFD tenant mode.
Example:
apic1(config-leaf-if)# bfd ip tenant mode
Step 7 bfd {ip | ipv6} inherit interface-policy Inherits the specified BFD interface template
policy-name policy.
Example:
apic1(config-leaf-if)# bfd ip inherit
interface-policy bfdIfPol1
Step 8 bfd {ip | ipv6} authentication keyed-sha1 Configures BFD authentication as keyed
keyid keyid key key SHA-1.
Example:
apic1(config-leaf-if)# bfd ip
authentication keyed-sha1 key 10 key
password
Examples
This example shows how to inherit the previously created BFD interface policy onto a L3 interface
with an IPv4 address.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/15
apic1(config-leaf-if)# bfd ip tenant mode
apic1(config-leaf-if)# bfd ip inherit interface-policy bfdIfPol1
apic1(config-leaf-if)# bfd ip authentication keyed-sha1 key 10 key password
This example shows how to inherit the previously created BFD interface policy onto a L3 interface
with an IPv6 address.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/15
This example shows how to configure BFD on a VLAN interface with an IPv4 address.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface vlan 15
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf vrf1
apic1(config-leaf-if)# bfd ip tenant mode
apic1(config-leaf-if)# bfd ip inherit interface-policy bfdIfPol1
apic1(config-leaf-if)# bfd ip authentication keyed-sha1 key 10 key password
This example shows how to configure BFD on a VLAN interface with an IPv6 address.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface vlan 15
apic1(config-leaf-if)# ipv6 address 2001::10:1/64 preferred
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf vrf1
apic1(config-leaf-if)# bfd ip tenant mode
apic1(config-leaf-if)# bfd ip inherit interface-policy bfdIfPol1
apic1(config-leaf-if)# bfd ip authentication keyed-sha1 key 10 key password
Procedure
Step 7 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent policy configuration mode
Example:
commands.
apic1(config-bgp)# vrf member tenant
exampleCorp vrf v100
Step 8 neighbor ip-address [/masklength] Specifies the IP address of the neighbor. The
mask length must be 32.
Example:
apic1(config-leaf-bgp-vrf)# neighbor
1.2.3.4
Step 9 [no] bfd enable Enables or disables BFD on the BGP consumer
protocol.
Example:
apic1(config-leaf-bgp-vrf-neighbor)# bfd
enable
Examples
This example shows how to enable BFD on the BGP consumer protocol.
apic1# configure
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 200
apic1(config-bgp-fabric)# exit
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 200
apic1(config-bgp)# vrf member tenant exampleCorp vrf v100
apic1(config-leaf-bgp-vrf)# neighbor 1.2.3.4
apic1(config-leaf-bgp-vrf-neighbor)# bfd enable
Procedure
Step 4 [no] {ip | ipv6} bfd eigrp enable Enables or disables BFD on the EIGRP
consumer protocol.
Example:
apic1(config-leaf-if)# ip bfd eigrp
enable
Examples
This example shows how to enable BFD on the EIGRP consumer protocol.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/15
apic1(config-leaf-if)# ip bfd eigrp enable
Procedure
Step 4 [no] ip ospf bfd enable Enables or disables BFD on the OSPF consumer
protocol.
Example:
apic1(config-leaf-if)# ip ospf bfd enable
Examples
This example shows how to enable BFD on the OSPF consumer protocol.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface vlan 123
apic1(config-leaf-if)# ip ospf bfd enable
Procedure
Step 3 [no] vrf context tenant tenant-name vrf Configures a tenant VRF on the node.
vrf-name
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf vrf1
Step 4 [no] {ip | ipv6} route ip-prefix/masklen Enables or disables BFD on the static route
next-hop-address bfd consumer protocol.
Example:
apic1(config-leaf-vrf)# ip route
10.0.0.1/16 10.0.0.5 bfd
Examples
This example shows how to enable BFD on the static route consumer protocol.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf vrf1
apic1(config-leaf-vrf)# ip route 10.0.0.1/16 10.0.0.5 bfd
Step 1 To enable BFD on the BGP consumer protocol using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 200
apic1(config-bgp-fabric)# exit
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 200
apic1(config-bgp)# vrf member tenant t0 vrf v0
apic1(config-leaf-bgp-vrf)# neighbor 1.2.3.4
apic1(config-leaf-bgp-vrf-neighbor)# [no] bfd enable
Step 2 To enable BFD on the EIGRP consumer protocol using the NX-OS CLI:
Example:
Step 3 To enable BFD on the OSPF consumer protocol using the NX-OS CLI:
Example:
apic1# configure
apic1(config)# spine 103
apic1(config-spine)# interface ethernet 5/3.4
apic1(config-spine-if)# [no] ip ospf bfd enable
Step 4 To enable BFD on the Static Route consumer protocol using the NX-OS CLI:
Example:
Step 5 To enable BFD on IS-IS consumer protocol using the NX-OS CLI:
Example:
• The Layer 3 multicast configuration is done at the VRF level so protocols function within the VRF and
multicast is enabled in a VRF, and each multicast VRF can be turned on or off independently.
• Once a VRF is enabled for multicast, the individual bridge domains (BDs) and L3 Outs under the enabled
VRF can be enabled for multicast configuration. By default, multicast is disabled in all BDs and Layer
3 Outs.
• Layer 3 multicast is not currently supported on VRFs that are configured with a shared L3 Out.
• Any Source Multicast (ASM) and Source-Specific Multicast (SSM) are supported.
• Bidirectional PIM, Rendezvous Point (RP) within the ACI fabric, and PIM IPv6 are currently not supported
• IGMP snooping cannot be disabled on pervasive bridge domains with multicast routing enabled.
• Multicast routers are not supported in pervasive bridge domains.
• The Layer 3 multicast feature is supported on the following leaf switches:
• EX models:
• N9K-93108TC-EX
• N9K-93180LC-EX
• N9K-93180YC-EX
• FX models:
• N9K-93108TC-FX
• N9K-93180YC-FX
• N9K-C9348GC-FXP
• FX2 models:
• N9K-93240YC-FX2
• N9K-C9336C-FX2
• PIM is supported on Layer 3 Out routed interfaces and routed subinterfaces including Layer 3 port-channel
interfaces. PIM is not supported on Layer 3 Out SVI interfaces.
• Enabling PIM on an L3Out causes an implicit external network to be configured. This action results in
the L3Out being deployed and protocols potentially coming up even if you have not defined an external
network.
• For Layer 3 multicast support, when the ingress leaf switch receives a packet from a source that is attached
on a bridge domain, and the bridge domain is enabled for multicast routing, the ingress leaf switch sends
only a routed VRF copy to the fabric (routed implies that the TTL is decremented by 1, and the source-mac
is rewritten with a pervasive subnet MAC). The egress leaf switch also routes the packet into receivers
in all the relevant bridge domains. Therefore, if a receiver is on the same bridge domain as the source,
but on a different leaf switch than the source, that receiver continues to get a routed copy, although it is
in the same bridge domain. This also applies if the source and receiver are on the same bridge domain
and on the same leaf switch, if PIM is enabled on this bridge domain.
For more information, see details about Layer 3 multicast support for multipod that leverages existing
Layer 2 design, at the following link Adding Pods.
• Starting with Release 3.1(1x), Layer 3 multicast is supported with FEX. Multicast sources or receivers
that are connected to FEX ports are supported. For further details about how to add FEX in your testbed,
see Configure a Fabric Extender with Application Centric Infrastructure at this URL:
https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/
application-policy-infrastructure-controller-apic/200529-Configure-a-Fabric-Extender-with-Applica.html.
For releases preceeding Release 3.1(1x), Layer 3 multicast is not supported with FEX. Multicast sources
or receivers that are connected to FEX ports are not supported.
Note Cisco ACI does not support IP fragmentation. Therefore, when you configure Layer 3 Outside (L3Out)
connections to external routers, or multipod connections through an Inter-Pod Network (IPN), it is critical
that the interface MTU is set appropriately on both ends of a link. On some platforms, such as Cisco ACI,
Cisco NX-OS, and Cisco IOS, the configurable MTU value does not take into account the Ethernet headers
(matching IP MTU, and excluding the 14-18 Ethernet header size), while other platforms, such as IOS-XR,
include the Ethernet header in the configured MTU value. A configured value of 9000 results in a max IP
packet size of 9000 bytes in Cisco ACI, Cisco NX-OS, and Cisco IOS, but results in a maximum IP packet
size of 8986 bytes for an IOS-XR untagged interface.
For the appropriate MTU values for each platform, see the relevant configuration guides.
We highly recommend that you test the MTU using CLI-based commands. For example, on the Cisco NX-OS
CLI, use a command such as ping 1.1.1.1 df-bit packet-size 9000 source-interface ethernet 1/1.
Step 5 (Optional) [no] ip pim auto-rp {forward Configures PIM auto-RP (Rendezvous Point)
[listen] | listen | mapping-agent-policy options. Auto-RP automates the distribution
mapping-agent-policy-name } of group-to-RP mappings in a PIM network.
You can choose to forward auto-RP messages,
Example:
listen to auto-RP messages, or associate a
apic1(config-tenant-vrf)# ip pim auto-rp route-map policy for filtering mapping agent
forward listen
messages.
Step 6 (Optional) [no] ip pim bsr {forward [listen] Configures PIM bootstrap router (BSR)
| listen | bsr-policy options. BSR performs similarly to auto-RP
mapping-agent-policy-name } in that it uses candidate routers for the RP
function and for relaying the RP information
Example:
for a group. RP information is distributed
apic1(config-tenant-vrf)# ip pim bsr through BSR messages, which are carried
forward listen
within PIM messages. You can choose to
forward Bootstrap/Candidate-RP messages,
listen to Bootstrap/Candidate-RP messages, or
associate a route-map policy for filtering BSR
messages.
Step 7 (Optional) [no] ip pim fast-convergence Enables the PIM fast convergence feature,
which allows the switch to discover
Example:
unresponsive neighbors more quickly.
apic1(config-tenant-vrf)# ip pim
fast-convergence
Step 8 (Optional) [no] ip pim mtu mtu-size Configures the maximum size of a PIM
message. The range is 1500 to 65536 bytes.
Example:
apic1(config-tenant-vrf)# ip pim mtu
1500
Step 9 (Optional) [no] ip pim register-policy Specifies the name of a policy for filtering
register-policy-name register messages.
Example:
apic1(config-tenant-vrf)# ip pim
register-policy regPolicy1
Step 11 (Optional) [no] ip pim register-source Configures a source IP address for PIM
ip-address messages.
Example:
apic1(config-tenant-vrf)# ip pim
register-source 192.0.20.123
Step 12 (Optional) [no] ip pim rp-address ip-address Configures a static route processor (RP)
[route-map route-map-name] address for a multicast group range.
Example:
apic1(config-tenant-vrf)# ip pim
rp-address 192.0.20.99
Step 13 (Optional) [no] ip pim sg-expiry-timer Configures the (S, G) expiry timer interval for
ip-address [sg-list route-map-name] PIM sparse mode (PIM-SM) (S, G) multicast
routes. The range is 180 to 604801 seconds.
Example:
The optional sg-list parameter specifies S,G
apic1(config-tenant-vrf)# ip pim values to which the timer applies. The default
sg-expiry-timer 4096
is 4096.
Step 14 (Optional) [no] ip pim ssm route-map Configures Source Specific Multicast (SSM),
route-map-name which is an extension of IP multicast in which
datagram traffic is forwarded to receivers from
Example:
only those multicast sources that the receivers
apic1(config-tenant-vrf)# ip pim ssm have explicitly joined. The route-map policy
route-map SSMRtMap
lists the group prefixes.
Step 15 (Optional) [no] ip pim state-limit max-entries Configures a maximum number of PIM state
[reserved route-map-name entries in the current VRF instance. The range
[maximum-reserve-state-entries]] is 0 to 4294967295 maximum state entries.
You can optionally specify a number of state
Example:
entries to be reserved for the routes specified
apic1(config-tenant-vrf)# ip pim in a policy map and you can specify the
state-limit 100000 reserved
myReservedPolicy 40000
maximum reserved (*, G) and (S, G) entries
allowed in this VRF. This number must be less
than or equal to the maximum states allowed.
The range is from 1 to 4294967295.
Step 16 (Optional) [no] ip pim use-shared-tree-only Creates the PIM (*, G) state only (where no
group-list policy-name source state is created). The policy defines the
group prefixes where this feature is applied.
Example:
apic1(config-tenant-vrf)# ip pim
use-shared-tree-only group-list myGroup1
What to do next
Configure IGMP options for the VRF.
Procedure
Step 10 [no] ip igmp group-timeout seconds Sets the group membership timeout for
IGMPv2. The range is 3 to 65535 seconds. The
Example:
default is 260 seconds.
apic1(config-tenant-interface)# ip igmp
group-timeout 260
Step 11 [no] ip igmp inherit interface-policy Associates a IGMP interface policy to this
policy-name interface.
Example:
apic1(config-tenant-interface)# ip igmp
inherit interface-policy MyIfPolicy
Step 12 [no] ip igmp join-group route-map Statically binds one or more multicast groups
route-map-name to the interface. The route-map policy lists the
group prefixes, group ranges, and source
Example:
prefixes.
apic1(config-tenant-interface)# ip igmp
join-group route-map MyGroupsRMap
Step 13 [no] ip igmp last-member-query-count count Sets the number of times that the software
sends an IGMP query in response to a host
Example:
leave message. The range is 1 to 5 queries. The
apic1(config-tenant-interface)# ip igmp default is 2 queries.
last-member-query-count 2
Step 14 [no] ip igmp Sets the query interval waited after sending
last-member-query-response-time seconds membership reports before the software deletes
the group state. The range is 1 to 25 seconds.
Example:
The default is 1 second.
apic1(config-tenant-interface)# ip igmp
last-member-query-response-time 1
Step 15 [no] ip igmp querier-timeout seconds Sets the number of seconds that the software
waits after the previous querier has stopped
Example:
querying and before it takes over as the querier.
apic1(config-tenant-interface)# ip igmp The range is 1 to 65535 seconds. The default
querier-timeout 255
is 255 seconds.
Step 17 [no] ip igmp query-max-response-time Sets the response time advertised in IGMP
seconds queries. You can tune the burstiness of IGMP
messages on the network by setting a larger
Example:
value so that host responses are spread out over
apic1(config-tenant-interface)# ip igmp a longer time. This value must be less than the
query-max-response-time 10
query interval. The range is 1 to 25 seconds.
The default is 10 seconds.
Step 19 [no] ip igmp report-policy policy-name Configures an access policy for IGMP reports
that is based on a route-map policy.
Example:
apic1(config-tenant-interface)# ip igmp
report-policy MyReportPolicy
Step 20 [no] ip igmp robustness-variable value Sets the robustness variable to compensate for
packet loss on a congested network. The
Example:
robustness value is used by the IGMP software
apic1(config-tenant-interface)# ip igmp to determine the number of times to send
robustness-variable 2
messages. You can use a larger value for a
lossy network. The range is 1 to 7. The default
is 2.
Step 21 [no] ip igmp snooping Enables IGMP snooping for the interface.
Example:
apic1(config-tenant-interface)# ip igmp
snooping
Step 22 [no] ip igmp snooping fast-leave Enables the software to remove the group state
when it receives an IGMP Leave report without
Example:
sending an IGMP query message. This
apic1(config-tenant-interface)# ip igmp parameter is used for IGMPv2 hosts when no
snooping fast-leave
more than one host is present on each port.
Step 23 [no] ip igmp snooping Sets a time interval in seconds after which the
last-member-query-interval group is removed from the associated port if
no hosts respond to an IGMP query message.
Example:
Step 24 [no] ip igmp snooping policy policy-name Associates the bridge domain with an IGMP
snooping policy.
Example:
apic1(config-tenant-interface)# ip igmp
snooping policy MySnoopingPolicy
Step 25 [no] ip igmp snooping querier Enables an IP IGMP snooping querier, which
sends out periodic IGMP queries that trigger
Example:
IGMP report messages from hosts who want
apic1(config-tenant-interface)# ip igmp to receive IP multicast traffic. IGMP snooping
snooping querier
listens to these IGMP reports to establish
appropriate forwarding.
Step 26 [no] ip igmp snooping query-interval Configures a snooping query interval when
seconds you do not enable PIM because multicast
traffic does not need to be routed. The range
Example:
is 1 to 18000 seconds. The default is 125
apic1(config-tenant-interface)# ip igmp seconds.
snooping query-interval 125
Step 28 [no] ip igmp snooping startup-query-count Configures snooping for a number of queries
count sent at startup when you do not enable PIM
because multicast traffic does not need to be
Example:
routed. The range is 1 to 10 queries. The
apic1(config-tenant-interface)# ip igmp default is 5 queries.
snooping startup-query-count 5
Step 30 [no] ip igmp startup-query-count count Sets the number of queries sent at startup that
are separated by the startup query interval. The
Example:
range is 1 to 10 queries. The default is 2
apic1(config-tenant-interface)# ip igmp queries.
startup-query-count 2
Step 31 [no] ip igmp startup-query-interval seconds Sets the query interval used when the software
starts up. By default, this interval is shorter
Example:
than the query interval so that the software can
apic1(config-tenant-interface)# ip igmp establish the group state as quickly as possible.
startup-query-interval 31
Step 32 [no] ip igmp state-limit max-states [reserved Configures a per interface limit on the number
route-map-name [max-reserved-gsg-entries]] of mroutes states created as a result of IGMP
membership reports (IGMP joins). The range
Example:
of states allowed is 1 to 4294967295 states.
apic1(config-tenant-interface)# ip igmp You can optionally specify a number of state
state-limit 100000 reserved
myReservedPolicy 40000
entries to be reserved for the routes specified
in a policy map and you can specify the
maximum reserved (*, G) and (S, G) entries
allowed on the interface. The number of
reserved states must be less than or equal to
the maximum states allowed. The range is from
1 to 4294967295.
Step 33 [no] ip igmp static-oif route-map Statically binds a multicast group to the
route-map-name outgoing interface (OIF), which is handled by
the device hardware. The route map defines
Example:
the group prefixes where this feature is applied.
apic1(config-tenant-interface)# ip igmp
static-oif route-map MyOifMap
Step 34 [no] ip igmp version {v1 | v2 | v3} Configures the IGMP version number for the
interface. The default version is v2.
Example:
apic1(config-tenant-interface)# ip igmp
version v3
What to do next
Configure an L3 Out for the tenant, enable PIM, and configure the leaf interface.
Procedure
Step 11 [no] ip igmp group-timeout seconds Sets the group membership timeout for
IGMPv2. The range is 3 to 65535 seconds. The
Example:
default is 260 seconds.
apic1(config-leaf-if)# ip igmp
group-timeout 260
Step 12 [no] ip igmp inherit interface-policy Associates a IGMP interface policy to this
policy-name interface.
Example:
apic1(config-leaf-if)# ip igmp inherit
interface-policy MyIfPolicy
Step 13 [no] ip igmp join-group route-map Statically binds one or more multicast groups
route-map-name to the interface. The route-map policy lists the
group prefixes, group ranges, and source
Example:
prefixes.
apic1(config-leaf-if)# ip igmp
join-group route-map MyGroupsRMap
Step 14 [no] ip igmp last-member-query-count count Sets the number of times that the software
sends an IGMP query in response to a host
Example:
leave message. The range is 1 to 5 queries. The
apic1(config-leaf-if)# ip igmp default is 2 queries.
last-member-query-count 2
Step 15 [no] ip igmp Sets the query interval waited after sending
last-member-query-response-time seconds membership reports before the software deletes
the group state. The range is 1 to 25 seconds.
Example:
The default is 1 second.
apic1(config-leaf-if)# ip igmp
last-member-query-response-time 1
Step 16 [no] ip igmp querier-timeout seconds Sets the number of seconds that the software
waits after the previous querier has stopped
Example:
querying and before it takes over as the querier.
apic1(config-leaf-if)# ip igmp The range is 1 to 65535 seconds. The default
querier-timeout 255
is 255 seconds.
Step 17 [no] ip igmp query-interval seconds Sets the frequency at which the software sends
IGMP host query messages. You can tune the
Example:
number of IGMP messages on the network by
apic1(config-leaf-if)# ip igmp setting a larger value so that the software sends
query-interval 125
IGMP queries less often. The range is 1 to
18000 seconds. The default is 125 seconds.
Step 18 [no] ip igmp query-max-response-time Sets the response time advertised in IGMP
seconds queries. You can tune the burstiness of IGMP
messages on the network by setting a larger
Example:
value so that host responses are spread out over
Step 20 [no] ip igmp report-policy policy-name Configures an access policy for IGMP reports
that is based on a route-map policy.
Example:
apic1(config-leaf-if)# ip igmp
report-policy MyReportPolicy
Step 21 [no] ip igmp robustness-variable value Sets the robustness variable to compensate for
packet loss on a congested network. The
Example:
robustness value is used by the IGMP software
apic1(config-leaf-if)# ip igmp to determine the number of times to send
robustness-variable 2
messages. You can use a larger value for a
lossy network. The range is 1 to 7. The default
is 2.
Step 22 [no] ip igmp startup-query-count count Sets the number of queries sent at startup that
are separated by the startup query interval. The
Example:
range is 1 to 10 queries. The default is 2
apic1(config-leaf-if)# ip igmp queries.
startup-query-count 2
Step 23 [no] ip igmp startup-query-interval seconds Sets the query interval used when the software
starts up. By default, this interval is shorter
Example:
than the query interval so that the software can
apic1(config-leaf-if)# ip igmp establish the group state as quickly as possible.
startup-query-interval 31
The range is 1 to 18000 seconds. The default
is 260 seconds. The default is 31 seconds.
Step 24 [no] ip igmp state-limit max-states [reserved Configures a per interface limit on the number
route-map-name [max-reserved-gsg-entries]] of mroutes states created as a result of IGMP
membership reports (IGMP joins). The range
Example:
of states allowed is 1 to 4294967295 states.
apic1(config-leaf-if)# ip igmp You can optionally specify a number of state
state-limit 100000 reserved
myReservedPolicy 40000
entries to be reserved for the routes specified
in a policy map and you can specify the
maximum reserved (*, G) and (S, G) entries
allowed on the interface. The number of
reserved states must be less than or equal to
the maximum states allowed. The range is from
1 to 4294967295.
Step 26 [no] ip igmp version {v1 | v2 | v3} Configures the IGMP version number for the
interface. The default version is v2.
Example:
apic1(config-leaf-if)# ip igmp version
v3
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# vrf context exampleCorp_vrf1
apic1(config-tenant-vrf)# ip pim
apic1(config-tenant-vrf)# ip pim fast-convergence
apic1(config-tenant-vrf)# ip pim bsr forward
# ENABLE AND CONFIGURE IGMP ON THE TENANT VRF AND BRIDGE DOMAIN
apic1(config-tenant-vrf)# ip igmp
apic1(config-tenant-vrf)# exit
apic1(config-tenant)# interface bridge-domain exampleCorp_bd
apic1(config-tenant-interface)# ip multicast
apic1(config-tenant-interface)# ip igmp allow-v3-asm
apic1(config-tenant-interface)# ip igmp fast-leave
apic1(config-tenant-interface)# exit
Procedure
apic1(config-tenant-l3ext-epg)# match
ip 192.0.20.0/24
apic1(config-tenant-l3ext-epg)# match
ipv6 2001::1/64
Step 6 set qos-class class Specifies the QOS level for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# set
qos-class level1
Step 7 set dscp dscp-value Specifies the DSCP value for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# set dscp
af31
Step 9 contract provider contract-name Specifies the provider contract for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# contract
provider cProvider1
Step 10 contract deny contract-name Specifies a deny contract for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# contract
deny cDeny1
Step 11 exit
Example:
apic1(config-tenant-l3ext-epg)# exit
Step 12 exit
Example:
apic1(config-tenant)# exit
Step 14 vrf context tenant tenant-name vrf vrf-name Configures a tenant VRF on the node.
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf v1
Step 15 external-l3 epg epg-name Associates the external layer 3 EPG on the
VRF.
Example:
apic1(config-leaf-vrf)# external-l3 epg
epgExtern1
Examples
This example shows how to configure an external layer 3 EPG and to deploy the EPG on a leaf.
apic1# configure
apic1(config)# tenant exampleCorp
Step 5 vrf member vrf-name Associates the L3Out with the tenant VRF.
Example:
apic1(config-tenant-l3out)# vrf member
v1
Step 9 vrf context tenant tenant-name vrf vrf-name Configures a tenant VRF on the node.
l3out l3out-name
Example:
apic1(config-leaf)# vrf context tenant
exampleCorp vrf v1 l3out out1
Step 10 Required: [no] router-id ipv4-address Assigns a router ID for routing protocols
running on the VRF.
Example:
apic1(config-leaf-vrf)# router-id
1.2.3.4
Step 11 [no] {ip | ipv6} route ip-prefix/masklen Configures static route information for the
next-hop-address [preferred] VRF.
Example:
apic1(config-leaf-vrf)# ip route
21.1.1.1/32 32.1.1.1
apic1(config-leaf-vrf)# ipv6 route
5001::1/128 6002::1
Examples
This example shows how to create a named L3Out under the tenant, assign it to the tenant VRF, and
deploy it on the border leaf switch.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# vrf context v1
apic1(config-tenant)# l3out out1
apic1(config-tenant-l3out)# vrf member v1
apic1(config-tenant-l3out)# exit
apic1(config-tenant)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf v1 l3out out1
apic1(config-leaf-vrf)# router-id 1.2.3.4
What to do next
Configure layer 3 interfaces for the named L3Out.
Procedure
Step 5 vrf member tenant tenant-name vrf vrf-name Attaches the interface to the tenant VRF.
l3out l3out-name
Step 6 [no] {ip | ipv6} address ip-prefix/masklen Configures IP addresses on the interface. The
[eui64] [secondary] [preferred] specified address can be declared as either:
Example: • preferred —The default source address
for traffic from the interface.
apic1(config-leaf-if)# ip address
10.1.1.1/24 • secondary —The secondary address of
apic1(config-leaf-if)# ipv6 address the interface.
2001::1/64 preferred
With the optional eui64 keyword, the host can
assign itself a 64-bit Extended Unique Identifier
(EUI).
In this mode, you can also configure ipv6
link-local , mac address , mtu , and other
layer 3 properties on the interface.
Examples
This example shows how to assign a layer 3 port to a named L3Out.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/20
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v1 l3out out1
apic1(config-leaf-if)# ip address 10.1.1.1/24
apic1(config-leaf-if)# ipv6 address 2001::1/64 preferred
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface eth 1/5
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vlan-domain member d1
apic1(config-leaf-if)# exit
apic1(config-leaf)# interface ethernet 1/5.1000
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v1 l3out out1
apic1(config-leaf-if)# ip address 10.1.1.1/24
apic1(config-leaf-if)# ipv6 address 2001::1/64 preferred
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# interface vlan 200
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v1
These route-maps are created when you associate a leaf to the L3Out through the vrf context tenant
tenant-name vrf vrf-name l3out l3out-name command.
• The scope of the route-maps under the named L3Out is always global and is applicable on all nodes
where the Named L3Out is deployed.
• All commands under the route-map (such as match prefix-list , match community-list , match
bridge-domain ) are the same as the route-map configuration for the Basic Mode discussed in the previous
sections.
Procedure
Step 3 [no] vrf context tenant tenant-name vrf Configures a tenant VRF on the node.
vrf-name l3out l3out-name
Example:
Step 4 Required: [no] route-map name Creates a route-map and enters route-map
configuration. This will be the import
Example:
route-map.
apic1(config-leaf-vrf)# route-map
out1_in
Step 5 Required: [no] ip prefix-list list-name permit Creates a prefix-list under the route-map.
prefix/masklen [le {32 | 128}]
Example:
apic1(config-leaf-vrf-route-map)# ip
prefix-list p1 permit 15.1.1.0/24
Step 6 Required: [no] match prefix-list list-name Matches a prefix-list that has already been
created and enters the match mode to configure
Example:
the route-control profile for the prefix-list.
apic1(config-leaf-vrf-route-map)# match
prefix-list p1
Step 9 Required: [no] route-map name Creates a route-map and enters route-map
configuration. This will be the export
Example:
route-map.
apic1(config-leaf-vrf)# route-map
out1_out
Step 10 Required: [no] ip prefix-list list-name permit Creates a prefix-list under the route-map.
prefix/masklen [le {32 | 128}]
Example:
apic1(config-leaf-vrf-route-map)# ip
prefix-list p2 permit 16.1.1.0/24
Step 11 Required: [no] match prefix-list list-name Matches a prefix-list that has already been
created and enters the match mode to configure
Example:
the route-control profile for the prefix-list.
apic1(config-leaf-vrf-route-map)# match
prefix-list p2
Step 12 Required: set tag name Sets the tag value. The name parameter is an
unsigned integer.
Example:
Step 14 Required: [no] match bridge-domain Matches a bridge domain in order to export its
list-name public subnets through the protocol.
Example:
apic1(config-leaf-vrf-route-map)# match
bridge-domain bd1
Step 16 Required: [no] route-map name Creates a route-map and enters route-map
configuration. This will be the shared
Example:
route-map.
apic1(config-leaf-vrf)# route-map
out1_shared
Step 17 Required: [no] ip prefix-list list-name permit Creates a prefix-list under the route-map.
prefix/masklen [le {32 | 128}]
Example:
apic1(config-leaf-vrf-route-map)# ip
prefix-list p3 permit 16.10.1.0/24
Step 18 Required: [no] match prefix-list list-name Matches a prefix-list that has already been
created and enters the match mode to configure
Example:
the route-control profile for the prefix-list.
apic1(config-leaf-vrf-route-map)# match
prefix-list p3
Step 19 Required: contract provider name Adds contract, required to leak routes
(matching this prefix-list) from this VRF.
Example:
apic1(config-leaf-vrf-route-map-match)#
contract provider default
Examples
This example shows how to configure route maps for a named L3Out.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant exampleCorp vrf v1 l3out out1
Procedure
Step 5 neighbor ip-address [/masklength] l3out Specifies the IP address of the neighbor.
l3out-name
Example:
apic1(config-leaf-bgp-vrf)# neighbor
192.0.2.229 l3out out1
Step 8 update-source ethernet interface-range Update the Source IP for BGP Packets to one
of loopback, physical, sub-interface or SVI
Example:
interfaces..
apic1(config-leaf-bgp-vrf-neighbor)#
update-source ethernet 1/3
Examples
This example shows how to configure BGP routing protocol for a named L3Out.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router bgp 100
apic1(config-bgp)# vrf member tenant exampleCorp vrf v1
apic1(config-leaf-bgp-vrf)# neighbor 192.0.2.229 l3out out1
apic1(config-leaf-bgp-vrf-neighbor)# remote-as 300
apic1(config-leaf-bgp-vrf-neighbor)# allow-self-as-count 5
apic1(config-leaf-bgp-vrf-neighbor)# update-source ethernet 1/3
Procedure
Step 3 router ospf default Creates an OSPF routing process and enters
OSPF policy configuration.
Example:
apic1(config-leaf)# router ospf default
Step 4 vrf member tenant tenant-name vrf vrf-name Enables a VRF in the OSPF session.
Example:
apic1(config-leaf-ospf)# vrf member
tenant exampleCorp vrf v100
Step 6 area area-id loopback loopback-address When OSPF is used as a connectivity protocol
for BGP, OSPF advertises the loopback
Example:
address which is used as the source of the BGP
apic1(config-leaf-ospf-vrf)# area session. Note that the loopback IP address and
0.0.0.1 loopback 192.0.20.11
not the loopback ID is used. In this case, a
BGP session relying on OSPF will use the
same loopback IP address in its update-source
command.
Step 11 vlan-domain member domain-name Assign a VLAN domain to the interface. The
VLAN domain must have already been created
Example:
using the vlan-domain command in the
apic1(config-leaf-if)# vlan-domain global configuration mode.
member dom1
Step 13 vrf member tenant tenant-name vrf vrf-name Attaches the interface to the tenant VRF.
l3out l3out-name
Example:
apic1(config-leaf-if)# vrf member tenant
exampleCorp vrf v1 l3out out1
Step 14 [no] {ip | ipv6} address ip-prefix/masklen Configures IP addresses on the interface. The
[eui64] [secondary] [preferred] specified address can be declared as either:
Example: • preferred —The default source address
for traffic from the interface.
apic1(config-leaf-if)# ip address
10.1.1.1/24 • secondary —The secondary address of
apic1(config-leaf-if)# ipv6 address the interface.
2001::1/64 preferred
With the optional eui64 keyword, the host
can assign itself a 64-bit Extended Unique
Identifier (EUI).
In this mode, you can also configure ipv6
link-local , mac address , mtu , and other
layer 3 properties on the interface.
Step 15 {ip | ipv6} router ospf default area area-id Creates an OSPF routing process and enters
OSPF policy configuration.
Example:
apic1(config-leaf-if)# ip router ospf
default area 0.0.0.1
Examples
This example shows how to configure OSPF routing protocol for a named L3Out.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router ospf default
Procedure
Step 4 vrf member tenant tenant-name vrf vrf-name Specifies the VRF instance to associate with
subsequent configuration mode commands.
Example:
apic1(config-eigrp)# vrf member tenant
exampleCorp vrf v100
Step 5 autonomous-system asn l3out l3out-name Enters Autonomous System configuration for
EIGRP.
Example:
apic1(config-eigrp-vrf)#
autonomous-system 500 l3out out1
Step 9 vlan-domain member domain-name Assign a VLAN domain to the interface. The
VLAN domain must have already been created
Example:
using the vlan-domain command in the
apic1(config-leaf-if)# vlan-domain global configuration mode.
member dom1
Step 11 vrf member tenant tenant-name vrf vrf-name Attaches the interface to the tenant VRF.
l3out l3out-name
Example:
apic1(config-leaf-if)# vrf member tenant
exampleCorp vrf v1 l3out out1
Step 12 [no] {ip | ipv6} address ip-prefix/masklen Configures IP addresses on the interface. The
[eui64] [secondary] [preferred] specified address can be declared as either:
Example: • preferred —The default source address
for traffic from the interface.
apic1(config-leaf-if)# ip address
10.1.1.1/24 • secondary —The secondary address of
apic1(config-leaf-if)# ipv6 address the interface.
2001::1/64 preferred
With the optional eui64 keyword, the host
can assign itself a 64-bit Extended Unique
Identifier (EUI).
In this mode, you can also configure ipv6
link-local , mac address , mtu , and other
layer 3 properties on the interface.
Step 13 {ip | ipv6} router eigrp default Sets EIGRP policies to default.
Example:
apic1(config-leaf-if)# ip router eigrp
default
Examples
This example shows how to configure EIGRP routing protocol for a named L3Out.
apic1# configure
apic1(config)# leaf 101
apic1(config-leaf)# router eigrp default
apic1(config-eigrp)# vrf member tenant exampleCorp vrf v1
apic1(config-eigrp-vrf)# autonomous-system 500 l3out out1
apic1(config-eigrp-vrf)# exit
apic1(config-eigrp)# exit
apic1(config-leaf)# interface eth 1/5
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant exampleCorp vrf v1 l3out out1
apic1(config-leaf-if)# ip address 10.1.1.1/24
apic1(config-leaf-if)# ip router eigrp default
Procedure
Step 3 external-l3 epg epg-name l3out l3out-name Enters the external-l3 EPG configuration mode.
Example:
apic1(config-tenant)# external-l3 epg
epg1 l3out out1
apic1(config-tenant-l3ext-epg)# match ip
192.0.20.0/24
apic1(config-tenant-l3ext-epg)# match
ipv6 2001::1/64
Step 5 contract consumer contract-name Specifies the consumer contract for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# contract
consumer cConsumer1
Step 6 contract provider contract-name Specifies the provider contract for the EPG.
Example:
apic1(config-tenant-l3ext-epg)# contract
provider cProvider1
Examples
This example shows how to configure an external layer 3 EPG for a named L3Out.
apic1# configure
apic1(config)# tenant exampleCorp
apic1(config-tenant)# external-l3 epg epg1 l3out out1
apic1(config-tenant-l3ext-epg)# match ip 192.0.20.0/24
apic1(config-tenant-l3ext-epg)# match ipv6 2001::1/64
apic1(config-tenant-l3ext-epg)# contract consumer cConsumer1
apic1(config-tenant-l3ext-epg)# contract provider cProvider1
ACI bridge domain ND always operates in flood mode; unicast mode is not supported.
The ACI fabric ND support includes the following:
• Interface policies (nd:IfPol) control ND timers and behavior for NS/NA messages.
• ND prefix policies (nd:PfxPol) control RA messages.
• Configuration of IPv6 subnets for ND (fv:Subnet).
• ND interface policies for external networks.
• Configurable ND subnets for external networks, and arbitrary subnet configurations for pervasive bridge
domains are not supported.
• Per Interface
• Control of ND packets (NS/NA)
• Neighbor Solicitation Interval
• Neighbor Solicitation Retry count
• Control of RA packets
• Suppress RA
• Suppress RA MTU
• RA Interval, RA Interval minimum, Retransmit time
Configuring a Tenant, VRF, and Bridge Domain with IPv6 Neighbor Discovery
on the Bridge Domain Using the NX-OS Style CLI
Procedure
Step 1 Configure an IPv6 neighbor discovery interface policy and assign it to a bridge domain:
a) Create an IPv6 neighbor discovery interface policy:
Example:
Step 2 Configure an IPV6 bridge domain subnet and neighbor discovery prefix policy on the subnet:
Example:
Procedure
Step 2 tenant tenant_name Creates a tenant and enters the tenant mode.
Example:
Step 4 ipv6 nd mtu mtu value Assigns an MTU value to the IPv6 ND policy.
Example:
apic1(config-tenant-template-ipv6-nd)#
ipv6 nd mtu 1500
apic1(config-tenant-template-ipv6)# exit
apic1(config-tenant-template)# exit
apic1(config-tenant)#
Step 7 vrf member VRF_name Associates the VRF with the Layer 3 Out.
Example:
Step 8 external-l3 epg instp l3out l3extOut001 Assigns the Layer 3 Out and the VRF to a
Layer 3 interface.
Example:
Step 10 vrf context tenant ExampleCorp vrf pvn1 Associates the VRF to the leaf switch.
l3out l3extOut001
Example:
apic1(config-leaf-vrf)# exit
Step 12 vrf member tenant ExampleCorp vrf pvn1 Specifies the associated Tenant, VRF, Layer
l3out l3extOut001 3 Out in the interface.
Example:
Step 13 ipv6 address 2001:20:21:22::2/64 preferred Specifies the primary or preferred IPv6
address.
Example:
Step 15 inherit ipv6 nd NDPol001 Configures the ND policy under the Layer 3
interface.
Example:
Microsoft NLB
Configuring Microsoft NLB in Unicast Mode Using the NX-OS Style CLI
This task configures Microsoft NLB to flood all of the ports in the bridge domain.
Procedure
Step 5 [no] endpoint {ip | ipv6} ip-address epnlb Configures Microsoft NLB in unicast mode,
mode mode-uc mac mac-address where:
Example: • ip-address is the Microsoft NLB cluster
apic1 (config-tenant-app-epg)# endpoint VIP.
ip 192.0.2.2/32 epnlb mode mode-uc mac
03:BF:01:02:03:04 • mac-address is the Microsoft NLB cluster
MAC address.
Configuring Microsoft NLB in Multicast Mode Using the NX-OS Style CLI
This task configures Microsoft NLB to flood only on certain ports in the bridge domain.
Procedure
Step 5 [no] endpoint {ip | ipv6} ip-address epnlb Configures Microsoft NLB in static multicast
mode mode-mcast--static mac mac-address mode, where:
Example: • ip-address is the Microsoft NLB cluster
apic1 (config-tenant-app-epg)# endpoint VIP.
ip 192.0.2.2/32 epnlb mode
mode-mcast--static mac 03:BF:01:02:03:04 • mac-address is the Microsoft NLB cluster
MAC address.
Step 6 [no] nld static-group mac-address leaf Adds Microsoft NLB multicast VMAC to the
leaf-num interface {ethernet slot/port | EPG ports where the Microsoft NLB servers
port-channel port-channel-name } vlan are connected, where:
portEncapVlan
• mac-address is the Microsoft NLB cluster
Example: MAC address that you entered in Step 5,
apic1 (config-tenant-app-epg)# nlb on page 287.
static-group 03:BF:01:02:03:04 leaf 102
interface ethernet 1/12 vlan 19 • leaf-num is the leaf switch that contains
the interface to be added or removed.
• port-channel-name is the name of the
port-channel, when the port-channel option
is used.
• portEncapVlan is the encapsulation VLAN
for the static member of the application
EPG.
Configuring Microsoft NLB in IGMP Mode Using the NX-OS Style CLI
This task configures Microsoft NLB to flood only on certain ports in the bridge domain.
Procedure
Step 5 [no] endpoint {ip | ipv6} ip-address epnlb Configures Microsoft NLB in IGMP mode,
mode mode-mcast-igmp group where:
multicast-IP-address
• ip-address is the Microsoft NLB cluster
Example: VIP.
apic1 (config-tenant-app-epg)# endpoint
ip 192.0.2.2/32 epnlb mode
• multicast-IP-address is the multicast IP
mode-mcast-igmp group 1.3.5.7 for the NLB endpoint group.
MLD Snooping
Configuring and Assigning an MLD Snooping Policy to a Bridge Domain using
the NX-OS Style CLI
Before you begin
• Create the tenant that will consume the MLD Snooping policy.
• Create the bridge domain for the tenant, where you will attach the MLD Snooping policy.
Procedure
Step 3 template ipv6 mld snooping policy Creates an MLD snooping policy. The example
policy-name NX-OS style CLI sequence creates an MLD
snooping policy named mldPolicy1.
Example:
Step 4 [no] ipv6 mld snooping Enables or disables the admin state of the MLD
snoop policy. The default state is disabled.
Example:
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping
apic1(config-tenant-template-ip-mld-snooping)#
no ipv6 mld snooping
Step 5 [no] ipv6 mld snooping fast-leave Enables or disables IPv6 MLD snooping
fast-leave processing.
Example:
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping fast-leave
apic1(config-tenant-template-ip-mld-snooping)#
no ipv6 mld snooping fast-leave
Step 6 [no] ipv6 mld snooping querier Enables or disables IPv6 MLD snooping
querier processing. For the enabling querier
Example:
option to be effectively enabled on the assigned
policy, you must also enable the querier option
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping querier in the subnets assigned to the bridge domains
apic1(config-tenant-template-ip-mld-snooping)# to which the policy is applied, as described in
no ipv6 mld snooping querier Step 14, on page 290.
Step 7 ipv6 mld snooping Changes the IPv6 MLD snooping last member
last-member-query-interval parameter query interval parameter. The example NX-OS
style CLI sequence changes the IPv6 MLD
Example:
snooping last member query interval parameter
to 25 seconds. Valid options are 1-25. The
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping default is 1 second.
last-member-query-interval 25
Step 8 ipv6 mld snooping query-interval parameter Changes the IPv6 MLD snooping query
interval parameter. The example NX-OS style
Example:
CLI sequence changes the IPv6 MLD snooping
query interval parameter to 300 seconds. Valid
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping query-interval 300 options are 1-18000. The default is 125
seconds.
Step 10 ipv6 mld snooping startup-query-count Changes the IPv6 MLD snooping number of
parameter initial queries to send. The example NX-OS
style CLI sequence changes the IPv6 MLD
Example:
snooping number of initial queries to send to
10. Valid options are 1-10. The default is 2.
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping startup-query-count
10
Step 11 ipv6 mld snooping startup-query-interval Changes the IPv6 MLD snooping time for
parameter sending initial queries. The example NX-OS
style CLI sequence changes the IPv6 MLD
Example:
snooping time for sending initial queries to
300 seconds. Valid options are 1-18000. The
apic1(config-tenant-template-ip-mld-snooping)#
ipv6 mld snooping default is 31 seconds.
startup-query-interval 300
apic1(config-tenant-template-ip-mld-snooping)#
exit
apic1(config-tenant)#
Step 15 ipv6 mld snooping policy policy-name Associates the bridge domain with an MLD
snooping policy. The example NX-OS style
Example:
CLI sequence associates the bridge domain
apic1(config-tenant-interface)# exit
apic1(config-tenant)#
Configuring HSRP
Configuring HSRP in Cisco APIC Using Inline Parameters in NX-OS Style CLI
HSRP is enabled when the leaf switch is configured.
Procedure
Configuring HSRP in Cisco APIC Using Template and Policy in NX-OS Style
CLI
HSRP is enabled when the leaf switch is configured.
Procedure
All tenant WAN connections use a single session on the spine switches where the WAN routers are connected.
This aggregation of tenant BGP sessions towards the Data Center Interconnect Gateway (DCIG) improves
control plane scale by reducing the number of tenant BGP sessions and the amount of configuration required
for all of them. The network is extended out using Layer 3 subinterfaces configured on spine fabric ports.
Transit routing with shared services using GOLF is not supported.
A Layer 3 external outside network (L3extOut) for GOLF physical connectivity for a spine switch is specified
under the infra tenant, and includes the following:
• LNodeP (l3extInstP is not required within the L3Out in the infra tenant. )
• A provider label for the L3extOut for GOLF in the infra tenant.
• OSPF protocol policies
• BGP protocol policies
All regular tenants use the above-defined physical connectivity. The L3extOut defined in regular tenants
requires the following:
• An l3extInstP (EPG) with subnets and contracts. The scope of the subnet is used to control import/export
route control and security policies. The bridge domain subnet must be set to advertise externally and it
must be in the same VRF as the application EPG and the GOLF L3Out EPG.
• Communication between the application EPG and the GOLF L3Out EPG is governed by explicit contracts
(not Contract Preferred Groups).
• An l3extConsLbl consumer label that must be matched with the same provider label of an L3Out for
GOLF in the infra tenant. Label matching enables application EPGs in other tenants to consume the
LNodeP external L3Out EPG.
• The BGP EVPN session in the matching provider L3extOut in the infra tenant advertises the tenant
routes defined in this L3Out.
• The default bgpPeerPfxPol policy restricts routes to 20, 000. For ACI WAN Interconnect peers, increase
this as needed.
• In a deployment scenario where there are two L3extOuts on one spine switch, and one of them has the
provider label prov1 and peers with the DCI 1, the second L3extOut peers with DCI 2 with provider
label prov2. If the tenant VRF has a consumer label pointing to any 1 of the provider labels (either prov1
or prov2), the tenant route will be sent out both DCI 1 and DCI 2.
• When aggregating GOLF OpFlex VRFs, the leaking of routes cannot occur in the ACI fabric or on the
GOLF device between the GOLF OpFlex VRF and any other VRF in the system. An external device
(not the GOLF router) must be used for the VRF leaking.
Note Cisco ACI does not support IP fragmentation. Therefore, when you configure Layer 3 Outside (L3Out)
connections to external routers, or multipod connections through an Inter-Pod Network (IPN), it is critical
that the interface MTU is set appropriately on both ends of a link. On some platforms, such as Cisco ACI,
Cisco NX-OS, and Cisco IOS, the configurable MTU value does not take into account the Ethernet headers
(matching IP MTU, and excluding the 14-18 Ethernet header size), while other platforms, such as IOS-XR,
include the Ethernet header in the configured MTU value. A configured value of 9000 results in a max IP
packet size of 9000 bytes in Cisco ACI, Cisco NX-OS, and Cisco IOS, but results in a maximum IP packet
size of 8986 bytes for an IOS-XR untagged interface.
For the appropriate MTU values for each platform, see the relevant configuration guides.
We highly recommend that you test the MTU using CLI-based commands. For example, on the Cisco NX-OS
CLI, use a command such as ping 1.1.1.1 df-bit packet-size 9000 source-interface ethernet 1/1.
Configuration Tasks to Configure Cisco ACI GOLF Services Using the NX-OS
Style CLI
Perform the following tasks to configure GOLF services (using the BGP EVPN protocol), with the NX-OS
style CLI:
• Configure the infra tenant for BGP EVPN, including the VLAN domain, VRF, Interface IP addressing,
and OSPF.
• Configure BGP on the spine node to support BGP EVPN.
• Configure a tenant for BGP EVPN.
• Configure the BGP EVPN route target, route map, and prefix-epg for the tenant.
• Configure BGP address-families to enable distributing BGP EVPN type-2 (MAC-IP) host routes to the
DCIG, with the host-rt-enable command .
Configuring a Spine and the Infra Tenant for BGP EVPN, Using the NX-OS Style
CLI
This task describes how to configure the infra tenant for BGP EVPN, including the VLAN domain, VRF,
Interface IP addressing, and OSPF in the following steps:
Procedure
Step 4 vrf context tenant tenant-name vrf vrf-name Associates the VRF with the tenant.
apic1(config-spine)# vrf context tenant
infra vrf overlay-1
Step 8 vlan-domain member vlan-domain-name Associates the interface with the VLAN
domain.
apic1(config-spine-if)# vlan-domain
member evpn-dom
Step 11 vrf member tenant tenant-name vrf vrf-name Associates the interface with the overlay-1
VRF and the infra tenant.
apic1(config-spine-if)# vrf member
tenant infra vrf overlay-1
Step 14 ip router ospf default area ospf-area-id Sets the default OSPF area ID for the interface.
apic1(config-spine-if)# ip router ospf
default area 0.0.0.150
Step 17 vlan-domain member vlan-domain-name Associates the interface with the VLAN
domain.
apic1(config-spine-if)# vlan-domain
member evpn-dom
Step 20 vrf member tenant tenant-name vrf vrf-name Associates the interface with the overlay-1
VRF and the infra tenant.
apic1(config-spine-if)# vrf member
tenant infra vrf overlay-1
Step 23 ip router ospf default area ospf-area-id Sets the default OSPF area ID for the interface.
apic1(config-spine-if)# ip router ospf
default area 0.0.0.200
Step 26 vrf member tenant tenant-name vrf vrf-name Associates the Router OSPF policy with the
overlay-1 VRF and infra tenant.
apic1(config-spine-ospf)# vrf member
tenant infra vrf overlay-1
Step 27 area area-id loopback loopback-ip-address Configure an OSPF area for the OSPF policy.
apic1(config-spine-ospf-vrf)# area
0.0.0.150 loopback 10.10.5.3
Step 28 area area-id loopback loopback-ip-address Configure another OSPF area for the OSPF
policy.
apic1(config-spine-ospf-vrf)# area
0.0.0.200 loopback 10.10.4.3
Route Target Configuration between the Spine Switches and the DCI
There are two ways to configure EVPN route targets (RTs) for the GOLF VRFs: Manual RT and Auto RT.
The route target is synchronized between ACI spines and DCIs through OpFlex. Auto RT for GOLF VRFs
has the Fabric ID embedded in the format: – ASN: [FabricID] VNID
If two sites have VRFs deployed as in the following diagram, traffic between the VRFs can be mixed.
Site 1 Site 2
Procedure
Step 2 Configure the outbound peer policy to filter routes based on the community in the inbound peer policy.
Example:
ip community-list standard test-com permit 1:1
Step 3 Configure the outbound peer policy to filter the community towards the WAN.
Example:
ip community-list standard test-com permit 1:1
update-source loopback0
send-community both
route-map multi-site-in in
send-community both
Configuring BGP to Support BGP EVPN on a Spine, Using the NX-OS Style CLI
This task shows how to configure BGP on the spine to support BGP EVPN in the following steps:
Procedure
Step 3 router bgp AS-number Configures BGP for the spine node.
apic1(config-spine)# router bgp 100
Step 4 vrf context tenant tenant-name vrf vrf-name Associates the Router BGP policy with the
infra tenant and the overlay-1 VRF.
apic1(config-spine-bgp)# vrf context
tenant infra vrf overlay-1
Step 5 vrf context tenant tenant-name vrf vrf-name Associates the Router BGP policy with the
infra tenant and the overlay-1 VRF.
apic1(config-spine-bgp-vrf)# vrf context
tenant infra vrf overlay-1
Step 8 update-source loopback loopback-ip-address Sets the update source to be the neighbor
vrf vrf-name loopback IP address.
apic1(config-spine-bgp-vrf-neighbor)#
update-source loopback 10.10.4.3
Step 11 neighbor neighbor-ip-address evpn Configures the IP address for an EVPN BGP
neighbor.
apic1(config-spine-bgp-vrf)# neighbor
10.10.5.1 evpn
Step 13 update-source loopback loopback-ip-address Sets the update source to be the neighbor
vrf vrf-name loopback IP address.
apic1(config-spine-bgp-vrf-neighbor)#
update-source loopback 10.10.5.3
Configuring a Tenant for BGP EVPN Using the NX-OS Style CLI
This task shows how to configure a tenant for BGP EVPN in the following steps:
Procedure
Step 6 vrf member vrf-name Associates the bridge domain with the VRF
and tenant.
apic1(config-tenant-bd)# vrf member
vrf-sky
Step 12 vrf member vrf-name Associates the bridge domain with the VRF
and tenant.
apic1(config-tenant-bd)# vrf member
vrf-sky
Procedure
Step 3 vrf context tenant tenant-name vrf vrf-name Enters creates a VRF or enters VRF
configuration mode.
apic1(config-spine)# vrf context tenant
sky vrf vrf_sky
Step 4 address-family { ipv4 | ipv6 } unicast Sets IPv4 or IPv6 unicast address family for
the VRF.
apic1(config-spine-vrf)# address-family
ipv4 unicast
Step 8 route-map route-map-name Creates a route map for EVPN (with prefix
learned from a transit network).
apic1(config-spine-vrf)# route map rmap
Step 9 ip prefix-list ip-pl-name permit A.B.C.D/LEN Adds an IP prefix list to the route map to
permit traffic from the specified subnet.
apic1(config-spine-vrf-route-map)# ip
prefix-list pl permit 11.10.10.0/24
Step 12 match prefix-list pl-name Sets the route-map to match the specified
prefix-list.
apic1(config-spine-vrf-route-map)# match
prefix-list pl
Step 15 evpn export map route-map-name label Assigns a consumer label to the VRF.
consumer-label-name apic1(config-spine-vrf)# evpn export
map rmap label evpn-aci
Step 16 route-map route-map-name Creates a route map for EVPN (with prefix
learned from a transit network).
apic1(config-spine-vrf)# route map rmap2
Step 19 match prefix-list pl-name Sets the route-map to match the specified
prefix-list.
apic1(config-spine-vrf-route-map)# match
prefix-list pl
Step 22 evpn export map route-map-name label Assigns a consumer label to the VRF.
consumer-label-name apic1(config-spine-vrf)# evpn export
map rmap label evpn-aci2
Enabling Distributing BGP EVPN Type-2 Host Routes to a DCIG Using the NX-OS
Style CLI
Procedure
apic1(config-bgp-af)# exit
Cisco ACI GOLF Configuration Example, Using the NX-OS Style CLI
These examples show the CLI commands to configure GOLF Services, which uses the BGP EVPN protocol
over OSPF for WAN routers that are connected to spine switches.
configure
vlan-domain evpn-dom dynamic
exit
spine 111
# Configure Tenant Infra VRF overlay-1 on the spine.
vrf context tenant infra vrf overlay-1
router-id 10.10.3.3
exit
Configure
spine 111
router bgp 100
vrf member tenant infra vrf overlay- 1
neighbor 10.10.4.1 evpn
label golf_aci
update-source loopback 10.10.4.3
remote-as 100
exit
neighbor 10.10.5.1 evpn
label golf_aci2
update-source loopback 10.10.5.3
remote-as 100
exit
exit
exit
configure
tenant sky
vrf context vrf_sky
exit
bridge-domain bd_sky
vrf member vrf_sky
exit
interface bridge-domain bd_sky
ip address 59.10.1.1/24
exit
bridge-domain bd_sky2
vrf member vrf_sky
exit
interface bridge-domain bd_sky2
ip address 59.11.1.1/24
exit
exit
Configuring the BGP EVPN Route Target, Route Map, and Prefix EPG for the Tenant
The following example shows how to configure a route map to advertise bridge-domain subnets through BGP
EVPN.
configure
spine 111
vrf context tenant sky vrf vrf_sky
address-family ipv4 unicast
route-target export 100:1
route-target import 100:1
exit
route-map rmap
ip prefix-list p1 permit 11.10.10.0/24
match bridge-domain bd_sky
exit
match prefix-list p1
exit
route-map rmap2
match bridge-domain bd_sky
exit
match prefix-list p1
exit
exit
Procedure
Step 1 Verify that HostLeak object is enabled under the VRF-AF in question, by entering a command such as the
following in the spine-switch CLI:
Example:
spine1# ls /mit/sys/bgp/inst/dom-apple/af-ipv4-ucast/
ctrl-l2vpn-evpn ctrl-vpnv4-ucast hostleak summary
Step 2 Verify that the config-MO has been successfully processed by BGP, by entering a command such as the
following in the spine-switch CLI:
Example:
spine1# show bgp process vrf apple
Look for output similar to the following:
Information for address family IPv4 Unicast in VRF apple
Table Id : 0
Table state : UP
Table refcount : 3
Peers Active-peers Routes Paths Networks Aggregates
0 0 0 0 0 0
Redistribution
None
Step 3 Verify that the public BD-subnet has been advertised to DCIG as an EVPN type-5 route:
Example:
spine1# show bgp l2vpn evpn 10.6.0.0 vrf overlay-1
Route Distinguisher: 192.41.1.5:4123 (L3VNI 2097154)
BGP routing table entry for [5]:[0]:[0]:[16]:[10.6.0.0]:[0.0.0.0]/224, version 2088
Paths: (1 available, best #1)
Flags: (0x000002 00000000) on xmit-list, is not in rib/evpn
Multipath: eBGP iBGP
Advertised path-id 1
Path type: local 0x4000008c 0x0 ref 1, path is valid, is best path
AS-Path: NONE, path locally originated
192.41.1.1 (metric 0) from 0.0.0.0 (192.41.1.5)
Origin IGP, MED not set, localpref 100, weight 32768
Received label 2097154
Community: 1234:444
Extcommunity:
RT:1234:5101
4BYTEAS-GENERIC:T:1234:444
In the Path type entry, ref 1 indicates that one route was sent.
Step 4 Verify whether the host route advertised to the EVPN peer was an EVPN type-2 MAC-IP route:
Example:
spine1# show bgp l2vpn evpn 10.6.41.1 vrf overlay-1
Route Distinguisher: 10.10.41.2:100 (L2VNI 100)
BGP routing table entry for [2]:[0]:[2097154]:[48]:[0200.0000.0002]:[32]:[10.6.41
.1]/272, version 1146
Shared RD: 192.41.1.5:4123 (L3VNI 2097154)
Paths: (1 available, best #1)
Flags: (0x00010a 00000000) on xmit-list, is not in rib/evpn
Multipath: eBGP iBGP
Advertised path-id 1
Path type: local 0x4000008c 0x0 ref 0, path is valid, is best path
AS-Path: NONE, path locally originated
EVPN network: [5]:[0]:[0]:[16]:[10.6.0.0]:[0.0.0.0] (VRF apple)
10.10.41.2 (metric 0) from 0.0.0.0 (192.41.1.5)
Origin IGP, MED not set, localpref 100, weight 32768
Received label 2097154 2097154
Extcommunity:
RT:1234:16777216
The Shared RD line indicates the RD/VNI shared by the EVPN type-2 route and the BD subnet.
The EVPN Network line shows the EVPN type-5 route of the BD-Subnet.
The Path-id advertised to peers indicates the path advertised to EVPN peers.
Step 5 Verify that the EVPN peer (a DCIG) received the correct type-2 MAC-IP route and the host route was
successfully imported into the given VRF, by entering a command such as the following on the DCIG device
(assuming that the DCIG is a Cisco ASR 9000 switch in the example below):
Example:
RP/0/RSP0/CPU0:asr9k#show bgp vrf apple-2887482362-8-1 10.6.41.1
Tue Sep 6 23:38:50.034 UTC
In this output, the received RD, next hop, and attributes are the same for the type-2 route and the BD subnet.
Multipod_Fabric
About Multipod Fabric
Multipod enables provisioning a more fault tolerant fabric comprised of multiple pods with isolated control
plane protocols. Also, multipod provides more flexibility with regard to the full mesh cabling between leaf
and spine switches. For example, if leaf switches are spread across different floors or different buildings,
multipod enables provisioning multiple pods per floor or building and providing connectivity between pods
through spine switches.
Multipod uses MP-BGP EVPN as the control-plane communication protocol between the ACI spines in
different Pods.
WAN routers can be provisioned in the IPN, directly connected to spine switches or connected to border leaf
switches. Multipod uses a single APIC cluster for all the pods; all the pods act as a single fabric. Individual
APIC controllers are placed across the pods but they are all part of a single APIC cluster.
Procedure
Step 2 [no] system switch-id serial-number switch-id For each switch in the multipod fabric, declare
switch-name [pod pod-id] [role {leaf | spine}] the associated pod and the role (leaf or spine)
of the switch. Repeat this command for each
Example:
leaf and spine switch in the multipod fabric.
apic1(config)# system switch-id
SAL1748H56D 201 ifav4-spine1 pod 1 role
spine
Step 3 [no] system pod pod-id tep-pool Configure a tunnel endpoint IP address pool for
ip-prefix/length a pod. Repeat this command for each pod in the
multipod fabric.
Example:
apic1(config)# system pod 1 tep-pool
10.0.0.0/16
Example
This example shows how to assign spine and leaf switches in a two-pod fabric.
apic1# configure
apic1(config)# system switch-id SAL1748H56D 201 ifav4-spine1 pod 1 role spine
apic1(config)# system switch-id SAL1938P7A6 202 ifav4-spine3 pod 1 role spine
apic1(config)# system switch-id SAL1819RXP4 101 ifav4-leaf1 pod 1 role leaf
apic1(config)# system switch-id SAL1803L25H 102 ifav4-leaf2 pod 1 role leaf
apic1(config)# system switch-id SAL1934MNY0 103 ifav4-leaf3 pod 1 role leaf
apic1(config)# system switch-id SAL1934MNY3 104 ifav4-leaf4 pod 1 role leaf
apic1(config)# system switch-id SAL1931LA3B 203 ifav4-spine2 pod 2 role spine
apic1(config)# system switch-id FGE173400A9 204 ifav4-spine4 pod 2 role spine
apic1(config)# system switch-id SAL1938PHBB 105 ifav4-leaf5 pod 2 role leaf
apic1(config)# system switch-id SAL1942R857 106 ifav4-leaf6 pod 2 role leaf
apic1(config)# system pod 1 tep-pool 10.0.0.0/16
apic1(config)# system pod 2 tep-pool 10.1.0.0/16
What to do next
Configure fabric-external connectivity.
Procedure
Step 3 [no] bgp evpn peering [password Configure BGP EVPN peering profile. You
peering-password] [type can configure a peering password, and you can
{automatic_with_full_mesh | set the type to be either full mesh or with
automatic_with_rr}] route-reflector.
Example:
apic1(config-fabric-external)# bgp evpn
peering
Step 12 [no] route-target extended ASN4:NN Route targets are carried as extended
community attributes. Enter the community
Example:
number in the AA4:NN2 format:
apic1(config-fabric-external)# 1-4294967295: 1-65535.
route-target extended 5:16
Step 13 exit
Example
This example shows how to configure fabric-external connectivity for a multipod fabric.
apic1# configure
apic1(config)# fabric-external 1
apic1(config-fabric-external)# bgp evpn peering
apic1(config-fabric-external)# pod 1
apic1(config-fabric-external-pod)# interpod data hardware-proxy 100.11.1.1/32
apic1(config-fabric-external-pod)# bgp evpn peering
apic1(config-fabric-external-pod)# exit
apic1(config-fabric-external)# pod 2
apic1(config-fabric-external-pod)# interpod data hardware-proxy 200.11.1.1/32
apic1(config-fabric-external-pod)# bgp evpn peering
apic1(config-fabric-external-pod)# exit
apic1(config-fabric-external)# route-map interpod-import
apic1(config-fabric-external-route-map)# ip prefix-list default permit 0.0.0.0/0
apic1(config-fabric-external-route-map)# exit
apic1(config-fabric-external)# route-target extended 5:16
apic1(config-fabric-external)# exit
What to do next
Configure spine interfaces and OSPF.
Procedure
Step 7 [no] vlan-domain member domain-name The VLAN domain must already exist, having
been created using the vlan-domain
Example:
domain-name command in the global
apic1(config-spine)# vlan-domain member configuration mode.
l3Dom
Step 10 [no] vrf member tenant infra vrf vrf-name Configure the interface as a member of the
tenant VRF.
Example:
apic1(config-spine-if)# vrf member
tenant infra vrf overlay-1
Step 18 [no] area area loopback ip-address Advertise the loopback address through OSPF.
This address is used by BGP EVPN sessions
Example:
for peering.
apic1(config-spine-ospf-vrf)# area
0.0.0.0 loopback 201.201.201.201
Example
apic1# configure
The remote leaf switches are added to an existing pod in the fabric. All policies deployed in the main datacenter
are deployed in the remote switches, which behave like local leaf switches belonging to the pod. In this
topology, all unicast traffic is through VXLAN over Layer 3. Layer 2 Broadcast, Unknown Unicast, and
Multicast (BUM) messages are sent using Head End Replication (HER) tunnels without the use of Multicast.
All local traffic on the remote site is switched directly between endpoints, whether physical or virtual. Any
traffic that requires use of the spine switch proxy is forwarded to the main datacenter.
The APIC system discovers the remote leaf switches when they come up. From that time, they can be managed
through APIC, as part of the fabric.
Note • All inter-VRF traffic goes to the spine switch before being forwarded.
• Before decommissioning a remote leaf, you must first delete the vPC.
You can configure Remote Leaf in the APIC GUI, either with and without a wizard, or use the REST API or
the NX-OS style CLI.
Note In Cisco APIC Release 3.2(x), the following features are supported that were not previously:
• FEX devices connected to remote leaf switches
• Cisco AVS with VLAN and Cisco AVS with VXLAN
• Cisco ACI Virtual Edge with VLAN and ACI Virtual Edge with VXLAN
• The Cisco Nexus 9336C-FX2 switch is now supported for remote leaf switches
Stretching of L3out SVI between local leaf switches (ACI main data center switches) and remote leaf switches
is not supported.
The following deployments and configurations are not supported with the remote leaf switch feature:
• APIC controllers directly connected to remote leaf switches
• Orphan port-channel or physical ports on remote leaf switches, with a vPC domain (this restriction applies
for releases 3.1 and earlier)
• With and without service node integration, local traffic forwarding within a remote location is only
supported if the consumer, provider, and services nodes are all connected to Remote Leaf switches are
in vPC mode
Full fabric and tenant policies are supported on remote leaf switches, in this release, except for the following
features:
• ACI Multi-Site
Bandwidth in the WAN must be a minimum of 100 Mbps and maximum supported latency is 300 msecs.
• It is recommended, but not required to connect the pair of remote leaf switches with a vPC. The switches
on both ends of the vPC must be remote leaf switches at the same remote datacenter.
• Configure the northbound interfaces as Layer 3 sub-interfaces on VLAN-4, with unique IP addresses.
If you connect more than one interface from the remote leaf switch to the router, configure each interface
with a unique IP address.
• Enable OSPF on the interfaces, but do not set the OSPF area type as stub area.
• The IP addresses in the remote leaf switch TEP Pool subnet must not overlap with the pod TEP subnet
pool. The subnet used must be /24 or lower.
• Multipod is supported, but not required, with the Remote Leaf feature.
• When connecting a pod in a single-pod fabric with remote leaf switches, configure an L3Out from a
spine switch to the WAN router and an L3Out from a remote leaf switch to the WAN router, both using
VLAN-4 on the switch interfaces.
• When connecting a pod in a multipod fabric with remote leaf switches, configure an L3Out from a spine
switch to the WAN router and an L3Out from a remote leaf switch to the WAN router, both using VLAN-4
on the switch interfaces. Also configure a multipod-internal L3Out using VLAN-5 to support traffic that
crosses pods destined to a remote leaf switch. The regular multipod and multipod-internal connections
can be configured on the same physical interfaces, as long as they use VLAN-4 and VLAN-5.
• When configuring the Multipod-internal L3Out, use the same router ID as for the regular multipod L3Out,
but deselect the Use Router ID as Loopback Address option for the router-id and configure a different
loopback IP address. This enables ECMP to function.
Procedure
Step 4 Configure two L3Outs for the infra tenant, one for the remote leaf connections and one for the multipod IPN.
Example:
Step 5 Configure the spine switch interfaces and sub-interfaces to be used by the L3Outs.
Example:
Step 6 Configure the remote leaf switch interface and sub-interface used for communicating with the main fabric
pod.
Example:
(config)# leaf 101
apic1(config-leaf)# vrf context tenant infra vrf overlay-1 l3out rl-wan-test
apic1(config-leaf-vrf)# exit
apic1(config-leaf)#
apic1(config-leaf)# interface ethernet 1/49
apic1(config-leaf-if)# vlan-domain member ospfDom
apic1(config-leaf-if)# exit
apic1(config-leaf)# router ospf default
apic1(config-leaf-ospf)# vrf member tenant infra vrf overlay-1
apic1(config-leaf-ospf-vrf)# area 5 l3out rl-wan-test
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit
apic1(config-leaf)#
apic1(config-leaf)# interface ethernet 1/49.4
apic1(config-leaf-if)# vrf member tenant infra vrf overlay-1 l3out rl-wan-test
apic1(config-leaf-if)# ip router ospf default area 5
apic1(config-leaf-if)# exit
Example
The following example provides a downloadable configuration:
apic1# configure
apic1(config)# system remote-leaf-site 5 pod 2 tep-pool 192.0.0.0/16
apic1(config)# system switch-id FDO210805SKD 109 ifav4-leaf9 pod 2
remote-leaf-site 5 node-type remote-leaf-wan
apic1(config)# vlan-domain ospfDom
apic1(config-vlan)# vlan 4-5
apic1(config-vlan)# exit
apic1(config)# tenant infra
apic1(config-tenant)# l3out rl-wan-test
apic1(config-tenant-l3out)# vrf member overlay-1
apic1(config-tenant-l3out)# exit
apic1(config-tenant)# l3out ipn-multipodInternal
apic1(config-tenant-l3out)# vrf member overlay-1
apic1(config-tenant-l3out)# exit
apic1(config-tenant)# exit
apic1(config)#
apic1(config)# spine 201
Transit Routing
Transit Routing in the ACI Fabric
The Cisco APIC software supports external Layer 3 connectivity with OSPF (NSSA) and iBGP. The fabric
advertises the tenant bridge domain subnets out to the external routers on the External Layer 3 Outside (L3Out)
connections. The routes that are learned from the external routers are not advertised to other external routers.
The fabric behaves like a stub network that can be used to carry the traffic between the external Layer 3
domains.
In transit routing, multiple L3Out connections within a single tenant and VRF are supported and the APIC
advertises the routes that are learned from one L3Out connection to another L3Out connection. The external
Layer 3 domains peer with the fabric on the border leaf switches. The fabric is a transit Multiprotocol-Border
Gateway Protocol (MP-BGP) domain between the peers.
The configuration for external L3Out connections is done at the tenant and VRF level. The routes that are
learned from the external peers are imported into MP-BGP at the ingress leaf per VRF. The prefixes that are
learned from the L3Out connections are exported to the leaf switches only where the tenant VRF is present.
Note For cautions and guidelines for configuring transit routing, see Guidelines for Transit Routing, on page 328
Figure 26:
In the examples in this chapter, the Cisco ACI fabric has 2 leaf switches and two spine switches, that are
controlled by an APIC cluster. The border leaf switches 101 and 102 have L3Outs on them providing
connections to two routers and thus to the Internet. The goal of this example is to enable traffic to flow from
EP 1 to EP 2 on the Internet into and out of the fabric through the two L3Outs.
In this example, the tenant that is associated with both L3Outs is t1, with VRF v1.
Before configuring the L3Outs, configure the nodes, ports, functional profiles, AEPs, and a Layer 3 domain.
You must also configure the spine switches 104 and 105 as BGP route reflectors.
Configuring transit routing includes defining the following components:
1. Tenant and VRF
2. Node and interface on leaf 101 and leaf 102
3. Primary routing protocol on each L3Out (used to exchange routes between border leaf switch and external
routers; in this example, BGP)
4. Connectivity routing protocol on each L3Out (provides reachability information for the primary protocol;
in this example, OSPF)
5. Two external EPGs
6. One route map
7. At least one filter and one contract
8. Associate the contract with the external EPGs
Note For transit routing cautions and guidelines, see Guidelines for Transit Routing, on page 328.
The following table lists the names that are used in the examples in this chapter:
Property Names for L3Out1 on Node 101 Names for L3Out2 on Node 102
Tenant t1 t1
VRF v1 v1
Route map rp1 with ctx1 and route destination rp2 with ctx2 and route destination
192.168.1.0/24 192.168.2.0/24
Transit Routing with a Single L3Out Before APIC, release 2.3(1f), transit routing was not supported
Profile within a single L3Out profile. In APIC, release 2.3(1f) and later,
you can configure transit routing with a single L3Out profile, with
the following limitations:
• If the VRF is unenforced, an external subnet (l3extSubnet)
of 0.0.0.0/0 can be used to allow traffic between the routers
sharing the same L3EPG.
• If the VRF is enforced, an external default subnet (0.0.0.0/0)
cannot be used to match both source and destination prefixes
for traffic within the same Layer 3 EPG. To match all traffic
within the same Layer 3 EPG, the following prefixes are
supported:
• IPv4
• 0.0.0.0/1—with External Subnets for the External
EPG
• 128.0.0.0/1—with External Subnets for the
External EPG
• 0.0.0.0/0—with Import Route Control Subnet,
Aggregate Import
• IPv6
• 0::0/1—with External Subnets for the External
EPG
• 8000::0/1—with External Subnets for the External
EPG
• 0:0/0—with Import Route Control Subnet,
Aggregate Import
Shared Routes: Differences in Hardware Routes shared between VRFs function correctly on Generation 2
Support switches (Cisco Nexus N9K switches with "EX" or "FX" on the
end of the switch model name, or later; for example,
N9K-93108TC-EX). On Generation 1 switches, however, there
may be dropped packets with this configuration, because the
physical ternary content-addressable memory (TCAM) tables that
store routes do not have enough capacity to fully support route
parsing.
OSPF or EIGRP in Back to Back Cisco APIC supports transit routing in export route control policies
Configuration that are configured on the L3Out. These policies control which
transit routes (prefixes) are redistributed into the routing protocols
in the L3Out. When these transit routes are redistributed into
OSPF or EIGRP, they are tagged 4294967295 to prevent routing
loops. The Cisco ACI fabric does not accept routes matching this
tag when learned on an OSPF or EIGRP L3Out. However, in the
following cases, it is necessary to override this behavior:
• When connecting two Cisco ACI fabrics using OSPF or
EIGRP.
• When connecting two different VRFs in the same Cisco ACI
fabric using OSPF or EIGRP.
Advertising BD Subnets Outside the The import and export route control policies only apply to the
Fabric transit routes (the routes that are learned from other external peers)
and the static routes. The subnets internal to the fabric that are
configured on the tenant BD subnets are not advertised out using
the export policy subnets. The tenant subnets are still permitted
using the IP prefix-lists and the route-maps but they are
implemented using different configuration steps. See the following
configuration steps to advertise the tenant subnets outside the
fabric:
1. Configure the tenant subnet scope as Public Subnet in the
subnet properties window.
2. Optional. Set the Subnet Control as ND RA Prefix in the
subnet properties window.
3. Associate the tenant bridge domain (BD) with the external
Layer 3 Outside (L3Out).
4. Create contract (provider or consumer) association between
the tenant EPG and the external EPG.
Setting the BD subnet to Public scope and associating the BD
to the L3Out creates an IP prefix-list and the route-map
sequence entry on the border leaf for the BD subnet prefix.
Advertising a Default Route For external connections to the fabric that only require a default
route, there is support for originating a default route for OSPF,
EIGRP, and BGP L3Out connections. If a default route is received
from an external peer, this route can be redistributed out to another
peer following the transit export route control as described earlier
in this article.
A default route can also be advertised out using a Default Route
Leak policy. This policy supports advertising a default route if it
is present in the routing table or it always supports advertising a
default route. The Default Route Leak policy is configured in the
L3Out connection.
When creating a Default Route Leak policy, follow these
guidelines:
• For BGP, the Always property is not applicable.
• For BGP, when configuring the Scope property, choose
Outside.
• For OSPF, the scope value Context creates a type-5 LSA
while the Scope value Outside creates type-7 LSA. Your
choice depends on the area type configured in the L3Out. If
the area type is Regular, set the scope to Context. If the area
type is NSSA, set the scope to Outside.
• For EIGRP, when choosing the Scope property, you must
choose Context.
For an example of the commands for these prerequisites, see NX-OS Style CLI Example: L3Out Prerequisites,
on page 173.
Procedure
• The second L3Out is on node 102, which is named nodep2. Node 102 is configured with router ID
22.22.22.203. It has a routed interface ifp2 at eth1/3, with the IP address, 23.23.23.1/24.
Example:
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# router-id 11.11.11.103
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# interface ethernet 1/3
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant t1 vrf v1
apic1(config-leaf-if)# ip address 12.12.12.3/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config)# leaf 102
apic1(config-leaf)# vrf context tenant t1 vrf v1
apic1(config-leaf-vrf)# router-id 22.22.22.203
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# interface ethernet 1/3
apic1(config-leaf-if)# vlan-domain member dom1
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant t1 vrf v1
apic1(config-leaf-if)# ip address 23.23.23.3/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
apic1(config-leaf-vrf)# exit
apic1(config-leaf)# router bgp 100
apic1(config-leaf-bgp)# vrf member tenant t1 vrf v1
apic1(config-leaf-bgp-vrf)# neighbor 25.25.25.2
apic1(config-leaf-bgp-vrf-neighbor)# route-map rp2 in
apic1(config-leaf-bgp-vrf-neighbor)# route-map rp1 out
apic1(config-leaf-bgp-vrf-neighbor)# exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf-bgp)# exit
apic1(config-leaf)# exit
Step 7 Create filters (access lists) and contracts to enable the EPGs to communicate.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# access-list http-filter
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# exit
apic1(config-tenant)# contract httpCtrct
apic1(config-tenant-contract)# scope vrf
apic1(config-tenant-contract)# subject subj1
apic1(config-tenant-contract-subj)# access-group http-filter both
apic1(config-tenant-contract-subj)# exit
apic1(config-tenant-contract)# exit
apic1(config-tenant)# exit
apic1(config-leaf-if)# no switchport
apic1(config-leaf-if)# vrf member tenant t1 vrf v1
apic1(config-leaf-if)# ip address 12.12.12.3/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# router bgp 100
apic1(config-leaf-bgp)# vrf member tenant t1 vrf v1
apic1(config-leaf-bgp-vrf)# neighbor 15.15.15.2
apic1(config-leaf-bgp-vrf-neighbor)# exit
apic1(config-leaf-bgp-vrf)# exit
apic1(config-leaf-bgp)# exit
apic1(config-leaf)# router ospf default
apic1(config-leaf-ospf)# vrf member tenant t1 vrf v1
apic1(config-leaf-ospf-vrf)# area 0.0.0.0 loopback 40.40.40.1
apic1(config-leaf-ospf-vrf)# exit
apic1(config-leaf-ospf)# exit
apic1(config-leaf)# exit
apic1(config)# tenant t1
apic1(config-tenant)# external-l3 epg extnw1
apic1(config-tenant-l3ext-epg)# vrf member v1
apic1(config-tenant-l3ext-epg)# match ip 192.168.1.0/24
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# external-l3 epg extnw2
apic1(config-tenant-l3ext-epg)# vrf member v1
apic1(config-tenant-l3ext-epg)# match ip 192.168.2.0/24
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# exit
apic1(config)# tenant t1
apic1(config-tenant)# access-list http-filter
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# exit
apic1(config-tenant)# contract httpCtrct
apic1(config-tenant-contract)# scope vrf
apic1(config-tenant-contract)# subject http-subj
apic1(config-tenant-contract-subj)# access-group http-filter both
apic1(config-tenant-contract-subj)# exit
apic1(config-tenant-contract)# exit
apic1(config-tenant)# exit
apic1(config)# tenant t1
apic1(config-tenant)# external-l3 epg extnw1
apic1(config-tenant-l3ext-epg)# vrf member v1
apic1(config-tenant-l3ext-epg)# contract provider httpCtrct
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# external-l3 epg extnw2
apic1(config-tenant-l3ext-epg)# vrf member v1
apic1(config-tenant-l3ext-epg)# contract consumer httpCtrct
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# exit
apic1(config)#
Note Only configure a QoS class or target DSCP in the contract, not in the external
EPG (l3extInstP).
• When creating a contract subject, you must choose a QoS priority level. You cannot choose Unspecified.
Procedure
Step 1 When configuring the tenant and VRF, to support QoS priority enforcement on the L3Out, configure the VRF
for egress mode and enable policy enforcement, using the following commands:
Example:
apic1# configure
apic1(config)# tenant t1
apic1(config-tenant)# vrf context v1
apic1(config-tenant-vrf)# contract enforce egress
apic1(config-tenant-vrf)# exit
apic1(congig-tenant)# exit
apic1(config)#
Step 2 When creating filters (access-lists), include the match dscp command, in this example with target DSCP
level EF. When configuring contracts, include the QoS class, for example, level1, for traffic ingressing on the
L3Out. Alternatively, it could define a target DSCP value. QoS policies are supported on either the contract
or the subject.
Example:
apic1(config)# tenant t1
apic1(config-tenant)# access-list http-filter
apic1(config-tenant-acl)# match ip
apic1(config-tenant-acl)# match tcp dest 80
apic1(config-tenant-acl)# match dscp EF
apic1(config-tenant-acl)# exit
apic1(config-tenant)# contract httpCtrct
apic1(config-tenant-contract)# scope vrf
apic1(config-tenant-contract)# qos-class level1
apic1(config-tenant-contract)# subject http-subject
apic1(config-tenant-contract-subj)# access-group http-filter both
apic1(config-tenant-contract-subj)# exit
apic1(config-tenant-contract)# exit
apic1(config-tenant)# exit
apic1(config)#
Procedure
CoS Preservation
Preserving 802.1P Class of Service Settings
APIC enables preserving 802.1P class of service (CoS) settings within the fabric. Enable the fabric global
QoS policy dot1p-preserve option to guarantee that the CoS value in packets which enter and transit the
ACI fabric is preserved.
802.1P CoS preservation is supported in single pod and multipod topologies.
In multipod topologies, CoS Preservation can be used where you want to preserve the QoS priority settings
of 802.1P traffic entering POD 1 and egressing out of POD 2, but you are not concerned with preserving the
CoS/DSCP settings in interpod network (IPN) traffic between the pods. To preserve CoS/DSCP settings when
multipod traffic is transitting an IPN, use a DSCP policy. For more information, see Preserving QoS Priority
Settings in a Multipod Fabric, on page 346.
Observe the following 801.1P CoS preservation guidelines and limitations:
• The current release can only preserve the 802.1P value within a VLAN header. The DEI bit is not
preserved.
• For VXLAN encapsulated packets, the current release will not preserve the 802.1P CoS value contained
in the outer header.
• 802.1P is not preserved when the following configuration options are enabled:
• Multipod QoS (using a DSCP policy) is enabled.
• Contracts are configured that include QoS.
• Dynamic packet prioritization is enabled.
Note When specifying vzAny for a contract, external EPG DSCP values are not honored
because vzAny is a collection of all EPGs in a VRF, and EPG specific
configuration cannot be applied. If EPG specific target DSCP values are required,
then the external EPG should not use vzAny.
Note Enabling CoS preservation applies a default CoS-to-DSCP mapping to the various traffic types.
Procedure
apic1# configure
Multipod QoS
Creating DSCP Translation Policy Using NX-OS Style CLI
This section describes how to create a DSCP translation policy to guarantee QoS Level settings across multiple
PODs connected by an IPN.
Procedure
apic1# configure
Example:
apic1(config-qos-cmap# set dscp-code control CS3
apic1(config-qos-cmap# set dscp-code span CS5
apic1(config-qos-cmap# set dscp-code level1 CS0
apic1(config-qos-cmap# set dscp-code level2 CS1
apic1(config-qos-cmap# set dscp-code level3 CS2
apic1(config-qos-cmap# set dscp-code level4 CS3
apic1(config-qos-cmap# set dscp-code level5 CS4
apic1(config-qos-cmap# set dscp-code level6 CS5
apic1(config-qos-cmap# set dscp-code policy CS4
apic1(config-qos-cmap# set dscp-code traceroute CS5
apic1(config-qos-cmap)# no shutdown
Note You can alternatively use CoS Preservation where you want to preserve the QoS priority settings of 802.1P
traffic entering POD 1 and egressing out of POD 2, but you are not concerned with preserving the CoS/DSCP
settings in interpod network (IPN) traffic between the pods. For more information, see Preserving 802.1P
Class of Service Settings, on page 343.
As illustrated in this figure, traffic between pods in a multipod topology passes through an IPN, which may
not be under APIC management. When an 802.1P frame is sent from a spine or leaf switch in POD 1, the
devices in the IPN may not preserve the CoS setting in 802.1P frames. In this situation, when the frame reaches
a POD 2 spine or leaf switch, it has the CoS level assigned by the IPN device, instead of the level assigned
at the source in POD 1. Use a DSCP policy to ensure that the QoS priority levels are preserved in this case.
Configure a DSCP policy to preserve the QoS priority settings in a multipod topology, where there is a need
to do deterministic mapping from CoS to DSCP levels for different traffic types, and you want to prevent the
devices in the IPN from changing the configured levels. With a DSCP policy enabled, APIC converts the CoS
level to a DSCP level, according to the mapping you configure. When a frame is sent from POD 1 (with the
PCP level mapped to a DSCP level), when it reaches POD 2, the mapped DSCP level is then mapped back
to the original PCP CoS level.
802.1P CoS translation is not supported when the following configuration options are enabled:
• Contracts are configured that include QoS.
• The outgoing interface is on a FEX.
• Multipod QoS using a DSCP policy is enabled.
• Dynamic packet prioritization is enabled.
• If an EPG is configured with intra-EPG endpoint isolation enforced.
• If an EPG is configured with allow-microsegmentation enabled.
Procedure
Example:
apic1(config)# tenant <tenant-name>
Procedure
Step 5 exit
Example:
apic1(config-controller-if)# exit
Step 6 exit
Example:
apic1(config-controller)# exit
Step 8 external-l3 epg default oob-mgmt Enters the configuration mode of the
out-of-band management EPG.
Example:
apic1(config-tenant)# external-l3 epg
default oob-mgmt
Step 10 exit
Example:
apic1(config-tenant-l3ext-epg)# exit
Step 11 access-list oob-default Configures the access list filter for the OOB
default policy.
Example:
apic1(config-tenant)# access-list
oob-default
Step 12 match tcp dest 443 Allows access on the management interface
for HTTPS traffic (TCP/443).
Example:
Examples
This example shows how to configure out-of-band management access for three APIC controllers.
In this example, the three controllers are assigned sequential IP addresses, with controller 1 at
172.23.48.16/21, controller 2 at 172.23.48.17/21, and controller 3 at 172.23.48.18/21.
apic1# configure
apic1(config)# controller 1-3
apic1(config-controller)# interface mgmt0
apic1(config-controller-if)# ip address-range 172.23.48.16/21 gateway 172.23.48.1
apic1(config-controller-if)# exit
apic1(config-controller)# exit
apic1(config)# tenant mgmt
apic1(config-tenant)# external-l3 epg default oob-mgmt
apic1(config-tenant-l3ext-epg)# match ip 192.0.20.0/24
apic1(config-tenant-l3ext-epg)# exit
apic1(config-tenant)# access-list oob-default
apic1(config-tenant-acl)# match tcp dest 443
apic1(config-tenant-acl)# match tcp dest 22
This example shows how to configure out-of-band management access for a leaf or spine switch.
apic1# configure
apic1(config)# switch 101
apic1(config-switch)# interface mgmt0
apic1(config-switch-if)# ip address 172.23.48.101/21 gateway 172.23.48.1
Procedure
Step 4 ip address addr/mask gateway addr Configures the IP address and gateway for
inband management. If you specified more than
Example:
one switch, the command becomes ip
apic1(config-switch-if)# ip address address-range and IP addresses are assigned
10.13.1.1/24 gateway 10.13.1.254
sequentially beginning with the address
specified in this command.
Step 5 exit
Example:
apic1(config-switch-if)# exit
Step 6 exit
Example:
apic1(config-switch)# exit
Examples
This example shows how to configure inband management for a switch from a management station
on an external network..
apic1# configure
apic1(config)# switch 101
apic1(config-switch)# interface inband-mgmt0
apic1(config-switch-if)# ip address 10.13.1.1/24 gateway 10.13.1.254
apic1(config-switch-if)# exit
apic1(config-switch)# exit
What to do next
• Configure inband (IB) management connectivity to the management station.
• Allow the necessary protocols (HTTPS and SSH) on the inbound management port.
Procedure
Step 4 ip address addr/mask gateway addr Configures the IP address and gateway for
inband management. If you specified more
Example:
than one controller or switch, the command
apic1(config-controller-if)# ip becomes ip address-range and IP addresses
address-range 10.13.1.1/24 gateway
10.13.1.254
are assigned sequentially beginning with the
address specified in this command.
Step 6 exit
Example:
apic1(config-controller-if)# exit
Step 7 exit
Example:
apic1(config-controller)# exit
Step 11 leaf node-id Specifies the leaf switch to which the controller
connected.
Example:
apic1(config)# leaf 102
Step 14 exit
Example:
apic1(config-leaf-if)# exit
Step 15 exit
Example:
apic1(config-leaf)# exit
Examples
This example shows how to configure inband management for a controller from a management
station on an external network. APIC controller 1 is connected to port Ethernet 1/1 on Leaf 101, and
VLAN 10 is used for the controller's inband connectivity.
apic1# configure
apic1(config)# controller 1-3
apic1(config-controller)# interface inband-mgmt0
apic1(config-controller-if)# ip address-range 10.13.1.1/24 gateway 10.13.1.254
apic1(config-controller-if)# vlan 10
apic1(config-controller-if)# exit
apic1(config-controller)# exit
What to do next
• Configure inband (IB) management connectivity to the management station.
• Allow the necessary protocols (HTTPS and SSH) on the inbound management port.
Procedure
Step 2 vlan-domain domain-name Creates and enters the configuration mode for
the VLAN domain.
Example:
apic1(config)# vlan-domain
external-inband
Step 8 switchport trunk allowed vlan vlan-id Configures external layer2 connectivity to
inband-mgmt gateway-ip/mask inband management. The specified IP address
is the gateway address used by the external
Example:
management station and the gateway
apic1(config-leaf-if)# switchport trunk functionality is provided by the ACI fabric.
allowed vlan 11 inband-mgmt
179.10.1.254/24
Step 9 exit
Example:
apic1(config-leaf-if)# exit
Step 10 exit
Example:
apic1(config-leaf)# exit
Examples
This example shows how to configure inband management connectivity to the management station.
# CONFIGURE LAYER 2 CONNECTIVITY FROM THE MANAGEMENT STATION INTERFACE TO INBAND MANAGEMENT
apic1(config)# leaf 102
apic1(config-leaf)# interface eth 1/2
apic1(config-leaf-if)# vlan-domain member external-inband
apic1(config-leaf-if)# switchport trunk allowed vlan 11 inband-mgmt 179.10.1.254/24
apic1(config-leaf-if)# exit
apic1(config-leaf)# exit
What to do next
• Allow the necessary protocols (HTTPS and SSH) on the inbound management port.
Step 3 access-list inband-default Configures the access list filter for the inband
default policy.
Example:
apic1(config-tenant)# access-list
inband-default
Step 4 match tcp dest 443 Allows access on the management interface for
HTTPS traffic (TCP/443).
Example:
apic1(config-tenant-acl)# match tcp dest
443
Step 5 match tcp dest 22 Allows access on the management interface for
SSH traffic (TCP/22).
Example:
apic1(config-tenant-acl)# match tcp dest
22
Examples
This example shows how to allow HTTPS and SSH access to the inband management port.
apic1# configure
apic1(config)# tenant mgmt
apic1(config-tenant)# access-list inband-default
apic1(config-tenant-acl)# match tcp dest 443
apic1(config-tenant-acl)# match tcp dest 22
apic1(config-tenant-acl)# exit
apic1(config-tenant)# exit
apic1# configure
apic1(config)# aaa authentication login default
apic1(config-default)# realm local
For information about adding users into the local username database, refer to the section “Configuring a
Locally Authenticated User.”
apic1# configure
apic1(config)# aaa authentication login default
apic1(config-default)# realm radius
Before you can use RADIUS as the login authentication method, you need to enable communication with the
RADIUS security server, same is true for TACACS+ or LDAP. For more information about establishing
communication with a remote security server, see the appropriate chapter:
• "Configuring a RADIUS Server"
• "Configuring a TACACS+ Server"
• "Configuring an LDAP Server"
Configuring AAA
Procedure
Step 2 aaa authentication login console Enters console configuration mode for users
accessing APIC through the console.
Example:
apic1(config)# aaa authentication login
console
Step 6 aaa authentication login default Enters the configuration mode for default login
authentication.
Example:
apic1(config)# aaa authentication login
default
Step 7 [no] realm {ldap | local | radius | tacacs} Specifies the authentication method.
Example:
apic1(config-default)# realm radius
Step 10 aaa authentication login domain Enters the configuration mode for default login
{domain-name | fallback} authentication. A login domain specifies the
authentication domain for a user.
Example:
apic1(config)# aaa authentication login
domain cisco
Step 11 [no] realm {ldap | local | none | radius | Specifies the authentication method.
tacacs}
Example:
apic1(config-domain)# realm radius
Step 15 aaa group {ldap | radius | tacacs} Creates or configures an authentication server
group-name group.
Example:
apic1(config)# aaa group radius
radiusGroup
Step 16 [no] server {ip-address | hostname} priority Adds a server to the authentication server
priority-number group and specifies its priority within the
server group. The priority can be between 0
Example:
and 17.
apic1(config-radius)# server 192.0.20.71
priority 2
Step 18 aaa scvmm-certificate certificate-name Specifies an SCVMM certificate. See the Cisco
ACI Virtualization Guide.
Example:
apic1(config)# aaa scvmm-certificate
myScvmmCert
Step 19 aaa user default-role {assign-default-role | Specifies how to respond when remote users
no-login} who do not have a user role attempt to log in
to APIC. The action can be either of these
Example:
options:
apic1(config)# aaa user default-role
assign-default-role • assign-default-role —Remote users who
do not have a user role are assigned a
default role.
• no-login —Remote users who do not
have a user role cannot log in.
Examples
This example shows how to configure AAA.
RadiusGroups : radiusGroup5
TacacsGroups :
LdapGroups :
Step 3 [no] radius-server timeout seconds Specifies the number of seconds APIC waits
for a reply to a RADIUS request before
Example:
retransmitting the request.
apic1(config)# radius-server timeout 5
In the global configuration mode, this
command applies to all RADIUS servers
unless overridden in the specific RADIUS host
configuration.
Step 4 [no] radius-server host {ip-address | Specifies the IP address or hostname of the
hostname} RADIUS server.
Example:
apic1(config)# radius-server host
192.0.20.71
Step 5 (Optional) [no] retries count For this RADIUS server, specifies how many
times APIC transmits each RADIUS request
Example:
to the server before giving up. The range is 0
apic1(config-host)# retries 2 to 5.
If no retry count is set, the global value is used.
Step 6 (Optional) [no] timeout seconds For this RADIUS server, specifies the number
of seconds APIC waits for a reply to a
Example:
RADIUS request before retransmitting the
apic1(config-host)# timeout 3 request.
If no timeout is set, the global value is used.
Step 7 (Optional) [no] descr text Provides descriptive information about this
RADIUS server. The text can be up to 128
Example:
alphanumeric characters. If the text contains
apic1(config-host)# descr "My primary spaces, it must be enclosed by single or double
RADIUS server"
quotes.
Step 8 [no] key key-value Specifies the shared secret text string used
between APIC and this RADIUS server for
Example:
authentication. The key can be up to 32
apic1(config-host)# key myRaDiUSpassWoRd characters.
Step 9 [no] port port-number Specifies a UDP port on this RADIUS server
to be used solely for authentication.
Example:
Step 10 [no] protocol {chap | mschap | pap} Specifies the RADIUS server protocol for
authentication.
Example:
apic1(config-host)# protocol pap
Examples
This example shows how to configure RADIUS settings globally and on one RADIUS server.
apic1# configure
apic1(config)# radius-server retries 1
apic1(config)# radius-server timeout 5
apic1(config)# radius-server host 192.0.20.71
apic1(config-host)# retries 2
apic1(config-host)# timeout 3
apic1(config-host)# descr "My primary RADIUS server"
apic1(config-host)# key myRaDiUSpassWoRd
apic1(config-host)# port 1812
apic1(config-host)# protocol pap
apic1(config-host)# exit
apic1(config)# show radius-server
timeout : 5
retries : 1
Hostname : 192.0.20.71
Port : 1812
Protocol : pap
Timeout : 3
Retries : 2
User : test
Descr : My primary RADIUS server
Step 2 [no] tacacs-server retries count Specifies how many times APIC transmits each
TACACS+ request to the server before giving
Example:
up. The range is 0 to 5.
apic1(config)# tacacs-server retries 1
In the global configuration mode, this
command applies to all TACACS+ servers
unless overridden in the specific TACACS+
host configuration.
Step 3 [no] tacacs-server timeout seconds Specifies the number of seconds APIC waits
for a reply to a TACACS+ request before
Example:
retransmitting the request.
apic1(config)# tacacs-server timeout 5
In the global configuration mode, this
command applies to all TACACS+ servers
unless overridden in the specific TACACS+
host configuration.
Step 4 [no] tacacs-server host {ip-address | Specifies the IP address or hostname of the
hostname} TACACS+ server.
Example:
apic1(config)# tacacs-server host
192.0.20.71
Step 5 (Optional) [no] retries count For this TACACS+ server, specifies how many
times APIC transmits each TACACS+ request
Example:
to the server before giving up. The range is 0
apic1(config-host)# retries 2 to 5.
If no retry count is set, the global value is used.
Step 6 [no] key Specifies the shared secret text string used
between APIC and this TACACS+ server for
Example:
authentication. The key can be up to 32
apic1(config-host)# key characters. For increased security, entering the
Enter key: myTacAcSpassWoRd
Enter key again: myTacAcSpassWoRd key value is interactive.
Step 7 [no] port port-number Specifies a UDP port on this TACACS+ server
to be used for TACACS+ accounting
Example:
messages.
apic1(config-host)# port 49
Examples
This example shows how to configure TACACS+ settings globally and on one TACACS+ server.
apic1# configure
apic1(config)# tacacs-server retries 1
apic1(config)# tacacs-server timeout 5
apic1(config)# tacacs-server host 192.0.20.72
apic1(config-host)# retries 2
apic1(config-host)# timeout 3
apic1(config-host)# key myTaCaCspassWoRd
apic1(config-host)# port 49
apic1(config-host)# protocol pap
apic1(config-host)# exit
apic1(config)# show tacacs-server
timeout : 5
retries : 1
Hostname : 192.0.20.72
Port : 1812
Protocol : pap
Timeout : 3
Retries : 2
User : test
Procedure
Step 2 [no] ldap-server host {ip-address | hostname} Specifies the IP address or hostname of the
LDAP server and enters the configuration
Example:
mode of that server.
apic1(config)# ldap-server host
192.0.20.73
Step 4 [no] ldap-server basedn Specifies the location in the LDAP hierarchy
where the server should begin searching when
Example:
it receives an authorization request. This can
apic1(config-host)# ldap-server basedn be a string of up to 127 characters. Spaces are
DC=sampledesign,DC=com
not permitted in the string, but other special
characters are allowed.
In the global configuration mode, this
command applies to all LDAP servers unless
overridden in the specific LDAP host
configuration.
Step 5 [no] ldap-server binddn Specifies the distinguished name (DN) for an
LDAP database account that has read and
Example:
search permissions for all objects under the
apic1(config-host)# ldap-server binddn base DN. This can be a string of up to 127
CN=ucsbind,OU=CiscoUsers,DC=sampledesign,DC=com
characters. Spaces are not permitted in the
string, but other special characters are allowed.
Step 6 [no] ldap-server retries count Specifies how many times APIC transmits each
LDAP request to the server before giving up.
Example:
The range is 0 to 5.
apic1(config-host)# ldap-server retries
1 In the global configuration mode, this
command applies to all LDAP servers unless
overridden in the specific LDAP host
configuration.
Step 7 [no] ldap-server timeout seconds Specifies the number of seconds APIC waits
for a reply to a LDAP request before
Example:
retransmitting the request.
apic1(config-host)# ldap-server timeout
30
Step 8 [no] ldap-server filter filter-expression Specifies a filter to filter the results of LDAP
searches. The filter can contain a maximum of
Example:
63 characters.
apic1(config-host)# ldap-server filter
sAMAccountName=$userid In the global configuration mode, this
command applies to all LDAP servers unless
overridden in the specific LDAP host
configuration.
Step 9 [no] key key-value Specifies the shared secret text string used
between APIC and this LDAP server for
Example:
authentication. The key can be up to 32
apic1(config-host)# key characters.
Enter key: myLdAppassWoRd
Enter key again: myLdAppassWoRd
Step 10 [no] port port-number Specifies the LDAP server port for
authentication.
Example:
apic1(config-host)# port 389
Step 11 (Optional) [no] retries count For this LDAP server, specifies how many
times APIC transmits each LDAP request to
Example:
the server before giving up. The range is 0 to
apic1(config-host)# retries 2 5.
If no retry count is set, the global value is used.
Step 13 [no] ssl-validation-level [permissive | strict] Sets the LDAP Server SSL Certificate
validation level.
Example:
apic1(config-host)# ssl-validation-level
permissive
Step 14 (Optional) [no] timeout seconds For this LDAP server, specifies the number of
seconds APIC waits for a reply to a LDAP
Example:
request before retransmitting the request.
apic1(config-host)# timeout 3
If no timeout is set, the global value is used.
Examples
This example shows how to configure LDAP server settings globally and on one LDAP server.
apic1# configure
apic1(config)# ldap-server retries 1
apic1(config)# ldap-server timeout 30
apic1(config)# ldap-server host 192.0.20.73
apic1(config-host)# retries 2
apic1(config-host)# timeout 3
apic1(config-host)# filter sAMAccountName=$userid
apic1(config-host)# key myLdAppassWoRd
apic1(config-host)# ssl-validation-level permissive
apic1(config-host)# enable-ssl
apic1(config-host)# port 389
apic1(config-host)# exit
apic1(config)# show ldap-server
timeout : 30
retries : 1
filter : sAMAccountName=$userid
Hostname : 192.0.20.73
Port : 389
Timeout : 3
Retries : 2
SSL : yes
SSL Level : permissive
User : test
Procedure
Step 5 [no] password no-change-interval hours Sets a minimum period before which a user
cannot change the password again. The range
Example:
is 1 to 745 hours.
apic1(config)# password
no-change-interval 60
Step 7 [no] password history-count count The password history count allows you to
prevent locally authenticated users from reusing
Example:
the same password over and over again. When
apic1(config)# password history-count 10 this property is configured, APIC stores
passwords that were previously used by locally
authenticated users up to a maximum of 15
passwords. The passwords are stored in reverse
chronological order with the most recent
password first to ensure that the only the oldest
password can be reused when the history count
threshold is reached.
A user must create and use the number of
passwords configured in the password history
count before being able to reuse one. For
example, if you set the password history count
to 8, a locally authenticated user cannot reuse
the first password until after the ninth password
has expired.
By default, the password history is set to 0. This
value disables the history count and allows users
to reuse previous passwords at any time. If
Step 8 [no] password pwd-strength-check Enforces strong passwords for all users.
Example:
apic1(config)# password
pwd-strength-check
Examples
This example shows how to configure global password settings for locally authenticated users.
apic1# configure
apic1(config)# password change-count 5
apic1(config)# password change-during-interval enable
apic1(config)# password change-interval 300
apic1(config)# password no-change-interval 60
apic1(config)# password expiration-warn-time 5
apic1(config)# password history-count 10
apic1(config)# password pwd-strength-check
This example shows how to prevent the password from being changed within 48 hours after a locally
authenticated user changes his or her password.
apic1# configure
apic1(config)# password change-during-interval disable
apic1(config)# password no-change-interval 48
This example shows how to allow the password to be changed a maximum of once within 24 hours
after a locally authenticated user changes his or her password
apic1# configure
apic1(config)# password change-count 1
apic1(config)# password change-during-interval enable
apic1(config)# password change-interval 24
Configuring Users
Configuring a Locally Authenticated User
Procedure
Step 3 [no] first-name first Sets the first name of this user.
Example:
apic1(config-username)# first-name
George
Step 4 [no] last-name last Sets the last name of this user.
Example:
apic1(config-username)# last-name
Washington
Step 5 [no] email email-address Sets the email address of this user.
Example:
apic1(config-username)# email
[email protected]
Step 6 [no] phone phone-number Sets the phone number of this user.
Example:
apic1(config-username)# phone
14085551212
Step 7 [no] account-status {active | inactive | Activates or deactivates this user account.
status}
Example:
apic1(config-username)# account-status
active
Step 10 expiration date-time Sets an expiration date and time for this user
account. The format is UTC Date format
Example:
(YYYY-MM-DDThh:mmTZD). You must
apic1(config-username)# expiration also enable expiration by configuring the
2017-12-31T23:59+08:00
expires command.
Step 12 [no] pwd-lifetime days Sets the lifetime of the user password. The
range is 0 to 3650 days.
Example:
apic1(config-username)# pwd-lifetime 90
Step 13 [no] domain {all | common | mgmt | Specifies or creates the AAA domain to which
domain-name} this user belongs.
Example:
apic1(config-username)# domain
mySecDomain
Step 14 [no] role role Creates the AAA domain role to set privilege
bitmask of a user domain.
Example:
apic1(config-domain)# role tenant-admin
Step 15 [no] priv-type {readPriv | writePriv} Creates the AAA domain role to set privilege
bitmask of a user domain.
Example:
apic1(config-role)# priv-type writePriv
Step 18 show username name Displays configuration details about this user.
Example:
apic1(config-username)# show username
user5
Examples
This example shows how to configure a local user.
What to do next
To configure an SSH key or certificate for the local user, see "Configuring Certificates and SSH-Keys."
Procedure
Step 6 [no] ssh-key ssh-key-name Sets an SSH key to log in using the SSH client
without being prompted for a password.
Example:
apic1(config-username)# ssh-key mySSHkey
Step 7 data key-data Sets the SSH key. The key can be up to 64
characters.
Example:
apic1(config-ssh-key)# data
AAAAB3NzaC1yc2EAA......
Examples
This example shows how to configure an SSH key and a certificate for a local user.
apic1(config-certificate)# exit
apic1(config-username)# ssh-key mySSHkey
apic1(config-ssh-key)# data AAAAB3NzaC1yc2EAA...
apic1(config-ssh-key)# exit
Procedure
Step 2 [no] crypto ca trustpoint-name Enters configuration mode for the specified
trustpoint certificate authority (CA).
Example:
apic1(config)# crypto ca myCA
Step 3 [no] cert-chain pem-data Stores the certificate chain in PEM format.
Enter the entire chain of trust from the trustpoint
Example:
to a trusted root authority.
apic1(config-ca)# cert-chain -----BEGIN
CERTIFICATE----- MIIC4jCCAoygAw.....
Examples
This example shows how to configure a CA.
apic1# configure
The APIC software allows you to generate an RSA key pair with a configurable key size (or modulus). The
default key size is 512. You can also configure an RSA key-pair label. The default key label is the device
fully qualified domain name (FQDN).
Procedure
Step 2 [no] crypto keyring {default | keyring-name} Creates or configures a keyring to hold an SSL
certificate.
Example:
apic1(config)# crypto keyring myKeyring
Step 6 [no] key key-data Creates the private key of the certificate.
Example:
apic1(config-keyring)# key
XXXXXXXXXXXXXXXXXXXXXXX
Step 7 [no] modulus {mod512 | mod1024 | mod1536 Sets the length of the encryption keys.
| mod2048}
Example:
apic1(config-keyring)# modulus mod1024
Examples
This example shows how to configure a keyring.
apic1# configure
apic1(config)# crypto keyring myKeyring
apic1(config-keyring)# cert "-----BEGIN CERTIFICATE----- MIIC4jCCAoygAw.....
apic1(config-keyring)# tp myCertificate
apic1(config-keyring)# key XXXXXXXXXXXXXXXXXXXXXXX
apic1(config-keyring)# modulus mod1024
apic1(config-keyring)# exit
Procedure
Step 2 [no] crypto keyring {default | keyring-name} Creates or configures a keyring to hold an SSL
certificate.
Example:
apic1(config)# crypto keyring default
Step 12 country country-code Sets the two-letter ISO code for the country
where the organization is located.
Example:
apic1(config-csr)# country US
Examples
This example shows how to generate a certificate signing request (CSR).
apic1# configure
apic1(config)# crypto keyring default
apic1(config-keyring)# csr
apic1(config-csr)# subj-name www.exampleCorp.com
apic1(config-csr)# cert "-----BEGIN CERTIFICATE----- MIIC4jCCAoygAw.....
apic1(config-csr)# pwd c1$c0123
What to do next
Submit the CSR to a CA.
Configuring Webtokens
Procedure
Step 3 [no] max-validity-period hours Sets the maximum validity period for a
webtoken. The range is 4 to 24 hours.
Example:
apic1(config-webtoken)#
max-validity-period 10
Step 5 [no] ui-idle-timeout-seconds seconds Sets the maximum GUI idle duration before
requiring login refresh. The range is 60 to 65525
Example:
seconds.
apic1(config-webtoken)#
ui-idle-timeout-seconds 120
Step 6 [no] webtoken-timeout-seconds seconds Sets the webtoken timeout interval. The range
is 600 to 9600 seconds.
Example:
apic1(config-webtoken)#
webtoken-timeout-seconds 1200
Step 7 exit
Example:
Examples
This example shows how to configure a webtoken.
apic1# configure
apic1(config)# crypto webtoken
apic1(config-webtoken)# max-validity-period 10
apic1(config-webtoken)# session-record-flags login,refresh
apic1(config-webtoken)# ui-idle-timeout-seconds 120
apic1(config-webtoken)# webtoken-timeout-seconds 1200
Step 8 [no] request-status-count count Sets the maximum count of HTTP requests to
track. The range is 0 to 10240.
Example:
apic1(config-http)# request-status-count
512
Examples
This example shows how to configure HTTP service.
apic1# configure
apic1(config)# comm-policy myCommPolicy
apic1(config-comm-policy)# http
apic1(config-http)# admin-state-enable
apic1(config-http)# allow-origin www.example.com
apic1(config-http)# port 8080
apic1(config-http)# no redirect
apic1(config-http)# request-status-count 512
apic1(config-http)# exit
Step 5 [no] port port-number Sets the port used for HTTPS communication
service.
Example:
apic1(config-https)# port 443
Step 6 [no] request-status-count count Sets the maximum count of HTTPS requests to
track. The range is 0 to 10240.
Example:
apic1(config-https)# request-status-count
512
Step 7 [no] ssl-protocols {TLSv1 | TLSv1.1 | Specifies in a comma-separated list the SSL
TLSv1.2} protocols that are supported. The options are
TLSv1 , TLSv1.1 , and TLSv1.2 .
Example:
apic1(config-https)# ssl-protocols
TLSv1.1,TLSv1.2
Step 8 [no] use-keyring keyring-name Specifies a keyring to use for the HTTPS server
SSL certificate.
Example:
apic1(config-https)# use-keyring
myKeyRing
Examples
This example shows how to configure HTTPS service.
apic1# configure
apic1(config)# comm-policy myCommPolicy
apic1(config-comm-policy)# https
apic1(config-https)# admin-state-enable
apic1(config-https)# port 443
apic1(config-https)# request-status-count 512
apic1(config-https)# ssl-protocols TLSv1.1,TLSv1.2
apic1(config-https)# use-keyring myKeyRing
apic1(config-https)# exit
Step 5 [no] port port-number Sets the port used for SSH communication
service.
Example:
apic1(config-ssh-service)# port 22
Examples
This example shows how to configure SSH service.
apic1# configure
apic1(config)# comm-policy myCommPolicy
apic1(config-comm-policy)# ssh-service
apic1(config-ssh-service)# admin-state-enable
apic1(config-ssh-service)# port 22
apic1(config-ssh-service)# exit
Procedure
Step 5 [no] port port-number Sets the port used for Telnet communication
service.
Example:
apic1(config-telnet)# port 23
Examples
This example shows how to configure Telnet service.
apic1# configure
apic1(config)# comm-policy myCommPolicy
apic1(config-comm-policy)# telnet
apic1(config-telnet)# admin-state-enable
apic1(config-telnet)# port 23
apic1(config-telnet)# exit
Procedure
Examples
This example shows how to enable AES encryption and configure a passphrase.
apic1# configure
apic1(config)# crypto aes
apic1(config-aes)# clear-encryption-key
apic1(config-aes)# passphrase "This is my passphrase"
apic1(config-aes)# encryption
Procedure
Step 3 system controller-id controller-id {approve | In strict mode, approves or rejects a controller
reject} to join the fabric.
Example:
apic1(config)# system controller-id
FCH1750V025 approve
Examples
This example shows how to change the fabric security mode to strict.
apic1# configure
apic1(config)# system fabric-security-mode strict
This example shows how to approve a controller to join the fabric when strict mode is configured.
apic1# configure
apic1(config)# system controller-id FCH1750V025 approve
Changing the configuration of the COOP authentication type has the following effects:
• When the configuration changes from compatible to strict mode, all non-authenticated ZMQ connections
are disconnected.
• When the configuration changes from strict to compatible mode, COOP immediately accepts both
authenticated and non-authenticated ZMQ connections.
Step 3 authentication type {compatible | strict} Configures the COOP authentication type as
one of the following:
Example:
apic1(config-coop-fabric)# authentication • compatible - COOP allows MD5
type compatible authenticated and non-authenticated ZMQ
connections.
• strict - allows MD5 authenticated
ZMQ connections only.
Example
This example shows how to configure COOP authentication in compatible mode:
apic1# configure
apic1(config)# coop-fabric
apic1(config-coop-fabric# authentication type compatible
Configuring FIPS
About Federal Information Processing Standards (FIPS)
The Federal Information Processing Standards (FIPS) Publication 140-2, Security Requirements for
Cryptographic Modules, details the U.S. government requirements for cryptographic modules. FIPS 140-2
specifies that a cryptographic module should be a set of hardware, software, firmware, or some combination
that implements cryptographic functions or processes, including cryptographic algorithms and, optionally,
key generation, and is contained within a defined cryptographic boundary.
FIPS specifies certain cryptographic algorithms as secure, and it also identifies which algorithms should be
used if a cryptographic module is to be called FIPS compliant.
Procedure
Step 2 fips mode enable Enables FIP. The no fips mode enable
command disables FIPS.
Example:
apic1(config)# fips mode enable You must reboot to complete the configuration.
Anytime you change the mode, you must reboot
to complete the configuration.
The ACI Leaf/Spine supervisor module has a control plane and is critical to the operation of the network. Any
disruption or attacks to the supervisor module will result in serious network outages. For example, excessive
traffic to the supervisor module could overload and slow down the performance of the entire Cisco ACI fabric.
Another example is a DoS attack on the ACI Leaf/Spine supervisor module that could generate IP traffic
streams to the control plane at a very high rate, forcing the control plane to spend a large amount of time in
handling these packets and preventing the control plane from processing genuine traffic.
Examples of DoS attacks are as follows:
• Internet Control Message Protocol (ICMP) echo requests
• IP fragments
• TCP SYN flooding
These attacks can impact the device performance and have the following negative effects:
• Reduced service quality (such as poor voice, video, or critical applications traffic)
• High route processor or switch processor CPU utilization
• Route flaps due to loss of routing protocol updates or keepalives
• Processor resource exhaustion, such as the memory and buffers
• Indiscriminate drops of incoming packets
Note ACI Leaf/Spines are by default protected by CoPP with default settings. This feature allows for tuning the
parameters on a group of nodes based on customer needs.
All of these different packets could be maliciously used to attack the control plane and overwhelm the Cisco
ACI Fabric. CoPP classifies these packets to different classes and provides a mechanism to individually control
the rate at which the ACI Leaf/Spine supervisor module receives these packets.
Classification for CoPP:
For effective protection, the ACI Leaf/Spine NX-OS classifies the packets that reach the supervisor modules
to allow you to apply different rate controlling policies based on the type of the packet. For example, you
might want to be less strict with a protocol packet such as Hello messages but more strict with a packet that
is sent to the supervisor module because the IP option is set.
Rate Controlling Mechanisms:
Once the packets are classified, the ACI Leaf/Spine NX-OS has different mechanisms to control the rate at
which packets arrive at the supervisor module.
You can configure the following parameters for policing:
• Committed information rate (CIR)—Desired bandwidth, specified as a bit rate or a percentage of the
link rate.
• Committed burst (BC)—Size of a traffic burst that can exceed the CIR within a given unit of time and
not impact scheduling.
When the Cisco ACI Leaf/Spine is bootup, the platform setup pre-defined CoPP parameters for different
protocols are based on the tests done by Cisco.
Configuring Per Interface Per Protocol CoPP Policy Using the NX-OS Style CLI
Procedure
The following supported FHS features secure the protocols and help build a secure endpoint database on the
fabric leaf switches, that are used to mitigate security threats such as MIM attacks and IP thefts:
• ARP Inspection—allows a network administrator to intercept, log, and discard ARP packets with invalid
MAC address to IP address bindings.
• ND Inspection—learns and secures bindings for stateless autoconfiguration addresses in Layer 2 neighbor
tables.
• DHCP Inspection—validates DHCP messages received from untrusted sources and filters out invalid
messages.
• RA Guard—allows the network administrator to block or reject unwanted or rogue router advertisement
(RA) guard messages.
• IPv4 and IPv6 Source Guard—blocks any data traffic from an unknown source.
• Trust Control—a trusted source is a device that is under your administrative control. These devices
include the switches, routers, and servers in the Fabric. Any device beyond the firewall or outside the
network is an untrusted source. Generally, host ports are treated as untrusted sources.
FHS features are enabled on a per tenant bridge domain (BD) basis. As the bridge domain, may be deployed
on a single or across multiple leaf switches, the FHS threat control and mitigation mechanisms cater to a single
switch and multiple switch scenarios.
• Any secured endpoint entry in the FHS Binding Table Database in DOWN state will get cleared after
18 Hours of timeout. The entry moves to DOWN state when the front panel port where the entry is
learned is link down. During this window of 18 Hours, if the endpoint is moved to a different location
and is seen on a different port, the entry will be gracefully moved out of DOWN state to
REACHABLE/STALE as long as the endpoint is reachable from the other port it is moved from.
• When IP Source Guard is enabled, the IPv6 traffic that is sourced using IPv6 Link Local address as IP
source address is not subject to the IP Source Guard enforcement (i.e. Enforcement of Source Mac <=>
Source IP Bindings secured by IP Inspect Feature). This traffic is permitted by default irrespective of
binding check failures.
• FHS is not supported on L3Out interfaces.
• FHS is not supported N9K-M12PQ based TORs.
• FHS in ACI Multi-Site is a site local capability therefore it can only be enabled in a site from the APIC
cluster. Also, FHS in ACI Multi-Site only works when the BD and EPG is site local and not stretched
across sites. FHS security cannot be enabled for stretched BD or EPGs.
• FHS is not supported on a Layer 2 only bridge domain.
• Enabling FHS feature can disrupt traffic for 50 seconds because the EP in the BD are flushed and EP
Learning in the BD is disabled for 50 seconds.
Procedure
Step 1 configure
Enters configuration mode.
Example:
apic1# configure
apic1(config-tenant-fhs-raguard)# other-config-flag
apic1(config-tenant-fhs-raguard)# maximum-router-preference low
apic1(config-tenant-fhs-raguard)# minimum-hop-limit 10
apic1(config-tenant-fhs-raguard)# maximum-hop-limit 100
apic1(config-tenant-fhs-raguard)# exit
apic1(config-tenant-fhs-secpol)# exit
apic1(config-tenant-fhs)# trust-control tcpol1
pic1(config-tenant-fhs-trustctrl)# arp
apic1(config-tenant-fhs-trustctrl)# dhcpv4-server
apic1(config-tenant-fhs-trustctrl)# dhcpv6-server
apic1(config-tenant-fhs-trustctrl)# ipv6-router
apic1(config-tenant-fhs-trustctrl)# router-advertisement
apic1(config-tenant-fhs-trustctrl)# neighbor-discovery
apic1(config-tenant-fhs-trustctrl)# exit
apic1(config-tenant-fhs)# exit
apic1(config-tenant)# bridge-domain bd1
apic1(config-tenant-bd)# first-hop-security security-policy pol1
apic1(config-tenant-bd)# exit
apic1(config-tenant)# application ap1
apic1(config-tenant-app)# epg epg1
apic1(config-tenant-app-epg)# first-hop-security trust-control tcpol1
Legend:
TR : trusted-access UNRES : unresolved Age
: Age since creation
UNTR : untrusted-access UNDTR : undetermined-trust CRTNG
: creating
UNKNW : unknown TENTV : tentative INV
: invalid
NDP : Neighbor Discovery Protocol STA : static-authenticated REACH
: reachable
INCMP : incomplete VERFY : verify INTF
: Interface
TimeLeft : Remaining time since last refresh LM : lla-mac-match DHCP
: dhcp-assigned
EPG-Mode:
U : unknown M : mac V : vlan I : ip
---------------------------------------------------------------------------------------------------------------------
| Origin | IP | MAC | INTF | EPG(sclass)(mode) | Trust-lvl |
State | Age | TimeLeft |
---------------------------------------------------------------------------------------------------------------------
| ARP | 192.0.200.12 | D0:72:DC:A0:3D:4F | eth1/1 | epg300(49154)(V) | LM,TR |
STALE | 00:04:49 | 18:08:13 |
| ARP | 172.29.205.232 | D0:72:DC:A0:3D:4F | eth1/1 | epg300(49154)(V) | LM,TR |
STALE | 00:03:55 | 18:08:21 |
| ARP | 192.0.200.21 | D0:72:DC:A0:3D:4F | eth1/1 | epg300(49154)(V) | LM,TR |
REACH | 00:03:36 | 00:00:02 |
| LOCAL | 192.0.200.1 | 00:22:BD:F8:19:FF | vlan3 | LOCAL(16387)(I) | STA |
REACH | 04:49:41 | N/A |
| LOCAL | fe80::200 | 00:22:BD:F8:19:FF | vlan3 | LOCAL(16387)(I) | STA |
REACH | 04:49:40 | N/A |
| LOCAL | 2001:0:0:200::1 | 00:22:BD:F8:19:FF | vlan3 | LOCAL(16387)(I) | STA |
Step 4 Show violations with the different types and reasons example:
Example:
leaf4# show fhs violations all
Violation-Type:
POL : policy THR : address-theft-remote
ROLE : role TH : address-theft
INT : internal
Violation-Reason:
IP-MAC-TH : ip-mac-theft OCFG_CHK : ra-other-cfg-check-fail
ANC-COL : anchor-collision
PRF-LVL-CHK : ra-rtr-pref-level-check-fail INT-ERR : internal-error
TRUST-CHK : trust-check-fail
SRV-ROL-CHK : srv-role-check-fail ST-EP-COL : static-ep-collision
LCL-EP-COL : local-ep-collision
MAC-TH : mac-theft EP-LIM : ep-limit-reached
MCFG-CHK : ra-managed-cfg-check-fail
HOP-LMT-CHK : ra-hoplimit-check-fail MOV-COL : competing-move-collision
RTR-ROL-CHK : rtr-role-check-fail
IP-TH : ip-theft
EPG-Mode:
U : unknown M : mac V : vlan I : ip
reach
authenticated able
1/102 local ipv6 fe80::200 00:22:BD:F8:19:FF vlan3 static-
reach
authenticated able
1/102 local ipv6 2001:0:0:200::1 00:22:BD:F8:19:FF vlan3 static-
reach
authenticated able
1/101 arp ipv4 192.0.200.23 D0:72:DC:A0:02:61 eth1/2 lla-mac-match
stale
,untrusted-
access
1/101 local ipv4 192.0.200.1 00:22:BD:F8:19:FF vlan3 static-
reach
authenticated able
1/101 nd ipv6 fe80::d272:dcff:fea0 D0:72:DC:A0:02:61 eth1/2 lla-mac-match
reach
:261 ,untrusted-
able
access
1/101 nd ipv6 2001:0:0:200::20 D0:72:DC:A0:02:61 eth1/2 lla-mac-match
stale
,untrusted-
access
1/101 nd ipv6 2001::200:d272:dcff: D0:72:DC:A0:02:61 eth1/2 lla-mac-match
stale
fea0:261 ,untrusted-
access
1/101 local ipv6 fe80::200 00:22:BD:F8:19:FF vlan3 static-
reach
authenticated able
1/101 local ipv6 2001:0:0:200::1 00:22:BD:F8:19:FF vlan3 static-
reach
authenticated able
1/103 local ipv4 192.0.200.1 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
1/103 local ipv6 fe80::200 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
1/103 local ipv6 2001:0:0:200::1 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
1/104 arp ipv4 192.0.200.10 F8:72:EA:AD:C4:7C eth1/1 lla-mac-match
stale
,trusted-access
1/104 arp ipv4 172.29.207.222 D0:72:DC:A0:3D:4C eth1/1 lla-mac-match
stale
,trusted-access
1/104 local ipv4 192.0.200.1 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
1/104 nd ipv6 fe80::fa72:eaff:fead F8:72:EA:AD:C4:7C eth1/1 lla-mac-match
stale
:c47c
,trusted-access
1/104 nd ipv6 2001:0:0:200::10 F8:72:EA:AD:C4:7C eth1/1 lla-mac-match
stale
,trusted-access
1/104 local ipv6 fe80::200 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
1/104 local ipv6 2001:0:0:200::1 00:22:BD:F8:19:FF vlan4 static-
reach
authenticated able
swtb23-ifc1#
Pod/Node : 1/104
Request Received : 6
Request Switched : 6
Request Dropped : 0
Reply Received : 954
Reply Switched : 954
Reply Dropped : 0
Pod/Node : 1/104
Neighbor Solicitation Received : 123
Neighbor Solicitation Switched : 47
Neighbor Solicitation Dropped : 76
Neighbor Advertisement Received : 252
Neighbor Advertisement Switched : 228
Neighbor Advertisement Drop : 24
Router Solicitation Received : 0
Router Solicitation Switched : 0
Router Solicitation Dropped : 0
Router Adv Received : 53
Router Adv Switched : 6
Router Adv Dropped : 47
Redirect Received : 0
Redirect Switched : 0
Redirect Dropped : 0
Configuring 802.1x
802.1X Overview
802.1X defines a client-server based access control and authentication protocol that restricts unauthorized
clients from connecting to a LAN through publicly accessible ports. The authentication server authenticates
each client connected to a Cisco NX-OS device port.
Until the client is authenticated, 802.1X access control allows only Extensible Authentication Protocol over
LAN (EAPOL) traffic through the port to which the client is connected. After authentication is successful,
normal traffic can pass through the port.
The RADIUS distributed client/server system allows you to secure networks against unauthorized access. In
the Cisco ACI implementation, RADIUS clients run on the ToRs and send authentication and accounting
requests to a central RADIUS server that contains all user authentication and network service access information.
Host Support
The 802.1X feature can restrict traffic on a port with the following modes:
• Single-host Mode—Allows traffic from only one endpoint device on the 802.1X port. Once the endpoint
device is authenticated, the APIC puts the port in the authorized state. When the endpoint device leaves
the port, the APIC put the port back into the unauthorized state. A security violation in 802.1X is defined
as a detection of frames sourced from any MAC address other than the single MAC address authorized
as a result of successful authentication. In this case, the interface on which this security association
violation is detected (EAPOL frame from the other MAC address) will be disabled. Single host mode is
applicable only for host-to-switch topology and when a single host is connected to the Layer 2 (Ethernet
access port) or Layer 3 port (routed port) of the APIC.
• Multi-host Mode—Allows multiple hosts per port but only the first one gets authenticated. The port is
moved to the authorized state after the successful authorization of the first host. Subsequent hosts are
not required to be authorized to gain network access once the port is in the authorized state. If the port
becomes unauthorized when reauthentication fails or an EAPOL logoff message is received, all attached
hosts are denied access to the network. The capability of the interface to shut down upon security
association violation is disabled in multiple host mode. This mode is applicable for both switch-to-switch
and host-to-switch topologies
• Multi-Auth Mode—Allows multiple hosts and all hosts are authenticated separately.
• Multi-Domain Mode—For separate data and voice domain. For use with IP-Phones.
Authentication Modes
ACI 802.1X supports the following authentication modes:
• EAP—The authenticator then sends an EAP-request/identity frame to the supplicant to request its identity
(typically, the authenticator sends an initial identity/request frame followed by one or more requests for
authentication information). When the supplicant receives the frame, it responds with an
EAP-response/identity frame.
• MAB—MAC Authentication Bypass (MAB) is supported as the fallback authentication mode. MAB
enables port-based access control using the MAC address of the endpoint. A MAB-enabled port can be
dynamically enabled or disabled based on the MAC address of the device that connects to it. Prior to
MAB, the endpoint's identity is unknown and all traffic is blocked. The switch examines a single packet
to learn and authenticate the source MAC address. After MAB succeeds, the endpoint's identity is known
and all traffic from that endpoint is allowed. The switch performs source MAC address filtering to help
ensure that only the MAB-authenticated endpoint is allowed to send traffic.
• The Cisco ACI does not support 802.1X authentication on port channels or subinterfaces.
• The Cisco ACI supports 802.1X authentication on member ports of a port channel but not on the port
channel itself.
• Member ports with and without 802.1X configuration can coexist in a port channel. However, you must
ensure the identical 802.1X configuration on all the member ports in order for channeling to operate with
802.1X
• When you enable 802.1X authentication, supplicants are authenticated before any other Layer 2 or Layer
3 features are enabled on an Ethernet interface.
• 802.1X is supported only on a leaf chassis that is EX or FX type.
• 802.1X is only supported Fabric Access Ports. 802.1X is not supported on Port-Channels, or
Virtual-Port-Channels.
• IPv6 is not supported for dot1x clients in the 3.2(1) release.
• While downgrading to earlier releases especially in cases where certain interface config (host mode and
auth type) is unsupported in that release, dot1x authentication type defaults to none. Host-mode would
need to be manually re-configured to either single host/multi host depending on whatever is desired. This
is to ensure that the user configures only the supported modes/auth-types in that release and doesn’t run
into unsupported scenarios.
• Multi-Auth supports 1 voice client and multiple data clients (all belonging to same data vlan/epg).
• Fail-epg/vlan under 802.1X node authentication policy is a mandatory configuration.
• Multi-domain more than 1 voice and 1 data client puts the port in security disabled state.
• The following platforms are not supported for 802.1X:
• N9K-C9396PX
• N9K-M12PQ
• N9K-C93128TX
• N9K-M12PQ
Configuration Overview
The 802.1X and RADIUS processes are started only when enabled by APIC. Internally, this means dot1x
process is started when 802.1X Inst MO is created and radius process is created when radius entity is created.
Dot1x based authentication must be enabled on each interface for authenticating users connected on that
interface otherwise the behavior is unchanged.
RADIUS server configuration is done separately from dot1x configuration. RADIUS configuration defines
a list of RADIUS servers and a way to reach them. Dot1x configuration contains a reference to RADIUS
group (or default group) to use for authentication.
Both 802.1X and RADIUS configuration must be done for successful authentication. Order of configuration
is not important but if there is no RADIUS configuration then 802.1X authentication cannot be successful.
Procedure
Step 3 Configure policy group and specify port authentication policy in the group:
Example:
apic1(config)#template leaf-policy-group lpg2
apic1(config-leaf-policy-group)# port-authentication mydot1x
apic1(config-leaf-policy-group)#exit
apic1(config-port-authentication)# exit
apic1(config-pol-grp-if)# exit
apic1(config)#
apic1(config)# leaf-profile myleafprofile
apic1(config-leaf-profile)# leaf-group myleafgrp
apic1(config-leaf-group)# leaf 101
apic1(config-leaf-group)# exit
Note If you configure an Anycast MAC and IP address using the addresses for an existing static endpoint, the
configuration is pushed from the APIC to the switch and no fault is generated, but the switch does not install
the Anycast addresses in the hardware. Deleting the static endpoint does not resolve the problem. You must
delete both the static endpoint and the Anycast configurations and reconfigure the Anycast addresses.
Procedure
Step 1 Configure Anycast services behind an EPG subnet, using the following commands:
a) configure
Enters configuration mode.
Example:
apic1# configure
b) tenant tenant-name
Creates a tenant if it does not exist or enters tenant configuration mode.
Example:
apic1(config)# tenant anycast1-it
c) application app-name
Creates an application profile if it doesn't exist and enters application profile configuration mode.
Example:
apic1(config-tenant)# application AP0
d) epg epg-name
Creates an EPG if it doesn't exist and enters EPG configuration mode.
Example:
apic1(config-tenant-app)# epg epg1
Step 2 Configure Anycast for Layer 4 to Layer 7 services with PBR, using the following commands:
a) configure
Enters configuration mode.
Example:
apic1# configure
b) tenant name
Creates a tenant if it does not exist or enters tenant configuration mode.
apic1(config)# tenant t1
c) svcredir-pol name
Enters service-redirect policy mode and creates a service redirection policy.
Example:
apic1(config-tenant)# svcredir-pol N1Ext
d) anycast enable
Enables Anycast for the service redirection policy. Use the no form of the command to disable Anycast
for the policy.
Example:
apic1(svcredir-pol)# anycast enable
Step 3 Configure Anycast for Layer 4 to Layer 7 services without PBR, with the following commands:
a) configure
Enters configuration mode.
Example:
apic1# configure
b) tenant name
Creates a tenant if it does not exist or enters tenant configuration mode.
apic1(config)# tenant t1
d) service device-cluster-name
Defines the service with a device cluster.
Example:
apic1(config-graph)# service N1
g) mac-address mac-address
Defines the Anycast MAC address. To remove it, use the no form of the command.
Example:
apic1(config-subnet-ip)# mac-address 00.00.00.00.00.50
Example
The following example configures Anycast services behind EPG1:
apic1# configure
apic1(config)# tenant anycast1-it
apic1(config-tenant)# application AP0
apic1(config-tenant-app)# epg epg-1
apic1(config-tenant-app-epg)# endpoint ip 1.2.3.4/32 anycast 00:11:22:33:44:55
The following example configures Anycast services in a Layer 4 to Layer 7 service redirection policy:
apic1# configure
apic1(config)# tenant t1
apic1(config-tenant)# svcredir-pol N1Ext
apic1(svcredir-pol)# anycast enable
apic1(svcredir-pol)# redir-dest 2000::25 00:00:00:00:00:07
The following example configures Anycast services in a Layer 4 to Layer 7 service without PBR:
apic1# configure
apic1(config)# tenant t1
apic1(config-tenant)# l4l7 graph WebGraph contract default
apic1(config-graph)# service N1
apic1(config-service)# connector provider
apic1(config-connector)# subnet-ip 50.50.50.50/32 subnet-ctrl no-default-gateway
apic1(config-subnet-ip)# mac-address 00.00.00.00.00.50
Configuring VMM
For information about configuring virtual machine management using the NX-OS style CLI for APIC, see
the Cisco ACI Virtualization Guide.
Procedure
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] Configures an NTP server for the active NTP
[use-vrf {inband-mgmt | oob-default}] [key policy. To make this server the preferred server
key-value] for the active NTP policy, include the prefer
keyword. If NTP authentication is enabled,
Example:
specify a reference key ID. To specify the
apic1(config-template-ntp-fabric)# in-band or out-of-band management access
server 192.0.20.123 prefer use-vrf
oob-mgmt VRF, include the use-vrf keyword with the
inb-default or oob-default keyword.
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
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
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#
------ - ------------ ------ ---- -- ----- ----- ----- ------ ------ ------
1 * 192.0.20.123 .GPS. u 27 64 377 76.427 0.087 0.067
Step 2 [no] clock display-format {local | utc} Sets the clock date time format to either local
or UTC time.
Example:
apic1(config)# clock display-format local
Step 3 [no] clock show-offset enable Enables (or disables) the display of the offfset
from UTC. This setting is valid only when the
Example:
display-format is local.
apic1(config)# clock show-offset enable
Step 4 [no] clock timezone timezone-code Specifies the local time zone. The default is
p0_utc.
Example:
apic1(config)# clock timezone
n420_America-Los_Angeles
Step 5 show clock Specifies the delay time for LLDP to initialize
on any interface . The range is 1 to 10 seconds;
Example:
the default is 2 seconds.
apic1(config)# show clock
Examples
This example shows how to configure the system clock for local time in the Los Angeles timezone.
Procedure
Step 2 [no] errdisable recovery interval seconds Specifies the interval for an interface to recover
from the error-disabled state. The range is from
Example:
30 to 65535 seconds
apic1(config)# errdisable recovery
interval 300
Step 3 [no] errdisable recovery cause {bpduguard Specifies a condition under which the interface
| ep-move | mcp-loop} automatically recovers from the error-disabled
state, and the device retries bringing the
Example:
interface up. The default is disabled. The
apic1(config)# errdisable recovery cause condition options are:
mcp-loop
• bpduguard —Enable timer to recover
from a BPDU guard error disable.
• ep-move —Enable timer to recover from
an endpoint move error disable.
• mcp-loop —Enable timer to recover from
an MCP loop error disable.
• storm-control-recovery —Enable timer
to recover from a storm control recovery
error disable.
Examples
This example shows how to configure EDR to recover from an MCP loop error disable.
Procedure
Step 2 [no] lldp holdtime seconds Specifies the hold time to be sent in LLDP
packets.
Example:
apic1(config)# lldp holdtime
Step 3 [no] lldp holdtime seconds Specifies the hold time to be sent in LLDP
packets. The range is 10 to 255 seconds; the
Example:
default is 120 seconds.
apic1(config)# lldp holdtime 120
Step 4 [no] lldp reinit seconds Specifies the delay time for LLDP to initialize
on any interface . The range is 1 to 10 seconds;
Example:
the default is 2 seconds.
apic1(config)# lldp reinit 2
Step 5 [no] lldp timer seconds Specifies the transmission frequency seconds
of LLDP updates in seconds. The range is 5 to
Example:
254 seconds; the default is 30 seconds.
apic1(config)# lldp timer 30
Examples
This example shows how to configure LLDP.
detected. MCP works in a complementary manner with STP that is running on external Layer 2 networks,
and handles Bridge Protocol Data Unit (BPDU) packets that access ports receive.
A fabric administrator provides a key that MCP uses to identify which MCP packets are initiated by the ACI
fabric. The administrator can choose how the MCP policies identify loops and how to act upon the loops:
syslog only, or disable the port.
Procedure
Step 2 [no] mcp action port-disable Specifies whether a port should be place in a
disabled state if mis-cabling is detected.
Example:
apic1(config)# mcp action port-disable
Step 3 [no] mcp enable [key key-value] Allows enabling or disabling of the MCP
protocol globally for the entire fabric. A
Example:
password (key) is required when enabling the
apic1(config)# mcp enable key policy but not when disabling.
0123456789abcdef
Step 4 [no] mcp factor number Sets the loop detection multiplication factor,
which is used while sending MCP packets. The
Example:
range is 1 to 255.
apic1(config)# mcp factor 64
Step 5 [no] mcp init-delay seconds Specifies the initial delay time. The range is 0
to 1800 seconds; the default is 180.
Example:
apic1(config)# mcp init-delay 180
Step 6 [no] mcp transmit-frequency frequency Sets the frequency of transmission of MCP
packets to detect mis-cabling. The range is 100
Example:
milliseconds to 300 seconds; the default is 2
apic1(config)# mcp transmit-frequency 2 seconds.
Examples
This example shows how to configure MCP for a transmit frequency of 2 seconds.
This example shows how to configure MCP for a transmit frequency of 2 seconds and 300
milliseconds.
Procedure
Step 2 [no] endpoint loop-detect action Specifies the action to perform when an
{bd-learn-disable | port-disable} endpoint loop is detected. The options are:
Example: • bd-learn-disable —Disable MAC address
apic1(config)# endpoint loop-detect learning on the bridge domain.
action port-disable
• port-disable —Disable the port.
Step 3 [no] endpoint loop-detect enable Allows enabling or disabling of the endpoint
loop protection protocol globally for the entire
Example:
fabric.
apic1(config)# endpoint loop-detect
enable
Step 4 [no] endpoint loop-detect factor number Sets the loop detection multiplication factor.
The range is 1 to 255.
Example:
apic1(config)# endpoint loop-detect
factor 64
Step 5 [no] endpoint loop-detect interval seconds Specifies the loop detection interval. The range
is 30 to 300 seconds.
Example:
apic1(config)# endpoint loop-detect
interval 60
Examples
This example shows how to configure the endpoint loop protection policy.
The rogue endpoint control policy is configured globally and, unlike other loop prevention methods, functions
at the level of individual endpoints (IP and MAC addresses). It does not distinguish between local or remote
moves; any type of interface change is considered a move in determining if an endpoint should be quarantined.
The rogue endpoint control feature is disabled by default.
Procedure
Step 1 configure
Enters global configuration mode.
Example:
apic1# configure
Configuring IP Aging
Overview
The IP Aging policy tracks and ages unused IP addresses on an endpoint. Tracking is performed using the
endpoint retention policy configured for the bridge domain to send ARP requests (for IPv4) and neighbor
solicitations (for IPv6) at 75% of the local endpoint aging interval. When no response is received from an IP
address, that IP address is aged out.
This document explains how to configure the IP Aging policy.
Procedure
What to do next
To specify the interval used for tracking IP addresses on endpoints, create an Endpoint Retention policy.
Procedure
Step 2 [no] system dynamic-load-balance mode Specifies the mode of operation of the load
{dynamic-aggressive | dynamic-conservative balancer. The modes are:
| link-failure-resiliency |
• dynamic-aggressive —The flowlet
packet-prioritization}
timeout is a relatively small value. This
very fine-grained dynamic load balancing
is optimal for the distribution of traffic,
but some packet reordering might occur.
However, the overall benefit to application
performance is equal to or better than the
conservative mode.
• dynamic-conservative —The flowlet
timeout is a larger value that guarantees
packets are not to be re-ordered. The
tradeoff is less granular load balancing
because new flowlet opportunities are less
frequent.
• link-failure-resiliency —Static load
balancing gives a distribution of flows
across the available links that is roughly
even.
• packet-prioritization —Dynamic Packet
Prioritization (DPP) prioritizes short flows
higher than long flows; a short flow is less
than approximately 15 packets. Because
short flows are more sensitive to latency
than long ones, DPP can improve overall
application performance.
apic1(config)# system
dynamic-load-balance mode
packet-prioritization
Examples
This example shows how to configure dynamic load balancing with packet prioritization.
Note Multiple Spanning Tree (MST) is not supported on interfaces configured with the Per Port VLAN feature
(configuring multiple EPGs on a leaf switch using the same VLAN ID with localPort scope).
Procedure
Step 5 [no] instance instance-id vlan vlan-range Maps VLANs to an MST instance. You can
assign a VLAN to only one spanning-tree
Example:
instance at a time. The instance ID range is 1
apic1(config-stp-region)# instance 2 vlan to 4094. To specify a VLAN range, use a
1-63
hyphen.
Examples
This example shows how to configure an MST spanning-tree policy.
Configuring IS-IS
Intermediate System-to-Intermediate System (IS-IS) is a dynamic link-state routing protocol that can detect
changes in the network topology and calculate loop-free routes to other nodes in the network.
Procedure
Step 4 [no] lsp-gen-interval level-1 lsp-max-wait Configures the IS-IS throttle for LSP
[lsp-initial-wait lsp-second-wait] generation. The parameters are as follows:
Example: • lsp-max-wait —The maximum wait
apic1(config-template-isis-fabric)# between the trigger and LSP generation.
lsp-gen-interval level-1 500 500 500
• lsp-initial-wait —The initial wait between
the trigger and LSP generation.
Step 5 [no] lsp-mtu mtu Sets the maximum transmission unit (MTU)
size of IS-IS hello packets. The range is 256
Example:
to 4352.
apic1(config-template-isis-fabric)#
lsp-mtu 2048 IS-IS hello packets are used to discover and
maintain adjacencies. By default, the hello
packets are padded to the full maximum
transmission unit (MTU) size to allow for early
detection of errors due to transmission
problems with large frames or due to
mismatched MTUs on adjacent interfaces.
However, IS-IS adjacency formation may fail
due to MTU mismatch on a link, requiring the
adjustment of the MTU size.
Step 6 [no] spf-interval level-1 spf-max-wait Configures the interval between LSA arrivals.
[spf-initial-wait spf-second-wait] The parameters are as follows:
Example: • spf-max-wait —The maximum wait
apic1(config-template-isis-fabric)# between the trigger and SPF computation.
spf-interval level-1 500 500 500
• spf-initial-wait —The initial wait between
the trigger and SPF computation.
• spf-second-wait —The second wait used
for SPF computation during backoff.
Examples
This example shows how to configure IS-IS.
aapic1# configure
apic1(config)# template isis-fabric polIsIs
apic1(config-template-isis-fabric)# lsp-fast-flood
apic1(config-template-isis-fabric)# lsp-gen-interval level-1 500 500 500
apic1(config-template-isis-fabric)# lsp-mtu 2048
apic1(config-template-isis-fabric)# spf-interval level-1 500 500 500
apic1(config-template-isis-fabric)# exit
apic1(config)# template pod-group allPods
apic1(config-pod-group)# inherit isis-fabric polIsIs
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#
Procedure
Step 4 [no] route-reflector spine list Configure up to two spine nodes as route
reflectors. For redundancy ,you should
Example:
configure primary and secondary route
apic1(config-bgp-fabric)# route-reflector reflectors.
spine spine1,spine2
Examples
This example shows how to configure spine1 and spine2 as BGP route reflectors.
apic1# configure
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 123456789
apic1(config-bgp-fabric)# route-reflector spine spine1,spine2
apic1(config-bgp-fabric)# exit
apic1(config)#
Decommissioning a Node
Two levels of decommissioning are supported:
• Regular—Similar to disabling the node. After being decommissioned, the node cannot rejoin the fabric
until the no decommission command is executed.
• Complete—When the node is decommissioned, all fabric configuration related to the node is cleared.
Procedure
Step 2 [no] decommission {controller | switch} Decommissions the specified node. Note that
node-id [remove-from-controller] controller node ID numbers are between 1 and
100, while switch node ID numbers are between
Example:
101 and 4000.
apic1(config)# decommission switch 104
remove-from-controller
Examples
This example shows how to perform a complete decommissioning of node 104 (a switch) and
recommission node 5 (a controller), which was decommissioned with the regular level.
apic1# configure
apic1(config)# decommission switch 104 remove-from-controller
apic1(config)# no decommission controller 5
Step 3 [no] description text Adds a description for this power supply
redundancy policy. If the text includes spaces,
Example:
it must be enclosed in single quotes.
apic1(config-power)# description 'This
is my power redundancy policy'
Examples
This example shows how to configure a power supply redundancy policy for the ps-redundant mode.
apic1# configure
apic1(config)# power redundancy-policy myPowerPolicy
apic1(config-pod)# isis fabric
apic1(config-power)# description 'This is my power redundancy policy'
apic1(config-power)# redundancy-mode ps-redundant
Configuring a Scheduler
A schedule allows operations, such as configuration import/export or tech support collection, to occur during
one or more specified windows of time.
A schedule contains a set of time windows (occurrences). These windows can be one time only or can recur
at a specified time and day each week. The options defined in the window, such as the duration or the maximum
number of tasks to be run, determine when a scheduled task will execute. For example, if a change cannot be
deployed during a given maintenance window because the maximum duration or number of tasks has been
reached, that deployment is carried over to the next maintenance window.
Each schedule checks periodically to see whether the APIC has entered one or more maintenance windows.
If it has, the schedule executes the deployments that are eligible according to the constraints specified in the
maintenance policy.
A schedule contains one or more occurrences, which determine the maintenance windows associated with
that schedule. An occurrence can be one of the following:
• Absolute (One Time) Window—An absolute window defines a schedule that will occur only once. This
window continues until the maximum duration of the window or the maximum number of tasks that can
be run in the window has been reached.
• Recurring Window—A recurring window defines a repeating schedule. This window continues until the
maximum number of tasks or the end of the day specified in the window has been reached.
Procedure
Step 3 [no] description text Adds a description for this scheduler. If the
text includes spaces, it must be enclosed in
Example:
single quotes.
apic1(config-scheduler)# description
'This is my scheduler'
Step 4 [no] absolute window window-name Creates an absolute (one time) window
schedule.
Example:
apic1(config-scheduler)# absolute window
myAbsoluteWindow
Step 6 [no] max running time time Sets the maximum running time for tasks in
the format dd:hh:mm:ss. The range is 0 to
Example:
65535. Set to 0 for no time limit.
apic1(config-scheduler-absolute)# max
running time 00:01:30:00
Step 7 [no] time start time Sets the starting time in the format
[[[yyyy:]mmm:]dd:]HH:MM.
Example:
apic1(config-scheduler-absolute)# time
start 2016:jan:01:12:01
Step 10 [no] max concurrent nodes count Sets the maximum number of nodes (tasks)
that can be processed concurrently. The range
Example:
is 0 to 65535. Set to 0 for unlimited nodes.
apic1(config-scheduler-recurring)# max
concurrent nodes 300
Step 11 [no] max running time time Sets the maximum running time for tasks in
the format dd:hh:mm:ss. The range is 0 to
Example:
65535. Set to 0 for no time limit.
apic1(config-scheduler-recurring)# max
running time 00:01:30:00
Step 12 [no] time start {daily HH:MM | weekly (See Sets the period (daily or weekly) and starting
usage) HH:MM} time. If weekly is selected, choose from these
options:
Example:
apic1(config-scheduler-recurring)# time • monday
start weekly wednesday 12:30
• tuesday
• wednesday
• thursday
• friday
• saturday
Examples
This example shows how to configure a recurring scheduler to run every Wednesday.
apic1# configure
apic1(config)# scheduler controller schedule myScheduler
apic1(config-scheduler)# description 'This is my scheduler'
apic1(config-scheduler)# recurring window myRecurringWindow
apic1(config-scheduler-recurring)# max concurrent nodes 300
apic1(config-scheduler-recurring)# max running time 00:01:30:00
apic1(config-scheduler-recurring)# time start weekly wednesday 12:30
Step 2 [no] system jumbomtu size Sets the maximum transmit unit (MTU) for host
facing ports. Up to Cisco APIC Release 3.1(2),
Example:
the range is 576 to 9000 bytes. From release
apic1(config)# system jumbomtu 9000 3.1(2), and later, the maximum MTU value is
9216. The default has not changed from 9000.
Examples
This example shows how to configure the system MTU size.
About PTP
Precision Time Protocol (PTP) is a time synchronization protocol defined in IEEE 1588 for nodes distributed
across a network. With PTP, it is possible to synchronize distributed clocks with an accuracy of less than 1
microsecond via Ethernet networks. PTP’s accuracy comes from the hardware support for PTP in the ACI
fabric spines and leafs. It allows the protocol to accurately compensate for message delays and variation across
the network.
PTP is a distributed protocol that specifies how real-time PTP clocks in the system synchronize with each
other. These clocks are organized into a master-slave synchronization hierarchy with the grandmaster clock,
which is the clock at the top of the hierarchy, determining the reference time for the entire system.
Synchronization is achieved by exchanging PTP timing messages, with the members using the timing
information to adjust their clocks to the time of their master in the hierarchy. PTP operates within a logical
scope called a PTP domain.
The PTP process consists of two phases: establishing the master-slave hierarchy and synchronizing the clocks.
Within a PTP domain, each port of an ordinary or boundary clock follows this process to determine its state:
• Examines the contents of all received announce messages (issued by ports in the master state).
• Compares the data sets of the foreign master (in the announce message) and the local clock for priority,
clock class, accuracy, and so on.
• Determines its own state as either master or slave.
After the master-slave hierarchy has been established, the clocks are synchronized as follows:
• The master sends a synchronization message to the slave and notes the time it was sent.
• The slave receives the synchronization message and notes the time that it was received. For every
synchronization message, there is a follow-up message. Hence, the number of sync messages should be
equal to the number of follow-up messages.
• The slave sends a delay-request message to the master and notes the time it was sent.
• The master receives the delay-request message and notes the time it was received.
• The master sends a delay-response message to the slave. The number of delay request messages should
be equal to the number of delay response messages.
• The slave uses these timestamps to adjust its clock to the time of its master.
In ACI fabric, when PTP feature is globally enabled in APIC, the software automatically enables PTP on
specific interfaces of all the supported spines and leafs. This auto-configuration ensures that PTP is optimally
enabled on all the supported nodes. In the absence of an external grandmaster clock, one of the spine switch
is chosen as the grandmaster. The master spine is given a different PTP priority as compared to the other
spines and leaf switches so that they will act as PTP slaves. This way we ensure that all the leaf switches in
the fabric synchronize to the PTP clock of the master spine.
If an external Grandmaster clock is connected to the spines, the spine syncs to the external GM and in turn
acts as a master to the leaf nodes.
Parameters Default
PTP domain 0
PTP VLAN 1
Note PTP operates only in boundary clock mode. Cisco recommends deployment of a Grand Master Clock (10
MHz) upstream, with servers containing clocks requiring synchronization connected to the switch.
PTP Verification
Command Purpose
show ptp clock Displays the properties of the local clock, including
clock identity.
show ptp clock foreign-masters record interface Displays the state of foreign masters known to the
ethernet slot/port PTP process. For each foreign master, the output
displays the clock identity, basic clock properties, and
whether the clock is being used as a grandmaster.
show ptp counters [all |interface Ethernet slot/port] Displays the PTP packet counters for all interfaces or
for a specified interface.
• Latency measurement and PTP are only supported on the following switches:
• N9K-C93108TC-EX
• N9K-C93108TC-FX
• N9K-C93180LC-EX
• N9K-C93180YC-EX
• N9K-C93180YC-FX
• N9K-C9364C
• N9K-X9732C-EX
• N9K-X9736C-EX
• N9K-X9736C-FX
• Latency measurement is supported only for the packets that ingress, egress, and transit through EX or
FX-based TORs.
• All the spine nodes in the fabric should have EX or FX-based line cards to support PTP.
• PTP and the latency feature is not supported on any N9K-C93128TX, N9K-C9396PX, and N9K-C9396TX
TORs or spine switches. In the presence of non-EX/FX TORs in the fabric, we recommend that you have
the external GM connectivity to all the spine switches to ensure that the PTP time is synced across all
the supported TORs.
• External Grandmaster (GM) clock is not mandatory for PTP in a single Pod. If there is no external GM
connected to the ACI fabric, one of the spine nodes acts as the GM. This spine switch has a PTP priority1
value as 254. All the other spine switches and leaf switches in the fabric will synchronize their clock to
this Master spine switch clock. If the external GM is connected later to the spine switch, it should have
a priority value less than 254 for it to act as the GM for the entire fabric.
• External Grandmaster clock is mandatory for PTP in a multipod scenario. In addition, external GM needs
to be connected to the IPN such that the Grandmaster clock is the master to the spine switches in different
PODs. The spine switches connected to IPN will act as the boundary clock and all the nodes within the
POD will sync their clock this spine switch.
• PTP operates only in boundary clock mode. End-to-end transparent clock and peer-to-peer transparent
clock modes are not supported.
• PTP supports transport over User Datagram Protocol (UDP). Transport over Ethernet is not supported.
• PTP supports multicast communication only; unicast mode is not supported.
• Beginning with release 4.0(1), support is added for changing the resolution factor to 11 which then can
measure up to 214 milliseconds with an accuracy of 204ns.
leaf1#
leaf1#
leaf1# show ptp clock
PTP Device Type: Boundary clock
Clock Identity : 0c:75:bd:ff:fe:03:1d:10
Clock Domain: 0
Number of PTP ports: 1
Priority1 : 255
Priority2 : 255
Clock Quality:
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset From Master : 32
Mean Path Delay : 128
Steps removed : 1
Local clock time:Thu Jul 27 19:43:42 2017
leaf1#
leaf1# show ptp clock foreign-masters record interface ethernet 1/49
leaf1#
leaf1#
leaf1# show ptp corrections
leaf1#
leaf1#
leaf1# show ptp parent
Parent Clock:
Parent Clock Identity: d4:6d:50:ff:fe:e6:4d:3f
Parent Port Number: 258
Observed Parent Offset (log variance): N/A
Observed Parent Clock Phase Change Rate: N/A
Grandmaster Clock:
Grandmaster Clock Identity: d4:6d:50:ff:fe:e6:4d:3f
Grandmaster Clock Quality:
Class: 248
Accuracy: 254
Offset (log variance): 65535
Priority1: 254
Priority2: 255
leaf1#
Cumulative
+--------------------+----------------+--------------------+
| Average (microsec) | Max (microsec) | Total Packet Count |
+--------------------+----------------+--------------------+
| 18 | 202 | 6117438 |
| | | |
+--------------------+----------------+--------------------+
Overview
This article provides examples of how to configure Cisco Tetration when using the Cisco APIC. The following
information applies when configuring Cisco Tetration.
• An inband management IP address must be configured on each leaf where the Cisco Tetration agent is
active.
• Define an analytics policy and specify the destination IP address of the Cisco Tetration server.
• Create a switch profile and include the policy group created in the previous step.
Step 5 exit
Exit command mode.
Example:
# apic1(config-analytics-cluster-exporter)# exit
Step 6 exit
Exit command mode.
Example:
apic1(config-analytics)# exit
Step 7 fabric-internal
Enters fabric internal configuration mode.
Example:
apic1(config)# fabric-internal
Step 10 exit
Exit command mode.
Example:
apic1(config-leaf-policy-group)# exit
Example:
apic1# show analytics
Cluster : cluster1
Config Server Name : server1
Destination IP : 192.0.2.1
Destination Port : unspecified
DSCP : VA
About NetFlow
The NetFlow technology provides the metering base for a key set of applications, including network traffic
accounting, usage-based network billing, network planning, as well as denial of services monitoring, network
monitoring, outbound marketing, and data mining for both service providers and enterprise customers. Cisco
provides a set of NetFlow applications to collect NetFlow export data, perform data volume reduction, perform
post-processing, and provide end-user applications with easy access to NetFlow data. If you have enabled
NetFlow monitoring of the traffic flowing through your datacenters, this feature enables you to perform the
same level of monitoring of the traffic flowing through the Cisco Application Centric Infrastructure (Cisco
ACI) fabric.
Instead of hardware directly exporting the records to a collector, the records are processed in the supervisor
engine and are exported to standard NetFlow collectors in the required format.
For information about configuring NetFlow with virtual machine networking, see the Cisco ACI Virtualization
Guide.
Note NetFlow is only supported on EX switches. See the Cisco NX-OS Release Notes for Cisco Nexus 9000 Series
ACI-Mode Switches document for the release that you have installed for a list of the supported EX switches.
Procedure
Procedure
Example:
apic1(config-node)# end
Procedure
Procedure
You can have one monitor policy per address family (IPv4 and IPv6).
You can have one monitor policy per address family (IPv4 and IPv6). The interfaces can also be vPCs.
Procedure
You can have one monitor policy per address family (IPv4 and IPv6). The interfaces can also be vPCs.
Procedure
Step 2 Create a tenant and bridge domain, and add them to a VRF.
Example:
apic1(config)# tenant tn2
apic1(config-tenant)# vrf context vrf2
apic1(config-tenant-vrf)# exit
apic1(config-tenant)# bridge-domain bd2
apic1(config-tenant-bridge-domain)# vrf member vrf2
apic1(config-tenant-bridge-domain)# exit
apic1(config-tenant)# bridge-domain bd3
apic1(config-tenant-bridge-domain)# vrf member vrf2
apic1(config-tenant-bridge-domain)# exit
Step 3 Create an application endpoint group behind which the exporter resides.
Example:
apic1(config-tenant)# application ap2
apic1(config-tenant-app)# epg epg2
apic1(config-tenant-app)# bridge-domain member bd2
apic1(config-tenant-app-bridge-domain)# exit
apic1(config-tenant-app)# exit
Step 4 Create a second application endpoint group behind which the exporter resides.
Example:
apic1(config-tenant)# application ap3
apic1(config-tenant-app)# epg epg3
apic1(config-tenant-app)# bridge-domain member bd3
apic1(config-tenant-app-bridge-domain)# exit
apic1(config-tenant-app)# exit
You can have one monitor policy per address family (IPv4 and IPv6). The interfaces can also be vPCs.
In the following commands, the destination endpoint group is the endpoint group that the exporter sits behind,
which in this case is an external Layer 3 endpoint group.
apic1(config)# flow exporter tnExporter2
apic1(config-flow-exporter)# transport udp 9990
apic1(config-flow-exporter)# destination address 2001:db5:a0c:1f0::2
apic1(config-flow-exporter)# destination external-l3 epg tenant tn2 vrf v2 epg accounting-inst
apic1(config-flow-exporter)# vrf member tenant tn2 vrf vrf2
apic1(config-flow-exporter)# version v5
apic1(config-flow-exporter)# source address 2001:db8:a0b:12f0::1
apic1(config-flow-exporter)# exit
Step 10 Add VLANs to the VLAN domain and configure a VRF for a leaf node.
Example:
apic1(config)# vlan-domain dom1
apic1(config-vlan)# vlan 5-100
apic1(config-vlan)# exit
apic1(config)# leaf 101
apic1(config-leaf)# vrf context tenant tn2 vrf vrf2
apic1(config-leaf-vrf)# exit
Procedure
Procedure
apic1(config-tenant)# exit
apic1(config)# exit
Step 2 (Optional) If you no longer want to use NetFlow, disable the feature:
Example:
apic1(config-tenant-app-epg-domain)# no flow monitor enable
Managing Firmware
Each firmware image includes a compatibility catalog that identifies supported types and switch models. APIC
maintains a catalog of the firmware images, switch types, and models that are allowed to use that firmware
image. The default setting is to reject a firmware update when it does not conform to the compatibility catalog.
APIC has an image repository for compatibility catalogs, controller firmware images, and switch images. The
administrator can download new firmware image to the APIC image repository from an external HTTP server
or SCP server.
Note Before you upgrade the switches, the APICs must have completed upgrading and have a health state of Fully
Fit.
Examples
Procedure
Examples
This example shows how to select a catalog firmware version from the repository.
apic1# configure
apic1(config)# firmware
apic1(config-firmware)# catalog-version aci-catalog-dk9.1.2.1b.bin
Procedure
Step 5 firmware-version firmware-name Specifies the desired version for the upgrade.
Example:
Step 6 [no] time start time Sets the starting time in the format
[[[yyyy:]mmm:]dd:]HH:MM. The date is
Example:
optional.
apic1(config-firmware-controller)# time
start 2016:jan:01:12:01 Note To upgrade the controllers
immediately, return to EXEC mode
and type the command firmware
upgrade controller-group .
Examples
This example shows how to upgrade the controllers.
ID Address In-Band Address OOB Address Version Flags Serial Number Health
apic1# configure
apic1(config)# firmware
apic1(config-firmware)# show version
Role Id Name Version
---------- ---------- ----------------- -----------
controller 1 apic1 1.2(1a)
controller 2 apic2 1.2(1a)
controller 3 apic3 1.2(1a)
leaf 101 leaf1 n9000-11.2(1a)
leaf 102 leaf2 n9000-11.2(1a)
leaf 103 leaf2 n9000-11.2(1a)
spine 201 spine1 n9000-11.2(1a)
spine 202 spine2 n9000-11.2(1a)
apic1(config-firmware)# controller-group
apic1(config-firmware-controller)# firmware-version aci-apic-dk9.1.2.1b.iso
apic1(config-firmware-controller)# time start 2016:jan:01:12:01
Note Before you upgrade the switches, the APICs must have completed upgrading and have a health state of Fully
Fit.
Procedure
Step 3 [no] switch-group group-name Creates (or deletes) switch group and enters
switch upgrade configuration mode.
Example:
apic1(config-firmware)# switch-group
mySwitchGroup5
Step 6 [no] run-mode {pause-never | Species whether to proceed to the next set of
pause-on-failure} nodes if the upgrade fails on the current set of
nodes.
Example:
apic1(config-firmware-switch)# run-mode
pause-on-failure
Step 8 [no] scheduler pause Pauses the maintenance policy scheduler. Use
the [no] prefix to resume.
Example:
apic1(config-firmware-switch)# scheduler
pause
apic1(config-firmware-switch)# no
scheduler pause
Examples
This example shows how to upgrade the firmware for three leaf switches.
apic1# configure
apic1(config)# firmware
apic1(config-firmware)# switch-group mySwitchGroup5
apic1(config-firmware-switch)# switch leaf1,leaf3,leaf6
apic1(config-firmware-switch)# no switch leaf4,leaf5
apic1(config-firmware-switch)# firmware-version aci-apic-dk9.1.1.3f.bin
apic1(config-firmware-switch)# run-mode pause-on-failure
apic1(config-firmware-switch)# schedule myNextSunday
apic1(config-firmware-switch)# show run
# Command: show running-config firmware switch-group mySwitchGroup5
# Time: Fri Nov 6 23:55:35 2015
firmware
switch-group mySwitchGroup5
switch 101
switch 102
switch 103
switch 106
schedule myNextSunday
exit
exit
Exporting a Snapshot
Before you begin
If you want to export snapshots according to a schedule, configure a scheduler before configuring the export
policy.
Procedure
Step 3 format {xml | json} Specifies the data format for the exported
configuration file. The default is
Example:
apic1(config-export)# format json
Step 4 (Optional) [no] schedule schedule-name Specifies an existing scheduler for exporting
snapshots.
Example:
apic1(config-export)# schedule
EveryEightHours
Step 5 (Optional) [no] target [infra | fabric | Assigns the target of the export, which can be
tenant-name] fabric, infra, a specific tenant, or none. If no
target is specified, all configuration information
Example:
is exported. The default is no target.
apic1(config-export)# target
tenantExampleCorp
Step 6 (Optional) [no] remote path remote-path-name Specifies the name of a configured remote path
to which the file will be sent. If no remote path
Example:
is specified, the file is exported locally to a
apic1(config-export)# remote path folder in the controller. The default is no remote
myBackupServer
path.
Step 8 Required: trigger snapshot export Executes the snapshot export task. If the export
policy-name policy is configured with a scheduler, this step
is unnecessary unless you want an immediate
Example:
export.
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
Importing a Snapshot
Procedure
Step 2 [no] snapshot import policy-name Creates a policy for importing snapshots.
Example:
apic1(config)# snapshot import
myImportPolicy
Step 5 [no] mode {atomic | best-effort} Specifies how the import process handles
configuration errors when applying the imported
Example:
settings. The best-effort import mode allows
apic1(config-import)# mode atomic skipping individual configuration errors in the
archive, while atomic mode cancels the import
upon any configuration error.
Step 6 (Optional) [no] remote path remote-path-name Specifies the name of a configured remote path
from which the file will be imported. If no
Example:
remote path is specified, the file is imported
apic1(config-import)# remote path locally from a folder in the controller. The
myBackupServer
default is no remote path.
Step 8 Required: trigger snapshot import Executes the snapshot import task.
policy-name
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# 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
Procedure
Step 2 [no] snapshot rollback policy-name Creates a policy for rollback using snapshots.
Example:
apic1(config)# snapshot rollback
myRollbackPolicy
Step 7 Required: trigger snapshot rollback Executes the snapshot rollback task.
policy-name
Example:
apic1# trigger snapshot rollback
myRollbackPolicy
Examples
This example shows how to configure and execute a rollback without previewing it first.
File : ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
Created : 2015-11-21T09:00:24.025+00:00
Root :
Size : 23588
apic1# configure
apic1(config)# snapshot rollback myRollbackPolicy
apic1(config-rollback)# first-file ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
apic1(config-rollback)# second-file ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
apic1(config-rollback)# end
apic1# trigger snapshot rollback myRollbackPolicy
Procedure
Step 2 [no] snapshot {upload | download} Creates a policy for uploading or downloading
policy-name remote-path-name snapshot files with a remote path.
Example:
apic1(config)# snapshot upload myUpPolicy
Step 3 remote path remote-path-name Specifies the name of a configured remote path
to which the snapshot file will be sent.
Example:
apic1(config-upload)# remote path
myBackupServer
Step 6 trigger snapshot {upload | download} Executes the snapshot upload or download task.
policy-name
Example:
apic1# trigger snapshot upload myUpPolicy
Examples
This example shows how to configure and execute the uploading of a snapshot file to a remote path.
apic1# configure
apic1(config)# snapshot upload myUpPolicy
apic1(config-upload)# remote path myBackupServer
apic1(config-upload)# file ce2_DailyAutoBackup-2015-11-21T01-00-17.tar.gz
apic1(config-upload)# end
apic1# trigger snapshot upload myUpPolicy
Command Description
clear snapshot file filename Removes a snapshot file from the local storage.
clear snapshot job job-name Removes a snapshot job from the history.
Examples
This example shows how to display snapshot files and the snapshot job history.
File : ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
Created : 2015-11-21T09:00:24.025+00:00
Root :
Size : 23588
Type : export
Run : 2015-11-21T09-00-21
State : success
Details : Success
File Name : ce2_DailyAutoBackup-2015-11-21T09-00-21.tar.gz
Type : rollback
Run : 2015-11-22T00-25-06
State : running
Details :
File Name : not applicable
Configuring Syslog
Configuring a Logging Server Group
In the ACI fabric, one or more logging server-groups can be configured with one or more logging destination
servers.
Procedure
Step 4 [no] console [severity {alerts | critical | Enables logging to the console (only for
emergencies}] switches) and optionally sets the minimum
severity level for logging.
Example:
apic1(config-logging)# console severity
critical
Step 5 [no] logfile [severity {alerts | critical | Enables logging to the logfile and optionally
debugging | emergencies | errors | sets the minimum severity level for logging.
information | notifications | warnings}]
Example:
apic1(config-logging)# logfile severity
critical
Step 6 [no] server ip-address-or-hostname [facility Adds a destination logging server and optionally
local-level] [severity severity-level] [mgmtepg sets the minimum severity level for logging.
{inb | oob}] [port port-number]
• facility —Local facility in the form local
Example: n
apic1(config-logging)# server
reach.example.com level local4 mgmtepg
• severity —Minimum severity level for
inb port 514 logging. Can be one of the options shown
in the logfile command.
• mgmt —Management endpoint group,
either inb (inband) or oob (out of band).
• port —Service port number of the logging
server.
Examples
This example shows how to configure a syslog destination server group.
apic1# configure
apic1(config)# logging server-group myLoggingGroup
apic1(config-logging)# logging description "This is my logging server group"
apic1(config-logging)# console severity critical
apic1(config-logging)# logfile severity critical
apic1(config-logging)# server reach.example.com level local4 mgmtepg inb port 514
What to do next
Configure syslog with this logging server group as the logging destination.
Configuring Syslog
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.
Procedure
Step 3 [no] logging description text Adds descriptive text about the policy.
Example:
apic1(config-syslog)# logging description
"This is the common logging policy"
Step 4 [no] logging severity {alerts | critical | Specifies the minimum severity level for
debugging | emergencies | errors | sending syslog messages.
information | notifications | warnings}
Example:
apic1(config-syslog)# logging severity
notifications
Step 5 [no] logging server-group server-group-name Specifies a destination logging server group.
Example:
apic1(config-syslog)# logging
server-group myLoggingGroup
Examples
This example shows how to configure syslog for messages of 'notification' severity or higher. Syslog
messages from fault and event logs are sent to servers in server-group myLoggingGroup.
apic1# configure
apic1(config)# syslog common
apic1(config-syslog)# logging description "This is the common logging policy"
apic1(config-syslog)# logging severity notifications
apic1(config-syslog)# logging server-group myLoggingGroup
apic1(config-syslog)# logging audit
apic1(config-syslog)# logging event
Procedure
Step 6 [no] logging severity {alert | critical | debug Specifies the minimum severity level for
| emergency | error | info | notice | warning} logging.
Example:
apic1(config-callhome)# logging severity
notice
Examples
This example shows how to configure a basic Call Home policy.
apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# logging event
apic1(config-callhome)# logging fault
apic1(config-callhome)# logging severity notice
apic1(config-callhome)# periodic-inventory notification schedule EveryEightHours
apic1(config-callhome)# end
apic1# show callhome common
Callhome : common
Destination-Profile :
Query-Profile :
Query Name Query Type Dn/Class Target Respones Subtree Response Include
----------- ---------- -------- ------ ----------------
------------------------------
myUserQuery class User self children
ep-records,fault-records,stats
What to do next
Configure a destination profile and (optionally) a query profile.
Procedure
Step 4 [no] destination dest-name Configures a destination where the Call Home
messages will be sent, including the format of
Example:
the messages and the severity level for sending.
apic1(config-callhome-destnprof)#
destination SanJose Note You can configure more than one
destination.
Step 5 [no] email-addr email Configures the e-mail address that will receive
the Call Home messages. Up to 255
Example:
alphanumeric characters are accepted in e-mail
apic1(config-callhome-destnprof-destn)# address format.
email-addr [email protected]
Step 7 [no] message-level {alert | critical | debug | Configures the minimum severity level for
emergency | error | info | notice | warning} sending messages.
Example:
apic1(config-callhome-destnprof-destn)#
message-level alert
Step 8 [no] message-size size Configures the size of the messages. The range
is 0 to 5000000 characters.
Example:
apic1(config-callhome-destnprof-destn)#
message-size 40000
Step 10 Configure the destination profile. Use the commands in Call Home Destination
Profile Configuration Commands, on page 484
Example:
apic1(config-callhome-destnprof)#
(various commands)
Examples
This example shows how to configure Call Home to send email messages of severity 'alert' or higher
to [email protected].
apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# destination-profile
apic1(config-callhome-destnprof)# destination SanJose
apic1(config-callhome-destnprof-destn)# email-addr [email protected]
apic1(config-callhome-destnprof-destn)# format xml
apic1(config-callhome-destnprof-destn)# message-level alert
apic1(config-callhome-destnprof-destn)# message-size 40000
apic1(config-callhome-destnprof-destn)# exit
apic1(config-callhome-destnprof)# contract-id 12345678
apic1(config-callhome-destnprof)# customer-id ABCDEFG
apic1(config-callhome-destnprof)# description "Example Corporation"
apic1(config-callhome-destnprof)# site-id XYZ123
apic1(config-callhome-destnprof)# street-address "1 Cisco Way"
apic1(config-callhome-destnprof)# phone-contact +14085551212
apic1(config-callhome-destnprof)# email-contact [email protected]
apic1(config-callhome-destnprof)# transport email from [email protected]
apic1(config-callhome-destnprof)# transport email reply-to [email protected]
apic1(config-callhome-destnprof)# transport email mail-server smtp.example.com mgmtepg inb
port 25
apic1(config-callhome)# end
apic1# show callhome common transport-email
From email-addr : [email protected]
SMTP Port num : 25
Command Purpose
contract-id contract-id The Call Home contract number for the customer.
customer-id customer-id The CCO ID that includes the contract numbers for the support
contract in its entitlements.
site-id site-id The unique Call Home identification number for the customer
site.
transport email from email The email address that should appear in the From field on Call
Home alert messages sent by the system.
transport email reply-to email The return email address that should appear in the From field
on Call Home alert messages sent by the system.
transport email mail-server smtp-server The IP address or hostname of the SMTP server and the port
mgmtepg {inb | oob} port port-number number the system should use to talk to the SMTP server.
Procedure
Step 4 [no] query query-name type {class class-name Configures a query profile.
| dn name}
Example:
apic1(config-callhome-queryprof)# query
myUserQuery type class User
Step 5 [no] response-subtree {full | children | no} Configures the response subtree. You can
choose to include the full subtree, only children,
Example:
or no subtree information.
apic1(config-callhome-queryprof-query)#
response-subtree children
Step 7 [no] target {children | self | subtree} Configures the query target.
Example:
Examples
This example shows how to configure a Call Home query.
apic1# configure
apic1(config)# callhome common
apic1(config-callhome)# query-profile
apic1(config-callhome-queryprof)# query myUserQuery type class User
apic1(config-callhome-queryprof-query)# response-subtree children
apic1(config-callhome-queryprof-query)# response-incl ep-records,fault-records,stats
apic1(config-callhome-queryprof-query)# target self
apic1(config-callhome)# end
apic1# show callhome common destination-profile
Query-Profile :
Query Name Query Type Dn/Class Target Respones Subtree Response Include
----------- ---------- -------- ------ ----------------
------------------------------
myUserQuery class User self children
ep-records,fault-records,stats
add-mo-list
audit-logs
config-only
count
custom-path-hop
deployment
deployment-records
ep-records
event-logs
fault-count
fault-records
faults
full-deployment
health
health-records
local-prefix
no-scoped
none
port-deployment
record-subtree
relations
relations-with-parent
required
state
stats
tasks
Note You must have administrator rights to access the TACACS External Logging commands in the NX-OS-style
CLI.
The following example CLI commands show how to configure a TACACS destination group and destination
using the NX-OS-style CLI:
Procedure
Note You can have logs sent to multiple ports on the same IP address by including additional port numbers
after the port keyword.
Step 4 Configure specific parameters for the new remote TACACS destination.
Example:
In the following command example, the following characteristics are configured for the new remote destination:
• Authentication key: 12345
• Authentication protocol: MS-CHAP
• Management EPG: Out-of-Band
apic1(config-remote-dest)# key
Enter Key: 12345
Enter Key again: 12345
apic1(config-remote-dest)# protocol mschap
apic1(config-remote-dest)# management-epg oob
The result of this configuration is the creation of a TACACS destination group containing a remote TACACS
server destination. If you want the same AAA logging data sent to multiple remote TACACS servers, you
can repeat steps 3 and 4 as many times as needed.
data is sent. For example, if you create the TACACS source in Fabric Policies, all AAA logging data for the
Cisco Application Centric Infrastructure (Cisco ACI) fabric supported by Cisco Application Policy Infrastructure
Controller (Cisco APIC) is sent to the associated TACACS destinations. You can create one or more sources
to support different destination groups.
The following example CLI commands show how to configure a TACACS source using the NX-OS-style
CLI:
Procedure
The result of this configuration is the creation of a TACACS source for the entire fabric and the association
of a destination group containing a remote TACACS server destination. All AAA logging data for the entire
fabric is then sent to the associated TACACS destination(s).
Note Do not trigger tech support 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 tech support files promptly.
Procedure
Step 2 trigger techsupport host host-id Triggers the export of a tech support file from
the specified host to the remote host. If no
Example:
remote host is specified, the file is collected in
apic1# trigger techsupport host the controller itself.
Step 3 trigger techsupport local Triggers the export of a local tech support file
to the remote host. If no remote host is
Example:
specified, the file is collected in the controller
apic1# trigger techsupport local itself.
Step 4 show techsupport {all | controllers switch After a tech support file is triggered, this
node-id} status command shows the status of the tech support
report.
Example:
apic1# show techsupport switch 101 status
Examples
This example shows how to trigger a tech support file for switch 101, to be stored locally on the
apic1 controller.
Triggering techsupport for Switch 101 using policy supNode101, setting filters to default
value
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.
Procedure
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] Sets the path and protocol to the remote server.
[remote-directory ] 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:
Broad queries are expensive in terms of system resources and storage. For example, using the show faults,
events, or audit commands without entity filters retrieves all logs or records from the entire system. We
recommend that you make use of the available data and entity filters to narrow your query as much as possible.
For example, the following command would result in a quicker and more filtered response by limiting the
query to the most recent 45 minute period:
show audits last-minutes 45
Tip At each point in the command, typing ‘ ?’ displays all possible keywords and options that can be used at that
point along with a brief explanation of each.
Filter Description
id fault-id fault ID
Filter Description
Examples
This example shows all faults that occurred in the past five days with code “F110473”, severity “warning”,
lifecycle “raised” and acknowledgment status “no” for the tenant TSW_Tenant0.
apic1# show faults code F110473 last-days 5 severity warning lc raised ack no tenant
TSW_Tenant0
Code : F110473
Severity : warning
Last Transition : 2015-11-03T01:19:04.913+00:00
Lifecycle : raised
DN : uni/tn-TSW_Tenant0/BD-tsw0ctx0BD1/fault-F110473
Description : TCA: ingress drop bytes rate(l2IngrBytesAg15min:dropRate)
value 160462 raised above threshold 100000
Filter Description
Filter Description
id event-id event ID
Examples
This example shows all events on leaf 101.
Severity : info
Affected Object : topology/pod-1/node-101/sys/phys-[eth1/28]
Code : E4208843
ID : 8589934758
Cause : transition
Description : PhysIf eth1/28 modified
Creation Time : 2015-11-03T01:11:16.763+00:00
Filter Description
Filter Description
Examples
This example shows a brief health report for all tenants.
This example shows all historical health records from the 4th of November that have a maximum health score
of 75 that have had a minimum change of 10% for the tenant TSW_Tenant0.
Filter Description
id log-id log ID
Filter Description
Examples
This example shows all audit logs in the last 45 minutes for the tenant TSW_Tenant0.
Filter Description
granularity {5min | 15min | 1h | 1d | 1w | 1mo | 1qtr the sampling interval size which can be 5 minutes, 15
| 1year} minutes, 1 hour, 1 day, 1 week, 1 month, 1 quarter,
or 1 year
Examples
This example shows 15 minute granularity statistics for the tenant TSW_Tenant0.
apic1# show stats granularity 15min leaf 101 interface ethernet 1/1
Filter
controller
leaf node-id interface [ethernet slot/port | l3instance [instance-name] | mgmt [mgmt0] | portchannel |
tunnel [tunnel-name]]
leaf node-id inventory {chassis [number] | fans [number] | module [number] | powersupply [number] |
supervisor [number]}
leaf node-id protocol {arp | bgp | coop | ipv4 | ipv6 | isis | lldp | ospf | ospfv3}
spine node-id
spine node-id interface [ethernet slot/port | l3instance [instance-name] | mgmt [mgmt0] | tunnel
[tunnel-name]]
spine node-id inventory {chassis [number] | fabric [number] | fans [number] | module [number] |
powersupply [number] | supervisor [number] | system [number]}
spine node-id protocol {arp | bgp | coop | ipv4 | ipv6 | isis | lldp | ospf | ospfv3}
tenant tenant-name
Configuring SNMP
Before you begin
To allow SNMP communications, you must configure an out-of-band contract allowing SNMP traffic, which
is normally on UDP:161.
Procedure
Step 3 [no] snmp-server protocol enable Enables (or disables) SNMP protocol support.
Example:
apic1(config-template-snmp-fabric)#
snmp-server protocol enable
Step 4 [no] snmp-server community The community is required for SNMPv2 only.
community-name
Example:
apic1(config-template-snmp-fabric)#
snmp-server community mysecret
Step 6 snmp-server location location-name Sets the location for the SNMP server.
Example:
apic1(config-template-snmp-fabric)#
snmp-server location SanJose
Examples
The following example configures an out-of-band contract allowing SNMP traffic in the fabric.
apic1# configure
apic1(config)# template snmp-fabric Pol1
apic1(config-template-snmp-fabric)# snmp-server protocol enable
apic1(config-template-snmp-fabric)# snmp-server community mysecret
apic1(config-template-snmp-fabric)# snmp-server contact admin80
apic1(config-template-snmp-fabric)# snmp-server location SanJose
apic1(config-template-snmp-fabric)# exit
apic1(config)# template pod-group allPods
apic1(config-pod-group)# inherit snmp-fabric Pol1
apic1(config-pod-group)# exit
apic1(config)#
Procedure
apic1# configure
apic1(config-template-snmp-fabric)#
snmp-server host 2001:420:28e:2020::10
traps-version 2c abc
apic1(config-template-snmp-fabric)#
snmp-server host 2001:420:28e:2020::2
traps-version 2c abc
apic1(config-template-snmp-fabric)#
snmp-server host 2001:420:28e:2020::11
traps-version 2c abc
apic1(config-template-snmp-fabric)#
snmp-server protocol enable
apic1(config-template-snmp-fabric)#
snmp-server trap-fwd-server
172.31.128.199
The fault triggers that are typical of the Smart Callhome feature correspond to the kind of events that threaten
to disrupt your network. Examples are:
• Temperature Faults: The temperature of a sensor exceeds a threshold.
• Fan/ Power Supply Faults: A fan or power supply unit goes offline.
• Disk Utilization Faults: The disk usage of a device exceeds a threshold.
Smart Callhome collects faults and emails them to a network support engineer, a Network Operations Center,
or to Cisco Smart Callhome services to generate a case with the Technical Assistance Center (TAC).
Procedure
Note The default name for the common policy configuration mode is "common". It is the only name that
can be created.
Step 5 Configure profile parameters about the new Smart Callhome destination group.
Example:
The following commands provide additional information about the destination group:
• contract-id: The service contract ID of the customer.
• customer-id: The customer ID.
• description: A description for the Smart Callhome destination profile.
• email-contact: The customer contact e-mail address.
• phone-contact: The customer contact phone number.
• site-id: The ID of the site where the network is deployed.
• street-address: The street address of the site.
Step 7 Configure specific parameters for the new remote Smart Callhome destination.
Example:
In the following command example, the following characteristics are configured for the new remote destination:
• Email address: [email protected]
• Message format: Short text
• RFC Compliant: True
The result of this configuration is the creation of a Smart Callhome destination group containing a remote
email destination. If you want the same Smart Callhome fault data sent to multiple email destinations, you
can repeat steps 5 and 6 as many times as needed.
The following table shows the different configuration elements for each session.
Access Local Access Ports, Port-channels local to one EPG Port local to same leaf as
leaf sources
Access ERSPAN Access Ports, Port-channels, VPCs EPG EPG anywhere in the fabric
among one or more leaf nodes
Fabric ERSPAN Fabric ports in one or mode leaf or spine BD or VRF EPG anywhere in the fabric
nodes
Tenant ERSPAN EPG anywhere in the fabric - EPG anywhere in the fabric
• On Generation 2 switches (with EX or FX on the switch name), Tx SPAN does not work whether
traffic is Layer 2 or Layer 3 switched.
Note While it is also possible to configure FEX fabric port-channel (NIF) member
interfaces as SPAN source interfaces on Generation 2 switches (Cisco Nexus
9000 Series switches with EX or FX on the switch name) for releases prior to
Cisco APIC Release 4.1, this is not supported.
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.
Procedure
Step 3 [no] description text Adds a description for this access monitoring
session. If the text includes spaces, it must be
Example:
enclosed in single quotes.
apic1(config-monitor-access)#
description "This is my SPAN session"
Step 4 [no] destination interface ethernet slot/port Specifies the destination interface. The
leaf node-id destination interface cannot be a FEX port or
port-channel.
Example:
apic1(config-monitor-access)#
destination interface eth 1/2 leaf 101
Step 5 [no] source interface ethernet {[fex/] Specifies the source interface port or port
slot/port | port-range} leaf node-id range.
Example:
apic1(config-monitor-access)# source
interface eth 1/2 leaf 101
Step 7 [no] filter tenant tenant-name application Filters traffic to be monitored. The filter can
application-name epg epg-name be configured independently for each source
port range.
Example:
apic1(config-monitor-access-source)#
filter tenant t1 application app1 epg
epg1
Step 9 [no] source interface port-channel Specifies the source interface port channel.
port-channel-name-list leaf node-id [fex fex-id]
(Enters the traffic direction and filter
Example: configuration, not shown here.)
apic1(config-monitor-access)# source
interface port-channel pc5 leaf 101
Examples
This example shows how to configure a local access monitoring session.
Procedure
Step 2 [no] monitor access session session-name Creates an access monitoring session
configuration.
Example:
apic1(config)# monitor access session
mySession
Step 4 [no] destination tenant tenant-name Specifies the destination interface as a tenant
application application-name epg epg-name and enters destination configuration mode.
destination-ip dest-ip-address
source-ip-prefix src-ip-address
Example:
apic1(config-monitor-access)#
destination tenant t1 application app1
epg epg1 destination-ip 192.0.20.123
source-ip-prefix 10.0.20.1
Step 5 [no] erspan-id flow-id Configures the ERSPAN ID for the ERSPAN
session. The ERSPAN range is from 1 to 1023.
Example:
apic1(config-monitor-access-dest)#
erspan-id 100
Step 7 [no] ip ttl ttl-value Configures the IP time-to-live (TTL) value for
the ERSPAN traffic. The range is from 1 to
Example:
255.
apic1(config-monitor-access-dest)# ip
ttl 16
Step 8 [no] mtu mtu-value Configures the maximum transmit unit (MTU)
size for the ERSPAN session. The range is 64
Example:
to 9216 bytes.
apic1(config-monitor-access-dest)# mtu
9216
Step 10 [no] source interface ethernet {[fex/] Specifies the source interface port or port
slot/port | port-range} leaf node-id range.
Example:
apic1(config-monitor-access)# source
interface eth 1/2 leaf 101
Step 11 [no] source interface port-channel Specifies the source interface port-channel.
port-channel-name-list leaf node-id [fex fex-id]
Step 12 [no] source interface vpc vpc-name-list leaf Specifies the source interface vPC.
node-id1 node-id2 [fex fex-id1 fex-id2]
Example:
apic1(config-monitor-access)# source
interface vpc pc1 leaf 101 102
Step 14 [no] filter tenant tenant-name application Filters traffic to be monitored. The filter can
application-name epg epg-name be configured independently for each source
port range.
Example:
apic1(config-monitor-access-source)#
filter tenant t1 application app1 epg
epg1
Examples
This example shows how to configure an ERSPAN access monitoring session.
apic1(config-monitor-access)# no shut
apic1(config-monitor-access)# show run
# Command: show running-config monitor access session mySession
# Time: Fri Nov 6 23:55:35 2015
monitor access session mySession
description "This is my ERSPAN session"
source interface eth 1/1 leaf 101
direction tx
filter tenant t1 application app1 epg epg1
exit
destination tenant t1 application app1 epg epg1 destination-ip 192.0.20.123
source-ip-prefix 10.0.20.1
ip dscp 42
ip ttl 16
erspan-id 9216
mtu 9216
exit
exit
This example shows how to configure a one leg of a vPC as a monitoring source.
This example shows how to configure a range of ports from FEX 101 as a monitoring source.
Procedure
Step 2 [no] monitor fabric session session-name Creates a fabric monitoring session
configuration.
Example:
apic1(config)# monitor fabric session
mySession
Step 4 [no] destination tenant tenant-name Specifies the destination interface as a tenant
application application-name epg epg-name and enters destination configuration mode.
destination-ip dest-ip-address
source-ip-prefix src-ip-address
Example:
apic1(config-monitor-fabric)#
destination tenant t1 application app1
epg epg1 destination-ip 192.0.20.123
source-ip-prefix 10.0.20.1
Step 5 [no] erspan-id flow-id Configures the ERSPAN ID for the ERSPAN
session. The ERSPAN range is from 1 to 1023.
Example:
apic1(config-monitor-fabric-dest)#
erspan-id 100
Step 7 [no] ip ttl ttl-value Configures the IP time-to-live (TTL) value for
the ERSPAN traffic. The range is from 1 to
Example:
255.
apic1(config-monitor-fabric-dest)# ip
ttl 16
Step 8 [no] mtu mtu-value Configures the maximum transmit unit (MTU)
size for the ERSPAN session. The range is 64
Example:
to 9216 bytes.
apic1(config-monitor-fabric-dest)# mtu
9216
Step 10 [no] source interface ethernet {slot/port | Specifies the source interface port or port
port-range} switch node-id range.
Example:
apic1(config-monitor-fabric)# source
interface eth 1/2 switch 101
Step 12 [no] filter tenant tenant-name bd bd-name Filters traffic by bridge domain.
Example:
apic1(config-monitor-fabric-source)#
filter tenant t1 bd bd1
Step 13 [no] filter tenant tenant-name vrf vrf-name Filters traffic by VRF.
Example:
apic1(config-monitor-fabric-source)#
filter tenant t1 vrf vrf1
Examples
This example shows how to configure an ERSPAN fabric monitoring session.
Procedure
Step 2 [no] monitor tenant tenant-name session Creates a tenant monitoring session
session-name configuration.
Example:
apic1(config)# monitor tenant session
mySession
Step 3 [no] description text Adds a description for this access monitoring
session. If the text includes spaces, it must be
Example:
enclosed in single quotes.
apic1(config-monitor-tenant)#
description "This is my tenant ERSPAN
session"
Step 4 [no] destination tenant tenant-name Specifies the destination interface as a tenant
application application-name epg epg-name and enters destination configuration mode.
destination-ip dest-ip-address
source-ip-prefix src-ip-address
Example:
apic1(config-monitor-tenant)#
destination tenant t1 application app1
epg epg1 destination-ip 192.0.20.123
source-ip-prefix 10.0.20.1
Step 5 [no] erspan-id flow-id Configures the ERSPAN ID for the ERSPAN
session. The ERSPAN range is from 1 to 1023.
Example:
apic1(config-monitor-tenant-dest)#
erspan-id 100
Step 8 [no] mtu mtu-value Configures the maximum transmit unit (MTU)
size for the ERSPAN session. The range is 64
Example:
to 9216 bytes.
apic1(config-monitor-tenant-dest)# mtu
9216
Step 10 [no] source application application-name epg Specifies the source interface port or port
epg-name range.
Example:
apic1(config-monitor-tenant)# source
application app2 epg epg5
Examples
This example shows how to configure an ERSPAN tenant monitoring session.
apic1(config-monitor-tenant-dest)# exit
apic1(config-monitor-tenant)# source application app2 epg epg5
apic1(config-monitor-tenant-source)# direction tx
apic1(config-monitor-tenant-source)# exit
apic1(config-monitor-tenant)# no shut
Procedure
Step 3 interface ethernet slot/port Identifies the slot number and port number for
an existing Ethernet interface.
Example:
dev4-ifc1(config-leaf)# interface
ethernet 1/34
Example
This example shows how to configure export-config.
dev4-ifc1# config
dev4-ifc1(config)# leaf 101
dev4-ifc1(config-leaf)# interface ethernet 1/34
dev4-ifc1(config-leaf-if)# export-config /tmp/showRunnLeaf101.txt
dev4-ifc1(config-leaf-if)# cat /tmp/showRunnLeaf101.txt
config
# Command: show running-config leaf 101 interface ethernet 1 / 34
# Time: Fri Sep 23 16:03:48 2016
leaf 101
interface ethernet 1/34
switchport trunk allowed vlan 602 tenant t1 external-svi l3out l3ext1sub1
exit
exit
dev4-ifc1(config-leaf-if)#
Procedure
Note With Cisco APIC Release 3.2(1), depending on your TOR switch hardware, a
Forwarding Scale Profile with the High Dual Stack option has different scales;
for example:
• For Cisco Nexus 9000 Series TOR switches with FX in the switch name,
the high dual-stack option has scalability of 48,000 IPv6 endpoints instead
of 24,000 and 128,000 policies instead of 8,000.
• For Cisco Nexus 9000 Series TOR switches with EX in the switch name,
the high dual-stack option has the same scale values as with earlier APIC
releases.
Forwarding Scale Profile Policy TOR Switches with EX Names TOR Switches with FX Names
Options
Note • Because the IPv4 forwarding scale profile policy does not support IPv6 configurations, all IPv6
configurations must be removed from switches configured with the IPv4 forwarding scale profile policy.
• Because the high dual stack profile has reduced-scale support for contract policies (8,000), the contracts
scale must be reduced accordingly prior to deploying that profile.
• Before migrating to minimal tenant multicast scale leaf profiles, such as high dual stack, we recommend
that you first disable Layer 2 IGMP snooping-, Layer 3 IGMP-, and PIM-related configurations to prevent
having a stale multicast state in your hardware.
• Applying a scale profile to a node requires a manual reload of that node. Any unsupported switches are
ignored. For a list of supported switches, see Supported Platforms for Forwarding Scale Profile Policies,
on page 523.
• VPCs associated with different scale profile settings are not supported. The VPC members must be
configured with the same scale profile settings.
Note • The switches that support the forwarding scale profile policy must be manually reloaded after the
forwarding scale profile policy is applied.
• Changing the scale profile for individual members of a VPC is not allowed. If members of the same VPC
are associated with different leaf profiles, then a new leaf profile should be created with both members
and the scale profile applied to it.
This section demonstrates how to configure the forwarding scale profile policy using the NX-OS-style CLI.
Procedure
Step 3 profile-type {dual-stack | high-dual-stack | Sets the Forwarding Scale profile type.
high-lpm | high-policy | ipv4 }
Example:
apic1(config-scale-profile)#
profile-type ipv4
Examples
This example shows how to configure the IPv4 scale profile policy.
apic1# configure
apic1(config)# scale-profile testFwdScaleProf
apic1(config-scale-profile)# profile-type ipv4
apic1(config-scale-profile)# exit
apic1(config)# template leaf-policy-group samplePolicyGrp
apic1(config-leaf-policy-group)# scale-profile testFwdScaleProf
apic1(config-leaf-policy-group)# exit
apic1(config)# leaf-profile sampleLeafProf
apic1(config-leaf-profile)# leaf-group sampleLeafGrp
apic1(config-leaf-profile)# leaf 201
apic1(config-leaf-group)# leaf-policy-group samplePolicyGrp
apic1(config-leaf-group)# show running-config scale-profile testFwdScaleProf
# Command: show running-config scale-profile testFwdScaleProf
# Time: Thu Jul 27 22:31:29 2017
scale-profile testFwdScaleProf
profile-type ipv4
exit
apic1(config-leaf-group)# show running-config template leaf-policy-group samplePolicyGrp
# Command: show running-config template leaf-policy-group samplePolicyGrp
# Time: Tue Aug 1 11:19:44 2017
template leaf-policy-group samplePolicyGrp
scale-profile testFwdScaleProf
exit
apic1(config-leaf-group)# show running-config leaf-profile sampleLeafProf
# Command: show running-config leaf-profile sampleLeafProf
# Time: Tue Aug 1 11:19:58 2017
leaf-profile sampleLeafProf
leaf-group sampleLeafGrp
leaf 201
leaf-policy-group samplePolicyGrp
exit
Separate-Config-Set
Tenants 100
VRFs 100
SPAN destinations 3
NTP servers 2
Contracts 100
DNS servers 2
Syslog servers 1
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
application server. The application server then communicates with the database server, and the traffic can
also communicate externally.
To deploy the three-tier application, you must create the required EPGs, filters, and contracts.
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.
apic1(config)# tenant t1
apic1(config-tenant)# vrf context v1
apic1(config-tenant-vrf)# contract enforce
apic1(config-tenant)# bridge-domain b1
apic1(config-tenant-bd)# vrf member v1
apic1(config-tenant)# interface bridge-domain b1
apic1(config-tenant-interface)# ip address 159.10.10.1/24 scope public
apic1(config-tenant-interface)# exit
Configure MP-BGP.
apic1(config)# bgp-fabric
apic1(config-bgp-fabric)# asn 100
apic1(config-bgp-fabric)# route-reflector spine 104,105
Configure filters.
Configure contracts.
apic1(config-tenant)# contract db
apic1(config-tenant-contract)# subject sql
apic1(config-tenant-contract-subj)# access-group sql both
Configure BGP connectivity over External SVI and export route corresponding to Site1.
Configure contract provider on l3epg1 (Site1) to establish connection with l3epg2 (Site2)
apic1(config)# tenant t1
apic1(config-tenant)# access-list acl1
apic1(config-tenant-acl)# match ip
apic1(config-tenant)# contract transit
apic1(config-tenant-contract)# subject ip
apic1(config-tenant-contract-subj)# access-group acl1 both
Virtual Port-Channel Name Domain VPC Leaf Id, Name Fex Id PC Id Ports
Port-Channel Name Type Leaf ID, Name Fex Id Port Channel Ports
----------------- ---- ------------------ ------ ------------- --------------------
po1 PC 101,leaf1 po1 eth1/2-5, eth1/32-33
po1 PC 102,leaf2 po2 eth1/32-33
show vlan-domain
show vlan-domain name dom100
vlan : 100-200(static)
101,102 vPC: vpc1 102 App-Epg Tenant: t1 b1: down b1: vlan-18
App: retail app: down app: vlan-19
Epg: app
101,102 vPC: vpc1 103 App-Epg Tenant: t1 b1: down b1: vlan-18
App: retail db: down db: vlan-20
Epg: db
Vrf: v1
show tenant
show tenant t1 detail
VRF Information:
VRF Policy Enforcement
-------------------- --------------------
v1 enforced
Bridge-Domain Information:
BD VRF
-------------------- --------------------
b1 v1
app
db
show external-l3
show external-l3 interfaces
eth1/11
Configuration : Operational
0.0.0.1
Interfaces :
Configuration : Operational