Chapter 1. New and Changed Information

New and Changed Information

Chapter 2. Overview

System Management Features

Chapter 3. Configuring PTP

Information About PTP

PTP Device Types

PTP Process

High Availability for PTP

Licensing Requirements for PTP

Guidelines and Limitations for PTP

Default Settings for PTP

Configuring PTP Globally

Configuring PTP on an Interface

Configuring Multiple PTP Domains

Configuring PTP Grandmaster Clock

Configuring PTP Cost Interface

Configuring clock Identity

Verifying the PTP Configuration

Chapter 4. Configuring User Accounts and RBAC

Information About User Accounts and RBAC

User Roles

Rules

User Role Policies

User Account Configuration Restrictions

User Password Requirements

Guidelines and Limitations for User Accounts

Configuring User Accounts

Creating User Roles and Rules

Creating Feature Groups

Changing User Role Interface Policies

Changing User Role VLAN Policies

Verifying the User Accounts and RBAC Configuration

Configuring User Accounts Default Settings for the User Accounts and RBAC

Chapter 5. Configuring Session Manager

Information About Session Manager

Guidelines and Limitations for Session Manager

Creating a Session

Configuring ACLs in a Session

Verifying a Session

Committing a Session

Saving a Session

Discarding a Session

Configuration Example for Session Manager

Verifying the Session Manager Configuration

Chapter 6. Configuring the Scheduler

Information About the Scheduler

Remote User Authentication

Scheduler Log Files

Licensing Requirements for the Scheduler

Guidelines and Limitations for the Scheduler

Default Settings for the Scheduler

Enabling the Scheduler

Defining the Scheduler Log File Size

Configuring Remote User Authentication

Defining a Job

Deleting a Job

Defining a Timetable

Clearing the Scheduler Log File

Disabling the Scheduler

Verifying the Scheduler Configuration

Creating a Scheduler Job

Scheduling a Scheduler Job

Displaying the Job Schedule

Displaying the Results of Running Scheduler Jobs

Standards for the Scheduler

Chapter 7. Configuring Online Diagnostics

Information About Online Diagnostics

Bootup Diagnostics

Health Monitoring Diagnostics

Expansion Module Diagnostics

Configuring Online Diagnostics

Verifying the Online Diagnostics Configuration

Default Settings for Online Diagnostics

Chapter 8. Configuring NTP

Information About NTP

NTP as a Time Server

Distributing NTP Using CFS

Clock Manager

Virtualization Support

Licensing Requirements for NTP

Guidelines and Limitations for NTP

Default Settings

Configuring NTP Server and Peer

Configuring NTP Authentication

Configuring NTP Access Restrictions

Configuring the NTP Source IP Address

Configuring the NTP Source Interface

Configuring NTP Logging

Enabling CFS Distribution for NTP

Commiting NTP Configuration Changes

Discarding NTP Configuration Changes

Releasing the CFS Session Lock

Verifying the NTP Configuration

Configuration Examples for NTP

Related Documents for NTP

Feature History for NTP

Chapter 9. Configuring System Message Logging

Information About System Message Logging

Syslog Servers

Licensing Requirements for System Message Logging

Guidelines and Limitations for System Message Logging

Default Settings for System Message Logging

Configuring System Message Logging to Terminal Sessions

Configuring System Message Logging to a File

Configuring Module and Facility Messages Logging

Configuring Logging Timestamps

Configuring Syslog Servers

Configuring syslog on a UNIX or Linux System

Configuring syslog Server Configuration Distribution

Displaying and Clearing Log Files

Configuring DOM Logging

Enabling DOM Logging

Disabling DOM Logging

Verifying the DOM Logging Configuration

Verifying the System Message Logging Configuration

Chapter 10. Configuring Smart Call Home

Information About Smart Call Home

Smart Call Home Overview

Smart Call Home Destination Profiles

Smart Call Home Alert Groups

Smart Call Home Message Levels

Call Home Message Formats

Guidelines and Limitations for Smart Call Home

Prerequisites for Smart Call Home

Default Call Home Settings

Registering for Smart Call Home

Configuring Contact Information

Creating a Destination Profile

Modifying a Destination Profile

Associating an Alert Group with a Destination Profile

Adding Show Commands to an Alert Group

Configuring E-Mail Server Details

Configuring Periodic Inventory Notifications

Disabling Duplicate Message Throttling

Enabling or Disabling Smart Call Home

Testing the Smart Call Home Configuration

Verifying the Smart Call Home Configuration

Sample Syslog Alert Notification in Full-Text Format

Sample Syslog Alert Notification in XML Format

Chapter 11. Configuring Rollback

Information About Rollbacks

Guidelines and Limitations for Rollbacks

Creating a Checkpoint

Implementing a Rollback

Verifying the Rollback Configuration

Chapter 12. Configuring DNS

Information About DNS Client

Name Servers

DNS Operation

High Availability

Prerequisites for DNS Clients

Licensing Requirements for DNS Clients

Default Settings for DNS Clients

Configuring DNS Clients

Chapter 13. Configuring SNMP

Information About SNMP

SNMP Functional Overview

SNMP Notifications

SNMPv3

Security Models and Levels for SNMPv1, v2, and v3

User-Based Security Model

CLI and SNMP User Synchronization

Group-Based SNMP Access

Licensing Requirements for SNMP

Guidelines and Limitations for SNMP

Default SNMP Settings

Configuring SNMP Users

Enforcing SNMP Message Encryption

Assigning SNMPv3 Users to Multiple Roles

Creating SNMP Communities

Filtering SNMP Requests

Configuring SNMP Notification Receivers

Configuring SNMP Notification Receivers with VRFs

Filtering SNMP Notifications Based on a VRF

Configuring SNMP for Inband Access

Enabling SNMP Notifications

Configuring Link Notifications

Disabling Link Notifications on an Interface

Enabling One-Time Authentication for SNMP over TCP

Assigning SNMP Switch Contact and Location Information

Configuring the Context to Network Entity Mapping

Disabling SNMP

Verifying the SNMP Configuration

Chapter 14. Configuring RMON

Information About RMON

RMON Alarms

RMON Events

Configuration Guidelines and Limitations for RMON

Configuring RMON Alarms

Configuring RMON Events

Verifying the RMON Configuration

Default RMON Settings

Chapter 15. Configuring SPAN

Information About SPAN

SPAN Sources

Characteristics of Source Ports

SPAN Destinations

Characteristics of Destination Ports

SPAN and ERSPAN Filtering

Guidelines and Limitations for SPAN and ERSPAN Filtering

SPAN and ERSPAN Sampling

Guidelines and Limitations for SPAN and ERSPAN Sampling

SPAN and ERSPAN Truncation

Guidelines and Limitations for SPAN and ERSPAN Truncation

Creating or Deleting a SPAN Session

Configuring an Ethernet Destination Port

Configuring Source Ports

Configuring Source Port Channels or VLANs

Configuring the Description of a SPAN Session

Activating a SPAN Session

Suspending a SPAN Session

Configuring a SPAN Filter

Configuring SPAN Sampling

Configuring SPAN Truncation

Displaying SPAN Information

Chapter 16. Configuring Warp SPAN

Information About Warp SPAN

Guidelines and Limitations for Warp Span

Configuring Warp SPAN

Verifying Warp SPAN Mode Configuration

Feature History for Warp SPAN

Chapter 17. Configuring ERSPAN

Information About ERSPAN

ERSPAN Types

ERSPAN Sources

ERSPAN Destinations

ERSPAN Sessions

Multiple ERSPAN Sessions

ERSPAN Marker Packet

High Availability

Licensing Requirements for ERSPAN

Prerequisites for ERSPAN

Guidelines and Limitations for ERSPAN

Default Settings for ERSPAN

Configuring an ERSPAN Source Session

Configuring an ERSPAN Destination Session

Shutting Down or Activating an ERSPAN Session

Configuring ERSPAN Filtering

Configuring ERSPAN Sampling

Configuring ERSPAN Truncation

Configuring an ERSPAN Marker Packet

Verifying the ERSPAN Configuration

Configuration Example for an ERSPAN Source Session

Configuration Example for an ERSPAN Destination Session

Related Documents

Chapter 18. Performing Software Maintenance Upgrades (SMUs)

About SMUs

Package Management

Prerequisites for SMUs

Guidelines and Limitations for SMUs

Performing a Software Maintenance Upgrade for Cisco NX-OS

Preparing for Package Installation

Copying the Package File to a Local Storage Device or Network Server

Adding and Activating Packages

Committing the Active Package Set

Deactivating and Removing Packages

Displaying Installation Log Information

Chapter 19. Configuring Active Buffer Monitoring

Active Buffer Monitoring Overview

Buffer Histogram Data Access and Collection

Configuring Active Buffer Monitoring

Displaying Buffer Histogram Data

Chapter 20. Configuring Traffic Forwarding Modes

Information About Warp Mode

Guidelines and Limitations for Warp Mode

Enabling and Disabling Warp Mode

Verifying Warp Mode Status

Feature History for Warp Mode

Preface

Audience

Document Conventions

Documentation Feedback

Copyright Page

Chapter 1. New and Changed Information

This chapter contains the following sections:

- New and Changed Information

New and Changed Information

The following table provides an overview of the significant changes made to this configuration guide. The table does not provide an exhaustive list of all changes made to this guide or all new features in a particular release.

New and Changed Features

Feature

Description

Added or Changed in Release

Where Documented

PTP

Added support for configuring PTP on multiple domains, grandmaster capability, PTP cost on interfaces and clock identity.

6.0(2)A8(3)

Configuring Multiple PTP Domains

Configuring PTP Grandmaster Clock

Configuring PTP Cost Interface

Configuring clock Identity

DOM logging

Added support for DOM logging.

6.0(2)A8(1)

Enabling DOM Logging

Software Maintenance Upgrades (SMUs)

Added support for performing Software Maintenance Upgrades (SMUs).

6.0(2)A7(2)

About SMUs

SPAN guidelines

Added guideline about SPAN threshold and the hardware profile buffer span-threshold <xx> CLI command.

6.0(2)A4(1)

Guidelines and Limitations for SPAN and ERSPAN Filtering

SPAN and ERSPAN

Added the ability to filter, sample and truncate packets for these features.

6.0(2)A4(1)

SPAN and ERSPAN Filtering

SPAN and ERSPAN Sampling

SPAN and ERSPAN Truncation

ERSPAN Marker Packet

Introduced a periodical marker packet to carry the original UTC timestamp information and provide a reference for the ERSPAN timestamp.

6.0(2)A4(1)

ERSPAN Marker Packet

Configuring ERSPAN

This feature was introduced.

6.0(2)A1(1)

Configuring ERSPAN

Configuring PTP

This feature was introduced.

6.0(2)A1(1)

Configuring PTP

Chapter 2. Overview

This chapter contains the following sections:

- System Management Features

System Management Features

The system management features documented in this guide are described below:

Feature

Description

Active Buffer Monitoring

The Active Buffer Monitoring feature provides detailed buffer occupancy data to help you detect network congestion, review past events to understand when and how network congestion is affecting network operations, understand historical trending, and identify patterns of application traffic flow.

Warp Mode

In warp mode, the access path is shortened by consolidating the forwarding table into single table, resulting in faster processing of frames and packets. In warp mode, latency is reduced by up to 20 percent.

User Accounts and RBAC

User accounts and role-based access control (RBAC) allow you to define the rules for an assigned role. Roles restrict the authorization that the user has to access management operations. Each user role can contain multiple rules and each user can have multiple roles.

Session Manager

Session Manager allows you to create a configuration and apply it in batch mode after the configuration is reviewed and verified for accuracy and completeness.

Online Diagnostics

Cisco Generic Online Diagnostics (GOLD) define a common framework for diagnostic operations across Cisco platforms. The online diagnostic framework specifies the platform-independent fault-detection architecture for centralized and distributed systems, including the common diagnostics CLI and the platform-independent fault-detection procedures for boot-up and run-time diagnostics.

The platform-specific diagnostics provide hardware-specific fault-detection tests and allow you to take appropriate corrective action in response to diagnostic test results.

System Message Logging

You can use system message logging to control the destination and to filter the severity level of messages that system processes generate. You can configure logging to a terminal session, a log file, and syslog servers on remote systems.

System message logging is based on RFC 3164. For more information about the system message format and the messages that the device generates, see the Cisco NX-OS System Messages Reference.

Smart Call Home

Call Home provides an e-mail-based notification of critical system policies. Cisco NX-OS provides a range of message formats for optimal compatibility with pager services, standard e-mail, or XML-based automated parsing applications. You can use this feature to page a network support engineer, e-mail a Network Operations Center, or use Cisco Smart Call Home services to automatically generate a case with the Technical Assistance Center.

Configuration Rollback

The configuration rollback feature allows users to take a snapshot, or user checkpoint, of the Cisco NX-OS configuration and then reapply that configuration to a switch at any point without having to reload the switch. A rollback allows any authorized administrator to apply this checkpoint configuration without requiring expert knowledge of the features configured in the checkpoint.

SNMP

The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

RMON

RMON is an Internet Engineering Task Force (IETF) standard monitoring specification that allows various network agents and console systems to exchange network monitoring data. Cisco NX-OS supports RMON alarms, events, and logs to monitor Cisco NX-OS devices.

SPAN

The Switched Port Analyzer (SPAN) feature (sometimes called port mirroring or port monitoring) selects network traffic for analysis by a network analyzer. The network analyzer can be a Cisco SwitchProbe, a Fibre Channel Analyzer, or other Remote Monitoring (RMON) probes.

Chapter 3. Configuring PTP

This chapter contains the following sections:

- Information About PTP

- PTP Device Types

- PTP Process

- High Availability for PTP

- Licensing Requirements for PTP

- Guidelines and Limitations for PTP

- Default Settings for PTP

Information About PTP

PTP is a time synchronization protocol for nodes distributed across a network. Its hardware timestamp feature provides greater accuracy than other time synchronization protocols such as the Network Time Protocol (NTP).

A PTP system can consist of a combination of PTP and non-PTP devices. PTP devices include ordinary clocks, boundary clocks, and transparent clocks. Non-PTP devices include ordinary network switches, routers, and other infrastructure devices.

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.

Starting from Cisco NXOS Release 6.0(2)A8(3), PTP supports configuring multiple PTP clocking domains, PTP grandmaster capability, PTP cost on interfaces for slave and passive election, and clock identity.

All the switches in a multi-domain environment, belong to one domain. The switches that are the part of boundary clock, must have multi-domain feature enabled on them. Each domain has user configurable parameters such as domain priority, clock class threshold and clock accuracy threshold. The clocks in each domain remain synchronized with the master clock in that domain. If the GPS in a domain fails, the master clock in the domain synchronizes time and data sets associated with the announce messages from the master clock in the domain where the GPS is active. If the master clock from the highest priority domain does not meet the clock quality attributes, a clock in the subsequent domain that match the criteria is selected. The Best Master Clock Algorithm (BMCA) is used to select the master clock if none of the domains has the desired clock quality attributes. If all the domains have equal priority and the threshold values less than master clock attributes or if the threshold values are greater than the master clock attributes, BMCA is used to select the master clock.

Grandmaster capability feature controls the switch’s ability of propagating its clock to other devices that it is connected to. When the switch receives announce messages on an interface, it checks the clock class threshold and clock accuracy threshold values. If the values of these parameters are within the predefined limits, then the switch acts as per PTP standards specified in IEEE 1588v2. If the switch does not receive announce messages from external sources or if the parameters of the announce messages received are not within the predefined limits, the port state will be changed to listening mode. On a switch with no slave ports, the state of all the PTP enabled ports is rendered as listening and on a switch with one slave port, the BMCA is used to determine states on all PTP enabled ports. Convergence time prevents timing loops at the PTP level when grandmaster capability is disabled on a switch. If the slave port is not selected on the switch, all the ports on the switch will be in listening state for a minimum interval specified in the convergence time. The convergence time range is from 3 to 2600 seconds and the default value is 3 seconds.

The interface cost applies to each PTP enabled port if the switch has more than one path to grandmaster clock. The port with the least cost value is elected as slave and the rest of the ports will remain as passive ports.

The clock identity is a unique 8-octet array presented in the form of a character array based on the switch MAC address. The clock identity is determined from MAC according to the IEEE1588v2-2008 specifications. The clock ID is a combination of bytes in a VLAN MAC address as defined in IEEE1588v2.

Only Cisco Nexus 3000 Series switches support PTP. Cisco Nexus 3100 Series switches do not support this feature.

PTP Device Types

The following clocks are common PTP devices:

Ordinary clock

Communicates with the network based on a single physical port, similar to an end host. An ordinary clock can function as a grandmaster clock.

Boundary clock

Typically has several physical ports, with each port behaving like a port of an ordinary clock. However, each port shares the local clock, and the clock data sets are common to all ports. Each port decides its individual state, either master (synchronizing other ports connected to it) or slave (synchronizing to a downstream port), based on the best clock available to it through all of the other ports on the boundary clock. Messages that are related to synchronization and establishing the master-slave hierarchy terminate in the protocol engine of a boundary clock and are not forwarded.

Transparent clock

Forwards all PTP messages like an ordinary switch or router but measures the residence time of a packet in the switch (the time that the packet takes to traverse the transparent clock) and in some cases the link delay of the ingress port for the packet. The ports have no state because the transparent clock does not need to synchronize to the grandmaster clock.

There are two kinds of transparent clocks:

End-to-end transparent clock

Measures the residence time of a PTP message and accumulates the times in the correction field of the PTP message or an associated follow-up message.

Peer-to-peer transparent clock

Measures the residence time of a PTP message and computes the link delay between each port and a similarly equipped port on another node that shares the link. For a packet, this incoming link delay is added to the residence time in the correction field of the PTP message or an associated follow-up message.

Note

PTP operates only in boundary clock mode. We recommend that you deploy a Grand Master Clock (10 MHz) upstream. The servers contain clocks that require synchronization and are connected to the switch.

End-to-end transparent clock and peer-to-peer transparent clock modes are not supported.

PTP Process

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. 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.

High Availability for PTP

Stateful restarts are not supported for PTP.

Licensing Requirements for PTP

PTP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.

Guidelines and Limitations for PTP

- In a Cisco Nexus 3500 only environment, PTP clock correction is expected to be in the 1- to 2-digit range, from 1 to 99 nanoseconds. However, in a mixed environment, PTP clock correction is expected to be up to 3 digits, from 100 to 999 nanoseconds.

- 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 only multicast communication. Negotiated unicast communication is not supported.

- PTP is limited to a single domain per network.

- Forwarding PTP management packets is not supported.

- PTP-capable ports do not identify PTP packets and do not time-stamp or redirect those packets unless you enable PTP on those ports.

- 1 packet per second (1 pps) input is not supported.

- PTP over IPv6 is not supported.

- Cisco Nexus 3500 Switches support a maximum of 32 PTP sessions

- Cisco Nexus switches should be synchronized from the neighboring master using a synchronization log interval that ranges from –3 to 1.

Default Settings for PTP

The following table lists the default settings for PTP parameters.

Default PTP Parameters

Parameters

Default

PTP

Disabled

PTP version

2

PTP domain

0. PTP multi domain is disabled by default.

PTP priority 1 value when advertising the clock

255

PTP priority 2 value when advertising the clock

255

PTP announce interval

1 log second

PTP sync interval

1 log second

PTP announce timeout

3 announce intervals

PTP minimum delay request interval

1 log second

PTP VLAN

1

Configuring PTP Globally

You can enable or disable PTP globally on a device. You can also configure various PTP clock parameters to help determine which clock in the network has the highest priority to be selected as the grandmaster.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # [no] feature ptp

Enables or disables PTP on the device.

Note:
Enabling PTP on the switch does not enable PTP on each interface.

Step 3

switch(config) # [no] ptp source ip-address [vrf vrf]

Configures the source IP address for all PTP packets.

The ip-address can be in IPv4 format.

Step 4

switch(config) # [no] ptp domain number

(Optional)
Configures the domain number to use for this clock. PTP domains allow you to use multiple independent PTP clocking subdomains on a single network.

The range for the number is from 0 to 128.

Step 5

switch(config) # [no] ptp priority1 value

(Optional)
Configures the priority1 value to use when advertising this clock. This value overrides the default criteria (clock quality, clock class, and so on) for the best master clock selection. Lower values take precedence.

The range for the value is from 0 to 255.

Step 6

switch(config) # [no] ptp priority2 value

(Optional)
Configures the priority2 value to use when advertising this clock. This value is used to decide between two devices that are otherwise equally matched in the default criteria. For example, you can use the priority2 value to give a specific switch priority over other identical switches.

The range for the value is from 0 to 255.

Step 7

switch(config) # show ptp brief

(Optional)
Displays the PTP status.

Step 8

switch(config) # show ptp clock

(Optional)
Displays the properties of the local clock.

Step 9

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure PTP globally on the device, specify the source IP address for PTP communications, and configure a preference level for the clock:

switch# configure terminal
switch(config)# feature ptp
switch(config)# ptp source 10.10.10.1
switch(config)# ptp priority1 1
switch(config)# ptp priority2 1
switch(config)# show ptp brief
PTP port status
-----------------------
Port State
------- --------------
switch(config)# show ptp clock
PTP Device Type: Boundary clock
Clock Identity : 0:22:55:ff:ff:79:a4:c1
Clock Domain: 0
Number of PTP ports: 0
Priority1 : 1
Priority2 : 1
Clock Quality:
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset From Master : 0
Mean Path Delay : 0
Steps removed : 0
Local clock time:Sun Jul 3 14:13:24 2011
switch(config)#

Configuring PTP on an Interface

After you globally enable PTP, it is not enabled on all supported interfaces by default. You must enable PTP interfaces individually.

Before You Begin

Make sure that you have globally enabled PTP on the switch and configured the source IP address for PTP communication.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # interface ethernet slot/port

Specifies the interface on which you are enabling PTP and enters interface configuration mode.

Step 3

switch(config-if) # [no] feature ptp

Enables or disables PTP on an interface.

Step 4

switch(config-if) # [no] ptp announce {interval log seconds | timeout count}

(Optional)
Configures the interval between PTP announce messages on an interface or the number of PTP intervals before a timeout occurs on an interface.

The range for the PTP announcement interval is from 0 to 4 seconds, and the range for the interval timeout is from 2 to 10.

Step 5

switch(config-if) # [no] ptp delay request minimum interval log seconds

(Optional)
Configures the minimum interval allowed between PTP delay-request messages when the port is in the master state.

The range is from log(-6) to log(1) seconds. Where, log(-2) = 2 frames per second.

Step 6

switch(config-if) # [no] ptp sync interval log seconds

(Optional)
Configures the interval between PTP synchronization messages on an interface.

The range for the PTP synchronization interval is from -3 log second to 1 log second

Step 7

switch(config-if) # [no] ptp vlan vlan-id

(Optional)
Specifies the VLAN for the interface where PTP is being enabled. You can only enable PTP on one VLAN on an interface.

The range is from 1 to 4094.

Step 8

switch(config-if) # show ptp brief

(Optional)
Displays the PTP status.

Step 9

switch(config-if) # show ptp port interface interface slot/port

(Optional)
Displays the status of the PTP port.

Step 10

switch(config-if)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure PTP on an interface and configure the intervals for the announce, delay-request, and synchronization messages:

switch# configure terminal
switch(config)# interface ethernet 2/1
switch(config-if)# ptp
switch(config-if)# ptp announce interval 3
switch(config-if)# ptp announce timeout 2
switch(config-if)# ptp delay-request minimum interval 4
switch(config-if)# ptp sync interval -1
switch(config-if)# show ptp brief
PTP port status
-----------------------
Port State
------- --------------
Eth2/1 Master
switch(config-if)# show ptp port interface ethernet 1/1
PTP Port Dataset: Eth1/1
Port identity: clock identity: f4:4e:05:ff:fe:84:7e:7c
Port identity: port number: 0
PTP version: 2
Port state: Slave
VLAN info: 1
Delay request interval(log mean): 0
Announce receipt time out: 3
Peer mean path delay: 0
Announce interval(log mean): 1
Sync interval(log mean): 1
Delay Mechanism: End to End
Cost: 255
Domain: 5
switch(config-if)#

Configuring Multiple PTP Domains

You can configure multiple PTP clocking domains on a single network. Each domain has a priority value associated with it. The default value is 255.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # [no] feature ptp

Enables or disables PTP on the device.

Note:
Enabling PTP on the switch does not enable PTP on each interface.

Step 3

switch(config) # [no] ptp source ip-address [vrf vrf]

Configures the source IP address for all PTP packets.

The ip-address can be in IPv4 format.

Step 4

switch(config) # [no] ptp multi-domain

Enables configuring multi domain feature on the switch. It also allow you to set the attributes such as priority, clock-class threshold , clock-accuracy threshold, transition priorities etc. on the switch.

Step 5

switch(config) # [no] ptp domain value priority value

Specify the values for the domain and priority.

The range for the domain value is from 0 to 127. The default value of the domain is 0

The range for the priority value is from 0 to 255. The default value of the priority is 255

Step 6

switch(config) # [no] ptp domain value clock-class-threshold value

Specify the values for domain and clock class threshold. The default value is 248.

The range for the domain value is from 0 to 127.

The range for the clock-class-threshold value is from 0 to 255.

Note:
It is not necessary that a clock class threshold value ensure election of the slave clock on any ports. The switch uses this value to determine whether the source clock is traceable. If the clock class value from the peer is higher or equal than the clock class threshold value in a domain, the switch runs BMCA to elect the slave port from a domain. If none of the domains has the clock class below the threshold value, the switch runs BMCA on all the PTP enabled ports to elect the best clock.

Step 7

switch(config) # [no] ptp domain value clock-accuracy-threshold value

Specify the values for domain and clock accuracy threshold. The default value is 254.

The range for the domain value is from 0 to 127.

The range for the clock-accuracy-threshold value is from 0 to 255.

Step 8

switch(config) # [no] ptp multi-domain transition-attributes priority1 value

Sets the domain transition-attributes priority1 value that is used when sending a packet out from this domain to a peer domain. The value of the priority1 in the announce message from the remote port is replaced by the value of domain transition-attributes priority1 when the announce message has to be transmitted to a peer in a domain, that is different from that of the slave interface. The default value is 255.

The range for the transition-attributes priority1 value is from 0 to 255.

Step 9

switch(config) # [no] ptp multi-domain transition-attributes priority2 value

Sets the domain transition-attributes priority2 value that is used when sending a packet out from this domain to a peer domain. The value of the priority2 in the announce message from the remote port is replaced by the value of domain transition-attributes priority2 when the announce message has to be transmitted to a peer in a domain, that is different from that of the slave interface. The default value is 255.

The range for the transition-attributes priority2 value is from 0 to 255.

Step 10

switch(config-if) # [no] ptp domain value

Associates a domain on a PTP enabled interface. If you do not configure the domain specifically on an interface, it takes the default value (0).

The range for the domain value is from 0 to 127.

The following example shows the PTP domains configured on a switch:

switch(config)# show ptp domain data
MULTI DOMAIN : ENABLED
GM CAPABILITY : ENABLED
PTP DEFAULT DOMAIN : 0
PTP TRANSITION PRIORITY1 : 20
PTP TRANSITION PRIORITY2 : 255
PTP DOMAIN PROPERTY
Domain-Number Domain-Priority Clock-Class Clock-Accuracy Ports
0         255        248             254             Eth1/1
1           1         1              254

switch(config)#

The following example shows the domains associated with each PTP enabled interfaces:

switch(config)# show ptp interface domain
PTP port interface domain
--------------------------
Port         Domain
-------  -----------------
Eth1/1        0
1         1              254

switch(config)#

Configuring PTP Grandmaster Clock

You can configure convergence time to prevent timing loops at the PTP level when grandmaster capability is disabled on a switch. Grandmaster capability is enabled on the device by default.

.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # [no] feature ptp

Enables or disables PTP on the device.

Note:
Enabling PTP on the switch does not enable PTP on each interface.

Step 3

switch(config) # [no] ptp source ip-address [vrf vrf]

Configures the source IP address for all PTP packets.

The ip-address can be in IPv4 format.

Step 4

switch(config) # no ptp grandmaster-capable [ convergence-time]

Disables grandmaster capability on the switch. Prevents the device from acting as a grandmaster when there is no external grandmaster available in any domains. The default convergence time is 30 seconds.

Step 5

switch(config) # [no] ptp domain value clock-class-threshold value

Specify the values for domain and clock class threshold. Clock class threshold defines the threshold value of clock class that the device uses to determine whether the source clock can be considered as a grandmaster clock.

The range for the domain value is from 0 to 127.

The range for the clock-class-threshold value is from 0 to 255.

Note:
The switch uses this value to determine whether the source clock is traceable. If the clock class value from all the peers is higher than the clock class threshold value, the BMCA may change all the port state to listening.

Step 6

switch(config) # [no] ptp domain value clock-accuracy-threshold value

Specify the values for domain and clock accuracy threshold

The range for the domain value is from 0 to 127.

The range for the clock-accuracy-threshold value is from 0 to 255.

Step 7

switch(config) # ptp grandmaster-capable

Enables grandmaster capability on a switch.

The following example displays the PTP clock information:

switch(config-if)# show ptp clock
PTP Device Type: Boundary clock
Clock Identity : f4:4e:05:ff:fe:84:7e:7c
Clock Domain: 5
Number of PTP ports: 2
Priority1 : 129
Priority2 : 255
Clock Quality:
Class : 248
Accuracy : 254
Offset (log variance) : 65535
Offset From Master : 0
Mean Path Delay : 391
Steps removed : 1
Local clock time:Wed Nov 9 10:31:21 2016
switch(config-if)#

Configuring PTP Cost Interface

You can configure interface cost on each PTP enabled port on a Cisco Nexus 3500 switch. The cost applies to each PTP enabled port if the switch has more than one path to grandmaster clock.

.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # [no] feature ptp

Enables or disables PTP on the device.

Note:
Enabling PTP on the switch does not enable PTP on each interface.

Step 3

switch(config) # [no] ptp source ip-address [vrf vrf]

Configures the source IP address for all PTP packets.

The ip-address can be in IPv4 format.

Step 4

switch(config-if) # [no] feature ptp

Enables or disables PTP on the interface.

Step 5

switch(config-if) # [no] ptp cost value

Associate cost on a PTP enabled interface. The interface having the least cost becomes the slave interface.

The range for the cost is from 0 to 255. The default value is 255.

The following example shows cost that is associated with each PTP enabled interfaces:

switch(config)# show ptp cost
PTP port costs
-----------------------
Port         Cost
-------  --------------
Eth1/1        255
switch(config)#

Configuring clock Identity

You can configure clock identity on a Cisco Nexus 3500 switch. The default clock identity is a unique 8-octet array presented in the form of a character array based on the switch MAC address.

.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # [no] feature ptp

Enables or disables PTP on the device.

Note:
Enabling PTP on the switch does not enable PTP on each interface.

Step 3

switch(config-if) # ptp clock-identity MAC Address

Assigns 6 byte MAC address for PTP clock-identity. Default clock identity is based on the MAC address of the switch. The clock-identity is defined as per IEEE standard (MAC-48 Byte0 | MAC-48 Byte1 | MAC-48 Byte2 | FF | FE | MAC-48 Bytes3-5).

Verifying the PTP Configuration

Use one of the following commands to verify the configuration:

PTP Show Commands

Command

Purpose

