CISCO Nexus 9000 Series NX-OS Fundamentals Configuration Guide Release 10.4 User Guide

Nexus 9000 Series NX-OS Fundamentals Configuration Guide Release 10.4

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Configuration](https://manuals.plus/wp-content/uploads/2023/12/CISCO- Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide- Release-10.4-Configuration.jpg) Cisco Nexus 9000 Series NX-OS Fundamentals Configuration Guide, Release 10.4(x)
  First Published: 2023-08-18

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 REFERENCED IN THIS DOCUMENTATION ARE SUBJECT TO CHANGE WITHOUT NOTICE.
EXCEPT AS MAY OTHERWISE BE AGREED BY CISCO IN WRITING, ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS DOCUMENTATION ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED.
The Cisco End User License Agreement and any supplemental license terms govern your use of any Cisco software, including this product documentation, and are located at:
http://www.cisco.com/go/softwareterms.Cisco product warranty information is available at http://www.cisco.com/go/warranty. US Federal Communications Commission Notices are found here http://www.cisco.com/c/en/us/products/us- fcc-notice.html.
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 products and features described herein as in development or available at a future date remain in varying stages of development and will be offered on a when-and if-available basis. Any such product or feature roadmaps are subject to change at the sole discretion of Cisco and Cisco will have no liability for delay in the delivery or failure to deliver any products or feature roadmap items that may be set forth in this document.
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.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.
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)
© 2023 Cisco Systems, Inc. All rights reserved.

Preface

This preface includes the following sections:

• Audience, on page xi
• Document Conventions, on page xi
• Related Documentation for Cisco Nexus 9000 Series Switches, on page xii
• Documentation Feedback, on page xii
• Communications, Services, and Additional Information, on page xii

Audience
This publication is for network administrators who install, configure, and maintain Cisco Nexus switches.

Document Conventions
Command descriptions use the following conventions:

literally as shown.
Italic| Italic text indicates arguments for which you supply the values.
[x]| Square brackets enclose an optional element (keyword or argument).
[x | y]| Square brackets enclosing keywords or arguments that are separated by a vertical bar indicate an optional choice.
{x | y}| Braces enclosing keywords or arguments that are separated by a vertical bar indicate a required choice.
[x {y | z}]| Nested set of square brackets or braces indicate optional or required choices within optional or required elements. Braces and a vertical bar within square brackets indicate a required choice within an optional element.
variable| Indicates a variable for which you supply values, in context where italics cannot be used.
string| A nonquoted set of characters. Do not use quotation marks around the string or the string includes the quotation marks.

Examples use the following conventions:

screen font.
boldface screen font| Information that you must enter is in boldface screen font.
italic screen font| Arguments for which you supply values are in italic screen font.

Related Documentation for Cisco Nexus 9000 Series Switches
The entire Cisco Nexus 9000 Series switch documentation set is available at the following URL: http://www.cisco.com/en/US/products/ps13386/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.
Communications, Services, and Additional Information

• To receive timely, relevant information from Cisco, sign up at Cisco Profile Manager.
• To get the business impact you’re looking for with the technologies that matter, visit Cisco Services.
• To submit a service request, visit Cisco Support.
• To discover and browse secure, validated enterprise-class apps, products, solutions and services, visit Cisco Marketplace.
• To obtain general networking, training, and certification titles, visit Cisco Press.
• To find warranty information for a specific product or product family, access Cisco Warranty Finder.

Cisco Bug Search Tool
Cisco Bug Search Tool (BST) is a web-based tool that acts as a gateway to the Cisco bug tracking system
that maintains a comprehensive list of defects and vulnerabilities in Cisco products and software. BST provides
you with detailed defect information about your products and software.

CHAPTER 1 New and Changed Information

• New and Changed Information, on page 1

New and Changed Information
Table 1 : New and Changed Features

Guidelines and Limitations for POAP, on page 42

CHAPTER 2 Overview

This chapter contains the following sections:

• Licensing Requirements, on page 3
• Supported Platforms, on page 3
• Software Image, on page 3
• Software Compatibility, on page 4
• Serviceability, on page 4
• Manageability, on page 5
• Programmability, on page 6
• Traffic Routing, Forwarding, and Management, on page 7
• Quality of Service, on page 9
• Network Security Features, on page 9
• Supported Standards, on page 10

Licensing Requirements
For a complete explanation of Cisco NX-OS licensing recommendations and how to obtain and apply licenses, see the Cisco NX-OS Licensing Guide and the Cisco NX-OS Licensing Options Guide.
Supported Platforms
Starting with Cisco NX-OS release 7.0(3)I7(1), use the Nexus Switch Platform Support Matrix to know from which Cisco NX-OS releases various Cisco Nexus 9000 and 3000 switches support a selected feature.
Software Image
The Cisco NX-OS software consists of one NXOS software image. This image runs on all Cisco Nexus 3400 Series switches.
Software Compatibility
The Cisco NX-OS software interoperates with Cisco products that run any variant of the Cisco IOS software.
The Cisco NX-OS software also interoperates with any networking operating system that conforms to the IEEE and RFC compliance standards.
Spine/Leaf Topology
The Cisco Nexus 9000 Series switches support a two-tier spine/leaf topology.
Figure 1: Spine/Leaf Topology
This figure shows an example of a spine/leaf topology with four leaf switches (Cisco Nexus 9396 or 93128) connecting into two spine switches (Cisco Nexus 9508) and two 40G Ethernet uplinks from each leaf to each

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Leaf Topology](https://manuals.plus/wp-content/uploads/2023/12/CISCO- Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Leaf- Topology.jpg)

Modular Software Design
The Cisco NX-OS software supports distributed multithreaded processing on symmetric multiprocessors (SMPs), multi-core CPUs, and distributed data module processors. The Cisco NX-OS software offloads computationally intensive tasks, such as hardware table programming, to dedicated processors distributed across the data modules. The modular processes are created on demand, each in a separate protected memory space. Processes are started and system resources are allocated only when you enable a feature. A real-time preemptive scheduler helps to ensure the timely processing of critical functions.
Serviceability
The Cisco NX-OS software has serviceability functions that allow the device to respond to network trends and events. These features help you with network planning and improving response times.
Switched Port Analyzer
The Switched Port Analyzer (SPAN) feature allows you to analyze all traffic between ports (called the SPAN source ports) by nonintrusively directing the SPAN session traffic to a SPAN destination port that has an external analyzer attached to it. For more information about SPAN, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.

Ethanalyzer
Ethanalyzer is a Cisco NX-OS protocol analyzer tool based on the Wireshark (formerly Ethereal) open source code. Ethanalyzer is a command-line version of Wireshark for capturing and decoding packets. You can use Ethanalyzer to troubleshoot your network and analyze the control-plane traffic. For more information about Ethanalyzer, see the Cisco Nexus 9000 Series NX-OS Troubleshooting Guide.
Smart Call Home
The Call Home feature continuously monitors hardware and software components to provide e-mail-based notification of critical system events. A versatile range of message formats is available for optimal compatibility with pager services, standard e-mail, and XML-based automated parsing applications. It offers alert grouping capabilities and customizable destination profiles. You can use this feature, for example, to directly page a network support engineer, send an e-mail message to a network operations center (NOC), and employ Cisco Auto Notify services to directly generate a case with the Cisco Technical Assistance Center (TAC). For more information about Smart Call Home, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Online Diagnostics
Cisco generic online diagnostics (GOLD) verify that hardware and internal data paths are operating as designed.
Boot-time diagnostics, continuous monitoring, and on-demand and scheduled tests are part of the Cisco GOLD feature set. GOLD allows rapid fault isolation and continuous system monitoring. For information about configuring GOLD, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Embedded Event Manager
Cisco Embedded Event Manager (EEM) is a device and system management feature that helps you to customize behavior based on network events as they happen. For information about configuring EEM, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Manageability
This section describes the manageability features for the Cisco Nexus 9000 Series switches.
Simple Network Management Protocol
The Cisco NX-OS software is compliant with Simple Network Management Protocol (SNMP) version 1, version 2, and version 3. A large number of MIBs is supported. For more information about SNMP, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Configuration Verification and Rollback
The Cisco NX-OS software allows you to verify the consistency of a configuration and the availability of necessary hardware resources prior to committing the configuration. You can preconfigure a device and apply the verified configuration at a later time. Configurations also include checkpoints that allow you to roll back to a known good configuration as needed. For more information about rollbacks, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Role-Based Access Control
With role-based access control (RBAC), you can limit access to device operations by assigning roles to users.
You can customize access and restrict it to the users who require it. For more information about RBAC, see the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
Cisco NX-OS Device Configuration Methods
You can use these methods to configure Cisco NX-OS devices:

• The CLI from a Secure Shell (SSH) session, a Telnet session, or the console port. SSH provides a secure connection to the device. The CLI configuration guides are organized by feature. For more information, see the Cisco NX-OS configuration guides. For more information about SSH and Telnet, see the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
• The XML management interface, which is a programmatic method based on the NETCONF protocol that complements the CLI. For more information, see the Cisco NX-OS XML Interface User Guide.
• The Cisco Data Center Network Management (DCNM) client, which runs on your local PC and uses web services on the Cisco DCNM server. The Cisco DCNM server configures the device over the XML management interface. For more information about the Cisco DCNM client, see the Cisco DCNM Fundamentals Guide.

Programmability
This section describes the programmability features for the Cisco Nexus 9000 Series switches.
Python API
Python is an easy-to-learn, powerful programming language. It has efficient high-level data structures and a simple but effective approach to object- oriented programming. Python’s elegant syntax and dynamic typing, together with its interpreted nature, make it an ideal language for scripting and rapid application development in many areas on most platforms. The Python interpreter and the extensive standard library are freely available in source or binary form for all major platforms from the Python website: http://www.python.org/. The Python scripting capability gives programmatic access to the CLI to perform various tasks and Power-On Auto Provisioning (POAP) or Embedded Event Manager (EEM) actions. For more information about the Python API and Python scripting, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.
Tcl
Tool Command Language (Tcl) is a scripting language. With Tcl, you gain more flexibility in your use of the CLI commands on the device. You can use Tcl to extract certain values in the output of a show command, perform switch configurations, run Cisco NX-OS commands in a loop, or define EEM policies in a script.
Cisco NX-API
The Cisco NX-API provides web-based programmatic access to the Cisco Nexus 9000 Series switches. This support is delivered through the NX-API open-source web server. The Cisco NX-API exposes the complete configuration and management capabilities of the command-line interface (CLI) through web-based APIs.
You can configure the switch to publish the output of the API calls in either XML or JSON format. For more information about the Cisco NX-API, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.
Note
NX-API performs authentication through a programmable authentication module (PAM) on the switch. Use cookies to reduce the number of PAM authentications and thus reduce the load on PAM.
Bash Shell
The Cisco Nexus 9000 Series switches support direct Linux shell access. With Linux shell support, you can access the Linux system on the switch in order to use Linux commands and manage the underlying system. For more information about Bash shell support, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.
Broadcom Shell
The Cisco Nexus 9000 Series switch front-panel and fabric module line cards contain several Broadcom ASICs. You can use the CLI to access the command-line shell (bcm shell) for these ASICs. The benefit of using this method to access the bcm shell is that you can use Cisco NX-OS command extensions such as pipe include and redirect output to file to manage the output. In addition, the activity is recorded in the system accounting log for audit purposes, unlike commands entered directly from the bcm shell, which are not recorded in the accounting log. For more information about Broadcom shell support, see the Cisco Nexus 9000 Series NX-OS Programmability Guide.
Caution
Use Broadcom shell commands with caution and only under the direct supervision or request of Cisco Support personnel.
Traffic Routing, Forwarding, and Management
This section describes the traffic routing, forwarding, and management features supported by the Cisco NX-OS software.
Ethernet Switching
The Cisco NX-OS software supports high-density, high-performance Ethernet systems and provides the following Ethernet switching features:

• IEEE 802.1D-2004 Rapid and Multiple Spanning Tree Protocols (802.1w and 802.1s)
• IEEE 802.1Q VLANs and trunks
• IEEE 802.3ad link aggregation
• Unidirectional Link Detection (UDLD) in aggressive and standard modes

For more information, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide and the Cisco Nexus 9000 Series NX-OS Layer 2 Switching Configuration Guide.
IP Routing
The Cisco NX-OS software supports IP version 4 (IPv4) and IP version 6 (IPv6) and the following routing protocols:

• Open Shortest Path First (OSPF) Protocol Versions 2 (IPv4) and 3 (IPv6)
• Intermediate System-to-Intermediate System (IS-IS) Protocol (IPv4 and IPv6)
• Border Gateway Protocol (BGP) (IPv4 and IPv6)
• Enhanced Interior Gateway Routing Protocol (EIGRP) (IPv4 only)
• Routing Information Protocol Version 2 (RIPv2) (IPv4 only)

The Cisco NX-OS software implementations of these protocols are fully compliant with the latest standards and include 4-byte autonomous system numbers (ASNs) and incremental shortest path first (SPF). All unicast protocols support Non-Stop Forwarding Graceful Restart (NSF-GR). All protocols support all interface types, including Ethernet interfaces, VLAN interfaces, sub interfaces, port channels, and loopback interfaces.
For more information, see the Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide.
IP Services
The following IP services are available in the Cisco NX-OS software:

• Virtual routing and forwarding (VRF)
• Dynamic Host Configuration Protocol (DHCP) helper
• Hot Standby Router Protocol (HSRP)
• Enhanced object tracking
• Policy-based routing (PBR)
• Unicast graceful restart for all protocols in IPv4 unicast graceful restart for OPSFv3 in IPv6

For more information, see the Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide.

IP Multicast
The Cisco NX-OS software includes the following multicast protocols and functions:

• Protocol Independent Multicast (PIM) Version 2 (PIMv2)
• PIM sparse mode (Any-Source Multicast [ASM] for IPv4)
• Anycast rendezvous point (Anycast-RP)
• Multicast NSF for IPv4
• RP-Discovery using bootstrap router (BSR) (Auto-RP and static)
• Internet Group Management Protocol (IGMP) Versions 1, 2, and 3 router role
• IGMPv2 host mode
• IGMP snooping
• Multicast Source Discovery Protocol (MSDP) (for IPv4)

Note
The Cisco NX-OS software does not support PIM dense mode.
For more information, see the Cisco Nexus 9000 Series NX-OS Multicast Routing Configuration Guide.
Quality of Service
The Cisco NX-OS software supports quality of service (QoS) functions for classification, marking, queuing, policing, and scheduling. Modular QoS CLI (MQC) supports all QoS features. You can use MQC to provide uniform configurations across various Cisco platforms. For more information, see the Cisco Nexus 9000 Series NX-OS Quality of Service Configuration Guide.
Network Security Features
The Cisco NX-OS software includes the following security features:

• Control Plane Policing (CoPP)
• Message-digest algorithm 5 (MD5) routing protocol authentication
• Authentication, authorization, and accounting (AAA)
• RADIUS and TACACS+
• SSH Protocol Version 2
• SNMPv3
• Policies based on MAC and IPv4 addresses supported by named ACLs (port-based ACLs [PACLs], VLAN-based ACLs [VACLs], and router-based ACLs [RACLs])
• Traffic storm control (unicast, multicast, and broadcast)

For more information, see the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.

Supported Standards
This table lists the IEEE compliance standards.
Table 2: IEEE Compliance Standards

This table lists the RFC compliance standards. For information on each RFC, see www.ietf.org.
Table 3: RFC Compliance Standards

BGP
RFC 1997| BGP Communities Attribute
RFC 2385| Protection of BGP Sessions via the TCP MD5 Signature Option
RFC 2439| BGP Route flap damping
RFC 2519| A Framework for Inter- Domain Route Aggregation
RFC 2545| Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
RFC 2858| Multiprotocol Extensions for BGP-4
RFC 2918| Route Refresh Capability for BGP-4
RFC 3065| Autonomous System Confederations for BGP
Standard| Description
---|---
RFC 3392| Capabilities Advertisement with BGP-4
RFC 4271| BGP version 4
RFC 4273| BGP4 MIB – Definitions of Managed Objects for BGP-4
RFC 4456| BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
RFC 4486| Subcodes for BGP cease notification message
RFC 4724| Graceful Restart Mechanism for BGP
RFC 4893| BGP Support for Four-octet AS Number Space
RFC 5004| Avoid BGP Best Path Transitions from One External to Another
RFC 5396| Textual Representation of Autonomous System (AS) Numbers
Note RFC 5396 is partially supported. The asplain and asdot notations are supported, but the asdot+ notation is not.
RFC 5549| Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
RFC 5668| 4-Octet AS Specific BGP Extended Community
ietf-draft| Bestpath transition avoidance (draft-ietf-idr-avoid- transition-05.txt)
ietf-draft| Peer table objects
(draft-ietf-idr-bgp4-mib-15.txt)
ietf-draft| Dynamic Capability
(draft-ietf-idr-dynamic-cap-03.txt)
IP Multicast
Standard| Description
---|---
RFC 2236| Internet Group Management Protocol, Version 2
RFC 3376| Internet Group Management Protocol, Version 3
RFC 3446| Anycast Rendezvous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
RFC 3569| An Overview of Source- Specific Multicast (SSM)
RFC 3618| Multicast Source Discovery Protocol (MSDP)
RFC 4601| Protocol Independent Multicast – Sparse Mode (PIM-SM): Protocol Specification (Revised)
RFC 4607| Source-Specific Multicast for IP
RFC 4610| Anycast-RP Using Protocol Independent Multicast (PIM)
RFC 6187| X.509v3 Certificates for Secure Shell Authentication
ietf-draft| Mtrace server functionality, to process mtrace-requests, draft- ietf-idmr-traceroute-ipm-07.txt
IP Services
RFC 768| UDP
RFC 783| TFTP
RFC 791| IP
RFC 792| ICMP
RFC 793| TCP
RFC 826| ARP
RFC 854| Telnet
RFC 959| FTP
RFC 1027| Proxy ARP
Standard| Description
---|---
RFC 1305| NTP v3
RFC 1519| CIDR
RFC 1542| BootP relay
RFC 1591| DNS client
RFC 1812| IPv4 routers
RFC 2131| DHCP Helper
RFC 2338| VRRP
IS-IS
RFC 1142 (OSI 10589)| OSI 10589 Intermediate system to intermediate system intra-domain routing exchange protocol
RFC 1195| Use of OSI IS-IS for routing in TCP/IP and dual environment
RFC 2763| Dynamic Hostname Exchange Mechanism for IS-IS
RFC 2966| Domain-wide Prefix Distribution with Two-Level IS-IS
RFC 2973| IS-IS Mesh Groups
RFC 3277| IS-IS Transient Blackhole Avoidance
RFC 3373| Three-Way Handshake for IS- IS Point-to-Point Adjacencies
RFC 3567| IS-IS Cryptographic Authentication
RFC 3847| Restart Signaling for IS- IS
ietf-draft| Internet Draft Point-to-point operation over LAN in link-state routing protocols
(draft-ietf-isis-igp-p2p-over-lan-06.txt)
OSPF
RFC 2328| OSPF Version 2
RFC 2370| OSPF Opaque LSA Option
RFC 2740| OSPF for IPv6 (OSPF version 3)
Standard| Description
---|---
RFC 3101| OSPF Not-So-Stubby-Area (NSSA) Option
RFC 3137| OSPF Stub Router Advertisement
RFC 3509| Alternative Implementations of OSPF Area Border Routers
RFC 3623| Graceful OSPF Restart
RFC 4750| OSPF Version 2 MIB
Per-Hop Behavior (PHB)
RFC 2597| Assured Forwarding PHB Group
RFC 3246| An Expedited Forwarding PHB
RIP
RFC 1724| RIPv2 MIB extension
RFC 2082| RIPv2 MD5 Authentication
RFC 2453| RIP Version 2
SNMP
RFC 2579| Textual Conventions for SMIv2
RFC 2819| Remote Network Monitoring Management Information Base
RFC 2863| The Interfaces Group MIB
RFC 3164| The BSD syslog Protocol
RFC 3176| InMon Corporation’s sFlow: A Method for Monitoring Traffic in Switched and Routed Networks
RFC 3411 and RFC 3418| An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks
RFC 3413| Simple Network Management Protocol (SNMP) Applications
RFC 3417| Transport Mappings for the Simple Network Management Protocol (SNMP)

CHAPTER 3 Using the Cisco NX-OS Setup Utility

This chapter contains the following sections:

• About the Cisco NX-OS Setup Utility, on page 15
• Prerequisites for the Setup Utility, on page 16
• Setting Up Your Cisco NX-OS Device, on page 17
• Additional References for the Setup Utility, on page 22

About the Cisco NX-OS Setup Utility
The Cisco NX-OS setup utility is an interactive command-line interface (CLI) mode that guides you through a basic (also called a startup) configuration of the system. The setup utility allows you to configure only enough connectivity for system management.
The setup utility allows you to build an initial configuration file using the System Configuration Dialog. The setup starts automatically when a device has no configuration file in NVRAM. The dialog guides you through initial configuration. After the file is created, you can use the CLI to perform additional configuration.
You can press Ctrl-C at any prompt to skip the remaining configuration options and proceed with what you have configured up to that point, except for the administrator password. If you want to skip answers to any questions, press Enter. If a default answer is not available (for example, the device hostname), the device uses what was previously configured and skips to the next question.

Figure 2: Setup Script Flow

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Setup Script Flo](https://manuals.plus/wp-content/uploads/2023/12/CISCO- Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Setup- Script-Flo.jpg) This figure shows how to enter and exit the setup script.
  You use the setup utility mainly for configuring the system initially, when no configuration is present. However, you can use the setup utility at any time for basic device configuration. The setup utility keeps the configured values when you skip steps in the script. For example, if you have already configured the mgmt0 interface, the setup utility does not change that configuration if you skip that step. However, if there is a default value for the step, the setup utility changes to the configuration using that default, not the configured value. Be sure to carefully check the configuration changes before you save the configuration.
  Note
  Be sure to configure the IPv4 route, the default network IPv4 address, and the default gateway IPv4 address to enable SNMP access. If you enable IPv4 routing, the device uses the IPv4 route and the default network IPv4 address. If IPv4 routing is disabled, the device uses the default gateway IPv4 address.
  Note
  The setup script only supports IPv4.
  Prerequisites for the Setup Utility
  The setup utility has the following prerequisites:

  • Have a password strategy for your network environment.
  • Connect the console port on the supervisor module to the network. If you have dual supervisor modules, connect the console ports on both supervisor modules to the network.
  • Connect the Ethernet management port on the supervisor module to the network. If you have dual supervisor modules, connect the Ethernet management ports on both supervisor modules to the network.

Setting Up Your Cisco NX-OS Device
To configure basic management of the Cisco NX-OS device using the setup utility, follow these steps:
Step 1 Power on the device.
Step 2 Enable or disable password-strength checking.
A strong password has the following characteristics:

• At least eight characters long
• Does not contain many consecutive characters (such as “abcd”)
• Does not contain many repeating characters (such as “aaabbb”)
• Does not contain dictionary words
• Does not contain proper names
• Contains both uppercase and lowercase characters
• Contains numbers

Example:
—- System Admin Account Setup —-
Do you want to enforce secure password standard (yes/no) [y]: y
Step 3 Enter the new password for the administrator.
Note
If a password is trivial (such as a short, easy-to-decipher password), your password configuration is rejected.
Passwords are case sensitive. Be sure to configure a strong password that has at least eight characters, both uppercase and lowercase letters, and numbers.
Example:
Enter the password for “admin”: < password>
Confirm the password for “admin”: < password>
—- Basic System Configuration Dialog —-
This setup utility will guide you through the basic configuration of the system. Setup configures only enough connectivity for management of the system.
Please register Cisco Nexus 9000 Family devices promptly with your supplier. Failure to register may affect response times for initial service calls. Nexus devices must be registered to receive entitled support services.
Press Enter at anytime to skip a dialog. Use ctrl-c at anytime to skip the remaining dialogs.
Step 4 Enter the setup mode by entering yes.
Example:
Would you like to enter the basic configuration dialog (yes/no): yes
Step 5
Create additional accounts by entering yes (no is the default).
Example:
Create another login account (yes/no) [n]:yes
a) Enter the user login ID.
Example:
Enter the User login Id : userlogin
Caution
Usernames must begin with an alphanumeric character and can contain only these special characters:
( + = . \ -). The # and ! symbols are not supported. If the username contains characters that are not allowed, the specified user is unable to log in.
b) Enter the user password.
Example:
Enter the password for “user1”: user_password
Confirm the password for “user1”: user_password
c) Enter the default user role.
Example:
Enter the user role (network-operator|network-admin) [network-operator]: default_user_role
For information on the default user roles, see the Cisco Nexus 9000 Series NX- OS Security Configuration Guide.
Step 6 Configure an SNMP community string by entering yes.
Example:
Configure read-only SNMP community string (yes/no) [n]: yes
SNMP community string : snmp_community_string
For information on SNMP, see the Cisco Nexus 9000 Series NX-OS System Management Configuration Guide.
Step 7
Enter a name for the device (the default name is switch).
Example:
Enter the switch name: switch_name
Step 8
Configure out-of-band management by entering yes. You can then enter the mgmt0 IPv4 address and subnet mask.
Note You can only configure IPv4 address in the setup utility. For information on configuring IPv6, see the Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide.
Example:
Continue with Out-of-band (mgmt0) management configuration? [yes/no]: yes
Mgmt0 IPv4 address: mgmt0_ip_address
Mgmt0 IPv4 netmask: mgmt0_subnet_mask
Step 9
Configure the IPv4 default gateway (recommended) by entering yes. You can then enter its IP address.
Example:
Configure the default-gateway: (yes/no) [y]: yes
IPv4 address of the default-gateway: default_gateway
Step 10
Configure advanced IP options such as the static routes, default network, DNS, and domain name by entering yes.
Example:
Configure Advanced IP options (yes/no)? [n]: yes
Step 11
Configure a static route (recommended) by entering yes. You can then enter its destination prefix, destination prefix mask, and next hop IP address.
Example:
Configure static route: (yes/no) [y]: yes
Destination prefix: dest_prefix
Destination prefix mask: dest_mask
Next hop ip address: next_hop_address
Step 12
Configure the default network (recommended) by entering yes. You can then enter its IPv4 address.
Note The default network IPv4 address is the same as the destination prefix in the static route configuration.
Example:
Configure the default network: (yes/no) [y]: yes
Default network IP address [dest_prefix]: dest_prefix
Step 13
Configure the DNS IPv4 address by entering yes. You can then enter the address.
Example:
Configure the DNS IP address? (yes/no) [y]: yes
DNS IP address: ipv4_address
Step 14
Configure the default domain name by entering yes. You can then enter the name.
Example:
Configure the DNS IP address? (yes/no) [y]: yes
DNS IP address: ipv4_address
Step 15
Enable the Telnet service by entering yes.
Example:
Enable the telnet service? (yes/no) [y]: yes
Step 16
Enable the SSH service by entering yes. You can then enter the key type and number of key bits. For more information, see the Cisco Nexus 9000 Series NX- OS Security Configuration Guide.
Example:
Enable the ssh service? (yes/no) [y]: yes
Type of ssh key you would like to generate (dsa/rsa) : key_type
Number of key bits <768-2048> : number_of_bits
Step 17
Configure the NTP server by entering yes. You can then enter its IP address. For more information, see the Cisco
Nexus 9000 Series NX-OS System Management Configuration Guide.
Example:
Configure NTP server? (yes/no) [n]: yes
NTP server IP address: ntp_server_IP_address
Step 18
Specify a default interface layer (L2 or L3).
Example:
Configure default interface layer (L3/L2) [L3]: interface_layer
Step 19
Enter the default switchport interface state (shutdown or no shutdown). A shutdown interface is in an administratively
down state. For more information, see the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide.
Example:
Configure default switchport interface state (shut/noshut) [shut]: default_state
Step 20
Enter yes (no is the default) to configure basic Fibre Channel configurations.
Example:
Enter basic FC configurations (yes/no) [n]: yes
Step 21
Enter shut (noshut is the default) to configure the default Fibre Channel switch port interface to the shut (disabled) state.
Example:
Configure default physical FC switchport interface state (shut/noshut)