show ptp brief

Displays the PTP status.

show ptp clock

Displays the properties of the local clock, including the clock identity.

show ptp clock foreign-masters-record

Displays the state of foreign masters known to the 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 corrections

Displays the last few PTP corrections.

show ptp parent

Displays the properties of the PTP parent.

show ptp port interface ethernet slot/port

Displays the status of the PTP port on the switch.

show ptp domain data

Displays multiple domain data, domain priority, clock threshold and information about grandmaster capabilities.

show ptp interface domain

Displays information about the interface to domain association.

show ptp cost

Displays PTP port to cost association.

Chapter 4. Configuring User Accounts and RBAC

This chapter contains the following sections:

- Information About User Accounts and RBAC

- Guidelines and Limitations for User Accounts

- Configuring User Accounts

- Verifying the User Accounts and RBAC Configuration

- Configuring User Accounts Default Settings for the User Accounts and RBAC

Information About User Accounts and RBAC

Cisco Nexus Series switches use role-based access control (RBAC) to define the amount of access that each user has when the user logs into the switch.

With RBAC, you define one or more user roles and then specify which management operations each user role is allowed to perform. When you create a user account for the switch, you associate that account with a user role, which then determines what the individual user is allowed to do on the switch.

- User Roles

- Rules

- User Role Policies

- User Account Configuration Restrictions

- User Password Requirements

User Roles

User roles contain rules that define the operations allowed for the user who is assigned the role. Each user role can contain multiple rules and each user can have multiple roles. For example, if role1 allows access only to configuration operations, and role2 allows access only to debug operations, users who belong to both role1 and role2 can access configuration and debug operations. You can also limit access to specific VLANs, and interfaces.

The switch provides the following default user roles:

network-admin (superuser)

Complete read and write access to the entire switch.

network-operator

Complete read access to the switch.

Note

If you belong to multiple roles, you can execute a combination of all the commands permitted by these roles. Access to a command takes priority over being denied access to a command. For example, suppose a user has RoleA, which denied access to the configuration commands. However, the user also has RoleB, which has access to the configuration commands. In this case, the user has access to the configuration commands.

Note

Only network-admin user can perform a Checkpoint or Rollback in the RBAC roles. Though other users have these commands as a permit rule in their role, the user access is denied when you try to execute these commands.

Rules

The rule is the basic element of a role. A rule defines what operations the role allows the user to perform. You can apply rules for the following parameters:

Command

A command or group of commands defined in a regular expression.

Feature

Commands that apply to a function provided by the Cisco Nexus device. Enter the show role feature command to display the feature names available for this parameter.

Feature group

Default or user-defined group of features. Enter the show role feature-group command to display the default feature groups available for this parameter.

These parameters create a hierarchical relationship. The most basic control parameter is the command. The next control parameter is the feature, which represents all commands associated with the feature. The last control parameter is the feature group. The feature group combines related features and allows you to easily manage the rules.

You can configure up to 256 rules for each role. The user-specified rule number determines the order in which the rules are applied. Rules are applied in descending order. For example, if a role has three rules, rule 3 is applied before rule 2, which is applied before rule 1.

User Role Policies

You can define user role policies to limit the switch resources that the user can access, or to limit access to interfaces and VLANs.

User role policies are constrained by the rules defined for the role. For example, if you define an interface policy to permit access to specific interfaces, the user does not have access to the interfaces unless you configure a command rule for the role to permit the interface command.

If a command rule permits access to specific resources (interfaces, VLANs), the user is permitted to access these resources, even if the user is not listed in the user role policies associated with that user.

User Account Configuration Restrictions

The following words are reserved and cannot be used to configure users:

- adm

- bin

- daemon

- ftp

- ftpuser

- games

- gdm

- gopher

- halt

- lp

- mail

- mailnull

- man

- mtsuser

- news

- nobody

- san-admin

- shutdown

- sync

- sys

- uucp

- xfs

Caution

User Password Requirements

Cisco Nexus device passwords are case sensitive and can contain alphanumeric characters only. Special characters, such as the dollar sign ($) or the percent sign (%), are not allowed.

Note

Starting from Cisco NX-OS Release 7.2(0)N1(1), special characters, such as the dollar sign ($) or the percent sign (%), can be used in Cisco Nexus device passwords.

If a password is trivial (such as a short, easy-to-decipher password), the Cisco Nexus device rejects the password. Be sure to configure a strong password for each user account. 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

The following are examples of strong passwords:

- If2CoM18

- 2009AsdfLkj30

- Cb1955S21

Note

For security reasons, user passwords do not display in the configuration files.

Guidelines and Limitations for User Accounts

User accounts have the following guidelines and limitations when configuring user accounts and RBAC:

- Up to 256 rules can be added to a user role.

- A maximum of 64 user roles can be assigned to a user account.

- You can assign a user role to more that one user account.

- Predefined roles such as network-admin, network-operator, and san-admin are not editable.

- Add, delete, and editing of rules is not supported for the SAN admin user role.

- The interface, VLAN, and/or VSAN scope cannot be changed for the SAN admin user role.

Note

A user account must have at least one user role.

Configuring User Accounts

Note

Changes to user account attributes do not take effect until the user logs in and creates a new session.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# show role

(Optional)
Displays the user roles available. You can configure other user roles, if necessary.

Step 3

switch(config) # username user-id [password password] [expire date] [role role-name]

Configures a user account.

The user-id is a case-sensitive, alphanumeric character string with a maximum of 28 characters.

The default password is undefined.

Note:
If you do not specify a password, the user might not be able to log into the switch.

The expire date option format is YYYY-MM-DD. The default is no expiry date.

Step 4

switch(config) # exit

Exists global configuration mode.

Step 5

switch# show user-account

(Optional)
Displays the role configuration.

Step 6

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure a user account:

switch# configure terminal
switch(config)# username NewUser password 4Ty18Rnt
switch(config)# exit
switch# show user-account

Creating User Roles and Rules

The rule number that you specify determines the order in which the rules are applied. Rules are applied in descending order. For example, if a role has three rules, rule 3 is applied before rule 2, which is applied before rule 1.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # role name role-name

Specifies a user role and enters role configuration mode.

The role-name argument is a case-sensitive, alphanumeric character string with a maximum of 16 characters.

Step 3

switch(config-role) # rule number {deny | permit} command command-string

Configures a command rule.

The command-string can contain spaces and regular expressions. For example, interface ethernet * includes all Ethernet interfaces.

Repeat this command for as many rules as needed.

Step 4

switch(config-role)# rule number {deny | permit} {read | read-write}

Configures a read-only or read-and-write rule for all operations.

Step 5

switch(config-role)# rule number {deny | permit} {read | read-write} feature feature-name

Configures a read-only or read-and-write rule for a feature.

Use the show role feature command to display a list of features.

Repeat this command for as many rules as needed.

Step 6

switch(config-role)# rule number {deny | permit} {read | read-write} feature-group group-name

Configures a read-only or read-and-write rule for a feature group.

Use the show role feature-group command to display a list of feature groups.

Repeat this command for as many rules as needed.

Step 7

switch(config-role)# description text

(Optional)
Configures the role description. You can include spaces in the description.

Step 8

switch(config-role)# end

Exits role configuration mode.

Step 9

switch# show role

(Optional)
Displays the user role configuration.

Step 10

switch# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to create user roles and specify rules:

switch# configure terminal
switch(config)# role name UserA
switch(config-role)# rule deny command clear users
switch(config-role)# rule deny read-write
switch(config-role)# description This role does not allow users to use clear commands
switch(config-role)# end
switch(config)# show role

Creating Feature Groups

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # role feature-group group-name

Specifies a user role feature group and enters role feature group configuration mode.

The group-name is a case-sensitive, alphanumeric character string with a maximum of 32 characters.

Step 3

switch(config) # exit

Exits global configuration mode.

Step 4

switch# show role feature-group

(Optional)
Displays the role feature group configuration.

Step 5

switch# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to create a feature group:

switch# configure terminal
switch(config) # role feature-group group1
switch(config) # exit
switch# show role feature-group
switch# copy running-config startup-config
switch#

Changing User Role Interface Policies

You can change a user role interface policy to limit the interfaces that the user can access. Specify a list of interfaces that the role can access. You can specify it for as many interfaces as needed.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # role name role-name

Specifies a user role and enters role configuration mode.

Step 3

switch(config-role) # interface policy deny

Enters role interface policy configuration mode.

Step 4

switch(config-role-interface) # permit interface interface-list

Specifies a list of interfaces that the role can access.

Repeat this command for as many interfaces as needed.

For this command, you can specify Ethernet interfaces.

Step 5

switch(config-role-interface) # exit

Exits role interface policy configuration mode.

Step 6

switch(config-role) # show role

(Optional)
Displays the role configuration.

Step 7

switch(config-role) # copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to change a user role interface policy to limit the interfaces that the user can access:

switch# configure terminal
switch(config)# role name UserB
switch(config-role)# interface policy deny
switch(config-role-interface)# permit interface ethernet 2/1
switch(config-role-interface)# permit interface fc 3/1
switch(config-role-interface)# permit interface vfc 30/1

Changing User Role VLAN Policies

You can change a user role VLAN policy to limit the VLANs that the user can access.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # role name role-name

Specifies a user role and enters role configuration mode.

Step 3

switch(config-role )# vlan policy deny

Enters role VLAN policy configuration mode.

Step 4

switch(config-role-vlan # permit vlan vlan-list

Specifies a range of VLANs that the role can access.

Repeat this command for as many VLANs as needed.

Step 5

switch(config-role-vlan) # exit

Exits role VLAN policy configuration mode.

Step 6

switch# show role

(Optional)
Displays the role configuration.

Step 7

switch# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

Verifying the User Accounts and RBAC Configuration

Use one of the following commands to verify the configuration:

Command

Purpose

show role [role-name]

Displays the user role configuration

show role feature

Displays the feature list.

show role feature-group

Displays the feature group configuration.

show startup-config security

Displays the user account configuration in the startup configuration.

show running-config security [all]

Displays the user account configuration in the running configuration. The all keyword displays the default values for the user accounts.

show user-account

Displays user account information.

Configuring User Accounts Default Settings for the User Accounts and RBAC

The following table lists the default settings for user accounts and RBAC parameters.

Default User Accounts and RBAC Parameters

Parameters

Default

User account password

Undefined.

User account expiry date

None.

Interface policy

All interfaces are accessible.

VLAN policy

All VLANs are accessible.

VFC policy

All VFCs are accessible.

VETH policy

All VETHs are accessible.

Chapter 5. Configuring Session Manager

This chapter contains the following sections:

- Information About Session Manager

- Guidelines and Limitations for Session Manager

- Verifying the Session Manager Configuration

Information About Session Manager

Session Manager allows you to implement your configuration changes in batch mode. Session Manager works in the following phases:

- Configuration session—Creates a list of commands that you want to implement in session manager mode.

- Validation—Provides a basic semantic check on your configuration. Cisco NX-OS returns an error if the semantic check fails on any part of the configuration.

- Verification—Verifies the configuration as a whole, based on the existing hardware and software configuration and resources. Cisco NX-OS returns an error if the configuration does not pass this verification phase.

- Commit— Cisco NX-OS verifies the complete configuration and implements the changes atomically to the device. If a failure occurs, Cisco NX-OS reverts to the original configuration.

- Abort—Discards the configuration changes before implementation.

You can optionally end a configuration session without committing the changes. You can also save a configuration session.

Guidelines and Limitations for Session Manager

Session Manager has the following configuration guidelines and limitations:

- Session Manager supports only the access control list (ACL) feature.

- You can create up to 32 configuration sessions.

- You can configure a maximum of 20,000 commands across all sessions.

Creating a Session

You can create up to 32 configuration sessions.

Procedure

Command or Action

Purpose

Step 1

switch# configure session name

Creates a configuration session and enters session configuration mode. The name can be any alphanumeric string.

Displays the contents of the session.

Step 2

switch(config-s)# show configuration session [name]

(Optional)
Displays the contents of the session.

Step 3

switch(config-s)# save location

(Optional)
Saves the session to a file. The location can be in bootflash or volatile.

Configuring ACLs in a Session

You can configure ACLs within a configuration session.

Procedure

Command or Action

Purpose

Step 1

switch# configure session name

Creates a configuration session and enters session configuration mode. The name can be any alphanumeric string.

Step 2

switch(config-s)# ip access-list name

Creates an ACL.

Step 3

switch(config-s-acl)# permit protocol source destination

(Optional)
Adds a permit statement to the ACL.

Step 4

switch(config-s-acl)# interface interface-type number

Enters interface configuration mode.

Step 5

switch(config-s-if)# ip port access-group name in

Adds a port access group to the interface.

Step 6

switch# show configuration session [name]

(Optional)
Displays the contents of the session.

Verifying a Session

To verify a session, use the following command in session mode:

Command

Purpose

switch(config-s)# verify [verbose]

Verifies the commands in the configuration session.

Committing a Session

To commit a session, use the following command in session mode:

Command

Purpose

switch(config-s)# commit [verbose]

Commits the commands in the configuration session.

Saving a Session

To save a session, use the following command in session mode:

Command

Purpose

switch(config-s)# save location

(Optional) Saves the session to a file. The location can be in bootflash or volatile.

Discarding a Session

To discard a session, use the following command in session mode:

Command

Purpose

switch(config-s)# abort

Discards the configuration session without applying the commands.

Configuration Example for Session Manager

The following example shows how to create a configuration session for ACLs:

switch# configure session name test2

switch(config-s)# ip access-list acl2

switch(config-s-acl)# permit tcp any any

switch(config-s-acl)# exit

switch(config-s)# interface Ethernet 1/4

switch(config-s-ip)# ip port access-group acl2 in

switch(config-s-ip)# exit

switch(config-s)# verify

switch(config-s)# exit

switch# show configuration session test2

Verifying the Session Manager Configuration

To verify Session Manager configuration information, perform one of the following tasks:

Command

Purpose

show configuration session [name]

Displays the contents of the configuration session.

show configuration session status [name]

Displays the status of the configuration session.

show configuration session summary

Displays a summary of all the configuration sessions.

Chapter 6. Configuring the Scheduler

This chapter contains the following sections:

- Information About the Scheduler

- Licensing Requirements for the Scheduler

- Guidelines and Limitations for the Scheduler

- Default Settings for the Scheduler

- Verifying the Scheduler Configuration

- Standards for the Scheduler

Information About the Scheduler

The scheduler allows you to define and set a timetable for maintenance activities such as the following:

- Quality of service policy changes

- Data backup

- Saving a configuration

Jobs consist of a single command or multiple commands that define routine activities. Jobs can be scheduled one time or at periodic intervals.

The scheduler defines a job and its timetable as follows:

Job

A routine task or tasks defined as a command list and completed according to a specified schedule.

Schedule

The timetable for completing a job. You can assign multiple jobs to a schedule.

A schedule is defined as either periodic or one-time only:

- Periodic mode— A recurring interval that continues until you delete the job. You can configure the following types of intervals:

- Daily— Job is completed once a day.

- Weekly— Job is completed once a week.

- Monthly—Job is completed once a month.

- Delta—Job begins at the specified start time and then at specified intervals (days:hours:minutes).

- One-time mode—Job is completed only once at a specified time.

- Remote User Authentication

- Scheduler Log Files

Remote User Authentication

Before starting a job, the scheduler authenticates the user who created the job. Because user credentials from a remote authentication are not retained long enough to support a scheduled job, you must locally configure the authentication passwords for users who create jobs. These passwords are part of the scheduler configuration and are not considered a locally configured user.

Before starting the job, the scheduler validates the local password against the password from the remote authentication server.

Scheduler Log Files

The scheduler maintains a log file that contains the job output. If the size of the job output is greater than the size of the log file, the output is truncated.

Licensing Requirements for the Scheduler

This feature does not require a license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.

Guidelines and Limitations for the Scheduler

- The scheduler can fail if it encounters one of the following while performing a job:

- If a feature license is expired when a job for that feature is scheduled.

- If a feature is disabled at the time when a job for that feature is scheduled.

- Verify that you have configured the time. The scheduler does not apply a default timetable. If you create a schedule, assign jobs, and do not configure the time, the job is not started.

- While defining a job, verify that no interactive or disruptive commands (for example, copy bootflash: file ftp:URI, write erase, and other similar commands) are specified because the job is started and conducted noninteractively.

Default Settings for the Scheduler

Default Command Scheduler Parameters

Parameters

Default

Scheduler state

Disabled

Log file size

16 KB

Enabling the Scheduler

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # feature scheduler

Enables the scheduler.

Step 3

switch(config) # show scheduler config

(Optional)
Displays the scheduler configuration.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to enable the scheduler:

switch# configure terminal
switch(config)# feature scheduler
switch(config)# show scheduler config
config terminal
feature scheduler
scheduler logfile size 16
end
switch(config)#

Defining the Scheduler Log File Size

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # scheduler logfile size value

Defines the scheduler log file size in kilobytes.

The range is from 16 to 1024. The default log file size is 16.

Note:
If the size of the job output is greater than the size of the log file, the output is truncated.

Step 3

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to define the scheduler log file size:

switch# configure terminal
switch(config)# scheduler logfile size 1024
switch(config)#

Configuring Remote User Authentication

Remote users must authenticate with their clear text password before creating and configuring jobs.

Remote user passwords are always shown in encrypted form in the output of the show running-config command. The encrypted option (7) in the command supports the ASCII device configuration.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # scheduler aaa-authentication password [0 | 7] password

Configures a password for the user who is currently logged in.

To configure a clear text password, enter 0.

To configure an encrypted password, enter 7.

Step 3

switch(config) # scheduler aaa-authentication username name password [0 | 7] password

Configures a clear text password for a remote user.

Step 4

switch(config) # show running-config | include "scheduler aaa-authentication"

(Optional)
Displays the scheduler password information.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure a clear text password for a remote user called NewUser:

switch# configure terminal
switch(config) # scheduler aaa-authentication
username NewUser password z98y76x54b
switch(config) # copy running-config startup-config
switch(config) #

Defining a Job

Once a job is defined, you cannot modify or remove a command. To change the job, you must delete it and create a new one.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # scheduler job name name

Creates a job with the specified name and enters job configuration mode.

The name is restricted to 31 characters.

Step 3

switch(config-job) # command1 ; [command2 ;command3 ; ...

Defines the sequence of commands for the specified job. You must separate commands with a space and a semicolon ( ;).

The filename is created using the current time stamp and switch name.

Step 4

switch(config-job) # show scheduler job [name]

(Optional)
Displays the job information.

The name is restricted to 31 characters.

Step 5

switch(config-job) # copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to create a scheduler job named backup-cfg, save the running configuration to a file in bootflash, copy the file from bootflash to a TFTP server, and save the change to the startup configuration:

switch# configure terminal
switch(config) # scheduler job name backup-cfg
switch(config-job) # cli var name timestamp
$(timestamp) ;copy running-config
bootflash:/$(SWITCHNAME)-cfg.$(timestamp) ;copy
bootflash:/$(SWITCHNAME)-cfg.$(timestamp)
tftp://1.2.3.4/ vrf management
switch(config-job) # copy running-config startup-config

Deleting a Job

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # no scheduler job name name

Deletes the specified job and all commands defined within it.

The name is restricted to 31 characters.

Step 3

switch(config-job) # show scheduler job [name]

(Optional)
Displays the job information.

Step 4

switch(config-job) # copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to delete a job called configsave:

switch# configure terminal
switch(config)# no scheduler job name configsave
switch(config-job)# copy running-config startup-config
switch(config-job)#

Defining a Timetable

You must configure a timetable. Otherwise, jobs will not be scheduled.

If you do not specify the time for the time commands, the scheduler assumes the current time. For example, if the current time is March 24, 2008, 22:00 hours,jobs are started as follows:

- For the time start 23:00 repeat 4:00:00 command, the scheduler assumes a start time of March 24, 2008, 23:00 hours.

- For the time daily 55 command, the scheduler assumes a start time every day at 22:55 hours.

- For the time weekly 23:00 command, the scheduler assumes a start time every Friday at 23:00 hours.

- For the time monthly 23:00 command, the scheduler assumes a start time on the 24th of every month at 23:00 hours.

Note

The scheduler will not begin the next occurrence of a job before the last one completes. For example, you have scheduled a job to be completed at one-minute intervals beginning at 22:00; but the job requires two minutes to complete. The scheduler starts the first job at 22:00, completes it at 22:02, and then observes a one-minute interval before starting the next job at 22:03.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # scheduler schedule name name

Creates a new scheduler and enters schedule configuration mode for that schedule.

The name is restricted to 31 characters.

Step 3

switch(config-schedule) # job name name

Associates a job with this schedule. You can add multiple jobs to a schedule.

The name is restricted to 31 characters.

Step 4

switch(config-schedule) # time daily time

Indicates the job starts every day at a designated time, specified as HH:MM.

Step 5

switch(config-schedule) # time weekly [[day-of-week:] HH:] MM

Indicates that the job starts on a specified day of the week.

The day of the week is represented by an integer (for example, 1 for Sunday, 2 for Monday) or as an abbreviation (for example, sun, mon).

The maximum length for the entire argument is 10 characters.

Step 6

switch(config-schedule) # time monthly [[day-of-month:] HH:] MM

Indicates that the job starts on a specified day each month.

If you specify 29, 30, or 31, the job is started on the last day of each month.

Step 7

switch(config-schedule) # time start {now repeat repeat-interval | delta-time [repeat repeat-interval]}

Indicates the job starts periodically.

The start-time format is [[[[yyyy:]mmm:]dd:]HH]:MM.

- delta-time— Specifies the amount of time to wait after the schedule is configured before starting a job.

- now— Specifies that the job starts two minutes from now.

- repeat repeat-interval— Specifies the frequency at which the job is repeated.

Step 8

switch(config-schedule) # show scheduler config

(Optional)
Displays the scheduler information.

Step 9

switch(config-schedule) # copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to define a timetable where jobs start on the 28th of each month at 23:00 hours:

switch# configure terminal
switch(config)# scheduler schedule name weekendbackupqos
switch(config-scheduler)# job name offpeakzoning
switch(config-scheduler)# time monthly 28:23:00
switch(config-scheduler)# copy running-config startup-config
switch(config-scheduler)#

Clearing the Scheduler Log File

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # clear scheduler logfile

Clears the scheduler log file.

This example shows how to clear the scheduler log file:

switch# configure terminal
switch(config)# clear scheduler logfile

Disabling the Scheduler

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # no feature scheduler

Disables the scheduler.

Step 3

switch(config) # show scheduler config

(Optional)
Displays the scheduler configuration.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to disable the scheduler:

switch# configure terminal
switch(config) # no feature scheduler
switch(config) # copy running-config startup-config
switch(config) #

Verifying the Scheduler Configuration

Use one of the following commands to verify the configuration:

Scheduler Show Commands

Command

Purpose

show scheduler config

Displays the scheduler configuration.

show scheduler job [name name]

Displays the jobs configured.

show scheduler logfile

Displays the contents of the scheduler log file.

show scheduler schedule [name name]

Displays the schedules configured.

Creating a Scheduler Job

This example shows how to create a scheduler job that saves the running configuration to a file in bootflash and then copies the file from bootflash to a TFTP server (the filename is created using the current time stamp and switch name):

switch# configure terminal
switch(config)# scheduler job name backup-cfg
switch(config-job)# cli var name timestamp $(TIMESTAMP) ;copy running-config
bootflash:/$(SWITCHNAME)-cfg.$(timestamp) ;copy bootflash:/$(SWITCHNAME)-cfg.$(timestamp)
tftp://1.2.3.4/ vrf management
switch(config-job)# end
switch(config)#

Scheduling a Scheduler Job

This example shows how to schedule a scheduler job called backup-cfg to run daily at 1 a.m.:

switch# configure terminal
switch(config)# scheduler schedule name daily
switch(config-schedule)# job name backup-cfg
switch(config-schedule)# time daily 1:00
switch(config-schedule)# end
switch(config)#

Displaying the Job Schedule

This example shows how to display the job schedule:

switch# show scheduler schedule
Schedule Name       : daily
---------------------------
User Name           : admin
Schedule Type       : Run every day at 1 Hrs 00 Mins
Last Execution Time : Fri Jan 2 1:00:00 2009
Last Completion Time: Fri Jan 2 1:00:01 2009
Execution count     : 2
-----------------------------------------------
Job Name            Last Execution Status
-----------------------------------------------
back-cfg                          Success (0)
switch(config)#

Displaying the Results of Running Scheduler Jobs

This example shows how to display the results of scheduler jobs that have been executed by the scheduler:

switch# show scheduler logfile
Job Name       : back-cfg                          Job Status: Failed (1)
Schedule Name  : daily                             User Name : admin
Completion time: Fri Jan 1  1:00:01 2009
--------------------------------- Job Output ---------------------------------
`cli var name timestamp 2009-01-01-01.00.00`
`copy running-config bootflash:/$(HOSTNAME)-cfg.$(timestamp)`
`copy bootflash:/switch-cfg.2009-01-01-01.00.00 tftp://1.2.3.4/ vrf management `
copy: cannot access file '/bootflash/switch-cfg.2009-01-01-01.00.00'
==============================================================================
Job Name       : back-cfg                          Job Status: Success (0)
Schedule Name  : daily                             User Name : admin
Completion time: Fri Jan 2  1:00:01 2009
--------------------------------- Job Output ---------------------------------
`cli var name timestamp 2009-01-02-01.00.00`
`copy running-config bootflash:/switch-cfg.2009-01-02-01.00.00`
`copy bootflash:/switch-cfg.2009--01-02-01.00.00 tftp://1.2.3.4/ vrf management `
Connection to Server Established.
[                         ]         0.50KBTrying to connect to tftp server......
[######                   ]        24.50KB
TFTP put operation was successful
==============================================================================
switch#

Standards for the Scheduler

No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.

Chapter 7. Configuring Online Diagnostics

This chapter contains the following sections:

- Information About Online Diagnostics

- Configuring Online Diagnostics

- Verifying the Online Diagnostics Configuration

- Default Settings for Online Diagnostics

Information About Online Diagnostics

Online diagnostics provide verification of hardware components during switch bootup or reset, and they monitor the health of the hardware during normal switch operation.

Cisco Nexus Series switches support bootup diagnostics and runtime diagnostics. Bootup diagnostics include disruptive tests and nondisruptive tests that run during system bootup and system reset.

Runtime diagnostics (also known as health monitoring diagnostics) include nondisruptive tests that run in the background during normal operation of the switch.

- Bootup Diagnostics

- Health Monitoring Diagnostics

- Expansion Module Diagnostics

Bootup Diagnostics

Bootup diagnostics detect faulty hardware before bringing the switch online. Bootup diagnostics also check the data path and control path connectivity between the supervisor and the ASICs. The following table describes the diagnostics that are run only during switch bootup or reset.

Bootup Diagnostics

Diagnostic

Description

PCIe

Tests PCI express (PCIe) access.

NVRAM

Verifies the integrity of the NVRAM.

In band port

Tests connectivity of the inband port to the supervisor.

Management port

Tests the management port.

Memory

Verifies the integrity of the DRAM.

Bootup diagnostics also include a set of tests that are common with health monitoring diagnostics.

Bootup diagnostics log any failures to the onboard failure logging (OBFL) system. Failures also trigger an LED display to indicate diagnostic test states (on, off, pass, or fail).

You can configure Cisco Nexus device to either bypass the bootup diagnostics or run the complete set of bootup diagnostics.

Health Monitoring Diagnostics

Health monitoring diagnostics provide information about the health of the switch. They detect runtime hardware errors, memory errors, software faults, and resource exhaustion.

Health monitoring diagnostics are nondisruptive and run in the background to ensure the health of a switch that is processing live network traffic.

The following table describes the health monitoring diagnostics for the switch.

Health Monitoring Diagnostics Tests

Diagnostic

Description

LED

Monitors port and system status LEDs.

Power Supply

Monitors the power supply health state.

Temperature Sensor

Monitors temperature sensor readings.

Test Fan

Monitors the fan speed and fan control.

Note

When the switch reaches the intake temperature threshold and does not go within the limits in 120 seconds, the switch will power off and the power supplies will have to be re-seated to recover the switch

The following table describes the health monitoring diagnostics that also run during system boot or system reset.

Health Monitoring and Bootup Diagnostics Tests

Diagnostic

Description

SPROM

Verifies the integrity of backplane and supervisor SPROMs.

Fabric engine

Tests the switch fabric ASICs.

Fabric port

Tests the ports on the switch fabric ASIC.

Forwarding engine

Tests the forwarding engine ASICs.

Forwarding engine port

Tests the ports on the forwarding engine ASICs.

Front port

Tests the components (such as PHY and MAC) on the front ports.

Note

When the switch exceeds the intake temperature threshold of 40 degrees Celsius and does not decrease to within the threshold limits in 120 seconds, the switch powers off and the power supplies must be re-seated to recover the switch.

Expansion Module Diagnostics

During the switch bootup or reset, the bootup diagnostics include tests for the in-service expansion modules in the switch.

When you insert an expansion module into a running switch, a set of diagnostics tests are run. The following table describes the bootup diagnostics for an expansion module. These tests are common with the bootup diagnostics. If the bootup diagnostics fail, the expansion module is not placed into service.

Expansion Module Bootup and Health Monitoring Diagnostics

Diagnostic

Description

SPROM

Verifies the integrity of backplane and supervisor SPROMs.

Fabric engine

Tests the switch fabric ASICs.

Fabric port

Tests the ports on the switch fabric ASIC.

Forwarding engine

Tests the forwarding engine ASICs.

Forwarding engine port

Tests the ports on the forwarding engine ASICs.

Front port

Tests the components (such as PHY and MAC) on the front ports.

Health monitoring diagnostics are run on in-service expansion modules. The following table describes the additional tests that are specific to health monitoring diagnostics for expansion modules.

Expansion Module Health Monitoring Diagnostics

Diagnostic

Description

LED

Monitors port and system status LEDs.

Temperature Sensor

Monitors temperature sensor readings.

Configuring Online Diagnostics

You can configure the bootup diagnostics to run the complete set of tests, or you can bypass all bootup diagnostic tests for a faster module boot up time.

Note

We recommend that you set the bootup online diagnostics level to complete. We do not recommend bypassing the bootup online diagnostics.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# diagnostic bootup level [complete | bypass]

Configures the bootup diagnostic level to trigger diagnostics when the device boots, as follows:

- complete—Performs all bootup diagnostics. This is the default value.

- bypass—Does not perform any bootup diagnostics.

Step 3

switch# show diagnostic bootup level

(Optional)
Displays the bootup diagnostic level (bypass or complete) that is currently in place on the switch.

The following example shows how to configure the bootup diagnostics level to trigger the complete diagnostics:

switch# configure terminal

switch(config)# diagnostic bootup level complete

Verifying the Online Diagnostics Configuration

Use the following commands to verify online diagnostics configuration information:

Command

Purpose

show diagnostic bootup level

Displays the bootup diagnostics level.

show diagnostic result module slot

Displays the results of the diagnostics tests.

Default Settings for Online Diagnostics

The following table lists the default settings for online diagnostics parameters.

Default Online Diagnostics Parameters

Parameters

Default

Bootup diagnostics level

complete

Chapter 8. Configuring NTP

This chapter contains the following sections:

- Information About NTP

- NTP as a Time Server

- Distributing NTP Using CFS

- Clock Manager

- Virtualization Support

- Licensing Requirements for NTP

- Guidelines and Limitations for NTP

- Default Settings

- Related Documents for NTP

- Feature History for NTP

Information About NTP

The Network Time Protocol (NTP) synchronizes the time of day among a set of distributed time servers and clients so that you can correlate events when you receive system logs and other time-specific events from multiple network devices. NTP uses the User Datagram Protocol (UDP) as its transport protocol. All NTP communications use Coordinated Universal Time (UTC).

An NTP server usually receives its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server, and then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of each other.

NTP uses a stratum to describe the distance between a network device and an authoritative time source:

- A stratum 1 time server is directly attached to an authoritative time source (such as a radio or atomic clock or a GPS time source).

- A stratum 2 NTP server receives its time through NTP from a stratum 1 time server.

Before synchronizing, NTP compares the time reported by several network devices and does not synchronize with one that is significantly different, even if it is a stratum 1. Because Cisco NX-OS cannot connect to a radio or atomic clock and act as a stratum 1 server, we recommend that you use the public NTP servers available on the Internet. If the network is isolated from the Internet, Cisco NX-OS allows you to configure the time as though it were synchronized through NTP, even though it was not.

Note

You can create NTP peer relationships to designate the time-serving hosts that you want your network device to consider synchronizing with and to keep accurate time if a server failure occurs.

The time kept on a device is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.

NTP as a Time Server

the Cisco NX-OS device can use NTP to distribute time. Other devices can configure it as a time server. You can also configure the device to act as an authoritative NTP server, enabling it to distribute time even when it is not synchronized to an outside time source.

Distributing NTP Using CFS

Cisco Fabric Services (CFS) distributes the local NTP configuration to all Cisco devices in the network. After enabling CFS on your device, a network-wide lock is applied to NTP whenever an NTP configuration is started. After making the NTP configuration changes, you can discard or commit them. In either case, the CFS lock is then released from the NTP application.

Clock Manager

Clocks are resources that need to be shared across different processes. Multiple time synchronization protocols, such as NTP and Precision Time Protocol (PTP), might be running in the system.

The clock manager allows you to specify the protocol to control the various clocks in the system. Once you specify the protocol, the system clock starts updating.

Virtualization Support

NTP recognizes virtual routing and forwarding (VRF) instances. NTP uses the default VRF if you do not configure a specific VRF for the NTP server and NTP peer.

Licensing Requirements for NTP

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco NX-OS

NTP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you.

Guidelines and Limitations for NTP

NTP has the following configuration guidelines and limitations:

- To configure NTP, you must have connectivity to at least one server that is running NTP.

- You should have a peer association with another device only when you are sure that your clock is reliable (which means that you are a client of a reliable NTP server).

- A peer configured alone takes on the role of a server and should be used as a backup. If you have two servers, you can configure several devices to point to one server and the remaining devices to point to the other server. You can then configure a peer association between these two servers to create a more reliable NTP configuration.

- If you have only one server, you should configure all the devices as clients to that server.

- You can configure up to 64 NTP entities (servers and peers).

- If CFS is disabled for NTP, then NTP does not distribute any configuration and does not accept a distribution from other devices in the network.

- After CFS distribution is enabled for NTP, the entry of an NTP configuration command locks the network for NTP configuration until a commit command is entered. During the lock, no changes can be made to the NTP configuration by any other device in the network except the device that initiated the lock.

- If you use CFS to distribute NTP, all devices in the network should have the same VRFs configured as you use for NTP.

- If you configure NTP in a VRF, ensure that the NTP server and peers can reach each other through the configured VRFs.

- You must manually distribute NTP authentication keys on the NTP server and Cisco NX-OS devices across the network.

Default Settings

Default NTP Parameters

Parameters

Default

NTP authentication

disabled

NTP access

enabled

NTP logging

disabled

Configuring NTP Server and Peer

You can configure an NTP server and peer.

Before You Begin

Make sure you know the IP address or DNS names of your NTP server and its peers.

If you plan to use CFS to distribute your NTP configuration to other devices, then you should have already completed the following:

- Enabled CFS distribution.

- Enabled CFS for NTP.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] ntp server {ip-address | ipv6-address | dns-name} [key key-id] [maxpoll max-poll] [minpoll min-poll] [prefer] [use-vrf vrf-name]

Forms an association with a server.

Use the key keyword to configure a key to be used while communicating with the NTP server. The range for the key-id argument is from 1 to 65535.

Use the maxpoll and minpoll keywords to configure the maximum and minimum intervals in which to poll a peer. The range for the max-poll and min-poll arguments is from 4 to 16 seconds, and the default values are 6 and 4, respectively.

Use the prefer keyword to make this the preferred NTP server for the device.

Use the use-vrf keyword to configure the NTP server to communicate over the specified VRF. The vrf-name argument can be default, management, or any case-sensitive alphanumeric string up to 32 characters.

Note:
If you configure a key to be used while communicating with the NTP server, make sure that the key exists as a trusted key on the device.

Step 3

switch(config)# [no] ntp peer {ip-address | ipv6-address | dns-name} [key key-id] [maxpoll max-poll] [minpoll min-poll] [prefer] [use-vrf vrf-name]

Forms an association with a peer. You can specify multiple peer associations.

Use the key keyword to configure a key to be used while communicating with the NTP peer. The range for the key-id argument is from 1 to 65535.

Use the maxpoll and minpoll keywords to configure the maximum and minimum intervals in which to poll a peer. The range for the max-poll and min-poll arguments is from 4 to 16 seconds, and the default values are 6 and 4, respectively.

Use the prefer keyword to make this the preferred NTP server for the device.

Use the use-vrf keyword to configure the NTP server to communicate over the specified VRF. The vrf-name argument can be default, management, or any case-sensitive alphanumeric string up to 32 characters.

Step 4

switch(config)# show ntp peers

(Optional)
Displays the configured server and peers.

Note:
A domain name is resolved only when you have a DNS server configured.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure an NTP server and peer:

switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# ntp server 192.0.2.10 key 10 use-vrf Red
switch(config)# ntp peer 2001:0db8::4101 prefer use-vrf Red
switch(config)# show ntp peers
--------------------------------------------------
Peer IP Address Serv/Peer
--------------------------------------------------
2001:0db8::4101 Peer (configured)
192.0.2.10 Server (configured)
switch(config)# copy running-config startup-config
[########################################] 100%
switch(config)#

Configuring NTP Authentication

You can configure the device to authenticate the time sources to which the local clock is synchronized. When you enable NTP authentication, the device synchronizes to a time source only if the source carries one of the authentication keys specified by the ntp trusted-key command. The device drops any packets that fail the authentication check and prevents them from updating the local clock. NTP authentication is disabled by default.

Before You Begin

Make sure that you configured the NTP server with the authentication keys that you plan to specify in this procedure.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] ntp authentication-key number md5 md5-string

Defines the authentication keys. The device does not synchronize to a time source unless the source has one of these authentication keys and the key number is specified by the ntp trusted-key number command.

Step 3

switch(config)# show ntp authentication-keys

(Optional)
Displays the configured NTP authentication keys.

Step 4

switch(config)# [no]ntp trusted-key number

Specifies one or more keys that a time source must provide in its NTP packets in order for the device to synchronize to it. The range for trusted keys is from 1 to 65535.

This command provides protection against accidentally synchronizing the device to a time source that is not trusted.

Step 5

switch(config)# show ntp trusted-keys

(Optional)
Displays the configured NTP trusted keys.

Step 6

switch(config)# [no] ntp authenticate

Enables or disables the NTP authentication feature. NTP authentication is disabled by default.

Step 7

switch(config)# show ntp authentication-status

(Optional)
Displays the status of NTP authentication.

Step 8

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure the device to synchronize only to time sources that provide authentication key 42 in their NTP packets:

switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# ntp authentication-key 42 md5 aNiceKey
switch(config)# ntp trusted-key 42
switch(config)# ntp authenticate
switch(config)# copy running-config startup-config
[########################################] 100%
switch(config)#

Configuring NTP Access Restrictions

You can control access to NTP services by using access groups. Specifically, you can specify the types of requests that the device allows and the servers from which it accepts responses.

If you do not configure any access groups, NTP access is granted to all devices. If you configure any access groups, NTP access is granted only to the remote device whose source IP address passes the access list criteria.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] ntp access-group {peer | serve | serve-only | query-only} access-list-name

Creates or removes an access group to control NTP access and applies a basic IP access list.

The access group options are scanned in the following order, from least restrictive to most restrictive. However, if NTP matches a deny ACL rule in a configured peer, ACL processing stops and does not continue to the next access group option.

- The peer keyword enables the device to receive time requests and NTP control queries and to synchronize itself to the servers specified in the access list.

- The serve keyword enables the device to receive time requests and NTP control queries from the servers specified in the access list but not to synchronize itself to the specified servers.

- The serve-only keyword enables the device to receive only time requests from servers specified in the access list.

- The query-only keyword enables the device to receive only NTP control queries from the servers specified in the access list.

Step 3

switch(config)# show ntp access-groups

(Optional)
Displays the NTP access group configuration.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure the device to allow it to synchronize to a peer from access group “accesslist1”:

switch# config t
switch(config)# ntp access-group peer accesslist1
switch(config)# show ntp access-groups
Access List Type
-----------------------------
accesslist1 Peer
switch(config)# copy running-config startup-config
[########################################] 100%
switch(config)#

Configuring the NTP Source IP Address

NTP sets the source IP address for all NTP packets based on the address of the interface through which the NTP packets are sent. You can configure NTP to use a specific source IP address.

To configure the NTP source IP address, use the following command in global configuration mode:

Procedure

Command or Action

Purpose

Step 1

switch(config)# [no] ntp source ip-address

Configures the source IP address for all NTP packets. The ip-address can be in IPv4 or IPv6 format.

This example shows how to configure NTP to a source IP address:

switch(config)# ntp source 192.0.2.1

Configuring the NTP Source Interface

You can configure NTP to use a specific interface.

To configure the NTP source interface, use the following command in global configuration mode:

Procedure

Command or Action

Purpose

Step 1

switch(config)# [no] ntp source-interface interface

Configures the source interface for all NTP packets. Use the ? keyword to display a list of supported interfaces.

This example shows how to configure NTP to a specific interface:

switch(config)# ntp source-interface
ethernet 2/1

Configuring NTP Logging

You can configure NTP logging in order to generate system logs with significant NTP events. NTP logging is disabled by default.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] ntp logging

Enables or disables system logs to be generated with significant NTP events. NTP logging is disabled by default.

Step 3

switch(config)# show ntp logging-status

(Optional)
Displays the NTP logging configuration status.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to enable NTP logging in order to generate system logs with significant NTP events:

switch# config t
switch(config)# ntp logging
switch(config)# copy running-config startup-config
[########################################] 100%
switch(config)#

Enabling CFS Distribution for NTP

You can enable CFS distribution for NTP in order to distribute the NTP configuration to other CFS-enabled devices.

Before You Begin

Make sure that you have enabled CFS distribution for the device.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# [no] ntp distribute

Enables or disables the device to receive NTP configuration updates that are distributed through CFS.

Step 3

switch(config)# show ntp status

(Optional)
Displays the NTP CFS distribution status.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to enable CFS distribution for NTP:

switch# config t
Enter configuration commands, one per
line. End with CNTL/Z.
switch(config)# ntp distribute
switch(config)# copy running-config
startup-config

Commiting NTP Configuration Changes

When you commit the NTP configuration changes, the effective database is overwritten by the configuration changes in the pending database and all the devices in the network receive the same configuration.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# ntp commit

Distributes the NTP configuration changes to all Cisco NX-OS devices in the network and releases the CFS lock. This command overwrites the effective database with the changes made to the pending database.

This example shows how to commit the NTP configuration changes:

switch(config)# ntp commit

Discarding NTP Configuration Changes

After making the configuration changes, you can choose to discard the changes instead of committing them. If you discard the changes, Cisco NX-OS removes the pending database changes and releases the CFS lock.

To discard NTP configuration changes, use the following command in global configuration mode:

Procedure

Command or Action

Purpose

Step 1

switch(config)# ntp abort

Discards the NTP configuration changes in the pending database and releases the CFS lock. Use this command on the device where you started the NTP configuration.

This example shows how to discard the NTP configuration changes:

switch(config)# ntp abort

Releasing the CFS Session Lock

If you have performed an NTP configuration and have forgotten to release the lock by either committing or discarding the changes, you or another administrator can release the lock from any device in the network. This action also discards pending database changes.

To release the session lock from any device and discard any pending database changes, use the following command in global configuration mode:

Procedure

Command or Action

Purpose

Step 1

switch(config)# clear ntp session

Discards the NTP configuration changes in the pending database and releases the CFS lock.

This example shows how to release the CFS session lock:

switch(config)# clear ntp session

Verifying the NTP Configuration

To display the NTP configuration, perform one of the following tasks:

Use the clear ntp session command to clear the NTP sessions.

Use the clear ntp statistics command to clear the NTP statistics.

Procedure

Command or Action

Purpose

Step 1

show ntp access-groups

Displays the NTP access group configuration.

Step 2

show ntp authentication-keys

Displays the configured NTP authentication keys.

Step 3

show ntp authentication-status

Displays the status of NTP authentication.

Step 4

show ntp logging-status

Displays the NTP logging status.

Step 5

show ntp peer-status

Displays the status for all NTP servers and peers.

Step 6

show ntp peers

Displays all the NTP peers.

Step 7

show ntp pending

Displays the temporary CFS database for NTP.

Step 8

show ntp pending-diff

Displays the difference between the pending CFS database and the current NTP configuration.

Step 9

show ntp rts-update

Displays the RTS update status.

Step 10

show ntp session status

Displays the NTP CFS distribution session information.

Step 11

show ntp source

Displays the configured NTP source IP address.

Step 12

show ntp source-interface

Displays the configured NTP source interface.

Step 13

show ntp statistics {io | local | memory | peer {ipaddr {ipv4-addr | ipv6-addr} | name peer-name}}

Displays the NTP statistics.

Step 14

show ntp status

Displays the NTP CFS distribution status.

Step 15

show ntp trusted-keys

Displays the configured NTP trusted keys.

Step 16

show running-config ntp

Displays NTP information.

Configuration Examples for NTP

This example shows how to configure an NTP server and peer, enable NTP authentication, enable NTP logging, and then save the configuration in startup so that it is saved across reboots and restarts:

switch# config terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# ntp server 192.0.2.105 key 42
switch(config)# ntp peer 2001:0db8::4101
switch(config)# show ntp peers
--------------------------------------------------
Peer IP Address            Serv/Peer
--------------------------------------------------
2001:db8::4101         Peer (configured)
192.0.2.105           Server (configured)
switch(config)# ntp authentication-key 42 md5 aNiceKey
switch(config)# show ntp authentication-keys
-----------------------------
Auth key        MD5 String
-----------------------------
42           aNicekey
switch(config)# ntp trusted-key 42
switch(config)# show ntp trusted-keys
Trusted Keys:
42
switch(config)# ntp authenticate
switch(config)# show ntp authentication-status
Authentication enabled.
switch(config)# ntp logging
switch(config)# show ntp logging
NTP logging enabled.
switch(config)# copy running-config startup-config
[########################################] 100%
switch(config)#

This example shows an NTP access group configuration with the following restrictions:

- Peer restrictions are applied to IP addresses that pass the criteria of the access list named “peer-acl.”

- Serve restrictions are applied to IP addresses that pass the criteria of the access list named “serve-acl.”

- Serve-only restrictions are applied to IP addresses that pass the criteria of the access list named “serve-only-acl.”

- Query-only restrictions are applied to IP addresses that pass the criteria of the access list named “query-only-acl.”

switch# config terminal
switch(config)# ntp peer 10.1.1.1
switch(config)# ntp peer 10.2.2.2
switch(config)# ntp peer 10.3.3.3
switch(config)# ntp peer 10.4.4.4
switch(config)# ntp peer 10.5.5.5
switch(config)# ntp peer 10.6.6.6
switch(config)# ntp peer 10.7.7.7
switch(config)# ntp peer 10.8.8.8
switch(config)# ntp access-group peer peer-acl
switch(config)# ntp access-group serve serve-acl
switch(config)# ntp access-group serve-only serve-only-acl
switch(config)# ntp access-group query-only query-only-acl

switch(config)# ip access-list peer-acl
switch(config-acl)# 10 permit ip host 10.1.1.1 any
switch(config-acl)# 20 permit ip host 10.8.8.8 any

switch(config)# ip access-list serve-acl
switch(config-acl)# 10 permit ip host 10.4.4.4 any
switch(config-acl)# 20 permit ip host 10.5.5.5 any

switch(config)# ip access-list serve-only-acl
switch(config-acl)# 10 permit ip host 10.6.6.6 any
switch(config-acl)# 20 permit ip host 10.7.7.7 any

switch(config)# ip access-list query-only-acl
switch(config-acl)# 10 permit ip host 10.2.2.2 any
switch(config-acl)# 20 permit ip host 10.3.3.3 any

Related Documents for NTP

Related Topic

Document Title

NTP CLI commands

Cisco Nexus 3548 Switch NX-OS System Management Command Reference Guide

Feature History for NTP

This table includes only the updates for those releases that have resulted in additions or changes to the feature.

Feature Name

Releases

Feature Information

NTP

5.0(3)A1(1)

This feature was introduced.

Chapter 9. Configuring System Message Logging

This chapter contains the following sections:

- Information About System Message Logging

- Licensing Requirements for System Message Logging

- Guidelines and Limitations for System Message Logging

- Default Settings for System Message Logging

- Configuring DOM Logging

- Verifying the System Message Logging Configuration

Information About System Message Logging

You can use system message logging to control the destination and to filter the severity level of messages that system processes generate. You can configure logging to terminal sessions, a log file, and syslog servers on remote systems.

System message logging is based on RFC 3164. For more information about the system message format and the messages that the device generates, see the Cisco NX-OS System Messages Reference.

By default, the Cisco Nexus device outputs messages to terminal sessions.

By default, the switch logs system messages to a log file.

The following table describes the severity levels used in system messages. When you configure the severity level, the system outputs messages at that level and lower.

System Message Severity Levels

Level

Description

0 – emergency

System unusable

1 – alert

Immediate action needed

2 – critical

Critical condition

3 – error

Error condition

4 – warning

Warning condition

5 – notification

Normal but significant condition

6 – informational

Informational message only

7 – debugging

Appears during debugging only

The switch logs the most recent 100 messages of severity 0, 1, or 2 to the NVRAM log. You cannot configure logging to the NVRAM.

You can configure which system messages should be logged based on the facility that generated the message and its severity level.

- Syslog Servers

Syslog Servers

Syslog servers run on remote systems that are configured to log system messages based on the syslog protocol. You can configure the Cisco Nexus Series switch to sends logs to up to eight syslog servers.

To support the same configuration of syslog servers on all switches in a fabric, you can use Cisco Fabric Services (CFS) to distribute the syslog server configuration.

Note

When the switch first initializes, messages are sent to syslog servers only after the network is initialized.

Licensing Requirements for System Message Logging

Product

License Requirement

Cisco NX-OS

System message logging requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.

Guidelines and Limitations for System Message Logging

System messages are logged to the console and the logfile by default.

Default Settings for System Message Logging

The following table lists the default settings for system message logging parameters.

Default System Message Logging Parameters

Parameters

Default

Console logging

Enabled at severity level 2

Monitor logging

Enabled at severity level 2

Log file logging

Enabled to log messages at severity level 5

Module logging

Enabled at severity level 5

Facility logging

Enabled

Time-stamp units

Seconds

Syslog server logging

Disabled

Syslog server configuration distribution

Disabled

Configuring System Message Logging to Terminal Sessions

You can configure the switch to log messages by their severity level to console, Telnet, and Secure Shell sessions.

By default, logging is enabled for terminal sessions.

Procedure

Command or Action

Purpose

Step 1

switch# terminal monitor

Copies syslog messages from the console to the current terminal session.

Step 2

switch# configure terminal

Enters global configuration mode.

Step 3

switch(config)# logging console [severity-level]

Enables the switch to log messages to the console session based on a specified severity level or higher (a lower number value indicates a higher severity level). Severity levels range from 0 to 7:

- 0 – emergency

- 1 – alert

- 2 – critical

- 3 – error

- 4 – warning

- 5 – notification

- 6 – informational

- 7 – debugging

If the severity level is not specified, the default of 2 is used.

Step 4

switch(config)# no logging console [severity-level]

(Optional)
Disables logging messages to the console.

Step 5

switch(config)# logging monitor [severity-level]

Enables the switch to log messages to the monitor based on a specified severity level or higher (a lower number value indicates a higher severity level). Severity levels range from 0 to 7:

- 0 – emergency

- 1 – alert

- 2 – critical

- 3 – error

- 4 – warning

- 5 – notification

- 6 – informational

- 7 – debugging

If the severity level is not specified, the default of 2 is used.

The configuration applies to Telnet and SSH sessions.

Step 6

switch(config)# no logging monitor [severity-level]

(Optional)
Disables logging messages to Telnet and SSH sessions.

Step 7

switch# show logging console

(Optional)
Displays the console logging configuration.

Step 8

switch# show logging monitor

(Optional)
Displays the monitor logging configuration.

Step 9

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure a logging level of 3 for the console:

switch# configure terminal

switch(config)# logging console 3

The following example shows how to display the console logging configuration:

switch# show logging console

Logging console:                enabled (Severity: error)

The following example shows how to disable logging for the console:

switch# configure terminal

switch(config)# no logging console

The following example shows how to configure a logging level of 4 for the terminal session:

switch# terminal monitor

switch# configure terminal

switch(config)# logging monitor 4

The following example shows how to display the terminal session logging configuration:

switch# show logging monitor

Logging monitor:                enabled (Severity: warning)

The following example shows how to disable logging for the terminal session:

switch# configure terminal

switch(config)# no logging monitor

Configuring System Message Logging to a File

You can configure the switch to log system messages to a file. By default, system messages are logged to the file log:messages.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# logging logfile logfile-name severity-level [size bytes]

Configures the name of the log file used to store system messages and the minimum severity level to log. You can optionally specify a maximum file size. The default severity level is 5 and the file size is 4194304.

Severity levels range from 0 to 7:

- 0 – emergency

- 1 – alert

- 2 – critical

- 3 – error

- 4 – warning

- 5 – notification

- 6 – informational

- 7 – debugging

The file size is from 4096 to 10485760 bytes.

Step 3

switch(config)# no logging logfile [logfile-name severity-level [size bytes]]

(Optional)
Disables logging to the log file. You can optionally specify a maximum file size. The default severity level is 5 and the file size is 4194304.

Step 4

switch# show logging info

(Optional)
Displays the logging configuration. You can optionally specify a maximum file size. The default severity level is 5 and the file size is 4194304.

Step 5

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure a switch to log system messages to a file:

switch# configure terminal
switch(config)# logging logfile my_log 6 size 4194304

The following example shows how to display the logging configuration (some of the output has been removed for brevity):

switch# show logging info
Logging console:                enabled (Severity: debugging)
Logging monitor:                enabled (Severity: debugging)

Logging timestamp:              Seconds
Logging server:                 disabled
Logging logfile:                enabled
Name - my_log: Severity - informational Size - 4194304
Facility        Default Severity        Current Session Severity
--------        ----------------        ------------------------
aaa                     3                       3

afm                     3                       3
altos                   3                       3
auth                    0                       0
authpriv                3                       3
bootvar                 5                       5
callhome                2                       2
capability              2                       2
cdp                     2                       2
cert_enroll             2                       2
...

Configuring Module and Facility Messages Logging

You can configure the severity level and time-stamp units of messages logged by modules and facilities.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# logging module [severity-level]

Enables module log messages that have the specified severity level or higher. Severity levels range from 0 to 7:

- 0 – emergency

- 1 – alert

- 2 – critical

- 3 – error

- 4 – warning

- 5 – notification

- 6 – informational

- 7 – debugging

If the severity level is not specified, the default of 5 is used.

Step 3

switch(config)# logging level facility severity-level

Enables logging messages from the specified facility that have the specified severity level or higher. Severity levels from 0 to 7:

- 0 – emergency

- 1 – alert

- 2 – critical

- 3 – error

- 4 – warning

- 5 – notification

- 6 – informational

- 7 – debugging

To apply the same severity level to all facilities, use the all facility. For defaults, see the show logging level command.

Note:
If the default severity and current session severity of a component is the same, then the logging level for the component will not be displayed in the running configuration.

Step 4

switch(config)# no logging module [severity-level]

(Optional)
Disables module log messages.

Step 5

switch(config)# no logging level [facility severity-level]

(Optional)
Resets the logging severity level for the specified facility to its default level. If you do not specify a facility and severity level, the switch resets all facilities to their default levels.

Step 6

switch# show logging module

(Optional)
Displays the module logging configuration.

Step 7

switch# show logging level [facility]

(Optional)
Displays the logging level configuration and the system default level by facility. If you do not specify a facility, the switch displays levels for all facilities.

Step 8

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure the severity level of module and specific facility messages:

switch# configure terminal

switch(config)# logging module 3

switch(config)# logging level aaa 2

Configuring Logging Timestamps

You can configure the time-stamp units of messages logged by the Cisco Nexus Series switch.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# logging timestamp {microseconds | milliseconds | seconds}

Sets the logging time-stamp units. By default, the units are seconds.

Step 3

switch(config)# no logging timestamp {microseconds | milliseconds | seconds}

(Optional)
Resets the logging time-stamp units to the default of seconds.

Step 4

switch# show logging timestamp

(Optional)
Displays the logging time-stamp units configured.

Step 5

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure the time-stamp units of messages:

switch# configure terminal
switch(config)# logging timestamp milliseconds
switch(config)# exit
switch# show logging timestamp
Logging timestamp:              Milliseconds

Configuring Syslog Servers

You can configure up to eight syslog servers that reference remote systems where you want to log system messages.

Procedure

Command or Action

Purpose

Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

logging server host [severity-level [use-vrf vrf-name [facility facility]]]

Example:

switch(config)# logging server 172.28.254.254 5
use-vrf default facility local3

Configures a host to receive syslog messages.

- The host argument identifies the hostname or the IPv4 or IPv6 address of the syslog server host.

- The severity-level argument limits the logging of messages to the syslog server to a specified level. Severity levels range from 0 to 7. See Table 1.

- The use vrf vrf-name keyword and argument identify the default or management values for the virtual routing and forwarding (VRF) name. If a specific VRF is not identified, management is the default. However, if management is configured, it will not be listed in the output of the show-running command because it is the default. If a specific VRF is configured, the show-running command output will list the VRF for each server.

Note:
The current Cisco Fabric Services (CFS) distribution does not support VRF. If CFS distribution is enabled, the logging server configured with the default VRF is distributed as the management VRF.

- The facility argument names the syslog facility type. The default outgoing facility is local7.

The facilities are listed in the command reference for the Cisco Nexus Series software that you are using.

Note:
Debugging is a CLI facility but the debug syslogs are not sent to the server.

Step 3

no logging server host

Example:

switch(config)# no logging server 172.28.254.254 5

(Optional)
Removes the logging server for the specified host.

Step 4

show logging server

Example:

switch# show logging server

(Optional)
Displays the syslog server configuration.

Step 5

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following examples show how to configure a syslog server:

switch# configure terminal
switch(config)# logging server 172.28.254.254 5
use-vrf default facility local3

switch# configure terminal
switch(config)# logging server 172.28.254.254 5 use-vrf management facility local3

- Configuring syslog on a UNIX or Linux System

Configuring syslog on a UNIX or Linux System

You can configure a syslog server on a UNIX or Linux system by adding the following line to the /etc/syslog.conf file:

facility.level <five tab characters> action

The following table describes the syslog fields that you can configure.

syslog Fields in syslog.conf

Field

Description

Facility

Creator of the message, which can be auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, local0 through local7, or an asterisk (*) for all. These facility designators allow you to control the destination of messages based on their origin.

Note:
Check your configuration before using a local facility.

Level

Minimum severity level at which messages are logged, which can be debug, info, notice, warning, err, crit, alert, emerg, or an asterisk (*) for all. You can use none to disable a facility.

Action

Destination for messages, which can be a filename, a hostname preceded by the at sign (@), or a comma-separated list of users or an asterisk (*) for all logged-in users.

Procedure

Step 1

Log debug messages with the local7 facility in the file /var/log/myfile.log by adding the following line to the /etc/syslog.conf file:

debug.local7             /var/log/myfile.log

Step 2

Create the log file by entering these commands at the shell prompt:

$ touch /var/log/myfile.log

$ chmod 666 /var/log/myfile.log

Step 3

Make sure that the system message logging daemon reads the new changes by checking myfile.log after entering this command:

$ kill -HUP ~cat /etc/syslog.pid~

Configuring syslog Server Configuration Distribution

You can distribute the syslog server configuration to other switches in the network by using the Cisco Fabric Services (CFS) infrastructure.

After you enable syslog server configuration distribution, you can modify the syslog server configuration and view the pending changes before committing the configuration for distribution. As long as distribution is enabled, the switch maintains pending changes to the syslog server configuration.

Note

If the switch is restarted, the syslog server configuration changes that are kept in volatile memory might get lost.

Before You Begin

You must have configured one or more syslog servers.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# logging distribute

Enables distribution of the syslog server configuration to network switches using the CFS infrastructure. By default, distribution is disabled.

Step 3

switch(config)# logging commit

Commits the pending changes to the syslog server configuration for distribution to the switches in the fabric.

Step 4

switch(config)# logging abort

Cancels the pending changes to the syslog server configuration.

Step 5

switch(config)# no logging distribute

(Optional)
Disables the distribution of the syslog server configuration to network switches using the CFS infrastructure. You cannot disable distribution when configuration changes are pending. See the logging commit and logging abort commands. By default, distribution is disabled.

Step 6

switch# show logging pending

(Optional)
Displays the pending changes to the syslog server configuration.

Step 7

switch# show logging pending-diff

(Optional)
Displays the differences from the current syslog server configuration to the pending changes of the syslog server configuration.

Step 8

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

Displaying and Clearing Log Files

You can display or clear messages in the log file and the NVRAM.

Procedure

Command or Action

Purpose

Step 1

switch# show logging last number-lines

Displays the last number of lines in the logging file. You can specify from 1 to 9999 for the last number of lines.

Step 2

switch# show logging logfile [start-time yyyy mmm dd hh:mm:ss] [end-time yyyy mmm dd hh:mm:ss]

Displays the messages in the log file that have a time stamp within the span entered. If you do not enter an end time, the current time is used. You enter three characters for the month time field and digits for the year and day time fields.

Step 3

switch# show logging nvram [last number-lines]

Displays the messages in the NVRAM. To limit the number of lines displayed, you can enter the last number of lines to display. You can specify from 1 to 100 for the last number of lines.

Step 4

switch# clear logging logfile

Clears the contents of the log file.

Step 5

switch# clear logging nvram

Clears the logged messages in NVRAM.

The following example shows how to display messages in a log file:

switch# show logging last 40

switch# show logging logfile start-time 2007 nov 1 15:10:0

switch# show logging nvram last 10

The following example shows how to clear messages in a log file:

switch# clear logging logfile

switch# clear logging nvram

Configuring DOM Logging

- Enabling DOM Logging

- Disabling DOM Logging

- Verifying the DOM Logging Configuration

Enabling DOM Logging

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# system ethernet dom polling

Enables transceiver digital optical monitoring periodic polling.

The following example shows how to enable DOM logging.

switch# configure terminal
switch(config)# system ethernet dom polling

Disabling DOM Logging

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# no system ethernet dom polling

Disables transceiver digital optical monitoring periodic polling.

The following example shows how to disable DOM logging.

switch# configure terminal
switch(config)# no system ethernet dom polling

Verifying the DOM Logging Configuration

Command

Purpose

show system ethernet dom polling status

Displays the transceiver digital optical monitoring periodic polling status.

Verifying the System Message Logging Configuration

Use these commands to verify system message logging configuration information:

Command

Purpose

show logging console

Displays the console logging configuration.

show logging info

Displays the logging configuration.

show logging ip access-list cache

Displays the IP access list cache.

show logging ip access-list cache detail

Displays detailed information about the IP access list cache.

show logging ip access-list status

Displays the status of the IP access list cache.

show logging last number-lines

Displays the last number of lines of the log file.

show logging level [facility]

Displays the facility logging severity level configuration.

show logging logfile [start-time yyyy mmm dd hh:mm:ss] [end-time yyyy mmm dd hh:mm:ss]

Displays the messages in the log file.

show logging module

Displays the module logging configuration.

show logging monitor

Displays the monitor logging configuration.

show logging nvram [last number-lines]

Displays the messages in the NVRAM log.

show logging pending

Displays the syslog server pending distribution configuration.

show logging pending-diff

Displays the syslog server pending distribution configuration differences.

show logging server

Displays the syslog server configuration.

show logging session

Displays the logging session status.

show logging status

Displays the logging status.

show logging timestamp

Displays the logging time-stamp units configuration.

Chapter 10. Configuring Smart Call Home

This chapter contains the following sections:

- Information About Smart Call Home

- Guidelines and Limitations for Smart Call Home

- Prerequisites for Smart Call Home

- Default Call Home Settings

- Verifying the Smart Call Home Configuration

- Sample Syslog Alert Notification in Full-Text Format

- Sample Syslog Alert Notification in XML Format

Information About Smart Call Home

Smart Call Home provides e-mail-based notification of critical system events. Cisco Nexus Series switches provide a range of message formats for optimal compatibility with pager services, standard e-mail, or XML-based automated parsing applications. You can use this feature to page a network support engineer, e-mail a Network Operations Center, or use Cisco Smart Call Home services to automatically generate a case with the Technical Assistance Center (TAC).

If you have a service contract directly with Cisco, you can register your devices for the Smart Call Home service. Smart Call Home provides fast resolution of system problems by analyzing Smart Call Home messages sent from your devices and providing background information and recommendations. For issues that can be identified as known, particularly GOLD diagnostics failures, Automatic Service Requests will be generated by the Cisco TAC.

Smart Call Home offers the following features:

- Continuous device health monitoring and real-time diagnostic alerts.

- Analysis of Smart Call Home messages from your device and, where appropriate, Automatic Service Request generation, routed to the appropriate TAC team, including detailed diagnostic information to speed problem resolution.

- Secure message transport directly from your device or through a downloadable Transport Gateway (TG) aggregation point. You can use a TG aggregation point in cases that require support for multiple devices or in cases where security requirements mandate that your devices may not be connected directly to the Internet.

- Web-based access to Smart Call Home messages and recommendations, inventory and configuration information for all Smart Call Home devices, and field notices, security advisories, and end-of-life information.

- Smart Call Home Overview

- Smart Call Home Destination Profiles

- Smart Call Home Alert Groups

- Smart Call Home Message Levels

- Call Home Message Formats

Smart Call Home Overview

You can use Smart Call Home to notify an external entity when an important event occurs on your device. Smart Call Home delivers alerts to multiple recipients that you configure in destination profiles.

Smart Call Home includes a fixed set of predefined alerts on your switch. These alerts are grouped into alert groups and CLI commands that are assigned to execute when an alert in an alert group occurs. The switch includes the command output in the transmitted Smart Call Home message.

The Smart Call Home feature offers the following:

- Automatic execution and attachment of relevant CLI command output.

- Multiple message format options such as the following:

- Short Text—Text that is suitable for pagers or printed reports.

- Full Text—Fully formatted message information that is suitable for human reading.

- XML—Matching readable format that uses the Extensible Markup Language (XML) and the Adaptive Messaging Language (AML) XML schema definition (XSD). The XML format enables communication with the Cisco TAC.

- Multiple concurrent message destinations. You can configure up to 50 e-mail destination addresses for each destination profile.

Smart Call Home Destination Profiles

A Smart Call Home destination profile includes the following information:

- One or more alert groups—The group of alerts that trigger a specific Smart Call Home message if the alert occurs.

- One or more e-mail destinations—The list of recipients for the Smart Call Home messages that are generated by alert groups assigned to this destination profile.

- Message format—The format for the Smart Call Home message (short text, full text, or XML).

- Message severity level—The Smart Call Home severity level that the alert must meet before the switch generates a Smart Call Home message to all e-mail addresses in the destination profile. The switch does not generate an alert if the Smart Call Home severity level of the alert is lower than the message severity level set for the destination profile.

You can also configure a destination profile to allow periodic inventory update messages by using the inventory alert group that will send out periodic messages daily, weekly, or monthly.

Cisco Nexus switches support the following predefined destination profiles:

- CiscoTAC-1—Supports the Cisco-TAC alert group in XML message format.

- full-text-destination—Supports the full text message format.

- short-text-destination—Supports the short text message format.

Smart Call Home Alert Groups

An alert group is a predefined subset of Smart Call Home alerts that are supported in all Cisco Nexus devices. Alert groups allow you to select the set of Smart Call Home alerts that you want to send to a predefined or custom destination profile. The switch sends Smart Call Home alerts to e-mail destinations in a destination profile only if that Smart Call Home alert belongs to one of the alert groups associated with that destination profile and if the alert has a Smart Call Home message severity at or above the message severity set in the destination profile.

The following table lists the supported alert groups and the default CLI command output included in Smart Call Home messages generated for the alert group.

Alert Groups and Executed Commands

Alert Group

Description

Executed Commands

Cisco-TAC

All critical alerts from the other alert groups destined for Smart Call Home.

Execute commands based on the alert group that originates the alert.

Diagnostic

Events generated by diagnostics.

show diagnostic result module all detail

show moduleshow version

show tech-support platform callhome

Supervisor hardware

Events related to supervisor modules.

show diagnostic result module all detail

show moduleshow version

show tech-support platform callhome

Linecard hardware

Events related to standard or intelligent switching modules.

show diagnostic result module all detail

show moduleshow version

show tech-support platform callhome

Configuration

Periodic events related to configuration.

show version

show module

show running-config all

show startup-config

System

Events generated by a failure of a software system that is critical to unit operation.

show system redundancy status

show tech-support

Environmental

Events related to power, fan, and environment-sensing elements such as temperature alarms.

show environment

show logging last 1000

show module show version

show tech-support platform callhome

Inventory

Inventory status that is provided whenever a unit is cold booted, or when FRUs are inserted or removed. This alert is considered a noncritical event, and the information is used for status and entitlement.

show module

show version

show license usage

show inventory

show sprom all

show system uptime

Smart Call Home maps the syslog severity level to the corresponding Smart Call Home severity level for syslog port group messages.

You can customize predefined alert groups to execute additional show commands when specific events occur and send that show output with the Smart Call Home message.

You can add show commands only to full text and XML destination profiles. Short text destination profiles do not support additional show commands because they only allow 128 bytes of text.

Smart Call Home Message Levels

Smart Call Home allows you to filter messages based on their level of urgency. You can associate each destination profile (predefined and user defined) with a Smart Call Home message level threshold. The switch does not generate any Smart Call Home messages with a value lower than this threshold for the destination profile. The Smart Call Home message level ranges from 0 (lowest level of urgency) to 9 (highest level of urgency), and the default is 0 (the switch sends all messages).

Smart Call Home messages that are sent for syslog alert groups have the syslog severity level mapped to the Smart Call Home message level.

Note

Smart Call Home does not change the syslog message level in the message text.

The following table shows each Smart Call Home message level keyword and the corresponding syslog level for the syslog port alert group.

Severity and Syslog Level Mapping

Smart Call Home Level

Keyword

Syslog Level

Description

9

Catastrophic

N/A

Network-wide catastrophic failure.

8

Disaster

N/A

Significant network impact.

7

Fatal

Emergency (0)

System is unusable.

6

Critical

Alert (1)

Critical conditions that indicate that immediate attention is needed.

5

Major

Critical (2)

Major conditions.

4

Minor

Error (3)

Minor conditions.

3

Warning

Warning (4)

Warning conditions.

2

Notification

Notice (5)

Basic notification and informational messages.

1

Normal

Information (6)

Normal event signifying return to normal state.

0

Debugging

Debug (7)

Debugging messages.

Call Home Message Formats

Call Home supports the following message formats:

- Short text message format

- Common fields for all full text and XML messages

- Inserted fields for a reactive or proactive event message

- Inserted fields for an inventory event message

- Inserted fields for a user-generated test message

The following table describes the short text formatting option for all message types.

Short Text Message Format

Data Item

Description

Device identification

Configured device name

Date/time stamp

Time stamp of the triggering event

Error isolation message

Plain English description of triggering event

Alarm urgency level

Error level such as that applied to a system message

The following table describes the common event message format for full text or XML.

Common Fields for All Full Text and XML Messages

Data Item (Plain Text and XML)

Description (Plain Text and XML)

XML Tag (XML Only)

Time stamp

Date and time stamp of event in ISO time notation:

YYYY-MM-DD HH:MM:SS GMT+HH:MM

/aml/header/time

Message name

Name of message. Specific event names are listed in the preceding table.

/aml/header/name

Message type

Name of message type, such as reactive or proactive.

/aml/header/type

Message group

Name of alert group, such as syslog.

/aml/header/group

Severity level

Severity level of message.

/aml/header/level

Source ID

Product type for routing.

/aml/header/source

Device ID

Unique device identifier (UDI) for the end device that generated the message. This field should be empty if the message is nonspecific to a device. The format is type@Sid@serial:

- type is the product model number from backplane IDPROM.

- @ is a separator character.

- Sid is C, identifying the serial ID as a chassis serial number.

- serial is the number identified by the Sid field.

An example is WS-C6509@C@12345678

/aml/ header/deviceID

Customer ID

Optional user-configurable field used for contract information or other ID by any support service.

/aml/ header/customerID

Contract ID

Optional user-configurable field used for contract information or other ID by any support service.

/aml/ header /contractID

Site ID

Optional user-configurable field used for Cisco-supplied site ID or other data meaningful to alternate support service.

/aml/ header/siteID

Server ID

If the message is generated from the device, this is the unique device identifier (UDI) of the device.

The format is type@Sid@serial:

- type is the product model number from backplane IDPROM.

- @ is a separator character.

- Sid is C, identifying the serial ID as a chassis serial number.

- serial is the number identified by the Sid field.

An example is WS-C6509@C@12345678

/aml/header/serverID

Message description

Short text that describes the error.

/aml/body/msgDesc

Device name

Node that experienced the event (hostname of the device).

/aml/body/sysName

Contact name

Name of person to contact for issues associated with the node that experienced the event.

/aml/body/sysContact

Contact e-mail

E-mail address of person identified as the contact for this unit.

/aml/body/sysContactEmail

Contact phone number

Phone number of the person identified as the contact for this unit.

/aml/body/sysContactPhoneNumber

Street address

Optional field that contains the street address for RMA part shipments associated with this unit.

/aml/body/sysStreetAddress

Model name

Model name of the device (the specific model as part of a product family name).

/aml/body/chassis/name

Serial number

Chassis serial number of the unit.

/aml/body/chassis/serialNo

Chassis part number

Top assembly number of the chassis.

/aml/body/chassis/partNo

Fields specific to a particular alert group message are inserted here.

The following fields may be repeated if multiple CLI commands are executed for this alert group.

Command output name

Exact name of the issued CLI command.

/aml/attachments/attachment/name

Attachment type

Specific command output.

/aml/attachments/attachment/type

MIME type

Either plain text or encoding type.

/aml/attachments/attachment/mime

Command output text

Output of command automatically executed.

/aml/attachments/attachment/atdata

The following table describes the reactive event message format for full text or XML.

Inserted Fields for a Reactive or Proactive Event Message

Data Item (Plain Text and XML)

Description (Plain Text and XML)

XML Tag (XML Only)

Chassis hardware version

Hardware version of chassis.

/aml/body/chassis/hwVersion

Supervisor module software version

Top-level software version.

/aml/body/chassis/swVersion

Affected FRU name

Name of the affected FRU that is generating the event message.

/aml/body/fru/name

Affected FRU serial number

Serial number of the affected FRU.

/aml/body/fru/serialNo

Affected FRU part number

Part number of the affected FRU.

/aml/body/fru/partNo

FRU slot

Slot number of the FRU that is generating the event message.

/aml/body/fru/slot

FRU hardware version

Hardware version of the affected FRU.

/aml/body/fru/hwVersion

FRU software version

Software version(s) that is running on the affected FRU.

/aml/body/fru/swVersion

The following table describes the inventory event message format for full text or XML.

Inserted Fields for an Inventory Event Message

Data Item (Plain Text and XML)

Description (Plain Text and XML)

XML Tag (XML Only)

Chassis hardware version

Hardware version of the chassis.

/aml/body/chassis/hwVersion

Supervisor module software version

Top-level software version.

/aml/body/chassis/swVersion

FRU name

Name of the affected FRU that is generating the event message.

/aml/body/fru/name

FRU s/n

Serial number of the FRU.

/aml/body/fru/serialNo

FRU part number

Part number of the FRU.

/aml/body/fru/partNo

FRU slot

Slot number of the FRU.

/aml/body/fru/slot

FRU hardware version

Hardware version of the FRU.

/aml/body/fru/hwVersion

FRU software version

Software version(s) that is running on the FRU.

/aml/body/fru/swVersion

The following table describes the user-generated test message format for full text or XML.

Inserted Fields for a User-Generated Test Message

Data Item (Plain Text and XML)

Description (Plain Text and XML)

XML Tag (XML Only)

Process ID

Unique process ID.

/aml/body/process/id

Process state

State of process (for example, running or halted).

/aml/body/process/processState

Process exception

Exception or reason code.

/aml/body/process/exception

Guidelines and Limitations for Smart Call Home

- If there is no IP connectivity, or if the interface in the virtual routing and forwarding (VRF) instance to the profile destination is down, the switch cannot send Smart Call Home messages.

- Operates with any SMTP e-mail server.

Prerequisites for Smart Call Home

- You must have e-mail server connectivity.

- You must have access to contact name (SNMP server contact), phone, and street address information.

- You must have IP connectivity between the switch and the e-mail server.

- You must have an active service contract for the device that you are configuring.

Default Call Home Settings

Default Call Home Parameters

Parameters

Default

Destination message size for a message sent in full text format

4000000

Destination message size for a message sent in XML format

4000000

Destination message size for a message sent in short text format

4000

SMTP server port number if no port is specified

25

Alert group association with profile

All for full-text-destination and short-text-destination profiles. The cisco-tac alert group for the CiscoTAC-1 destination profile.

Format type

XML

Call Home message level

0 (zero)

Registering for Smart Call Home

Before You Begin

- Know the sMARTnet contract number for your switch

- Know your e-mail address

- Know your Cisco.com ID

Procedure

Step 1

In a browser, navigate to the Smart Call Home web page:
Click Here

Step 2

Under Getting Started, follow the directions to register Smart Call Home.

What to Do Next

Configure contact information.

Configuring Contact Information

You must configure the e-mail, phone, and street address information for Smart Call Home. You can optionally configure the contract ID, customer ID, site ID, and switch priority information.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# snmp-server contact sys-contact

Configures the SNMP sysContact.

Step 3

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 4

switch(config-callhome)# email-contact email-address

Configures the e-mail address for the primary person responsible for the switch.

The email-address can be up to 255 alphanumeric characters in an e-mail address format.

Note:
You can use any valid e-mail address. The address cannot contain spaces.

Step 5

switch(config-callhome)# phone-contact international-phone-number

Configures the phone number in international phone number format for the primary person responsible for the device. The international-phone-number can be up to 17 alphanumeric characters and must be in international phone number format.

Note:
The phone number cannot contain spaces. Use the plus (+) prefix before the number.

Step 6

switch(config-callhome)# streetaddress address

Configures the street address for the primary person responsible for the switch.

The address can be up to 255 alphanumeric characters. Spaces are accepted.

Step 7

switch(config-callhome)# contract-id contract-number

(Optional)
Configures the contract number for this switch from the service agreement.

The contract-number can be up to 255 alphanumeric characters.

Step 8

switch(config-callhome)# customer-id customer-number

(Optional)
Configures the customer number for this switch from the service agreement.

The customer-number can be up to 255 alphanumeric characters.

Step 9

switch(config-callhome)# site-id site-number

(Optional)
Configures the site number for this switch.

The site-number can be up to 255 alphanumeric characters in free format.

Step 10

switch(config-callhome)# switch-priority number

(Optional)
Configures the switch priority for this switch.

The range is from 0 to 7, with 0 being the highest priority and 7 the lowest. The default is 7.

Note:
Switch priority is used by the operations personnel or TAC support personnel to decide which Call Home message should be responded to first. You can prioritize Call Home alerts of the same severity from each switch.

Step 11

switch# show callhome

(Optional)
Displays a summary of the Smart Call Home configuration.

Step 12

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure the contact information for Call Home:

switch# configuration terminal
switch(config)# snmp-server contact personname@companyname.com
switch(config)# callhome
switch(config-callhome)# email-contact personname@companyname.com
switch(config-callhome)# phone-contact +1-800-123-4567
switch(config-callhome)# street-address 123 Anystreet St., Anycity, Anywhere

What to Do Next

Create a destination profile.

Creating a Destination Profile

You must create a user-defined destination profile and configure the message format for that new destination profile.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# destination-profile {ciscoTAC-1 {alert-group group | email-addr address | http URL | transport-method {email | http}} | profilename {alert-group group | email-addr address | format {XML | full-txt | short-txt} | http URL | message-level level | message-size size | transport-method {email | http}} | full-txt-destination {alert-group group | email-addr address | http URL | message-level level | message-size size | transport-method {email | http}} | short-txt-destination {alert-group group | email-addr address | http URL | message-level level | message-size size | transport-method {email | http}}}

Creates a new destination profile and sets the message format for the profile. The profile-name can be any alphanumeric string up to 31 characters.

For further details about this command, see the command reference for your platform.

Step 4

switch# show callhome destination-profile [profile name]

(Optional)
Displays information about one or more destination profiles.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to create a destination profile for Smart Call Home:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# destination-profile Noc101 format full-text

Modifying a Destination Profile

You can modify the following attributes for a predefined or user-defined destination profile:

- Destination address—The actual address, pertinent to the transport mechanism, to which the alert should be sent.

- Message formatting—The message format used for sending the alert (full text, short text, or XML).

- Message level—The Call Home message severity level for this destination profile.

- Message size—The allowed length of a Call Home message sent to the e-mail addresses in this destination profile.

Note

You cannot modify or delete the CiscoTAC-1 destination profile.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# destination-profile {name | full-txt-destination | short-txt-destination} email-addr address

Configures an e-mail address for a user-defined or predefined destination profile. You can configure up to 50 e-mail addresses in a destination profile.

Step 4

destination-profile {name | full-txt-destination | short-txt-destination} message-level number

Configures the Smart Call Home message severity level for this destination profile. The switch sends only alerts that have a matching or higher Smart Call Home severity level to destinations in this profile. The range for the number is from 0 to 9, where 9 is the highest severity level.

Step 5

switch(config-callhome)# destination-profile {name | full-txt-destination | short-txt-destination} message-size number

Configures the maximum message size for this destination profile. The range is from 0 to 5000000 for full-txt-destination and the default is 2500000. The range is from 0 to 100000 for short-txt-destination and the default is 4000. The value is 5000000 for CiscoTAC-1, which is not changeable.

Step 6

switch# show callhome destination-profile [profile name]

(Optional)
Displays information about one or more destination profiles.

Step 7

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to modify a destination profile for Smart Call Home:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# destination-profile full-text-destination email-addr person@example.com
switch(config-callhome)# destination-profile full-text-destination message-level 5
switch(config-callhome)# destination-profile full-text-destination message-size 10000
switch(config-callhome)#

What to Do Next

Associate an alert group with a destination profile.

Associating an Alert Group with a Destination Profile

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# destination-profile name alert-group {All | Cisco-TAC | Configuration | Diagnostic | Environmental | Inventory | License | Linecard-Hardware | Supervisor-Hardware | Syslog-group-port | System | Test}

Associates an alert group with this destination profile. Use the All keyword to associate all alert groups with the destination profile.

Step 4

switch# show callhome destination-profile [profile name]

(Optional)
Displays information about one or more destination profiles.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to associate all alert groups with the destination profile Noc101:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# destination-profile Noc101 alert-group All
switch(config-callhome)#

What to Do Next

Optionally, you can add show commands to an alert group and configure the SMTP e-mail server.

Adding Show Commands to an Alert Group

You can assign a maximum of five user-defined show commands to an alert group.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# alert-group {Configuration | Diagnostic | Environmental | Inventory | License | Linecard-Hardware | Supervisor-Hardware | Syslog-group-port | System | Test} user-def-cmd show-cmd

Adds the show command output to any Call Home messages sent for this alert group. Only valid show commands are accepted.

Note:
You cannot add user-defined show commands to the CiscoTAC-1 destination profile.

Step 4

switch# show callhome user-def-cmds

(Optional)
Displays information about all user-defined show commands added to alert groups.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to add the show ip routing command to the Cisco-TAC alert group:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# alert-group Configuration user-def-cmd show ip routing
switch(config-callhome)#

What to Do Next

Configure Smart Call Home to connect to the SMTP e-mail server.

Configuring E-Mail Server Details

You must configure the SMTP server address for the Smart Call Home functionality to work. You can also configure the from and reply-to e-mail addresses.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# transport email smtp-server ip-address [port number] [use-vrf vrf-name]

Configures the SMTP server as either the domain name server (DNS) name, IPv4 address, or IPv6 address.

The number range is from1 to 65535. The default port number is 25.

Optionally, you can configure the VRF instance to use when communicating with this SMTP server.

Step 4

switch(config-callhome)# transport email from email-address

(Optional)
Configures the e-mail from field for Smart Call Home messages.

Step 5

switch(config-callhome)# transport email reply-to email-address

(Optional)
Configures the e-mail reply-to field for Smart Call Home messages.

Step 6

switch# show callhome transport-email

(Optional)
Displays information about the e-mail configuration for Smart Call Home.

Step 7

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure the e-mail options for Smart Call Home messages:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# transport email smtp-server 192.0.2.10 use-vrf Red
switch(config-callhome)# transport email from person@example.com
switch(config-callhome)# transport email reply-to person@example.com
switch(config-callhome)#

What to Do Next

Configure periodic inventory notifications.

Configuring Periodic Inventory Notifications

You can configure the switch to periodically send a message with an inventory of all software services currently enabled and running on the device with hardware inventory information. The switch generates two Smart Call Home notifications; periodic configuration messages and periodic inventory messages.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome)# periodic-inventory notification [interval days] [timeofday time]

Configures periodic inventory messages.

The interval days range is from 1 to 30 days.

The default is 7 days.

The timeofday time is in HH:MM format.

Step 4

switch# show callhome

(Optional)
Displays information about Smart Call Home.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure the periodic inventory messages to generate every 20 days:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# periodic-inventory notification interval 20
switch(config-callhome)#

What to Do Next

Disable duplicate message throttling.

Disabling Duplicate Message Throttling

You can limit the number of duplicate messages received for the same event. By default, the switch limits the number of duplicate messages received for the same event. If the number of duplicate messages sent exceeds 30 messages within a 2-hour time frame, the switch discards further messages for that alert type.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome) # no duplicate-message throttle

Disables duplicate message throttling for Smart Call Home.

Duplicate message throttling is enabled by default.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to disable duplicate message throttling:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# no duplicate-message throttle
switch(config-callhome)#

What to Do Next

Enable Smart Call Home.

Enabling or Disabling Smart Call Home

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome) # [no] enable