Step 22
Enter on (on is the default) to configure the switch port trunk mode
Example:
Configure default physical FC switchport trunk mode (on/off/auto) [on]: on
Step 23
Enter permit (deny is the default) to permit a default zone policy configuration.
Example:
Configure default zone policy (permit/deny) [deny]: permit Permits traffic flow to all members of the default zone.
Example:
Note
If you are executing the setup script after entering a write erase command, you explicitly must change the default zone policy to permit for VSAN 1 after finishing the script using the following command:
switch(config)# zone default-zone permit vsan 1
Step 24
Enter yes (no is the default) to enable a full zone set distribution.
Example:
Enable full zoneset distribution (yes/no) [n]: yes
Step 25
Enter the best practices profile for control plane policing (CoPP). For more information, see the Cisco Nexus 9000 Series NX-OS Security Configuration Guide.
Example:
Configure best practices CoPP profile (strict/moderate/lenient/none) [strict]: moderate The system now summarizes the complete configuration and asks if you want to edit it.
Step 26
Continue to the next step by entering no. If you enter yes, the setup utility returns to the beginning of the setup and repeats each step.
Example:
Would you like to edit the configuration? (yes/no) [y]: yes
Step 27
Use and save this configuration by entering yes. If you do not save the configuration at this point, none of your changes are part of the configuration the next time the device reboots. Enter yes to save the new configuration. This step ensures that the boot variables for the nx-os image are also automatically configured.
Example:
Use this configuration and save it? (yes/no) [y]: yes
Caution
If you do not save the configuration at this point, none of your changes are part of the configuration the next time that the device reboots. Enter yes to save the new configuration to ensure that the boot variables for the nx-os image are also automatically configured.
Additional References for the Setup Utility
This section includes additional information related to using the setup utility.
Related Documents for the Setup Utility