Enables or disables Smart Call Home.

Smart Call Home is disabled by default.

Step 4

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to enable Smart Call Home:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# enable
switch(config-callhome)#

What to Do Next

Optionally, generate a test message.

Testing the Smart Call Home Configuration

Before You Begin

Verify that the message level for the destination profile is set to 2 or lower.

Important:
Smart Call Home testing fails when the message level for the destination profile is set to 3 or higher.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# callhome

Enters Smart Call Home configuration mode.

Step 3

switch(config-callhome) # callhome send diagnostic

Sends the specified Smart Call Home message to all configured destinations.

Step 4

switch(config-callhome) # callhome test

Sends a test message to all configured destinations.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to enable Smart Call Home:

switch# configuration terminal
switch(config)# callhome
switch(config-callhome)# callhome send diagnostic
switch(config-callhome)# callhome test
switch(config-callhome)#

Verifying the Smart Call Home Configuration

Use one of the following commands to verify the configuration:

Command

Purpose

show callhome

Displays the status for Smart Call Home.

show callhome destination-profile name

Displays one or more Smart Call Home destination profiles.

show callhome pending-diff

Displays the differences between he pending and running Smart Call Home configuration.

show callhome status

Displays the Smart Call Home status.

show callhome transport-email

Displays the e-mail configuration for Smart Call Home.

show callhome user-def-cmds

Displays CLI commands added to any alert groups.

show running-config [callhome | callhome-all]

Displays the running configuration for Smart Call Home.

show startup-config callhome

Displays the startup configuration for Smart Call Home.

show tech-support callhome

Displays the technical support output for Smart Call Home.

Sample Syslog Alert Notification in Full-Text Format

This sample shows the full-text format for a syslog port alert-group notification:

source:MDS9000
Switch Priority:7
Device Id:WS-C6509@C@FG@07120011
Customer Id:Example.com
Contract Id:123
Site Id:San Jose
Server Id:WS-C6509@C@FG@07120011
Time of Event:2004-10-08T11:10:44
Message Name:SYSLOG_ALERT
Message Type:Syslog
Severity Level:2
System Name:10.76.100.177
Contact Name:User Name
Contact Email:person@example.com
Contact Phone:+1-408-555-1212
Street Address:#1234 Any Street, Any City, Any State, 12345
Event Description:2006 Oct  8 11:10:44 10.76.100.177 %PORT-5-IF_TRUNK_UP:
%$VLAN 1%$ Interface e2/5, vlan 1 is up
syslog_facility:PORT
start chassis information:
Affected Chassis:WS-C6509
Affected Chassis Serial Number:FG@07120011
Affected Chassis Hardware Version:0.104
Affected Chassis Software Version:3.1(1)
Affected Chassis Part No:73-8607-01
end chassis information:

Sample Syslog Alert Notification in XML Format

This sample shows the XML format for a syslog port alert-group notification:

From: example
Sent: Wednesday, April 25, 2007 7:20 AM
To: User (user)
Subject: System Notification From Router - syslog - 2007-04-25 14:19:55
GMT+00:00
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-env="http://www.w3.org/2003/05/soap-envelope">
<soap-env:Header>
<aml-session:Session xmlns:aml-session="http://www.example.com/2004/01/aml-session"
soap-env:mustUnderstand="true" soap-env:role=
"http://www.w3.org/2003/05/soap-envelope/role/next">
<aml-session:To>http://tools.example.com/services/DDCEService</aml-session:To>
<aml-session:Path>
<aml-session:Via>http://www.example.com/appliance/uri</aml-session:Via>
</aml-session:Path>
<aml-session:From>http://www.example.com/appliance/uri</aml-session:From>
<aml-session:MessageId>M2:69000101:C9D9E20B</aml-session:MessageId>
</aml-session:Session>
</soap-env:Header>
<soap-env:Body>
<aml-block:Block xmlns:aml-block="http://www.example.com/2004/01/aml-block">
<aml-block:Header>
<aml-block:Type>http://www.example.com/2005/05/callhome/syslog</aml-block:Type>
<aml-block:CreationDate>2007-04-25 14:19:55 GMT+00:00</aml-block:CreationDate>
<aml-block:Builder>
<aml-block:Name>Cat6500</aml-block:Name>
<aml-block:Version>2.0</aml-block:Version>
</aml-block:Builder>
<aml-block:BlockGroup>
<aml-block:GroupId>G3:69000101:C9F9E20C</aml-block:GroupId>
<aml-block:Number>0</aml-block:Number>
<aml-block:IsLast>true</aml-block:IsLast>
<aml-block:IsPrimary>true</aml-block:IsPrimary>
<aml-block:WaitForPrimary>false</aml-block:WaitForPrimary>
</aml-block:BlockGroup>
<aml-block:Severity>2</aml-block:Severity>
</aml-block:Header>
<aml-block:Content>
<ch:Call Home xmlns:ch="http://www.example.com/2005/05/callhome" version="1.0">
<ch:EventTime>2007-04-25 14:19:55 GMT+00:00</ch:EventTime>
<ch:MessageDescription>03:29:29: %CLEAR-5-COUNTERS: Clear counter on all
interfaces by console</ch:MessageDescription>
<ch:Event>
<ch:Type>syslog</ch:Type>
<ch:SubType>
</ch:SubType>
<ch:Brand>Cisco Systems</ch:Brand>
<ch:Series>Catalyst 6500 Series Switches</ch:Series>
</ch:Event>
<ch:CustomerData>
<ch:UserData>
<ch:Email>person@example.com</ch:Email>
</ch:UserData>
<ch:ContractData>
<ch:CustomerId>12345</ch:CustomerId>
<ch:SiteId>building 1</ch:SiteId>
<ch:ContractId>abcdefg12345</ch:ContractId>
<ch:DeviceId>WS-C6509@C@69000101</ch:DeviceId>
</ch:ContractData>
<ch:SystemInfo>
<ch:Name>Router</ch:Name>
<ch:Contact>
</ch:Contact>
<ch:ContactEmail>user@example.com</ch:ContactEmail>
<ch:ContactPhoneNumber>+1-408-555-1212</ch:ContactPhoneNumber>
<ch:StreetAddress>#1234 Any Street, Any City, Any State, 12345
</ch:StreetAddress>
</ch:SystemInfo>
</ch:CustomerData>
<ch:Device>
<rme:Chassis xmlns:rme="http://www.example.com/rme/4.0">
<rme:Model>WS-C6509</rme:Model>
<rme:HardwareVersion>1.0</rme:HardwareVersion>
<rme:SerialNumber>69000101</rme:SerialNumber>
<rme:AdditionalInformation>
<rme:AD name="PartNumber" value="73-3438-03 01" />
<rme:AD name="SoftwareVersion" value="4.0(20080421:012711)" />
</rme:AdditionalInformation>
</rme:Chassis>
</ch:Device>
</ch:Call Home>
</aml-block:Content>
<aml-block:Attachments>
<aml-block:Attachment type="inline">
<aml-block:Name>show logging</aml-block:Name>
<aml-block:Data encoding="plain">
<![CDATA[Syslog logging: enabled (0 messages dropped, 0 messages
rate-limited, 0 flushes, 0 overruns, xml disabled, filtering disabled)
Console logging: level debugging, 53 messages logged, xml disabled,
filtering disabled    Monitor logging: level debugging, 0 messages logged,
xml disabled,filtering disabled    Buffer logging: level debugging,
53 messages logged, xml disabled,      filtering disabled    Exception
Logging: size (4096 bytes)    Count and timestamp logging messages: disabled
Trap logging: level informational, 72 message lines logged
Log Buffer (8192 bytes):
00:00:54: curr is 0x20000
00:00:54: RP: Currently running ROMMON from F2 region
00:01:05: %SYS-5-CONFIG_I: Configured from memory by console
00:01:09: %SYS-5-RESTART: System restarted --Cisco IOS Software,
s72033_rp Software (s72033_rp-ADVENTERPRISEK9_DBG-VM), Experimental
Version 12.2(20070421:012711) Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 26-Apr-07 15:54 by xxx
Firmware compiled 11-Apr-07 03:34 by integ Build [100]00:01:01: %PFREDUN-6-ACTIVE:
Initializing as ACTIVE processor for this switch00:01:01: %SYS-3-LOGGER_FLUSHED:
System was paused for 00:00:00 to ensure console debugging output.00:03:00: SP: SP:
Currently running ROMMON from F1 region00:03:07: %C6K_PLATFORM-SP-4-CONFREG_BREAK
_ENABLED: The default factory setting for config register is 0x2102.It is advisable
to retain 1 in 0x2102 as it prevents returning to ROMMON when break is issued.00:03:18:
%SYS-SP-5-RESTART: System restarted --Cisco IOS Software, s72033_sp Software
(s72033_sp-ADVENTERPRISEK9_DBG-VM), Experimental Version 12.2(20070421:012711)Copyright
(c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 26-Apr-07 18:00 by xxx
00:03:18: %SYS-SP-6-BOOTTIME: Time taken to reboot after reload =  339 seconds
00:03:18: %OIR-SP-6-INSPS: Power supply inserted in slot 1
00:03:18: %C6KPWR-SP-4-PSOK: power supply 1 turned on.
00:03:18: %OIR-SP-6-INSPS: Power supply inserted in slot00:01:09: %SSH-5-ENABLED:
SSH 1.99 has been enabled
00:03:18: %C6KPWR-SP-4-PSOK: power supply 2 turned on.
00:03:18: %C6KPWR-SP-4-PSREDUNDANTMISMATCH: power supplies rated outputs do not match.
00:03:18: %C6KPWR-SP-4-PSREDUNDANTBOTHSUPPLY: in power-redundancy mode, system is
operating on both power supplies.
00:01:10: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
00:01:10: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is OFF
00:03:20: %C6KENV-SP-4-FANHIOUTPUT: Version 2 high-output fan-tray is in effect
00:03:22: %C6KPWR-SP-4-PSNOREDUNDANCY: Power supplies are not in full redundancy,
power usage exceeds lower capacity supply
00:03:26: %FABRIC-SP-5-FABRIC_MODULE_ACTIVE: The Switch Fabric Module in slot 6
became active.
00:03:28: %DIAG-SP-6-RUN_MINIMUM: Module 6: Running Minimal Diagnostics...
00:03:50: %DIAG-SP-6-DIAG_OK: Module 6: Passed Online Diagnostics
00:03:50: %OIR-SP-6-INSCARD: Card inserted in slot 6, interfaces are now online
00:03:51: %DIAG-SP-6-RUN_MINIMUM: Module 3: Running Minimal Diagnostics...
00:03:51: %DIAG-SP-6-RUN_MINIMUM: Module 7: Running Minimal Diagnostics...
00:03:51: %DIAG-SP-6-RUN_MINIMUM: Module 9: Running Minimal Diagnostics...
00:01:51: %MFIB_CONST_RP-6-REPLICATION_MODE_CHANGE: Replication Mode Change Detected.
Current system replication mode is Ingress
00:04:01: %DIAG-SP-6-DIAG_OK: Module 3: Passed Online Diagnostics
00:04:01: %OIR-SP-6-DOWNGRADE: Fabric capable module 3 not at an appropriate hardware
revision level, and can only run in flowthrough mode
00:04:02: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces are now online
00:04:11: %DIAG-SP-6-DIAG_OK: Module 7: Passed Online Diagnostics
00:04:14: %OIR-SP-6-INSCARD: Card inserted in slot 7, interfaces are now online
00:04:35: %DIAG-SP-6-DIAG_OK: Module 9: Passed Online Diagnostics
00:04:37: %OIR-SP-6-INSCARD: Card inserted in slot 9, interfaces are now online
00:00:09: DaughterBoard (Distributed Forwarding Card 3)
Firmware compiled 11-Apr-07 03:34 by integ Build [100]
00:00:22: %SYS-DFC4-5-RESTART: System restarted --
Cisco DCOS Software, c6lc2 Software (c6lc2-SPDBG-VM), Experimental Version 4.0
(20080421:012711)Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 26-Apr-08 17:20 by xxx
00:00:23: DFC4: Currently running ROMMON from F2 region
00:00:25: %SYS-DFC2-5-RESTART: System restarted --
Cisco IOS Software, c6slc Software (c6slc-SPDBG-VM), Experimental Version 12.2
(20070421:012711)Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Thu 26-Apr-08 16:40 by username1
00:00:26: DFC2: Currently running ROMMON from F2 region
00:04:56: %DIAG-SP-6-RUN_MINIMUM: Module 4: Running Minimal Diagnostics...
00:00:09: DaughterBoard (Distributed Forwarding Card 3)
Firmware compiled 11-Apr-08 03:34 by integ Build [100]
slot_id is 8
00:00:31: %FLASHFS_HES-DFC8-3-BADCARD: /bootflash:: The flash card seems to
be corrupted
00:00:31: %SYS-DFC8-5-RESTART: System restarted --
Cisco DCOS Software, c6lc2 Software (c6lc2-SPDBG-VM), Experimental Version 4.0
(20080421:012711)Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 26-Apr-08 17:20 by username1
00:00:31: DFC8: Currently running ROMMON from S (Gold) region
00:04:59: %DIAG-SP-6-RUN_MINIMUM: Module 2: Running Minimal Diagnostics...
00:05:12: %DIAG-SP-6-RUN_MINIMUM: Module 8: Running Minimal Diagnostics...
00:05:13: %DIAG-SP-6-RUN_MINIMUM: Module 1: Running Minimal Diagnostics...
00:00:24: %SYS-DFC1-5-RESTART: System restarted --
Cisco DCOS Software, c6slc Software (c6slc-SPDBG-VM), Experimental Version 4.0
(20080421:012711)Copyright (c) 1986-2008 by Cisco Systems, Inc.
Compiled Thu 26-Apr-08 16:40 by username1
00:00:25: DFC1: Currently running ROMMON from F2 region
00:05:30: %DIAG-SP-6-DIAG_OK: Module 4: Passed Online Diagnostics
00:05:31: %SPAN-SP-6-SPAN_EGRESS_REPLICATION_MODE_CHANGE: Span Egress HW
Replication Mode Change Detected. Current replication mode for unused asic
session 0 is Centralized
00:05:31: %SPAN-SP-6-SPAN_EGRESS_REPLICATION_MODE_CHANGE: Span Egress HW
Replication Mode Change Detected. Current replication mode for unused asic
session 1 is Centralized
00:05:31: %OIR-SP-6-INSCARD: Card inserted in slot 4, interfaces are now online
00:06:02: %DIAG-SP-6-DIAG_OK: Module 1: Passed Online Diagnostics
00:06:03: %OIR-SP-6-INSCARD: Card inserted in slot 1, interfaces are now online
00:06:31: %DIAG-SP-6-DIAG_OK: Module 2: Passed Online Diagnostics
00:06:33: %OIR-SP-6-INSCARD: Card inserted in slot 2, interfaces are now online
00:04:30: %XDR-6-XDRIPCNOTIFY: Message not sent to slot 4/0 (4) because of IPC
error timeout. Disabling linecard. (Expected during linecard OIR)
00:06:59: %DIAG-SP-6-DIAG_OK: Module 8: Passed Online Diagnostics
00:06:59: %OIR-SP-6-DOWNGRADE_EARL: Module 8 DFC installed is not identical to
system PFC and will perform at current system operating mode.
00:07:06: %OIR-SP-6-INSCARD: Card inserted in slot 8, interfaces are now online
Router#]]>
</aml-block:Data>
</aml-block:Attachment>
</aml-block:Attachments>
</aml-block:Block>
</soap-env:Body>
</soap-env:Envelope>

Chapter 11. Configuring Rollback

This chapter contains the following sections:

- Information About Rollbacks

- Guidelines and Limitations for Rollbacks

- Creating a Checkpoint

- Implementing a Rollback

- Verifying the Rollback Configuration

Information About Rollbacks

The rollback feature allows you to take a snapshot, or user checkpoint, of the Cisco NX-OS configuration and then reapply that configuration to your switch at any point without having to reload the switch. A rollback allows any authorized administrator to apply this checkpoint configuration without requiring expert knowledge of the features configured in the checkpoint.

You can create a checkpoint copy of the current running configuration at any time. Cisco NX-OS saves this checkpoint as an ASCII file which you can use to roll back the running configuration to the checkpoint configuration at a future time. You can create multiple checkpoints to save different versions of your running configuration.

When you roll back the running configuration, you can trigger an atomic rollback. An atomic rollback implements a rollback only if no errors occur.

Guidelines and Limitations for Rollbacks

A rollback has the following configuration guidelines and limitations:

- You can create up to ten checkpoint copies.

- You cannot apply the checkpoint file of one switch into another switch.

- Your checkpoint file names must be 75 characters or less.

- You cannot start a checkpoint filename with the word system.

- You can start a checkpoint filename with the word auto.

- You can name a checkpoint file summary or any abbreviation of the word summary.

- Only one user can perform a checkpoint, rollback, or copy the running configuration to the startup configuration at the same time.

- After you enter the write erase and reload command, checkpoints are deleted. You can use the clear checkpoint database command to clear out all checkpoint files.

- When checkpoints are created on bootflash, differences with the running-system configuration cannot be performed before performing the rollback, and the system reports “No Changes.”

- Checkpoints are local to a switch.

- Checkpoints that are created using the checkpoint and checkpoint checkpoint_name commands are present upon a switchover for all switches.

- A rollback to files on bootflash is supported only on files that are created using the checkpoint checkpoint_name command and not on any other type of ASCII file.

- Checkpoint names must be unique. You cannot overwrite previously saved checkpoints with the same name.

- The Cisco NX-OS commands may differ from the Cisco IOS commands.

Creating a Checkpoint

You can create up to ten checkpoints of your configuration per switch.

Procedure

Command or Action

Purpose

Step 1

switch# checkpoint { [cp-name] [description descr] |file file-name

Example:

switch# checkpoint stable

Creates a checkpoint of the running configuration to either a user checkpoint name or a file. The checkpoint name can be any alphanumeric string up to 80 characters but cannot contain spaces. If you do not provide a name, Cisco NX-OS sets the checkpoint name to user-checkpoint-<number> where number is from 1 to 10.

The description can contain up to 80 alphanumeric characters, including spaces.

Step 2

switch# no checkpointcp-name

Example:

switch# no checkpoint stable

(Optional)
You can use the no form of the checkpoint command to remove a checkpoint name.

Use the delete command to remove a checkpoint file.

Step 3

switch# show checkpointcp-name

Example:
[ all]

switch# show checkpoint stable

(Optional) Displays the contents of the checkpoint name.

Implementing a Rollback

You can implement a rollback to a checkpoint name or file. Before you implement a rollback, you can view the differences between source and destination checkpoints that reference current or saved configurations.

Note

If you make a configuration change during an atomic rollback, the rollback will fail.

Procedure

Command or Action

Purpose

Step 1

show diff rollback-patch {checkpoint src-cp-name | running-config | startup-config | file source-file} {checkpoint dest-cp-name | running-config | startup-config | file dest-file}

Example:

switch# show diff rollback-patch checkpoint stable
running-config

Displays the differences between the source and destination checkpoint selections.

Step 2

rollback running-config {checkpoint cp-name | file cp-file} atomic

Example:

switch# rollback running-config checkpoint stable

Creates an atomic rollback to the specified checkpoint name or file if no errors occur.

The following example shows how to create a checkpoint file and then implement an atomic rollback to a user checkpoint name:

switch# checkpoint stable
switch# rollback running-config checkpoint stable atomic

Verifying the Rollback Configuration

Use the following commands to verify the rollback configuration:

Command

Purpose

show checkpoint name [ all]

Displays the contents of the checkpoint name.

show checkpoint all [user | system]

Displays the contents of all checkpoints in the current switch. You can limit the displayed checkpoints to user or system-generated checkpoints.

show checkpoint summary [user | system]

Displays a list of all checkpoints in the current switch. You can limit the displayed checkpoints to user or system-generated checkpoints.

show diff rollback-patch {checkpoint src-cp-name | running-config | startup-config | file source-file} {checkpoint dest-cp-name | running-config | startup-config | file dest-file}

Displays the differences between the source and destination checkpoint selections.

show rollback log [exec | verify]

Displays the contents of the rollback log.

Note

Use the clear checkpoint database command to delete all checkpoint files.

Chapter 12. Configuring DNS

This chapter contains the following sections:

- Information About DNS Client

- Prerequisites for DNS Clients

- Licensing Requirements for DNS Clients

- Default Settings for DNS Clients

- Configuring DNS Clients

Information About DNS Client

If your network devices require connectivity with devices in networks for which you do not control name assignment, you can assign device names that uniquely identify your devices within the entire internetwork using the domain name server (DNS). DNS uses a hierarchical scheme for establishing hostnames for network nodes, which allows local control of the segments of the network through a client-server scheme. The DNS system can locate a network device by translating the hostname of the device into its associated IP address.

On the Internet, a domain is a portion of the naming hierarchy tree that refers to general groupings of networks based on the organization type or geography. Domain names are pieced together with periods (.) as the delimiting characters. For example, Cisco is a commercial organization that the Internet identifies by a com domain, so its domain name is cisco.com. A specific hostname in this domain, the File Transfer Protocol (FTP) system, for example, is identified as ftp.cisco.com.

- Name Servers

- DNS Operation

- High Availability

Name Servers

Name servers keep track of domain names and know the parts of the domain tree for which they have complete information. A name server may also store information about other parts of the domain tree. To map domain names to IP addresses in Cisco NX-OS, you must first identify the hostnames, then specify a name server, and enable the DNS service.

Cisco NX-OS allows you to statically map IP addresses to domain names. You can also configure Cisco NX-OS to use one or more domain name servers to find an IP address for a hostname.

DNS Operation

A name server handles client-issued queries to the DNS server for locally defined hosts within a particular zone as follows:

- An authoritative name server responds to DNS user queries for a domain name that is under its zone of authority by using the permanent and cached entries in its own host table. If the query is for a domain name that is under its zone of authority but for which it does not have any configuration information, the authoritative name server replies that no such information exists.

- A name server that is not configured as the authoritative name server responds to DNS user queries by using information that it has cached from previously received query responses. If no router is configured as the authoritative name server for a zone, queries to the DNS server for locally defined hosts receive nonauthoritative responses.

Name servers answer DNS queries (forward incoming DNS queries or resolve internally generated DNS queries) according to the forwarding and lookup parameters configured for the specific domain.

High Availability

Cisco NX-OS supports stateless restarts for the DNS client. After a reboot or supervisor switchover, Cisco NX-OS applies the running configuration.

Prerequisites for DNS Clients

The DNS client has the following prerequisites:

- You must have a DNS name server on your network.

Licensing Requirements for DNS Clients

The following table shows the licensing requirements for this feature:

Product

Licence Rquirement

Cicco NX-OS

DNS requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.

Default Settings for DNS Clients

The following table shows the default settings for DNS client parameters.

Parameter

Default

DNS client

Enabled

Configuring DNS Clients

You can configure the DNS client to use a DNS server on your network.

Before You Begin

- Ensure that you have a domain name server on your network.

Procedure

Command or Action

Purpose

Step 1

switch# configuration terminal

Enters global configuration mode.

Step 2

switch(config)# vrf context managment

Specifies a configurable virtual and routing (VRF) name.

Step 3

switch(config)# ip host name address1 [address2... address6]

Defines up to six static hostname-to-address mappings in the host name cache.

Step 4

switch(config)# ip domain name name [use-vrf vrf-name]

(Optional)
Defines the default domain name server that Cisco NX-OS uses to complete unqualified hostnames. You can optionally define a VRF that Cisco NX-OS uses to resolve this domain name server if it cannot be resolved in the VRF that you configured this domain name under.

Cisco NX-OS appends the default domain name to any host name that does not contain a complete domain name before starting a domain-name lookup.

Step 5

switch(config)# ip domain-list name [use-vrf vrf-name]

(Optional)
Defines additional domain name servers that Cisco NX-OS can use to complete unqualified hostnames. You can optionally define a VRF that Cisco NX-OS uses to resolve this domain name server if it cannot be resolved in the VRF that you configured this domain name under.

Cisco NX-OS uses each entry in the domain list to append that domain name to any hostname that does not contain a complete domain name before starting a domain-name lookup. Cisco NX-OS continues this for each entry in the domain list until it finds a match.

Step 6

switch(config)# ip name-server server-address1 [server-address2... server-address6] [use-vrf vrf-name]

(Optional)
Defines up to six name servers. The address can be either an IPv4 address or an IPv6 address.

You can optionally define a VRF that Cisco NX-OS uses to reach this name server if it cannot be reached in the VRF that you configured this name server under.

Step 7

switch(config)# ip domain-lookup

(Optional)
Enables DNS-based address translation. This feature is enabled by default.

Step 8

switch(config)# show hosts

(Optional)
Displays information about DNS.

Step 9

switch(config)# exit

Exits configuration mode and returns to EXEC mode.

Step 10

switch# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

The following example shows how to configure a default domain name and enable DNS lookup:

switch# config t
switch(config)# vrf context management
switch(config)# ip domain-name mycompany.com
switch(config)# ip name-server 172.68.0.10
switch(config)# ip domain-lookup

Chapter 13. Configuring SNMP

This chapter contains the following sections:

- Information About SNMP

- Licensing Requirements for SNMP

- Guidelines and Limitations for SNMP

- Default SNMP Settings

- Disabling SNMP

- Verifying the SNMP Configuration

Information About SNMP

The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

- SNMP Functional Overview

- SNMP Notifications

- SNMPv3

SNMP Functional Overview

The SNMP framework consists of three parts:

- An SNMP manager—The system used to control and monitor the activities of network devices using SNMP.

- An SNMP agent—The software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The Cisco Nexus device supports the agent and MIB. To enable the SNMP agent, you must define the relationship between the manager and the agent.

- A managed information base (MIB)—The collection of managed objects on the SNMP agent

Note

Cisco NX-OS does not support SNMP sets for Ethernet MIBs.

The Cisco Nexus device supports SNMPv1, SNMPv2c, and SNMPv3. Both SNMPv1 and SNMPv2c use a community-based form of security.

SNMP is defined in RFC 3410 ( Click Here ), RFC 3411 ( Click Here ), RFC 3412 ( Click Here ), RFC 3413 ( Click Here ), RFC 3414 ( Click Here ), RFC 3415 ( Click Here ), RFC 3416 ( Click Here ), RFC 3417 ( Click Here ), RFC 3418 ( Click Here ), and RFC 3584 ( Click Here ).

SNMP Notifications

A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.

Cisco NX-OS generates SNMP notifications as either traps or informs. A trap is an asynchronous, unacknowledged message sent from the agent to the SNMP managers listed in the host receiver table. Informs are asynchronous messages sent from the SNMP agent to the SNMP manager which the manager must acknowledge receipt of.

Traps are less reliable than informs because the SNMP manager does not send any acknowledgment when it receives a trap. The switch cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the Cisco Nexus device never receives a response, it can send the inform request again.

You can configure Cisco NX-OS to send notifications to multiple host receivers.

SNMPv3

SNMPv3 provides secure access to devices by a combination of authenticating and encrypting frames over the network. The security features provided in SNMPv3 are the following:

- Message integrity—Ensures that a packet has not been tampered with in-transit.

- Authentication—Determines the message is from a valid source.

- Encryption—Scrambles the packet contents to prevent it from being seen by unauthorized sources.

SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the role in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security mechanism is employed when handling an SNMP packet.

- Security Models and Levels for SNMPv1, v2, and v3

- User-Based Security Model

- CLI and SNMP User Synchronization

- Group-Based SNMP Access

Security Models and Levels for SNMPv1, v2, and v3

The security level determines if an SNMP message needs to be protected from disclosure and if the message needs to be authenticated. The various security levels that exist within a security model are as follows:

- noAuthNoPriv—Security level that does not provide authentication or encryption. This level is not supported for SNMPv3.

- authNoPriv—Security level that provides authentication but does not provide encryption.

- authPriv—Security level that provides both authentication and encryption.

Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. The security model combined with the security level determine the security mechanism applied when the SNMP message is processed.

SNMP Security Models and Levels

Model

Level

Authentication

Encryption

What Happens

v1

noAuthNoPriv

Community string

No

Uses a community string match for authentication.

v2c

noAuthNoPriv

Community string

No

Uses a community string match for authentication.

v3

authNoPriv

HMAC-MD5 or HMAC-SHA

No

Provides authentication based on the Hash-Based Message Authentication Code (HMAC) Message Digest 5 (MD5) algorithm or the HMAC Secure Hash Algorithm (SHA).

v3

authPriv

HMAC-MD5 or HMAC-SHA

DES

Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption in addition to authentication based on the Cipher Block Chaning (CBC) DES (DES-56) standard.

User-Based Security Model

SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services:

- Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized manner and that data sequences have not been altered to an extent greater than can occur nonmaliciously.

- Message origin authentication—Confirms that the claimed identity of the user who received the data was originated.

- Message confidentiality—Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes.

SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages.

Cisco NX-OS uses two authentication protocols for SNMPv3:

- HMAC-MD5-96 authentication protocol

- HMAC-SHA-96 authentication protocol

Cisco NX-OS uses Advanced Encryption Standard (AES) as one of the privacy protocols for SNMPv3 message encryption and conforms with RFC 3826.

The priv option offers a choice of DES or 128-bit AES encryption for SNMP security encryption. The priv option and the aes-128 token indicates that this privacy password is for generating a 128-bit AES key #.The AES priv password can have a minimum of eight characters. If the passphrases are specified in clear text, you can specify a maximum of 64 characters. If you use the localized key, you can specify a maximum of 130 characters.

Note

For an SNMPv3 operation using the external AAA server, you must use AES for the privacy protocol in user configuration on the external AAA server.

CLI and SNMP User Synchronization

SNMPv3 user management can be centralized at the Access Authentication and Accounting (AAA) server level. This centralized user management allows the SNMP agent in Cisco NX-OS to leverage the user authentication service of the AAA server. Once user authentication is verified, the SNMP PDUs are processed further. Additionally, the AAA server is also used to store user group names. SNMP uses the group names to apply the access/role policy that is locally available in the switch.

Any configuration changes made to the user group, role, or password results in database synchronization for both SNMP and AAA.

Cisco NX-OS synchronizes user configuration in the following ways:

- The auth passphrase specified in the snmp-server user command becomes the password for the CLI user.

- The password specified in the username command becomes the auth and priv passphrases for the SNMP user.

- If you create or delete a user using either SNMP or the CLI, the user is created or deleted for both SNMP and the CLI.

- User-role mapping changes are synchronized in SNMP and the CLI.

- Role changes (deletions or modifications from the CLI) are synchronized to SNMP.

Note

When you configure passphrase/password in localized key/encrypted format, Cisco NX-OS does not synchronize the user information (passwords, rules, etc.).

Group-Based SNMP Access

Note

Because a group is a standard SNMP term used industry-wide, roles are referred to as groups in this SNMP section.

SNMP access rights are organized by groups. Each group in SNMP is similar to a role through the CLI. Each group is defined with three accesses: read access, write access, and notification access. Each access can be enabled or disabled within each group.

You can begin communicating with the agent once your username is created, your roles are set up by your administrator, and you are added to the roles.

Licensing Requirements for SNMP

This feature does not require a license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the Cisco NX-OS Licensing Guide.

Guidelines and Limitations for SNMP

Cisco NX-OS supports read-only access to Ethernet MIBs.

For more information about supported MIBs, see the following URL:

Click Here

Cisco NX-OS does not support the SNMPv3 noAuthNoPriv security level.

Default SNMP Settings

Default SNMP Parameters

Parameters

Default

license notifications

Enabled

linkUp/Down notification type

ietf-extended

Configuring SNMP Users

Note

The commands used to configure SNMP users in Cisco NX-OS are different from those used to configure users in Cisco IOS.

Procedure

Command or Action

Purpose

Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

switch(config)# snmp-server user name [auth {md5 | sha} passphrase [auto] [priv [aes-128] passphrase] [engineID id] [localizedkey]]

Example:

switch(config)# snmp-server user Admin auth sha abcd1234 priv abcdefgh

Configures an SNMP user with authentication and privacy parameters.

The passphrase can be any case-sensitive, alphanumeric string up to 64 characters.

If you use the localizedkey keyword, the passphrase can be any case-sensitive, alphanumeric string up to 130 characters.

The engineID format is a 12-digit, colon-separated decimal number.

Step 3

switch# show snmp user

Example:

switch(config) # show snmp user

(Optional)
Displays information about one or more SNMP users.

Step 4

copy running-config startup-config

Example:

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure an SNMP user:

switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# snmp-server user Admin auth sha abcd1234 priv abcdefgh

Enforcing SNMP Message Encryption

You can configure SNMP to require authentication or encryption for incoming requests. By default, the SNMP agent accepts SNMPv3 messages without authentication and encryption. When you enforce privacy, Cisco NX-OS responds with an authorization error for any SNMPv3 PDU request that uses a security level parameter of either noAuthNoPriv or authNoPriv.

Use the following command in global configuration mode to enforce SNMP message encryption for a specific user:

Command

Purpose

switch(config)# snmp-server user name enforcePriv

Enforces SNMP message encryption for this user.

Use the following command in global configuration mode to enforce SNMP message encryption for all users:

Command

Purpose

switch(config)# snmp-server globalEnforcePriv

Enforces SNMP message encryption for all users.

Assigning SNMPv3 Users to Multiple Roles

After you configure an SNMP user, you can assign multiple roles for the user.

Note

Only users who belong to a network-admin role can assign roles to other users.

Command

Purpose

switch(config)# snmp-server user name group

Associates this SNMP user with the configured user role.

Creating SNMP Communities

You can create SNMP communities for SNMPv1 or SNMPv2c.

Command

Purpose

switch(config)# snmp-server community name group {ro | rw}

Creates an SNMP community string.

Filtering SNMP Requests

You can assign an access list (ACL) to a community to filter incoming SNMP requests. If the assigned ACL allows the incoming request packet, SNMP processes the request. If the ACL denies the request, SNMP drops the request and sends a system message.

Create the ACL with the following parameters:

- Source IP address

- Destination IP address

- Source port

- Destination port

- Protocol (UDP or TCP)

The ACL applies to both IPv4 and IPv6 over UDP and TCP. After creating the ACL, assign the ACL to the SNMP community.

Tip

For more information about creating ACLs, see the NX-OS security configuration guide for the Cisco Nexus Series software that you are using.

Use the following command in global configuration mode to assign an IPv4 or IPv6 ACL to an SNMPv3 community to filter SNMP requests:

Command

Purpose

switch(config)# snmp-server community name [use-ipv4acl ipv4acl-name] [use-ipv6acl ipv6acl-name]

switch(config)# snmp-server community public use-ipv4acl myacl

Assigns an IPv4 or IPv6 ACL to an SNMPv3 community to filter SNMP requests.

Configuring SNMP Notification Receivers

You can configure Cisco NX-OS to generate SNMP notifications to multiple host receivers.

You can configure a host receiver for SNMPv1 traps in a global configuration mode.

Command

Purpose

switch(config)# snmp-server host ip-address traps version 1 community [udp_port number]

Configures a host receiver for SNMPv1 traps. The ip-address can be an IPv4 or IPv6 address. The community can be any alphanumeric string up to 255 characters. The UDP port number range is from 0 to 65535.

You can configure a host receiver for SNMPv2c traps or informs in a global configuration mode.

Command

Purpose

switch(config)# snmp-server host ip-address {traps | informs} version 2c community [udp_port number]

Configures a host receiver for SNMPv2c traps or informs. The ip-address can be an IPv4 or IPv6 address. The community can be any alphanumeric string up to 255 characters. The UDP port number range is from 0 to 65535.

You can configure a host receiver for SNMPv3 traps or informs in a global configuration mode.

Command

Purpose

switch(config)# snmp-server host ip-address {traps | informs} version 3 {auth | noauth | priv} username [udp_port number]

Configures a host receiver for SNMPv2c traps or informs. The ip-address can be an IPv4 or IPv6 address. The username can be any alphanumeric string up to 255 characters. The UDP port number range is from 0 to 65535.

Note

The SNMP manager must know the user credentials (authKey/PrivKey) based on the SNMP engineID of the Cisco Nexus device to authenticate and decrypt the SNMPv3 messages.

The following example shows how to configure a host receiver for an SNMPv1 trap:

switch(config)# snmp-server host 192.0.2.1 traps version 1 public

The following example shows how to configure a host receiver for an SNMPv2 inform:

switch(config)# snmp-server host 192.0.2.1 informs version 2c public

The following example shows how to configure a host receiver for an SNMPv3 inform:

switch(config)# snmp-server host 192.0.2.1 informs version 3 auth NMS

Configuring SNMP Notification Receivers with VRFs

You can configure Cisco NX-OS to use a configured VRF to reach the host receiver. SNMP adds entries into the cExtSnmpTargetVrfTable of the CISCO-SNMP-TARGET-EXT-MIB when you configure the VRF reachability and filtering options for an SNMP notification receiver.

Note

You must configure the host before configuring the VRF reachability or filtering options.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch# snmp-server host ip-address use-vrf vrf_name [udp_port number]

Configures SNMP to use the selected VRF to communicate with the host receiver. The IP address can be an IPv4 or IPv6 address. The VRF name can be any alphanumeric string up to 255 characters. The UDP port number range is from 0 to 65535. This command adds an entry into thc ExtSnmpTargetVrfTable of the CISCO-SNMP-TARGET-EXT-MB.

Step 3

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure the SNMP server host with IP address 192.0.2.1 to use the VRF named "Blue:"

switch# configuration terminal
switch(config)# snmp-server host 192.0.2.1 use-vrf Blue
switch(config)# copy running-config startup-config

Filtering SNMP Notifications Based on a VRF

You can configure Cisco NX-OS filter notifications based on the VRF in which the notification occurred.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# snmp-server host ip-address filter-vrf vrf_name [udp_port number]

Filters notifications to the notification host receiver based on the configured VRF. The IP address can be an IPv4 or IPv6 address. The VRF name can be any alphanumeric string up to 255 characters. The UDP port number range is from 0 to 65535.

This command adds an entry into thc ExtSnmpTargetVrfTable of the CISCO-SNMP-TARGET-EXT-MB.

Step 3

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure filtering of SNMP notifications based on a VRF:

switch# configuration terminal
switch(config)# snmp-server host 192.0.2.1 filter-vrf Red
switch(config)# copy running-config startup-config

Configuring SNMP for Inband Access

You can configure SNMP for inband access using the following:

- Using SNMP v2 without context—You can use a community that is mapped to a context. In this case, the SNMP client does not need to know about the context.

- Using SNMP v2 with context—The SNMP client needs to specify the context by specifying a community; for example, <community>@<context>.

- Using SNMP v3—You can specify the context.

Procedure

Command or Action

Purpose

Step 1

switch# configuration terminal

Enters global configuration mode.

Step 2

switch(config)# snmp-server context context-name vrf vrf-name

Maps an SNMP context to the management VRF or default VRF. Custom VRFs are not supported. The names can be any alphanumeric string up to 32 characters.

Note:   By default, SNMP sends the traps using the management VRF. If you do not want to use the management VRF, you must use this command to specify the desired VRF.

Step 3

switch(config)# snmp-server community community-name group group-name

Maps an SNMPv2c community to an SNMP context and identifies the group to which the community belongs. The names can be any alphanumeric string up to 32 characters.

Step 4

switch(config)# snmp-server mib community-map community-name context context-name

Maps an SNMPv2c community to an SNMP context. The names can be any alphanumeric string up to 32 characters.

The following SNMPv2 example shows how to map a community named snmpdefault to a context:

switch# config t
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# snmp-server context def vrf default
switch(config)# snmp-server community snmpdefault group network-admin
switch(config)# snmp-server mib community-map snmpdefault context def
switch(config)#

The following SNMPv2 example shows how to configure and inband access to the community comm which is not mapped:

switch# config t
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# snmp-server context def vrf default
switch(config)# snmp-server community comm group network-admin
switch(config)#

The following SNMPv3 example shows how to use a v3 username and password:

switch# config t
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# snmp-server context def vrf default
switch(config)#

Enabling SNMP Notifications

You can enable or disable notifications. If you do not specify a notification name, Cisco NX-OS enables all notifications.

Note

The snmp-server enable traps CLI command enables both traps and informs, depending on the configured notification host receivers.

The following table lists the CLI commands that enable the notifications for Cisco NX-OS MIBs.

Enabling SNMP Notifications

MIB

Related Commands

All notifications

snmp-server enable traps

BRIDGE-MIB

snmp-server enable traps bridge newroot

snmp-server enable traps bridge topologychange

CISCO-AAA-SERVER-MIB

snmp-server enable traps aaa

ENITY-MIB, CISCO-ENTITY-FRU-CONTROL-MIB, CISCO-ENTITY-SENSOR-MIB

snmp-server enable traps entity

snmp-server enable traps entity fru

CISCO-LICENSE-MGR-MIB

snmp-server enable traps license

IF-MIB

snmp-server enable traps link

CISCO-PSM-MIB

snmp-server enable traps port-security

SNMPv2-MIB

snmp-server enable traps snmp

snmp-server enable traps snmp authentication

CISCO-FCC-MIB

snmp-server enable traps fcc

CISCO-DM-MIB

snmp-server enable traps fcdomain

CISCO-NS-MIB

snmp-server enable traps fcns

CISCO-FCS-MIB

snmp-server enable traps fcs discovery-complete

snmp-server enable traps fcs request-reject

CISCO-FDMI-MIB

snmp-server enable traps fdmi

CISCO-FSPF-MIB

snmp-server enable traps fspf

CISCO-PSM-MIB

snmp-server enable traps port-security

CISCO-RSCN-MIB

snmp-server enable traps rscn

snmp-server enable traps rscn els

snmp-server enable traps rscn ils

CISCO-ZS-MIB

snmp-server enable traps zone

snmp-server enable traps zone default-zone-behavior-change

snmp-server enable traps zone enhanced-zone-db-change

snmp-server enable traps zone merge-failure

snmp-server enable traps zone merge-success

snmp-server enable traps zone request-reject

snmp-server enable traps zone unsupp-mem

CISCO-CONFIG-MAN-MIB

Note:
Supports no MIB objects except the following notification: ccmCLIRunningConfigChanged

snmp-server enable traps config

Note

The license notifications are enabled by default.

To enable the specified notification in the global configuration mode, perform one of the following tasks:

Command

Purpose

switch(config)# snmp-server enable traps

Enables all SNMP notifications.

switch(config)# snmp-server enable traps aaa [server-state-change]

Enables the AAA SNMP notifications.

switch(config)# snmp-server enable traps entity [fru]

Enables the ENTITY-MIB SNMP notifications.

switch(config)# snmp-server enable traps license

Enables the license SNMP notification.

switch(config)# snmp-server enable traps port-security

Enables the port security SNMP notifications.

switch(config)# snmp-server enable traps snmp [authentication]

Enables the SNMP agent notifications.

Configuring Link Notifications

You can configure which linkUp/linkDown notifications to enable on a device. You can enable the following types of linkUp/linkDown notifications:

- cieLinkDown—Enables the Cisco extended link state down notification.

- cieLinkUp—Enables the Cisco extended link state up notification.

- cisco-xcvr-mon-status-chg—Enables the Cisco interface transceiver monitor status change notification.

- delayed-link-state-change—Enables the delayed link state change.

- extended-linkUp—Enables the Internet Engineering Task Force (IETF) extended link state up notification.

- extended-linkDown—Enables the IETF extended link state down notification.

- linkDown—Enables the IETF Link state down notification.

- linkUp—Enables the IETF Link state up notification.

Procedure

Command or Action

Purpose

Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

snmp-server enable traps link [cieLinkDown | cieLinkUp | cisco-xcvr-mon-status-chg | delayed-link-state-change] | extended-linkUp | extended-linkDown | linkDown | linkUp]

Example:

switch(config)# snmp-server enable traps link cieLinkDown

Enables the link SNMP notifications.

Disabling Link Notifications on an Interface

You can disable linkUp and linkDown notifications on an individual interface. You can use these limit notifications on a flapping interface (an interface that transitions between up and down repeatedly).

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# interface type slot/port

Specifies the interface to be changed.

Step 3

switch(config -if)# no snmp trap link-status

Disables SNMP link-state traps for the interface. This feature is enabled by default.

Enabling One-Time Authentication for SNMP over TCP

You can enable a one-time authentication for SNMP over a TCP session.

Command

Purpose

switch(config)# snmp-server tcp-session [auth]

Enables a one-time authentication for SNMP over a TCP session. This feature is disabled by default.

Assigning SNMP Switch Contact and Location Information

You can assign the switch contact information, which is limited to 32 characters (without spaces), and the switch location.

Procedure

Command or Action

Purpose

Step 1

switch# configuration terminal

Enters global configuration mode.

Step 2

switch(config)# snmp-server contact name

Configures sysContact, the SNMP contact name.

Step 3

switch(config)# snmp-server location name

Configures sysLocation, the SNMP location.

Step 4

switch# show snmp

(Optional)
Displays information about one or more destination profiles.

Step 5

switch# copy running-config startup-config

(Optional)
Saves this configuration change.

Configuring the Context to Network Entity Mapping

You can configure an SNMP context to map to a logical network entity, such as a protocol instance or VRF.

Procedure

Command or Action

Purpose

Step 1

switch# configuration terminal

Enters global configuration mode.

Step 2

switch(config)# snmp-server context context-name [instance instance-name] [vrf vrf-name] [topology topology-name]

Maps an SNMP context to a protocol instance, VRF, or topology. The names can be any alphanumeric string up to 32 characters.

Step 3

switch(config)# snmp-server mib community-map community-name context context-name

Maps an SNMPv2c community to an SNMP context. The names can be any alphanumeric string up to 32 characters.

Step 4

switch(config)# no snmp-server context context-name [instance instance-name] [vrf vrf-name] [topology topology-name]

(Optional)
Deletes the mapping between an SNMP context and a protocol instance, VRF, or topology. The names can be any alphanumeric string up to 32 characters.

Note:
Do not enter an instance, VRF, or topology to delete a context mapping. If you use the instance, vrf, or topology keywords, you configure a mapping between the context and a zero-length string.

Disabling SNMP

Procedure

Command or Action

Purpose

Step 1

configure terminal

Example:

switch# configure terminal
switch(config)#

Enters global configuration mode.

Step 2

switch(config) # no snmp-server protocol enable

Example:

no snmp-server protocol enable

Disables SNMP.

SNMP is disabled by default.

Verifying the SNMP Configuration

To display SNMP configuration information, perform one of the following tasks:

Command

Purpose

show snmp

Displays the SNMP status.

show snmp community

Displays the SNMP community strings.

show snmp engineID

Displays the SNMP engineID.

show snmp group

Displays SNMP roles.

show snmp sessions

Displays SNMP sessions.

show snmp trap

Displays the SNMP notifications enabled or disabled.

show snmp user

Displays SNMPv3 users.

Chapter 14. Configuring RMON

This chapter contains the following sections:

- Information About RMON

- Configuration Guidelines and Limitations for RMON

- Verifying the RMON Configuration

- Default RMON Settings

Information About RMON

RMON is an Internet Engineering Task Force (IETF) standard monitoring specification that allows various network agents and console systems to exchange network monitoring data. The Cisco NX-OS supports RMON alarms, events, and logs to monitor Cisco Nexus device.

An RMON alarm monitors a specific management information base (MIB) object for a specified interval, triggers an alarm at a specified threshold value (threshold), and resets the alarm at another threshold value. You can use alarms with RMON events to generate a log entry or an SNMP notification when the RMON alarm triggers.

RMON is disabled by default and no events or alarms are configured in Cisco Nexus devices. You can configure your RMON alarms and events by using the CLI or an SNMP-compatible network management station.

- RMON Alarms

- RMON Events

RMON Alarms

You can set an alarm on any MIB object that resolves into an SNMP INTEGER type. The specified object must be an existing SNMP MIB object in standard dot notation (for example, 1.3.6.1.2.1.2.2.1.17 represents ifOutOctets.17).

When you create an alarm, you specify the following parameters:

- MIB object to monitor

- Sampling interval—The interval that the Cisco Nexus device uses to collect a sample value of the MIB object.

- Sample type—Absolute samples take the current snapshot of the MIB object value. Delta samples take two consecutive samples and calculate the difference between them.

- Rising threshold—The value at which the Cisco Nexus device triggers a rising alarm or resets a falling alarm.

- Falling threshold—The value at which theCisco Nexus device triggers a falling alarm or resets a rising alarm.

- Events—The action that the Cisco Nexus device takes when an alarm (rising or falling) triggers.

Note

Use the hcalarms option to set an alarm on a 64-bit integer MIB object.

For example, you can set a delta type rising alarm on an error counter MIB object. If the error counter delta exceeds this value, you can trigger an event that sends an SNMP notification and logs the rising alarm event. This rising alarm does not occur again until the delta sample for the error counter drops below the falling threshold.

Note

The falling threshold must be less than the rising threshold.

RMON Events

You can associate a particular event to each RMON alarm. RMON supports the following event types:

- SNMP notification—Sends an SNMP risingAlarm or fallingAlarm notification when the associated alarm triggers.

- Log—Adds an entry in the RMON log table when the associated alarm triggers.

- Both—Sends an SNMP notification and adds an entry in the RMON log table when the associated alarm triggers.

You can specify a different even for a falling alarm and a rising alarm.

Configuration Guidelines and Limitations for RMON

RMON has the following configuration guidelines and limitations:

- You must configure an SNMP user and a notification receiver to use the SNMP notification event type.

- You can only configure an RMON alarm on a MIB object that resolves to an integer.

Configuring RMON Alarms

You can configure RMON alarms on any integer-based SNMP MIB object.

You can optionally specify the following parameters:

- The eventnumber to trigger if the rising or falling threshold exceeds the specified limit.

- The owner of the alarm.

Ensure you have configured an SNMP user and enabled SNMP notifications.

Before You Begin

Ensure you have configured an SNMP user and enabled SNMP notifications.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# rmon alarm index mib-object sample-interval {absolute | delta} rising-threshold value [event-index] falling-threshold value [event-index] [owner name]

Creates an RMON alarm. The value range is from –2147483647 to 2147483647. The owner name can be any alphanumeric string.

Step 3

switch(config)# rmon hcalarm index mib-object sample-interval {absolute | delta} rising-threshold-high value rising-threshold-low value [event-index] falling-threshold-high value falling-threshold-low value [event-index] [owner name] [storagetype type]

Creates an RMON high-capacity alarm. The value range is from –2147483647 to 2147483647. The owner name can be any alphanumeric string.

The storage type range is from 1 to 5.

Step 4

switch# show rmon {alarms | hcalarms}

(Optional)
Displays information about RMON alarms or high-capacity alarms.

Step 5

switch# copy running-config startup-config

(Optional)
Saves this configuration change.

The following example shows how to configure RMON alarms:

switch# configure terminal

switch(config)# rmon alarm 1 1.3.6.1.2.1.2.2.1.17.83886080 5 delta rising-threshold 5 1 falling-threshold 0 owner test

switch(config)# exit

switch# show rmon alarms

Alarm 1 is active, owned by test

Monitors 1.3.6.1.2.1.2.2.1.17.83886080 every 5 second(s)

Taking delta samples, last value was 0

Rising threshold is 5, assigned to event 1

Falling threshold is 0, assigned to event 0

On startup enable rising or falling alarm

Configuring RMON Events

You can configure RMON events to associate with RMON alarms. You can reuse the same event with multiple RMON alarms.

Ensure you have configured an SNMP user and enabled SNMP notifications.

Before You Begin

Ensure that you have configured an SNMP user and enabled SNMP notifications.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# rmon event index [description string] [log] [trap] [owner name]

Configures an RMON event. The description string and owner name can be any alphanumeric string.

Step 3

switch(config)# show rmon {alarms | hcalarms}

(Optional)
Displays information about RMON alarms or high-capacity alarms.

Step 4

switch# copy running-config startup-config

(Optional)
Saves this configuration change.

Verifying the RMON Configuration

Use the following commands to verify the RMON configuration information:

Command

Purpose

show rmon alarms

Displays information about RMON alarms.

show rmon events

Displays information about RMON events.

show rmon hcalarms

Displays information about RMON hcalarms.

show rmon logs

Displays information about RMON logs.

Default RMON Settings

The following table lists the default settings for RMON parameters.

Default RMON Parameters

Parameters

Default

Alarms

None configured.

Events

None configured.

Chapter 15. Configuring SPAN

This chapter contains the following sections:

- Information About SPAN

- SPAN Sources

- Characteristics of Source Ports

- SPAN Destinations

- Characteristics of Destination Ports

- SPAN and ERSPAN Filtering

- SPAN and ERSPAN Sampling

- SPAN and ERSPAN Truncation

- Creating or Deleting a SPAN Session

- Configuring an Ethernet Destination Port

- Configuring Source Ports

- Configuring Source Port Channels or VLANs

- Configuring the Description of a SPAN Session

- Activating a SPAN Session

- Suspending a SPAN Session

- Configuring a SPAN Filter

- Configuring SPAN Sampling

- Configuring SPAN Truncation

- Displaying SPAN Information

Information About SPAN

The Switched Port Analyzer (SPAN) feature (sometimes called port mirroring or port monitoring) selects network traffic for analysis by a network analyzer. The network analyzer can be a Cisco SwitchProbe or other Remote Monitoring (RMON) probes.

SPAN Sources

SPAN sources refer to the interfaces from which traffic can be monitored. The Cisco Nexus device supports Ethernet, port channels, and VLANs as SPAN sources. With VLANs, all supported interfaces in the specified VLAN are included as SPAN sources. You can choose the SPAN traffic in the ingress direction, the egress direction, or both directions for Ethernet source interfaces:

- Ingress source (Rx)—Traffic entering the device through this source port is copied to the SPAN destination port.

- Egress source (Tx)—Traffic exiting the device through this source port is copied to the SPAN destination port.

Characteristics of Source Ports

A source port, also called a monitored port, is a switched interface that you monitor for network traffic analysis. The switch supports any number of ingress source ports (up to the maximum number of available ports on the switch) and any number of source VLANs.

A source port has these characteristics:

- Can be of Ethernet, port channel, or VLAN port type.

- Cannot be a destination port.

- Can be configured with a direction (ingress, egress, or both) to monitor. For VLAN sources, the monitored direction can only be ingress and applies to all physical ports in the group. The RX/TX option is not available for VLAN SPAN sessions.

- Can be in the same or different VLANs.

Note

- If some of the FEX ports are being used by a SPAN session as source ports, the remaining FEX ports cannot be a part of a different SPAN session.

- The maximum number of source ports per SPAN session is 128 ports.

- The maximum number of SPAN sessions supported on the Nexus 5000 Series and Nexus 5500 Series switches is 4.

- The maximum number of SPAN sessions supported on the Nexus 5600 Series and Nexus 6000 Series switches is 16.

SPAN Destinations

SPAN destinations refer to the interfaces that monitors source ports. The Cisco Nexus Series device supports Ethernet interfaces as SPAN destinations.

Characteristics of Destination Ports

Each local SPAN session must have a destination port (also called a monitoring port) that receives a copy of traffic from the source ports or VLANs. A destination port has these characteristics:

- Can be any physical port. Source Ethernet and FCoE ports cannot be destination ports.

- Cannot be a source port.

- Cannot be a port channel.

- Does not participate in spanning tree while the SPAN session is active.

- Is excluded from the source list and is not monitored if it belongs to a source VLAN of any SPAN session.

- Receives copies of sent and received traffic for all monitored source ports.

- The FEX interface cannot be a span destination.

- The same destination interface cannot be used for multiple SPAN sessions. However, an interface can act as a destination for a SPAN and an ERSPAN session.

SPAN and ERSPAN Filtering

A SPAN or ERSPAN session can be used to monitor all the traffic on all the source interfaces. This volume of traffic can cause packet drops if there are congestions or if the destination bandwidth is not enough to monitor all the traffic.

Cisco NX-OS Release 6.0(2)A4(1) provides the ability to filter out specific SPAN or ERSPAN traffic flows that must be monitored. Filtering is achieved by creating a filter and attaching it to a SPAN or ERSPAN session. Only the packets that match the filter are mirrored.

Filtering can be of the following types:

- MAC-based

- IP-based

- VLAN-based

- Guidelines and Limitations for SPAN and ERSPAN Filtering

Guidelines and Limitations for SPAN and ERSPAN Filtering

SPAN and ERSPAN filtering have the following guidelines and limitations:

- Cisco Nexus 3500 Series switches drop the SPAN copies while spanning an interface in the rx direction and another interface in the tx direction when the traffic starts. It happens due to the default SPAN threshold limit being low and it cannot handle the burst traffic for SPAN. Use the CLI command hardware profile buffer span-threshold <xx> to increase the SPAN threshold.

Note

Increasing the SPAN threshold affects the shared buffer allocation. It allocates the SPAN buffers from the shared buffer pool.

- The span-threshold least value has been updated from 0 to 2. When you set the span-threshold to a lowest value of 2, the SPAN buffer occupied is 528. When you use the negate command no hardware profile buffer span-threshold 2, the span-threshold value is 208. The default value is lesser then the least value of span-threshold.

- When a source interface in a SPAN session is operationally down, then that SPAN session will not go operationally down. This behavior does not impact any functionality.

- SPAN filtering supports only 16 filters. These filters can be a combination of VLAN-based, IP-based, and MAC-based filters.

- When a SPAN session is configured with a multicast router port being the source port, the destination port sees all the multicast traffic even when there is no traffic that is actually being forwarded to the source port. This is due to a current limitation of the multicast/SPAN implementation.

- SPAN filtering is applicable for all the traffic of the switch except the SPAN source interface traffic.

- You can configure only one IP-based, one MAC-based and one VLAN-based filter per SPAN session.

- The number of filters is further restricted by the number of SPAN sessions and the type of source as follows:

- A maximum of 8 MAC-based, 8 IP-based or 8 VLAN-based filters can be configured.

- A maximum of 4 IP-based, 4 MAC-based or 4 VLAN-based filters can be attached to all interface-based SPAN sessions.

- A maximum of 8 IP-based, 8 MAC-based or 8 VLAN-based filters can be attached to all VLAN-based SPAN sessions.

- Filters can be used only in the ingress direction. This is not configurable.

- A SPAN session must be up to for filters to work.

- You cannot configure filters on ERSPAN-dst sessions.

- You cannot configure filters on Warp SPAN sessions.

SPAN and ERSPAN Sampling

Cisco NX-OS Release 6.0(2)A4(1) supports sampling of source packets for each SPAN or ERSPAN session. Monitoring only a sample number of source packets helps reduce SPAN or ERSPAN bandwidth. This sample is defined by a range that you can configure. For example, if you configure the range as 2, 1 out of every 2 source packets will be spanned. Similarly, if you configure the range as 1023, 1 out of every 1023 packets will be spanned. This method provides an accurate count of SPAN or ERSPAN source packets, but it does not include any time-related information about the spanned packets.

By default, SPAN and ERSPAN sampling are disabled. To use sampling, you must enable it for each SPAN or ERSPAN session.

- Guidelines and Limitations for SPAN and ERSPAN Sampling

Guidelines and Limitations for SPAN and ERSPAN Sampling

SPAN and ERSPAN sampling have the following guidelines and limitations:

- Sampling is only supported for local and ERSPAN-src sessions.

- Sampling is not supported for ERSPAN-dst sessions.

- Sampling is not supported for Warp SPAN sessions.

- The supported sampling range is from 2 to 1023.

SPAN and ERSPAN Truncation

Cisco NX-OS Release 6.0(2)A4(1) introduces truncation of source packets for each SPAN or ERSPAN session based on the size of their MTU. Truncation helps reduce SPAN or ERSPAN bandwidth by reducing the size of packets monitored. MTU truncation can be set from 64 bytes to 1518 bytes. Any SPAN or ERSPAN packet that is larger than the configured MTU size is truncated to the given size with a 4-byte offset. For example, if you configure the MTU as 300 bytes, the maximum size of the replicated packet is 304 bytes.

By default, SPAN and ERSPAN truncation are disabled. To use truncation, you must enable it for each SPAN or ERSPAN session.

- Guidelines and Limitations for SPAN and ERSPAN Truncation

Guidelines and Limitations for SPAN and ERSPAN Truncation

SPAN and ERSPAN truncation have the following guidelines and limitations:

- Truncation is only supported for local and ERSPAN-src sessions.

- Truncation is not supported for ERSPAN-dst sessions.

- Truncation is not supported for Warp SPAN sessions.

- The supported MTU range is from 64 bytes to 1518 bytes.

Creating or Deleting a SPAN Session

You create a SPAN session by assigning a session number using the monitor session command. If the session already exists, any additional configuration information is added to the existing session.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session session-number

Enters the monitor configuration mode. New session configuration is added to the existing session configuration.

The following example shows how to configure a SPAN monitor session:

switch# configure terminal
switch(config) # monitor session 2
switch(config) #

Configuring an Ethernet Destination Port

You can configure an Ethernet interface as a SPAN destination port.

Note

The SPAN destination port can only be a physical port on the switch.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# interface ethernet slot/port

Enters interface configuration mode for the Ethernet interface with the specified slot and port.

Note:   To enable the switchport monitor command on virtual ethernet ports, you can use the interface vethernet slot/port command.

Step 3

switch(config-if)# switchport monitor

Enters monitor mode for the specified Ethernet interface. Priority flow control is disabled when the port is configured as a SPAN destination.

Step 4

switch(config-if)# exit

Reverts to global configuration mode.

Step 5

switch(config)# monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 6

switch(config-monitor)# destination interface ethernet slot/port

Configures the Ethernet SPAN destination port.

Note:   To enable the virtual ethernet port as destination interface in the monitor configuration, you can use the destination interface vethernet slot/port command.

The following example shows how to configure an Ethernet SPAN destination port (HIF):

switch# configure terminal
switch(config)# interface ethernet100/1/24
switch(config-if)# switchport monitor
switch(config-if)# exit
switch(config)# monitor session 1
switch(config-monitor)# destination interface ethernet100/1/24
switch(config-monitor)#

The following example shows how to configure a virtual ethernet (VETH) SPAN destination port:

switch# configure terminal
switch(config)# interface vethernet10
switch(config-if)# switchport monitor
switch(config-if)# exit
switch(config)# monitor session 2
switch(config-monitor)# destination interface vethernet10
switch(config-monitor)#

Configuring Source Ports

Source ports can only be Ethernet ports.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # monitor session session-number

Enters monitor configuration mode for the specified monitoring session.

Step 3

switch(config-monitor) # source interface type slot/port [rx | tx | both]

Adds an Ethernet SPAN source port and specifies the traffic direction in which to duplicate packets. You can enter a range of Ethernet, Fibre Channel, or virtual Fibre Channel ports. You can specify the traffic direction to duplicate as ingress (Rx), egress (Tx), or both. By default, the direction is both.

The following example shows how to configure an Ethernet SPAN source port:

switch# configure terminal
switch(config)# monitor session 2
switch(config-monitor)# source interface ethernet 1/16
switch(config-monitor)#

Configuring Source Port Channels or VLANs

You can configure the source channels for a SPAN session. These ports can be port channels and VLANs. The monitored direction can be ingress, egress, or both and applies to all physical ports in the group.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 3

switch(config-monitor) # source {interface {port-channel} channel-number [rx | tx | both] | vlan vlan-range}

Configures port channel or VLAN sources. For VLAN sources, the monitored direction is implicit.

The following example shows how to configure a port channel SPAN source:

switch# configure terminal
switch(config)# monitor session 2
switch(config-monitor)# source interface port-channel 1 rx
switch(config-monitor)# source interface port-channel 3 tx
switch(config-monitor)# source interface port-channel 5 both
switch(config-monitor)#

The following example shows how to configure a VLAN SPAN source:

switch# configure terminal
switch(config)# monitor session 2
switch(config-monitor)# source vlan 1
switch(config-monitor)#

Configuring the Description of a SPAN Session

For ease of reference, you can provide a descriptive name for a SPAN session.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 3

switch(config-monitor) # description description

Creates a descriptive name for the SPAN session.

The following example shows how to configure a SPAN session description:

switch# configure terminal
switch(config) # monitor session 2
switch(config-monitor) # description monitoring ports eth2/2-eth2/4
switch(config-monitor) #

Activating a SPAN Session

The default is to keep the session state shut. You can open a session that duplicates packets from sources to destinations.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # no monitor session {all | session-number} shut

Opens the specified SPAN session or all sessions.

The following example shows how to activate a SPAN session:

switch# configure terminal
switch(config) # no monitor session 3 shut

Suspending a SPAN Session

By default, the session state is shut.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config) # monitor session {all | session-number} shut

Suspends the specified SPAN session or all sessions.

The following example shows how to suspend a SPAN session:

switch# configure terminal
switch(config) # monitor session 3 shut
switch(config) #

Configuring a SPAN Filter

You can configure SPAN filters for local and ERSPAN-source sessions only.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 3

switch(config-monitor)# source {interface {port-channel} channel-number [rx | tx | both] | vlan vlan-range}

Configures port channel or VLAN sources. For VLAN sources, the monitored direction is implicit.

Step 4

switch(config-monitor)# filter {ip source-ip-address source-ip-mask destination-ip-address destination-ip-mask}

Creates a SPAN filter.

Step 5

switch(config-monitor)# destination interface ethernet slot/port

Configures the Ethernet SPAN destination port.

The following example shows how to configure an IP-based SPAN filter for a local session:

switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# monitor session 1
switch(config-monitor)# source interface Ethernet 1/7 rx
switch(config-monitor)# filter ip 10.1.1.1 255.255.255.255 20.1.1.1 255.255.255.255
switch(config-monitor)# destination interface Ethernet 1/48
switch(config-monitor)# no shut
switch(config-monitor)#

The following example shows how to configure a VLAN-based SPAN filter for a local session:

switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# monitor session 3
switch(config-monitor)# source vlan 200
switch(config-monitor)# destination interface Ethernet 1/4
switch(config-monitor)# no shut
switch(config-monitor)#

Configuring SPAN Sampling

You can configure sampling for local and ERSPAN-source sessions only.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 3

switch(config-monitor)# source {interface {port-channel} channel-number [rx | tx | both] | vlan vlan-range}

Configures port channel or VLAN sources. For VLAN sources, the monitored direction is implicit.

Step 4

switch(config-monitor)# sampling sampling-range

Configures a range for spanning packets. If the range is defined as n, every nth packet will be spanned.

The sampling range is between 2 and 1023.

Step 5

switch(config-monitor)# destination interface ethernet slot/port

Configures the Ethernet SPAN destination port.

The following example shows how to configure sampling on a VLAN for a local session:

switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# monitor session 1
switch(config-monitor)# source vlan 100
switch(config-monitor)# sampling 10
switch(config-monitor)# destination interface ethernet 1/48
switch(config-monitor)# no shut
switch(config-monitor)# show monitor session 1
session 1
---------------
type              : local
state             : up
sampling          : 10
source intf       :
rx            : Eth1/3        Eth1/7
tx            :
both          :
source VLANs      :
rx            : 100
destination ports : Eth1/48

Legend: f = forwarding enabled, l = learning enabled

The following example shows how to configure sampling on an Ethernet interface for a local session:

switch# configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
switch(config)# monitor session 3
switch(config-monitor)# source interface ethernet 1/8
switch(config-monitor)# sampling 20
switch(config-monitor)# destination interface ethernet 1/4
switch(config-monitor)# show monitor session 3
session 3
---------------
type              : local
state             : down (No operational src/dst)
sampling          : 20
source intf       :
rx            : Eth1/8
tx            : Eth1/8
both          : Eth1/8
source VLANs      :
rx            : 200
destination ports : Eth1/4

Legend: f = forwarding enabled, l = learning enabled

Configuring SPAN Truncation

You can configure truncation for local and ERSPAN-source sessions only.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session session-number

Enters monitor configuration mode for the specified SPAN session.

Step 3

switch(config-monitor) # source {interface {port-channel} channel-number [rx | tx | both] | vlan vlan-range}

Configures port channel or VLAN sources. For VLAN sources, the monitored direction is implicit.

Step 4

switch(config-monitor) # mtu size

Configures the MTU size for truncation. Any SPAN packet that is larger than the configured MTU size is truncated to the configured size with a 4-byte offset.

The MTU truncation size is between 64 bytes and 1518 bytes.

Step 5

switch(config-monitor)# destination interface ethernet slot/port

Configures the Ethernet SPAN destination port.

The following example shows how to configure MTU truncation for a local session:

switch# configure terminal
switch(config)# monitor session 5
switch(config-monitor)# source interface ethernet 1/5 both
switch(config-monitor)# mtu 512
switch(config-monitor)# destination interface Ethernet 1/39
switch(config-monitor)# no shut
switch(config-monitor)# show monitor session 5
session 5
---------------
type              : local
state             : down (No operational src/dst)
mtu               : 512
source intf       :
rx            : Eth1/5
tx            : Eth1/5
both          : Eth1/5
source VLANs      :
rx            :
destination ports : Eth1/39

Legend: f = forwarding enabled, l = learning enabled

Displaying SPAN Information

Procedure

Command or Action

Purpose

Step 1

switch# show monitor [session {all | session-number | range session-range} [brief]]

Displays the SPAN configuration.

The following example shows how to display SPAN session information:

switch# show monitor
SESSION  STATE        REASON                  DESCRIPTION
-------  -----------  ----------------------  --------------------------------
2        up           The session is up
3        down         Session suspended
4        down         No hardware resource

The following example shows how to display SPAN session details:

switch# show monitor session 2
session 2
---------------
type              : local
state             : up

source intf       :

source VLANs      :
rx            :

destination ports : Eth3/1

Chapter 16. Configuring Warp SPAN

This chapter contains the following sections:

- Information About Warp SPAN

- Guidelines and Limitations for Warp Span

- Configuring Warp SPAN

- Verifying Warp SPAN Mode Configuration

- Feature History for Warp SPAN

Information About Warp SPAN

Warp SPAN is AlgoBoost feature that spans the traffic coming into a dedicated port to a group of ports at very low latency. In Warp SPAN, traffic arriving at one dedicated ingress port is replicated to a user configurable group of egress ports. The packet replication happens without any filters or lookup mechanisms. Unlike normal or Warp mode traffic forwarding, the incoming traffic is replicated before any traffic classification or ACL processing occurs. Because traffic bypasses these processes, the latency for the replicated packets is as low as 50ns. The Warp SPAN functions independently and simultaneously to normal traffic forwarding. For example, the incoming source traffic can be switched, routed, multicast replicated, and so on, while at the same time this incoming traffic is warp spanned to multiple destination ports.

The original traffic ingressing the dedicated source port is forwarded normally with nominal switch latency, along with the Warp SPAN traffic at about 50ns to the configured destination ports. Warp SPAN can be enabled both in normal traffic forwarding mode and Warp mode.

The source can be monitored only in the ingress direction and is not configurable. The source port is configured automatically as soon as you configure the Warp SPAN session.

You configure the dedicated source Layer 2/Layer 3 port (must be Ethernet port 1/36) with standard configuration as required by the network.

You configure destination ports similar to any regular SPAN destination port. The destination ports cannot be used as regular Layer 2/Layer 3 ports. Destination ports must be configured in groups of four, so you can create a maximum of 12 groups with a total of 47 destination ports (one port—port 1/36—is the fixed source port). See the following table.

Warp SPAN Groups

Group

Destination Ports

1

1-4

2

5-8

3

9-12

4

13-16

5

17-20

6

21-24

7

25-28

8

29-32

9

33-35

[1]

10

37-40

11

41-44

12

45-48

[1]
Port 36 is the dedicated source port.

Guidelines and Limitations for Warp Span

Warp SPAN has the following configuration guidelines and limitations:

- Source and destination Warp SPAN ports must all be 10G.

- The source port is not configurable and is fixed as Ethernet port 1/36.

- You can create a maximum of 12 groups with a total of 47 destination ports. All of the groups have four ports, except for group 9, which has only three ports and excludes port 1/36 (the fixed source port).

- All four ports in a group must be configured with the switchport monitor command before they can be grouped in a SPAN destination group.

- Warp SPAN does not allow the destination group to be configured unless all of the ports are administratively up. After the group has been configured, you can bring up or down any of the ports in the SPAN destination group. If you copy a working warp configuration that has one or more ports in the administratively down state and paste that configuration back in the configuration file of the same switch, Warp SPAN logs the following error:

ERROR: Cannot configure group with member interfaces in admin DOWN state

Configuring Warp SPAN

You configure Warp SPAN by enabling it and then configuring its destination groups.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config-monitor)# interface ethernet port/slot