Guide_
SNMP and NTP| Cisco Nexus 9000 Series NX-OS System Management Configuration Guide

CHAPTER 4 Using PowerOn Auto Provisioning

This chapter contains the following sections:

• About PowerOn Auto Provisioning, on page 23
• POAPv3, on page 40
• Guidelines and Limitations for POAP, on page 42
• Setting Up the Network Environment to Use POAP, on page 44
• Configuring a Switch Using POAP, on page 44
• Creating md5 Files, on page 45
• Verifying the Device Configuration, on page 46
• Troubleshooting for POAP, on page 47
• Managing the POAP Personality, on page 48

About PowerOn Auto Provisioning
PowerOn Auto Provisioning (POAP) automates the process of upgrading software images and installing configuration files on devices that are being deployed in the network for the first time.
When a device with the POAP feature boots and does not find the startup configuration, the device enters POAP mode, locates a DHCP server, and bootstraps itself with its interface IP address, gateway, and DNS server IP addresses. The device also obtains the IP address of a TFTP server and downloads a configuration script that enables the switch to download and install the appropriate software image and configuration file.
Note
The DHCP information is used only during the POAP process.
Network Requirements for POAP
POAP requires the following network infrastructure:

• A DHCP server to bootstrap the interface IP address, gateway address, and Domain Name System (DNS) server.
• A TFTP server that contains the configuration script used to automate the software image installation and configuration process.
• One or more servers that contains the desired software images and configuration files.
• If you use USB, then no DHCP server or TFTP server are required for POAP.