Enters interface configuration mode for the specified interface.

Note:   You can specify a range to configure multiple interfaces at once.

Step 3

switch(config-if)# switchport monitor

Sets the interface to monitor mode. Priority flow control (PFC) is disabled when the port is configured as a SPAN destination.

Step 4

switch(config-if)# no shutdown

Brings the interface administratively up.

Step 5

switch(config)# monitor session warp

Enables Warp SPAN on the interface.

Step 6

switch(config)# no shutdown

Brings the interface administratively up.

Step 7

switch(conifig-monitor)# destination group group-number

Configures the destination group.
Note:
You can create a maximum of 12 groups with a total of 47 destination ports. All of the groups have four ports, except for group 9, which has only three ports and excludes port 1/36 (the fixed source port).

Step 8

switch(config-if)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

The following example shows how to configure destination SPAN ports 1/1-4 for Warp SPAN:

switch# configure terminal
switch(config-monitor)# interface ethernet 1/1-4
switch(config-if-range)# switchport monitor
switch(config-if-range)# no shutdown
switch(config)# monitor session warp
switch(config)# no shutdown
switch(config-monitor)# destination group 1
switch(config-if-range)# copy running-config startup-config

Verifying Warp SPAN Mode Configuration

You can verify the Warp SPAN mode configuration.

Procedure

Command or Action

Purpose

Step 1

switch(config)# show monitor session {number | all | range}

Displays information about a specific SPAN session, all SPAN sessions, or a range of SPAN sessions.

Step 2

switch(config)# show monitor session warp

Displays information about only the Warp SPAN sessions.

This example shows how to display information about all SPAN sessions and only the Warp SPAN sessions:

switch(config)# show monitor session all
session warp
---------------
type : local
state : up
source intf :
rx : Eth1/36
tx :
both :
source VLANs :
rx :
destination ports : Eth1/1 Eth1/2 Eth1/3 Eth1/4

Legend: f = forwarding enabled, l = learning enabled

switch(config)# show monitor session warp
session warp
---------------
type : local
state : up
source intf :
rx : Eth1/36
tx :
both :
source VLANs :
rx :
destination ports : Eth1/1 Eth1/2 Eth1/3 Eth1/4

Legend: f = forwarding enabled, l = learning enabled

Feature History for Warp SPAN

Feature Name

Release

Feature Information

Warp SPAN

5.0(3)A1(2)

This feature was introduced.

Chapter 17. Configuring ERSPAN

This chapter contains the following sections:

- Information About ERSPAN

- Licensing Requirements for ERSPAN

- Prerequisites for ERSPAN

- Guidelines and Limitations for ERSPAN

- Default Settings for ERSPAN

Information About ERSPAN

The Cisco NX-OS system supports the Encapsulated Remote Switching Port Analyzer (ERSPAN) feature on both source and destination ports. ERSPAN transports mirrored traffic over an IP network. The traffic is encapsulated at the source router and is transferred across the network. The packet is decapsulated at the destination router and then sent to the destination interface.

ERSPAN consists of an ERSPAN source session, routable ERSPAN generic routing encapsulation (GRE)-encapsulated traffic, and an ERSPAN destination session. You can separately configure ERSPAN source sessions and destination sessions on different switches.

- ERSPAN Types

- ERSPAN Sources

- ERSPAN Destinations

- ERSPAN Sessions

- Multiple ERSPAN Sessions

- ERSPAN Marker Packet

- High Availability

ERSPAN Types

ERSPAN Type III supports all of the ERSPAN Type II features and functionality and adds these enhancements:

- Provides timestamp information in the ERSPAN Type III header that can be used to calculate packet latency among edge, aggregate, and core switches.

- Identifies possible traffic sources using the ERSPAN Type III header fields.

ERSPAN Sources

The interfaces from which traffic can be monitored are called ERSPAN sources. Sources designate the traffic to monitor and whether to copy ingress, egress, or both directions of traffic. ERSPAN sources include the following:

- Ethernet ports and port channels.

- VLANs—When a VLAN is specified as an ERSPAN source, all supported interfaces in the VLAN are ERSPAN sources.

ERSPAN source ports have the following characteristics:

- A port configured as a source port cannot also be configured as a destination port.

- ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.

ERSPAN Destinations

ERSPAN destination sessions capture packets sent by ERSPAN source sessions on Ethernet ports or port channels and send them to the destination port. Destination ports receive the copied traffic from ERSPAN sources.

ERSPAN destination sessions are identified by the configured source IP address and ERSPAN ID. This allows multiple source sessions to send ERSPAN traffic to the same destination IP and ERSPAN ID and allows you to have multiple sources terminating at a single destination simultaneously.

ERSPAN destination ports have the following characteristics:

- A port configured as a destination port cannot also be configured as a source port.

- Destination ports do not participate in any spanning tree instance or any Layer 3 protocols.

- Ingress and ingress learning options are not supported on monitor destination ports.

- Host Interface (HIF) port channels and fabric port channel ports are not supported as SPAN destination ports.

ERSPAN Sessions

You can create ERSPAN sessions that designate sources and destinations to monitor.

When configuring ERSPAN source sessions, you must configure the destination IP address. When configuring ERSPAN destination sessions, you must configure the source IP address. See ERSPAN Sources for the properties of source sessions and ERSPAN Destinations for the properties of destination sessions.

Note

Only eight unidirectional, or four bidirectional ERSPAN or SPAN source sessions can run simultaneously across all switches. Only 20 ERSPAN destination sessions can run simultaneously across all switches.

The following figure shows an ERSPAN configuration.

ERSPAN Configuration

Multiple ERSPAN Sessions

You can define up to eight unidirectional ERSPAN source or SPAN sessions, or four bidirectional ERSPAN source or SPAN sessions at one time. You can shut down any unused ERSPAN sessions.

For information about shutting down ERSPAN sessions, see Shutting Down or Activating an ERSPAN Session.

ERSPAN Marker Packet

The type III ERSPAN header carries a hardware generated 32-bit timestamp. This timestamp field wraps periodically. When the switch is set to 1 ns granularity, this field wraps every 4.29 seconds. Such a wrap time makes it difficult to interpret the real value of the timestamp.

To recover the real value of the ERSPAN timestamp, Cisco NX-OS Release 6.0(2)A4(1) introduces a periodical marker packet to carry the original UTC timestamp information and provide a reference for the ERSPAN timestamp. The marker packet is sent out in 1-second intervals. Therefore, the destination site can detect the 32-bit wrap by checking the difference between the timestamp of the reference packet and the packet order.

High Availability

The ERSPAN feature supports stateless and stateful restarts. After a reboot or supervisor switchover, the running configuration is applied.

Licensing Requirements for ERSPAN

The following table shows the licensing requirements for this feature:

Product

License Requirement

Cisco NX-OS

ERSPAN requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS system images and is provided at no extra charge to you. For a complete explanation of the Cisco NX-OS licensing scheme, see the License and Copyright Information for Cisco NX-OS Software available at the following URL: Click Here .

Prerequisites for ERSPAN

ERSPAN has the following prerequisite:

•You must first configure the Ethernet interfaces for ports on each device to support the desired ERSPAN configuration. For more information, see the Interfaces configuration guide for your platform.

Guidelines and Limitations for ERSPAN

ERSPAN has the following configuration guidelines and limitations:

- ERSPAN supports the following:

- ERSPAN source session type (Packets are encapsulated as GRE-tunnel packets and sent on the IP network.)

- ERSPAN destination session type (Support for decapsulating the ERSPAN packet is available. The encapsulated packet is decapsulated at the destination box and the plain decapsulated packet is spanned to a front panel port at the ERSPAN terminating point.)

- ERSPAN source sessions are shared with local SPAN sessions. You can configure a maximum of eight ERSPAN source or SPAN source sessions in a single direction; If both receive and transmit sources are configured in the same session, it counts as two sessions and you can configure four such bidirectional sessions at one time.

- If you install NX-OS 5.0(3)U2(2), configure ERSPAN, and then downgrade to a lower version of software, the ERSPAN configuration is lost. This situation occurs because ERSPAN is not supported in versions before NX-OS 5.0(3)U2(2).

For information about a similar SPAN limitation, see Guidelines and Limitations for SPAN.

- ERSPAN is not supported for packets generated by the supervisor.

- ERSPAN sessions are terminated identically at the destination router.

- ERSPAN is not supported for management ports.

- A destination port can be configured in only one ERSPAN session at a time.

- You cannot configure a port as both a source and destination port.

- A single ERSPAN session can include mixed sources in any combination of the following:

- Ethernet ports or port channels but not subinterfaces.

- VLANs or port channels, which can be assigned to port channel subinterfaces.

- The port channels to the control plane CPU.

Note

ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.

- Destination ports do not participate in any spanning tree instance or Layer 3 protocols.

- When an ERSPAN session contains source ports that are monitored in the transmit or transmit and receive direction, packets that these ports receive may be replicated to the ERSPAN destination port even though the packets are not actually transmitted on the source ports. Some examples of this behavior on source ports include:

- Traffic that results from flooding

- Broadcast and multicast traffic

- When Nexus 3548 is the ERSPAN destination, GRE headers are stripped off before sending mirrored packets out of the terminating point.

- ERSPAN does not support 1588 granularity mode, and rejects this mode if selected.

- ERSPAN supports 100 microseconds (ms), 100 nanoseconds (ns), and ns granularity.

- ERSPAN sends all timestamps in 32-bit format. Therefore, the timestamp field will wrap periodically. When the switch is set to ns granularity, this field will wrap every 4.29 seconds.

- A Layer 3 subinterface cannot be configured as an ERSPAN source interface.

- All ERSPAN sources terminating in a single destination box must use the same destination IP address.

- You cannot configure different source IP addresses in different ERSPAN destination sessions.

- Layer 3 switched traffic from VLAN X to VLAN Y, which is spanned through the ERSPAN source in either the Rx or Tx direction, will carry VLAN information in the ERSPAN header of VLAN X (the VLAN before Layer 3 switching or ingress VLAN).

- Traffic coming in on an access port or a Layer 3 interface, which is part of an ERSPAN source session, will not have VLAN information in the ERSPAN header (VLAN ID 0). This could result in incompatibility issues with Catalyst 6000, which expects a non-zero VLAN ID.

- Multicast flood packets that do not go out of the ERSPAN source interface, which is configured for the egress (Tx) direction, can still reach the ERSPAN destination. This is because egress spanned packets are spanned before the original egress port is selectively enabled to receive specific frames and drop others, whereas the span for the Nexus 3548 switch application-specific integrated circuit (ASIC) is based on the monitor port's property. As a result, the spanned packet is still sent to the remote destination. This is expected behavior from platforms specific to multicast flood and is not seen for other traffic streams.

- Replicated multicast packets sent out of the ERSPAN source in the Tx direction are not sent to the ERSPAN destination.

Default Settings for ERSPAN

The following table lists the default settings for ERSPAN parameters.

Default ERSPAN Parameters

Parameters

Default

ERSPAN sessions

Created in the shut state.

Configuring an ERSPAN Source Session

You can configure an ERSPAN session on the local device only. By default, ERSPAN sessions are created in the shut state.

For sources, you can specify Ethernet ports, port channels, and VLANs. A single ERSPAN session can include mixed sources in any combination of Ethernet ports or VLANs.

Note

ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.

Procedure

Command or Action

Purpose

Step 1

configure terminal

Example:

switch# config t
switch(config)#

Enters global configuration mode.

Step 2

monitor erspan origin ip-address ip-address global

Example:

switch(config)# monitor erspan origin
ip-address 10.0.0.1 global

Configures the ERSPAN global origin IP address.

Step 3

no monitor session {session-number | all}

Example:

switch(config)# no monitor session 3

Clears the configuration of the specified ERSPAN session. The new session configuration is added to the existing session configuration.

Step 4

monitor session {session-number | all} type erspan-source

Example:

switch(config)# monitor session 3 type erspan-source
switch(config-erspan-src)#

Configures an ERSPAN source session.

Step 5

description description

Example:

switch(config-erspan-src)# description erspan_src_session_3

Configures a description for the session. By default, no description is defined. The description can be up to 32 alphanumeric characters.

Step 6

source {[interface[type slot/port[-port][, type slot/port[-port]]] [port-channel channel-number]] | [vlan {number | range}]} [rx | tx | both]

Example:

switch(config-erspan-src)# source interface ethernet 2/1-3, ethernet 3/1 rx

Example:

switch(config-erspan-src)# source interface port-channel 2

Example:

switch(config-erspan-src)# source interface sup-eth 0 both

Example:

switch(config-monitor)# source interface ethernet 101/1/1-3

Configures the sources and traffic direction in which to copy packets. You can enter a range of Ethernet ports, a port channel, or a range of VLANs.

You can configure one or more sources, as either a series of comma-separated entries or a range of numbers. You can specify up to 128 interfaces. For information on the VLAN range, see the Cisco Nexus 3500 Series NX-OS Layer 2 Switching Configuration Guide.

You can specify the traffic direction to copy as ingress, egress, or both. The default direction is both.

Step 7

Repeat Step 6 to configure all ERSPAN sources.

(Optional)
—

Step 8

destination ip ip-address

Example:

switch(config-erspan-src)# destination ip 10.1.1.1

Configures the destination IP address in the ERSPAN session. Only one destination IP address is supported per ERSPAN source session.

Step 9

erspan-id erspan-id

Example:

switch(config-erspan-src)# erspan-id 5

Configures the ERSPAN ID for the ERSPAN source session. The ERSPAN range is from 1 to 1023. This ID uniquely identifies a source and destination ERSPAN session pair. The ERSPAN ID configured in the corresponding destination ERSPAN session must be same as the one configured in the source session.

Step 10

vrf vrf-name

Example:

switch(config-erspan-src)# vrf default

Configures the VRF that the ERSPAN source session uses for traffic forwarding.

Step 11

ip ttl ttl-number

Example:

switch(config-erspan-src)# ip ttl 25

(Optional)
Configures the IP time-to-live (TTL) value for the ERSPAN traffic. The range is from 1 to 255.

Step 12

ip dscp dscp-number

Example:

switch(config-erspan-src)# ip dscp 42

(Optional)
Configures the differentiated services code point (DSCP) value of the packets in the ERSPAN traffic. The range is from 0 to 63.

Step 13

no shut

Example:

switch(config-erspan-src)# no shut

Enables the ERSPAN source session. By default, the session is created in the shut state.
Note:
Only two ERSPAN source sessions can be running simultaneously.

Step 14

show monitor session {all | session-number | range session-range}

Example:

switch(config-erspan-src)# show monitor session 3

(Optional)
Displays the ERSPAN session configuration.

Step 15

show running-config monitor

Example:

switch(config-erspan-src)# show running-config monitor

(Optional)
Displays the running ERSPAN configuration.

Step 16

show startup-config monitor

Example:

switch(config-erspan-src)# show startup-config monitor

(Optional)
Displays the ERSPAN startup configuration.

Step 17

copy running-config startup-config

Example:

switch(config-erspan-src)# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

Configuring an ERSPAN Destination Session

You can configure an ERSPAN destination session to copy packets from a source IP address to destination ports on the local device. By default, ERSPAN destination sessions are created in the shut state.

Before You Begin

Ensure that you have already configured the destination ports in monitor mode.

Procedure

Command or Action

Purpose

Step 1

config t

Example:

switch# config t
switch(config)#

Enters global configuration mode.

Step 2

interface ethernet slot/port[-port]

Example:

switch(config)# interface ethernet 2/5
switch(config-if)#

Enters interface configuration mode on the selected slot and port or range of ports.

Step 3

switchport

Example:

switch(config-if)# switchport

Configures switchport parameters for the selected slot and port or range of ports.

Step 4

switchport mode [access | trunk]

Example:

switch(config-if)# switchport mode trunk

Configures the following switchport modes for the selected slot and port or range of ports:

- access

- trunk

Step 5

switchport monitor

Example:

switch(config-if)# switchport monitor

Configures the switch interface in monitor mode.

To configure an interface to be an ERSPAN or SPAN destination (using the destination interface ethernet interface command), it must first be configured in monitor mode.

Step 6

Repeat Steps 2 to 5 to configure monitoring on additional ERSPAN destinations.

—

Step 7

no monitor session {session-number | all}

Example:

switch(config-if)# no monitor session 3

Clears the configuration of the specified ERSPAN session. The new session configuration is added to the existing session configuration.

Step 8

monitor session {session-number | all} type erspan-destination

Example:

switch(config-if)# monitor session 3 type erspan-destination
switch(config-erspan-dst)#

Configures an ERSPAN destination session.

Step 9

description description

Example:

switch(config-erspan-dst)# description erspan_dst_session_3

Configures a description for the session. By default, no description is defined. The description can be up to 32 alphanumeric characters.

Step 10

source ip ip-address

Example:

switch(config-erspan-dst)# source ip 10.1.1.1

Configures the source IP address in the ERSPAN session. Only one source IP address is supported per ERSPAN destination session.

This IP address must match the destination IP address configured in the corresponding ERSPAN source session.

Step 11

destination {[interface [type slot/port[-port], [type slot/port [port]]] ]}

Example:

switch(config-erspan-dst)# destination interface ethernet 2/5

Configures a destination for copied source packets. You can configure only interfaces as a destination.
Note:
You can configure destination ports as trunk ports.

Step 12

erspan-id erspan-id

Example:

switch(config-erspan-dst)# erspan-id 5

Configures the ERSPAN ID for the ERSPAN session. The range is from 1 to 1023. This ID uniquely identifies a source and destination ERSPAN session pair. The ERSPAN ID configured in the corresponding destination ERSPAN session must be same as the one configured in the source session.

Step 13

vrf default

Example:

switch(config-erspan-dst)# vrf default

Configures the VRF instance that the ERSPAN destination session uses for traffic forwarding.

ERSPAN destination sessions support the default VRF only.

Step 14

no shut

Example:

switch(config)# no shut

Enables the ERSPAN destination session. By default, the session is created in the shut state.
Note:
Only 16 active ERSPAN destination sessions can be running simultaneously.

Step 15

show monitor session {all | session-number | range session-range}

Example:

switch(config)# show monitor session 3

(Optional)
Displays the ERSPAN session configuration.

Step 16

show running-config monitor

Example:

switch(config-erspan-src)# show running-config monitor

(Optional)
Displays the running ERSPAN configuration.

Step 17

show startup-config monitor

Example:

switch(config-erspan-src)# show startup-config monitor

(Optional)
Displays the ERSPAN startup configuration.

Step 18

copy running-config startup-config

Example:

switch(config-erspan-src)# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

Shutting Down or Activating an ERSPAN Session

You can shut down ERSPAN sessions to discontinue the copying of packets from sources to destinations. Because only a specific number of ERSPAN sessions can be running simultaneously, you can shut down a session to free hardware resources to enable another session. By default, ERSPAN sessions are created in the shut state.

You can enable ERSPAN sessions to activate the copying of packets from sources to destinations. To enable an ERSPAN session that is already enabled but operationally down, you must first shut it down and then enable it. You can shut down and enable the ERSPAN session states with either a global or monitor configuration mode command.

Procedure

Command or Action

Purpose

Step 1

configuration terminal

Example:

switch# configuration terminal
switch(config)#

Enters global configuration mode.

Step 2

monitor session {session-range | all} shut

Example:

switch(config)# monitor session 3 shut

Shuts down the specified ERSPAN sessions. The session range is from . By default, sessions are created in the shut state.

Note:

- In Cisco Nexus 5000 and 5500 platforms, two sessions can run simultaneously.

- In Cisco Nexus 5600 and 6000 platforms, 16 sessions can run simultaneously.

Step 3

no monitor session {session-range | all} shut

Example:

switch(config)# no monitor session 3 shut

Resumes (enables) the specified ERSPAN sessions. The session range is from . By default, sessions are created in the shut state. .
Note:
If a monitor session is enabled but its operational status is down, then to enable the session, you must first specify the monitor session shut command followed by the no monitor session shut command.

Step 4

monitor session session-number type erspan-source

Example:

switch(config)# monitor session 3 type erspan-source
switch(config-erspan-src)#

Enters the monitor configuration mode for the ERSPAN source type. The new session configuration is added to the existing session configuration.

Step 5

monitor session session-number type erspan-destination

Example:

switch(config-erspan-src)# monitor session 3 type erspan-destination

Enters the monitor configuration mode for the ERSPAN destination type.

Step 6

shut

Example:

switch(config-erspan-src)# shut

Shuts down the ERSPAN session. By default, the session is created in the shut state.

Step 7

no shut

Example:

switch(config-erspan-src)# no shut

Enables the ERSPAN session. By default, the session is created in the shut state.

Step 8

show monitor session all

Example:

switch(config-erspan-src)# show monitor session all

(Optional)
Displays the status of ERSPAN sessions.

Step 9

show running-config monitor

Example:

switch(config-erspan-src)# show running-config monitor

(Optional)
Displays the running ERSPAN configuration.

Step 10

show startup-config monitor

Example:

switch(config-erspan-src)# show startup-config monitor

(Optional)
Displays the ERSPAN startup configuration.

Step 11

copy running-config startup-config

Example:

switch(config-erspan-src)# copy running-config startup-config

(Optional)
Copies the running configuration to the startup configuration.

Configuring ERSPAN Filtering

You can configure SPAN filters for local and ERSPAN-source sessions only. SPAN and ERSPAN Filtering provides more information about filters.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session {session-number | all} type erspan-source

Configures an ERSPAN source session.

Step 3

switch(config-erspan-src)# filter {ip source-ip-address source-ip-mask destination-ip-address destination-ip-mask}

Creates an ERSPAN filter.

Step 4

switch(config-erspan-src)# erspan-id erspan-id

Configures the ERSPAN ID for the ERSPAN source session. The ERSPAN range is from 1 to 1023. This ID uniquely identifies a source and destination ERSPAN session pair. The ERSPAN ID configured in the corresponding destination ERSPAN session must be same as the one configured in the source session.

Step 5

switch(config-erspan-src)# vrf vrf-name

Configures the VRF that the ERSPAN source session uses for traffic forwarding.

Step 6

switch(config-erspan-src)# destination ip ip-address

Configures the destination IP address in the ERSPAN session. Only one destination IP address is supported per ERSPAN source session.

Step 7

switch(config-erspan-src)# source [interface [type slot/port] | port-channel channel-number] | [vlan vlan-range] [rx | tx | both]

Configures the sources and traffic direction in which to copy packets. You can enter a range of Ethernet ports, a port channel, or a range of VLANs.

You can configure one or more sources, as either a series of comma-separated entries or a range of numbers. You can specify up to 128 interfaces.

You can specify the traffic direction to copy as ingress, egress, or both. The default direction is both.

The following example shows how to configure an MAC-based filter for an ERSPAN-source session:

switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# monitor session 2 type erspan-source
switch(config-erspan-src)# filter abcd.ef12.3456 1111.2222.3333 1234.5678.9012 1111.2222.3333
switch(config-erspan-src)# erspan-id 20
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 200.1.1.1
switch(config-erspan-src)# source interface Ethernet 1/47 rx
switch(config-erspan-src)# no shut
switch(config-erspan-src)#

The following example shows how to configure a VLAN-based filter for an ERSPAN-source session:

switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# monitor session 2 type erspan-source
switch(config-erspan-src)# filter abcd.ef12.3456 1111.2222.3333 1234.5678.9012 1111.2222.3333
switch(config-erspan-src)# erspan-id 21
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 200.1.1.1
switch(config-erspan-src)# source interface Ethernet 1/47 rx
switch(config-erspan-src)# source vlan 315
switch(config-erspan-src)# mtu 200
switch(config-erspan-src)# no shut
switch(config-erspan-src)#

Configuring ERSPAN Sampling

You can configure sampling for local and ERSPAN-source sessions only. SPAN and ERSPAN Sampling provides more information about sampling.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session {session-number | all} type erspan-source

Configures an ERSPAN source session.

Step 3

switch(config-erspan-src)# sampling sampling-range

Configures a range for spanning packets. If the range is defined as n, every nth packet will be spanned.

The sampling range is between 2 and 1023.

Step 4

switch(config-erspan-src)# erspan-id erspan-id

Configures the ERSPAN ID for the ERSPAN source session. The ERSPAN range is from 1 to 1023. This ID uniquely identifies a source and destination ERSPAN session pair. The ERSPAN ID configured in the corresponding destination ERSPAN session must be same as the one configured in the source session.

Step 5

switch(config-erspan-src)# vrf vrf-name

Configures the VRF that the ERSPAN source session uses for traffic forwarding.

Step 6

switch(config-erspan-src)# destination ip ip-address

Configures the destination IP address in the ERSPAN session. Only one destination IP address is supported per ERSPAN source session.

Step 7

switch(config-erspan-src)# source [interface type slot/port | port-channel channel-number] | [vlan vlan-range] [rx | tx | both]

Configures the sources and traffic direction in which to copy packets. You can enter a range of Ethernet ports, a port channel, or a range of VLANs.

You can configure one or more sources, as either a series of comma-separated entries or a range of numbers. You can specify up to 128 interfaces.

You can specify the traffic direction to copy as ingress, egress, or both. The default direction is both.

The following example shows how to configure sampling for an ERSPAN-source session:

switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# monitor session 2 type erspan-source
switch(config-erspan-src)# sampling 40
switch(config-erspan-src)# erspan-id 30
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 200.1.1.1
switch(config-erspan-src)# source interface ethernet 1/47
switch(config-erspan-src)# show monitor session 2
session 2
---------------
type : erspan-source
state : up
granularity : 100 microseconds
erspan-id : 30
vrf-name : default
destination-ip : 200.1.1.1
ip-ttl : 255
ip-dscp : 0
header-type : 2
mtu : 200
sampling : 40
origin-ip : 150.1.1.1 (global)
source intf :
rx : Eth1/47
tx : Eth1/47
both : Eth1/47
source VLANs :
rx : 315
switch(config-erspan-src)#

Configuring ERSPAN Truncation

You can configure truncation for local and ERSPAN-source sessions only. SPAN and ERSPAN Truncation provides more information about truncation.

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# monitor session {session-number | all} type erspan-source

Configures an ERSPAN source session.

Step 3

switch(config-erspan-src)# mtu size

Configures the MTU size for truncation. Any SPAN packet that is larger than the configured MTU size is truncated to the configured size with a 4-byte offset.

The MTU truncation size is between 64 bytes and 1518 bytes.

Step 4

switch(config-erspan-src)# erspan-id erspan-id

Configures the ERSPAN ID for the ERSPAN source session. The ERSPAN range is from 1 to 1023. This ID uniquely identifies a source and destination ERSPAN session pair. The ERSPAN ID configured in the corresponding destination ERSPAN session must be same as the one configured in the source session.

Step 5

switch(config-erspan-src)# vrf vrf-name

Configures the VRF that the ERSPAN source session uses for traffic forwarding.

Step 6

switch(config-erspan-src)# destination ip ip-address

Configures the destination IP address in the ERSPAN session. Only one destination IP address is supported per ERSPAN source session.

Step 7

switch(config-erspan-src)# source [interface type slot/port | port-channel channel-number] | [vlan vlan-range] [rx | tx | both]

Configures the sources and traffic direction in which to copy packets. You can enter a range of Ethernet ports, a port channel, or a range of VLANs.

You can configure one or more sources, as either a series of comma-separated entries or a range of numbers. You can specify up to 128 interfaces.

You can specify the traffic direction to copy as ingress, egress, or both. The default direction is both.

The following example shows how to configure MTU truncation for an ERSPAN-source session:

switch# configure terminal
switch(config)# monitor session 6 type erspan-source
switch(config-erspan-src)# mtu 1096
switch(config-erspan-src)# erspan-id 40
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 200.1.1.1
switch(config-erspan-src)# source interface ethernet 1/40
switch(config-erspan-src)# show monitor session 6
session 6
---------------
type : erspan-source
state : down (Session admin shut)
granularity : 100 microseconds
erspan-id : 40
vrf-name : default
destination-ip : 200.1.1.1
ip-ttl : 255
ip-dscp : 0
header-type : 2
mtu : 1096
origin-ip : 150.1.1.1 (global)
source intf :
rx : Eth1/40
tx : Eth1/40
both : Eth1/40
source VLANs :
rx :

Configuring an ERSPAN Marker Packet

Use the following commands to configure an ERSPAN marker packet:

Command

Purpose

marker-packet seconds