Figure 3: POAP Network Infrastructure

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• POAP Network Infrastructure](https://manuals.plus/wp-content/uploads/2023/12 /CISCO-Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4 -POAP-Network-Infrastructure.jpg)

Secure Download of POAP Script
Beginning with Cisco NX-OS Release 10.2(3)F, you have the option of securely downloading the POAP script. When a device with the POAP feature boots and does not find the startup configuration, the device enters POAP mode, locates a DHCP server, and bootstraps itself with its interface IP address, gateway, and DNS server IP addresses. The device also obtains the IP address of an HTTPS server and downloads POAP script securely. The script enables the switch to download and install the appropriate software image and configuration file.
To download the POAP script securely, you need to select specific POAP options. Until Cisco NX-OS Release 10.2(3)F, POAP used options 66 and 67 for IPv4, and options 77 and 15 for IPv6 to extract the booting script information. However, the transfer of the script uses http, and is not very secure. Beginning with Cisco NX-OS Release 10.2(3)F, option 43 specifies the secure POAP related provisioning script information for IPv4 and option 17 specifies the same for IPv6. Additionally, these options allow the POAP to reach the file server in a secure manner. The POAP options 66, 67, 77, and 15 continue to be supported in Cisco NX-OS Release10.2(3)F. Furthermore, if you are using option 43 or 17, you can use the earlier options as fallback options, if required. From Cisco NX-OS Release 10.4(1)F, you can use Root-CA bundles instead of single .pem certificate for Secure POAP.
Note
The maximum character length is 512 bytes for both option 43 and option 17.
The sub-options available for option 43 and option 17 are discussed in the following sections:

• Option 43 – IPv4
• Option 17 – IPv6

IPv4
Option 43 has the following sub-options for IPv4:

• option space poap length width 2;
• option poap.version code 1 = unsigned integer 8;

Note
This sub-option is mandatory.

• option poap.ca_list code 50 = text;
• option poap.url code 2 = text;

Note
This sub-option is mandatory.

• option poap.debug code 51 = unsigned integer 8;
• option poap.ntp code 3 = ip-address;

Note
This sub-option is only supported for IPv4 (Option 43).

• option poap.flag code 52 = unsigned integer 8;

Note
Flag is used to skip server certificate validation in the client.

Sample configuration for IPv4 is as follows:

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Figure 2](https://manuals.plus/wp-content/uploads/2023/12/CISCO-Nexus-9000 -Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Figure-2.jpg)

IPv6
Option 17 has the following sub-options for IPv6:

• option space poap_v6 length width 2;
• option poap_v6.version code 1 = unsigned integer 8;

Note
This sub-option is mandatory.

• option poap_v6.ca_list code 50 = text;
• option poap_v6.url code 3 = text;

Note
This sub-option is mandatory.

• option poap_v6.debug code 51 = unsigned integer 8;
• option vsio.poap_v6 code 9 = encapsulate poap_v6;

Sample configuration for IPv6 is as follows:

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Figure 3](https://manuals.plus/wp-content/uploads/2023/12/CISCO-Nexus-9000 -Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Figure-3-1.jpg)

Network Requirements for Secure POAP
Secure POAP requires the following network infrastructure:

• A DHCP server to bootstrap the interface IP address, gateway address, and Domain Name System (DNS) server.

• An HTTPS server that contains the POAP script used for software image installation and configuration process.
  Note
  • If the HTTPS server runs on a non-SUDI device, a physical USB drive with the CA certificates of the file-server is required.
  • In case of secure download of POAP script, the TFTP server is replaced with the HTTPS server. Hence, when you read the content related to the TFTP server in this chapter, remember to read the TFTP server as the HTTPS server.

• One or more servers that contain the desired software images and configuration files.

Deployment Scenarios
Cisco devices have a unique identifier known as the Secure Unique Device Identifier (SUDI). The hardware SUDI can be used for authentication, as it can be used for asymmetric key operations such as encryption, decryption, signing, and verifying that allow passage of the data to be operated upon. All non- Cisco devices are classified as non-SUDI devices. For a non-SUDI device, the root-CA bundle is required to authenticate the file server. However, the file server can be hosted on either a SUDI or a non-SUDI device.
Based on all these capabilities, you can use one of the following deployment scenarios to download the POAP script in a secure way:

• SUDI Supported Device as File Server
• Non-SUDI Supported Device as a File Server

SUDI Supported Device as File Server
The SUDI supported devices are Cisco devices. Unlike the earlier implementation, the DHCP server now provides a https location rather than http/tftp. In this scenario, only the DHCP server and the SUDI supported script server (HTTPS server) are required, other than one or more servers that contain the required software images and configuration files.
Note
SUDI only supports TLSv1.2 or below. Also, the SUDI solution only considers secure download using https, but not sftp.

Figure 4: SUDI Supported Device as File Server Infrastructure

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• SUDI Supported Device as File Server Infrastructure](https://manuals.plus /wp-content/uploads/2023/12/CISCO-Nexus-9000-Series-NX-OS-Fundamentals- Configuration-Guide-Release-10.4-SUDI-Supported-Device-as-File-Server- Infrastructure.jpg)

The workflow for SUDI supported devices is as follows:

• Booting device is SUDI capable and has the needed trust store to verify a SUDI certificate
• Booting device sends out DHCP discover
• DHCP server responds to booting device with https server details
• Device establishes the secure channel using standard SSL APIs
• Authentication is done by verifying SUDI on both sides
• Downloads poap.py

Non-SUDI Supported Device as a File Server
In this scenario, the Root-CA bundle must be installed in the booting device. The Root-CA bundle is required for authentication. Here, the DHCP server, intermediate device, and non-SUDI supported script server (HTTPS server) are required, other than one or more servers that contain the required software images and configuration files.
The DHCP offer has the details of intermediate server that has the Root-CA bundle available. The intermediate device should support SUDI. The booting device uses the intermediate device to download the Root-CA bundle, install it, and then communicate with the file server. The intermediate devices should be provisioned first.
Note
The intermediate device requires that you provide the Root-CA bundle manually. For more information, see Bench Configured Device Hosting Root-CA Bundle.

Figure 5: Non-SUDI Supported Device as File Server Infrastructure

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Non-SUDI Supported Device as File Server Infrastructure](https://manuals.plus/wp-content/uploads/2023/12/CISCO- Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Non- SUDI-Supported-Device-as-File-Server-Infrastructure.jpg)

The workflow for non-SUDI supported devices is as follows:

• Booting device is SUDI capable and has the needed trust store to verify a SUDI certificate
• Intermediate device that hosts a server with Root-CA bundle is also SUDI capable
• Booting device sends out DHCP discover
• DHCP server responds to booting device with https server details and Root-CA server details
• Booting device reaches to intermediate device, gets the CA bundle, adds it to the trust store
• Booting device reaches the file server to download poap.py

Bench Configured Device Hosting Root-CA Bundle
A bench configured device requires manual intervention during bootup to install the Root-CA bundle by inserting a USB drive.
The workflow is as follows:

• Devices acting as intermediate devices, should be supplied with a USB drive during bootup.

• This USB drive will have poap_usb.py and Root-CA bundle.

• The poap_usb.py file in the USB copies Root-CA to the device, adds Root-CA to trust store, and returns a failure to POAP to trigger DHCP discover.
  Note
  • The required script is available as a template in GitHub.
  • To change port on the Bench Configured Device, use the file-server <port- number> command. Avoid using standard ports such as port 80 (http) and port 443 (https).

• The DHCP discover phase helps in provisioning the device.

• When the device boots up after provisioning, it has an additional server that hosts the Root-CA bundle.

Secure POAP on a Device Shipped with Old Image
Support for secure POAP will be available only for devices that are shipped with image that has secure POAP feature.
If the device does not have the secure POAP feature, then use the legacy DHCP options to move the device to a later version of the image that supports secure POAP. Then these devices can be reloaded and use the secure POAP feature.
Troubleshooting Secure POAP
Perform the following steps to collect debugging information regarding secure POAP:

1. Set the debug option for IPv4 in option 43 to 1 and for IPv6 in option 17. The debug option enables additional logs.
2. Allow the switch to run one cycle of POAP.
3. Abort POAP.
4. When the system boots up, run the show tech-support poap command.
   This command displays POAP status and configuration.

Disabling POAP
POAP is enabled when there is no configuration in the system. It runs as a part of bootup. However, you can bypass POAP enablement during initial setup. If you want to disable POAP permanently (even when there is no configuration in the system), you can use the ‘system no poap’ command. This command ensures that POAP is not started during the next boot (even if there is no configuration). To enable POAP, use the ‘system poap’ command or the ‘write erase poap’ command. The ‘write erase poap’ command erases the POAP flag and enables POAP.

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• Figure 4](https://manuals.plus/wp-content/uploads/2023/12/CISCO-Nexus-9000 -Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Figure-4.jpg) ![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4
• Figure 5](https://manuals.plus/wp-content/uploads/2023/12/CISCO-Nexus-9000 -Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-Figure-5.jpg)

POAP Configuration Script
The reference script supplied by Cisco supports the following functionality:

• Retrieves the switch-specific identifier, for example, the serial number.
• Downloads the nx-os software image if the files do not already exist on the switch. The nx-os image is installed on the switch and is used at the next reboot.
• Schedules the downloaded configuration to be applied at the next switch reboot.
• Stores the configuration as the startup configuration.

Cisco has sample configuration scripts that were developed using the Python programming language and Tool Command Language (Tcl). You can customize one of these scripts to meet the requirements of your network environment. You can access the Python script to perform POAP on the Cisco Nexus 9000 Series switch at this link: https://github.com/datacenter/nexus9000/tree/master/nx- os/poap.
The Python programming language uses two APIs that can execute CLI commands. These APIs are described in the following table. The arguments for these APIs are strings of the CLI commands.

characters.
clid()| For CLI commands that support XML, this API puts the command output in a Python dictionary.
This API can be useful to help search the output of  show commands.

POAP Configuration Script
We provide a sample configuration script that is developed using the Python programming language. We recommend using the provided script and modifying it to meet the requirements of your network environment.
The POAP script can be found at https://github.com/datacenter/nexus9000/blob/master/nx-os/poap/poap.py.
To modify the script using Python, see the Cisco NX-OS Python API Reference Guide for your platform.
Using the POAP Script and POAP Script Options
Before using the POAP script, perform the following actions:

1. Edit the options dictionary at the top of the script to ensure that all relevant options for your setup are included in the script. Do not change the defaults (in the default options function) directly.

2. Update the MD5 checksum of the POAP script as shown using shell commands.
   f=poap_nexus_script.py ; cat $f | sed ‘/^#md5sum/d’ > $f.md5 ; sed -i
   “s/^#md5sum=./#md5sum=\”$(md5sum $f.md5 | sed ‘s/ .//’)\”/” $f

3. If the device has a startup configuration, perform a write erase and reload the device.

The following POAP script options can be specified to alter the POAP script behavior. When you download files from a server, the hostname, username, and password options are required. For every mode except personality, the target_system_image is also required. Required parameters are enforced by the script, and the script aborts if the required parameters are not present. Every option except hostname, username, and password has a default option. If you do not specify the option in the options dictionary, the default is used.

• username
  The username to use when downloading files from the server.

• password
  The password to use when downloading files from the server.

• hostname
  The name or address of the server from which to download files.

• mode
  The default is serial_number.
  Use one of the following options:

• personality
  A method to restore the switch from a tarball.

• serial_number
  The serial number of the switch to determine the configuration filename. The format for the serial number in the configuration file is conf.serialnumber. Example: conf.FOC123456

• hostname
  The hostname as received in the DHCP options to determine the configuration filename. The format for the hostname in the configuration file is conf_hostname.cfg. Example: conf_3164-RS.cfg

• mac
  The interface MAC address to determine the configuration filename. The format for the hostname in the configuration file is conf_macaddress.cfg. Example: conf_7426CC5C9180.cfg

• raw
  The configuration filename is used exactly as provided in the options. The filename is not altered in any way.

• location
  The CDP neighbors are used to determine the configuration filename. The format for the location in the configuration file is conf_host_intf.cfg, where host is the host connected to the device over the POAP interface, and intf is the remote interface to which the POAP interface is connected.
  Example: conf_remote-switch_Eth1_8.cfg

• required_space
  The required space in KB for that particular iteration of POAP. The default is 100,000. For multi-step upgrades, specify the size of the last image in the upgrade path of the target image.

• transfer_protocol
  Any transfer protocol such as http, https, ftp, scp, sftp, or tftp that is supported by VSH. The default is scp.

• config_path
  The path to the configuration file on the server. Example: /tftpboot. The default is /var/lib/tftpboot.

• target_system_image
  The name of the image to download from the remote server. This is the image you get after POAP completes. This option is a required parameter for every mode except personality. The default is “”.

• target_image_path
  The path to the image on the server. Example: /tftpboot. The default is /var/lib/tftpboot.

• destination_path
  The path to which to download images and MD5 sums. The default is /bootflash.

• destination_system_image
  The name for the destination image filename. If not specified, the default will be the target_system_image name.

• user_app_path
  The path on the server where the user scripts, agents, and user data are located. The default is /var/lib/tftpboot.

• disable_md5
  This is True if MD5 checking should be disabled. The default is False.

• midway_system_image
  The name of the image to use for the midway system upgrade. By default, the POAP script finds the name of any required midway images in the upgrade path and uses them. Set this option if you prefer to pick a different midway image for a two-step upgrade. The default is “”.

• source_config_file
  The name of the configuration file when raw mode is used. The default is poap.cfg.

• vrf
  The VRF to use for downloads and so on. The VRF is automatically set by the POAP process. The default is the POAP_VRF environment variable.

• destination_config
  The name to use for the downloaded configuration. The default is poap_replay.cfg.

• split_config_first
  The name to use for the first configuration portion if the configuration needs to be split. It is applicable only when the configuration requires a reload to take effect. The default is poap_1.cfg.

• split_config_second
  The name to use for the second configuration portion if the configuration is split. The default is poap_2.cfg.

• timeout_config
  The timeout in seconds for copying the configuration file. The default is

120. For non-legacy images, this option is not used, and the POAP process times out. For legacy images, FTP uses this timeout for the login process and not for the copy process, while scp and other protocols use this timeout for the copy process.

• timeout_copy_system
  The timeout in seconds for copying the system image. The default is 2100. For non-legacy images, this option is not used, and the POAP process times out. For legacy images, FTP uses this timeout for the login process and not for the copy process, while scp and other protocols use this timeout for the copy process.

• timeout_copy_personality
  The timeout in seconds for copying the personality tarball. The default is

900. For non-legacy images, this option is not used, and the POAP process times out. For legacy images, FTP uses this timeout for the login process and not for the copy process, while scp and other protocols use this timeout for the copy process.

• timeout_copy_user
  The timeout in seconds for copying any user scripts and agents. The default is 900. For non-legacy images, this option is not used, and the POAP process times out. For legacy images, FTP uses this timeout for the login process and not for the copy process, while scp and other protocols use this timeout for the copy process.

• personality_path
  The remote path from which to download the personality tarball. Once the tarball is downloaded and the personality process is started, the personality will download all files in the future from locations specified inside the tarball configuration. The default is /var/lib/tftpboot.

• source_tarball
  The name of the personality tarball to download. The default is personality.tar.

• destination_tarball
  The name for the downloaded personality tarball after it is downloaded. The default is personality.tar.

Setting up the DHCP Server without DNS for POAP
Beginning with Cisco NX-OS Release 7.0(3)I6(1), the tftp-server-name can be used without the DNS option.
To enable POAP functionality without DNS on earlier releases, a custom option of 150 must be used to specify the tftp-server-address.
To use the tftp-server-address option, specify the following at the start of your dhcpd.conf file.
option tftp-server-address code 150 = ip-address;
For example:

Downloading and Using User Data, Agents, and Scripts as part of POAP
Under the options dictionary, you can find the download_scripts_and_agents function. If you choose to download user scripts and data, uncomment the first poap_log line and then use a series of download_user_app function calls to download each application. Since older Cisco NX-OS versions do not support recursive copy of directories, such directories must be put into a tarball (TAR archive) and then unpacked once on the switch.
The parameters for the download_scripts_and_agents function are as follows:

• source_path – The path to where the file or tarball is located. This is a required parameter. Example: /var/lib/tftpboot.
• source_file – The name of the file to download. This is a required parameter. Example: agents.tar, script.py, and so on.
• dest_path – The location to download the file on the switch. Any directories that do not exist earlier will be created. This is an optional parameter. The default is /bootflash.
• dest_file – The name to give the downloaded file. This is an optional parameter. The default is unchanged source_file.
• unpack – Indicates whether a tarball exists for unpacking. Unpacking is done with tar -xf tarfile -C /bootflash. This is an optional parameter. The default is False.
• delete_after_unpack – Indicates whether to delete the downloaded tarball after unpack is successful.
  There is no effect if unpack is False. The default is False.

Using the download functionality, you can download all the agents and files needed to run POAP. To start the agents, you should have the configuration present in the running configuration downloaded by POAP.
Then the agents, scheduler, and cron entry, along with EEM, can be used.

POAP Process
The POAP process has the following phases:

1. Power up
2. USB discovery
3. DHCP discovery
4. Script execution
5. Post-installation reload

Within these phases, other process and decision points occur. The following illustration shows a flow diagram of the POAP process.

Figure 6: POAP Process

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• POAP Process](https://manuals.plus/wp-content/uploads/2023/12/CISCO- Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4-POAP- Process.jpg)

Power-Up Phase
When you powerup the device for the first time, it loads the software image that is installed at manufacturing and tries to find a configuration file from which to boot. When a configuration file is not found, POAP mode starts.
During startup, a prompt appears asking if you want to abort POAP and continue with a normal setup. You can choose to exit or continue with POAP.
Note
No user intervention is required for POAP to continue. The prompt that asks if you want to abort POAP remains available until the POAP process is complete.
If you exit POAP mode, you enter the normal interactive setup script. If you continue in POAP mode, all the front-panel interfaces are set up in the default configuration.
USB Discovery Phase
When POAP starts, the process searches the root directory of all accessible USB devices for the POAP script file (the Python script file, poap_script.py), configuration files, and system and kickstart images.
If the script file is found on a USB device, POAP begins running the script. If the script file is not found on the USB device, POAP executes DHCP discovery. (When failures occur, the POAP process alternates between USB discovery and DHCP discovery, until POAP succeeds or you manually abort the POAP process.)
If the software image and switch configuration files specified in the configuration script are present, POAP uses those files to install the software and configure the switch. If the software image and switch configuration files are not on the USB device, POAP does some cleanup and starts DHCP phase from the beginning.
DHCP Discovery Phase
The switch sends out DHCP discover messages on the front-panel interfaces or the MGMT interface that solicit DHCP offers from the DHCP server or servers. (See the following figure.) The DHCP client on the Cisco Nexus switch uses the switch serial number in the client-identifier option to identify itself to the DHCP server. The DHCP server can use this identifier to send information, such as the IP address and script filename, back to the DHCP client.
POAP requires a minimum DHCP lease period of 3600 seconds (1 hour). POAP checks the DHCP lease period. If the DHCP lease period is set to less than 3600 seconds (1 hour), POAP does not complete the DHCP negotiation.

The DHCP discover message also solicits the following options from the DHCP server:

• TFTP server name or TFTP server address—The DHCP server relays the TFTP server name or TFTP server address to the DHCP client. The DHCP client uses this information to contact the TFTP server to obtain the script file.
• Bootfile name—The DHCP server relays the bootfile name to the DHCP client. The bootfile name includes the complete path to the bootfile on the TFTP server. The DHCP client uses this information to download the script file.

When multiple DHCP offers that meet the requirement are received, the one arriving first is honored and the POAP process moves to next stage. The device completes the DHCP negotiation (request and acknowledgment) with the selected DHCP server, and the DHCP server assigns an IP address to the switch. If a failure occurs in any of the subsequent steps in the POAP process, the IP address is released back to the DHCP server.
If no DHCP offers meet the requirements, the switch does not complete the DHCP negotiation (request and acknowledgment) and an IP address is not assigned.

Figure 7: DHCP Discovery Process

![CISCO Nexus 9000 Series NX OS Fundamentals Configuration Guide Release 10.4

• DHCP Discovery Process](https://manuals.plus/wp-content/uploads/2023/12 /CISCO-Nexus-9000-Series-NX-OS-Fundamentals-Configuration-Guide-Release-10.4 -DHCP-Discovery-Process.jpg)

POAP Dynamic Breakout
Beginning with Cisco NX-OS Release 7.0(3)I4(1), POAP dynamically breaks out ports in an effort to detect a DHCP server behind one of the broken-out ports. Previously, the DHCP server used for POAP had to be directly connected to a normal cable because breakout cables were not supported.
POAP determines which breakout map (for example, 10gx4, 50gx2, 25gx4, or 10gx2) will bring up the link connected to the DHCP server. If breakout is not supported on any of the ports, POAP skips the dynamic breakout process. After the breakout loop completes, POAP proceeds with the DHCP discovery phase as normal.
Note
For more information on dynamic breakout, see the interfaces configuration guide for your device.

Script Execution Phase
After the device bootstraps itself using the information in the DHCP acknowledgement, the script file is downloaded from the TFTP server.
The switch runs the configuration script, which downloads and installs the software image and downloads a switch-specific configuration file.
However, the configuration file is not applied to the switch at this point, because the software image that currently runs on the switch might not support all of the commands in the configuration file. After the switch reboots, it begins running the new software image, if an image was installed. At that point, the configuration is applied to the switch.
Note
If the switch loses connectivity, the script stops, and the switch reloads its original software images and bootup variables.
Post-Installation Reload Phase
The switch restarts and applies (replays) the configuration on the upgraded software image. Afterward, the switch copies the running configuration to the startup configuration.
POAPv3
PowerOn Auto Provisioning version 3 (POAPv3) is introduced in Cisco NX-OS Release 9.3(5). With this feature you can install license, RPM, and certificate through POAP.\
Perform the following steps to install license or RPM or certificate through POAP.

1. Create a folder on the POAP server with serial number of the box as the name.
2. Create .yaml or .yml file with files to be installed. Make sure the file name is in .yaml or .yml format.
3. Create MD5 checksum for the .yaml or .yml file.
4. Make sure the format of the .yaml file should be similar to the below format:
5. Note that the yaml keywords must match the format shown in above example.
6. Place all files in appropriate path.
7. Update the POAP script with install_path variable as the path where folder with the serial number as name is placed.

The following list provides the guidelines and limitations related to POAPv3:

• YAML is a human friendly data serialization standard for all programming languages. YAML stands for YAML Ain’t Markup Language, and this file format technology is used in documents. These documents are saved in plain text format and are appended with the . yml extension. YAML is the file format and .yml is the file extension.

• YAML is a superset of JSON and the YAML parser understands JSON. YAML file formats are used for configuration management because it is easy to read and comments are useful.

• The Target_image mentioned in yaml should be kept only in the target_system_image path mentioned within POAP script. Relative path is not supported for the Target_image in yaml file.

• Both .yaml and .yml extensions are supported. You have an option to choose to use any of these extensions. If you don’t choose any option, the .yaml extension will be tried first and if it fails the .yml is considered.

• The MD5 files of yaml/yml is required similar to the configuration file. But if the disable_md5 is ‘True’ then the MD5 files of yaml/yml are not required.

• Although ‘install_path’ is set in the POAP script file if no yaml file for device is found, then POAP workflow will proceed with the legacy path, i.e., without any installation of RPMs, licenses and certificates.

• Install reset is highly preferred over write erase if PoAP with RPM installation is done in scenarios apart from Day-0.

• ISSU is the new default for moving to new image via PoAP. Note that you need to use “use_nxos_boot”: True, if legacy boot nxos <> is required.

• The Filetype checks for .pfx,.p12 in trustpoints; .lic in license; and .rpm in rpms and aborts the current POAP if the checks/fileformats are not honoured.

• In case of .rpm, you need to provide the original file name in the yaml file.
  For example: if you renamed customCliGoApp-1.0-1.7.5.x86_64.rpm to custom.rpm then PoAP will bail out indicating the name mismatch.
  To get the original name of rpm:
  bash-4.3$ rpm -qp –qf ‘%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm’ custom.rpm
  customCliGoApp-1.0-1.7.5.x86_64.rpm
  bash-4.3$

• Once ISSU via POAP begins, abort of PoAP will be blocked. If ISSU fails for some reason, then abort capability will be re-enabled.

Guidelines and Limitations for POAP
POAP configuration guidelines and limitations are as follows:

• The bootflash:poap_retry_debugs.log is a file populated by POAP-PNP for internal purposes only. This  file has no relevance in case of any POAP failures.

• Due to limitations in Syslog, securePOAP pem file name characters length is limited to 230 characters, though secure POAP supports 256 characters length for a pem file name.

• The switch software image must support POAP for this feature to function.

• POAP does not support provisioning of the switch after it has been configured and is operational. Only auto-provisioning of a switch with no startup configuration is supported.

• The https_ignore_certificate option should be turned on to use the ignore-certificate keyword with https protocol in POAP. This would enable you to successfully perform HTTPS transfer in the POAP script and without this option https as protocol cannot work with POAP.

• For those who uses HTTP/HTTPS servers for Day 0 provisioning, provisioning instructions will be given based on the MAC information and other related details in the HTTP header. POAP uses these details from HTTP GET headers so that the correct provisioning script is identified and used. This was available for other vendors (and other Cisco OSs).These additional information will be available in HTTP get headers from Cisco NX-OS Release 10.2(1) for Cisco Nexus 9000. This feature will be available by default for POAP and non-POAP HTTP get operations.

• When you use copy http/https GET commands, the following fields are shared as part of the HTTP header:
  Host: IP address
  User-Agent: cisco-nxos
  X-Vendor-SystemMAC: System MAC
  X-Vendor-ModelName: Switch-Model
  X-Vendor-Serial: Serial_Num
  X-Vendor-HardwareVersion: Hardwareversion
  X-Vendor-SoftwareVersion: sw_version
  X-Vendor-Architecture: Architecture

• If you use POAP to bootstrap a Cisco Nexus device that is a part of a virtual port channel (vPC) pair using static port channels on the vPC links, the Cisco Nexus device activates all of its links when POAP starts up. The dually connected device at the end of the vPC links might start sending some or all of its traffic to the port-channel member links that are connected to the Cisco Nexus device, which causes traffic to get lost.
  To work around this issue, you can configure Link Aggregation Control Protocol (LACP) on the vPC links so that the links do not incorrectly start forwarding traffic to the Cisco Nexus device that is being bootstrapped using POAP.

• If you use POAP to bootstrap a Cisco Nexus device that is connected downstream to a Cisco Nexus 9000 Series switch through a LACP port channel, the Cisco Nexus 9000 Series switch defaults to suspend its member port if it cannot bundle it as a part of a port channel. To work around this issue, configure the Cisco Nexus 9000 Series switch to not suspend its member ports by using the no lacp suspend-individual command from interface configuration mode.

• Important POAP updates are logged in the syslog and are available from the serial console.

• Critical POAP errors are logged to the bootflash. The filename format is date-time_poapPID[init,1,2].log, where date-time is in the YYYYMMDD_hhmmss format and PID is the process ID.

• You can bypass the password and the basic POAP configuration by using the skip option at the POAP prompt. When you use the skip option, no password is configured for the admin user. The copy running-config startup-config command is blocked until a valid password is set for the admin user.

• If the boot poap enable command (perpetual POAP) is enabled on the switch, on a reload, a POAP boot is triggered even if there is a startup configuration present. If you do not want to use POAP in this scenario, remove the boot poap enable configuration by using the no boot poap enable command.

• Script logs are saved in the bootflash directory. The filename format is date-time_poap_PID_script.log, where date-time is in the YYYYMMDD_hhmmss format and PID is the process ID.
  You can configure the format of the script log file. Script file log formats are specified in the script. The template of the script log file has a default format; however, you can choose a different format for the script execution log file.

• The POAP feature does not require a license and is enabled by default. However for the POAP feature to function, appropriate licenses must be installed on the devices in the network before the deployment of the network.

• USB support for POAP enables checking a USB device containing the configuration script file in POAP mode. This feature is supported on the Nexus 9300-EX, -FX, -FX2, -FX3, and Nexus 9200-X, -FX2 switches.

• POAP DHCP transaction may fail if the device receives high traffic rate. This issue happens when POAP uses a front panel. To avoid this issue, make sure POAP uses a management port.

• Beginning with NX-OS 7.0(3)I7(4), RFC 3004 (User Class Option for DHCP) is supported. This enables POAP to support user-class option 77 for DHCPv4 and user-class option 15 for DHCPv6. The text displayed for the user class option for both DHCPv4 and DHCPv6 is “Cisco-POAP”.

• With RFC 3004 (User Class Option for DHCP) support, POAP over IPv6 is supported on Nexus 9000 switches.

• Beginning with NX-OS 9.2(2), POAP over IPv6 is supported on Nexus 9504 and Nexus 9508 switches with –R line cards.
  The POAP over IPv6 feature enables the POAP process to use IPv6 when IPv4 fails. The feature is designed to cycle between IPv4 and IPv6 protocols when a connection failure occurs.

• For secure POAP, ensure that DHCP snooping is enabled.

• To support POAP, set firewall rules to block unintended or malicious DHCP servers.

• To maintain system security and make POAP more secure, configure the following:

• Enable DHCP snooping.

• Set firewall rules to block unintended or malicious DHCP servers.

• POAP is supported on both MGMT ports and in-band ports.

• Beginning with Cisco NX-OS Release 10.2(3)F, the Hardware SUDI for POAP/HTTPS feature provides an option to securely download the POAP script.

• To collect the debugging information on POAP, use the show tech-support poap command, post abort of POAP.

• Beginning with Cisco NX-OS Release 10.3(1)F, POAP is supported on Cisco Nexus X9836DM-A line card of the Cisco Nexus 9808 platform switches.

• Beginning with Cisco NX-OS Release 10.4(1)F, POAP is supported on Cisco Nexus X98900CD-A line card of Cisco Nexus 9808 switches.

• Beginning with Cisco NX-OS Release 10.4(1)F, POAP is supported on the Cisco Nexus 9804 platform switches, and Cisco Nexus X98900CD-A and X9836DM-A line cards.

Setting Up the Network Environment to Use POAP

Step 1
Modify the basic configuration script provided by Cisco or create your own script. For information, see the Python Scripting and API Configuration Guide.
Step 2
Every time you make a change to the configuration script, ensure that you recalculate the MD5 checksum by running # f=poap_nexus_script.py ; cat $f | sed ‘/^#md5sum/d’ > $f.md5 ; sed -i “s/^#md5sum=./#md5sum=\”$(md5sum $f.md5 | sed ‘s/ .//’)\”/” $f using a bash shell. For more information, see the Python API Reference Guide.
Step 3
(Optional) Put the POAP script and any other desired software image and switch configuration files on a USB device accessible to the switch.
Step 4
Deploy a DHCP server and configure it with the interface, gateway, and TFTP server IP addresses and a bootfile with the path and name of the configuration script file. (This information is provided to the switch when it first boots.) You do not need to deploy a DHCP server if all software image and switch configuration files are on the USB device.
Step 5
Deploy a TFTP or HTTP server to host the configuration script. In order to trigger the HTTP request to the server, prefix HTTP:// to the TFTP server name. HTTPS is not supported.
Step 6
Add the URL portion into the TFTP script name to show correct path to the file name.
Step 7
Deploy one or more servers to host the software images and configuration files.

Configuring a Switch Using POAP
Before you begin
Make sure that the network environment is set up to use POAP.
Step 1
Install the switch in the network.
Step 2
Power on the switch.
If no configuration file is found, the switch boots in POAP mode and displays a prompt that asks if you want to abort POAP and continue with a normal setup.
No entry is required to continue to boot in POAP mode.
Step 3
(Optional) If you want to exit POAP mode and enter the normal interactive setup script, enter y (yes).
The switch boots, and the POAP process begins.

What to do next
Verify the configuration.

Creating md5 Files
Every time you make a change to the configuration script, ensure that you recalculate the MD5 checksum by running # f=poap_fabric.py ; cat $f | sed ‘/^#md5sum/d’ > $f.md5 ; sed -i “s/^#md5sum=./#md5sum=\”$(md5sum $f.md5 | sed ‘s/ .//’)\”/” $f using a bash shell.
This procedure replaces md5sum in poap_fabric.py with a new value if there was any change in that file.
Note
Steps 1-4 and 7-8 are needed only if you are using the BASH shell. If you have access to any other Linux server, these steps are not required.

Before you begin
Access to the BASH shell.

| Command or Action| Purpose
---|---|---
Step 1| configure terminal
Example:
switch# configure terminal switch(config)#| Enters global configuration mode.
Step 2| feature bash-shell
Example:
switch(config)# feature bash-shell| Enable BASH shell feature.
Step 3| exit
Example:
switch(config)# exit| Exit configuration mode.
Step 4| run bash
Example:
switch# run bash| Open Linux BASH.
Step 5| md5sum /bootflash/nxos.release_number.bin > **/bootflash/nxos.release_number.bin.md5
Example:
bash-4.2$ md5sum /bootflash/nxos.7.0.3.I6.1.bin > /bootflash/nxos.7.0.3.I6.1.bin.md5| Creates md5sum for the .bin file.
Step 6| md5sum /bootflash/poap.cfg > /bootflash/poap.cfg.md5
Example:
bash-4.2$ md5sum /bootflash/poap.cfg > /bootflash/poap.cfg.md5| Creates md5sum for the .cfg file.
Step 7| exit
Example:
switch(config)# exit| Exit the BASH shell.
Step 8| dir | i .md5
Example:
switch# dir | i .md5
65 Jun 09 12:38:48 2017
nxos.7.0.3.I6.1.bin.md5
54 Jun 09 12:39:36 2017 poap.cfg.md5
67299 Jun 09 12:48:58 2017 poap.py.md5| Display the .md5 files.
Step 9| copy bootflash:poap.cfg.md5 scp://ip_address/
Example:
** copy bootflash:poap.cfg.md5 scp://10.1.100.3/ Enter vrf (If no input, current vrf ‘default’ is considered): management Enter username: root [email protected]’s password:
poap.cfg.md5          100%
54       0.1KB/s         00:00
Copy complete.| Uploads the files to the Configuration and Software Server.

Verifying the Device Configuration
To verify the configuration, use one of the following commands:

Displays the contents of the currently running configuration or a subset of that configuration, use the show running-config command in the appropriate mode. :
•  exclude : (Optional) Excludes a specific configuration from the display.
Use the exclude keyword followed by a command argument to exclude a specific configuration from the display.
•  command : (Optional) Displays only a single command or a subset of commands available under a specified command mode.
•  sanitized : (Optional) Displays a sanitized configuration for safe distribution and analysis.
Beginning with Cisco NX-OS Release 10.3(2)F, sanitized keyword is supported on Cisco Nexus 9000 series switches.
show startup-config| Displays the startup configuration.
show time-stamp running-config last-changed| Displays the timestamp when the running configuration was last changed.

The following example shows sample output of show running-config command with the sanitized keyword.
The sanitized configuration is used to share a configuration without exposing some configuration details.
This option masks the sensitive words in running configuration output with