Enables the ERSPAN marker packet for a session.

The interval can range from 1 second to 4 seconds.

no marker-packet

Disables the ERSPAN marker packet for a session.

This example shows how to enable the ERSPAN marker packet with an interval of 2 seconds:

Note

Configuring the interval parameter is optional. If you enable the marker-packet without specifying a parameter, it uses the default or existing interval as the interval value. The marker-packet command only enables the marker-packet.

switch# configure terminal
switch(config)# monitor erspan origin ip-address 172.28.15.250 global
switch(config)# monitor session 1 type erspan-source
switch(config)# header-type 3
switch(config-erspan-src)# erspan-id 1
switch(config-erspan-src)# ip ttl 16
switch(config-erspan-src)# ip dscp 5
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 9.1.1.2
switch(config-erspan-src)# source interface e1/15 both
switch(config-erspan-src)# marker-packet 2
switch(config-erspan-src)# no shut
switch(config-erspan-src)# exit

Verifying the ERSPAN Configuration

Use the following command to verify the ERSPAN configuration information:

Command

Purpose

show monitor session {all | session-number | range session-range}

Displays the ERSPAN session configuration.

show running-config monitor

Displays the running ERSPAN configuration.

show startup-config monitor

Displays the ERSPAN startup configuration.

Configuration Example for an ERSPAN Source Session

The following example shows how to configure an ERSPAN source session:

switch# config t
switch(config)# interface e14/30
switch(config-if)# no shut
switch(config-if)# exit
switch(config)# monitor erspan origin ip-address 3.3.3.3 global
switch(config)# monitor erspan granularity 100_ns
switch(config-erspan-src)# header-type 3
switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# source interface e14/30
switch(config-erspan-src)# erspan-id 1
switch(config-erspan-src)# ip ttl 16
switch(config-erspan-src)# ip dscp 5
switch(config-erspan-src)# vrf default
switch(config-erspan-src)# destination ip 9.1.1.2
switch(config-erspan-src)# no shut
switch(config-erspan-src)# exit
switch(config)# show monitor session 1

Configuration Example for an ERSPAN Destination Session

The following example shows how to configure an ERSPAN destination session:

switch# config t
switch(config)# interface e14/29
switch(config-if)# no shut
switch(config-if)# switchport
switch(config-if)# switchport monitor
switch(config-if)# exit
switch(config)# monitor session 2 type erspan-destination
switch(config-erspan-dst)# source ip 9.1.1.2
switch(config-erspan-dst)# destination interface e14/29
switch(config-erspan-dst)# erspan-id 1
switch(config-erspan-dst)# vrf default
switch(config-erspan-dst)# no shut
switch(config-erspan-dst)# exit
switch(config)# show monitor session 2

switch# config t
switch(config)# interface e14/29
switch(config-if)# no shut
switch(config-if)# switchport
switch(config-if)# switchport monitor
switch(config-if)# exit
switch(config)# monitor session 2 type erspan-destination
switch(config-erspan-dst)# source ip 9.1.1.2
switch(config-erspan-dst)# destination interface e14/29
switch(config-erspan-dst)# erspan-id 1
switch(config-erspan-dst)# no shut
switch(config-erspan-dst)# exit
switch(config)# show monitor session 2

Related Documents

Related Topic

Document Title

ERSPAN commands: complete command syntax, command modes, command history, defaults, usage guidelines, and examples

Cisco Nexus NX-OS System Management Command Reference for your platform.

Chapter 18. Performing Software Maintenance Upgrades (SMUs)

This chapter includes the following sections:

- About SMUs

- Package Management

- Prerequisites for SMUs

- Guidelines and Limitations for SMUs

- Performing a Software Maintenance Upgrade for Cisco NX-OS

- Preparing for Package Installation

- Copying the Package File to a Local Storage Device or Network Server

- Adding and Activating Packages

- Committing the Active Package Set

- Deactivating and Removing Packages

- Displaying Installation Log Information

About SMUs

A software maintenance upgrade (SMU) is a package file that contains fixes for a specific defect. SMUs are created to respond to immediate issues and do not include new features. Typically, SMUs do not have a large impact on device operations. SMU versions are synchronized to the package major, minor, and maintenance versions they upgrade.

The effect of an SMU depends on its type:

- Process restart SMU-Causes a process or group of processes to restart on activation.

- Reload SMU-Causes a parallel reload of supervisors and line cards.

SMUs are not an alternative to maintenance releases. They provide a quick resolution of immediate issues. All defects fixed by SMUs are integrated into the maintenance releases.

For information on upgrading your device to a new feature or maintenance release, see the Cisco Nexus 3000 Series NX-OS Software Upgrade and Downgrade Guide.

Note

Activating an SMU does not cause any earlier SMUs, or the package to which the SMU applies, to be automatically deactivated.

Package Management

The general procedure for adding and activating SMU packages on the device is as follows:

1. Copy the package file or files to a local storage device or file server.

2. Add the package or packages on the device using the install add command.

3. Activate the package or packages on the device using the install activate command.

4. Commit the current set of packages using the install commit command.

5. (Optional) Deactivate and remove the package, when desired.

The following figure illustrates the key steps in the package management process.

Process to Add, Activate, and Commit SMU Packages

Prerequisites for SMUs

These prerequisites must be met for a package to be activated or deactivated:

- You must be in a user group associated with a task group that includes the proper task IDs. If you suspect a user group assignment is preventing you from using a command, contact your AAA administrator for assistance.

- Verify that all line cards are installed and operating properly. For example, do not activate or deactivate packages while line cards are booting, while line cards are being upgraded or replaced, or when you anticipate an automatic switchover activity.

Guidelines and Limitations for SMUs

SMUs have the following guidelines and limitations:

- Some packages require the activation or deactivation of other packages. If the SMUs have dependencies on each other, you cannot activate them without first activating the previous ones.

- The package being activated must be compatible with the current active software set.

- You cannot activate multiple SMUs in one command.

- Activation is performed only after the package compatibility checks have been passed. If a conflict is found, an error message displays.

- While a software package is being activated, other requests are not allowed to run on any of the impacted nodes. Package activation is completed when a message similar to this one appears:

Install operation 1 completed successfully at Thu Jan 9 01:19:24 2014

- Each CLI install request is assigned a request ID, which can be used later to review the events.

- If you perform a software maintenance upgrade and later upgrade your device to a new Cisco Nexus 3500 software release, the new image will overwrite both the previous Cisco Nexus 3500 release and the SMU package file.

Performing a Software Maintenance Upgrade for Cisco NX-OS

Preparing for Package Installation

You should use several show commands to gather information in preparation for the SMU package installation.

Before You Begin

Determine if a software change is required.

Verify that the new package is supported on your system. Some software packages require that other packages or package versions be activated, and some packages support only specific line cards.

Review the release notes for important information related to that release and to help determine the package compatibility with your device configuration.

Verify that the system is stable and prepared for the software changes.

Procedure

Command or Action

Purpose

Step 1

show install active

Example:

switch# show install active

Displays the active software on the device. Use this command to determine what software should be added on the device and to compare to the active software report after installation operations are complete.

Step 2

show module

Example:

switch# show module

Confirms that all modules are in the stable state.

Step 3

show clock

Example:

switch# show clock

Verifies that the system clock is correct. Software operations use certificates based on device clock times.

This example shows how to display the active packages for the entire system. Use this information to determine if a software change is required.

switch# show install active
Active Packages:
Active Packages on Module #3:

Active Packages on Module #6:

Active Packages on Module #7:
Active Packages on Module #22:

Active Packages on Module #30:

This example shows how to display the current system clock setting:

switch# show clock
02:14:51.474 PST Wed Jan 04 2014

Copying the Package File to a Local Storage Device or Network Server

You must copy the SMU package file to a local storage device or a network file server to which the device has access. After this task is done, the package can be added and activated on the device.

If you need to store package files on the device, we recommend that you store the files on the hard disk. The boot device is the local disk from which the package is added and activated. The default boot device is bootflash:.

Tip

Before you copy package files to a local storage device, use the dir command to determine if the required package files are already on the device.

If the SMU package files are located on a remote TFTP, FTP, or SFTP server, you can copy the files to a local storage device. After the files are located on the local storage device, the package can be added and activated on the device from that storage device. The following server protocols are supported:

- Trivial File Transfer Protocol—TFTP allows files to be transferred from one computer to another over a network, usually without the use of client authentication (for example, username and password). It is a simplified version of FTP.

Note

Some package files might be larger than 32 MB, and the TFTP services provided by some vendors might not support a file this large. If you do not have access to a TFTP server that supports files larger than 32 MB, download the file using FTP.

- File Transfer Protocol—FTP is part of the TCP/IP protocol stack and requires a username and password.

- SSH File Transfer Protocol—SFTP is part of the SSHv2 feature in the security package and provides for secure file transfers.

After the SMU package file has been transferred to a network file server or the local storage device, you are ready to add and activate the file.

Adding and Activating Packages

You can add SMU package files that are stored on a local storage device or on a remote TFTP, FTP, or SFTP server to your device.

Note

The SMU package being activated must be compatible with the currently active software to operate. When an activation is attempted, the system runs an automatic compatibility check to ensure that the package is compatible with the other active software on the device. If a conflict is found, an error message displays. The activation is performed only after all compatibility checks have been passed.

Procedure

Command or Action

Purpose

Step 1

install add filename [activate]

Example:

switch# install add bootflash:
n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin

Unpacks the package software files from the local storage device or network server and adds them to the bootflash: and all active and standby supervisors installed on the device.

The filename argument can take any of these formats:

- bootflash:filename

- tftp://hostname-or-ipaddress/directory-path/filename

- ftp://username:password@ hostname-or-ipaddress/directory-path/filename

- sftp://hostname-or-ipaddress/directory-path/filename

Step 2

show install inactive

Example:

switch# show install inactive

(Optional)
Displays the inactive packages on the device. Verify that the package added in the previous step appears in the display.

Step 3

install activate filename [test]

Example:

switch# install activate
n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin

Example:

switch# install activate
n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 1 completed successfully at
Thu Jan 9 01:27:56 2014

Example:

switch# install activate
n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 2 !!WARNING!! This patch will get
activated only after a reload of the switch. at
Sun Mar 9 00:42:12 2014

Activates a package that was added to the device. SMU packages remain inactive until activated. (Skip this step if the package was activated earlier with the install add activate command.)

Note:
Press ? after a partial package name to display all possible matches available for activation. If there is only one match, press the Tab key to fill in the rest of the package name.

Step 4

Repeat Step 3 until all packages are activated.

Activates additional packages as required.

Step 5

show install active

Example:

switch# show install active

(Optional)
Displays all active packages. Use this command to determine if the correct packages are active.

Committing the Active Package Set

When an SMU package is activated on the device, it becomes part of the current running configuration. To make the package activation persistent across system-wide reloads, you must commit the package on the device.

Procedure

Command or Action

Purpose

Step 1

install commit filename

Example:

switch# install commit n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin

Commits the current set of packages so that these packages are used if the device is restarted.

Step 2

show install committed

Example:

switch# show install committed

(Optional)
Displays which packages are committed.

Deactivating and Removing Packages

When a package is deactivated, it is no longer active on the device, but the package files remain on the boot disk. The package files can be reactivated later, or they can be removed from the disk.

Procedure

Command or Action

Purpose

Step 1

install deactivate filename

Example:

switch# install deactivate n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin

Deactivates a package that was added to the device and turns off the package features for the line card.

Note:
Press ? after a partial package name to display all possible matches available for deactivation. If there is only one match, press the Tab key to fill in the rest of the package name.

Step 2

show install inactive

Example:

switch# show install inactive

(Optional)
Displays the inactive packages on the device.

Step 3

install commit

Example:

switch# install commit

(Optional)
Commits the current set of packages so that these packages are used if the device is restarted.

Note:
Packages can be removed only if the deactivation operation is committed.

Step 4

install remove {filename | inactive}

Example:

switch# install remove n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Proceed with removing n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin? (y/n)? [n] y

Example:

switch# install remove inactive
Proceed with removing? (y/n)? [n] y

(Optional)
Removes the inactive package.

- Only inactive packages can be removed.

- Packages can be removed only if they are deactivated from all line cards in the device.

- The package deactivation must be committed.

- To remove a specific inactive package from a storage device, use the install remove command with the filename argument.

- To remove all inactive packages from all nodes in the system, use the install remove command with the inactive keyword.

Displaying Installation Log Information

The installation log provides information on the history of the installation operations. Each time an installation operation is run, a number is assigned to that operation.

- Use the show install log command to display information about both successful and failed installation operations.

- Use the show install log command with no arguments to display a summary of all installation operations. Specify the request-id argument to display information specific to an operation. Use the detail keyword to display details for a specific operation, including file changes, nodes that could not be reloaded, and any impact to processes.

This example shows how to display information for all installation requests:

switch# show install log
Thu Jan 9 01:26:09 2014
Install operation 1 by user 'admin' at Thu Jan 9 01:19:19 2014
Install add bootflash: n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 1 completed successfully at Thu Jan 9 01:19:24 2014
----------------------------------------
Install operation 2 by user 'admin' at Thu Jan 9 01:19:29 2014
Install activate n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 2 completed successfully at Thu Jan 9 01:19:45 2014
----------------------------------------
Install operation 3 by user 'admin' at Thu Jan 9 01:20:05 2014
Install commit n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 3 completed successfully at Thu Jan 9 01:20:08 2014
----------------------------------------
Install operation 4 by user 'admin' at Thu Jan 9 01:20:21 2014
Install deactivate n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 4 completed successfully at Thu Jan 9 01:20:36 2014
----------------------------------------
Install operation 5 by user 'admin' at Thu Jan 9 01:20:43 2014
Install commit n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 5 completed successfully at Thu Jan 9 01:20:46 2014
----------------------------------------
Install operation 6 by user 'admin' at Thu Jan 9 01:20:55 2014
Install remove n3500-uk9.6.0.2.U6.0.1.CSCab00001.bin
Install operation 6 completed successfully at Thu Jan 9 01:20:57 2014

Chapter 19. Configuring Active Buffer Monitoring

This chapter contains the following sections:

- Configuring Active Buffer Monitoring

- Displaying Buffer Histogram Data

Active Buffer Monitoring Overview

The Active Buffer Monitoring feature provides detailed buffer occupancy data to help you detect network congestion, review past events to understand when and how network congestion is affecting network operations, understand historical trending, and identify patterns of application traffic flow.

A hardware component, called the Algorithm Boost Engine (Algo Boost Engine) supports buffer histogram counters for unicast buffer usage per individual port, total buffer usage per buffer block, and multicast buffer usage per buffer block. Each histogram counter has 18 buckets that span across the memory block. The Algo Boost Engine polls buffer usage data every hardware sampling interval (the default is every 4 milliseconds, but you can configure it to be as low as 10 nanoseconds). Based on the buffer utilization, the corresponding histogram counter is incremented. For example, if Ethernet port 1/4 is consuming 500 KB of the buffer, the bucket 2 counter (which represents 384 KB to 768 KB) for Ethernet 1/4 is incremented.

To avoid a counter overflow, the Cisco NX-OS software collects the histogram data every polling interval and maintains it in the system memory. The software maintains the histogram data in the system memory for the last 60 minutes with 1-second granularity. Every hour, the software copies the buffer histogram data from the system memory to the bootflash as a backup.

The Active Buffer Monitoring feature has two modes of operation:

- Unicast mode—The Algo Boost Engine monitors and maintains a buffer histogram for total buffer utilization per buffer block and unicast buffer utilization for all 48 ports.

- Multicast mode—The Algo Boost Engine monitors and maintains buffer histogram data for total buffer utilization per buffer block and multicast buffer utilization per buffer block.

Buffer Histogram Data Access and Collection

After active buffer monitoring is enabled, the device maintains 70 minutes of data—the first 60 minutes (0 to 60 minutes) in the log and another 60 minutes (10 to 70 minutes) in memory.

You can access buffer histogram data using several methods:

- You can access it from the system memory using show commands.

- You can integrate the Active Buffer Monitoring feature with Cisco NX-OS Python scripting to collect historical data by copying the data to a server regularly.

- You can access the buffer histogram data using an XML interface.

- You can configure Cisco NX-OS to log a message in the syslog whenever the buffer occupancy exceeds the configured threshold.

Configuring Active Buffer Monitoring

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# hardware profile buffer monitor {unicast | multicast}

Enables the hardware profile buffer for either unicast or multicast traffic.

Step 3

switch(config)# hardware profile buffer monitor {unicast | multicast} threshold threshold-value

Specifies to generate a syslog entry when the specified maximum buffer size is exceeded. The range is from 384 to 6144 kilobytes with 384 kilobyte increments. The default is 90 percent of the total available shared buffer.

Note:
Use the logging level mtc-usd5 command to display the active buffer monitoring threshold exceed system logging.

Step 4

switch(config)# hardware profile buffer monitor {unicast | multicast} sampling sampling-value

Specifies to sample data at the specified interval. The range is from 10 to 20000000 nanoseconds. The default sampling value is 4 milliseconds.

Step 5

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

This example shows how to configure Active Buffer Monitoring for unicast traffic with a threshold value of 10 kilobytes and a sampling value of 5000 nanoseconds:

switch# configure terminal
switch(config)# hardware profile buffer monitor unicast
switch(config)# hardware profile buffer monitor unicast threshold 384
switch(config)# hardware profile buffer monitor unicast sampling 5000
switch(config)# copy running-config startup-config

The following example shows how to configure Active Buffer Monitoring for multicast traffic with a threshold value of 10 kilobytes and a sampling value of 5000 nanoseconds.

switch# configure terminal
switch(config)# hardware profile buffer monitor multicast
switch(config)# hardware profile buffer monitor multicast threshold 384
switch(config)# hardware profile buffer monitor multicast sampling 5000
switch(config)# copy running-config startup-config

Displaying Buffer Histogram Data

Procedure

Command or Action

Purpose

Step 1

switch# show hardware profile buffer monitor [interface ethernet slot/port] {brief | buffer-block | detail | multicast | summary}

Displays data collected about the buffer. The keywords are defined as follows:

- brief—Specifies to show limited information about each interface.

- buffer-block—Specifies to display information about a specific buffer block.

- detail—Specifies to display all information gathered for each interface.

- interface—(Optional) Specifies to display information about a specific port.

- multicast—Specifies to show buffer data for multicast traffic only.

- summary—Specifies to display summary information about each buffer block.

Note:
The show command option interface is only valid in unicast mode and the multicast option is only valid in multicast mode.

Step 2

switch# clear hardware profile buffer monitor

(Optional)
Clears the collected buffer data.

This example shows how to display summary information for each buffer block and for all of the buffers combined:

switch# show hardware profile buffer monitor summary
Summary CLI issued at: 09/18/2012 07:38:39

Maximum buffer utilization detected
1sec     5sec    60sec     5min      1hr
------   ------   ------   ------   ------
Buffer Block 1       0KB      0KB      0KB      0KB      N/A

Total Shared Buffer Available = 5049 Kbytes
Class Threshold Limit = 4845 Kbytes
============================================================
Buffer Block 2       0KB      0KB      0KB      0KB      N/A

Total Shared Buffer Available = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes
============================================================
Buffer Block 3       0KB      0KB   5376KB   5376KB      N/A

Total Shared Buffer Available = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes

This example shows how to display the maximum buffer utilization of each buffer block and each interface for unicast mode:

switch# show hardware profile buffer monitor brief
Brief CLI issued at: 09/18/2012 07:38:29

Maximum buffer utilization detected
1sec     5sec    60sec     5min      1hr
------   ------   ------   ------   ------
Buffer Block 1       0KB      0KB      0KB      0KB      N/A

Total Shared Buffer Avaliable = 5049 Kbytes
Class Threshold Limit = 4845 Kbytes
------------------------------------------------------------
Ethernet1/45         0KB      0KB      0KB      0KB      N/A
Ethernet1/46         0KB      0KB      0KB      0KB      N/A
Ethernet1/47         0KB      0KB      0KB      0KB      N/A
Ethernet1/48         0KB      0KB      0KB      0KB      N/A
Ethernet1/21         0KB      0KB      0KB      0KB      N/A
Ethernet1/22         0KB      0KB      0KB      0KB      N/A
Ethernet1/23         0KB      0KB      0KB      0KB      N/A
Ethernet1/24         0KB      0KB      0KB      0KB      N/A
Ethernet1/9          0KB      0KB      0KB      0KB      N/A
Ethernet1/10         0KB      0KB      0KB      0KB      N/A
Ethernet1/11         0KB      0KB      0KB      0KB      N/A
Ethernet1/12         0KB      0KB      0KB      0KB      N/A
Ethernet1/33         0KB      0KB      0KB      0KB      N/A
Ethernet1/34         0KB      0KB      0KB      0KB      N/A
Ethernet1/35         0KB      0KB      0KB      0KB      N/A
Ethernet1/36         0KB      0KB      0KB      0KB      N/A
============================================================
Buffer Block 2       0KB      0KB      0KB      0KB      N/A

Total Shared Buffer Avaliable = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes
------------------------------------------------------------
Ethernet1/17         0KB      0KB      0KB      0KB      N/A
Ethernet1/18         0KB      0KB      0KB      0KB      N/A
Ethernet1/19         0KB      0KB      0KB      0KB      N/A
Ethernet1/20         0KB      0KB      0KB      0KB      N/A
Ethernet1/5          0KB      0KB      0KB      0KB      N/A
Ethernet1/6          0KB      0KB      0KB      0KB      N/A
Ethernet1/7          0KB      0KB      0KB      0KB      N/A
Ethernet1/8          0KB      0KB      0KB      0KB      N/A
Ethernet1/41         0KB      0KB      0KB      0KB      N/A
Ethernet1/42         0KB      0KB      0KB      0KB      N/A
Ethernet1/43         0KB      0KB      0KB      0KB      N/A
Ethernet1/44         0KB      0KB      0KB      0KB      N/A
Ethernet1/29         0KB      0KB      0KB      0KB      N/A
Ethernet1/30         0KB      0KB      0KB      0KB      N/A
Ethernet1/31         0KB      0KB      0KB      0KB      N/A
Ethernet1/32         0KB      0KB      0KB      0KB      N/A
============================================================
Buffer Block 3       0KB      0KB   5376KB   5376KB      N/A

Total Shared Buffer Avaliable = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes
------------------------------------------------------------
Ethernet1/13         0KB      0KB      0KB      0KB      N/A
Ethernet1/14         0KB      0KB      0KB      0KB      N/A
Ethernet1/15         0KB      0KB      0KB      0KB      N/A
Ethernet1/16         0KB      0KB      0KB      0KB      N/A
Ethernet1/37         0KB      0KB      0KB      0KB      N/A
Ethernet1/38         0KB      0KB      0KB      0KB      N/A
Ethernet1/39         0KB      0KB      0KB      0KB      N/A
Ethernet1/40         0KB      0KB      0KB      0KB      N/A
Ethernet1/25         0KB      0KB      0KB      0KB      N/A
Ethernet1/26         0KB      0KB      0KB      0KB      N/A
Ethernet1/27         0KB      0KB      0KB      0KB      N/A
Ethernet1/28         0KB      0KB      0KB      0KB      N/A
Ethernet1/1          0KB      0KB      0KB      0KB      N/A
Ethernet1/2          0KB      0KB      0KB      0KB      N/A
Ethernet1/3          0KB      0KB      0KB      0KB      N/A
Ethernet1/4          0KB      0KB   5376KB   5376KB      N/A

This example shows how to display the maximum buffer utilization information of each buffer block for multicast mode:

switch# show hardware profile buffer monitor brief
Brief CLI issued at: 09/18/2012 08:30:08

Maximum buffer utilization detected
1sec     5sec    60sec     5min      1hr
------   ------   ------   ------   ------
Buffer Block 1       0KB      0KB      0KB      0KB      0KB

Total Shared Buffer Avaliable = 5049 Kbytes
Class Threshold Limit = 4845 Kbytes
Mcast Usage 1        0KB      0KB      0KB      0KB      0KB
============================================================
Buffer Block 2       0KB      0KB      0KB      0KB      0KB

Total Shared Buffer Avaliable = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes
Mcast Usage 2        0KB      0KB      0KB      0KB      0KB
============================================================
Buffer Block 3       0KB      0KB      0KB      0KB      0KB

Total Shared Buffer Avaliable = 5799 Kbytes
Class Threshold Limit = 5598 Kbytes
Mcast Usage 3        0KB      0KB      0KB      0KB      0KB

The following example shows how to display detailed buffer utilization information of buffer block 3 for multicast mode:

switch# show hardware profile buffer monitor multicast 3 detail
Detail CLI issued at: 09/18/2012 08:30:12

Legend -
384KB  - between   1 and 384KB of shared buffer consumed by port
768KB  - between 385 and 768KB of shared buffer consumed by port
307us  - estimated max time to drain the buffer at 10Gbps

Active Buffer Monitoring for Mcast Usage 3 is: Active
KBytes                 384  768 1152 1536 1920 2304 2688 3072 3456 3840 4224 4608 4992 5376 5760 6144
us @ 10Gbps            307  614  921 1228 1535 1842 2149 2456 2763 3070 3377 3684 3991 4298 4605 4912
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
09/18/2012 08:30:12      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:11      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:10      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:09      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:08      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:07      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:06      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:05      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:04      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 08:30:03      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0

The following example shows how to display detailed buffer data about Ethernet interface 1/4:

switch# show hardware profile buffer monitor interface ethernet 1/4 detail
Detail CLI issued at: 09/18/2012 07:38:43

Legend -
384KB  - between   1 and 384KB of shared buffer consumed by port
768KB  - between 385 and 768KB of shared buffer consumed by port
307us  - estimated max time to drain the buffer at 10Gbps

Active Buffer Monitoring for port Ethernet1/4 is: Active
KBytes                 384  768 1152 1536 1920 2304 2688 3072 3456 3840 4224 4608 4992 5376 5760 6144
us @ 10Gbps            307  614  921 1228 1535 1842 2149 2456 2763 3070 3377 3684 3991 4298 4605 4912
---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
09/18/2012 07:38:42      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:41      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:40      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:39      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:38      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:37      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:36      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:35      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:34      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:33      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:32      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:31      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:30      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:29      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:28      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:27      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:26      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:25      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:24      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:23      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:22      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:21      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:20    177   36    0    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:19      0  143  107    0    0    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:18      0    0   72  178    3    0    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:17      0    0    0    0  176   74    0    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:16      0    0    0    0    0  105  145    0    0    0    0    0    0    0    0    0
09/18/2012 07:38:15      0    0    0    0    0    0   33  179   38    0    0    0    0    0    0    0
09/18/2012 07:38:14      0    0    0    0    0    0    0    0  140  113    0    0    0    0    0    0
09/18/2012 07:38:13      0    0    0    0    0    0    0    0    0   66  178    6    0    0    0    0
09/18/2012 07:38:12      0    0    0    0    0    0    0    0    0    0    0  173   77    0    0    0
09/18/2012 07:38:11      1    0    0    1    0    0    1    0    0    1    0    0  102   42    0    0
09/18/2012 07:38:10      0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0

Chapter 20. Configuring Traffic Forwarding Modes

This chapter contains the following sections:

- Information About Warp Mode

- Guidelines and Limitations for Warp Mode

- Enabling and Disabling Warp Mode

- Verifying Warp Mode Status

- Feature History for Warp Mode

Information About Warp Mode

The Cisco Nexus device uses a hardware component called the Algorithm Boost Engine (Algo Boost Engine) to support a forwarding mechanism, called warp mode. In warp mode, the access path is shortened by consolidating the forwarding table into single table, resulting in faster processing of frames and packets. In warp mode, latency is reduced by up to 20 percent. For more information about the Algo Boost Engine, see Active Buffer Monitoring Overview.

Guidelines and Limitations for Warp Mode

Warp mode has the following configuration guidelines and limitations:

- Warp mode provides up to 20 percent better switch latency than normal forwarding.

- In warp mode, unicast route tables are reduced. The route table is reduced from 24000 to 4000 entries. The host table and MAC table are reduced from 64000 to 8000 entries. (The multicast route table remains the same at 8000 entries.)

- In warp mode, the following features are not supported:

- Egress Routed Access Control Lists (RACLs)

- Port Access Control Lists (PACLs)

- Equal-cost Multipathing (ECMP)

- IP Redirect

Enabling and Disabling Warp Mode

Procedure

Command or Action

Purpose

Step 1

switch# configure terminal

Enters global configuration mode.

Step 2

switch(config)# hardware profile forwarding-mode warp

Enables warp mode on the device. To disable warp mode, use the no form of this command. The default is warp mode disabled.

Step 3

switch(config)# copy running-config startup-config

(Optional)
Saves the change persistently through reboots and restarts by copying the running configuration to the startup configuration.

Step 4

Reload the switch.

—

This example shows how to enable warp mode on the device:

switch# configuration terminal
switch(config)# hardware profile forwarding-mode warp
Warning: This command will take effect only after saving the configuration (copy r s)
switch(config)# copy running-config startup-config
switch(config)#

This example shows how to disable warp mode on the device:

switch# configuration terminal
switch(config)# no hardware profile forwarding-mode warp
Warning: This command will take effect only after saving the configuration (copy r s)
switch(config)# copy running-config startup-config

Verifying Warp Mode Status

Procedure

Command or Action

Purpose

Step 1

switch# show hardware profile forwarding-mode

Displays information about warp mode and the host, unicast, multicast, and Layer 2 ternary content addressable memory (TCAM) sizes.

This example shows how to display information about warp mode:

switch# show hardware profile forwarding-mode
==========================
forwarding-mode : warp
==========================
host      size  = 8192
unicast   size  = 4096
multicast size  = 8192
l2        size  = 8192
switch#

Feature History for Warp Mode

Feature Name

Release

Feature Information

Warp Mode

5.0(3)A1(1)

This feature was introduced.

Preface

The preface contains the following sections:

- Audience

- Document Conventions

- Documentation Feedback

Audience

This publication is for network administrators who configure and maintain Cisco Nexus devices.

Document Conventions

Note

As part of our constant endeavor to remodel our documents to meet our customers' requirements, we have modified the manner in which we document configuration tasks. As a result of this, you may find a deviation in the style used to describe these tasks, with the newly included sections of the document following the new format.

Command descriptions use the following conventions:

Convention

Description

bold

Bold text indicates the commands and keywords that you enter literally as shown.

Italic

Italic text indicates arguments for which the user supplies the values.

[x]

Square brackets enclose an optional element (keyword or argument).

[x | y]

Square brackets enclosing keywords or arguments separated by a vertical bar indicate an optional choice.

{x | y}

Braces enclosing keywords or arguments separated by a vertical bar indicate a required choice.

[x {y | z}]

Nested set of square brackets or braces indicate optional or required choices within optional or required elements. Braces and a vertical bar within square brackets indicate a required choice within an optional element.

variable

Indicates a variable for which you supply values, in context where italics cannot be used.

string

A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

Examples use the following conventions:

Convention

Description

screen font

Terminal sessions and information the switch displays are in screen font.

boldface screen font

Information you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

< >

Nonprinting characters, such as passwords, are in angle brackets.

[ ]

Default responses to system prompts are in square brackets.

!, #

An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

This document uses the following conventions:

Note

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.

Documentation Feedback

To provide technical feedback on this document, or to report an error or omission, please send your comments to: .

We appreciate your feedback.

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Click Here . Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)