Nexus 7000 NX OS PDF

Send document comments to [email protected].
INDEX
coordinated distributions 2-3

B
default settings 2-6
bootup diagnostics 13-2 description 2-1
boundary clock 4-2 disabling on a switch 2-31
distribution 2-2
distribution modes 2-3
C
enabling on a switch 2-31
Call Home features supported 2-2
e-mail notifications 1-4 guidelines 2-5
CDP high availability 2-5
clearing cache 5-7 licensing requirements 2-5
clearing statistics 5-7 limitations 2-5
configuring timers, example 5-8 locking the network 2-4
default settings 5-4 merge support 2-4
defined with LLDP 18-2 MIBs (table) 2-33
description 5-1 NTP 3-2, 3-14
disabling the feature 5-5 prerequisites 2-5
enabling globally 5-4 releasing session lock 3-16
enabling on an interface 5-5 uncoordinated distributions 2-3
guidelines 5-3 unrestricted uncoordinated distributions 2-3
licensing requirements 5-3 verifying configuration 2-32
limitations 5-3 virtualization 2-5
MIBs (table) 5-8 CFS applications
optional parameters 5-7 clearing session locks 2-29
prerequisites 5-3 committing changes 2-27
TLV fields 5-2 discarding changes 2-30
verifying configuration 5-7 enabling 2-7
version 5-4 enabling distribution for Call Home
configurations 2-7
virtualization 5-3
enabling distribution for device alias
VLAN ID 5-2
configurations 2-8
VTP 5-2
enabling distribution for DPVM configurations 2-9
CFS
enabling distribution for FC domain
connectivity in a mixed fabric 2-3 configurations 2-10
Cisco Nexus 7000 Series NX-OS System Management Configuration Guide, Release 5.x
OL-20635-03 IN-1
Index
enabling distribution for FC port security

configurations 2-11 D
enabling distribution for FC timer default settings
configurations 2-12
CDP 5-4
enabling distribution for IVR configurations 2-13
EEM 14-7
enabling distribution for NTP configurations 2-14
NetFlow 19-5
enabling distribution for RADIUS
configurations 2-15 NTP 3-4, 5-4, 16-7, 17-5
enabling distribution for RSCN configurations 2-16 OBFL 15-3
enabling distribution for TACACS+ online diagnostics 13-6

configurations 2-17 PTP 4-5
enabling distribution for user role RMON 12-3
configurations 2-18
rollback 8-4
fabric locking 2-27
Scheduler 10-3
CFS distribution mode, specifying 2-19
Smart Call Home 7-9
CFS over Ethernet (CFSoE), description 2-2
SNMP 11-7
CFS over Fibre Channel (CFSoFC), description 2-2
system messages 6-3
CFS over IP (CFSoIP)
device discovery protocol 18-2
configuring IP multicast addresses 2-20
diagnostics
description 2-2
bootup 13-2
CFS regions
on demand 13-5
configuring 2-22
runtime 13-3
creating 2-22
documentation
deleting 2-26
additional publications i-xxv
description 2-4
conventions i-xxv
moving an application to/from 2-23
obtaining i-xxvii
removing an application 2-25
checkpoints
system 8-2 E
Cisco discovery protocol
EEM
See CDP
actions 14-4
Cisco Fabric Service. See CFS
activating a script policy 14-15
clock manager
allow CLI commands to execute 14-14
PTP 4-3
configuration examples B-4
command scheduler
configuring action statements 14-13
execution logs 10-2
configuring event statements 14-10
configuration limits
description (table) C-1
defining an environment variable 14-7
configuration methods 1-2
defining a policy 14-8
defining script policies 14-14
IN-2 OL-20635-03
Index
description 14-1 to 14-5 guidelines 17-4

environment variables 14-5 high availability 17-3
event correlation 14-5 licensing requirements 17-4
event correlation (example) 14-21 limitations 17-4
event logs 14-2 multicast best effort mode (example) 17-17
events 14-3, B-3 multiple sessions 17-3
example configuration 14-21 prerequisites 17-4
guidelines 14-6 session limits 17-4
high availability 14-5 sessions 17-2
licensing requirements 14-6 session sources 17-6
limitations 14-6 shutting down a session 17-12
override policy 14-2 sources 17-2
override policy (note) 14-3 verifying configuration 17-15
override policy actions (note) 14-4 virtualization support 17-3
overriding a system policy 14-15 executing a session 9-5
parameter substitution 14-5 exporter map 19-2
policies 14-2
prerequisites 14-6
F
registering a script policy 14-15
SNMP support 11-5 feature history
system policies 14-2, B-1 ERSPAN 17-18
using to monitor syslog messages 14-19 features, new and changed (table) i-xix
verifying configuration 14-20
virtualization support 14-5
VSH script policies 14-4
G
EEM overriding a system policy (example) 14-21 GOLD. See online diagnostics
embedded event manager. See EEM
encapsulated remote switched port analyzer. See ERSPAN
ERSPAN H
ACL configuration example 17-16 health monitoring diagnostics 13-3
activating a session 17-12 high availability
configuring a destination session 17-9 CDP 5-3
configuring a session (example) 17-16 CFS 2-5
configuring a source session 17-6 EEM 14-5
configuring multicast best effort mode for a ERSPAN 17-3
session 17-14
LLDP 18-3
description 17-1
NetFlow 19-3
destinations 17-2
NTP 3-3, 5-3
feature history 17-18
OL-20635-03 IN-3
Index
online diagnostics 13-5 guidelines 18-4

PTP 4-3 high availability 18-3
RMON 12-2 licensing requirements 18-3
rollback 8-2 limitations 18-4
SNMP 11-6 verifying configuration 18-9
SPAN 16-4 virtualization support 18-3
L M
licensing requirements MIBs

CDP 5-3 CDP 5-8
CFS 2-5 CFS 2-33
EEM 14-6 description 11-2
ERSPAN 17-4 location to download 11-29
LLDP 18-3 NTP 3-19, 5-8
NetFlow 19-4 PTP 4-11
NTP 3-3 RMON 12-8
OBFL 15-2 Smart Call Home 7-39
online diagnostics 13-5 SNMP 11-29
PTP 4-4 monitor map 19-3
RMON 12-3 MTU truncation, configuring for SPAN sessions 16-16
rollback 8-3 multibest best effort mode
Scheduler 10-3 configuring for a SPAN session 16-19
session manager 9-2 multicast best effort mode
Smart Call Home 7-8 configuring for an ERSPAN session 17-14
SNMP 11-6 multicast best mode
SPAN 16-5 ERSPAN configuration example 17-17
system messages 6-3
limits
N
description (table) C-1
LLDP NetFlow
configuring optional parameters 18-7 applying a monitor map to an interface 19-13
configuring timers 18-7 applying a monitor map to a VLAN 19-14
default settings 18-4 applying a sampler map to an interface 19-13
defined 18-2 configuring Bridged NetFlow 19-14
description 18-1 configuring NetFlow 19-5
enabling or disabling globally 18-5 configuring timeouts 19-17
enabling or disabling on an interface 18-6 creating a monitor map 19-11
example configuration 18-9
IN-4 OL-20635-03
Index
creating an export map 19-9 configuring server 3-7

creating a record map 19-6 configuring the device as an authoritative server 3-6
creating a sampler map 19-12 default settings 3-4, 5-4, 16-7, 17-5
default settings 19-5 description 3-1
description 19-1 to 19-4 disabling 3-5
disabling 19-6 discarding configuration changes 3-16
enabling 19-6 enabling 3-5
example configuration 19-19 feature history 3-19
exporter map 19-2 guidelines 3-3
export formats 19-3 high availability 3-3, 5-3
flows 19-1 licensing requirements 3-3
full mode 19-2 limitations 3-3
high availability 19-3 logging 3-13
keys 19-1 MIBs (table) 3-19, 5-8
licensing requirements 19-4 prerequisites 3-3
monitor map 19-3 releasing CFS session lock 3-16
record map 19-2 source interface 3-13
sampled mode 19-2 source IP address 3-13
sampler map 19-3 stratum 3-2
specifying collect parameters 19-8 trusted keys 3-11
specifying match parameters 19-8 verifying configuration 3-16
verifying configuration 19-18 virtualization 3-3, 5-3
Netflow
O
configuring Layer 2 keys 19-15
Network Time Protocol. See NTP OBFL
NTP clearing statistics 15-7
access groups 3-11 default settings 15-3
as a time server 3-2 description 15-1
authentication keys 3-10 enabling 15-3
CFS 3-2, 3-14 example configuration 15-7
clearing a session 3-17 guidelines 15-3
clearing statistics 3-17 licensing requirements 15-2
clock manager 3-2 limitations 15-3
committing configuration changes 3-15 prerequisites 15-2
configuration examples 3-17 verifying configuration 15-6
configuring access restrictions 3-11 virtualization support 15-2
configuring authentication 3-10 on-board failure logging. See OBFL
configuring peer 3-7 on demand diagnostics 13-5
OL-20635-03 IN-5
Index
online diagnostics high availability 4-3

activating a diagnostics test 13-7 licensing requirements 4-4
bootup 13-2 limitations 4-4
clearing the test results 13-10 MIBs (table) 4-11
configuring the bootup diagnostic level 13-7 prerequisites 4-4
default settings 13-6 process 4-3
description 13-1 to 13-5 verifying configuration 4-9
example configuration 13-12 virtualization 4-4
feature history (table) 13-13
guidelines 13-6
R
health monitoring 13-3
high availability 13-5 record map 19-2
licensing requirements 13-5 related documents i-xxv
limitations 13-6 RMON
on demand 13-5 alarms 12-2
prerequisites 13-6 configuring alarms 12-4
runtime 13-3 configuring events 12-6
setting a diagnostic test as inactive 13-9 default settings 12-3
simulating a test result 13-11 description 12-1
starting an on-demand test 13-9 events 12-2
stopping an on-demand test 13-9 example configuration 12-7
verifying configuration 13-11 guidelines 12-3
virtualization support 13-5 high availability 12-2
VRFs 13-5 licensing requirements 12-3
ordinary clock 4-2 limitations 12-3
MIBs 12-8
prerequisites 12-3
P
Pong, description 4-3 virtualization support 12-3
Precision Time Protocol. See PTP VRFs 12-3
PTP rollback
configuration examples 4-9 checkpoint copy 8-2
configuring globally 4-5 creating a checkpoint copy 8-4
configuring on an interface 4-7 default settings 8-4
default settings 4-5 description 8-1
description 4-2 example configuration 8-7
device types 4-2 guidelines 8-3
feature history 4-11 high availability 8-2
guidelines 4-4 implementing a rollback 8-5
IN-6 OL-20635-03
Index
licensing requirements 8-3 discarding a session 9-6

limitations 8-3 guidelines 9-2
prerequisites 8-3 high availability 9-2
reverting to checkpoint file 8-5 licensing requirements 9-2
verifying configuration 8-6 limitations 9-2
virtualization support 8-3 prerequisites 9-2
runtime diagnostics 13-3 saving a session 9-6
verifying the session 9-5
S
sampler map 19-3 Simple Network Management Protocol. See SNMP
Scheduler Smart Call Home
authentication 10-2 alert groups 7-3
clearing the logfile 10-11 benefits 7-2
configuring 10-4 configuring an HTTP proxy server 7-22
configuring authentication 10-6 configuring contact information 7-10
configuring logfile 10-5 configuring e-mail 7-19
default settings 10-3 configuring inventory notification 7-19, 7-24
defining a timetable 10-9 configuring VRFs to send messages using
HTTP 7-21
defining jobs 10-7
database merge guidelines 7-7
deleting a job 10-8
description 10-1
description 7-1
disabling the feature 10-12
destination profiles
enabling the feature 10-4
associating an alert group 7-16
guidelines 10-3
attributes 7-14
high availability 10-2
creating 7-12
licensing requirements 10-3
description 7-2
limitations 10-3
modifying 7-14
prerequisites 10-3
predefined 7-2
disabling 7-25
disabling duplicate message throttle 7-25
scheduler
enabling 7-25
execution logs 10-2
event triggers (table) 7-27
session manager 9-5
example configuration 7-27
committing a session 9-5
guidelines 7-8
configuring ACLs 9-4
configuring an ACL session (example) 9-6
creating a session 9-3
limitations 7-8
description 9-1
OL-20635-03 IN-7
Index
mapping message levels to syslog levels (table) 7-5 example configuration 11-27
message formats feature history (table) 11-29
full text (table) 7-29, 7-30 filtering SNMP requests 11-10
full-text format, example 7-32 group-based access 11-5
inventory events (table) 7-31 guidelines 11-7
options 7-2 high availability 11-6
proactive events (table) 7-31 licensing requirements 11-6
reactive events (table) 7-31 limitations 11-7
short text (table) 7-29 manager 11-2
XML (table) 7-29, 7-30 MIBs 11-2
XML format, example 7-35 MIBs supported 11-29
message levels 7-5 multiple instance support 11-5
MIBs 7-39 notifications
modifying an alert group 7-17 configuring LinkUp/LinkDown
notifications 11-22
prerequisites 7-8
configuring notification receivers 11-11
registration requirements 7-6
sending a test message 7-26
configuring notification receivers with
VRFs 11-13
SMARTnet registration 7-6
configuring source interface for 11-12
configuring the notification target user 11-12
description 11-2
SNMP
enabling individual notifications 11-16
agent 11-2
informs 11-2
assigning contact 11-23
trap 11-2
assigning location 11-23
notification source interface 11-12
assigning multiple user roles 11-9
prerequisites 11-6
authentication 11-4
RFCs 11-2
configuring a user 11-8
RMON 12-1
configuring context to network entity mapping 11-24
user synchronization with CLI 11-4
context mapping 11-6
versions
contexts 11-5
security models and levels 11-3
creating communities 11-10
SNMPv3 11-2
USM 11-4
description 11-1 to 11-6
disabling protocol 11-26
VRFs 11-6
display ifIndex values 11-23
SNMP requests
EEM support 11-5
filtering 11-10
enabling one-time authentication 11-23
source rate limit, configuring for SPAN sessions 16-17
enforcing encryption 11-9
SPAN
engine ID format 11-8
IN-8 OL-20635-03
Index
configuring an RSPAN VLAN 16-14 configuring severity level to log 6-7

configuring a PVLAN source in a session configuring timestamp 6-7
(example) 16-22
configuring a session 16-8
description 6-1
configuring a session (example) 16-21
displaying a log file 6-10
configuring a source rate limit for each session 16-17
guidelines 6-3
configuring a virtual SPAN session 16-11
configuring a virtual SPAN session (example) 16-21
list of messages 6-12
configuring MTU truncation for each session 16-16
logging to a file 6-5
configuring the multicast best effort mode for a
logging to a terminal session 6-4
session 16-19
logging to the console port 6-4
description 16-1
RFC 6-1
enabling a session 16-15
severity levels (table) 6-2
guidelines 16-5
syslog server 6-2
limitations 16-5
multiple sessions 16-4
prerequisites 16-5 T
session destinations 16-8
TLVs
session limits 16-5
defined 18-2
sessions 16-3
supported by LLDP 18-8
session sources 16-8
transparent clock 4-2
shutting down a session 16-15
trap. See SNMP
subinterface restriction 16-8
troubleshooting 1-7
virtual SPAN sessions 16-3 V
switched port analyzer. See SPAN
syslog virtualization
as EEM publisher 14-19 CFS 2-5
See system messages NTP 3-3
system checkpoints 8-2 PTP 4-4
system messages virtualization support
clearing a log file 6-11 LLDP 18-3
configuring (example) 6-12 VTP
configuring a syslog server 6-8 CDP 5-2
configuring a syslog server on a Linux system 6-10

configuring a syslog server on a UNIX system 6-10
OL-20635-03 IN-9
Index
IN-10 OL-20635-03
New and Changed Information
This chapter provides release-specific information for each new and changed feature in the Cisco Nexus
7000 Series NX-OS System Management Configuration Guide, Release 5.x. The latest version of this
document is available at the following Cisco website:
http://www.cisco.com/en/US/products/ps9402/products_installation_and_configuration_guides_list.ht
ml
To check for additional information about Cisco NX-OS Release 5.x, see the Cisco Nexus 7000 Series
NX-OS Release Notes, Release 5.x available at the following Cisco website:
http://www.cisco.com/en/US/products/ps9402/prod_release_notes_list.html
Table 1 summarizes the new and changed features for the Cisco Nexus 7000 Series NX-OS System
Management Configuration Guide, Release 5.x and tells you where they are documented.
Table 1 New and Changed Features for Release 5.x
Change
d in
Feature Description Release Where Documented
NTP Increased the length of NTP authentication keys 5.2(3) Chapter 1, “Configuring NTP
from 8 to 15 alphanumeric characters. Authentication”
CFS protocol Added CFS over Fibre Channel (CFSoFC) 5.2(1) Chapter 1, “Configuring CFS”
distribution support for device alias, DPVM, FC
domain, FC port security, FC timer, IVR, and
RSCN.
EEM event correlation Added support for multiple event triggers in a 5.2(1) Chapter 1, “Configuring the
single EEM policy. Embedded Event Manager”
ERSPAN Added ERSPAN source support for Cisco Nexus 5.2(1) Chapter 1, “Configuring ERSPAN”
2000 Series Fabric Extender interfaces.
ERSPAN Added the ability to configure the multicast best 5.2(1) Chapter 1, “Configuring ERSPAN”
effort mode for an ERSPAN session.
HTTP proxy server for Added the ability to send HTTP messages 5.2(1) Chapter 1, “Configuring Smart
Smart Call Home through an HTTP proxy server. Call Home”
LLDP Added LLDP support for the Cisco Nexus 2000 5.2(1) Chapter 1, “Configuring LLDP”
Series Fabric Extender.
NetFlow Added NetFlow support on switch virtual 5.2(1) Chapter 1, “Configuring NetFlow”
interfaces (SVIs) for F1 Series ports.
OL-20635-03 11
Table 1 New and Changed Features for Release 5.x (continued)
Change
d in
NTP Added NTP support for all VDCs, enabling them 5.2(1) Chapter 1, “Virtualization
to act as time servers. Support”
NTP Added the ability to configure the device as an 5.2(1) Chapter 1, “Configuring the Device
authoritative NTP server, enabling it to distribute as an Authoritative NTP Server”
time even when it is not synchronized to an
existing time server.
NTP Changed the command to enable or disable NTP 5.2(1) Chapter 1, “Enabling or Disabling
from [no] ntp enable to [no] feature ntp. NTP”
NTP access groups Added the serve, serve-only, and query-only 5.2(1) Chapter 1, “Configuring NTP
access group options to control access to Access Restrictions”
additional NTP services.
Online diagnostics Enabled the SpineControlBus test on the standby 5.2(1) Chapter 1, “Configuring Online
(GOLD) supervisor. Diagnostics”
Online diagnostics Deprecated the SnakeLoopback test on F1 Series 5.2(1) Chapter 1, “Configuring Online
(GOLD) modules. Diagnostics”
PTP Added support for the Precision Time Protocol 5.2(1) Chapter 1, “Configuring PTP”
(PTP).
SPAN Added SPAN source support for Cisco Nexus 5.2(1) Chapter 1, “Configuring SPAN”
2000 Series Fabric Extender interfaces.
SPAN Added the ability to configure MTU truncation, 5.2(1) Chapter 1, “Configuring SPAN”
the source rate limit, and the multicast best effort
mode for each SPAN session.
System message logging Added the ability to add the description for 5.2(1) Chapter 1, “Configuring System
physical Ethernet interfaces and subinterfaces in Message Logging”
the system message log.
Online diagnostics Added support for the SnakeLoopback test on F1 5.1(2) Chapter 1, “Configuring Online
(GOLD) Series modules. Diagnostics”
Bridged NetFlow Added support for VLAN configuration mode, 5.1(1) Chapter 1, “Configuring Bridged
which enables you to configure VLANs NetFlow on a VLAN”
independently of their creation, when configuring
bridged NetFlow on a VLAN.
DCBXP This link layer protocol is used to announce, 5.1(1) Chapter 1, “Configuring LLDP”
exchange, and negotiate node parameters
between peers.
ERSPAN and ERSPAN You can configure ERSPAN to monitor traffic 5.1(1) Chapter 1, “Configuring ERSPAN”
ACLs across the IP network.
Online diagnostics Added support for FIPS and 5.1(1) Chapter 1, “Configuring Online
(GOLD) BootupPortLoopback tests. Diagnostics”
RMON Enabled RMON by default. 5.1(1) Chapter 1, “Configuring RMON”
12 OL-20635-03
Table 1 New and Changed Features for Release 5.x (continued)
Change
d in
SPAN Added support for F1 Series modules and 5.1(1) Chapter 1, “Configuring SPAN”
increased the number of supported SPAN
sessions from 18 to 48.
Syslog as EEM publisher You can monitor syslog messages from the 5.1(1) Chapter 1, “Configuring the
switch. Embedded Event Manager” and
Appendix 1, “Embedded Event
Manager System Events and
Configuration Examples”
Syslog servers Increased the number of supported syslog servers 5.1(1) Chapter 1, “Configuring System
from three to eight. Message Logging”
SMTP server You can configure multiple SMTP servers for 5.0(2) Chapter 1, “Configuring Smart
configuration for Smart Smart Call Home. Call Home”
Call Home
VRF support for HTTP VRFs can be used to send e-mail and other Smart 5.0(2) Chapter 1, “Configuring Smart
transport of Smart Call Call Home messages over HTTP. Call Home”
Home messages
Smart Call Home crash Messages are sent for process crashes on line 5.0(2) Chapter 1, “Configuring Smart
notifications cards (as well as supervisor modules). Call Home”
EEM system policies Fan EEM policies are modified for the Cisco 5.0(2) Appendix 1, “Embedded Event
Nexus 7000 10-Slot Switch. Manager System Events and
Configuration Examples”
LLDP You can configure the Link Layer Discovery 5.0(2) Chapter 1, “Configuring LLDP”
Protocol (LLDP) in order to discover other
devices on the local network.
NetFlow You can specify the NetFlow instance for which 5.0(2) Chapter 1, “Verifying the NetFlow
you want to display NetFlow IPv4 flows and Configuration”
NetFlow table utilization.
NTP access groups You can control access to NTP services by using 5.0(2) Chapter 1, “Configuring NTP
access groups. Authentication”
NTP authentication You can configure the device to authenticate the 5.0(2) Chapter 1, “Configuring NTP
time sources to which the local clock is Authentication”
synchronized.
NTP logging You can configure NTP logging in order to 5.0(2) Chapter 1, “Configuring NTP
generate system logs with significant NTP events. Authentication”
NTP server configuration Added the optional key keyword to the ntp 5.0(2) Chapter 1, “Configuring NTP
server command to configure a key to be used Authentication”
while communicating with the NTP server.
SNMP notifications Updated the snmp-server enable traps 5.0(2) Chapter 1, “Configuring SNMP”
commands.
OL-20635-03 13
14 OL-20635-03
Preface
This preface describes the audience, organization and conventions of the Cisco Nexus 7000 Series
NX-OS System Management Configuration Guide, Release 5.x. It also provides information on how to
obtain related documentation.
This chapter includes the following sections:
• Audience, page 15
• Document Organization, page 15
• Document Conventions, page 17
• Related Documentation, page 17
• Obtaining Documentation and Submitting a Service Request, page 19
Audience
This publication is for experienced network administrators who configure and maintain Cisco NX-OS
devices.
Document Organization
This document is organized into the following chapters:
Title Description
Chapter 1, “Overview” Provides an overview of the features in this
document.
Chapter 1, “Configuring CFS” Describes how to use Cisco Fabric Services (CFS)
to distribute data, including configuration
changes, to all Cisco NX-OS devices in a
network.
Chapter 1, “Configuring NTP” Describes how to configure the Network Time
Protocol (NTP).
Chapter 1, “Configuring PTP” Describes how to configure the Precision Time
Protocol (PTP).
Chapter 1, “Configuring CDP” Describes how to configure the Cisco Discovery
Protocol (CDP).
OL-20635-03 15
Preface
Title Description
Chapter 1, “Configuring System Message Describes how to configure logging for system
Logging” messages.
Chapter 1, “Configuring Smart Call Home” Describes how to configure the smart Call Home
feature for e-mail-based notification of critical
system policies.
Chapter 1, “Configuring Rollback” Describes how to create configuration snapshots
with the rollback feature and how to apply
commands in batch mode with the Session
Manager.
Chapter 1, “Configuring Session Manager” Describes how to apply commands in batch mode
with the Session Manager.
Chapter 1, “Configuring the Scheduler” Describes how to schedule batch configuration
jobs.
Chapter 1, “Configuring SNMP” Describes how to configure SNMP and enable
SNMP notifications.
Chapter 1, “Configuring RMON” Describes how to monitor the device by
configuring RMON alarms and events.
Chapter 1, “Configuring Online Diagnostics” Describes how to configure online diagnostics to
monitor the software and hardware.
Chapter 1, “Configuring the Embedded Event Describes how to configure the Embedded Event
Manager” Manager.
Chapter 1, “Configuring Onboard Failure Describes how to configure on-board failure
Logging” logging to log failure data to persistent storage.
Chapter 1, “Configuring SPAN” Describes how to configure SPAN to monitor
traffic into and out of a port.
Chapter 1, “Configuring ERSPAN” Describes how to configure ERSPAN to transport
mirrored traffic in an IP network on Cisco NX-OS
devices.
Chapter 1, “Configuring LLDP” Describes how to configure Link Layer Discovery
Protocol (LLDP) in order to discover servers that
are connected to your device.
Chapter 1, “Configuring NetFlow” Describes how to configure NetFlow to gather
statistics on input and output traffic.
Appendix 1, “IETF RFCs supported by Cisco Lists supported IETF RFCs.
NX-OS System Management”
Appendix 1, “Embedded Event Manager System Lists the EEM system policies.
Events and Configuration Examples”
Appendix 1, “Configuration Limits for Cisco Lists the maximum system management
NX-OS System Management” configuration limits.
16 OL-20635-03
Preface
Document Conventions
Command descriptions use these conventions:
Convention Description
boldface font Commands and keywords are in boldface.
italic font Arguments for which you supply values are in italics.
[ ] Elements in square brackets are optional.
[x|y|z] Optional alternative keywords are grouped in brackets and separated by vertical
bars.
string A nonquoted set of characters. Do not use quotation marks around the string or
the string will include the quotation marks.
Screen examples use these conventions:

screen font Terminal sessions and information that the switch displays are in screen font.
boldface screen Information that you must enter is in boldface screen font.
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.
Related Documentation
Cisco NX-OS includes the following documents:
Release Notes
Cisco Nexus 7000 Series NX-OS Release Notes, Release 5.x
OL-20635-03 17
Preface
Cisco NX-OS Configuration Guides
Configuring the Cisco Nexus 2000 Series Fabric Extender

Cisco Nexus 7000 Series NX-OS FabricPath Configuration Guide
Configuring Feature Set for FabricPath
Cisco NX-OS FCoE Configuration Guide for Cisco Nexus 7000 and Cisco MDS 9500
Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS High Availability and Redundancy Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS Layer 2 Switching Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS LISP Configuration Guide
Cisco Nexus 7000 Series NX-OS MPLS Configuration Guide
Cisco Nexus 7000 Series NX-OS Multicast Routing Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS OTV Configuration Guide
Cisco Nexus 7000 Series OTV Quick Start Guide
Cisco Nexus 7000 Series NX-OS Quality of Service Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x
Cisco Nexus 7000 Series NX-OS Virtual Device Context Quick Start, Release 5.x
Cisco NX-OS Command References
Cisco Nexus 7000 Series NX-OS Command Reference Master Index

Cisco Nexus 7000 Series NX-OS FabricPath Command Reference
Cisco NX-OS FCoE Command Reference for Cisco Nexus 7000 and Cisco MDS 9500
Cisco Nexus 7000 Series NX-OS Fundamentals Command Reference
Cisco Nexus 7000 Series NX-OS High Availability Command Reference
Cisco Nexus 7000 Series NX-OS Interfaces Command Reference
Cisco Nexus 7000 Series NX-OS Layer 2 Switching Command Reference
Cisco Nexus 7000 Series NX-OS LISP Command Reference
Cisco Nexus 7000 Series NX-OS MPLS Command Reference
Cisco Nexus 7000 Series NX-OS Multicast Routing Command Reference
Cisco Nexus 7000 Series NX-OS OTV Command Reference
Cisco Nexus 7000 Series NX-OS Quality of Service Command Reference
Cisco Nexus 7000 Series NX-OS SAN Switching Command Reference
Cisco Nexus 7000 Series NX-OS Security Command Reference
18 OL-20635-03
Preface
Cisco Nexus 7000 Series NX-OS System Management Command Reference

Cisco Nexus 7000 Series NX-OS Unicast Routing Command Reference
Cisco Nexus 7000 Series NX-OS Virtual Device Context Command Reference
Other Software Document
Cisco NX-OS Licensing Guide

Cisco Nexus 7000 Series NX-OS MIB Quick Reference
Cisco Nexus 7000 Series NX-OS Software Upgrade and Downgrade Guide, Release 5.x
Cisco NX-OS System Messages Reference
Cisco Nexus 7000 Series NX-OS Troubleshooting Guide
Cisco NX-OS XML Interface User Guide
Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional
information, see the monthly What’s New in Cisco Product Documentation, which also lists all new and
revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Subscribe to the What’s New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed
and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free
service and Cisco currently supports RSS Version 2.0.
OL-20635-03 19
Preface
20 OL-20635-03
CHAPTER 3
Overview
This chapter describes the system management features that you can use to monitor and manage Cisco
NX-OS devices.
• Cisco NX-OS Device Configuration Methods, page 3-22
• Cisco Fabric Services, page 3-23
• Network Time Protocol, page 3-23
• Precision Time Protocol, page 3-23
• Cisco Discovery Protocol, page 3-24
• System Messages, page 3-24
• Call Home, page 3-24
• Rollback, page 3-24
• Session Manager, page 3-24
• Scheduler, page 3-25
• SNMP, page 3-25
• RMON, page 3-25
• Online Diagnostics, page 3-25
• Embedded Event Manager, page 3-25
• On-Board Failure Logging, page 3-25
• SPAN, page 3-26
• ERSPAN, page 3-26
• LLDP, page 3-26
• NetFlow, page 3-26
• FabricPath, page 3-27
• Troubleshooting Features, page 3-27
OL-20635-03 3-21
Chapter 3 Overview
Cisco NX-OS Device Configuration Methods
Cisco NX-OS Device Configuration Methods

You can configure devices using direct network configuration methods or web services hosted on a Cisco
Data Center Network Management (Cisco DCNM) server.
Figure 3-1 shows the device configuration methods available to a network user.
Figure 3-1 Cisco NX-OS Device Configuration Methods
User PC
CLI
CLI DCNM Client
XML Management Interface
XML Management Custom GUI
SNMP Interface
XML Management
Interface
NX-OS Device DCNM Server
User configuration path
280156
DCNM server configuration path
Table 3-1 lists the configuration method and the document where you can find more information.
Table 3-1 Configuration Methods Book Links
Configuration Method Document

CLI from a Secure Shell (SSH) session, a Telnet Cisco Nexus 7000 Series NX-OS Fundamentals
session, or the console port Configuration Guide, Release 5.x
XML management interface Cisco NX-OS XML Interface User Guide
Cisco DCNM client Fundamentals Configuration Guide, Cisco
DCNM for LAN, Release 5.x
User-defined GUI Web Services API Guide, Cisco DCNM for LAN,
Release 5.x
This section includes the following topics:

• Configuring with CLI or XML Management Interface, page 3-23
• Configuring with Cisco DCNM or a Custom GUI, page 3-23
3-22 OL-20635-03
Chapter 3 Overview
Cisco Fabric Services
Configuring with CLI or XML Management Interface

You can configure Cisco NX-OS devices using the command-line interface (CLI) or the XML
management interface over Secure Shell (SSH) as follows:
• CLI from an SSH session, a Telnet session, or the console port—You can configure devices using
the CLI from an SSH session, a Telnet session, or the console port. SSH provides a secure
connection to the device. For more information, see the Cisco Nexus 7000 Series NX-OS
Fundamentals Configuration Guide, Release 5.x.
• XML management interface over SSH—You can configure devices using the XML management
interface, which is a programmatic method based on the NETCONF protocol that complements the
CLI functionality. For more information, see the Cisco NX-OS XML Interface User Guide.
Configuring with Cisco DCNM or a Custom GUI

You can configure Cisco NX-OS devices using the Cisco DCNM client or from your own GUI as
follows:
• Cisco DCNM Client—You can configure devices using the Cisco DCNM client, which runs on your
local PC and uses web services on the Cisco DCNM server. The Cisco DCNM server configures the
device over the XML management interface. For more information about the Cisco DCNM client,
see the Fundamentals Configuration Guide, Cisco DCNM for LAN, Release 5.x .
• Custom GUI—You can create your own GUI to configure devices using the Cisco DCNM web
services application program interface (API) on the Cisco DCNM server. You use the SOAP
protocol to exchange XML-based configuration messages with the Cisco DCNM server. The Cisco
DCNM server configures the device over the XML management interface. For more information
about creating custom GUIs, see the Web Services API Guide, Cisco DCNM for LAN, Release 5.x.
Cisco Fabric Services

Cisco Fabric Services (CFS) is a Cisco proprietary feature that distributes data, including configuration
changes, to all Cisco NX-OS devices in a network. For more information about CFS, see Chapter 1,
“Configuring CFS.”
Network Time Protocol

The Network Time Protocol (NTP) synchronizes the time of day among a set of distributed time servers
and clients so that you can correlate time-specific information, such as system logs, received from the
devices in your network. For more information about NTP, see Chapter 1, “Configuring NTP.”
Precision Time Protocol

The Precision Time Protocol (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 Network Time Protocol (NTP). For more information about PTP, see Chapter 1,
“Configuring PTP.”
OL-20635-03 3-23
Chapter 3 Overview
Cisco Discovery Protocol
Cisco Discovery Protocol

You can use the Cisco Discovery Protocol (CDP) to discover and view information about all Cisco
equipment that is directly attached to your device. CDP runs on all Cisco-manufactured equipment
including routers, bridges, access and communication servers, and switches. CDP is media and protocol
independent, and gathers the protocol addresses of neighboring devices, discovering the platform of
those devices. CDP runs over the data link layer only. Two systems that support different Layer 3
protocols can learn about each other. For more information about CDP, see Chapter 1, “Configuring
CDP.”
System Messages
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. For
information about configuring system messages, see Chapter 1, “Configuring System Message
Logging.”
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. For information about configuring Call Home, see Chapter 1,
“Configuring Smart Call Home.”
Rollback
The rollback feature allows you to take a snapshot, or checkpoint, of the device configuration and then
reapply that configuration at any point without having to reload. Rollback allows any authorized
administrator to apply this checkpoint configuration without requiring expert knowledge of the features
configured in the checkpoint.
Session Manager allows you to create a configuration session and apply all commands within that
session atomically. For more information, see the Chapter 1, “Configuring Rollback.”
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. For more information, see Chapter 1,
“Configuring Session Manager.”
3-24 OL-20635-03
Chapter 3 Overview
Scheduler
Scheduler
The scheduler allows you to create and manage jobs such as routinely backing up data or making QoS
policy changes. The scheduler can start a job according to your needs—only once at a specified time or
at periodic intervals. For more information, see Chapter 1, “Configuring the Scheduler.”
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. For more information, see Chapter 1, “Configuring SNMP.”
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. For more information, see
Chapter 1, “Configuring RMON.”
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. For information about configuring
online diagnostics, see Chapter 1, “Configuring Online Diagnostics.”
Embedded Event Manager

The Embedded Event Manager (EEM) allows you to detect and handle critical events in the system. EEM
provides event detection and recovery, including monitoring of events either as they occur or as
thresholds are crossed. For information about configuring EEM, see Chapter 1, “Configuring the
Embedded Event Manager.”
On-Board Failure Logging

You can configure a device to log failure data to persistent storage, which you can retrieve and display
for analysis at a later time. This on-board failure logging (OBFL) feature stores failure and
environmental information in nonvolatile memory on the module. This information is useful for analysis
of failed modules. For information about configuring OBFL, see Chapter 1, “Configuring Onboard
Failure Logging.”
OL-20635-03 3-25
Chapter 3 Overview
SPAN
SPAN
You can configure an Ethernet switched port analyzer (SPAN) to monitor traffic in and out of your
device. The SPAN features allow you to duplicate packets from source ports to destination ports. For
information about configuring SPAN, see Chapter 1, “Configuring SPAN.”
ERSPAN
Encapsulated remote switched port analyzer (ERSPAN) is used to transport mirrored traffic in an IP
network. ERSPAN supports source ports, source VLANs, and destinations on different switches, which
provide remote monitoring of multiple switches across your network. ERSPAN uses a generic routing
encapsulation (GRE) tunnel to carry traffic between switches.
ERSPAN consists of an ERSPAN source session, routable ERSPAN GRE-encapsulated traffic, and an
ERSPAN destination session. You separately configure ERSPAN source sessions and destination
sessions on different switches.
To configure an ERSPAN source session on one switch, you associate a set of source ports or VLANs
with a destination IP address, ERSPAN ID number, and virtual routing and forwarding (VRF) name. To
configure an ERSPAN destination session on another switch, you associate the destinations with the
source IP address, the ERSPAN ID number, and a VRF name.
The ERSPAN source session copies traffic from the source ports or source VLANs and forwards the
traffic using routable GRE-encapsulated packets to the ERSPAN destination session. The ERSPAN
destination session switches the traffic to the destinations. For information about configuring ERSPAN,
see Chapter 1, “Configuring ERSPAN.”
LLDP
Link Layer Discovery Protocol (LLDP) is a vendor-neutral, one-way device discovery protocol that
allows network devices to advertise information about themselves to other devices on the network. This
protocol runs over the data-link layer, which allows two systems running different network layer
protocols to learn about each other. You can enable LLDP globally or per interface. For information
about configuring LLDP, see Chapter 1, “Configuring LLDP.”
NetFlow
NetFlow allows you to identify packet flows for both ingress and egress IP packets and provide statistics
based on these packet flows. NetFlow does not require any change to either the packets themselves or to
any networking device. For information about configuring NetFlow, see Chapter 1, “Configuring
NetFlow.”
3-26 OL-20635-03
Chapter 3 Overview
FabricPath
FabricPath
FabricPath brings the benefits of Layer 3 routing to Layer 2 switched networks to build a highly resilient
and scalable Layer 2 fabric. The system manager is responsible for starting the FabricPath resources
process and monitoring its heartbeats. For information about configuring FabricPath, see the Cisco
Nexus 7000 Series NX-OS FabricPath Configuration Guide.
Troubleshooting Features
Cisco NX-OS provides troubleshooting tools such as ping, traceroute, Ethanalyzer, and the Blue Beacon
feature. See the Cisco Nexus 7000 Series NX-OS Troubleshooting Guide for details on these features.
When a service fails, the system generates information that can be used to determine the cause of the
failure. The following sources of information are available:
• Every service restart generates a syslog message of level LOG_ERR.
• If the Smart Call Home service is enabled, every service restart generates a Smart Call Home event.
• If SNMP traps are enabled, the SNMP agent sends a trap when a service is restarted.
• When a service failure occurs on a local module, you can view a log of the event by entering the
show processes log command in that module. The process logs are persistent across supervisor
switchovers and resets.
• When a service fails, a system core image file is generated. You can view recent core images by
entering the show cores command on the active supervisor. Core files are not persistent across
supervisor switchovers and resets, but you can configure the system to export core files to an
external server using a file transfer utility such as Trivial File Transfer Protocol (TFTP) by entering
the system cores command.
• CISCO-SYSTEM-MIB contains a table for cores (cseSwCoresTable).
For information on collecting and using the generated information relating to service failures, see the
Cisco Nexus 7000 Series NX-OS Troubleshooting Guide.
OL-20635-03 3-27
Chapter 3 Overview
Troubleshooting Features
3-28 OL-20635-03
CHAPTER 4
Configuring CFS
This chapter describes how to use Cisco Fabric Services (CFS), a Cisco proprietary feature that
distributes data, including configuration changes, to all Cisco NX-OS devices in a network.
• Information About CFS, page 4-29
• Licensing Requirements for CFS, page 4-33
• Prerequisites for CFS, page 4-33
• Guidelines and Limitations, page 4-33
• Default Settings, page 4-34
• Configuring CFS Distribution, page 4-34
• Verifying the CFS Configuration, page 4-60
• Additional References, page 4-60
• Feature History for CFS, page 4-62
Information About CFS

You can use CFS to distribute and synchronize a configuration on one Cisco device or with all other
Cisco devices in your network. CFS provides you with consistent and, in most cases, identical
configurations and behavior in your network.
• Applications that Use CFS to Distribute Configuration Changes, page 4-30
• CFS Distribution, page 4-30
• CFS Connectivity in a Mixed Fabric, page 4-31
• CFS Merge Support, page 4-32
• Locking the Network, page 4-32
• CFS Regions, page 4-32
• High Availability, page 4-33
• Virtualization Support, page 4-33
OL-20635-03 4-29
Chapter 4 Configuring CFS
Applications that Use CFS to Distribute Configuration Changes

CFS distributes configuration changes for the applications shown in Table 4-1.
Table 4-1 CFS-Supported Applications
Application Default State

Call Home Disabled
Device alias Enabled
DPVM Enabled
FC domain Disabled
FC port security Disabled
FC timer Disabled
IVR Disabled
NTP Disabled
RADIUS Disabled
RSCN Disabled
TACACS+ Disabled
User roles Disabled
CFS Distribution
CFS distributes configuration changes to multiple devices across a complete network. CFS supports the
following types of distribution:
• CFS over Ethernet (CFSoE)—Distributes application data over an Ethernet network.
• CFS over IP (CFSoIP)—Distributes application data over an IPv4 network.
• CFS over Fibre Channel (CFSoFC)—Distributes application data over a Fibre Channel, such as a
virtual storage area network (VSAN). If the device is provisioned with Fibre Channel ports, CFSoFC
is enabled by default.
Beginning with Cisco NX-OS Release 5.2, you can configure Fibre Channel over Ethernet (FCoE),
which allows Fibre Channel traffic to be encapsulated over a physical Ethernet link. To run FCoE
on a Cisco Nexus 7000 Series switch, you must configure a dedicated storage virtual device context
(VDC). If FCoE is enabled on the device, CFSoFC services can be used. The applications that
require CFS distribution to be enabled in the storage VDC are noted in the configuration instructions
throughout this chapter. For more information on FCoE and storage VDCs, see the Cisco NX-OS
FCoE Configuration Guide for Cisco Nexus 7000 and Cisco MDS 9500 and the Cisco Nexus 7000
Series NX-OS Virtual Device Context Configuration Guide, Release 5.x.
Note All of the information in this chapter applies to both CFSoIP and CFSoFC, unless otherwise noted.
4-30 OL-20635-03
CFS Distribution Modes

CFS supports three distribution modes to accommodate different feature requirements. Only one mode
is allowed at a given time.
• Uncoordinated distributions—Distribute information that is not expected to conflict with that from
a peer. Parallel uncoordinated distributions are allowed for an application.
• Coordinated distributions—Distribute information that can be manipulated and distributed from
multiple devices (for example, the port security configuration). Coordinated distributions allow only
one application distribution at a given time. CFS uses locks to enforce this. A coordinated
distribution is not allowed to start if locks are acquired for the application anywhere in the network.
A coordinated distribution consists of three stages:
– A network lock is acquired.
– The configuration is distributed and committed.
– The network lock is released.
CFS can execute these stages in response to an application request without intervention from the
application or under complete control of the application.
• Unrestricted uncoordinated distributions—Allow multiple parallel distributions in the network in the
presence of an existing coordinated distribution. Unrestricted uncoordinated distributions are allowed to
run in parallel with all other types of distributions.
CFS Connectivity in a Mixed Fabric

CFS is an infrastructure component that also runs on the Cisco Nexus 5000 Series switches and the Cisco
MDS 9000 switches. A mixed fabric of different platforms (such as the Cisco Nexus 7000 Series, Cisco
Nexus 5000 Series, and Cisco MDS 9000 switches) can interact with each other.
Using CFSoIP and CFSoFC, the respective CFS clients can also talk to their instances running on the
other platforms. Within a defined domain and distribution scope, CFS can distribute the client’s data and
configuration to its peers running on other platforms.
All three platforms support both CFSoIP and CFSoFC. However, the Cisco Nexus 7000 Series and Cisco
Nexus 5000 Series switches require an FC or FCoE plugin and corresponding configuration in order for
CFSoFC to operate. Both options are available by default on the Cisco MDS 9000 switches.
Note Some applications are not compatible with their instances running on different platforms. Therefore,
Cisco recommends that you carefully read the client guidelines for CFS distribution before committing
the configuration.
For more information on CFS for the Cisco Nexus 5000 Series and Cisco MDS 9000 switches, see the
Cisco Nexus 5000 Series NX-OS System Management Configuration Guide and the Cisco MDS 9000
Family NX-OS System Management Configuration Guide, respectively.
OL-20635-03 4-31
CFS Merge Support

An application keeps the configuration synchronized in the fabric through CFS. When two such fabrics
become reachable to one another, CFS triggers a merge. These two fabrics could have two different sets
of configuration information that need to be reconciled in the event of a merge. CFS provides notification
each time an application peer comes online. If a fabric with M application peers merges with another
fabric with N application peers and if an application triggers a merge action on every notification, a
link-up event results in MxN merges in the fabric.
CFS supports a protocol that reduces the number of merges required to one by handling the complexity
of the merge at the CFS layer. This protocol runs per application per scope. The protocol involves
selecting one device in a fabric as the merge manager for that fabric. The other devices do not have a
role in the merge process.
During a merger of two networks, their designated managers exchange configuration databases. The
application on one of them merges the databases, decides if the merge is successful, and notifies all other
devices.
In the merge is successful, the merged database is distributed to all devices in the combined fabric, and
the entire new fabric remains in a consistent state.
Locking the Network

When you configure an application that uses the CFS infrastructure, that application starts a CFS session
and locks the network. When a network is locked, the device software allows configuration changes to
this application only from the device holding the lock. If you make configuration changes to the
application from another device, the device issues a message to inform the user about the locked status.
The configuration changes are held in a pending database by that application.
If you start a CFS session that requires a network lock but forget to end the session, an administrator can
clear the session. If you lock a network at any time, your user name is remembered across restarts and
switchovers. If another user (on the same machine) tries to perform configuration tasks, that user’s
attempts are rejected.
CFS Regions
A CFS region is a user-defined subset of devices for a given feature or application. You usually define
regions to localize or restrict distribution based on devices that are close to one another. When a network
covers many geographies with many different administrators who are responsible for subsets of devices,
you can manage the scope of an application by setting up a CFS region.
CFS regions are identified by numbers ranging from 0 through 200. Region 0 is reserved as the default
region and contains every device in the network. You can configure regions from 1 through 200.
Note If an application is moved (that is, assigned to a new region), its scope is restricted to that region, and it
ignores all other regions for distribution or merging purposes. The assignment of the region to an
application has precedence in distribution over its initial scope.
You can configure a CFS region to distribute configurations for multiple applications. However, on a
given device, you can configure only one CFS region at a time to distribute the configuration for a given
application. Once you assign an application to a CFS region, its configuration cannot be distributed
within another CFS region.
4-32 OL-20635-03
Licensing Requirements for CFS
High Availability
Stateless restarts are supported for CFS. After a reboot or a supervisor switchover, the running
configuration is applied. For more information on high availability, see the Cisco Nexus 7000 Series
NX-OS High Availability and Redundancy Guide, Release 5.x.
Virtualization Support
CFS is configured per VDC. When you access Cisco NX-OS, it places you in the default VDC unless
you specify a different VDC. For more information on VDCs, see the Cisco Nexus 7000 Series NX-OS
Virtual Device Context Configuration Guide, Release 5.x.
Licensing Requirements for CFS

Product License Requirement
Cisco NX-OS CFS 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.
Prerequisites for CFS

CFS has the following prerequisites:
• CFS is enabled by default. All devices in the fabric must have CFS enabled, or they do not receive
distributions.
• If CFS is disabled for an application, that application does not distribute any configuration, and it
does not accept a distribution from other devices in the fabric.
Guidelines and Limitations

CFS has the following configuration guidelines and limitations:
• If the virtual port channel (vPC) feature is enabled for your device, do not disable CFSoE.
Note CFSoE must be enabled for the vPC feature to work.
• All CFSoIP-enabled devices with similar multicast addresses form one CFSoIP fabric.
• Make sure that CFS is enabled for the applications that you want to configure. For detailed
information, see the “Enabling CFS Distribution for Applications” procedure on page 4-35.
• Anytime you lock a fabric, your username is remembered across restarts and switchovers.
• Anytime you lock a fabric, configuration changes attempted by anyone else are rejected.
OL-20635-03 4-33
Default Settings
• While a fabric is locked, the application holds a working copy of configuration changes in a pending
database or temporary storage area—not in the running configuration.
• Configuration changes that have not been committed yet (still saved as a working copy) are not in
the running configuration and do not display in the output of show commands.
• If you start a CFS session that requires a fabric lock but forget to end the session, an administrator
can clear the session. For more information, see the “Clearing a Locked Session” procedure on
page 4-57.
• An empty commit is allowed if configuration changes are not previously made. In this case, the
commit command results in a session that acquires locks and distributes the current database.
• You can only use the commit command on the specific device where the fabric lock was acquired.
• CFSoIP and CFSoE are not supported for use together.
• CFS regions can be applied only to CFSoIP and CFSoFC applications.
• You cannot distribute the user role configuration between a Cisco MDS 9500 Series switch and the
storage VDC configured for a Cisco Nexus 7000 Series switch. To prevent this distribution, make
sure to assign the user role configuration in Cisco MDS and the Cisco Nexus 7000 storage VDC to
different CFS regions.
Default Settings
Table 4-2 lists the default settings for CFS parameters.
Table 4-2 Default CFS Parameters
Parameters Default
CFS distribution on the device Enabled
CFSoIP Disabled
IPv4 multicast address 239.255.70.83
CFSoFC Enabled, if FCoE is present
CFSoE Disabled
Configuring CFS Distribution

This section describes how to configure CFS and includes the following topics:
• Enabling CFS Distribution for Applications, page 4-35
• Specifying a CFS Distribution Mode, page 4-47
• Configuring an IP Multicast Address for CFSoIP, page 4-48
• Configuring CFS Regions, page 4-50
• Creating and Distributing a CFS Configuration, page 4-55
• Clearing a Locked Session, page 4-57
• Discarding a Configuration, page 4-58
• Disabling CFS Distribution Globally, page 4-59
4-34 OL-20635-03
Enabling CFS Distribution for Applications

• Enabling CFS to Distribute Call Home Configurations, page 4-35
• Enabling CFS to Distribute Device Alias Configurations, page 4-36
• Enabling CFS to Distribute DPVM Configurations, page 4-37
• Enabling CFS to Distribute FC Domain Configurations, page 4-38
• Enabling CFS to Distribute FC Port Security Configurations, page 4-39
• Enabling CFS to Distribute FC Timer Configurations, page 4-40
• Enabling CFS to Distribute IVR Configurations, page 4-41
• Enabling CFS to Distribute NTP Configurations, page 4-42
• Enabling CFS to Distribute RADIUS Configurations, page 4-43
• Enabling CFS to Distribute RSCN Configurations, page 4-44
• Enabling CFS to Distribute TACACS+ Configurations, page 4-45
• Enabling CFS to Distribute User Role Configurations, page 4-46
Note See Chapter 1, “Configuring Smart Call Home” for more information on Call Home, and see Chapter 1,
“Configuring NTP” for more information on NTP. See the Cisco Nexus 7000 Series NX-OS Security
Configuration Guide, Release 5.x for more information on CFS for RADIUS, TACACS+, and user roles.
See the Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide for more information on
device alias, DPVM, FC domain, FC port security, FC timer, IVR, and RSCN.
Enabling CFS to Distribute Call Home Configurations

You can enable CFS to distribute Call Home configurations to all Cisco NX-OS devices in the network.
The entire Call Home configuration is distributed except the device priority and the sysContact names.
BEFORE YOU BEGIN
Make sure that you are in the correct VDC. To change the VDC, use the switchto vdc command.
SUMMARY STEPS
1. config t
2. callhome
3. distribute
4. (Optional) show application-name status
5. (Optional) copy running-config startup-config
OL-20635-03 4-35
DETAILED STEPS
Command Purpose
Step 1 config t Places you in global configuration mode.
Example:
switch# config t
Enter configuration commands, one per
line. End with CNTL/Z.
switch(config)#
Step 2 callhome Places you in callhome configuration mode.
Example:
switch(config)# callhome
switch(config-callhome)#
Step 3 distribute Enables CFS to distribute Call Home configuration
updates.
Example:
switch(config-callhome)# distribute
Step 4 show application-name status (Optional) For the specified application, displays the
CFS distribution status.
Example:
switch(config-callhome)# show callhome
status
Step 5 copy running-config startup-config (Optional) Saves the change persistently through
reboots and restarts by copying the running
Example:
switch(config-callhome)# copy
configuration to the startup configuration.
running-config startup-config
This example shows how to enable CFS to distribute Call Home configurations:
switch(config-callhome)# distribute
switch(config-callhome)# show callhome status
Distribution : Enabled
switch(config-callhome)# copy running-config startup-config
[########################################] 100%
Enabling CFS to Distribute Device Alias Configurations

You can enable CFS to distribute device alias configurations in order to consistently administer and
maintain the device alias database across all Cisco NX-OS devices in the fabric.
BEFORE YOU BEGIN
Make sure that you are in the storage VDC. To change to the storage VDC, use the switchto vdc fcoe
command.
SUMMARY STEPS
1. config t
2. device-alias distribute
4-36 OL-20635-03
3. (Optional) show cfs application

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 device-alias distribute Enables CFS to distribute device alias configuration
updates.
Example:
switch(config)# device-alias distribute
Step 3 show cfs application (Optional) Displays the CFS distribution status.
Example:
switch(config)# show cfs application
Example:
switch(config)# copy running-config
startup-config
This example shows how to enable CFS to distribute device alias configurations:
switch(config)# device-alias distribute
----------------------------------------------
Application Enabled Scope
----------------------------------------------
device-alias Yes Physical-fc
switch(config)# copy running-config startup-config
[########################################] 100%
Enabling CFS to Distribute DPVM Configurations

You can enable CFS to distribute dynamic port VSAN membership (DPVM) configurations in order to
consistently administer and maintain the DPVM database across all Cisco NX-OS devices in the fabric.
BEFORE YOU BEGIN
command.
Make sure that you enable the DPVM feature. To do so, use the feature dpvm command.
SUMMARY STEPS
1. config t
2. dpvm distribute
OL-20635-03 4-37

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 dpvm distribute Enables CFS to distribute DPVM configuration
updates.
Example:
switch(config)# dpvm distribute
Example:
switch(config)# show dpvm status
Example:
startup-config
This example shows how to enable CFS to distribute DPVM configurations:

switch(config)# dpvm distribute
switch(config)# show dpvm status
Distribution is enabled.
[########################################] 100%
Enabling CFS to Distribute FC Domain Configurations

You can enable CFS to distribute Fibre Channel (FC) domain configurations in order to synchronize the
configuration across the fabric from the console of a single Cisco NX-OS device and to ensure
consistency in the allowed domain ID lists on all devices in the VSAN.
BEFORE YOU BEGIN
command.
SUMMARY STEPS
1. config t
2. fcdomain distribute
4-38 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 fcdomain distribute Enables CFS to distribute FC domain configuration
updates.
Example:
switch(config)# fcdomain distribute
Example:
switch(config)# show fcdomain status
Example:
startup-config
This example shows how to enable CFS to distribute FC domain configurations:

switch(config)# fcdomain distribute
switch(config)# show fcdomain status
fcdomain distribution is enabled
[########################################] 100%
Enabling CFS to Distribute FC Port Security Configurations

You can enable CFS to distribute Fibre Channel (FC) port security configurations in order to provide a
single point of configuration for the entire fabric in the VSAN and to enforce the port security policies
throughout the fabric.
BEFORE YOU BEGIN
command.
Make sure that you enable the FC port security feature. To do so, use the feature fc-port-security
command.
SUMMARY STEPS
1. config t
2. fc-port-security distribute
OL-20635-03 4-39
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 fc-port-security distribute Enables CFS to distribute FC port security
configuration updates.
Example:
switch(config)# fc-port-security
distribute
Example:
Example:
startup-config
This example shows how to enable CFS to distribute FC port security configurations:
switch(config)# fc-port-security distribute
----------------------------------------------
----------------------------------------------
fc-port-securi Yes Logical
[########################################] 100%
Enabling CFS to Distribute FC Timer Configurations

You can enable CFS to distribute Fibre Channel (FC) timer configurations for all Cisco NX-OS devices
in the fabric.
BEFORE YOU BEGIN
command.
SUMMARY STEPS
1. config t
2. fctimer distribute
4-40 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 fctimer distribute Enables CFS to distribute FC timer configuration
updates.
Example:
switch(config)# fctimer distribute
Example:
switch(config)# show fctimer status
Example:
startup-config
This example shows how to enable CFS to distribute FC timer configurations:

switch(config)# fctimer distribute
switch(config)# show fctimer status
[########################################] 100%
Enabling CFS to Distribute IVR Configurations

You can enable CFS to distribute inter-VSAN routing (IVR) configurations in order to enable efficient
IVR configuration management and to provide a single point of configuration for the entire fabric in the
VSAN.
BEFORE YOU BEGIN
command.
Make sure that you install the Advanced SAN Services license.
Make sure that you enable the IVR feature. To do so, use the feature ivr command.
SUMMARY STEPS
1. config t
2. ivr distribute
OL-20635-03 4-41
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 ivr distribute Enables CFS to distribute IVR configuration updates.
Example: Note You must enable IVR distribution on all
switch(config)# ivr distribute IVR-enabled switches in the fabric.
Example:
Example:
startup-config
This example shows how to enable CFS to distribute IVR configurations:

switch(config)# ivr distribute
----------------------------------------------
----------------------------------------------
ivr Yes Physical-fc
[########################################] 100%
Enabling CFS to Distribute NTP Configurations

You can enable CFS to distribute NTP configurations to all Cisco NX-OS devices in the network.
BEFORE YOU BEGIN
Make sure that you enable the NTP feature. To enable NTP in a Cisco NX-OS Release prior to 5.2, use
the ntp enable command. To enable NTP in Cisco NX-OS Release 5.2 or a later release, use the feature
ntp command.
SUMMARY STEPS
1. config t
2. ntp distribute
4-42 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 ntp distribute Enables CFS to distribute NTP configuration updates.
Example:
switch(config)# ntp distribute
Example:
switch(config)# show ntp status
Example:
startup-config
This example shows how to enable CFS to distribute NTP configurations:

[########################################] 100%
Enabling CFS to Distribute RADIUS Configurations

You can enable CFS to distribute RADIUS configurations to all Cisco NX-OS devices in the network.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. radius distribute
OL-20635-03 4-43
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 radius distribute Enables CFS to distribute RADIUS configuration
updates.
Example:
switch(config)# radius distribute
Example:
switch(config)# show radius status
Example:
startup-config
This example shows how to enable CFS to distribute RADIUS configurations:

switch(config)# radius distribute
switch(config)# show radius status
[########################################] 100%
Enabling CFS to Distribute RSCN Configurations

You can enable CFS to distribute registered state change notification (RSCN) configurations to all Cisco
NX-OS devices in the fabric.
BEFORE YOU BEGIN
command.
SUMMARY STEPS
1. config t
2. rscn distribute
4-44 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 rscn distribute Enables CFS to distribute RSCN configuration
updates.
Example:
switch(config)# rscn distribute
Example:
Example:
startup-config
This example shows how to enable CFS to distribute RSCN configurations:

switch(config)# rscn distribute
----------------------------------------------
----------------------------------------------
rscn Yes Logical
[########################################] 100%
Enabling CFS to Distribute TACACS+ Configurations

You can enable CFS to distribute TACACS+ configurations to all Cisco NX-OS devices in the network.
BEFORE YOU BEGIN
Make sure that you enable the TACACS+ feature. To do so, use the feature tacacs+ command.
SUMMARY STEPS
1. config t
2. tacacs+ distribute
OL-20635-03 4-45
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 tacacs+ distribute Enables CFS to distribute configuration updates for
TACACS+.
Example:
switch(config)# tacacs+ distribute
Example:
switch(config)# show tacacs+ status
Example:
startup-config
This example shows how to enable CFS to distribute TACACS+ configurations:

switch(config)# tacacs+ distribute
switch(config)# show tacacs+ status
Last operational state: No session
[########################################] 100%
Enabling CFS to Distribute User Role Configurations

You can enable CFS to distribute user role configurations to all Cisco NX-OS devices in the network.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. role distribute
4-46 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 role distribute Enables CFS to distribute role configurations.
Example:
switch(config)# role distribute
Example:
switch(config)# show role status
Example:
startup-config
This example shows how to enable CFS to distribute role configurations:

switch(config)# role distribute
switch(config)# show role status
[########################################] 100%
Specifying a CFS Distribution Mode

You can specify and enable a CFS distribution mode (Ethernet or IPv4).
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. cfs {eth | ipv4} distribute
3. (Optional) show cfs status
OL-20635-03 4-47
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 cfs {eth | ipv4} distribute Globally enables CFS distribution over one of the
following for all applications on the device.
Example:
switch(config)# cfs ipv4 distribute • Ethernet
• IPv4
In this example, CFS distribution is enabled over
IPv4.
Step 3 show cfs status (Optional) Shows the current state of CFS including
the distribution mode.
Example:
switch(config)# show cfs status In this example, CFS is shown as being distributed
over IPv4.
Example:
startup-config
This example shows how to enable the Ethernet CFS distribution mode:
switch(config)# cfs eth distribute
switch(config)# show cfs status
Distribution over IP : Disabled
Distribution over Ethernet : Enabled
[########################################] 100%
Configuring an IP Multicast Address for CFSoIP

For CFS protocol-specific distributions, such as the keepalive mechanism for detecting network
topology changes, use the IP multicast address to send and receive information.
You can configure the IP multicast address used to distribute CFSoIPv4. The default IPv4 multicast
address is 239.255.70.83.
BEFORE YOU BEGIN
You must disable CFS IP distribution before changing the multicast address.
4-48 OL-20635-03
SUMMARY STEPS
1. config t
2. no cfs ipv4 distribute
3. cfs ipv4 mcast-address ip-address
4. cfs ipv4 distribute
DETAILED STEPS
Command Purpose
Example:
switch# config t
Enter configuration commands, one per line.
End with CNTL/Z.
switch(config)#
Step 2 no cfs ipv4 distribute Globally disables CFSoIP distribution for all
applications on the device.
Example:
switch(config)# no cfs ipv4 distribute Note CFSoIP must be disabled before you can
This will prevent CFS from distributing change the multicast address.
over IPv4 network.
Are you sure? (y/n) [n] y
Step 3 cfs ipv4 mcast-address ip-address Configures the multicast address for CFS
distribution over IPv4. The ranges of valid IPv4
Example:
switch(config)# cfs ipv4 mcast-address
addresses are 239.255.0.0 through
239.255.1.1 239.255.255.255 and 239.192/16 through
Distribution over this IP type will be 239.251/16. The default IPv4 address is
affected 239.255.70.83.
Change multicast address for CFS-IP ?
Step 4 cfs ipv4 distribute Globally enables CFSoIP distribution for all
Example:
switch(config)# cfs ipv4 distribute
Step 5 show cfs status (Optional) Shows the current state of CFS
including whether it is enabled, its IP mode, and
Example:
its multicast addresses.
In this example, CFS is shown as being distributed
over IPv4 on 239.255.1.1.
Example:
startup-config
OL-20635-03 4-49
This example shows how to configure the IP multicast address used to distribute CFSoIP for IPv4:
switch(config)# no cfs ipv4 distribute
switch(config)# cfs ipv4 mcast-address 239.255.1.1
switch(config)# cfs ipv4 distribute
Distribution over IP : Enabled - mode IPv4
IPv4 multicast address : 239.255.1.1
[########################################] 100%
Configuring CFS Regions

This section describes how to create and configure a CFS region and includes the following topics:
• Creating a CFS Region, page 4-50
• Moving an Application to a Different Region, page 4-51
• Removing an Application from a Region, page 4-53
• Deleting a CFS Region, page 4-54
Creating a CFS Region

You can create a CFS region and add an application, such as Call Home, to it.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. cfs region region-number
3. application-name
4. (Optional) show cfs regions brief
4-50 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 cfs region region-number Creates the region and places you into configuration
mode for the specified region.
Example:
switch(config)# cfs region 4 In this example, region 4 is created.
switch(config-cfs-region)#
Step 3 application-name For the specified region, adds the named application.
Example:
switch(config-cfs-region)# callhome
Step 4 show cfs regions brief (Optional) Shows all configured regions and
applications but does not show peers.
Example:
switch(config-cfs-region)# show cfs In this example, the Call Home application is shown
regions brief in region 4.
---------------------------------------
Region Application Enabled
---------------------------------------
4 callhome yes
Example:
startup-config
Moving an Application to a Different Region

You can move an application to a different region. For example, you can move NTP from region 1 to
region 2.
Note When an application is moved, its scope is restricted to the new region. It ignores all other regions for
distribution or merging purposes.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
3. application-name
OL-20635-03 4-51
4. (Optional) show cfs regions name application-name

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 cfs region region-number Places you in the configuration mode for the
target/destination region.
Example:
switch(config)# cfs region 2
Step 3 application-name Specifies applications to be moved.
Example: In this example, the Call Home and RADIUS
switch(config-cfs-region)# callhome applications are moved to region 2.
switch(config-cfs-region)# radius
Step 4 show cfs regions name application-name (Optional) Displays peers and region information for
a given application.
Example:
switch(config-cfs-region)# show cfs
regions name callhome
Example:
startup-config
This example shows how to move the Call Home application to CFS region 2:
switch# config t
switch(config-cfs-region)# callhome
switch(config-cfs-region)# show cfs regions name callhome
Region-ID : 2
Application: callhome
Scope : Physical-fc-ip
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:22:55:79:a4:c1 172.28.230.85 [Local]
switch
Total number of entries = 1
4-52 OL-20635-03
Removing an Application from a Region

You can remove an application from a region. Removing an application from a region is the same as
moving the application back to the default region. The default region is usually region 0. This action
brings the entire fabric into the scope of distribution for the application.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
3. no application-name
4. (Optional) Repeat Step 3 for each application that you want to remove from this region.
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 cfs region region-number Places you in the configuration mode for the specified
region.
Example:
Step 3 no application-name Removes the specified application from the region.
Example:
switch(config-cfs-region)# no ntp
Step 4 (Optional) Repeat Step 3 for each application —

that you want to remove from this region.
OL-20635-03 4-53
Command Purpose
Example:
switch(config-cfs-region)# show cfs
regions brief
---------------------------------------
---------------------------------------
4 tacacs+ yes
6 radius yes
Example:
startup-config
Deleting a CFS Region

You can delete a region and move all included applications back to the default region.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. no cfs region region-number
4. (Optional) show cfs application name application-name
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 no cfs region region-number Deletes the specified region after warning that this
action causes all applications in the region to move to
Example:
switch(config)# no cfs region 4
the default region.
WARNING: All applications in the region After deleting the region, you are returned to the
will be moved to default region.
global configuration mode.
Are you sure? (y/n) [n]
4-54 OL-20635-03
Command Purpose
Example:
switch(config)# show cfs regions brief In this example, region 4 is absent.
---------------------------------------
---------------------------------------
6 radius no
Step 4 show cfs application name (Optional) Shows local application information by
application-name name.
Example: In this case, the Call Home application is shown as
switch(config)# show cfs application now belonging to the default region.
name callhome
Enabled : Yes
Timeout : 20s
Merge Capable : Yes
Scope : Physical-fc-ip
Region : Default
Example:
startup-config
Creating and Distributing a CFS Configuration

You can create a configuration change for an application and then distribute it to its application peers.
Caution If you do not commit the changes, they are not distributed and saved in the running configuration of
application peer devices.
Caution If you do not save the changes to the startup configuration in every application peer device where
distributed, then changes are retained only in their running configurations.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. application-name
3. application-command
4. (Optional) Repeat Step 3 for each configuration command that you want to make.
OL-20635-03 4-55
6. commit
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 application-name Specifies that CFS starts a session for the specified
application name and locks the fabric.
Example:
Step 3 application-command Specifies that configuration changes are saved as a
working copy and are not saved in the running
Example:
switch(config-callhome)# email-contact
configuration until you enter the commit command.
[email protected]
Step 4 (Optional) Repeat Step 3 for each —
configuration command that you want to
make.
Example:
switch(config-callhome)# show callhome In this example, the output shows that distribution is
status enabled for Call Home.
Step 6 commit CFS distributes the configuration changes to the
running configuration of every application peer
Example:
switch(config-callhome)# commit
device.
If one or more external devices report a successful
status, the software overwrites the running
configuration with the changes from the CFS
working copy and releases the fabric lock.
If none of the external devices report a successful
status, no changes are made, and the fabric lock
remains in place.
Example:
configuration to the startup configuration in all
startup-config devices in the fabric.
4-56 OL-20635-03
This example shows how to configure and distribute the contact information for Call Home:
switch# config t
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)# snmp-server contact [email protected]
switch(config-callhome)# email-contact [email protected]
switch(config-callhome)# phone-contact +1-800-123-4567
switch(config-callhome)# street-address 123 Anystreet st. Anytown,AnyWhere
switch(config-callhome)# copy running-config startup-config
[######################################] 100%
Clearing a Locked Session

You can clear a lock held by an application from any device in the fabric.
You must have administrator permissions to release a lock.
Caution When you clear a lock in the fabric, any pending configurations in any device in the fabric are discarded.
BEFORE YOU BEGIN
SUMMARY STEPS

2. clear application-name session
DETAILED STEPS
Command Purpose
Step 1 show application-name status (Optional) Shows the current application state.
switch(config)# show ntp status In this example, NTP is shown as locked.
Last operational state: Fabric Locked
Step 2 clear application-name session Clears the application configuration session and
releases the lock on the fabric.
Example:
switch(config)# clear ntp session All pending changes are discarded.
Step 3 show application-name status (Optional) Shows the current application state.
Example: This example shows that the lock is removed from the
switch(config)# show ntp status NTP application.
Last operational state: No session
OL-20635-03 4-57
Discarding a Configuration
You can discard configuration changes and release the lock.
Caution If you discard configuration changes, the application flushes the pending database and releases locks in
the fabric.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
1. application-name abort
2. (Optional) show application-name session status
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 application-name abort Aborts the application configuration after
y requesting confirmation.
Example: In this case, the NTP configuration is aborted, the
switch(config)# ntp abort changes to the configuration are discarded, the
This will prevent CFS from distributing the
CFS session is closed, and the fabric lock is
configuration to other switches.
Are you sure? (y/n) [n] y released.
Note The abort command is supported only on
the device where the fabric lock is
acquired.
Step 3 show application-name session status (Optional) For the specified application, displays
the CFS session status.
Example:
switch(config)# show ntp session status In this example, the output shows that the CFS
Last Action Time Stamp : Wed Nov 12 session was aborted.
16:07:25 2010
Last Action : Abort
Last Action Result : Success
Last Action Failure Reason : none
4-58 OL-20635-03
Disabling CFS Distribution Globally

You can disable CFS distribution for a device, isolating the applications using CFS from fabric-wide
distributions while maintaining physical connectivity.
When CFS is globally disabled on a device, CFS operations are restricted to the device, and all CFS
commands continue to function as if the device was physically isolated.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. no cfs distribute
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 no cfs distribute Globally disables CFS distribution for all
Example:
switch(config)# no cfs distribute Note If the virtual port channel (vPC) feature is
This will prevent CFS from distributing the enabled, then only IP distribution is
configuration to other switches.
disabled. You must first disable vPC
switch(config)# before you can disable CFS distribution.
Step 3 show cfs status (Optional) Displays the global CFS distribution
status for the device.
Example:
Distribution over IP : Disabled
IPv4 multicast address : 239.255.70.83
Distribution over Ethernet : Disabled
Example:
startup-config
OL-20635-03 4-59
Verifying the CFS Configuration
Verifying the CFS Configuration

To display the CFS configuration information, perform one of the following tasks:
Command Purpose
show application-name session Displays the configuration session status, including the last
status action, the result, and the reason if there was a failure.
show application-name status For the specified application, displays the CFS distribution
status.
show cfs application Displays the applications that are currently CFS enabled.
show cfs application name Displays the details for a particular application, including the
application-name enabled or disabled state, timeout as registered with CFS,
merge capability if registered with CFS for merge support,
distribution scope, and distribution region.
show cfs internal Displays information internal to CFS including memory
statistics, event history, and so on.
show cfs lock Displays all active locks.
show cfs merge status name name Displays the merge status for a given application.
[detail]
show cfs peers Displays all the peers in the physical fabric.
show cfs regions Displays all the applications with peers and region
information.
show cfs status Displays the status of CFS distribution on the device as well
as IP distribution information.
show logging level cfs Displays the CFS logging configuration.
show tech-support cfs Displays information about the CFS configuration required by
technical support when resolving a CFS issue.
Additional References
For additional information, see the following sections:
• Related Documents, page 4-61
• MIBs, page 4-61
4-60 OL-20635-03
Related Documents
Related Topic Document Title
CFS CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Cisco Nexus 7000 Series NX-OS SAN Switching Command Reference
CFS configuration for Call Home Configuring Smart Call Home, page 1-1
CFS configuration for device alias Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for DPVM Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for FC domain Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for FC port security Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for FC timer Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for IVR Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for NTP Configuring NTP, page 1-1
CFS configuration for RADIUS Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release
5.x
CFS configuration for RSCN Cisco Nexus 7000 Series NX-OS SAN Switching Configuration Guide
CFS configuration for TACACS+ Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release
5.x
CFS configuration for roles Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release
5.x
FCoE Cisco NX-OS FCoE Configuration Guide for Cisco Nexus 7000 and
Cisco MDS 9500
VDCs and VRFs Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
Guide, Release 5.x
MIBs
MIBs MIBs Link
• CISCO-CFS-MIB Cisco NX-OS MIB Support
OL-20635-03 4-61
Feature History for CFS
Feature History for CFS

This section provides the CFS release history.
Feature Name Releases Feature Information

CFS protocol 5.2(1) Added CFS over Fibre Channel (CFSoFC) distribution
support for device alias, DPVM, FC domain, FC port
security, FC timer, IVR, and RSCN.
CFS protocol 5.1(1) No change from Release 5.0.
CFS protocol 4.1(2) This feature was introduced.
4-62 OL-20635-03
CHAPTER 5
Configuring NTP
This chapter describes how to configure the Network Time Protocol (NTP) on Cisco NX-OS devices.
• Information About NTP, page 5-63
• Licensing Requirements for NTP, page 5-65
• Prerequisites for NTP, page 5-65
• Configuring NTP, page 5-66
• Verifying the NTP Configuration, page 5-79
• Configuration Examples for NTP, page 5-80
• Feature History for NTP, page 5-82
Information About NTP

• NTP Overview, page 5-63
• NTP as Time Server, page 5-64
• Distributing NTP Using CFS, page 5-64
• Clock Manager, page 5-64
NTP Overview
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).
OL-20635-03 5-63
Chapter 5 Configuring NTP
Information About NTP
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 Time Server

Beginning with Cisco NX-OS Release 5.2, 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.
For more information about CFS, see the “Configuring CFS” section on page 4-29.
Clock Manager
Clocks are resources that need to be shared across different processes and across different VDCs.
Multiple time synchronization protocols, such as NTP and Precision Time Protocol (PTP), might be
running in the system, and multiple instances of the same protocol might be running in different VDCs.
Beginning with Cisco NX-OS Release 5.2, the clock manager allows you to specify the protocol and a
VDC running that protocol to control the various clocks in the system. Once you specify the protocol
and VDC, the system clock starts updating. For information on configuring the clock manager, see the
Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide, Release 5.x.
5-64 OL-20635-03
Licensing Requirements for NTP
High Availability
Stateless restarts are supported for NTP. After a reboot or a supervisor switchover, the running
You can configure NTP peers to provide redundancy in case an NTP server fails.
If you are running a Cisco NX-OS Release prior to 5.2, up to one instance of NTP is supported on the
entire platform. You must configure NTP in the default virtual device context (VDC), and you are
automatically placed in the default VDC unless you specify otherwise.
If you are running Cisco NX-OS Release 5.2 or later, multiple instances of NTP are supported, one
instance per VDC. By default, Cisco NX-OS places you in the default VDC unless you specifically
configure another VDC.
Only one VDC (the default VDC by default) synchronizes the system clock at any given time. The NTP
daemon in all other VDCs acts only as an NTP server for the other devices. To change which VDC
synchronizes the system clock, use the clock protocol ntp vdc vdc-id command.
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. See the Cisco Nexus 7000 Series NX-OS
Unicast Routing Configuration Guide, Release 5.x for more information about VRFs.
For more information about VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context
Configuration Guide, Release 5.x.
Licensing Requirements for NTP

Cisco NX-OS NTP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for NTP

NTP has the following prerequisites:
• To configure NTP, you must have connectivity to at least one server that is running NTP.
• To configure VDCs, you must install the Advanced Services license. See the Cisco Nexus 7000

NTP has the following configuration guidelines and limitations:
OL-20635-03 5-65
Default Settings
• NTP server functionality is supported starting in Cisco NX-OS Release 5.2.

• 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
Table 5-1 lists the default settings for NTP parameters.
Table 5-1 Default NTP Parameters
Parameters Default
NTP Enabled in all VDCs
NTP authentication Disabled
NTP access Enabled
NTP logging Disabled
Configuring NTP
• Enabling or Disabling NTP, page 5-67
• Configuring the Device as an Authoritative NTP Server, page 5-68
• Configuring an NTP Server and Peer, page 5-69
• Configuring NTP Authentication, page 5-72
• Configuring NTP Access Restrictions, page 5-73
5-66 OL-20635-03
Configuring NTP
• Configuring the NTP Source IP Address, page 5-75

• Configuring the NTP Source Interface, page 5-75
• Configuring NTP on a Secondary (Non-Default) VDC, page 5-75
• Configuring NTP Logging, page 5-76
• Enabling CFS Distribution for NTP, page 5-77
• Committing NTP Configuration Changes, page 5-78
• Discarding NTP Configuration Changes, page 5-79
• Releasing the CFS Session Lock, page 5-79
Note Be aware that the Cisco NX-OS commands for this feature may differ from those commands used in
Cisco IOS.
Enabling or Disabling NTP

You can enable or disable NTP in a particular VDC. NTP is enabled in all VDCs by default.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. [no] feature ntp
3. (Optional) show ntp status
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 [no] feature ntp Enables or disables NTP in a particular VDC. NTP is
enabled by default.
Example:
switch(config)# feature ntp Note If you are running a Cisco NX-OS Release
prior to 5.2, NTP is enabled or disabled using
the [no] ntp enable command.
OL-20635-03 5-67
Configuring NTP
Command Purpose
Step 3 show ntp status (Optional) Displays the status of the NTP application.
Example:
Distribution: Enabled
Last operational state: Fabric Locked
Example:
startup-config
This example shows how to disable NTP:

switch# config t
switch(config)# no feature ntp
Configuring the Device as an Authoritative NTP Server

You can configure the device to act as an authoritative NTP server, enabling it to distribute time even
when it is not synchronized to an existing time server.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. [no] ntp master [stratum]
3. (Optional) show running-config ntp
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 [no] ntp master [stratum] Configures the device as an authoritative NTP server.
Example: You can specify a different stratum level from which
switch(config)# ntp master NTP clients get their time synchronized. The range is
from 1 to 15.
5-68 OL-20635-03
Configuring NTP
Command Purpose
Step 3 show running-config ntp (Optional) Displays the NTP configuration.
Example:
switch(config)# show running-config ntp
Example:
startup-config
This example shows how to configure the Cisco NX-OS device as an authoritative NTP server with a
different stratum level:
switch# config t
switch(config)# ntp master 5
Configuring an 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 using the “Configuring CFS Distribution” section on page 4-34.
– Enabled CFS for NTP using the “Enabling CFS Distribution for NTP” section on page 5-77.
SUMMARY STEPS
1. config t
2. [no] ntp server {ip-address | ipv6-address | dns-name} [key key-id] [maxpoll max-poll] [minpoll
min-poll] [prefer] [use-vrf vrf-name]
3. [no] ntp peer {ip-address | ipv6-address | dns-name} [key key-id] [maxpoll max-poll] [minpoll
min-poll] [prefer] [use-vrf vrf-name]
4. (Optional) show ntp peers
OL-20635-03 5-69
Configuring NTP
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 [no] ntp server {ip-address | ipv6-address | Forms an association with a server.
dns-name} [key key-id] [maxpoll max-poll]
[minpoll min-poll] [prefer] [use-vrf Use the key keyword to configure a key to be
vrf-name] used while communicating with the NTP server.
The range for the key-id argument is from 1 to
Example:
65535.
switch(config)# ntp server 192.0.2.10
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. For more information
on trusted keys, see the “Configuring
NTP Authentication” section on
page 5-72.
5-70 OL-20635-03
Configuring NTP
Command Purpose
Step 3 [no] ntp peer {ip-address | ipv6-address | Forms an association with a peer. You can
dns-name} [key key-id] [maxpoll max-poll] specify multiple peer associations.
[minpoll min-poll] [prefer] [use-vrf
vrf-name] Use the key keyword to configure a key to be
used while communicating with the NTP peer.
Example:
The range for the key-id argument is from 1 to
switch(config)# ntp peer 2001:0db8::4101
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 17
seconds, and the default values are 6 and 4,
respectively.
Use the prefer keyword to make this the
preferred NTP peer for the device.
Use the use-vrf keyword to configure the NTP
peer to communicate over the specified VRF.
The vrf-name argument can be default,
management, or any case-sensitive
Step 4 show ntp peers (Optional) Displays the configured server and
peers.
Example:
switch(config)# show ntp peers Note A domain name is resolved only when
you have a DNS server configured.
Example:
startup-config
This example shows how to configure an NTP server and peer:

switch# config t
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)
[########################################] 100%
switch(config)#
OL-20635-03 5-71
Configuring NTP
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. See the “Configuring an NTP Server and Peer” section on page 5-69 for information.
SUMMARY STEPS
1. config t
2. [no] ntp authentication-key number md5 md5-string
3. (Optional) show ntp authentication-keys
4. [no] ntp trusted-key number
5. (Optional) show ntp trusted-keys
6. [no] ntp authenticate
7. (Optional) show ntp authentication-status
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 [no] ntp authentication-key number md5 Defines the authentication keys. The device does
md5-string not synchronize to a time source unless the
switch(config)# ntp authentication-key 42 md5
source has one of these authentication keys and
aNiceKey the key number is specified by the ntp
trusted-key number command.
The range for authentication keys is from 1 to
65535. Cisco NX-OS Release 5.2(3) and later
5.x releases support up to 15 alphanumeric
characters for the MD5 string. Earlier releases
support up to 8 alphanumeric characters.
5-72 OL-20635-03
Configuring NTP
Command Purpose
Step 3 show ntp authentication-keys (Optional) Displays the configured NTP
authentication keys.
Example:
switch(config)# show ntp authentication-keys
Step 4 [no] ntp trusted-key number Specifies one or more keys (defined in Step 2)
that a time source must provide in its NTP
Example:
switch(config)# ntp trusted-key 42
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 show ntp trusted-keys (Optional) Displays the configured NTP trusted
keys.
Example:
switch(config)# show ntp trusted-keys
Step 6 [no] ntp authenticate Enables or disables the NTP authentication
feature. NTP authentication is disabled by
Example:
switch(config)# ntp authenticate
default.
Step 7 show ntp authentication-status (Optional) Displays the status of NTP
authentication.
Example:
switch(config)# show ntp
authentication-status
Example:
startup-config
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
switch(config)# ntp authentication-key 42 md5 aNiceKey
[########################################] 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.
BEFORE YOU BEGIN
OL-20635-03 5-73
Configuring NTP
SUMMARY STEPS
1. config t
2. [no] ntp access-group {peer | serve | serve-only | query-only} access-list-name
3. (Optional) show ntp access-groups
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 [no] ntp access-group {peer | serve | Creates or removes an access group to control
serve-only | query-only} access-list-name NTP access and applies a basic IP access list.
Example: The access group options are scanned in the
switch(config)# ntp access-group peer following order, from least restrictive to most
accesslist1
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 show ntp access-groups (Optional) Displays the NTP access group
configuration.
Example:
switch(config)# show ntp access-groups
Example:
startup-config
5-74 OL-20635-03
Configuring NTP
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
[########################################] 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:
Command Purpose
[no] ntp source ip-address Configures the source IP address for all NTP
packets. The ip-address can be in IPv4 or IPv6
Example:
switch(config)# ntp source 192.0.2.1
format.
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:
Command Purpose
[no] ntp source-interface interface Configures the source interface for all NTP
packets. Use the ? keyword to display a list of
Example:
switch(config)# ntp source-interface
supported interfaces.
ethernet 2/1
Configuring NTP on a Secondary (Non-Default) VDC

You can configure a non-default VDC to get a timing update from the default VDC and its clients in order
to synchronize with it.
BEFORE YOU BEGIN
Use the switchto vdc command to switch to the desired non-default VDC.
OL-20635-03 5-75
Configuring NTP
SUMMARY STEPS
1. config t
2. feature ntp
3. ntp master
4. (Optional) ntp source-interface interface
5. (Optional) ntp source ip-address
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 feature ntp Enables NTP in the non-default VDC.
Example:
switch(config)# feature ntp
Step 3 ntp master Configures the device as an authoritative NTP
server.
Example:
switch(config)# ntp master
Step 4 ntp source-interface interface (Optional) Configures the source interface for all
NTP packets. Use the ? keyword to display a list
Example:
switch(config)# ntp source-interface ethernet
of supported interfaces.
2/1
Step 5 ntp source ip-address (Optional) Configures the source IP address for
all NTP packets. The ip-address can be in IPv4
Example:
switch(config)# ntp source 192.0.2.1
or IPv6 format.
Example:
startup-config
Configuring NTP Logging

You can configure NTP logging in order to generate system logs with significant NTP events. NTP
logging is disabled by default.
BEFORE YOU BEGIN
5-76 OL-20635-03
Configuring NTP
SUMMARY STEPS
1. config t
2. [no] ntp logging
3. (Optional) show ntp logging-status
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 [no] ntp logging Enables or disables system logs to be generated
with significant NTP events. NTP logging is
Example:
switch(config)# ntp logging
disabled by default.
Step 3 show ntp logging-status (Optional) Displays the NTP logging
configuration status.
Example:
switch(config)# show ntp logging-status
Example:
startup-config
This example shows how to enable NTP logging in order to generate system logs with significant NTP
events:
switch# config t
[########################################] 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 using the “Configuring CFS
Distribution” section on page 4-34.
OL-20635-03 5-77
Configuring NTP
SUMMARY STEPS
1. config t
2. [no] ntp distribute
3. (Optional) show ntp status
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 [no] ntp distribute Enables or disables the device to receive NTP
configuration updates that are distributed through
Example:
CFS.
Step 3 show ntp status (Optional) Displays the NTP CFS distribution status.
Example:
Example:
startup-config
Committing 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.
To commit the NTP configuration changes, use the following command in global configuration mode:
Command Purpose
ntp commit Distributes the NTP configuration changes to all
Cisco NX-OS devices in the network and releases
Example:
switch(config)# ntp commit
the CFS lock. This command overwrites the
effective database with the changes made to the
pending database.
5-78 OL-20635-03
Verifying the NTP Configuration
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:
Command Purpose
ntp abort Discards the NTP configuration changes in the
pending database and releases the CFS lock. Use
Example:
switch(config)# ntp abort
this command on the device where you started the
NTP configuration.
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:
Command Purpose
clear ntp session Discards the NTP configuration changes in the
pending database and releases the CFS lock.
Example:
switch(config)# clear ntp session
Verifying the NTP Configuration

To display the NTP configuration, perform one of the following tasks:
Command Purpose
show ntp access-groups Displays the NTP access group configuration.
show ntp authentication-keys Displays the configured NTP authentication keys.
show ntp authentication-status Displays the status of NTP authentication.
show ntp internal Displays internal NTP information.
show ntp logging-status Displays the NTP logging status.
show ntp peer-status Displays the status for all NTP servers and peers.
show ntp peers Displays all the NTP peers.
show ntp pending Displays the temporary CFS database for NTP.
show ntp pending-diff Displays the difference between the pending CFS
database and the current NTP configuration.
OL-20635-03 5-79
Configuration Examples for NTP
Command Purpose
show ntp rts-update Displays the RTS update status.
show ntp session status Displays the NTP CFS distribution session
information.
show ntp source Displays the configured NTP source IP address.
show ntp source-interface Displays the configured NTP source interface.
show ntp statistics {io | local | memory | peer Displays the NTP statistics.
{ipaddr {ipv4-addr | ipv6-addr} | name
peer-name}}
show ntp status Displays the NTP CFS distribution status.
show ntp trusted-keys Displays the configured NTP trusted keys.
show running-config ntp Displays NTP information.
Use the clear ntp session command to clear the NTP sessions.
Use the clear ntp statistics command to clear the NTP statistics.
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 t
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)# show ntp trusted-keys
Trusted Keys:
42
switch(config)# show ntp authentication-status
Authentication enabled.
switch(config)# show ntp logging
NTP logging enabled.
[########################################] 100%
switch(config)#
5-80 OL-20635-03
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 t
switch(config)# ntp peer 10.1.1.1
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)# ip access-list serve-acl

switch(config)# ip access-list serve-only-acl

switch(config)# ip access-list query-only-acl

For additional information related to implementing NTP, see the following sections:
• MIBs, page 5-82
OL-20635-03 5-81
Feature History for NTP
Related Documents
NTP CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Clock manager Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide,
Release 5.x
VDCs and VRFs Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
Guide, Release 5.x
MIBs
MIBs MIBs Link
• CISCO-NTP-MIB To locate and download MIBs, go to the following URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Table 5-2 lists the release history for this feature.
Table 5-2 Feature History for NTP

NTP 5.2(3) Increased the length of NTP authentication keys from 8 to
15 alphanumeric characters.
NTP 5.2(1) Added NTP support for all VDCs, enabling them to act as
time servers. See the “Virtualization Support” section on
page 5-65.
NTP 5.2(1) Changed the command to enable or disable NTP from [no]
ntp enable to [no] feature ntp. See the “Enabling or
Disabling NTP” section on page 5-67.
NTP 5.2(1) Added the ability to configure the device as an authoritative
NTP server, enabling it to distribute time even when it is not
synchronized to an existing time server. See the
“Configuring the Device as an Authoritative NTP Server”
section on page 5-68.
NTP access groups 5.2(1) Added the serve, serve-only, and query-only access group
options to control access to additional NTP services. See the
“Configuring NTP Access Restrictions” section on
page 5-73.
NTP 5.1(1) No change from Release 5.0.
NTP access groups 5.0(2) Added the ability to control access to NTP services by using
access groups. See the “Configuring NTP Access
Restrictions” section on page 5-73.
5-82 OL-20635-03
Table 5-2 Feature History for NTP (continued)

NTP authentication 5.0(2) Added the ability to enable or disable NTP authentication.
See the “Configuring NTP Authentication” section on
page 5-72.
NTP logging 5.0(2) Added the ability to enable or disable NTP logging. See the
“Configuring NTP Logging” section on page 5-76.
NTP server configuration 5.0(2) Added the optional key keyword to the ntp server
command to configure a key to be used while
communicating with the NTP server. See the “Configuring
an NTP Server and Peer” section on page 5-69.
CFS support 4.2(1) Added the ability to distribute NTP configuration using
CFS. See the “Enabling CFS Distribution for NTP” section
on page 5-77.
NTP source IP address or interface 4.1(3) Added the ability set the source IP address or source
interface that NTP includes in all NTP packets sent to peers.
NTP 4.0(3) Added the ability to disable NTP.
See the “Enabling or Disabling NTP” section on page 5-67.
OL-20635-03 5-83
5-84 OL-20635-03
CHAPTER 6
Configuring PTP
This chapter describes how to configure the Precision Time Protocol (PTP) on Cisco NX-OS devices.
• Information About PTP, page 6-85
• Licensing Requirements for PTP, page 6-88
• Prerequisites for PTP, page 6-88
• Configuring PTP, page 6-89
• Verifying the PTP Configuration, page 6-93
• Configuration Examples for PTP, page 6-93
• Feature History for PTP, page 6-95
Information About PTP

• PTP Overview, page 6-86
• PTP Device Types, page 6-86
• PTP Process, page 6-87
• Pong, page 6-87
• Clock Manager, page 6-87
OL-20635-03 6-85
Chapter 6 Configuring PTP
PTP Overview
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 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-member synchronization hierarchy with the
grandmaster clock, 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.
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 member (synchronizing to a downstream port), based on the best clock available to it through
all of the other ports on the boundary clock. Messages related to synchronization and establishing
the master-member 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.
– 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 In Cisco NX-OS Release 5.2, PTP operates only in boundary clock mode. End-to-end transparent clock
and peer-to-peer transparent clock modes are not supported.
6-86 OL-20635-03
PTP Process
The PTP process consists of two phases: establishing the master-member 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
• Based on this comparison, determines its own state as either master or member
After the master-member hierarchy has been established, the clocks are synchronized as follows:
• The master sends a synchronization message to the member and notes the time it was sent.
• The member receives the synchronization message and notes the time it was received.
• The member 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 member.
• The member uses these timestamps to adjust its clock to the time of its master.
Pong
The network-monitoring tool Pong leverages the PTP’s time synchronization infrastructure to diagnose
the health of the network. Pong measures port-to-port delays and is similar to the network-monitoring
utility Ping but provides for a greater depth of network diagnostics. For more information on Pong, see
the Cisco Nexus 7000 Series NX-OS Troubleshooting Guide.
Clock Manager
Clocks are resources that need to be shared across different processes and across different VDCs.
Multiple time synchronization protocols (such as NTP and PTP) might be running in the system, and
multiple instances of the same protocol might be running in different VDCs. The clock manager allows
you to specify the protocol and a VDC running that protocol to control the various clocks in the system.
For information on configuring the clock manager, see the Cisco Nexus 7000 Series NX-OS
Fundamentals Configuration Guide, Release 5.x.
High Availability
Stateful restarts are supported for PTP. After a reboot or a supervisor switchover, the running
OL-20635-03 6-87
Licensing Requirements for PTP
Cisco NX-OS supports multiple instances of PTP, one instance per virtual device context (VDC). By
default, Cisco NX-OS places you in the default VDC unless you specifically configure another VDC.
For more information about VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context
Licensing Requirements for PTP

Cisco NX-OS PTP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for PTP

PTP has the following prerequisites:
• To configure VDCs, you must install the Advanced Services license. See the Cisco Nexus 7000

PTP has the following configuration guidelines and limitations:
• In Cisco NX-OS Release 5.2, PTP operates only in boundary clock mode. End-to-end transparent
clock and peer-to-peer transparent clock modes are not supported.
• Only one PTP process can control all of the port clocks through the clock manager.
• 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.
• All management messages are forwarded on ports on which PTP is enabled. Handling management
messages is not supported.
• PTP can be enabled only on F1 Series module ports.
• PTP-capable ports do not identify PTP packets and do not time-stamp or redirect those packets
unless you enable PTP on those ports.
• For F1 Series modules, PTP is not supported on the port if priority flow control is enabled. Similarly,
priority flow control is not supported if PTP is enabled on the same port.
• For F1 Series modules, Pong is not supported on the VDC if priority flow control is enabled on any
of the ports in the same VDC. Similarly, priority flow control is not supported if Pong is enabled in
the same VDC.
6-88 OL-20635-03
Default Settings
Default Settings
Table 6-1 lists the default settings for PTP parameters.
Table 6-1 Default PTP Parameters
Parameters Default
PTP Disabled
PTP domain 0
PTP priority1 value when advertising the clock 255
PTP priority2 value when advertising the clock 255
PTP announce interval 1 (one packet every 2 seconds)
PTP sync interval 2 (one packet every 4 seconds)
PTP announce timeout 3
PTP minimum delay request interval 2 (one packet every 4 seconds)
PTP VLAN 1
Configuring PTP
• Configuring PTP Globally, page 6-89
• Configuring PTP on an Interface, page 6-91
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.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. [no] feature ptp
3. [no] ptp source ip-address [vrf vrf]
4. (Optional) [no] ptp domain number
5. (Optional) [no] ptp priority1 value
6. (Optional) [no] ptp priority2 value
OL-20635-03 6-89
Configuring PTP
7. (Optional) show ptp brief

8. (Optional) show ptp clock
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 [no] feature ptp Enables or disables PTP on the device.
Example:
switch(config)# feature ptp
Step 3 [no] ptp source ip-address [vrf vrf] Configures the source IP address for all PTP packets.
The ip-address can be in IPv4 format.
Example:
switch(config)# ptp source 192.0.2.1
Step 4 [no] ptp domain number (Optional) Configures the domain number to use for
this clock. PTP domains allow you to use multiple
Example:
switch(config)# ptp domain 1
independent PTP clocking subdomains on a single
network. The range is from 0 to 128.
Step 5 [no] ptp priority1 value (Optional) Configures the priority1 value to use when
advertising this clock. This value overrides the default
Example:
switch(config)# ptp priority1 10
criteria (clock quality, clock class, and so on) for best
master clock selection. Lower values take precedence.
The range is from 0 to 255.
Step 6 [no] ptp priority2 value (Optional) Configures the priority2 value to use when
advertising this clock. This value is used to decide
Example:
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 is from 0 to
255.
Step 7 show ptp brief (Optional) Displays the PTP status.
Example:
switch(config)# show ptp brief
Step 8 show ptp clock (Optional) Displays the properties of the local clock.
Example:
switch(config)# show ptp clock
6-90 OL-20635-03
Configuring PTP
Command Purpose
Example:
startup-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 on individual interfaces.
BEFORE YOU BEGIN
Make sure that you have globally enabled PTP on the device and configured the source IP address for
PTP communication.
SUMMARY STEPS
1. config t
2. interface ethernet slot/port
3. [no] ptp
4. (Optional) [no] ptp announce {interval seconds | timeout count}
5. (Optional) [no] ptp delay-request minimum interval seconds
6. (Optional) [no] ptp sync interval seconds
7. (Optional) [no] ptp vlan vlan
8. (Optional) show ptp brief
9. (Optional) show ptp port interface interface slot/port
OL-20635-03 6-91
Configuring PTP
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 interface ethernet slot/port Specifies the interface on which you are enabling
PTP and enters the interface configuration mode.
Example:
switch(config)# interface ethernet 7/1
switch(config-if)
Step 3 [no] ptp Enables or disables PTP on an interface.
Example:
switch(config-if)# ptp
Step 4 [no] ptp announce {interval seconds | timeout (Optional) Configures the interval between PTP
count} announce messages on an interface or the
Example:
number of PTP intervals before a timeout occurs
switch(config-if)# ptp announce interval 1 on an interface.
The range for the PTP announcement interval is
from 0 to 4 log seconds, and the range for the
interval timeout is from 2 to 10.
Step 5 [no] ptp delay-request minimum interval (Optional) Configures the minimum interval
seconds allowed between PTP delay-request messages
Example:
when the port is in the master state. The range is
switch(config-if)# ptp delay-request minimum from –1 to 6 log seconds.
interval 3
Step 6 [no] ptp sync interval seconds (Optional) Configures the interval between PTP
synchronization messages on an interface. The
Example:
switch(config-if)# ptp sync interval 1
range is from –1 to 2 log seconds.
Step 7 [no] ptp vlan vlan (Optional) Configures the PTP VLAN value on
an interface. The range is from 1 to 4094.
Example:
switch(config-if)# ptp vlan 10
Step 8 show ptp brief (Optional) Displays the PTP status.
Example:
Step 9 show ptp port interface interface slot/port (Optional) Displays the status of the PTP port.
Example:
switch(config-if)# show ptp port interface
ethernet 7/1
Example:
switch(config-if)# copy running-config
startup-config
6-92 OL-20635-03
Verifying the PTP Configuration
Verifying the PTP Configuration

To display the PTP configuration, perform one of the following tasks:
Command Purpose
show ptp brief Displays the PTP status.
show ptp clock Displays the properties of the local clock.
show ptp clock foreign-masters record Displays the state of foreign masters known to the
[interface interface slot/port] PTP process. For each foreign master, the output
displays the clock identity, basic clock properties,
and whether the clock is being used as a
grandmaster.
show ptp corrections Displays the last few PTP corrections.
show ptp parent Displays the properties of the PTP parent.
show ptp port interface interface slot/port Displays the status of the PTP port.
show ptp time-property Displays the properties of the PTP clock.
Configuration Examples for PTP

This 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# config t
switch(config)# feature ptp
switch(config)# ptp source 10.10.10.1
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
OL-20635-03 6-93
This example shows how to configure PTP on an interface and configure the intervals for the announce,
delay-request, and synchronization messages:
switch# config t
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 2/1
PTP Port Dataset: Eth2/1
Port identity: clock identity: 0:22:55:ff:ff:79:a4:c1
Port identity: port number: 1028
PTP version: 2
Port state: Master
Delay request interval(log mean): 4
Announce receipt time out: 2
Peer mean path delay: 0
Announce interval(log mean): 3
Sync interval(log mean): -1
Delay Mechanism: End to End
Peer delay request interval(log mean): 0
For additional information related to implementing PTP, see the following sections:
• MIBs, page 6-95
Related Documents
PTP CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference, Release 5.x
Pong Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide,
Release 5.x
Clock manager Cisco Nexus 7000 Series NX-OS Fundamentals Configuration Guide,
Release 5.x
VDCs Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
Guide, Release 5.x
6-94 OL-20635-03
Feature History for PTP
MIBs
MIBs MIBs Link
• CISCO-PTP-MIB To locate and download MIBs, go to the following URL:

Table 6-2 Feature History for PTP

PTP 5.2(1) This feature was introduced.
OL-20635-03 6-95
6-96 OL-20635-03
CHAPTER 7
Configuring CDP
This chapter describes how to configure the Cisco Discovery Protocol (CDP) on Cisco NX-OS devices.
• Information About CDP, page 7-97
• Licensing Requirements for CDP, page 7-99
• Prerequisites for CDP, page 7-99
• Configuring CDP, page 7-100
• Verifying the CDP Configuration, page 7-103
• Configuration Example for CDP, page 7-104
• Feature History for CDP, page 7-105
Information About CDP

• CDP Overview, page 7-97
• VTP Feature Support, page 7-98
CDP Overview
The Cisco Discovery Protocol (CDP) is a media-independent and protocol-independent protocol that
runs on all Cisco-manufactured equipment including routers, bridges, access and communication
servers, and switches. You can use CDP to discover and view information about all the Cisco devices
that are directly attached to the device.
CDP gathers protocol addresses of neighboring devices and discovers the platform of those devices. CDP
runs over the data link layer only. Two systems that support different Layer 3 protocols can learn about
each other.
OL-20635-03 7-97
Chapter 7 Configuring CDP
Information About CDP
Each device that you configure for CDP sends periodic advertisements to a multicast address. Each
device advertises at least one address at which it can receive SNMP messages. The advertisements also
contain hold-time information, which indicates the length of time that a receiving device should hold
CDP information before removing it. You can configure the advertisement or refresh timer and the hold
timer.
CDP Version-2 (CDPv2) allows you to track instances where the native VLAN ID or port duplex states
do not match between connecting devices.
CDP advertises the following type-length-value fields (TLVs):
• Device ID
• Address
• Port ID
• Capabilities
• Version
• Platform
• Native VLAN
• Full/Half Duplex
• MTU
• SysName
• SysObjectID
• Management Address
• Physical Location
• VTP
All CDP packets include a VLAN ID. If you configure CDP on a Layer 2 access port, the CDP packets
sent from that access port include the access port VLAN ID. If you configure CDP on a Layer 2 trunk
port, the CDP packets sent from that trunk port include the lowest configured VLAN ID allowed on that
trunk port. The trunk port can receive CDP packets that include any VLAN ID in the allowed VLAN list
for that trunk port. For more information on VLANs, see the Cisco Nexus 7000 Series NX-OS Layer 2
Switching Configuration Guide, Release 5.x.
VTP Feature Support

CDP sends the VLAN Trunking Protocol (VTP) type-length-value field (TLV) if the following
conditions are met:
• CDP Version 2 is enabled
• The VTP feature is enabled
• A VTP domain name is configured
You can view the VTP information with the show cdp neighbors detail command.
7-98 OL-20635-03
Licensing Requirements for CDP
High Availability
Cisco NX-OS supports stateless restarts for CDP. After a reboot or a supervisor switchover, Cisco
NX-OS applies the running configuration. For more information on high availability, see the Cisco
Nexus 7000 Series NX-OS High Availability and Redundancy Guide, Release 5.x.
Cisco NX-OS supports multiple instances of CDP, one instance per virtual device context (VDC). By
default, Cisco NX-OS places you in the default VDC unless you specifically configure another VDC.
For more information on VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context
Licensing Requirements for CDP

Cisco NX-OS CDP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for CDP

CDP has the following prerequisites:
If you configure VDCs, install the Advanced Services license and enter the desired VDC (see the Cisco
Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x).

CDP has the following configuration guidelines and limitations:
• CDP can discover up to 256 neighbors per port if the port is connected to a hub with 256
connections.
• CDP must be enabled on the device or you cannot enable it on any interfaces.
• You can configure CDP on physical interfaces and port channels only.
• CDP is not supported for the Cisco Nexus 2000 Series Fabric Extender.
OL-20635-03 7-99
Default Settings
Default Settings
Table 7-1 lists the CDP default settings.
Table 7-1 CDP Default Settings
Parameters Default
CDP Enabled globally and on all interfaces
CDP version Version 2
CDP device ID Serial number
CDP timer 60 seconds
CDP hold timer 180 seconds
Configuring CDP
• Enabling or Disabling CDP Globally, page 7-100
• Enabling or Disabling CDP on an Interface, page 7-101
• Configuring Optional CDP Parameters, page 7-103
Note Be aware that the Cisco NX-OS commands may differ from the Cisco IOS commands.
Enabling or Disabling CDP Globally

CDP is enabled by default. You can disable CDP and then reenable it.
You must enable CDP on the device before you enable CDP on any interfaces. If CDP is disabled
globally and you enable CDP on specified interfaces, CDP will not be active on those interfaces; the
system does not return an error message.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. cdp enable
3. copy running-config startup-config
7-100 OL-20635-03
Configuring CDP
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 cdp enable Enables the CDP feature on the entire device. This is
enabled by default.
Example:
switch(config)# cdp enable
Step 3 copy running-config startup-config (Optional) Saves this configuration change.
Example:
startup-config
Use the no cdp enable command to disable the CDP feature on the device.
Command Purpose
no cdp enable Disables the CDP feature on the device.
Example:
switch(config)# no cdp enable
This example shows how to enable the CDP feature:

switch# config t
switch(config)# cdp enable
Enabling or Disabling CDP on an Interface

CDP is enabled by default on an interface. You can disable CDP on an interface.
If CDP is disabled globally and you enable CDP on specified interfaces, CDP will not be active on those
interfaces; the system does not return an error message.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. interface interface-type slot/port
3. cdp enable
OL-20635-03 7-101
Configuring CDP
4. show cdp interface interface-type slot/port

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 interface interface-type slot/port Enters interface configuration mode.
Example:
switch(config-if)#
Step 3 cdp enable Enables CDP on this interface. This is enabled by
default.
Example:
switch(config-if)# cdp enable Note Ensure that CDP is enabled on the device (see
the “Enabling or Disabling CDP Globally”
section on page 7-100).
Step 4 show cdp interface interface-type (Optional) Displays CDP information for an interface.
slot/port
Example:
switch(config-if)# show cdp interface
ethernet 1/2
Example:
startup-config
This example shows how to disable CDP on Ethernet 1/2:

switch# config t
switch(config-if)# no cdp enable
switch(config-if)# copy running-config startup-config
This example shows how to enable CDP on port channel 2:

switch# config t
switch(config)# interface port-channel 2
switch(config-if)# cdp enable
switch(config-if)# copy running-config startup-config
7-102 OL-20635-03
Verifying the CDP Configuration
Configuring Optional CDP Parameters

You can use the following optional commands in global configuration mode to modify CDP:
Command Purpose
cdp advertise {v1 | v2} Sets the CDP version supported by the device. The
default is v2.
Example:
switch(config)# cdp advertise v1
cdp format device-id {mac-address | Sets the CDP device ID. The options are as follows:
serial-number | system-name}
• mac-address—MAC address of the chassis.
Example:
• serial-number—Chassis serial
switch(config)# cdp format device-id
mac-address number/Organizationally Unique Identifier
(OUI)
• system-name—The system name or fully
qualified domain name.
The default displays system-name and
serial-number information.
cdp holdtime seconds Sets the time that CDP holds onto neighbor
information before removing it. The range is from
Example:
switch(config)# cdp holdtime 150
10 to 255 seconds. The default is 180 seconds.
cdp timer seconds Sets the refresh time when CDP sends
advertisements to neighbors. The range is from 5 to
Example:
switch(config)# cdp timer 50
254 seconds. The default is 60 seconds.
Verifying the CDP Configuration

To display the CDP configuration, perform one of the following tasks:
Command Purpose
show cdp all Displays all interfaces that have CDP enabled.
show cdp entry {all | name entry-name} Displays the CDP database entries.
show cdp global Displays the CDP global parameters.
show cdp interface interface-type slot/port Displays the CDP interface status.
show cdp neighbors {device-id | interface Displays the CDP neighbor status.
interface-type slot/port} [detail]
show cdp traffic interface interface-type Displays the CDP traffic statistics on an interface.
slot/port
Use the clear cdp counters command to clear CDP statistics on an interface.
Use the clear cdp table command to clear the CDP cache for one or all interfaces.
OL-20635-03 7-103
Configuration Example for CDP
Configuration Example for CDP

This example shows how to enable the CDP feature and configure the refresh and hold timers:
config t
cdp enable
cdp timer 50
cdp holdtime 100
This example shows how to display the CDP global parameters:

switch# show cdp neighbors
Capability Codes: R - Router, T - Trans-Bridge, B - Source-Route-Bridge

S - Switch, H - Host, I - IGMP, r - Repeater,
V - VoIP-Phone, D - Remotely-Managed-Device,
s - Supports-STP-Dispute
Device-ID Local Intrfce Hldtme Capability Platform Port ID

Mgmt-switch
mgmt0 148 R S I WS-C4948-10GE Gig1/37
switch88(FOX1518GRE6)
Eth1/25 164 R S I s N5K-C5596UP Eth1/25
switch89(FOX1518GQJ2)
Eth1/26 163 R S I s N5K-C5596UP Eth1/25
For additional information related to implementing CDP, see the following sections:
• MIBs, page 7-104
Related Documents

CDP CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
VDCs and VRFs Cisco Nexus 7000 Series NX-OS Virtual Device Context
Configuration Guide, Release 5.x
MIBs
MIBs MIBs Link

• CISCO-CDP-MIB To locate and download MIBs, go to the following URL:
7-104 OL-20635-03
Feature History for CDP

Table 7-2 Feature History for CDP

CDP 5.2(1) No change from Release 5.1.
CDP support for VTP domain name 4.2(1) CDP advertises the VLAN Trunking Protocol (VTP)
type-length-value field (TLV) in CDP version-2 packets.
See VTP Feature Support, page 7-98.
OL-20635-03 7-105
7-106 OL-20635-03
CHAPTER 8
Configuring System Message Logging
This chapter describes how to configure system message logging on Cisco NX-OS devices.
• Information About System Message Logging, page 8-107
• Licensing Requirements for System Message Logging, page 8-109
• Configuring System Message Logging, page 8-109
• Verifying the System Message Logging Configuration, page 8-117
• Configuration Example for System Message Logging, page 8-118
• Feature History for System Message Logging, page 8-119
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 device outputs messages to terminal sessions. For information about configuring logging
to terminal sessions, see the “Configuring System Message Logging to Terminal Sessions” section on
page 8-110.
By default, the device logs system messages to a log file. For information about configuring logging to
a file, see the “Logging System Messages to a File” section on page 8-111.
Table 8-1 describes the severity levels used in system messages. When you configure the severity level,
the system outputs messages at that level and lower.
OL-20635-03 8-107
Chapter 8 Configuring System Message Logging
Information About System Message Logging

.
Table 8-1 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 device 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. For information about facilities, see the Cisco Nexus 7000 Series NX-OS
System Management Command Reference. For information about configuring the severity level by
module and facility, see the “Configuring Module and Facility Messages Logged” section on page 8-113.
• syslog Servers, page 8-108
syslog Servers
The syslog servers run on remote systems that log system messages based on the syslog protocol. You
can configure up to eight IPv4 or IPv6 syslog servers. For information about configuring syslog servers,
see the “Configuring syslog Servers” section on page 8-114.
Note When the device first initializes, messages are sent to syslog servers only after the network is initialized.
A virtual device context (VDC) is a logical representation of a set of system resources. System message
logging applies only to the VDC where commands are entered.
For information about configuring VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device
Context Configuration Guide, Release 5.x.
8-108 OL-20635-03
Licensing Requirements for System Message Logging
Licensing Requirements for System Message Logging

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.

System messages are logged to the console and the logfile by default.
Default Settings
Table 8-2 lists the default settings for system message logging parameters.
Table 8-2 Default System Message Logging Parameters
Parameters Default
Console logging Enabled at severity level 2
Monitor logging Enabled at severity level 5
Log file logging Enabled to log messages at severity level 5
Module logging Enabled at severity level 5
Facility logging Enabled; for severity levels, see the Cisco Nexus
7000 Series NX-OS System Management
Command Reference
Time-stamp units Seconds
syslog server logging Disabled

• Configuring System Message Logging to Terminal Sessions, page 8-110
• Logging System Messages to a File, page 8-111
• Configuring Module and Facility Messages Logged, page 8-113
• Configuring syslog Servers, page 8-114
• Displaying and Clearing Log Files, page 8-116
Cisco IOS.
OL-20635-03 8-109
Configuring System Message Logging to Terminal Sessions

You can configure the device to log messages by their severity level to console, Telnet, and SSH sessions.
By default, logging is enabled for terminal sessions.
Tip The current critical (default) logging level is maintained if the console baud speed is 9600 baud (default).
All attempts to change the console logging level generate an error message. To increase the logging level
(above critical), you must change the console baud speed to 38400 baud.
BEFORE YOU BEGIN
SUMMARY STEPS
1. terminal monitor
2. config t
3. logging console [severity-level]
no logging console
4. show logging console
5. logging monitor [severity-level]
no logging monitor
6. show logging monitor
7. logging message interface type ethernet description
no logging message interface type ethernet description
Command Purpose
Step 1 terminal monitor Enables the device to log messages to the console.
Example:
switch# terminal monitor
Example:
switch# config t
switch(config)#
8-110 OL-20635-03
Command Purpose
Step 3 logging console [severity-level] Configures the device to log messages to the console
session based on a specified severity level or higher.
Example:
switch(config)# logging console 3
Severity levels, which can range from 0 to 7, are
listed in Table 8-1. If the severity level is not
specified, the default of 2 is used.
no logging console [severity-level] Disables the device’s ability to log messages to the
console.
Example:
switch(config)# no logging console
Step 4 show logging console (Optional) Displays the console logging
configuration.
Example:
switch(config)# show logging console
Step 5 logging monitor [severity-level] Enables the device to log messages to the monitor
based on a specified severity level or higher. The
Example:
switch(config)# logging monitor 3
configuration applies to Telnet and SSH sessions.
Severity levels, which can range from 0 to 7, are
listed in Table 8-1. If the severity level is not
specified, the default of 2 is used.
no logging monitor [severity-level] Disables logging messages to Telnet and SSH
sessions.
Example:
switch(config)# no logging monitor
Step 6 show logging monitor (Optional) Displays the monitor logging
configuration.
Example:
switch(config)# show logging monitor
Step 7 logging message interface type ethernet Enables you to add the description for physical
description Ethernet interfaces and subinterfaces in the system
Example:
message log. The description is the same description
switch(config)# logging message interface that was configured on the interface.
type ethernet description
no logging message interface type ethernet Disables the printing of the interface description in
description the system message log for physical Ethernet
Example:
interfaces.
switch(config)# no logging message
interface type ethernet description
Step 8 copy running-config startup-config (Optional) Copies the running configuration to the
startup configuration.
Example:
startup-config
Logging System Messages to a File

You can configure the device to log system messages to a file. By default, system messages are logged
to the file log:messages.
For information about displaying and clearing log files, see the “Displaying and Clearing Log Files”
OL-20635-03 8-111
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. logging logfile logfile-name severity-level [size bytes]
no logging logfile [logfile-name severity-level [size bytes]]
3. logging event {link-status | trunk-status} {enable | default}
4. show logging info
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 logging logfile logfile-name Configures the name of the log file used to store
severity-level [size bytes] system messages and the minimum severity level to
Example:
log. You can optionally specify a maximum file size.
switch(config)# logging logfile my_log 6 The default severity level is 5 and the file size is
10485760. Severity levels are listed in Table 8-1.
The file size is from 4096 to 10485760 bytes.
no logging logfile [logfile-name Disables logging to the log file.
severity-level [size bytes]]
Example:
switch(config)# no logging logfile
Step 3 logging event {link-status | trunk-status} Logs interface events.
{enable | default}
• link-status—Logs all UP/DOWN and
Example: CHANGE messages.
switch(config)# logging event link-status
default • trunk-status—Logs all TRUNK status
messages.
• enable—Specifies to enable logging to override
the port level configuration.
• default—Specifies that the default logging
configuration is used by interfaces not explicitly
configured.
Step 4 show logging info (Optional) Displays the logging configuration.
Example:
switch(config)# show logging info
8-112 OL-20635-03
Command Purpose
Example:
startup-config
Configuring Module and Facility Messages Logged

You can configure the severity level and time-stamp units of messages logged by modules and facilities.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. logging module [severity-level]
no logging module
3. show logging module
4. logging level facility severity-level
no logging level [facility severity-level]
5. show logging level [facility]
6. logging timestamp {microseconds | milliseconds | seconds}
no logging timestamp {microseconds | milliseconds | seconds}
7. show logging timestamp
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 logging module [severity-level] Enables module log messages that have the specified
severity level or higher. Severity levels, which range
Example:
switch(config)# logging module 3
from 0 to 7, are listed in Table 8-1. If the severity
level is not specified, the default of 5 is used.
no logging module [severity-level] Disables module log messages.
Example:
switch(config)# no logging module
OL-20635-03 8-113
Command Purpose
Step 3 show logging module (Optional) Displays the module logging
configuration.
Example:
switch(config)# show logging module
Step 4 logging level facility severity-level Enables logging messages from the specified facility
that have the specified severity level or higher. The
Example:
switch(config)# logging level aaa 2
facilities are listed in the Cisco Nexus 7000 Series
NX-OS System Management Command Reference.
Severity levels, which range from 0 to 7, are listed in
Table 8-1. To apply the same severity level to all
facilities, use the all facility. For defaults, see the
show logging level command.
no logging level [facility severity-level] Resets the logging severity level for the specified
facility to its default level. If you do not specify a
Example:
switch(config)# no logging level aaa 3
facility and severity level, the device resets all
facilities to their default levels.
Step 5 show logging level [facility] (Optional) Displays the logging level configuration
and the system default level by facility. If you do not
Example:
switch(config)# show logging level aaa
specify a facility, the device displays levels for all
facilities.
Step 6 logging timestamp {microseconds | Sets the logging time-stamp units. By default, the
milliseconds | seconds} units are seconds.
Example: Note This command applies to logs that are kept
switch(config)# logging timestamp in the switch. It does not apply to the
milliseconds
external logging server.
no logging timestamp {microseconds | Resets the logging time-stamp units to the default of
milliseconds | seconds} seconds.
Example: Note This command applies to logs that are kept
switch(config)# no logging timestamp in the switch. It does not apply to the
milliseconds
external logging server.
Step 7 show logging timestamp (Optional) Displays the logging time-stamp units
configured.
Example:
switch(config)# show logging timestamp
Example:
startup-config
Configuring syslog Servers

You can configure up to eight syslog servers that reference remote systems where you want to log system
messages.
8-114 OL-20635-03
Note We recommend that you configure the syslog server to use the management virtual routing and
forwarding (VRF) instance. For more information on VRFs, see the Cisco Nexus 7000 Series NX-OS
Unicast Routing Configuration Guide, Release 5.x.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. logging server host [severity-level [use-vrf vrf-name]]
no logging server host
3. logging source-interface loopback virtual-interface
4. show logging server
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 logging server host [severity-level Configures a syslog server at the specified hostname
[use-vrf vrf-name]] or IPv4 or IPv6 address. You can limit logging of
Example 1:
messages to a particular VRF by using the use-vrf
switch(config)# logging server 192.0.2.253 keyword. In Cisco NX-OS Release 4.2 or higher, the
default VRF is default. Severity levels, which range
Example 2: from 0 to 7, are listed in Table 8-1. The default
switch(config)# logging server outgoing facility is local7.
2001::)db*::3 5 use-vrf red
Example 1 forwards all messages on facility local 7.
Example 2 forwards messages with severity level 5
or lower for VRF red.
no logging server host Removes the logging server for the specified host.
Example:
switch(config)# no logging server host
Step 3 logging source-interface loopback Enables a source interface for the remote syslog
virtual-interface server. The range for the virtual-interface argument
Example:
is from 0 to 1023.
switch(config)# logging source-interface
loopback 5
Step 4 show logging server (Optional) Displays the syslog server configuration.
Example:
switch(config)# show logging server
OL-20635-03 8-115
Command Purpose
Example:
startup-config
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
Table 8-3 describes the syslog fields that you can configure.
.
Table 8-3 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
(@), a comma-separated list of users, or an asterisk (*) for all logged-in users.
To configure a syslog server on a UNIX or Linux system, follow these steps:
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 the system message logging daemon reads the new changes by checking myfile.log after
entering this command:
$ kill -HUP ~cat /etc/syslog.pid~
Displaying and Clearing Log Files

You can display or clear messages in the log file and the NVRAM.
BEFORE YOU BEGIN
8-116 OL-20635-03
Verifying the System Message Logging Configuration
SUMMARY STEPS
1. show logging last number-lines

2. show logging logfile [start-time yyyy mmm dd hh:mm:ss] [end-time yyyy mmm dd hh:mm:ss]
3. show logging nvram [last number-lines]
4. clear logging logfile
5. clear logging nvram
Command Purpose
Step 1 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
Example:
switch# show logging last 40
of lines.
Step 2 show logging logfile [start-time yyyy mmm Displays the messages in the log file that have a time
dd hh:mm:ss] [end-time yyyy mmm dd stamp within the span entered. If you do not enter an
hh:mm:ss]
end time, the current time is used. You enter three
Example: characters for the month time field, and digits for the
switch# show logging logfile start-time year and day time fields.
2007 nov 1 15:10:0
Step 3 show logging nvram [last number-lines] Displays the messages in the NVRAM. To limit the
number of lines displayed, you can enter the last
Example:
switch# show logging nvram last 10
number of lines to display. You can specify from 1
to 100 for the last number of lines.
Step 4 clear logging logfile Clears the contents of the log file.
Example:
switch# clear logging logfile
Step 5 clear logging nvram Clears the logged messages in NVRAM.
Example:
switch# clear logging nvram
Verifying the System Message Logging Configuration

To display system message logging configuration information, perform one of the following tasks:
Command Purpose
show logging console Displays the console logging configuration.
show logging info Displays the logging configuration.
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 Displays the messages in the log file.
hh:mm:ss] [end-time yyyy mmm dd hh:mm:ss]
show logging module Displays the module logging configuration.
show logging monitor Displays the monitor logging configuration.
OL-20635-03 8-117
Configuration Example for System Message Logging
Command Purpose
show logging nvram [last number-lines] Displays the messages in the NVRAM log.
show logging server Displays the syslog server configuration.
show logging timestamp Displays the logging time-stamp units
configuration.
Example:
switch(config)# show logging timestamp
Logging timestamp: Seconds
For detailed information about the fields in the output from these commands, see the Cisco Nexus 7000
Series NX-OS System Management Command Reference.
Configuration Example for System Message Logging

This example shows how to configure system message logging:
config t
logging console 3
logging monitor 3
logging logfile my_log 6
logging module 3
logging level aaa 2
logging timestamp milliseconds
logging server 172.28.254.253
logging server 172.28.254.254 5 facility local3
copy running-config startup-config
For additional information related to implementing system message logging, see the following sections:
• Standards, page 8-119
Related Documents
System messages CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
System messages Cisco NX-OS System Messages Reference
8-118 OL-20635-03
Feature History for System Message Logging
Standards
Standards Title
No new or modified standards are supported by this —
feature, and support for existing standards has not been
modified by this feature.

Table 8-4 Feature History for System Message Logging

System message logging 5.2(1) Added the ability to add the description for physical
Ethernet interfaces and subinterfaces in the system message
log.
Syslog servers 5.1(1) Increased the number of supported syslog servers from
three to eight.
IPv6 support 4.2(1) Added support for IPv6 syslog hosts.
System message logging 4.0(1) This feature was introduced.
OL-20635-03 8-119
8-120 OL-20635-03
CHAPTER 9
Configuring Smart Call Home
This chapter describes how to configure the Smart Call Home feature of the Cisco NX-OS devices.
• Information About Smart Call Home, page 9-121
• Licensing Requirements for Smart Call Home, page 9-128
• Prerequisites for Smart Call Home, page 9-128
• Configuring Smart Call Home, page 9-129
• Verifying the Smart Call Home Configuration, page 9-147
• Configuration Example for Smart Call Home, page 9-148
• Feature History for Smart Call Home, page 9-161
Information About Smart Call Home

• Smart Call Home Overview, page 9-122
• Destination Profiles, page 9-122
• Smart Call Home Alert Groups, page 9-123
• Smart Call Home Message Urgency Levels, page 9-125
• Obtaining Smart Call Home, page 9-126
• Distributing Smart Call Home Using CFS, page 9-127
• Database Merge Guidelines, page 9-127
OL-20635-03 9-121
Chapter 9 Configuring Smart Call Home
Smart Call Home Overview

Smart Call Home provides an e-mail-based notification for critical system policies. A range of message
formats are available for 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.
Smart Call Home provides the following:
• Automatic execution and attachment of relevant CLI command output.
• Multiple message format options such as the following:
– Short Text—Suitable for pagers or printed reports.
– Full Text—Fully formatted message information suitable for human reading.
– XML—Machine-readable format that uses Extensible Markup Language (XML) and Adaptive
Messaging Language (AML) XML schema definition (XSD). The AML XSD is published on
the Cisco.com website at http://www.cisco.com/. The XML format enables communication with
the Cisco Systems Technical Assistance Center.
• Multiple concurrent message destinations. You can configure up to 50 e-mail destination addresses
for each destination profile.
Destination Profiles
A 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
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 Cisco
NX-OS generates a Smart Call Home message to all e-mail addresses in the destination profile. For
more information about Smart Call Home severity levels, see the “Smart Call Home Message
Urgency Levels” section on page 9-125. Cisco NX-OS 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 NX-OS supports the following predefined destination profiles:
• CiscoTAC-1—Supports the Cisco-TAC alert group in XML message format. This profile is
preconfigured with the [email protected] e-mail contact, maximum message size, and message
severity level 0. You cannot change any of the default information for this profile.
• full-text-destination—Supports the full text message format.
• short-text-destination—Supports the short text message format.
See the “Message Formats” section on page 9-150 for more information about the message formats.
9-122 OL-20635-03
Smart Call Home Alert Groups

An alert group is a predefined subset of Smart Call Home alerts that are supported in all Cisco NX-OS
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. Cisco NX-OS 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 (see the “Smart Call Home Message Urgency
Levels” section on page 9-125).
Table 9-1 lists supported alert groups and the default CLI command output included in Smart Call Home
messages generated for the alert group.
Table 9-1 Alert Groups and Executed Commands
Alert Group Description Executed Commands

Cisco-TAC All critical alerts from the other alert Execute commands based on the alert group that originates the
groups destined for Smart Call Home. alert.
Configuration Periodic events related to configuration. show module
show running-configuration vdc-all all
show startup-configuration vdc-all
show vdc current
show vdc membership
show version
Diagnostic Events generated by diagnostics. show diagnostic result module all detail
show diagnostic result module number detail
show hardware
show logging last 200
show module
show sprom all
show tech-support gold
show tech-support ha
show tech-support platform
show vdc current
show vdc membership
show version
EEM Events generated by EEM. show diagnostic result module all detail
show diagnostic result module number detail
show module
show vdc current
show vdc membership
Environmental Events related to power, fan, and show environment
environment-sensing elements such as show logging last 200
temperature alarms. show module
show vdc current
show vdc membership
show version
OL-20635-03 9-123
Table 9-1 Alert Groups and Executed Commands (continued)

Inventory Inventory status that is provided show inventory
whenever a unit is cold booted, or when show license usage
FRUs are inserted or removed. This alert show module
is considered a noncritical event, and the show system uptime
information is used for status and show sprom all
entitlement. show vdc current
show vdc membership
show version
License Events related to licensing and license show license usage vdc all
violations. show logging last 200
show vdc current
show vdc membership
Linemodule Events related to standard or intelligent show diagnostic result module all detail
hardware switching modules. show diagnostic result module number detail
show hardware
show module
show sprom all|
show tech-support ethpm
show vdc current
show vdc membership
show version
Supervisor Events related to supervisor modules. show diagnostic result module all detail
hardware show hardware
show module
show sprom all
show vdc current
show vdc membership
show version
Syslog port group Events generated by the syslog PORT show license usage
facility. show logging last 200
show vdc current
show vdc membership
9-124 OL-20635-03
Table 9-1 Alert Groups and Executed Commands (continued)

System Events generated by a failure of a show diagnostic result module all detail
software system that is critical to unit show hardware
operation. show logging last 200
show module
show sprom all
show vdc current
show vdc membership
Test User-generated test message. show module
show vdc current
show vdc membership
show version
Smart Call Home maps the syslog severity level to the corresponding Smart Call Home severity level for
syslog port group messages (see the “Smart Call Home Message Urgency Levels” section on
page 9-125).
You can customize predefined alert groups to execute additional CLI 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 Urgency Levels

Smart Call Home allows you to filter messages based on urgency. You can associate each predefined or
user-defined destination profile with a Smart Call Home threshold from 0 (least urgent) to 9 (most
urgent). The default is 0 (all messages are sent).
Syslog severity levels are mapped to the Smart Call Home message level.
Note Smart Call Home does not change the syslog message level in the message text. The syslog messages in
the Smart Call Home log appear as they are described in the Cisco NX-OS System Messages Reference.
Table 9-2 lists each Smart Call Home message level keyword and the corresponding syslog level for the
syslog port alert group.
Table 9-2 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.
OL-20635-03 9-125
Table 9-2 Severity and syslog Level Mapping (continued)
Smart Call
Home Level Keyword syslog Level Description
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.
Possibly independently insignificant.
1 Normal Information (6) Normal event signifying return to normal state.
0 Debugging Debug (7) Debugging messages.
Obtaining Smart Call Home

If you have a service contract directly with Cisco, you can register for the Smart Call Home service.
Smart Call Home analyzes Smart Call Home messages and provides background information and
recommendations. For known issues, particularly online diagnostics failures, Automatic Service
Requests are generated with 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 and, if needed, Automatic Service Request generation,
routed to the correct TAC team, including detailed diagnostic information to speed problem
resolution.
• Secure message transport directly from your device or through an HTTP proxy server or a
downloadable Transport Gateway (TG). You can use a TG aggregation point to support multiple
devices or in cases where security dictates 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. Provides access to associated field
notices, security advisories, and end-of-life information.
You need the following information to register:
• The SMARTnet contract number for your device
• Your e-mail address
• Your Cisco.com ID
For more information about Smart Call Home, see the following Smart Call Home page:
http://www.cisco.com/go/smartcall/
9-126 OL-20635-03
Distributing Smart Call Home Using CFS

You can use Cisco Fabric Services (CFS) to distribute a Smart Call Home configuration to all
CFS-enabled devices in the network. The entire Smart Call Home configuration is distributed except the
device priority and the sysContact names.
For more information about CFS, see the “Configuring CFS” section on page 4-29.
Database Merge Guidelines

When merging two Smart Call Home databases, the following guidelines apply:
• The merged database contains the following information:
– A superset of all the destination profiles from the merging devices.
– The destination profile e-mail addresses and alert groups.
– Other configuration information (for example, message throttling, or periodic inventory)
present in the managing device.
• Destination profile names cannot be duplicated within the merging devices—even though the
configurations are different, the names cannot be duplicated. If a profile name is duplicated, one of
the duplicate profiles must first be deleted or the merger fails.
High Availability
Stateless restarts are supported for Smart Call Home. After a reboot or supervisor switchover, the
running configuration is applied.
One instance of Smart Call Home is supported per virtual device context (VDC). Smart Call Home uses
the contact information from the first registered VDC as the administrator contact for all VDCs on the
physical device. For example, if you want the Smart Call Home to use the contact information from the
default VDC, you should register using that VDC. You can update this information at the Smart Call
Home web site at the following URL:
http://www.cisco.com/go/smartcall/
Smart Call Home registers the contacts for all other VDCs as users that can see all the Smart Call Home
data for the physical device but cannot act as administrators. All registered users and the registered
administrator receive all Smart Call Home notifications from all VDCs on the physical device.
By default, you are placed in the default VDC. In the default VDC, you can test Smart Call Home using
the callhome send and callhome test commands. In a nondefault VDC, only the callhome test command
is available. For more information on VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device
Context Configuration Guide.
Smart Call Home is virtual routing and forwarding (VRF) aware. You can configure Smart Call Home
to use a particular VRF to reach the Smart Call Home SMTP server.
OL-20635-03 9-127
Licensing Requirements for Smart Call Home
Licensing Requirements for Smart Call Home

Cisco NX-OS Smart Call Home 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.
Prerequisites for Smart Call Home

Smart Call Home has the following prerequisites:
• To send messages to an e-mail address, you must first configure an e-mail server. To send messages
using HTTP, you must have access to an HTTPS server and have a valid certificate installed on the
Nexus device.
• Your device must have IP connectivity to an e-mail server or HTTPS server.
• You must first configure the contact name (SNMP server contact), phone, and street address
information. This step is required to determine the origin of messages received.
• If you use Smart Call Home, you need an active service contract for the device that you are
configuring.
• If you configure VDCs, install the Advanced Services license (see the Cisco Nexus 7000 Series
NX-OS Virtual Device Context Configuration Guide). This license is required for VDCs only, not
for Smart Call Home.

Smart Call Home has the following configuration guidelines and limitations:
• If there is no IP connectivity or if the interface in the VRF to the profile destination is down, Smart
Call Home messages cannot be sent.
• Smart Call Home operates with any SMTP server.
• You can configure up to five SMTP servers for Smart Call Home.
• If you distribute the Smart Call Home configuration using CFS, then the entire Smart Call Home
configuration is distributed except device priority and the sysContact names.
• In a mixed fabric environment with CFS enabled, Cisco devices running Cisco NX-OS Release 5.x
can distribute 5.x configurations (multiple SMTP server support, HTTP VRF support, and HTTP
proxy support) to other 5.x devices in the fabric over CFS. However, if an existing device upgrades
to 5.x, these new configurations are not distributed to that device because a CFS merge is not
triggered upon an upgrade. Therefore, we recommend applying the new configurations only when
all the devices in the fabric support them or performing an empty commit from an existing 5.x device
(not the newly upgraded device) that has the new configurations.
9-128 OL-20635-03
Default Settings
Default Settings
Table 9-3 lists the default settings for Smart Call Home parameters.
Table 9-3 Default Smart Call Home Parameters
Parameters Default
Destination message size for a message sent in full 2,500,000
text format
Destination message size for a message sent in 2,500,000
XML format
Destination message size for a message sent in 4000
short text format
SMTP server port number if no port is specified 25
SMTP server priority if no priority is specified 50
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
Smart Call Home message level 0 (zero)
HTTP proxy server use Disabled and no proxy server configured

Note If you distribute the Smart Call Home configuration using CFS, see the “Configuring CFS” section on
page 4-29.

• Configuring Contact Information, page 9-130
• Creating a Destination Profile, page 9-132
• Modifying a Destination Profile, page 9-134
• Associating an Alert Group and a Destination Profile, page 9-136
• Adding show Commands to an Alert Group, page 9-138
• Configuring E-Mail, page 9-139
• Configuring VRFs To Send Messages Using HTTP, page 9-141
• Configuring an HTTP Proxy Server, page 9-143
• Configuring Periodic Inventory Notifications, page 9-144
• Disabling Duplicate Message Throttle, page 9-146
• Enabling or Disabling Smart Call Home, page 9-146
• Testing Smart Call Home Communications, page 9-147
OL-20635-03 9-129
We recommend that you complete the Smart Call Home configuration procedures in the following
sequence:
1. Configuring Contact Information, page 9-130
2. Creating a Destination Profile, page 9-132
3. Associating an Alert Group and a Destination Profile, page 9-136
4. (Optional) Adding show Commands to an Alert Group, page 9-138
5. (Optional) Creating and Distributing a CFS Configuration, page 4-55
6. Enabling or Disabling Smart Call Home, page 9-146
7. (Optional) Testing Smart Call Home Communications, page 9-147
Configuring Contact Information

You can configure the contact information for Smart Call Home.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. snmp-server contact sys-contact
3. callhome
4. email-contact email-address
5. phone-contact international-phone-number
6. streetaddress address
7. contract-id contract-number
8. customer-id customer-number
9. site-id site-number
10. switch-priority number
11. commit
12. show callhome
9-130 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 snmp-server contact sys-contact Configures the SNMP sysContact.
Example:
switch(config)# snmp-server contact
[email protected]
Step 3 callhome Enters callhome configuration mode.
Example:
Step 4 email-contact email-address Configures the e-mail address for the person primarily
responsible for the device. Up to 255 alphanumeric
Example:
switch(config-callhome)# email-contact
characters are accepted in an e-mail address format.
[email protected] Note You can use any valid e-mail address. You
cannot use spaces.
Step 5 phone-contact Configures the phone number in international phone
international-phone-number number format for the primary person responsible for
Example:
the device. Up to 17 alphanumeric characters are
switch(config-callhome)# phone-contact accepted in international format.
+1-800-123-4567
Note You cannot use spaces. Be sure to use the +
prefix before the number.
Step 6 streetaddress address Configures the street address as an alphanumeric string
with white spaces for the primary person responsible
Example:
switch(config-callhome)# streetaddress
for the device. Up to 255 alphanumeric characters are
123 Anystreet st. Anytown,AnyWhere accepted, including spaces.
Step 7 contract-id contract-number (Optional) Configures the contract number for this
device from the service agreement. The contract
Example:
switch(config-callhome)# contract-id
number can be up to 255 alphanumeric characters in
Contract5678 free format.
Step 8 customer-id customer-number (Optional) Configures the customer number for this
device from the service agreement. The customer
Example:
switch(config-callhome)# customer-id
number can be up to 255 alphanumeric characters in
Customer123456 free format.
Step 9 site-id site-number (Optional) Configures the site number for this device.
The site number can be up to 255 alphanumeric
Example:
switch(config-callhome)# site-id Site1
characters in free format.
OL-20635-03 9-131
Command Purpose
Step 10 switch-priority number (Optional) Configures the switch priority for this
device. The range is from 0 to 7, with 0 being the
Example:
switch(config-callhome)# switch-priority
highest priority and 7 the lowest. The default is 7.
3
Step 11 commit Commits the callhome configuration commands.
Example:
Step 12 show callhome (Optional) Displays a summary of the Smart Call
Home configuration.
Example:
Example:
startup-config
This example shows how to configure the contact information for Smart Call Home:
switch# config t
switch(config)# snmp-server contact [email protected]
switch(config-callhome)# email-contact [email protected]
switch(config-callhome)# phone-contact +1-800-123-4567
switch(config-callhome)# streetaddress 123 Anystreet st. Anytown,AnyWhere
Creating a Destination Profile

You can create a user-defined destination profile and configure its message format.
BEFORE YOU BEGIN
Make sure that you are in the correct VDC (or use the switchto vdc command).
SUMMARY STEPS
1. config t
2. callhome
3. destination-profile name
4. destination-profile name format {XML | full-txt | short-txt}
5. commit
6. show callhome destination-profile [profile name]
9-132 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 destination-profile name Creates a new destination profile. The name can be any
Example:
destination-profile Noc101
Step 4 destination-profile name format {XML | Sets the message format for the profile. The name can
full-txt | short-txt} be any alphanumeric string up to 31 characters.
Example:
destination-profile Noc101 format
full-txt
Example:
Step 6 show callhome destination-profile (Optional) Displays information about one or more
[profile name] destination profiles.
Example:
destination-profile profile Noc101
Example:
startup-config
This example shows how to create a destination profile for Smart Call Home:
switch# config t
switch(config-callhome)# destination-profile Noc101
switch(config-callhome)# destination-profile Noc101 format full-text
OL-20635-03 9-133
Modifying a Destination Profile

You can modify the following attributes for a predefined or user-defined destination profile:
• Destination e-mail address—E-mail address that defines where alerts should be sent.
• Destination URL—HTTP or HTTPS URL that defines where alerts should be sent.
• Transport method—E-mail or HTTP transport that determines which type of destination addresses
are used.
• Message formatting—Message format used for sending the alert (full text, short text, or XML).
• Message level—Smart Call Home message severity level for this destination profile.
• Message size—Allowed length of a Smart Call Home message sent to destination addresses in this
destination profile.
See the “Associating an Alert Group and a Destination Profile” section on page 9-136 for information
on configuring an alert group for a destination profile.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. destination-profile {name | CiscoTAC-1 | full-txt-destination | short-txt-destination}
email-addr address
4. destination-profile {name | CiscoTAC-1 | full-txt-destination | short-txt-destination} http
address
transport-method {email | http}
message-level number
message-size number
8. commit
9-134 OL-20635-03
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 destination-profile {name | CiscoTAC-1 | Configures an e-mail address for a user-defined or
full-txt-destination | predefined destination profile.
short-txt-destination} email-addr
address Tip You can configure up to 50 e-mail addresses in
a destination profile.
Example:
destination-profile full-txt-destination
email-addr [email protected]
Step 4 destination-profile {name | CiscoTAC-1 | Configures an HTTP or HTTPS URL for a
full-txt-destination | user-defined or predefined destination profile. The
short-txt-destination} http address
URL can be up to 255 characters.
Example: Note This command is not distributable with CFS.
As a workaround, enter this command after the
destination-profile CiscoTAC-1 http
http://site.com/service/callhome commit command.
Step 5 destination-profile {name | CiscoTAC-1 | Configures an e-mail or HTTP transport method for a
full-txt-destination | user-defined or predefined destination profile. The
short-txt-destination} transport-method
{email | http}
type of transport method that you choose determines
the configured destination addresses of that type.
Example:
Note This command is not distributable with CFS.
destination-profile CiscoTAC-1 http As a workaround, enter this command after the
http://site.com/service/callhome commit command.
Step 6 destination-profile {name | CiscoTAC-1 | Configures the Smart Call Home message severity
full-txt-destination | level for this destination profile. Cisco NX-OS sends
short-txt-destination} message-level
number
only alerts that have a matching or higher Smart Call
Home severity level to destinations in this profile. The
Example: range is from 0 to 9, where 9 is the highest severity
switch(config-callhome)# level.
message-level 5
OL-20635-03 9-135
Command Purpose
Step 7 destination-profile {name | CiscoTAC-1 | Configures the maximum message size for this
full-txt-destination | destination profile The range is from 0 to 5000000.
short-txt-destination} message-size
number
The default is 2500000.
Example:
message-size 100000
Example:
Example:
destination-profile profile
full-text-destination
Example:
startup-config
This example shows how to modify a destination profile for Smart Call Home:
switch# config t
switch(config-callhome)# destination-profile full-text-destination email-addr
[email protected]
switch(config-callhome)# destination-profile full-text-destination message-level 5
switch(config-callhome)# destination-profile full-text-destination message-size 10000
Associating an Alert Group and a Destination Profile

You can associate one or more alert groups with a destination profile.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
alert-group {All | Cisco-TAC | Configuration | Diagnostic | EEM | Environmental | Inventory |
License | Linecard-Hardware | Supervisor-Hardware | Syslog-group-port | System | Test}
4. commit
9-136 OL-20635-03

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 destination-profile {name | CiscoTAC-1 | Associates an alert group with this destination profile.
full-txt-destination | Use the All keyword to associate all alert groups with
short-txt-destination} alert-group {All
| Cisco-TAC | Configuration | Diagnostic
the destination profile.
| EEM | Environmental | Inventory |
License | Linecard-Hardware |
Supervisor-Hardware | Syslog-group-port
| System | Test}
Example:
destination-profile Noc101 alert-group
All
Example:
Example:
destination-profile profile Noc101
Example:
startup-config
This example shows how to associate all alert groups with the destination profile Noc101:
switch# config t
switch(config-callhome)# destination-profile Noc101 alert-group All
OL-20635-03 9-137
Adding show Commands to an Alert Group

You can assign a maximum of five user-defined CLI show commands to an alert group.
Note You cannot add user-defined CLI show commands to the CiscoTAC-1 destination profile.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. alert-group {Configuration | Diagnostic | EEM | Environmental | Inventory | License |
Linecard-Hardware | Supervisor-Hardware | Syslog-group-port | System | Test} user-def-cmd
show-cmd
4. commit
5. show call-home user-def-cmds
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 alert-group {Configuration | Diagnostic Adds the show command output to any Smart Call
| EEM | Environmental | Inventory | Home messages sent for this alert group. Only valid
License | Linecard-Hardware |
Supervisor-Hardware | Syslog-group-port
show commands are accepted.
| System | Test} user-def-cmd show-cmd
Example:
switch(config-callhome)# alert-group
Configuration user-def-cmd show ip route
Example:
9-138 OL-20635-03
Command Purpose
Step 5 show callhome user-def-cmds (Optional) Displays information about all user-defined
show commands added to alert groups.
Example:
user-def-cmds
Example:
startup-config
This example shows how to add the show ip route command to the Cisco-TAC alert group:
switch# config t
switch(config-callhome)# alert-group Configuration user-def-cmd show ip route
Configuring E-Mail
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.
You can configure up to five SMTP servers for Smart Call Home. The servers are tried based on their
priority. The highest priority server is tried first. If the message fails to be sent, the next server in the list
is tried until the limit is exhausted. If two servers have equal priority, the one that was configured earlier
is tried first.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. transport email mail-server ip-address [port number] [priority number] [use-vrf vrf-name]
4. transport email from email-address
5. transport email reply-to email-address
6. commit
7. show callhome transport
OL-20635-03 9-139
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 transport email mail-server ip-address Configures the SMTP server as the domain name
[port number] [priority number] [use-vrf server (DNS) name, IPv4 address, or IPv6 address.
vrf-name]
Optionally configures the port number. The port range
Example: is from 1 to 65535. The default port number is 25.
switch(config-callhome)# transport email
Also optionally configures the priority of the SMTP
mail-server 192.0.2.1 use-vrf Red
server. The priority range is from 1 to 100, with 1 being
the highest priority and 100 the lowest. If you do not
specify a priority, the default value of 50 is used.
Also optionally configures the VRF to use when
communicating with this SMTP server. The VRF
specified is not used to send messages using HTTP. To
use HTTP, see the “Configuring VRFs To Send
Messages Using HTTP” section on page 9-141.
Note To distribute the SMTP server configuration to
devices that run Release 4.2 or earlier, you
must use the transport email smtp-server
command, which configures only one SMTP
server.
Step 4 transport email from email-address (Optional) Configures the e-mail from field for Smart
Call Home messages.
Example:
from [email protected]
Step 5 transport email reply-to email-address (Optional) Configures the e-mail reply-to field for
Smart Call Home messages.
Example:
reply-to [email protected]
Example:
9-140 OL-20635-03
Command Purpose
Step 7 show callhome transport (Optional) Displays the transport-related configuration
Example:
transport
Example:
startup-config
This example shows how to configure the e-mail options for Smart Call Home messages:
switch# config t
switch(config-callhome)# transport email mail-server 192.0.2.10 use-vrf Red
switch(config-callhome)# transport email from [email protected]
switch(config-callhome)# transport email reply-to [email protected]
This example shows how to configure multiple SMTP servers for Smart Call Home messages:
switch# config t
switch(config-callhome)# transport email mail-server 192.0.2.10 priority 4
switch(config-callhome)# transport email mail-server 172.21.34.193
switch(config-callhome)# transport email smtp-server 10.1.1.174
switch(config-callhome)# transport email mail-server 64.72.101.213 priority 60
switch(config-callhome)# transport email from [email protected]
switch(config-callhome)# transport email reply-to [email protected]
Based on the configuration above, the SMTP servers would be tried in this order:
10.1.1.174 (priority 0)
192.0.2.10 (priority 4)
172.21.34.193 (priority 50, which is the default)
64.72.101.213 (priority 60)
When CFS distribution is enabled, devices that run Release 4.2 or earlier accept only the transport
email smtp-server command configurations while devices that run Release 5.0(1) or later accept both
the transport email smtp-server and transport email mail-server command configurations.
Note When a device accepts both the transport email smtp-server and transport email mail-server
commands, the transport email smtp-server command has a priority of 0, which is the highest. The
server specified by this command is tried first followed by the servers specified by the transport email
mail-server commands in order of priority.
Configuring VRFs To Send Messages Using HTTP

You can use VRFs to send Smart Call Home messages over HTTP. If HTTP VRFs are not configured,
the default VRF is used to transport messages over HTTP.
OL-20635-03 9-141
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. transport http use-vrf vrf-name
4. commit
5. show callhome
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 transport http use-vrf vrf-name Configures the VRF used to send e-mail and other
Smart Call Home messages over HTTP.
Example:
switch(config-callhome)# transport http
use-vrf Blue
Example:
Step 5 show callhome (Optional) Displays information about Smart Call
Home.
Example:
Example:
startup-config
9-142 OL-20635-03
This example shows how to configure a VRF to send Smart Call Home messages using HTTP:
switch# config t
switch(config-callhome)# transport http use-vrf Blue
Configuring an HTTP Proxy Server

Beginning with Cisco NX-OS Release 5.2, you can configure Smart Call Home to send HTTP messages
through an HTTP proxy server. If you do not configure an HTTP proxy server, Smart Call Home sends
HTTP messages directly to the Cisco Transport Gateway (TG).
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. transport http proxy server ip-address [port number]
4. transport http proxy enable
5. commit
6. show callhome transport
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 transport http proxy server ip-address Configures the HTTP proxy server domain name
[port number] server (DNS) name, IPv4 address, or IPv6 address.
Example:
Optionally configures the port number. The port range
switch(config-callhome)# transport http is from 1 to 65535. The default port number is 8080.
proxy server 192.0.2.1
OL-20635-03 9-143
Command Purpose
Step 4 transport http proxy enable Enables Smart Call Home to send all HTTP messages
through the HTTP proxy server.
Example:
switch(config-callhome)# transport http Note You can execute this command only after the
proxy enable proxy server address has been configured.
Note The VRF used for transporting messages

through the proxy server is the same as that
configured using the transport http use-vrf
command.
Example:
Step 6 show callhome transport (Optional) Displays the transport-related configuration
Example:
transport
Example:
startup-config
This example shows how to configure Smart Call Home to send HTTP messages through an HTTP proxy
server:
switch# config t
switch(config-callhome)# transport http proxy server 10.10.10.1 port 4
switch(config-callhome)# transport http proxy enable
Configuring Periodic Inventory Notifications

You can configure your device to periodically send a message with an inventory of all software services
currently enabled and running on the device along with hardware inventory information. Cisco NX-OS
generates two Smart Call Home notifications, periodic configuration messages and periodic inventory
messages.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. callhome
3. periodic-inventory notification [interval days | timeofday time]
9-144 OL-20635-03
4. commit
5. show callhome
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
Step 3 periodic-inventory notification Configures the periodic inventory messages. The
[interval days] [timeofday time] interval range is from 1 to 30 days, and the default is 7.
Example:
The time argument is in HH:MM format. It defines at
switch(config-callhome)# what time of the day every X days an update is sent
periodic-inventory notification interval (where X is the update interval).
20
Example:
Step 5 show callhome (Optional) Displays information about Smart Call
Home.
Example:
Example:
startup-config
This example shows how to configure the periodic inventory messages to generate every 20 days:
switch# config t
switch(config-callhome)# periodic-inventory notification interval 20
OL-20635-03 9-145
Disabling Duplicate Message Throttle

You can limit the number of duplicate messages received for the same event. By default, Cisco NX-OS
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, then Cisco NX-OS disables further messages for
that alert type.
Use the following commands in Smart Call Home configuration mode to disable duplicate message
throttling:
Command Purpose
Step 1 no duplicate-message throttle Disables duplicate message throttling for Smart Call
Home. Enabled by default.
Example:
switch(config-callhome)# no
duplicate-message throttle
Example:
Enabling or Disabling Smart Call Home

Once you have configured the contact information, you can enable the Smart Call Home function.
Use the following commands in Smart Call Home configuration mode to enable Smart Call Home:
Command Purpose
Step 1 enable Enables Smart Call Home. Disabled by default.
Example: Note To disable Smart Call Home, use the no enable
switch(config-callhome)# enable command in Smart Call Home configuration
mode.
Example:
9-146 OL-20635-03
Verifying the Smart Call Home Configuration
Testing Smart Call Home Communications

You can generate a test message to test your Smart Call Home communications.
Use the following commands in any mode to generate a test Smart Call Home message:
Command Purpose
callhome send [configuration | diagnostic] Sends the specified Smart Call Home test message
to all configured destinations.
Example:
switch(config-callhome)# callhome send Note This command is available only in the
diagnostic default VDC.
callhome test Sends a test message to all configured
destinations.
Example:
switch(config-callhome)# callhome test
Verifying the Smart Call Home Configuration

To display Smart Call Home configuration information, perform one of the following tasks:
Command Purpose
show callhome Displays the Smart Call Home configuration.
show callhome destination-profile name Displays one or more Smart Call Home
destination profiles.
show callhome merge Displays the status of the last CFS merger for
Smart Call Home.
show callhome pending Displays the Smart Call Home configuration
changes in the pending CFS database.
show callhome pending-diff Displays the differences between the pending and
running Smart Call Home configuration.
show callhome session status Displays the status of the last CFS commit or
abort operation.
show callhome status Displays the CFS distribution state (enabled or
disabled) for Smart Call Home.
show callhome transport Displays the transport-related configuration for
Smart Call Home.
show callhome user-def-cmds Displays CLI commands added to any alert
groups.
show running-config 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.
OL-20635-03 9-147
Configuration Example for Smart Call Home
Configuration Example for Smart Call Home

This example shows how to create a destination profile called Noc101, associate the Configuration alert
group to that profile, configure contact and e-mail information, and specify the VRF used to send Smart
Call Home messages over HTTP:
config t
snmp-server contact [email protected]
callhome
distribute
email-contact [email protected]
phone-contact +1-800-123-4567
streetaddress 123 Anystreet st. Anytown,AnyWhere
destination-profile Noc101 format full-txt
destination-profile full-text-destination email-addr [email protected]
destination-profile full-text-destination message-level 5
destination-profile Noc101 alert-group Configuration
alert-group Configuration user-def-cmd show ip route
transport email mail-server 192.0.2.10 priority 1
transport http use-vrf Blue
enable
commit
For additional information related to implementing Smart Call Home, see the following sections:
• Event Triggers, page 9-148
• Message Formats, page 9-150
• Sample syslog Alert Notification in Full-Text Format, page 9-153
• Sample syslog Alert Notification in XML Format, page 9-156
Event Triggers
Table 9-4 lists the event triggers and their Smart Call Home message severity levels.
Table 9-4 Event Triggers
Smart
Call
Home
Severity
Alert Group Event Name Description Level
Configuration PERIODIC_CONFIGURATION Periodic configuration update message. 2
9-148 OL-20635-03
Table 9-4 Event Triggers (continued)
Smart
Call
Home
Severity
Alert Group Event Name Description Level
Diagnostic DIAGNOSTIC_MAJOR_ALERT GOLD generated a major alert. 7
DIAGNOSTIC_MINOR_ALERT GOLD generated a minor alert. 4
DIAGNOSTIC_NORMAL_ALERT Smart Call Home generated a normal diagnostic alert. 2
Environmental FAN_FAILURE Cooling fan has failed. 5
and POWER_SUPPLY_ALERT Power supply warning has occurred. 6
CISCO_TAC
POWER_SUPPLY_FAILURE Power supply has failed. 6
POWER_SUPPLY_SHUTDOWN Power supply has shut down. 6
TEMPERATURE_ALARM Thermal sensor going bad. 6
TEMPERATURE_MAJOR_ALARM Thermal sensor indicates temperature has reached 6
operating major threshold.
TEMPERATURE_MINOR_ALARM Thermal sensor indicates temperature has reached 4
operating minor threshold.
Inventory and COLD_BOOT Switch is powered up and reset to a cold boot sequence. 2
CISCO_TAC HARDWARE_INSERTION New piece of hardware has been inserted into the 2
chassis.
HARDWARE_REMOVAL Hardware has been removed from the chassis. 2
PERIODIC_INVENTORY Periodic inventory message has been generated. 2
License LICENSE_VIOLATION Feature in use is not licensed and is turned off after 6
grace period expiration.
Line module LINEmodule_FAILURE Module operation has failed. 7
Hardware and
CISCO_TAC
Supervisor CMP_FAILURE CMP module operation has failed. 5
Hardware and SUP_FAILURE Supervisor module operation has failed. 7
CISCO_TAC
Syslog-group- PORT_FAILURE syslog message that corresponds to the port facility has 6
port been generated.
SYSLOG_ALERT syslog alert message has been generated. 5
System and SW_CRASH Software process has failed with a stateless restart, 5
CISCO_TAC indicating an interruption of a service. Messages are
sent for process crashes on supervisor modules and line
cards.
SW_SYSTEM_INCONSISTENT Inconsistency has been detected in software or file 5
system.
Test and TEST User generated test has occurred. 2
CISCO_TAC
OL-20635-03 9-149
Message Formats
Smart Call Home supports the following message formats:
• Short Text Message Format
• Common Fields for Full Text and XML Messages
• Fields Specific to Alert Group Messages for Full Text and XML Messages
• Inserted Fields for a Reactive and Proactive Event Message
• Inserted Fields for an Inventory Event Message
• Inserted Fields for a User-Generated Test Message
Table 9-5 describes the short text formatting option for all message types.
Table 9-5 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 system message
Table 9-6 describes the first set of common event message fields for full text or XML messages.
Table 9-6 Common Fields for Full Text and XML Messages
Data Item
(Plain Text and Description XML Tag
XML) (Plain Text and XML) (XML Only)
Time stamp Date and time stamp of event in ISO time notation: /aml/header/time
YYYY-MM-DD HH:MM:SS GMT+HH:MM.
Message name Name of message. Specific event names are listed in Table 9-4. /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 (see the “Smart Call Home Message Urgency /aml/header/level
Levels” section on page 9-125).
Source ID Product type for routing, such as the Catalyst 6500 series switch. /aml/header/source
Device ID Unique device identifier (UDI) for the end device that generated the /aml/ header/deviceId
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 the 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
9-150 OL-20635-03
Table 9-6 Common Fields for Full Text and XML Messages (continued)
Data Item
Customer ID Optional user-configurable field used for contract information or other /aml/ header/customerID
ID by any support service.
Contract ID Optional user-configurable field used for contract information or other /aml/ header /contractId
ID by any support service.
Site ID Optional user-configurable field used for Cisco-supplied site ID or /aml/ header/siteId
other data meaningful to alternate support service.
Server ID If the message is generated from the device, this is the unique device /aml/header/serverId
identifier (UDI) of the device.
The format is type@Sid@serial.
• type is the product model number from the 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.
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 /aml/body/sysContact
experienced the event.
Contact e-mail E-mail address of person identified as the contact for this unit. /aml/body/sysContactEmail
Contact phone Phone number of the person identified as the contact for this unit. /aml/body/sysContactPhone
number Number
Street address Optional field that contains the street address for RMA part shipments /aml/body/sysStreetAddress
associated with this unit.
Model name Model name of the device (the specific model as part of a product /aml/body/chassis/name
family 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
Table 9-7 describes the fields specific to alert group messages for full text and XML. These fields may
be repeated if multiple CLI commands are executed for an alert group.
OL-20635-03 9-151
Table 9-7 Fields Specific to Alert Group Messages for Full Text and XML Messages
Data Item
Command output Exact name of the issued CLI command. /aml/attachments/attachment/na
name me
Attachment type Specific command output. /aml/attachments/attachment/typ
e
MIME type Either plain text or encoding type. /aml/attachments/attachment/mi
me
Command output Output of command automatically executed (see the “Smart Call /aml/attachments/attachment/atd
text Home Alert Groups” section on page 9-123). ata
Table 9-8 describes the reactive and proactive event message format for full text or XML messages.
Table 9-8 Inserted Fields for a Reactive and Proactive Event Message
Data Item
Chassis hardware Hardware version of chassis. /aml/body/chassis/hwVersion
version
Supervisor module Top-level software version. /aml/body/chassis/swVersion
software version
Affected FRU name Name of the affected FRU that is generating the event message. /aml/body/fru/name
Affected FRU serial Serial number of the affected FRU. /aml/body/fru/serialNo
number
Affected FRU part Part number of the affected FRU. /aml/body/fru/partNo
number
FRU slot Slot number of the FRU that is generating the event message. /aml/body/fru/slot
FRU hardware Hardware version of the affected FRU. /aml/body/fru/hwVersion
version
FRU software Software version(s) that is running on the affected FRU. /aml/body/fru/swVersion
version
Table 9-9 describes the inventory event message format for full text or XML messages.
9-152 OL-20635-03
Table 9-9 Inserted Fields for an Inventory Event Message
Data Item
Chassis hardware Hardware version of the chassis. /aml/body/chassis/hwVersio
version n
Supervisor module Top-level software version. /aml/body/chassis/swVersion
software version
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 Hardware version of the FRU. /aml/body/fru/hwVersion
version
FRU software Software version(s) that is running on the FRU. /aml/body/fru/swVersion
version
Table 9-10 describes the user-generated test message format for full text or XML.
Table 9-10 Inserted Fields for a User-Generated Test Message
Data Item
Process ID Unique process ID. /aml/body/process/id
Process state State of process (for example, running or halted). /aml/body/process/processSt
ate
Process exception Exception or reason code. /aml/body/process/exception
Sample syslog Alert Notification in Full-Text Format

This sample shows the full-text format for a syslog port alert-group notification:
Severity Level:5
Series:Nexus7000
Switch Priority:0
Device Id:N7K-C7010@C@TXX12345678
Server Id:N7K-C7010@C@TXX12345678
Time of Event:2008-01-17 16:31:33 GMT+0000 Message Name:
Message Type:syslog
System Name:dc3-test
Contact Name:Jay Tester
Contact Email:[email protected]
Contact Phone:+91-80-1234-5678
Street Address:#1 Any Street
OL-20635-03 9-153
Event Description:SYSLOG_ALERT 2008 Jan 17 16:31:33 dc3-test %ETHPORT-2-IF_SEQ_ERROR:

Error (0x20) while communicating with component MTS_SAP_ELTM
opcode:MTS_OPC_ETHPM_PORT_PHY_CLEANUP (for:RID_PORT: Ethernet3/1)
syslog_facility:ETHPORT
start chassis information:
Affected Chassis:N7K-C7010
Affected Chassis Serial Number:TXX12345678 Affected Chassis Hardware Version:0.405
Affected Chassis Software Version:4.1(1) Affected Chassis Part No:73-10900-04 end chassis
information:
start attachment
name:show logging logfile | tail -n 200
type:text
data:
2008 Jan 17 10:57:51 dc3-test %SYSLOG-1-SYSTEM_MSG : Logging logfile (messages)
cleared by user
2008 Jan 17 10:57:53 dc3-test %VSHD-5-VSHD_SYSLOG_CONFIG_I: Configuring console from
/dev/ttyS0 /dev/ttyS0_console
2008 Jan 17 10:59:00 dc3-test %DAEMON-3-SYSTEM_MSG: error: setsockopt IP_TOS 16:
Invalid argument: - sshd[14484]
2008 Jan 17 12:11:18 dc3-test %SYSMGR-STANDBY-5-SUBPROC_TERMINATED: "System Manager
(gsync controller)" (PID 12000) has finished with error code
SYSMGR_EXITCODE_GSYNCFAILED_NONFATAL (12).
2008 Jan 17 16:28:44 dc3-test %SYSMGR-3-BASIC_TRACE: core_copy: PID 2579 with message
Core not generated by system for eltm(0). WCOREDUMP(9) returned zero .
2008 Jan 17 16:28:44 dc3-test %SYSMGR-2-SERVICE_CRASHED: Service "eltm" (PID 3504)
hasn't caught signal 9 (no core).
Core not generated by system for eltm(0). WCOREDUMP(9) returned zero.
Core not generated by system for eltm(0). WCOREDUMP(9) returned zero.
2008 Jan 17 16:29:25 dc3-test %SYSMGR-2-HASWITCHOVER_PRE_START: This supervisor is
becoming active (pre-start phase).
2008 Jan 17 16:29:25 dc3-test %SYSMGR-2-HASWITCHOVER_START: This supervisor is
becoming active.
2008 Jan 17 16:29:26 dc3-test %USER-3-SYSTEM_MSG: crdcfg_get_srvinfo: mts_send failed
- device_test
2008 Jan 17 16:29:27 dc3-test %NETSTACK-3-IP_UNK_MSG_MAJOR: netstack [4336]
Unrecognized message from MRIB. Major type 1807
2008 Jan 17 16:29:27 dc3-test %IM-5-IM_INTF_STATE: mgmt0 is DOWN in vdc 1
2008 Jan 17 16:29:28 dc3-test %SYSMGR-2-SWITCHOVER_OVER: Switchover completed.
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:socket family : 2 -
ntpd[19045]
ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:ipv6 only defined -
ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:bindv6 only defined -
ntpd[19045]
ntpd[19045]
9-154 OL-20635-03

ntpd[19045]
ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %NETSTACK-3-CLIENT_GET: netstack [4336] HA client
filter recovery failed (0)
2008 Jan 17 16:29:28 dc3-test %NETSTACK-3-CLIENT_GET: netstack [4336] HA client
filter recovery failed (0)
2008 Jan 17 16:29:29 dc3-test %DAEMON-3-SYSTEM_MSG: ssh disabled, removing -
dcos-xinetd[19072]
2008 Jan 17 16:29:29 dc3-test %DAEMON-3-SYSTEM_MSG: Telnet disabled, removing -
dcos-xinetd[19072]
dcos-xinetd[19073]
dcos-xinetd[19079]
dcos-xinetd[19079]
2008 Jan 17 16:29:34 dc3-test %IM-5-IM_INTF_STATE: mgmt0 is UP in vdc 1
dcos-xinetd[19105]
dcos-xinetd[19105]
2008 Jan 17 16:29:35 dc3-test %PLATFORM-2-PS_AC_IN_MISSING: Power supply 2 present but
all AC inputs are not connected, ac-redundancy might be affected
2008 Jan 17 16:29:35 dc3-test %PLATFORM-2-PS_AC_IN_MISSING: Power supply 3 present but
all AC inputs are not connected, ac-redundancy might be affected
2008 Jan 17 16:29:38 dc3-test %CALLHOME-2-EVENT: SUP_FAILURE
2008 Jan 17 16:29:46 dc3-test vsh[19166]: CLIC-3-FAILED_EXEC: Can not exec command
<more> return code <14>
2008 Jan 17 16:31:23 dc3-test %CALLHOME-2-EVENT: SW_CRASH alert for service: eltm
2008 Jan 17 16:31:33 dc3-test %NETSTACK-3-INTERNAL_ERROR: netstack [4336] (null)
OL-20635-03 9-155
2008 Jan 17 16:31:33 dc3-test %ETHPORT-2-IF_SEQ_ERROR: Error (0x20) while

communicating with component MTS_SAP_ELTM opcode:MTS_OPC_ETHPM_PORT_PHY_CLEANUP
(for:RID_PORT: Ethernet3/1) end attachment start attachment
name:show vdc membership
type:text
data:
vdc_id: 1 vdc_name: dc3-test interfaces:

Ethernet3/1 Ethernet3/2 Ethernet3/3
vdc_id: 2 vdc_name: dc3-aaa interfaces:
vdc_id: 3 vdc_name: dc3-rbac interfaces:
vdc_id: 4 vdc_name: dc3-call interfaces:
end attachment
start attachment
name:show vdc current-vdc
type:text
data:
Current vdc is 1 - dc3-test
end attachment
start attachment
name:show license usage
type:text
data:
Feature Ins
Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
LAN_ADVANCED_SERVICES_PKG Yes - In use Never -
LAN_ENTERPRISE_SERVICES_PKG Yes - Unused Never -
--------------------------------------------------------------------------------
end attachment
Sample syslog Alert Notification in XML Format

This sample shows the XML format for a syslog port alert-group notification:
<?xml version="1.0" encoding="UTF-8" ?>
<soap-env:Envelope xmlns:soap-env="http://www.w3.org/2003/05/soap-envelope">
<soap-env:Header>
9-156 OL-20635-03
<aml-session:Session xmlns:aml-session="http://www.cisco.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.cisco.com/neddce/services/DDCEService</aml-session:To>
<aml-session:Path>
<aml-session:Via>http://www.cisco.com/appliance/uri</aml-session:Via>
</aml-session:Path>
<aml-session:From>http://www.cisco.com/appliance/uri</aml-session:From>
<aml-session:MessageId>1004:TXX12345678:478F82E6</aml-session:MessageId>
</aml-session:Session>
</soap-env:Header>
<soap-env:Body>
<aml-block:Block xmlns:aml-block="http://www.cisco.com/2004/01/aml-block">
<aml-block:Header>
<aml-block:Type>http://www.cisco.com/2005/05/callhome/syslog</aml-block:Type>
<aml-block:CreationDate>2008-01-17 16:31:33 GMT+0000</aml-block:CreationDate>
<aml-block:Builder> <aml-block:Name>DC3</aml-block:Name>
<aml-block:Version>4.1</aml-block:Version>
</aml-block:Builder>
<aml-block:BlockGroup>
<aml-block:GroupId>1005:TXX12345678:478F82E6</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>5</aml-block:Severity>
</aml-block:Header>
<aml-block:Content>
<ch:CallHome xmlns:ch="http://www.cisco.com/2005/05/callhome" version="1.0">
<ch:EventTime>2008-01-17 16:31:33 GMT+0000</ch:EventTime>
<ch:MessageDescription>SYSLOG_ALERT 2008 Jan 17 16:31:33 dc3-test %ETHPORT-2-IF_SEQ_ERROR:
Error (0x20) while communicating with component MTS_SAP_ELTM
opcode:MTS_OPC_ETHPM_PORT_PHY_CLEANUP (for:RID_PORT: Ethernet3/1) </ch:MessageDescription>
<ch:Event> <ch:Type>syslog</ch:Type> <ch:SubType></ch:SubType> <ch:Brand>Cisco</ch:Brand>
<ch:Series>Nexus7000</ch:Series> </ch:Event> <ch:CustomerData> <ch:UserData>
<ch:Email>[email protected]</ch:Email>
</ch:UserData>
<ch:ContractData>
<ch:DeviceId>N7K-C7010@C@TXX12345678</ch:DeviceId>
</ch:ContractData>
<ch:SystemInfo>
<ch:Name>dc3-test</ch:Name>
<ch:Contact>Jay Tester</ch:Contact> <ch:ContactEmail>[email protected]</ch:ContactEmail>
<ch:ContactPhoneNumber>+91-80-1234-5678</ch:ContactPhoneNumber>
<ch:StreetAddress>#1, Any Street</ch:StreetAddress> </ch:SystemInfo> </ch:CustomerData>
<ch:Device> <rme:Chassis xmlns:rme="http://www.cisco.com/rme/4.1">
<rme:Model>N7K-C7010</rme:Model>
<rme:HardwareVersion>0.405</rme:HardwareVersion>
<rme:SerialNumber>TXX12345678</rme:SerialNumber>
</rme:Chassis>
</ch:Device>
</ch:CallHome>
</aml-block:Content>
<aml-block:Attachments>
<aml-block:Attachment type="inline">
<aml-block:Name>show logging logfile | tail -n 200</aml-block:Name> <aml-block:Data
encoding="plain">
<![CDATA[2008 Jan 17 10:57:51 dc3-test %SYSLOG-1-SYSTEM_MSG : Logging logfile (messages)
cleared by user
OL-20635-03 9-157
2008 Jan 17 10:59:00 dc3-test %DAEMON-3-SYSTEM_MSG: error: setsockopt IP_TOS 16: Invalid
argument: - sshd[14484]
2008 Jan 17 12:11:18 dc3-test %SYSMGR-STANDBY-5-SUBPROC_TERMINATED: \"System Manager
(gsync controller)\" (PID 12000) has finished with error code
SYSMGR_EXITCODE_GSYNCFAILED_NONFATAL (12).
2008 Jan 17 16:28:44 dc3-test %SYSMGR-3-BASIC_TRACE: core_copy: PID 2579 with message Core
not generated by system for eltm(0). WCOREDUMP(9) returned zero .
2008 Jan 17 16:28:44 dc3-test %SYSMGR-2-SERVICE_CRASHED: Service \"eltm\" (PID 3504)
2008 Jan 17 16:29:25 dc3-test %SYSMGR-2-HASWITCHOVER_PRE_START: This supervisor is
becoming active (pre-start phase).
2008 Jan 17 16:29:25 dc3-test %SYSMGR-2-HASWITCHOVER_START: This supervisor is becoming
active.
2008 Jan 17 16:29:26 dc3-test %USER-3-SYSTEM_MSG: crdcfg_get_srvinfo: mts_send failed -
device_test
2008 Jan 17 16:29:27 dc3-test %NETSTACK-3-IP_UNK_MSG_MAJOR: netstack [4336] Unrecognized
message from MRIB. Major type 1807
2008 Jan 17 16:29:28 dc3-test %SYSMGR-2-SWITCHOVER_OVER: Switchover completed.
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:socket family : 2 - ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:ipv6 only defined - ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %DAEMON-3-SYSTEM_MSG: ntp:bindv6 only defined - ntpd[19045]
2008 Jan 17 16:29:28 dc3-test %NETSTACK-3-CLIENT_GET: netstack [4336] HA client filter
recovery failed (0)
2008 Jan 17 16:29:28 dc3-test %NETSTACK-3-CLIENT_GET: netstack [4336] HA client filter
recovery failed (0)
dcos-xinetd[19072]
dcos-xinetd[19072]
dcos-xinetd[19073]
dcos-xinetd[19079]
dcos-xinetd[19079]
dcos-xinetd[19105]
dcos-xinetd[19105]
9-158 OL-20635-03
2008 Jan 17 16:29:35 dc3-test %PLATFORM-2-PS_AC_IN_MISSING: Power supply 2 present but all
AC inputs are not connected, ac-redundancy might be affected
2008 Jan 17 16:29:35 dc3-test %PLATFORM-2-PS_AC_IN_MISSING: Power supply 3 present but all
AC inputs are not connected, ac-redundancy might be affected
2008 Jan 17 16:29:38 dc3-test %CALLHOME-2-EVENT: SUP_FAILURE
2008 Jan 17 16:31:23 dc3-test %CALLHOME-2-EVENT: SW_CRASH alert for service: eltm
2008 Jan 17 16:31:33 dc3-test %NETSTACK-3-INTERNAL_ERROR: netstack [4336] (null)
2008 Jan 17 16:31:33 dc3-test %ETHPORT-2-IF_SEQ_ERROR: Error (0x20) while communicating
with component MTS_SAP_ELTM opcode:MTS_OPC_ETHPM_PORT_PHY_CLEANUP (for:RID_PORT:
Ethernet3/1) ]]> </aml-block:Data> </aml-block:Attachment> <aml-block:Attachment
type="inline"> <aml-block:Name>show vdc membership</aml-block:Name> <aml-block:Data
encoding="plain"> <![CDATA[
vdc_id: 1 vdc_name: dc3-test interfaces:
vdc_id: 2 vdc_name: dc3-aaa interfaces:
vdc_id: 3 vdc_name: dc3-rbac interfaces:
OL-20635-03 9-159
vdc_id: 4 vdc_name: dc3-call interfaces:
]]>
</aml-block:Data>
</aml-block:Attachment>
<aml-block:Attachment type="inline">
<aml-block:Name>show vdc current-vdc</aml-block:Name> <aml-block:Data encoding="plain">
<![CDATA[Current vdc is 1 - dc3-test ]]> </aml-block:Data> </aml-block:Attachment>
<aml-block:Attachment type="inline"> <aml-block:Name>show license usage</aml-block:Name>
<aml-block:Data encoding="plain">
<![CDATA[Feature Ins Lic Status Expiry Date Comments
Count
--------------------------------------------------------------------------------
LAN_ADVANCED_SERVICES_PKG Yes - In use Never -
LAN_ENTERPRISE_SERVICES_PKG Yes - Unused Never -
--------------------------------------------------------------------------------
]]>
</aml-block:Data>
</aml-block:Attachment>
</aml-block:Attachments>
</aml-block:Block>
</soap-env:Body>
</soap-env:Envelope>
Related Documents
Smart Call Home CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Configuration Guide
Standards
Standards Title
MIBs
MIBs MIBs Link
• CISCO-CALLHOME-MIB To locate and download MIBs, go to the following URL:
9-160 OL-20635-03
Feature History for Smart Call Home

Table 9-11 Feature History for Smart Call Home

HTTP proxy server 5.2(1) Added the ability to send HTTP messages through an HTTP
proxy server. See the “Configuring an HTTP Proxy Server”
Smart Call Home 5.1(1) No change from Release 5.0.
SMTP server configuration 5.0(2) Added the ability to configure multiple SMTP servers. See
the “Configuring E-Mail” section on page 9-139.
VRF support for HTTP transport of Smart Call 5.0(2) VRFs can be used to send e-mail and other Smart Call Home
Home messages messages over HTTP. See the “Configuring VRFs To Send
Messages Using HTTP” section on page 9-141.
Crash notifications 5.0(2) Messages are sent for process crashes on line cards. See the
“Event Triggers” section on page 9-148.
Destination profile configuration 4.1(3) The commands destination-profile http and
destination-profile transport-method cannot be
distributed. See the “Modifying a Destination Profile”
OL-20635-03 9-161
9-162 OL-20635-03
CHAPTER 10
Configuring Rollback
This chapter describes how to configure the Rollback feature on Cisco NX-OS devices.
• Information About Rollback, page 10-163
• Licensing Requirements, page 10-165
• Prerequisites for Rollback, page 10-165
• Configuring Rollback, page 10-166
• Verifying the Rollback Configuration, page 10-168
• Configuration Example for Rollback, page 10-169
• Feature History for Rollback, page 10-170
Information About Rollback

• Rollback Overview, page 10-163
• Automatically Generated System Checkpoints, page 10-164
Rollback Overview
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 device at any point without having to reload the device. A
rollback allows any authorized administrator to apply this checkpoint configuration without requiring
expert knowledge of the features configured in the checkpoint.
Cisco NX-OS automatically creates system checkpoints as described in the “Automatically Generated
System Checkpoints” section on page 10-164. You can use either a user or system checkpoint to perform
a rollback.
OL-20635-03 10-163
Chapter 10 Configuring Rollback
Information About Rollback
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 the following rollback types:
• atomic—Implement a rollback only if no errors occur.
• best-effort—Implement a rollback and skip any errors.
• stop-at-first-failure—Implement a rollback that stops if an error occurs.
The default rollback type is atomic.
When you are ready to roll back to a checkpoint configuration, you can view the changes that will be
applied to your current running configuration before committing to the rollback operation. If an error
occurs during the rollback operation, you can choose to cancel the operation, or ignore the error and
proceed with the rollback. If you cancel the operation, Cisco NX-OS provides a list of changes already
applied before the error occurred. You need to clean up these changes manually.
Automatically Generated System Checkpoints

The Cisco NX-OS software automatically generates system checkpoints to help you avoid a loss of
configuration information. System checkpoints are generated by the following events:
• Disabling an enabled feature with the no feature command
• Removing an instance of a Layer 3 protocol, such as with the no router bgp command or the no ip
pim sparse-mode command
• License expiration of a feature
If one of these events causes system configuration changes, the feature software creates a system
checkpoint that you can use to roll back to the previous system configuration.
The system generated checkpoint filenames begin with “system-” and include the feature name. For
example, the first time that you disable the EIGRP feature, the system creates the checkpoint named
system-fm-__inst_1__eigrp.
High Availability
Whenever a checkpoint is created using the checkpoint or checkpoint checkpoint_name commands, the
checkpoint is synchronized to the standby unit.
Rollback remembers the states of the checkpoint operation, so if the checkpoint operation is interrupted
and the system is left in an inconsistent state, rollback can complete the checkpoint operation
(synchronize the checkpoint with the standby unit) before proceeding with the rollback operation.
Your checkpoint files are still available after a process restart or supervisor switchover. Even if there is
an interruption during the process restart or supervisor switchover, the checkpoint will complete
successfully before proceeding with the operation. In a supervisor switchover, the checkpoint is
completed on the new active unit.
If a process restart or supervisor switchover occurs during a rollback operation, after the restart or
switchover completes, the rollback will resume from its previous state and complete successfully.
10-164 OL-20635-03
Licensing Requirements
Cisco NX-OS creates a checkpoint of the running configuration in the virtual device context (VDC) that
you are logged into. You can create different checkpoint copies in each VDC. You cannot apply the
checkpoint of one VDC into another VDC. By default, Cisco NX-OS places you in the default VDC. See
the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x.
VDC configuration does not support checkpoints for any operations, including (but not limited to) VDC
creation, VDC deletion, VDC suspension, VDC reloading, VDC renaming, VDC interface allocation,
shared interface allocation, FCoE VLAN allocation, resource allocation, and resource templates. You
should create your checkpoint from within a specific VDC.
Licensing Requirements
Cisco NX-OS The rollback feature requires no license. Any feature not included in a license package is bundled with the
Prerequisites for Rollback

If you configure VDCs, install the Advanced Services license and go to the specific VDC. For more
information, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide,
Release 5.x.
To configure the rollback feature, you must have network-admin or vdc-admin user privileges.

Rollback has the following configuration guidelines and limitations:
• You can create up to ten checkpoint copies per VDC.
• You cannot apply the checkpoint file of one VDC into another VDC
• You cannot apply a checkpoint configuration in a nondefault VDC if there is a change in the global
configuration portion of the running configuration compared to the checkpoint configuration.
• Your checkpoint filenames must be 80 characters or less.
• You cannot start a checkpoint filename with the word system.
• Beginning in Cisco NX-OS Release 4.2(1), you can start a checkpoint filename with the word auto.
• Beginning in Cisco NX-OS Release 4.2(1), 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 in a VDC.
• After the system executes the write erase or reload command, checkpoints are deleted. You can use
the clear checkpoint database command to clear out all checkpoint files.
OL-20635-03 10-165
Default Settings
• A rollback fails for NetFlow if during a rollback, you try to modify a record that is programmed in
the hardware.
• Although rollback is not supported for checkpoints across software versions, users can perform
rollback at their own discretion and can use the best-effort mode to recover from errors.
• 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 virtual device context (VDC).
• Checkpoints created using the checkpoint and checkpoint checkpoint_name commands are present
upon a switchover for all VDCs.
• Checkpoints created in the default VDC are present upon reload unless a write-erase command is
issued before a reload.
• Checkpoints created in nondefault VDCs are present upon reload only if a copy running-config
startup-config command is issued in the applicable VDC and the default VDC.
• Rollback to files on bootflash is supported only on files 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.
• Rollback is not supported in the storage VDC.
Default Settings
Table 10-1 lists the default settings for rollback parameters.
Table 10-1 Default Rollback Parameters
Parameters Default
rollback type atomic
• Creating a Checkpoint, page 10-166
• Implementing a Rollback, page 10-167
Creating a Checkpoint
You can create up to ten checkpoints of your configuration per VDC.
10-166 OL-20635-03
BEFORE YOU BEGIN
SUMMARY STEPS
1. checkpoint {[cp-name] [description descr] | file filename}

no checkpoint cp-name
2. show checkpoint cp-name [all]
DETAILED STEPS
Command Purpose
Step 1 checkpoint {[cp-name] [description Creates a checkpoint of the running configuration to
descr] | file filename} either a user checkpoint name or a file. The checkpoint
Example:
name can be any alphanumeric string up to 80
switch# checkpoint stable 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.
no checkpoint cp-name You can use the no form of the checkpoint command
to remove a checkpoint name.
Example:
switch# no checkpoint stable Use the delete command to remove a checkpoint file.
Step 2 show checkpoint cp-name [all] (Optional) Displays the contents of the checkpoint
name.
Example:
switch# show checkpoint stable
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.
For information about automatically generated system checkpoints, see the “Automatically Generated
System Checkpoints” section on page 10-164.
Note If you make a configuration change during an atomic rollback, the rollback will fail.
BEFORE YOU BEGIN
You are logged in to the device in EXEC mode for the correct VDC. To go to the correct VDC, use the
switchto vdc command.
OL-20635-03 10-167
Verifying the Rollback Configuration
SUMMARY STEPS
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}
2. rollback running-config {checkpoint cp-name | file cp-file} [atomic | best-effort |
stop-at-first-failure]
DETAILED STEPS
Command Purpose
Step 1 show diff rollback-patch {checkpoint Displays the differences between the source and
src-cp-name | running-config | destination checkpoint selections.
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
Step 2 rollback running-config {checkpoint Creates a rollback to the specified checkpoint name or
cp-name | file cp-file} [atomic | file. You can implement the following rollback types:
best-effort | stop-at-first-failure]
• atomic—Implement a rollback only if no errors
Example: occur.
switch# rollback running-config
checkpoint stable • best-effort—Implement a rollback and skip any
errors.
• stop-at-first-failure—Implement a rollback that
stops if an error occurs.
The default is atomic.
This example shows how to implement a rollback to a
user checkpoint name.
Verifying the Rollback Configuration

To display rollback configuration information, perform one of the following tasks:
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 VDC. 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
VDC. You can limit the displayed checkpoints to
user or system generated checkpoints.
10-168 OL-20635-03
Configuration Example for Rollback
Command Purpose
show diff rollback-patch {checkpoint Displays the differences between the source and
src-cp-name | running-config | startup-config | destination checkpoint selections.
file source-file} {checkpoint dest-cp-name |
running-config | startup-config | file dest-file}
show rollback log {exec | verify} Displays the contents of the rollback log.
Use the clear checkpoint database command to delete all checkpoint files.
Configuration Example for Rollback

This example shows how to create a checkpoint file and then implements a best-effort rollback to a user
checkpoint name:
checkpoint stable
rollback running-config checkpoint stable best-effort
For additional information related to implementing a rollback, see the following sections:
Related Documents
Rollback CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Configuration files Cisco Nexus 7000 Series NX-OS Fundamentals Configuration
Guide, Release 5.x
VDCs Cisco Nexus 7000 Series NX-OS Virtual Device Context
Standards
Standards Title
OL-20635-03 10-169
Feature History for Rollback
Feature History for Rollback

Table 10-2 Feature History for Rollback

Rollback feature 5.2(1) No change from Release 5.1.
High Availability 4.2(1) Checkpoint and rollback operations support high
availability.
See the “High Availability” section on page 10-164.
Guidelines and Limitations 4.2(1) Checkpoint file naming conventions changed.
Rollback to files on bootflash is supported only on files
created using the checkpoint checkpoint_name command.
See the “Guidelines and Limitations” section on
page 10-165.
Automatically generated system checkpoints 4.2(1) The software automatically generates a system checkpoint
when disabling a feature or license expiration could cause
loss of configuration information.
See the “Automatically Generated System Checkpoints”
Guidelines and Limitations 4.1(3) A rollback fails for NetFlow if during rollback, you try to
modify a record that is programmed in the hardware.
A rollback is not supported for checkpoints across software
versions.
page 10-165.
10-170 OL-20635-03
CHAPTER 11
Configuring Session Manager
This chapter describes how to configure Session Manager on Cisco NX-OS devices.
• Information About Session Manager, page 11-171
• Licensing Requirements for Session Manager, page 11-172
• Prerequisites for Session Manager, page 11-172
• Configuring Session Manager, page 11-173
• Verifying the Session Manager Configuration, page 11-176
• Configuration Example for Session Manager, page 11-176
• Feature History for Session Manager, page 11-177
Information About Session Manager

• Session Manager Overview, page 11-171
Session Manager Overview

Session Manager allows you to implement configuration changes in batch mode, using 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.
OL-20635-03 11-171
Chapter 11 Configuring Session Manager
Licensing Requirements for Session Manager
• Commit—Cisco NX-OS verifies the complete configuration and applies the changes 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.
High Availability
Session Manager sessions remain available after a supervisor switchover. Sessions are not persistent
across a software reload.
By default, Cisco NX-OS places you in the default VDC. See the Cisco Nexus 7000 Series NX-OS Virtual
Device Context Configuration Guide, Release 5.x.
Licensing Requirements for Session Manager

Cisco NX-OS Session Manager requires no license. Any feature not included in a license package is bundled with the
Prerequisites for Session Manager

If you configure VDCs, install the Advanced Services license and go to the specific VDC. For more
Release 5.x.
Make sure that you have the privilege level required to support the Session Manager commands that you
plan to use.

Session Manager has the following configuration guidelines and limitations:
• Session Manager supports only the ACL and QoS features.
• You can create up to 32 configuration sessions per VDC.
• You cannot issue an in-service software upgrade (ISSU) if an active session is in progress. You must
commit the session, save it, or abort it before issuing an ISSU.
• You can configure a maximum of 20,000 commands across all sessions in a VDC.
11-172 OL-20635-03
• You cannot simultaneously execute configuration commands in more then one configuration session
or configuration terminal mode. Parallel configurations (for example, one configuration session and
one configuration terminal) may cause validation or verification failures in the configuration
session.
• If an interface reloads while you are configuring that interface in a configuration session, Session
Manager may accept the commands even though the interface is not present in the device at that
time.

• Creating a Session, page 11-173
• Configuring ACLs in a Session, page 11-174
• Verifying a Session, page 11-175
• Committing a Session, page 11-175
• Saving a Session, page 11-176
• Discarding a Session, page 11-176
Note Be aware that the Cisco NX-OS commands may differ from Cisco IOS commands.
Creating a Session
You can create up to 32 configuration sessions.
BEFORE YOU BEGIN
SUMMARY STEPS
1. configure session name

2. show configuration session [name]
3. save location
OL-20635-03 11-173
DETAILED STEPS
Command Purpose
Step 1 configure session name Creates a configuration session and enters session
configuration mode. The name can be any
Example:
switch# configure session myACLs
alphanumeric string.
switch(config-s)#
Step 2 show configuration session [name] (Optional) Displays the contents of the session.
Example:
switch(config-s)# show configuration
session myACLs
Step 3 save location (Optional) Saves the session to a file. The location can
be in bootflash:, slot0:, or volatile:
Example:
switch(config-s)# save
bootflash:sessions/myACLs
Configuring ACLs in a Session

You can configure ACLs within a configuration session.
BEFORE YOU BEGIN
SUMMARY STEPS
1. configure session name

2. ip access-list name
3. permit protocol source destination
4. interface interface-type number
5. ip access-group name {in | out}
6. show configuration session [name]
DETAILED STEPS
Command Purpose
Step 1 configure session name Creates a configuration session and enters session
configuration mode. The name can be any
Example:
switch# configure session myacls
alphanumeric string.
switch(config-s)#
Step 2 ip access-list name Creates an ALC and enters a configuration mode for
that ACL.
Example:
switch(config-s)# ip access-list acl1
switch(config-s-acl)#
11-174 OL-20635-03
Command Purpose
Step 3 permit protocol source destination (Optional) Adds a permit statement to the ACL
Example:
switch(config-s-acl)# permit tcp any any
Step 4 interface interface-type number Enters interface configuration mode
Example:
switch(config-s-acl)# interface e 2/1
switch(config-s-if)#
Step 5 ip access-group name {in | out} Specifies the direction of traffic the access group is
applied to.
Example:
switch(config-s-if)# ip access-group
acl1 in
Step 6 show configuration session [name] (Optional) Displays the contents of the session.
Example:
switch(config-s)# show configuration
session myacls
Verifying a Session
Use the following command in session mode to verify a session:
Command Purpose
verify [verbose] Verifies the configuration as a whole, based on the
existing hardware and software configuration and
Example:
switch(config-s)# verify
resources. Cisco NX-OS returns an error if the
configuration does not pass this verification.
Committing a Session
Use the following command in session mode to commit a session:
Command Purpose
commit [verbose] Validates the configuration changes made in the current
session and applies valid changes to the device.
Example:
switch(config-s)# commit If the validation fails, Cisco NX-OS reverts to the
original configuration.
OL-20635-03 11-175
Verifying the Session Manager Configuration
Saving a Session
Use the following command in session mode to save a session:
Command Purpose
save location (Optional) Saves the session to a file. The location can
be in bootflash:, slot0:, or volatile:.
Example:
switch(config-s)# save
bootflash:sessions/myACLs
Discarding a Session
Use the following command in session mode to discard a session:
Command Purpose
abort Discards the configuration session without applying the
changes.
Example:
switch(config-s)# abort
switch#
Verifying the Session Manager Configuration

To display the 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 session.
Configuration Example for Session Manager

This example shows how to create and commit an ACL configuration using Session Manager:
switch# configure session ACL_tcp_in
Config Session started, Session ID is 1
switch(config-s)# ip access-list ACL1
switch(config-s-acl)# permit tcp any any
switch(config)# interface e 7/1
switch(config-if)# ip access-group ACL1 in
switch(config-if)# exit
switch(config)# exit
switch# config session ACL_tcp_in
Config Session started, Session ID is 1
switch(config-s)# verify
Verification Successful
11-176 OL-20635-03
switch(config-s)# commit
Commit Successful
switch#
For additional information related to implementing Session Manager, see the following sections:
Related Documents
Session Manager CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Guide, Release 5.x
Standards
Standards Title
Feature History for Session Manager

Table 11-1 Feature History for Session Manager

Session Manager 5.2(1) No change from Release 5.1.
OL-20635-03 11-177
Feature History for Session Manager
11-178 OL-20635-03
CHAPTER 12
Configuring the Scheduler
This chapter describes how to configure the scheduler on Cisco NX-OS devices.
• Information About the Scheduler, page 12-179
• Licensing Requirements for the Scheduler, page 12-181
• Prerequisites for the Scheduler, page 12-181
• Configuring the Scheduler, page 12-182
• Verifying the Scheduler Configuration, page 12-191
• Configuration Examples for Scheduler, page 12-191
• Feature History for the Scheduler, page 12-193
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.
• Scheduler Overview, page 12-180
• Remote User Authentication, page 12-180
• Logs, page 12-180
OL-20635-03 12-179
Chapter 12 Configuring the Scheduler
Information About the Scheduler
Scheduler Overview
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

Before starting a job, the scheduler authenticates the user who created the job. Since user credentials
from a remote authentication are not retained long enough to support a scheduled job, you need to 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.
Logs
The scheduler maintains a log file containing the job output. If the size of the job output is greater than
the size of the log file, then the output is truncated. For more information, see the “Defining the
Scheduler Log File Size” procedure on page 12-183.
High Availability
Scheduled jobs remain available after a supervisor switchover or a software reload.
Jobs are created in the virtual device context (VDC) that you are logged into. By default, Cisco NX-OS
places you in the default VDC. For more information, see the Cisco Nexus 7000 Series NX-OS Virtual
Device Context Configuration Guide, Release 5.x.
12-180 OL-20635-03
Licensing Requirements for the Scheduler
Licensing Requirements for the Scheduler

Cisco NX-OS The scheduler 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.
Prerequisites for the Scheduler

The scheduler has the following prerequisites:
• You must enable any conditional features before you can configure those features in a job.
• You must have a valid license installed for any licensed features that you want to configure in the job.
• You must have network-admin or vdc-admin user privileges to configure a scheduled job.

The scheduler has the following configuration guidelines and limitations:
• The scheduler can fail if it encounters one of the following while performing a job:
– If the license has expired for a feature at the time the job for that feature is scheduled.
– If a feature is disabled at the time when a job for that feature is scheduled.
– If you have removed a module from a slot and a job for that slot is scheduled.
• Verify that you have configured the time. The scheduler does not apply a default timetable. If you
create a schedule and 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
Table 12-1 lists the scheduler default settings.
Table 12-1 Default Command Scheduler Parameters
Parameters Default
Scheduler state Disabled.
Log file size 16 KB.
OL-20635-03 12-181

• Enabling the Scheduler, page 12-182
• Defining the Scheduler Log File Size, page 12-183
• Configuring Remote User Authentication, page 12-184
• Defining a Job, page 12-185
• Deleting a Job, page 12-186
• Defining a Timetable, page 12-187
• Clearing the Scheduler Log File, page 12-189
• Disabling the Scheduler, page 12-190
Enabling the Scheduler

You can enable the scheduler feature so that you can configure and schedule jobs.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. feature scheduler
3. show scheduler config
12-182 OL-20635-03
DETAILED STEPS
Command or Action Purpose

Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 feature scheduler Enables the scheduler in the current VDC.
Example:
switch(config)# feature scheduler
Step 3 show scheduler config (Optional) Displays the scheduler configuration.
Example:
switch(config)# show scheduler config
config terminal
feature scheduler
scheduler logfile size 16
end
switch(config)#
Example:
startup-config
Defining the Scheduler Log File Size

You can configure the log file size for capturing jobs, schedules, and job output.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. scheduler logfile size value
OL-20635-03 12-183
DETAILED STEPS

Example:
switch# config t
Enter configuration commands, one
per line. End with CNTL/Z.
switch(config)#
Step 2 scheduler logfile size value Defines the scheduler log file size in kilobytes. The range is
from 16 to 1024. The default is 16.
Example:
switch(config)# scheduler logfile Note If the size of the job output is greater than the size
size 1024 of the log file, then the output is truncated.
Step 3 copy running-config startup-config (Optional) Saves the change persistently through reboots
and restarts by copying the running configuration to the
Example:
startup-config
Configuring Remote User Authentication

You can configure the scheduler to use remote authentication for users who want to configure and
schedule jobs.
Note Remote users must authenticate with their clear text password before creating and configuring jobs.
Note 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.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. scheduler aaa-authentication password [0 | 7] password
3. scheduler aaa-authentication username name password [0 | 7] password
4. show running-config | include “scheduler aaa-authentication”
12-184 OL-20635-03
DETAILED STEPS

Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 scheduler aaa-authentication password [0 | Configures a clear text password for the user who
7] password is currently logged in.
Example:
switch(config)# scheduler
aaa-authentication password X12y34Z56a
Step 3 scheduler aaa-authentication username name Configures a clear text password for a remote user.
password [0 | 7] password
Example:
switch(config)# scheduler
aaa-authentication username newuser
password Z98y76X54b
Step 4 show running-config | include “scheduler (Optional) Displays the scheduler password
aaa-authentication” information.
Example:
switch(config)# show running-config |
include “scheduler aaa-authentication”
Example:
startup-config
Defining a Job
You can define a job including the job name and the command sequence.
Caution 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.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. scheduler job name string
OL-20635-03 12-185
3. command1 ;[command2 ;command3 ;...]

4. show scheduler job [name name]
DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 scheduler job name string Creates a job and enters job configuration mode.
Example: This example creates a scheduler job named
switch(config)# scheduler job name backup-cfg.
backup-cfg
switch(config-job)
Step 3 command1 ;[command2 ;command3 ;...] Defines the sequence of commands for the
specified job. You must separate commands with a
Example:
switch(config-job)# cli var name timestamp
space and a semicolon (for example, “ ;”).
$(TIMESTAMP) ;copy running-config This example creates a scheduler job that saves the
bootflash:/$(SWITCHNAME)-cfg.$(timestamp)
running configuration to a file in bootflash and
;copy
bootflash:/$(SWITCHNAME)-cfg.$(timestamp) then copies the file from bootflash to a TFTP
tftp://1.2.3.4/ vrf management server. The file name is created using the current
switch(config-job)# time stamp and switch name.
Step 4 show scheduler job [name name] (Optional) Displays the job information.
Example:
switch(config-job)# show scheduler job
Example:
switch(config-job)# copy running-config
startup-config
Deleting a Job
You can delete a job from the scheduler.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. no scheduler job name string
12-186 OL-20635-03
3. show scheduler job [name name]

DETAILED STEPS
Command Purpose
Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 no scheduler job name string Deletes the specified job and all commands
defined within it.
Example:
switch(config)# no scheduler job name
configsave
switch(config-job)
Step 3 show scheduler job [name name] (Optional) Displays the job information.
Example:
switch(config-job)# show scheduler job name
configsave
Example:
startup-config
Defining a Timetable
You can define a timetable in the scheduler to be used with one or more jobs.
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, then 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.
OL-20635-03 12-187
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. scheduler schedule name string
3. job name string
4. time daily time
time weekly [[dow:] HH:]MM
time monthly [[dm:] HH:] MM
time start {now repeat repeat-interval | delta-time [repeat repeat-interval]}
5. show scheduler schedule [name]
DETAILED STEPS

Example:
switch# config t
Enter configuration commands, one
per line. End with CNTL/Z.
switch(config)#
Step 2 scheduler schedule name string Creates a new schedule and places you in schedule
configuration mode for that schedule.
Example:
switch(config)# scheduler schedule
name weekendbackupqos
switch(config-schedule)#
Step 3 job name string Associates a job with this schedule. You can add multiple
jobs to a schedule.
Example:
switch(config-schedule)# job name
offpeakZoning
Step 4 time daily time Indicates the job starts every day at a designated time
specified as HH:MM.
Example:
switch(config-schedule)# time daily
23:00
time weekly [[dow:]HH:]MM Indicates that the job starts on a specified day of the week.
Example: • Day of the week (dow) specified as one of the
switch(config-schedule)# time weekly following:
Sun:23:00
– An integer such as 1 = Sunday, 2 = Monday, and
so on.
– An abbreviation such as Sun = Sunday.
The maximum length for the entire argument is 10.
12-188 OL-20635-03

time monthly [[dm:]HH:]MM Indicates the job starts on a specified day each month (dm).
If you specify either 29, 30, or 31, the job is started on the
Example:
switch(config-schedule)# time
last day of each month.
monthly 28:23:00
time start {now repeat Indicates the job starts periodically.
repeat-interval | delta-time [repeat
repeat-interval]} The start-time format is [[[[yyyy:]mmm:]dd:]HH]:MM.
• delta-time
Example:
switch(config-schedule)# time start Specifies the amount of time to wait after the schedule
now repeat 48:00 is configured before starting a job.
• now
Specifies that the job starts now.
• repeat repeat-interval
Specifies the frequency at which the job is repeated
In this example, the job starts immediately and repeats
every 48 hours.
Example:
switch(config)# show scheduler
config
Step 6 copy running-config startup-config (Optional) Saves the change persistently through reboots
and restarts by copying the running configuration to the
Example:
startup-config
Clearing the Scheduler Log File

You can clear the scheduler log file.
BEFORE YOU BEGIN
SUMMARY STEPS
1. clear scheduler logfile
DETAILED STEPS

Step 1 clear scheduler logfile Clears the scheduler log file.
Example:
switch(config)# clear scheduler
logfile
OL-20635-03 12-189
Disabling the Scheduler

You can disable the scheduler feature.
BEFORE YOU BEGIN
The scheduler feature must be enabled before you can configure and schedule jobs.
SUMMARY STEPS
1. config t
2. no feature scheduler
3. show scheduler config
DETAILED STEPS

Example:
switch# config t
End with CNTL/Z.
switch(config)#
Step 2 no feature scheduler Disables the scheduler in the current VDC.
Example:
switch(config)# no feature scheduler
In this example, the scheduler feature is disabled
Example:
switch(config)# show scheduler config
so the command is not recognized.
^
% Invalid command at '^' marker.
switch(config)#
Example:
startup-config
12-190 OL-20635-03
Verifying the Scheduler Configuration
Verifying the Scheduler Configuration

To display the scheduler configuration information, perform one of the following tasks:
Command Purpose
show scheduler config Displays the scheduler configuration.
show scheduler job [name string] Displays the jobs configured.
show scheduler logfile Displays the contents of the scheduler log file.
show scheduler schedule [name string] Displays the schedules configured.
Configuration Examples for Scheduler

• Creating a Scheduler Job, page 12-191
• Scheduling a Scheduler Job, page 12-191
• Displaying the Job Schedule, page 12-192
• Displaying the Results of Running Scheduler Jobs, page 12-192
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# config t
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# config t
switch(config)# scheduler schedule name daily
switch(config-if)# job name backup-cfg
switch(config-if)# time daily 1:00
switch(config-if)# end
switch(config)#
OL-20635-03 12-191
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#
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#
For additional information related to the scheduler, see the following sections:
12-192 OL-20635-03
Feature History for the Scheduler
Related Documents

Scheduler CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
VDCs Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
Guide, Release 5.x
Standards
Standards Title

Table 12-2 Feature History for the Scheduler

Scheduler 5.2(1) No change from Release 5.1.
OL-20635-03 12-193
12-194 OL-20635-03
CHAPTER 13
Configuring SNMP
This chapter describes how to configure the SNMP feature on Cisco NX-OS devices.
• Information About SNMP, page 13-195
• Licensing Requirements for SNMP, page 13-201
• Prerequisites for SNMP, page 13-201
• Configuring SNMP, page 13-202
• Verifying the SNMP Configuration, page 13-222
• Configuration Examples for SNMP, page 13-222
• Feature History for SNMP, page 13-224
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, page 13-196
• SNMP Notifications, page 13-196
• SNMPv3, page 13-197
• SNMP and Embedded Event Manager, page 13-200
• Multiple Instance Support, page 13-200
OL-20635-03 13-195
Chapter 13 Configuring SNMP
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. Cisco NX-OS 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.
SNMP is defined in RFCs 3411 to 3418.
Cisco NX-OS supports SNMPv1, SNMPv2c, and SNMPv3. Both SNMPv1 and SNMPv2c use a
community-based form of security.
Cisco NX-OS supports SNMP over IPv6.
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 a 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
(see the “Configuring SNMP Notification Receivers with VRFs” section on page 13-208). 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. Cisco NX-OS 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 Cisco NX-OS never receives a response, it can send the inform request again.
You can configure Cisco NX-OS to send notifications to multiple host receivers. See the “Configuring
SNMP Notification Receivers” section on page 13-206 for more information about host receivers.
Table 13-1 lists the SNMP traps that are enabled by default.
Table 13-1 SNMP Traps Enabled By Default
Trap Type Description

generic : coldStart
generic : warmStart
entity : entity_mib_change
entity : entity_module_status_change
entity : entity_power_status_change
entity : entity_module_inserted
entity : entity_module_removed
entity : entity_unrecognised_module
13-196 OL-20635-03
Table 13-1 SNMP Traps Enabled By Default (continued)
Trap Type Description

entity : entity_fan_status_change
entity : entity_power_out_change
link : linkDown
link : linkUp
link : extended-linkDown
link : extended-linkUp
link : cieLinkDown
link : cieLinkUp
link : delayed-link-state-change
rf : redundancy_framework
license : notify-license-expiry
license : notify-no-license-for-feature
license : notify-licensefile-missing
license : notify-license-expiry-warning
upgrade : UpgradeOpNotifyOnCompletion
upgrade : UpgradeJobStatusNotify
rmon : risingAlarm
rmon : fallingAlarm
rmon : hcRisingAlarm
rmon : hcFallingAlarm
entity : entity_sensor
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 as follows:
• Message integrity—Ensures that a packet has not been tampered with while it was in-transit.
• Authentication—Determines that 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, v3, page 13-198
• User-Based Security Model, page 13-198
• CLI and SNMP User Synchronization, page 13-199
OL-20635-03 13-197
• Group-Based SNMP Access, page 13-200
Security Models and Levels for SNMPv1, v2, 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.
• 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.
Table 13-2 identifies what the combinations of security models and levels mean.
Table 13-2 SNMP Security Models and Levels
Encryptio
Model Level Authentication n 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 noAuthNoPriv Username No Uses a username match for
authentication.
v3 authNoPriv HMAC-MD5 or No Provides authentication based on the
HMAC-SHA Hash-Based Message Authentication
Code (HMAC) Message Digest 5
(MD5) algorithm or the HMAC
Secure Hash Algorithm (SHA).
v3 authPriv HMAC-MD5 or DES Provides authentication based on the
HMAC-SHA HMAC-MD5 or HMAC-SHA
AES-128
algorithms. By default, the switch
provides Data Encryption Standard
(DES) 56-bit encryption in addition to
authentication based on the Cipher
Block Chaining (CBC) DES
(DES-56) standard. The switch also
provides an option to use a 128-bit
AES algorithm for privacy.
User-Based Security Model

The 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.
13-198 OL-20635-03
• Message origin authentication—Ensures that the claimed identity of the user on whose behalf
received data was originated is confirmed.
• 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 indicate 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 case-sensitive alphanumeric characters. If you use the
localized key, you can specify a maximum of 130 characters.
Note For an SNMPv3 operation that uses the external AAA server, you must use AES for the privacy protocol
in the 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 authentication passphrase specified in the snmp-server user command becomes the password
for the CLI user.
• The password specified in the username command becomes the authentication and privacy
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 a passphrase/password in localized key/encrypted format, Cisco NX-OS
does not synchronize the user information (password, roles, and so on).
Cisco NX-OS holds the synchronized user configuration for 60 minutes by default. See the “Modifying
the AAA Synchronization Time” section on page 13-221 for information on how to modify this default
value.
OL-20635-03 13-199
Group-Based SNMP Access
Note Because group is a standard SNMP term used industry-wide, we refer to role(s) as group(s) 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 read access or read-write access.
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.
SNMP and Embedded Event Manager

The Embedded Event Manager (EEM) feature monitors events, including SNMP MIB objects, and
triggers an action based on these events. One of the actions could be to send an SNMP notification. EEM
sends the cEventMgrPolicyEvent of CISCO-EMBEDDED-EVENT-MGR-MIB as the SNMP
notification.
See Chapter 1, “Configuring the Embedded Event Manager” for more information about EEM.
Multiple Instance Support

A device can support multiple instances of a logical network entity, such as protocol instances or VRFs.
Most existing MIBs cannot distinguish between these multiple logical network entities. For example, the
original OSPF-MIB assumes a single protocol instance on a device, but you can now configure multiple
OSPF instances on a device.
SNMPv3 uses contexts to distinguish between these multiple instances. An SNMP context is a collection
of management information you can access through the SNMP agent. A device can support multiple
contexts for different logical network entities. An SNMP context allows the SNMP manager to access
one of the multiple instances of a MIB module supported on the device for the different logical network
entities.
Cisco NX-OS supports the CISCO-CONTEXT-MAPPING-MIB to map between SNMP contexts and
logical network entities. You can associate an SNMP context to a VRF, protocol instance, or topology.
SNMPv3 supports contexts with the contextName field of the SNMPv3 PDU. You can map this
contextName field to a particular protocol instance or VRF.
For SNMPv2c, you can map the SNMP community to a context using the snmpCommunityContextName
MIB object in the SNMP-COMMUNITY-MIB (RFC 3584). You can then map this
snmpCommunityContextName to a particular protocol instance or VRF using the
CISCO-CONTEXT-MAPPING-MIB or the CLI.
To map an SNMP context to a logical network entity, follow these steps:
Step 1 Create the SNMPv3 context.

Step 2 Determine the logical network entity instance.
Step 3 Map the SNMPv3 context to a logical network entity.
13-200 OL-20635-03
Licensing Requirements for SNMP
Step 4 Optionally, map the SNMPv3 context to an SNMPv2c community.
For more information, see the “Configuring the Context to Network Entity Mapping” section on
page 13-219.
High Availability
Cisco NX-OS supports stateless restarts for SNMP. After a reboot or supervisor switchover, Cisco
NX-OS applies the running configuration.
Cisco NX-OS supports one instance of the SNMP per virtual device context (VDC). By default, Cisco
NX-OS places you in the default VDC. For more information, see the Cisco Nexus 7000 Series NX-OS
Virtual Device Context Configuration Guide, Release 5.x.
SNMP supports multiple MIB module instances and maps them to logical network entities. For more
information, see the “Multiple Instance Support” section on page 13-200.
SNMP is also VRF aware. You can configure SNMP to use a particular VRF to reach the SNMP
notification host receiver. You can also configure SNMP to filter notifications to an SNMP host receiver
based on the VRF where the notification occurred. For more information, see the “Configuring SNMP
Notification Receivers with VRFs” section on page 13-208.
Licensing Requirements for SNMP

Cisco NX-OS SNMP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for SNMP

SNMP has the following prerequisites:
• If you configure VDCs, install the Advanced Services license and enter the desired VDC. For more
Release 5.x.
OL-20635-03 13-201

SNMP has the following configuration guidelines and limitations:
• Cisco NX-OS supports read-only access to some SNMP MIBs. See the Cisco NX-OS MIB support
list at the following URL for more information:
Default Settings
Table 13-3 lists the default settings for SNMP parameters.
Table 13-3 Default SNMP Parameters
Parameters Default
license notifications Enabled.
Configuring SNMP
• Configuring SNMP Users, page 13-203
• Enforcing SNMP Message Encryption, page 13-204
• Assigning SNMPv3 Users to Multiple Roles, page 13-204
• Creating SNMP Communities, page 13-205
• Filtering SNMP Requests, page 13-205
• Configuring SNMP Notification Receivers, page 13-206
• Configuring a Source Interface for SNMP Notifications, page 13-206
• Configuring the Notification Target User, page 13-207
• Configuring SNMP Notification Receivers with VRFs, page 13-208
• Configuring SNMP to Send Traps Using an Inband Port, page 13-209
• Enabling SNMP Notifications, page 13-211
• Disabling LinkUp/LinkDown Notifications on an Interface, page 13-217
• Displaying SNMP ifIndex for an Interface, page 13-218
• Enabling a One-time Authentication for SNMP over TCP, page 13-218
• Assigning the SNMP Device Contact and Location Information, page 13-218
• Configuring the Context to Network Entity Mapping, page 13-219
• Disabling SNMP, page 13-221
• Modifying the AAA Synchronization Time, page 13-221
13-202 OL-20635-03
Configuring SNMP
Cisco IOS.
Configuring SNMP Users

You can configure a user for SNMP.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. snmp-server user name [auth {md5 | sha} passphrase [auto] [priv [aes-128] passphrase]
[engineID id] [localizedkey]]
3. show snmp user
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 snmp-server user name [auth {md5 | sha} Configures an SNMP user with authentication and
passphrase [auto] [priv [aes-128] privacy parameters. The passphrase can be any
passphrase] [engineID id]
[localizedkey]]
case-sensitive alphanumeric string up to 64 characters.
If you use the localizedkey keyword, the passphrase
Example: can be any case-sensitive alphanumeric string up to
switch(config)# snmp-server user Admin 130 characters.
auth sha abcd1234 priv abcdefgh
The engineID format is a 12-digit colon-separated
decimal number.
Step 3 show snmp user (Optional) Displays information about one or more
SNMP users.
Example:
switch(config-callhome)# show snmp user
Example:
startup-config
OL-20635-03 13-203
Configuring SNMP
This example shows how to configure the SNMP contact and location information:
switch# config t
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 authorizationError for any SNMPv3 PDU request using
securityLevel parameter of either noAuthNoPriv or authNoPriv.
Use the following command in global configuration mode to enforce SNMP message encryption for a
user:
Command Purpose
snmp-server user name enforcePriv Enforces SNMP message encryption for this user.
Example:
switch(config)# snmp-server user Admin
enforcePriv
Use the following command in global configuration mode to enforce SNMP message encryption for all
users:
Command Purpose
snmp-server globalEnforcePriv Enforces SNMP message encryption for all users.
Example:
switch(config)# snmp-server
globalEnforcePriv
Assigning SNMPv3 Users to Multiple Roles

After you configure an SNMP user, you can assign multiple roles for the user.
Note Only users belonging to a network-admin role can assign roles to other users.
Use the following command in global configuration mode to assign a role to an SNMP user:
Command Purpose
snmp-server user name group Associates this SNMP user with the configured
user role.
Example:
switch(config)# snmp-server user Admin
superuser
13-204 OL-20635-03
Configuring SNMP
Creating SNMP Communities

You can create SNMP communities for SNMPv1 or SNMPv2c.
Use the following command in global configuration mode to create an SNMP community string:
Command Purpose
snmp-server community name group {ro | rw} Creates an SNMP community string.
Example:
switch(config)# snmp-server community
public ro
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)
See the Cisco Nexus 7000 Series NX-OS Security Configuration Guide, Release 5.x for more information
on creating ACLs. The ACL applies to both IPv4 and IPv6 over UDP and TCP.
Use the following command in global configuration mode to assign an ACL to a community to filter
SNMP requests:
Command Purpose
snmp-server community community-name Assigns an ACL to an SNMP community to filter
use-acl acl-name SNMP requests.
Example:
switch(config)# snmp-server community
public use-acl my_acl_for_public
OL-20635-03 13-205
Configuring SNMP
Configuring SNMP Notification Receivers

You can configure Cisco NX-OS to generate SNMP notifications to multiple host receivers.
Use the following command in global configuration mode to configure a host receiver for SNMPv1 traps:
Command Purpose
snmp-server host ip-address traps version Configures a host receiver for SNMPv1 traps. The
1 community [udp_port number] ip-address can be an IPv4 or IPv6 address. The
Example:
community can be any alphanumeric string up to
switch(config)# snmp-server host 192.0.2.1 255 characters. The UDP port number range is
traps version 1 public from 0 to 65535.
Use the following command in global configuration mode to configure a host receiver for SNMPv2c
traps or informs:
Command Purpose
snmp-server host ip-address {traps | Configures a host receiver for SNMPv2c traps or
informs} version 2c community [udp_port informs. The ip-address can be an IPv4 or IPv6
number]
address. The community can be any alphanumeric
Example: string up to 255 characters. The UDP port number
switch(config)# snmp-server host 192.0.2.1 range is from 0 to 65535.
informs version 2c public
Use the following command in global configuration mode to configure a host receiver for SNMPv3 traps
or informs:
Command Purpose
snmp-server host ip-address {traps | Configures a host receiver for SNMPv3 traps or
informs} version 3 {auth | noauth | priv} informs. The ip-address can be an IPv4 or IPv6
username [udp_port number]
address. The username can be any alphanumeric
Example: string up to 255 characters. The UDP port number
switch(config)# snmp-server host 192.0.2.1 range is from 0 to 65535.
informs version 3 auth NMS
Note The SNMP manager must know the user credentials (authKey/PrivKey) based on the SNMP engine ID
of the Cisco NX-OS device to authenticate and decrypt the SNMPv3 messages.
Configuring a Source Interface for SNMP Notifications

You can configure SNMP to use the IP address of an interface as the source IP address for notifications.
When a notification is generated, its source IP address is based on the IP address of this configured
interface.
13-206 OL-20635-03
Configuring SNMP
You can configure this as follows:

• All notifications sent to all SNMP notification receivers.
• All notifications sent to a specific SNMP notification receiver. This configuration overrides the
global source interface configuration.
Note Configuring the source interface IP address for outgoing trap packets does not guarantee that the device
will use the same interface to send the trap. The source interface IP address defines the source address
inside of the SNMP trap, and the connection is opened with the address of the egress interface as source.
Use the following command in global configuration mode to configure a host receiver on a source
interface:
Command Purpose
snmp-server host ip-address Configures a host receiver for SNMPv2c traps or
source-interface if-type if-number informs. The ip-address can be an IPv4 or IPv6
[udp_port number]
address. Use ? to determine the supported
Example: interface types. The UDP port number range is
switch(config)# snmp-server host 192.0.2.1 from 0 to 65535.
source-interface ethernet 2/1
This configuration overrides the global source
interface configuration.
Use the following command in global configuration mode to configure a source interface for sending out
all SNMP notifications:
Command Purpose
snmp-server source-interface {traps | Configures a source interface for sending out
informs} if-type if-number SNMPv2c traps or informs. Use ? to determine
Example:
the supported interface types.
switch(config)# snmp-server
source-interface traps ethernet 2/1
Use the show snmp source-interface command to display information about configured source
interfaces.
Configuring the Notification Target User

You must configure a notification target user on the device to send SNMPv3 inform notifications to a
notification host receiver.
Cisco NX-OS uses the credentials of the notification target user to encrypt the SNMPv3 inform
notification messages to the configured notification host receiver.
Note For authenticating and decrypting the received inform PDU, the notification host receiver should have
the same user credentials as configured in Cisco NX-OS to authenticate and decrypt the informs.
OL-20635-03 13-207
Configuring SNMP
Use the following command in global configuration mode to configure the notification target user:
Command Purpose
snmp-server user name [auth {md5 | sha} Configures the notification target user with the
passphrase [auto] [priv [aes-128] specified engine ID for the notification host
passphrase] [engineID id]
receiver. The engineID format is a 12-digit
Example: colon-separated decimal number.
switch(config)# snmp-server user NMS auth
sha abcd1234 priv abcdefgh engineID
00:00:00:63:00:01:00:10:20:15:10:03
Configuring SNMP Notification Receivers with VRFs

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.
You can configure Cisco NX-OS to use a configured VRF to reach the host receiver.
Use the following command in global configuration mode to configure a VRF to use for sending
notifications to the host receiver:
Command Purpose
snmp-server host ip-address use-vrf Configures SNMP to use the selected VRF to
vrf_name [udp_port number] communicate with the host receiver. The
Example:
ip-address can be an IPv4 or IPv6 address. The
switch(config)# snmp-server host 192.0.2.1 VRF name can be any alphanumeric string up to
use-vrf Blue 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.
no snmp-server host ip-address use-vrf Removes the VRF reachability information for
vrf_name [udp_port number] the configured host, and removes the entry from
Example:
thc ExtSnmpTargetVrfTable of the
switch(config)# no snmp-server host CISCO-SNMP-TARGET-EXT-MB.
192.0.2.1 use-vrf Blue
The ip-address can be an IPv4 or IPv6 address.
Does not remove the host configuration.
13-208 OL-20635-03
Configuring SNMP
You can configure Cisco NX-OS filter notifications based on the VRF in which the notification occurred.
Use the following command in global configuration mode to filter notifications based on a configured
VRF:
Command Purpose
snmp-server host ip-address filter-vrf Filters notifications to the notification host
vrf_name [udp_port number] receiver based on the configured VRF. The
Example:
ip-address can be an IPv4 or IPv6 address. The
switch(config)# snmp-server host 192.0.2.1 VRF name can be any alphanumeric string up to
filter-vrf Red 255 characters. The UDP port number range is
from 0 to 65535.
This command adds an entry into thc
ExtSnmpTargetVrfTable of the
no snmp-server host ip-address filter-vrf Removes the VRF filter information for the
vrf_name configured host, and removes the entry from thc
Example:
switch(config)# no snmp-server host CISCO-SNMP-TARGET-EXT-MB.
192.0.2.1 filter-vrf Red
The ip-address can be an IPv4 or IPv6 address.
This command does not remove the host
configuration.
Configuring SNMP to Send Traps Using an Inband Port

You can configure SNMP to send traps using an inband port. To do so, you must configure the source
interface (at the global or host level) and the VRF used to send the traps.
SUMMARY STEPS
1. config t
2. snmp-server source-interface traps if-type if-number
3. show snmp source-interface
4. snmp-server host ip-address use-vrf vrf_name [udp_port number]
5. show snmp host
OL-20635-03 13-209
Configuring SNMP
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 snmp-server source-interface traps Globally configures a source interface for sending out
if-type if-number SNMP traps. Use ? to determine the supported
Example:
interface types.
switch(config)# snmp-server You can configure the source interface at the global
source-interface traps ethernet 1/2
level or at a host level. When the source interface is
configured globally, any new host configuration uses
the global configuration to send the traps.
Note To configure a source interface at the host
level, use this command: snmp-server host
ip-address source-interface if-type if-number.
Step 3 show snmp source-interface (Optional) Displays information about configured
source interfaces.
Example:
switch(config)# show snmp
source-interface
Step 4 snmp-server host ip-address use-vrf Configures SNMP to use the selected VRF to
vrf_name [udp_port number] communicate with the host receiver. The ip-address
Example:
can be an IPv4 or IPv6 address. The VRF name can be
switch(config)# snmp-server host any alphanumeric string up to 255 characters. The
171.71.48.164 use_vrf default UDP port number range is from 0 to 65535. This
command adds an entry into the
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 5 show snmp host (Optional) Displays information about configured
SNMP hosts.
Example:
switch(config)# show snmp host
Example:
startup-config
13-210 OL-20635-03
Configuring SNMP
This example shows how to configure SNMP to send traps using a globally configured inband port:
switch# config t
switch(config)# snmp-server source-interface traps ethernet 1/2
switch(config)# show snmp source-interface
-------------------------------------------------------------------
Notification source-interface
-------------------------------------------------------------------
trap Ethernet1/2
inform -
-------------------------------------------------------------------
switch(config)# snmp-server host 171.71.48.164 use_vrf default

-------------------------------------------------------------------
Host Port Version Level Type SecName
-------------------------------------------------------------------
171.71.48.164 162 v2c noauth trap public
Use VRF: default
Source interface: Ethernet 1/2

-------------------------------------------------------------------
Enabling SNMP Notifications

You can enable or disable notifications. If you do not specify a notification name, Cisco NX-OS enables
all notifications.
Table 13-4 lists the commands that enable the notifications for Cisco NX-OS MIBs.
Note The snmp-server enable traps command enables both traps and informs, depending on the configured
notification host receivers.
Table 13-4 Enabling SNMP Notifications
MIB Related Commands

All notifications snmp-server enable traps
CISCO-AAA-SERVER-MIB snmp-server enable traps aaa
snmp-server enable traps aaa server-state-change
CISCO-BGP4-MIB snmp-server enable traps bgp
CISCO-STP-BRIDGE-MIB snmp-server enable traps bridge
snmp-server enable traps bridge newroot
snmp-server enable traps bridge topologychange
CISCO-CALLHOME-MIB snmp-server enable traps callhome
snmp-server enable traps callhome event-notify
snmp-server enable traps callhome smtp-send-fail
CISCO-CFS-MIB snmp-server enable traps cfs
snmp-server enable traps cfs merge-failure
snmp-server enable traps cfs state-change-notif
OL-20635-03 13-211
Configuring SNMP
Table 13-4 Enabling SNMP Notifications (continued)

CISCO-CONFIG-MAN-MIB snmp-server enable traps config
snmp-server enable traps config ccmCLIRunningConfigChanged
CISCO-EIGRP-MIB snmp-server enable traps eigrp [tag]
ENTITY-MIB, snmp-server enable traps entity
CISCO-ENTITY-SENSOR- snmp-server enable traps entity entity_fan_status_change
MIB snmp-server enable traps entity entity_mib_change
snmp-server enable traps entity entity_module_inserted
snmp-server enable traps entity entity_module_removed
snmp-server enable traps entity entity_module_status_change
snmp-server enable traps entity entity_power_out_change
snmp-server enable traps entity entity_power_status_change
snmp-server enable traps entity entity_unrecognised_module
CISCO-FEATURE- snmp-server enable traps feature-control
CONTROL-MIB snmp-server enable traps feature-control
FeatureOpStatusChange
CISCO-HSRP-MIB snmp-server enable traps hsrp
snmp-server enable traps hsrp state-change
CISCO-LICENSE-MGR-MIB snmp-server enable traps license
snmp-server enable traps license notify-license-expiry
snmp-server enable traps license notify-license-expiry-warning
snmp-server enable traps license notify-licensefile-missing
snmp-server enable traps license notify-no-license-for-feature
IF-MIB snmp-server enable traps link
snmp-server enable traps link IETF-extended-linkDown
snmp-server enable traps link IETF-extended-linkUp
snmp-server enable traps link cisco-extended-linkDown
snmp-server enable traps link cisco-extended-linkUp
snmp-server enable traps link linkDown
snmp-server enable traps link Up
OSPF-MIB, snmp-server enable traps ospf [tag]
OSPF-TRAP-MIB snmp-server enable traps ospf lsa
snmp-server enable traps ospf rate-limit rate
CISCO-PORT-SECURITY- snmp-server enable traps port-security
MIB snmp-server enable traps port-security
access-secure-mac-violation
snmp-server enable traps port-security
trunk-secure-mac-violation
CISCO-RF-MIB snmp-server enable traps rf
snmp-server enable traps rf redundancy_framework
CISCO-RMON-MIB snmp-server enable traps rmon
snmp-server enable traps rmon fallingAlarm
snmp-server enable traps rmon hcFallingAlarm
snmp-server enable traps rmon hcRisingAlarm
snmp-server enable traps rmon risingAlarm
13-212 OL-20635-03
Configuring SNMP
Table 13-4 Enabling SNMP Notifications (continued)

SNMPv2-MIB snmp-server enable traps snmp
snmp-server enable traps snmp authentication
CISCO-STPX-MIB snmp-server enable traps stpx
snmp-server enable traps stpx inconsistency
snmp-server enable traps stpx loop-inconsistency
snmp-server enable traps stpx root-inconsistency
CISCO-SYSTEM-EXT-MIB sysmgr
sysmgr cseFailSwCoreNotifyExtended
UPGRADE-MIB upgrade
upgrade UpgradeJobStatusNotify
upgrade UpgradeOpNotifyOnCompletion
ZONE-MIB zone
zone default-zone-behavior-change
zone merge-failure
zone merge-success
zone request-reject1
zone unsupp-mem
Use the following commands in global configuration mode to enable the specified notification:
Command Purpose
snmp-server enable traps Enables all SNMP notifications.
Example:
switch(config)# snmp-server enable traps
snmp-server enable traps aaa Enables AAA SNMP notifications. Optionally,
[server-state-change] enables the following specific notifications:
Example: • server-state-change—Enables AAA server
switch(config)# snmp-server enable traps state-change notifications.
aaa
snmp-server enable traps bgp Enables BGP SNMP notifications.
Example:
bgp
snmp-server enable traps bridge Enables STP bridge SNMP notifications.
[newroot] Optionally, enables the following specific
[topologychange]
notifications:
Example: • newroot—Enables STP new root bridge
notifications.
bridge
• topologychange—Enables STP bridge
topology-change notifications.
OL-20635-03 13-213
Configuring SNMP
Command Purpose
snmp-server enable traps callhome Enables Call Home notifications. Optionally,
[event-notify] enables the following specific notifications:
[smtp-send-fail]
• event-notify—Enables Call Home external
Example: event notifications.
callhome • smtp-send-fail—Enables Simple Mail
Transfer Protocol (SMTP) message send fail
notifications.
snmp-server enable traps cfs Enables Cisco Fabric Services (CFS)
[merge-failure] notifications. Optionally, enables the following
[state-change-notif]
specific notifications:
Example: • merge-failure—Enables CFS merge-failure
notifications.
cfs
• state-change-notif—Enables CFS
state-change notifications.
snmp-server enable traps config Enables SNMP notifications for configuration
[ccmCLIRunningConfigChanged] changes.
Example: • ccmCLIRunningConfigChanged—Enables
switch(config)# snmp-server enable traps SNMP notifications for configuration
config
changes in the running or startup
configuration.
snmp-server enable traps eigrp [tag] Enables CISCO-EIGRP-MIB SNMP
notifications.
Example:
eigrp
snmp-server enable traps entity Enables ENTITY-MIB SNMP notifications.
[entity_fan_status_change] Optionally, enables the following specific
[entity_mib_change]
[entity_module_inserted]
notifications:
[entity_module_removed] • entity_fan_status_change—Enables entity
[entity_module_status_change]
fan status-change notifications.
[entity_power_out_change]
[entity_power_status_change] • entity_mib_change—Enables entity MIB
[entity_unrecognised_module] change notifications.
Example: • entity_module_inserted—Enables entity
switch(config)# snmp-server enable traps module inserted notifications.
entity
• entity_module_removed—Enables entity
module removed notifications.
• entity_module_status_change—Enables
entity module status-change notifications.
• entity_power_out_change—Enables entity
power-out change notifications.
• entity_power_status_change—Enables
entity power status-change notifications.
• entity_unrecognised_module—Enables
entity unrecognized module notifications.
13-214 OL-20635-03
Configuring SNMP
Command Purpose
snmp-server enable traps feature-control Enables feature-control SNMP notifications.
[FeatureOpStatusChange] Optionally, enables the following specific
Example:
notifications:
switch(config)# snmp-server enable traps • FeatureOpStatusChange—Enables feature
feature-control
operation status-change notifications.
snmp-server enable traps hsrp Enables CISCO-HSRP-MIB SNMP notifications.
[state-change] Optionally, enables the following specific
Example:
notifications:
switch(config)# snmp-server enable traps • state-change—Enables HSRP state-change
hsrp
notifications.
snmp-server enable traps license Enables license SNMP notifications. Optionally,
[notify-license-expiry] enables the following specific notifications:
[notify-license-expiry-warning]
[notify-licensefile-missing] • notify-license-expiry—Enables license
[notify-no-license-for-feature] expiry notifications.
Example: • notify-license-expiry-warning—Enables
switch(config)# snmp-server enable traps license expiry warning notifications.
license
• notify-licensefile-missing—Enables license
file-missing notifications.
• notify-no-license-for-feature—Enables
no-license-installed-for-feature notifications.
snmp-server enable traps link Enables IF-MIB link notifications. Optionally,
[IETF-extended-linkDown] enables the following specific notifications:
[IETF-extended-linkUp]
[cisco-extended-linkDown] • IETF-extended-linkDown—Enables
[cisco-extended-linkUp] Internet Engineering Task Force (IETF)
[linkDown]
extended link state down notifications.
[linkUp]
• IETF-extended-linkUp—Enables Internet
Example: Engineering Task Force (IETF) extended link
link
state up notifications.
• cisco-extended-linkDown—Enables Cisco
extended link state down notifications.
• cisco-extended-linkUp—Enables Cisco
extended link state up notifications.
• linkDown—Enables IETF link state down
notifications.
• linkUp—Enables IETF link state up
notifications.
snmp-server enable traps ospf [tag] Enables open shortest path first (OSPF)
[lsa] notifications. Optionally, enables the following
[rate-limit rate]
Example: • lsa—Enables OSPF LSA notifications.
ospf • rate-limit rate—Enables rate limits on OSPF
notifications. The range is from 2 to 60
seconds. The default is 10 seconds.
OL-20635-03 13-215
Configuring SNMP
Command Purpose
snmp-server enable traps port-security Enables port-security SNMP notifications.
[access-secure-mac-violation] Optionally, enables the following specific
[trunk-secure-mac-violation]
notifications:
Example: • access-secure-mac-violation—Enables
secure machine access control (MAC)
port-security
violation notifications.
• trunk-secure-mac-violation—Enables
virtual LAN (VLAN) secure MAC violation
notifications.
snmp-server enable traps rf Enables redundancy framework (RF) SNMP
[redundancy-framework] notifications. Optionally, enables the following
Example:
switch(config)# snmp-server enable traps rf • redundancy-framework—Enables RF
Supervisor switchover MIB notifications.
snmp-server enable traps rmon Enables remote monitoring (RMON) SNMP
[fallingAlarm] notifications. Optionally, enables the following
[hcFallingAlarm]
[hcRisingAlarm]
[risingAlarm] • fallingAlarm—Enables RMON falling alarm
notifications.
Example:
switch(config)# snmp-server enable traps • hcFallingAlarm—Enables RMON
rmon high-capacity falling alarm notifications.
• hcRisingAlarm—Enables RMON
high-capacity rising alarm notifications.
• risingAlarm—Enables RMON rising alarm
notifications.
snmp-server enable traps snmp Enables general SNMP notifications. Optionally,
[authentication] enables the following specific notifications:
Example: • authentication—Enables SNMP
switch(config)# snmp-server enable traps authentication notifications.
snmp
snmp-server enable traps stpx Enables STPX MIB notifications. Optionally,
[inconsistency] enables the following specific notifications:
[loop-inconsistency]
[root-inconsistency] • inconsistency—Enables SNMP STPX MIB
inconsistency update notifications.
Example:
switch(config)# snmp-server enable traps • loop-inconsistency—Enables SNMP STPX
stpx MIB loop-inconsistency update notifications.
• root-inconsistency—Enables SNMP STPX
MIB root-inconsistency update notifications.
snmp-server enable traps sysmgr Enables software change notifications.
[cseFailSwCoreNotifyExtended] Optionally, enables the following specific
Example:
notifications:
switch(config)# snmp-server enable traps • cseFailSwCoreNotifyExtended—Enables
sysmgr
software core notifications.
13-216 OL-20635-03
Configuring SNMP
Command Purpose
snmp-server enable traps upgrade Enables upgrade notifications. Optionally,
[UpgradeJobStatusNotify] enables the following specific notifications:
[UpgradeOpNotifyOnCompletion]
• UpgradeJobStatusNotify—Enables upgrade
Example: job status notifications.
upgrade • UpgradeOpNotifyOnCompletion—Enables
upgrade global status notifications.
snmp-server enable traps vtp Enables upgrade notifications. Optionally,
[notifs] enables the following specific notifications:
[vlancreate]
[vlandelete] • notifs—Enables VTP notifications.
Example: • vlancreate—Enables VLAN creation
switch(config)# snmp-server enable traps notifications.
vtp
• vlandelete—Enables VLAN deletion
notifications.
snmp-server enable traps zone Enables default zone change notifications.
[default-zone-behavior-change] Optionally, enables the following specific
[merge-failure]
[merge-success]
notifications:
[request-reject1] • default-zone-behavior-change—Enables
[unsupp-mem]
default zone behavior change notifications.
Example: • merge-failure—Enables merge failure
switch(config)# snmp-server enable traps notifications.
zone
• merge-success—Enables merge success
notifications.
• request-reject1—Enables request reject
notifications.
• unsupp-mem—Enables unsupported
member notifications.
Disabling LinkUp/LinkDown 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).
Use the following command in interface configuration mode to disable linkUp/linkDown notifications
for the interface:
Command Purpose
no snmp trap link-status Disables SNMP link-state traps for the interface.
This command is enabled by default.
Example:
switch(config-if)# no snmp trap link-status
OL-20635-03 13-217
Configuring SNMP
Displaying SNMP ifIndex for an Interface

The SNMP ifIndex is used across multiple SNMP MIBs to link related interface information. The ifIndex
is also used by NetFlow to collect information on an interface.
Use the following command in any mode to display the SNMP ifIndex values for interfaces:
Command Purpose
show interface snmp-ifindex Displays the persistent SNMP ifIndex value from
IF-MIB for all interfaces. Optionally, use the |
Example:
switch# show interface snmp-ifindex | grep
keyword and the grep keyword to search for a
-i Eth12/1 particular interface in the output.
Eth12/1 441974784 (0x1a580000)
Enabling a One-time Authentication for SNMP over TCP

You can enable a one-time authentication for SNMP over a TCP session.
Use the following command in global configuration mode to enable a one-time authentication for SNMP
over TCP:
Command Purpose
snmp-server tcp-session [auth] Enables a one-time authentication for SNMP over
a TCP session. The default is disabled.
Example:
switch(config)# snmp-server tcp-session
Assigning the SNMP Device Contact and Location Information

You can assign the device contact information, which is limited to 32 characters (without spaces) and
the device location.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. snmp-server contact name
3. snmp-server location name
4. show snmp
13-218 OL-20635-03
Configuring SNMP
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 snmp-server contact name Configures sysContact, which is the SNMP contact
name.
Example:
switch(config)# snmp-server contact
Admin
Step 3 snmp-server location name Configures sysLocation, which is the SNMP location.
Example:
switch(config)# snmp-server location
Lab-7
Step 4 show snmp (Optional) Displays information about one or more
destination profiles.
Example:
switch(config)# show snmp
Example:
startup-config
This example shows how to configure the SNMP contact and location information:
switch# config t
switch(config)# snmp contact Admin
switch(config)# snmp location Lab-7
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.
BEFORE YOU BEGIN
Determine the logical network entity instance. For more information on VRFs and protocol instances,
see the Cisco Nexus 7000 Series NX-OS Unicast Routing Configuration Guide, Release 5.x, or the Cisco
Nexus 7000 Series NX-OS Multicast Routing Configuration Guide, Release 5.x.
OL-20635-03 13-219
Configuring SNMP
SUMMARY STEPS
1. config t
2. snmp-server context context-name [instance instance-name] [vrf vrf-name] [topology
topology-name]
3. snmp-server mib community-map community-name context context-name
4. show snmp context
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 snmp-server context context-name Maps an SNMP context to a protocol instance, VRF, or
[instance instance-name] [vrf vrf-name] topology. The names can be any alphanumeric string
[topology topology-name]
up to 32 characters.
Example:
switch(config)# snmp-server context
public1 vrf red
Step 3 snmp-server mib community-map (Optional) Maps an SNMPv2c community to an
community-name context context-name SNMP context. The names can be any alphanumeric
Example:
string up to 32 characters.
switch(config)# snmp-server mib
community-map public context public1
Step 4 show snmp context (Optional) Displays information about one or more
SNMP contexts.
Example:
switch(config)# show snmp context
Example:
startup-config
This example shows how to map VRF red to the SNMPv2c public community string:
switch# config t
switch(config)# vrf context red
switch(config-vrf)# exit
switch(config)# snmp-server context public1 vrf red
switch(config)# snmp-server mib community-map public context public1
13-220 OL-20635-03
Configuring SNMP
This example shows how to map OSPF instance Enterprise to the same SNMPv2c public community
string:
switch# config t
switch(config)# feature ospf
switch(config)# router ospf Enterprise
switch(config-router)# exit
switch(config)# snmp-server context public1 instance Enterprise
switch(config)# snmp-server mib community-map public context public1
Use the following command in global configuration mode to delete the mapping between an SNMP
context and a logical network entity:
Command Purpose
no snmp-server context context-name Deletes the mapping between an SNMP context
[instance instance-name] [vrf vrf-name] and a protocol instance, VRF, or topology. The
[topology topology-name]
names can be any alphanumeric string up to 32
Example: characters.
switch(config)# no snmp-server context
Note Do not enter an instance, VRF, or
public1
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
You can disable SNMP on a device.
Use the following command in global configuration mode to disable SNMP:
Command Purpose
no snmp-server protocol enable Disables SNMP. This command is enabled by
default.
Example:
switch(config)# no snmp-server protocol
enable
Modifying the AAA Synchronization Time

You can modify how long Cisco NX-OS holds the synchronized user configuration.
Use the following command in global configuration mode to modify the AAA synchronization time:
Command Purpose
snmp-server aaa-user cache-timeout seconds Configures how long the AAA synchronized user
configuration stays in the local cache. The range
Example:
switch(config)# snmp-server aaa-user
is from 1 to 86400 seconds. The default is 3600.
cache-timeout 1200.
OL-20635-03 13-221
Verifying the SNMP Configuration
Verifying the SNMP Configuration

To display the SNMP configuration information, perform one of the following tasks:
Command Purpose
show interface snmp-ifindex Displays the SNMP ifIndex value for all
interfaces (from IF-MIB).
show running-config snmp [all] Displays the SNMP running configuration.
show snmp Displays the SNMP status.
show snmp community Displays the SNMP community strings.
show snmp context Displays the SNMP context mapping.
show snmp engineID Displays the SNMP engineID.
show snmp group Displays SNMP roles.
show snmp host Displays information about configured SNMP
hosts.
show snmp session Displays SNMP sessions.
show snmp source-interface Displays information about configured source
interfaces.
show snmp trap Displays the SNMP notifications enabled or
disabled.
show snmp user Displays SNMPv3 users.
Configuration Examples for SNMP

This example shows how to configure Cisco NX-OS to send the Cisco linkUp or Down notifications to
one notification host receiver using the Blue VRF and defines two SNMP users, Admin and NMS:
config t
snmp-server contact [email protected]
snmp-server user Admin auth sha abcd1234 priv abcdefgh
snmp-server user NMS auth sha abcd1234 priv abcdefgh engineID
00:00:00:63:00:01:00:22:32:15:10:03
snmp-server host 192.0.2.1 informs version 3 auth NMS
snmp-server host 192.0.2.1 use-vrf Blue
snmp-server enable traps link cisco
This example shows how to configure SNMP to send traps using an inband port configured at the host
level:
switch# config t
switch(config)# snmp-server host 171.71.48.164 version 2c public
switch(config)# snmp-server host 171.71.48.164 source-interface ethernet 1/2
-------------------------------------------------------------------
-------------------------------------------------------------------
13-222 OL-20635-03

-------------------------------------------------------------------
switch(config)# snmp-server host 171.71.48.164 use_vrf default

-------------------------------------------------------------------
-------------------------------------------------------------------
Use VRF: default

-------------------------------------------------------------------
For additional information related to implementing SNMP, see the following sections:
Related Documents
SNMP CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
MIBs http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Standards
Standards Title
OL-20635-03 13-223
Feature History for SNMP
MIBs
MIBs MIBs Link
• SNMP-COMMUNITY-MIB To locate and download MIBs, go to the following URL:
• SNMP-FRAMEWORK-MIB http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
• SNMP-NOTIFICATION-MIB
• SNMP-TARGET-MIB
• SNMPv2-MIB
Feature History for SNMP

Table 13-5 Feature History for SNMP

SNMP protocol 5.2(1) No change from Release 5.1.
SNMP protocol 5.1(1) No change from Release 5.0.
SNMP notifications 5.0(2) Updated the snmp-server enable traps commands. See the
“Enabling SNMP Notifications” section on page 13-211.
IPv6 support 4.2(1) Supports configuring IPv6 SNMP hosts.
Filter SNMP requests by community using an 4.2(1) Assigns an ACL to an SNMP community to filter SNMP
ACL requests. See the “Filtering SNMP Requests” section on
page 13-205.
Use interfaces for SNMP notification receivers 4.2(1) Adds support to designate an interface to act as the source
interface for SNMP notifications. See the “Configuring
SNMP Notification Receivers” section on page 13-206.
SNMP AAA synchronization 4.0(3) Adds ability to modify the synchronized user configuration
timeout. See the “Modifying the AAA Synchronization
Time” section on page 13-221.
SNMP protocol 4.0(3) Added ability to disable the SNMP protocol. See the
“Disabling SNMP” section on page 13-221.
13-224 OL-20635-03
CHAPTER 14
Configuring RMON
This chapter describes how to configure the RMON feature on Cisco NX-OS devices.
• Information About RMON, page 14-225
• Licensing Requirements for RMON, page 14-227
• Prerequisites for RMON, page 14-227
• Configuring RMON, page 14-228
• Verifying the RMON Configuration, page 14-231
• Configuration Example for RMON, page 14-231
• Related Topics, page 14-231
• Feature History for RMON, page 14-232
Information About RMON

RMON is a Simple Network Management Protocol (SNMP) 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.
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.
Beginning with Cisco NX-OS Release 5.1, RMON is enabled by default, but no alarms are configured
in Cisco NX-OS. You can configure RMON alarms by using the CLI or an SNMP-compatible network
management station.
• RMON Alarms, page 14-226
• RMON Events, page 14-226
OL-20635-03 14-225
Chapter 14 Configuring RMON
Information About RMON

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.14
represents ifInOctets.14).
When you create an alarm, you specify the following parameters:
• MIB object to monitor.
• Sampling interval—The interval that Cisco NX-OS 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 Cisco NX-OS triggers a rising alarm or resets a falling alarm.
• Falling threshold—The value at which Cisco NX-OS triggers a falling alarm or resets a rising alarm.
• Events—The action that Cisco NX-OS 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 will 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 event for a falling alarm and a rising alarm.
High Availability
Cisco NX-OS supports stateless restarts for RMON. After a reboot or supervisor switchover, Cisco
14-226 OL-20635-03
Licensing Requirements for RMON
Cisco NX-OS supports one instance of the RMON per virtual device context (VDC). By default, Cisco
NX-OS places you in the default VDC. See the Cisco Nexus 7000 Series NX-OS Virtual Device Context
RMON is virtual routing and forwarding (VRF) aware. You can configure RMON to use a particular
VRF to reach the RMON SMTP server.
Licensing Requirements for RMON

Cisco NX-OS RMON requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for RMON

RMON has the following prerequisites:

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 configure an RMON alarm only on a MIB object that resolves to an integer.
• When you configure an RMON alarm, the object identifier must be complete with its index so that
it refers to only one object. For example, 1.3.6.1.2.1.2.2.1.14 corresponds to cpmCPUTotal5minRev,
and .1 corresponds to index cpmCPUTotalIndex, which creates object identifier
1.3.6.1.2.1.2.2.1.14.1.
Default Settings
Table 14-1 lists the default settings for RMON parameters.
Table 14-1 Default RMON Parameters
Parameters Default
RMON Enabled beginning with Cisco NX-OS Release 5.1
Alarms None configured
OL-20635-03 14-227
Configuring RMON
Configuring RMON
• Configuring RMON Alarms, page 14-228
• Configuring RMON Events, page 14-230
Cisco IOS.
Configuring RMON Alarms

You can configure RMON alarms on any integer-based SNMP MIB object.
You can optionally specify the following parameters:
• The event-number to trigger if the rising or falling threshold exceeds the specified limit.
• The owner of the alarm.
BEFORE YOU BEGIN
Ensure that you have configured an SNMP user and enabled SNMP notifications (see the “Configuring
SNMP” section on page 13-202).
SUMMARY STEPS
1. config t
2. rmon alarm index mib-object sample-interval {absolute | delta} rising-threshold value
[event-index] falling-threshold value [event-index] [owner name]
or
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]
3. show rmon [alarms | hcalarms]
14-228 OL-20635-03
Configuring RMON
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 rmon alarm index mib-object Creates an RMON alarm. The value range is from
sample-interval {absolute | delta} –2147483647 to 2147483647. The owner name can be
rising-threshold value [event-index]
falling-threshold value [event-index]
any alphanumeric string.
[owner name]
Example:
switch(config)# rmon alarm 20
1.3.6.1.2.1.2.2.1.14.1 2900 delta
rising-threshold 1500 1
falling-threshold 0 owner test
rmon hcalarm index mib-object Creates an RMON high capacity alarm. The value
sample-interval {absolute | delta} range is from –2147483647 to 2147483647. The owner
rising-threshold-high value
rising-threshold-low value [event-index]
name can be any alphanumeric string.
falling-threshold-high value The storage type range is from 1 to 5.
falling-threshold-low value
[event-index] [owner name] [storagetype
type]
Example:
switch(config)# rmon alarm 20
1.3.6.1.2.1.2.2.1.14.16777216 2900 delta
rising-threshold-high 15
rising-threshold-low 151
falling-threshold-high 0
falling-threshold-low 0 owner test
Step 3 show rmon {alarms | hcalarms} (Optional) Displays information about rmon alarms or
high capacity alarms.
Example:
switch(config)# show rmon alarms
Example:
startup-config
OL-20635-03 14-229
Configuring RMON
Configuring RMON Events

You can configure RMON events to associate with RMON alarms. You can reuse the same event with
multiple RMON alarms.
BEFORE YOU BEGIN
Ensure that you have configured an SNMP user and enabled SNMP notifications (see the “Configuring
SNMP” section on page 13-202).
SUMMARY STEPS
1. config t
2. rmon event index [log] [trap string] [owner name] [description string]
3. show rmon events
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 rmon event index [log] [trap string] Configures an RMON event. The trap string, owner
[owner name] [description string] name, and description string can be any alphanumeric
Example:
string.
switch(config)# rmon event 1 trap trap1
Step 3 show rmon events (Optional) Displays information about rmon events.
Example:
switch(config)# show rmon events
Example:
startup-config
14-230 OL-20635-03
Verifying the RMON Configuration
Verifying the RMON Configuration

To display RMON configuration information, perform one of the following tasks:
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.
Configuration Example for RMON

This example shows how to create a delta rising alarm on ifInOctets.14 and associates a notification
event with this alarm:
config t
rmon alarm 20 1.3.6.1.2.1.2.2.1.14.1 2900 delta rising-threshold 1500 1
falling-threshold 0 owner test
rmon event 1 trap trap1
Related Topics
See the following related topics:
• Configuring SNMP, page 13-195
For additional information related to implementing RMON, see the following sections:
Related Documents
RMON CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
OL-20635-03 14-231
Feature History for RMON
Standards
Standards Title
MIBs
MIBs MIBs Link
• RMON-MIB To locate and download MIBs, go to the following URL:
Feature History for RMON

Table 14-2 Feature History for RMON

RMON 5.2(1) No change from Release 5.1.
RMON 5.1(1) Enabled RMON by default.
RMON 5.0(2) No change from Release 4.2.
14-232 OL-20635-03
CHAPTER 15
Configuring Online Diagnostics
This chapter describes how to configure the generic online diagnostics (GOLD) feature on Cisco NX-OS
devices.
• Information About Online Diagnostics, page 15-233
• Licensing Requirements for Online Diagnostics, page 15-237
• Prerequisites for Online Diagnostics, page 15-238
• Configuring Online Diagnostics, page 15-238
• Verifying the Online Diagnostics Configuration, page 15-243
• Configuration Examples for Online Diagnostics, page 15-244
• Feature History for Online Diagnostics, page 15-245
Note For complete syntax and usage information for the commands in this chapter, see the
Cisco Nexus 7000 Series NX-OS System Management Command Reference.
Information About Online Diagnostics

Online diagnostics help you verify that hardware and internal data paths are operating as designed so
that you can rapidly isolate faults.
• Online Diagnostic Overview, page 15-234
• Bootup Diagnostics, page 15-234
• Runtime or Health Monitoring Diagnostics, page 15-235
• On-Demand Diagnostics, page 15-237
OL-20635-03 15-233
Chapter 15 Configuring Online Diagnostics
Online Diagnostic Overview

With online diagnostics, you can test and verify the hardware functionality of the device while the device
is connected to a live network.
The online diagnostics contain tests that check different hardware components and verify the data path
and control signals. Disruptive online diagnostic tests (such as the disruptive loopback test) and
nondisruptive online diagnostic tests (such as the ASIC register check) run during bootup, line module
online insertion and removal (OIR), and system reset. The nondisruptive online diagnostic tests run as
part of the background health monitoring, and you can run these tests on demand.
Online diagnostics are categorized as bootup, runtime or health-monitoring diagnostics, and on-demand
diagnostics. Bootup diagnostics run during bootup, health-monitoring tests run in the background, and
on-demand diagnostics run once or at user-designated intervals when the device is connected to a live
network.
Bootup Diagnostics
Bootup diagnostics run during bootup and detect faulty hardware before Cisco NX-OS brings a module
online. For example, if you insert a faulty module in the device, bootup diagnostics test the module and
take it offline before the device uses the module to forward traffic.
Bootup diagnostics also check the connectivity between the supervisor and module hardware and the
data and control paths for all the ASICs. Table 15-1 describes the bootup diagnostic tests for a module
and a supervisor.
Table 15-1 Bootup Diagnostics
Diagnostic Description
Module
EOBCPortLoopback Disruptive test, not an on-demand test
Ethernet out of band
OBFL Verifies the integrity of the onboard failure logging (OBFL) flash.
1
PortLoopback Disruptive test, not an on-demand test
Sends and receives data on the same port to verify that the port is
operational.
FIPS2 Disruptive test; run only when FIPS is enabled on the system
An internal test that runs during module bootup to validate the
security device on the module.
BootupPortLoopback Disruptive test, not an on-demand test
A PortLoopback test that runs only during module bootup.
15-234 OL-20635-03
Table 15-1 Bootup Diagnostics (continued)
Diagnostic Description
Supervisor
USB Nondisruptive test
Checks the USB controller initialization on a module.
CryptoDevice Nondisruptive test
Checks the Cisco Trusted Security (CTS) device initialization on a
module.
ManagementPortLoopback Disruptive test, not an on-demand test
Tests loopback on the management port of a module.
EOBCPortLoopback Disruptive test, not an on-demand test
Ethernet out of band
OBFL Verifies the integrity of the onboard failure logging (OBFL) flash.
1. The PortLoopback test is supported on all modules except the 48-port 1G copper Ethernet module.
2. F1 Series modules do not support the FIPS test.
Bootup diagnostics log failures to onboard failure logging (OBFL) and syslog and trigger a diagnostic
LED indication (on, off, pass, or fail).
You can configure Cisco NX-OS to either bypass the bootup diagnostics or run the complete set of
bootup diagnostics. See the “Setting the Bootup Diagnostic Level” section on page 15-239.
Runtime or Health Monitoring Diagnostics

Runtime diagnostics are also called health monitoring (HM) diagnostics. These diagnostics provide
information about the health of a live device. They detect runtime hardware errors, memory errors, the
degradation of hardware modules over time, software faults, and resource exhaustion.
Health monitoring diagnostics are nondisruptive and run in the background to ensure the health of a
device that is processing live network traffic. You can enable or disable health monitoring tests or change
their runtime interval. Table 15-2 describes the health monitoring diagnostics and test IDs for a module
and a supervisor.
Table 15-2 Health Monitoring Nondisruptive Diagnostics
Default Default
Diagnostic Interval Setting Description
Module
ASICRegisterCheck 1 minute active Checks read/write access to scratch registers
for the ASICs on a module.
PrimaryBootROM 30 minutes active Verifies the integrity of the primary boot
device on a module.
SecondaryBootROM 30 minutes active Verifies the integrity of the secondary boot
device on a module.
OL-20635-03 15-235
Table 15-2 Health Monitoring Nondisruptive Diagnostics (continued)
Default Default
1
PortLoopback 15 minutes active Verifies connectivity through every port that
is administratively down on every module in
the system.
RewriteEngineLoopback 1 minute active Verifies the integrity of the nondisruptive
loopback for all ports up to the Rewrite
Engine ASIC device.
SnakeLoopback test2 20 minutes active Performs a nondisruptive loopback on all
ports, even those ports that are not in the shut
state. The ports are formed into a snake
during module bootup, and the supervisor
checks the snake connectivity periodically.
Note This test is deprecated in Cisco
NX-OS Release 5.2.
FIPS3 Not Not Runs on CTS-enabled ports when the
applicable applicable interface is enabled with a no shut command.
This internal test validates the security
device on the module.
Supervisor
ASICRegisterCheck 20 seconds active Checks read/write access to scratch registers
for the ASICs on the supervisor.
NVRAM 5 minutes active Verifies the sanity of the NVRAM blocks on
a supervisor.
RealTimeClock 5 minutes active Verifies that the real-time clock on the
supervisor is ticking.
PrimaryBootROM 30 minutes active Verifies the integrity of the primary boot
device on the supervisor.
SecondaryBootROM 30 minutes active Verifies the integrity of the secondary boot
device on the supervisor.
CompactFlash 30 minutes active Verifies access to the internal compact flash
devices.
ExternalCompactFlash 30 minutes active Verifies access to the external compact flash
devices.
PwrMgmtBus 30 seconds active Verifies the standby power management
control bus.
SpineControlBus4 30 seconds active Verifies the availability of the standby spine
module control bus.
SystemMgmtBus 30 seconds active Verifies the availability of the standby system
management bus.
StatusBus 30 seconds active Verifies the status transmitted by the status
bus for the supervisor, modules, and fabric
cards.
15-236 OL-20635-03
Licensing Requirements for Online Diagnostics
Table 15-2 Health Monitoring Nondisruptive Diagnostics (continued)
Default Default
StandbyFabricLoopback 30 seconds active Verifies the connectivity of the standby
supervisor to the crossbars on the spine card.
1. The PortLoopback test is supported on all modules except the 48-port 1G copper Ethernet module.
2. Only F1 Series modules support the SnakeLoopback test.
3. F1 Series modules do not support the FIPS test.
4. Beginning with Cisco NX-OS Release 5.2, the SpineControlBus test is enabled by default on the standby supervisor.
On-Demand Diagnostics
On-demand tests help localize faults and are usually needed in one of the following situations:
• To respond to an event that has occurred, such as isolating a fault.
• In anticipation of an event that may occur, such as a resource exceeding its utilization limit.
You can run all the health monitoring tests on demand.
You can schedule on-demand diagnostics to run immediately. See the “Starting or Stopping an
On-Demand Diagnostic Test” section on page 15-241 for more information.
You can also modify the default interval for a health monitoring test. See the “Activating a Diagnostic
Test” section on page 15-239 for more information.
High Availability
A key part of high availability is detecting hardware failures and taking corrective action while the
device runs in a live network. Online diagnostics in high availability detect hardware failures and provide
feedback to high availability software components to make switchover decisions.
Cisco NX-OS supports stateless restarts for online diagnostics. After a reboot or supervisor switchover,
Cisco NX-OS applies the running configuration.
Cisco NX-OS supports online diagnostics in the default virtual device context (VDC). By default, Cisco
NX-OS places you in the default VDC. See the Cisco Nexus 7000 Series NX-OS Virtual Device Context
Configuration Guide, Release 5.x for more information.
Online diagnostics are virtual routing and forwarding (VRF) aware. You can configure online
diagnostics to use a particular VRF to reach the online diagnostics SMTP server.
Licensing Requirements for Online Diagnostics

Cisco NX-OS Online diagnostics require no license. Any feature not included in a license package is bundled with the
OL-20635-03 15-237
Prerequisites for Online Diagnostics
Prerequisites for Online Diagnostics

Online diagnostics have the following prerequisite:
• If you configure VDCs, install the Advanced Services license and go to the VDC that you want to
configure. For more information, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context

• You cannot run disruptive online diagnostic tests on demand.
• The F1 Series modules support only these tests: ASICRegisterCheck, PrimaryBootROM,
SecondaryBootROM, EOBCPortLoopback, PortLoopback, BootupPortLoopback, and
SnakeLoopback.
• Only F1 Series modules support the SnakeLoopback test.
• The SnakeLoopback test is deprecated in Cisco NX-OS Release 5.2.
Default Settings
Table 15-3 lists the default settings for online diagnostic parameters.
Table 15-3 Default Online Diagnostic Parameters
Parameters Default
Bootup diagnostics level complete
Nondisruptive tests active

• Setting the Bootup Diagnostic Level, page 15-239
• Activating a Diagnostic Test, page 15-239
• Setting a Diagnostic Test as Inactive, page 15-241
• Starting or Stopping an On-Demand Diagnostic Test, page 15-241
• Clearing Diagnostic Results, page 15-242
• Simulating Diagnostic Results, page 15-243
Cisco IOS.
15-238 OL-20635-03
Setting the Bootup Diagnostic Level

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 bootup time.
Note We recommend that you set the bootup online diagnostics level to complete. We do not recommend
bypassing the bootup online diagnostics.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. diagnostic bootup level {complete | bypass}
3. (Optional) show diagnostic bootup level
DETAILED STEPS
Command Purpose
Example:
switch# config t
Enter configuration commands, one per line. End
with CNTL/Z.
switch(config)#
Step 2 diagnostic bootup level {complete | bypass} Configures the bootup diagnostic level to trigger
diagnostics as follows when the device boots:
Example:
switch(config)# diagnostic bootup level complete • complete—Perform all bootup diagnostics. The
default is complete.
• bypass—Do not perform any bootup diagnostics.
Step 3 show diagnostic bootup level (Optional) Displays the bootup diagnostic level (bypass
or complete) that is currently in place on the device.
Example:
switch(config)# show diagnostic bootup level
Example:
startup-config
Activating a Diagnostic Test

You can set a diagnostic test as active and optionally modify the interval (in hours, minutes, and seconds)
at which the test runs.
OL-20635-03 15-239
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. (Optional) diagnostic monitor interval module slot test [test-id | name | all] hour hour min
minutes second sec
3. diagnostic monitor module slot test [test-id | name | all]
4. (Optional) show diagnostic content module {slot | all}
DETAILED STEPS
Command Purpose
Example:
switch# config t
Enter configuration commands, one per line. End
with CNTL/Z.
switch(config)#
Step 2 diagnostic monitor interval module slot test (Optional) Configures the interval at which the specified
[test-id | name | all] hour hour min minutes test is run. If no interval is set, the test runs at the interval
second sec
set previously, or the default interval.
Example: The argument ranges are as follows:
switch(config)# diagnostic monitor interval
module 6 test 3 hour 1 min 0 sec 0 • slot—The range is from 1 to 10.
• test-id—The range is from 1 to 14.
• name—Can be any case-sensitive alphanumeric
• hour —The range is from 0 to 23 hours.
• minute—The range is from 0 to 59 minutes.
• second —The range is from 0 to 59 seconds.
Step 3 diagnostic monitor module slot test [test-id | Activates the specified test.
name | all]
The argument ranges are as follows:
Example:
• slot—The range is from 1 to 10.
switch(config)# diagnostic monitor interval
module 6 test 3 • test-id—The range is from 1 to 14.
• name—Can be any case-sensitive alphanumeric
Step 4 show diagnostic content module {slot | all} (Optional) Displays information about the diagnostics
and their attributes.
Example:
switch(config)# show diagnostic content module 6
15-240 OL-20635-03
Setting a Diagnostic Test as Inactive

You can set a diagnostic test as inactive. Inactive tests keep their current configuration but do not run at
at the scheduled interval.
Use the following command in global configuration mode to set a diagnostic test as inactive:
Command Purpose
no diagnostic monitor module slot test Inactivates the specified test.
[test-id | name | all]
Example:
switch(config)# no diagnostic monitor
interval module 6 test 3 • test-id—The range is from 1 to 14.
• name—Can be any case-sensitive
Starting or Stopping an On-Demand Diagnostic Test

You can start or stop an on-demand diagnostic test. You can optionally modify the number of iterations
to repeat this test, and the action to take if the test fails.
We recommend that you only manually start a disruptive diagnostic test during a scheduled network
maintenance time.
BEFORE YOU BEGIN
SUMMARY STEPS
1. (Optional) diagnostic ondemand iteration number

2. (Optional) diagnostic ondemand action-on-failure {continue failure-count num-fails | stop}
3. diagnostic start module slot test [test-id | name | all | non-disruptive] [port port-number | all]
4. diagnostic stop module slot test [test-id | name | all]
5. (Optional) show diagnostic status module slot
OL-20635-03 15-241
DETAILED STEPS
Command Purpose
Step 1 diagnostic ondemand iteration number (Optional) Configures the number of times that the
on-demand test runs. The range is from 1 to 999. The
Example:
switch# diagnostic ondemand iteration 5
default is 1.
Step 2 diagnostic ondemand action-on-failure {continue (Optional) Configures the action to take if the on-demand
failure-count num-fails | stop} test fails. The num-fails range is from 1 to 999. The
Example:
default is 1.
switch# diagnostic ondemand action-on-failure
stop
Step 3 diagnostic start module slot test [test-id | name Starts one or more diagnostic tests on a module. The
| all | non-disruptive] [port port-number | all] module slot range is from 1 to 10. The test-id range is
Example:
from 1 to 14. The test name can be any case-sensitive
switch# diagnostic start module 6 test all alphanumeric string up to 32 characters. The port range
is from 1 to 48.
Step 4 diagnostic stop module slot test [test-id | name Stops one or more diagnostic tests on a module. The
| all] module slot range is from 1 to 10. The test-id range is
Example:
from 1 to 14. The test name can be any case-sensitive
switch# diagnostic stop module 6 test all alphanumeric string up to 32 characters.
Step 5 show diagnostic status module slot (Optional) Verifies that the diagnostic has been
scheduled.
Example:
switch# show diagnostic status module 6
Clearing Diagnostic Results

You can clear diagnostic test results.
Use the following command in any mode to clear the diagnostic test results:
Command Purpose
diagnostic clear result module [slot | all] Clears the test result for the specified test.
test {test-id | all}
Example:
switch# diagnostic clear result module 2
test all • test-id—The range is from 1 to 14.
15-242 OL-20635-03
Verifying the Online Diagnostics Configuration
Simulating Diagnostic Results

You can simulate a diagnostic test result.
Use the following command in any mode to simulate a diagnostic test result:
Command Purpose
diagnostic test simulation module slot test Simulates a test result. The test-id range is from 1
test-id {fail | random-fail | success} to 14. The port range is from 1 to 48.
[port number | all]
Example:
switch# diagnostic test simulation module 2
test 2 fail
Use the following command in any mode to clear the simulated diagnostic test result:
Command Purpose
diagnostic test simulation module slot test Clears the simulated test result. The test-id range
test-id clear is from 1 to 14.
Example:
switch# diagnostic test simulation module 2
test 2 clear
Verifying the Online Diagnostics Configuration

To display online diagnostics configuration information, perform one of the following tasks:
Command Purpose
show diagnostic bootup level Displays information about bootup diagnostics.
show diagnostic content module {slot | all} Displays information about diagnostic test
content for a module.
show diagnostic description module slot test Displays the diagnostic description.
[test-name | all]
show diagnostic events [error | info] Displays diagnostic events by error and
information event type.
show diagnostic ondemand setting Displays information about on-demand
diagnostics.
show diagnostic result module slot [test Displays information about the results of a
[test-name | all]] [detail] diagnostic.
show diagnostic simulation module slot Displays information about a simulated
diagnostic.
show diagnostic status module slot Displays the test status for all tests on a module.
OL-20635-03 15-243
Configuration Examples for Online Diagnostics
Command Purpose
show hardware capacity [eobc | Displays information about the hardware
fabric-utilization | forwarding | interface | capabilities and current hardware utilization by
module | power] the system.
show module Displays module information including the online
diagnostic test status.
Configuration Examples for Online Diagnostics

This example shows how to start all on-demand tests on module 6:
diagnostic start module 6 test all
This example shows how to activate test 2 and set the test interval on module 6:
conf t
diagnostic monitor module 6 test 2
diagnostic monitor interval module 6 test 2 hour 3 min 30 sec 0
For additional information related to implementing online diagnostics, see the following sections:
Related Documents
Online diagnostics CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Standards
Standards Title
15-244 OL-20635-03
Feature History for Online Diagnostics

Table 15-4 Feature History for Online Diagnostics

Online diagnostics (GOLD) 5.2(1) Enabled the SpineControlBus test on the standby
supervisor.
Online diagnostics (GOLD) 5.2(1) Deprecated the SnakeLoopback test on F1 Series modules.
Online diagnostics (GOLD) 5.1(2) Added support for the SnakeLoopback test on F1 Series
modules.
Online diagnostics (GOLD) 5.1(1) Added support for the FIPS and BootupPortLoopback tests.
Online diagnostics (GOLD) 5.0(2) No change from Release 4.2.
Online diagnostics (GOLD) 4.2(1) Added support for the PortLoopback, StatusBus, and
StandbyFabricLoopback tests.
Online diagnostics (GOLD) 4.0(1) This feature was introduced.
OL-20635-03 15-245
15-246 OL-20635-03
CHAPTER 16
Configuring the Embedded Event Manager
This chapter describes how to configure the Embedded Event Manager (EEM) to detect and handle
critical events on Cisco NX-OS devices.
• Information About EEM, page 16-247
• Licensing Requirements for EEM, page 16-252
• Prerequisites for EEM, page 16-252
• Configuring EEM, page 16-253
• Verifying the EEM Configuration, page 16-266
• Configuration Examples for EEM, page 16-267
• Feature History for EEM, page 16-268
Information About EEM

EEM monitors events that occur on your device and takes action to recover or troubleshoot these events,
based on your configuration.
• EEM Overview, page 16-248
• Policies, page 16-248
• Event Statements, page 16-249
• Action Statements, page 16-250
• VSH Script Policies, page 16-250
• Environment Variables, page 16-251
• EEM Event Correlation, page 16-251
OL-20635-03 16-247
Chapter 16 Configuring the Embedded Event Manager
EEM Overview
EEM consists of three major components:
• Event statements—Events to monitor from another Cisco NX-OS component that may require some
action, workaround, or notification.
• Action statements —An action that EEM can take, such as sending an e-mail, or disabling an
interface, to recover from an event.
• Policies—An event paired with one or more actions to troubleshoot or recover from the event.
Policies
An EEM policy consists of an event statement and one or more action statements. The event statement
defines the event to look for as well as the filtering characteristics for the event. The action statement
defines the action EEM takes when the event occurs.
Figure 16-1 shows the two basic statements in an EEM policy.
Figure 16-1 EEM Policy Statements
EEM Policy
Event Statement Action Statement
Tells your system: Look for this Tells your system: If that event
specific event to happen. happens, do these things.
For example, when a card is For example, when a card is

removed. removed, log the details. 186905
You can configure EEM policies using the CLI or a VSH script.
EEM gives you a device-wide view of policy management. You configure EEM policies on the
supervisor, and EEM pushes the policy to the correct module based on the event type. EEM takes any
actions for a triggered event either locally on the module or on the supervisor (the default option).
EEM maintains event logs on the supervisor.
Cisco NX-OS has a number of preconfigured system policies. These system policies define many
common events and actions for the device. System policy names begin with two underscore characters
(__).
You can create user policies to suit your network. If you create a user policy, any actions in your policy
occur after EEM triggers any system policy actions related to the same event as your policy. To configure
a user policy, see the “Defining a User Policy Using the CLI” section on page 16-254.
You can also override some system policies. The overrides that you configure take the place of the
system policy. You can override the event or the actions.
Use the show event manager system-policy command to view the preconfigured system policies and
determine which policies that you can override.
To configure an overriding policy, see the “Overriding a Policy” section on page 16-261.
16-248 OL-20635-03
Note You should use the show running-config eem command to check the configuration of each policy. An
override policy that consists of an event statement and no action statement triggers no action and no
notification of failures.
Note Your override policy should always include an event statement. An override policy without an event
statement overrides all possible events in the system policy.
Event Statements
An event is any device activity for which some action, such as a workaround or a notification, should be
taken. In many cases, these events are related to faults in the device such as when an interface or a fan
malfunctions.
EEM defines event filters so only critical events or multiple occurrences of an event within a specified
time period trigger an associated action.
Figure 16-2 shows events that are handled by EEM.
Figure 16-2 EEM Overview
Events
System_switchover
File_system_events
HAP_reset
OIR
fanabsent
fanbad
tempsensor
module_failure
Event Manager
Validates and records user-defined Dynamically registers the following:
User-defined Policy policy information.
– event names
(Defined in CLI in Directs event notifications.
– event descriptions
an applet or script.)
Dir ects policy actions. – event actions
Logs e vents. event parameters
–
Filters events and matches with policies
186904
Event Log
OL-20635-03 16-249
Event statements specify the event that triggers a policy to run. In Cisco NX-OS Releases prior to 5.2,
you can configure only one event statement per policy. However, beginning in Cisco NX-OS Release 5.2,
you can configure multiple event triggers. For more information on configuring multiple events, see the
“EEM Event Correlation” section on page 16-251.
EEM schedules and runs policies on the basis of event statements. EEM examines the event and action
commands and runs them as defined.
Note If you want to allow the triggered event to process any default actions, you must configure the EEM
policy to allow the event default action statement.
Action Statements
Action statements describe the action triggered by a policy. Each policy can have multiple action
statements. If no action is associated with a policy, EEM still observes events but takes no actions.
EEM supports the following actions in action statements:
• Execute any CLI commands.
• Update a counter.
• Log an exception.
• Force the shutdown of any module.
• Reload the device.
• Shut down specified modules because the power is over budget.
• Generate a syslog message.
• Generate a Call Home event.
• Generate an SNMP notification.
• Use the default action for the system policy.
policy to allow the default action. For example, if you match a CLI command in a match statement, you
must add the event-default action statement to the EEM policy or EEM will not allow the CLI command
to execute.
Note Verify that your action statements within your user policy or overriding policy do not negate each other
or adversely affect the associated system policy.
VSH Script Policies

You can also write policies in a VSH script, using a text editor. These policies have an event statement
and action statement(s) just as other policies, and these policies can either augment or override system
policies. After you write your VSH script policy, copy it to the device and activate it. To configure a
policy in a VSH script, see the “Defining a Policy using a VSH Script” section on page 16-260.
16-250 OL-20635-03
Environment Variables
You can define environment variables for EEM that are available for all policies. Environment variables
are useful for configuring common values that you can use in multiple policies. For example, you can
create an environment variable for the IP address of an external e-mail server.
You can use an environment variable in action statements by using the parameter substitution format.
Example 16-1 shows a sample action statement to force a module 1 shutdown, with a reset reason of
“EEM action.”
Example 16-1 Action Statement
switch (config-eem-policy)# action 1.0 forceshut module 1 reset-reason “EEM action.”
If you define an environment variable for the shutdown reason, called default-reason, you can replace
that reset reason with the environment variable, as shown in Example 16-2.
Example 16-2 Action Statement with Environment Variable
switch (config-eem-policy)# action 1.0 foreshut module 1 reset-reason $default-reason
You can reuse this environment variable in any policy. For more information on environment variables,
see the “Defining an Environment Variable” section on page 16-253.
EEM Event Correlation

Beginning with Cisco NX-OS Release 5.2, you can trigger an EEM policy based on a combination of
events. First, you use the tag keyword to create and differentiate multiple events in the EEM policy. Then
using a set of boolean operators (and, or, andnot), along with the count and time, you can define a
combination of these events to trigger a custom action.
Note For information on configuring EEM event correlation, see the “Defining a User Policy Using the CLI”
High Availability
Cisco NX-OS supports stateless restarts for EEM. After a reboot or supervisor switchover, Cisco NX-OS
applies the running configuration.
You configure EEM in the virtual device context (VDC) that you are logged into. By default, Cisco
NX-OS places you in the default VDC. You must be in this VDC to configure policies for module-based
events.
Not all actions or events are visible in all VDCs. You must have network-admin or vdc-admin privileges
to configure policies.
See the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x, for
more information on VDCs.
OL-20635-03 16-251
Licensing Requirements for EEM
Licensing Requirements for EEM

Cisco NX-OS EEM requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for EEM

EEM has the following prerequisites:
• You must have network-admin or vdc-admin user privileges to configure EEM.

EEM has the following configuration guidelines and limitations:
• The maximum number of configurable EEM policies is 500.
• Action statements within your user policy or overriding policy should not negate each other or
adversely affect the associated system policy.
• If you want to allow a triggered event to process any default actions, you must configure the EEM
policy to allow the default action. For example, if you match a CLI command in a match statement,
you must add the event-default action statement to the EEM policy or EEM will not allow the CLI
command to execute.
• An override policy that consists of an event statement and no action statement triggers no action and
no notification of failures.
• An override policy without an event statement overrides all possible events in the system policy.
• The following rules apply to regular command expressions: all keywords must be expanded, and
only the * symbol can be used for argument replacement.
• EEM event correlation is supported only on the supervisor module, not on individual line cards.
• EEM event correlation is not supported across different modules within a single policy.
• EEM event correlation supports up to four event statements in a single policy. The event types can
be the same or different, but only these event types are supported: cli, counter, module,
module-failure, oir, snmp, syslog, and track.
• When more than one event statement is included in an EEM policy, each event statement must have
a tag keyword with a unique tag argument.
• EEM event correlation does not override the system default policies.
• Default action execution is not supported for policies that are configured with tagged events.
16-252 OL-20635-03
Default Settings
Default Settings
Table 16-1 lists the default settings for EEM parameters.
Table 16-1 Default EEM Parameters
Parameters Default
System policies Active
Configuring EEM
You can create policies that contain actions to take based on system policies. To display information
about the system policies, use the show event manager system-policy command. For more information
about system policies, see the “Embedded Event Manager System Events and Configuration Examples”
appendix.
• Defining an Environment Variable, page 16-253
• Defining a User Policy Using the CLI, page 16-254
• Defining a Policy using a VSH Script, page 16-260
• Registering and Activating a VSH Script Policy, page 16-261
• Overriding a Policy, page 16-261
• Configuring Memory Thresholds, page 16-263
• Configuring Syslog as EEM Publisher, page 16-265
Defining an Environment Variable

You can define a variable to serve as a parameter in an EEM policy.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. event manager environment variable-name variable-value
3. (Optional) show event manager environment {variable-name | all}
OL-20635-03 16-253
Configuring EEM
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 event manager environment variable-name Creates an environment variable for EEM. The
variable-value variable-name can be any case-sensitive alphanumeric
Example:
string up to 29 characters. The variable-value can be
switch(config)# event manager any quoted alphanumeric string up to 39 characters,
environment emailto “[email protected]”
Step 3 show event manager environment (Optional) Displays information about the configured
{variable-name | all} environment variables.
Example:
switch(config)# show event manager
environment all
Example:
startup-config
Defining a User Policy Using the CLI

You can define a user policy using the CLI to the device.
• Configuring Event Statements, page 16-256
• Configuring Action Statements, page 16-259
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. event manager applet applet-name
3. (Optional) description policy-description
4. event event-statement
(Repeat Step 4 for multiple event statements.)
5. (Optional) tag tag {and | andnot | or} tag [and | andnot | or {tag}] {happens occurs in seconds}
6. action number[.number2] action-statement
(Repeat Step 6 for multiple action statements.)
16-254 OL-20635-03
Configuring EEM
7. (Optional) show event manager policy-state name [module module-id]

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 event manager applet applet-name Registers the applet with EEM and enters applet
configuration mode. The applet-name can be any
Example:
switch(config)# event manager applet
monitorShutdown
switch(config-applet)#
Step 3 description policy-description (Optional) Configures a descriptive string for the
policy. The string can be any alphanumeric string up to
Example:
switch(config-applet)# description
80 characters. Enclose the string in quotation marks.
“Monitors interface shutdown.”
Step 4 event event-statement Configures the event statement for the policy. See the
“Configuring Event Statements” section on
Example:
switch(config-applet)# event cli match
page 16-256.
“shutdown” Repeat Step 4 for multiple event statements.
Step 5 tag tag {and | andnot | or} tag [and | (Optional) Correlates multiple events in the policy.
andnot | or {tag}] {happens occurs in
seconds} The range for the occurs argument is from 1 to
4294967295. The range for the seconds argument is
Example: from 0 to 4294967295 seconds.
switch(config-applet)# tag one or two
happens 1 in 10000
Step 6 action number[.number2] action-statement Configures an action statement for the policy. See the
“Configuring Action Statements” section on
Example:
switch(config-applet)# action 1.0 cli
page 16-259.
show interface e 3/1 Repeat Step 6 for multiple action statements.
Step 7 show event manager policy-state name (Optional) Displays information about the status of the
[module module-id] configured policy.
Example:
switch(config-applet)# show event
manager policy-state monitorShutdown
Example:
startup-config
OL-20635-03 16-255
Configuring EEM
Configuring Event Statements

Use one of the following commands in EEM configuration mode to configure an event statement:
Command Purpose
event cli [tag tag] match expression [count Triggers an event if you enter a command that
repeats | time seconds] matches the regular expression.
Example: The tag tag keyword-argument pair identifies this
switch(config-applet)# event cli match specific event when multiple events are included
“shutdown”
in the policy.
The repeats range is from 1 to 65000. The time
range, in seconds, is from 0 to 4294967295, where
0 indicates no time limit.
event counter [tag tag] name counter Triggers an event if the counter crosses the entry
entry-val entry entry-op {eq | ge | gt | le threshold based on the entry operation. The event
| lt |ne} [exit-val exit exit-op {eq | ge |
gt | le | lt |ne}]
resets immediately. Optionally, you can configure
the event to reset after the counter passes the exit
Example: threshold.
switch(config-applet)# event counter name
mycounter entry-val 20 gt The tag tag keyword-argument pair identifies this
specific event when multiple events are included
in the policy.
The counter name can be any case-sensitive,
alphanumeric string up to 28 characters. The entry
and exit value ranges are from 0 to 2147483647.
event fanabsent [fan number] time seconds Triggers an event if a fan is removed from the
device for more than the configured time, in
Example:
switch(config-applet)# event fanabsent time
seconds. The number range is module dependent.
300 The seconds range is from 10 to 64000.
event fanbad [fan number] time seconds Triggers an event if a fan fails for more than the
configured time, in seconds. The number range is
Example:
switch(config-applet)# event fanbad time
module dependent. The seconds range is from 10
3000 to 64000.
event gold module {slot | all} test Triggers an event if the named online diagnostic
test-name [severity {major | minor | test experiences the configured failure severity for
moderate}] testing-type {bootup |
monitoring | ondemand | scheduled}
the configured number of consecutive failures.
consecutive-failure count The slot range is from 1 to 10. The test-name is
the name of a configured online diagnostic test.
Example: The count range is from 1 to 1000.
switch(config-applet)# event gold module 2
test ASICRegisterCheck testing-type
ondemand consecutive-failure 2
event memory {critical | minor | severe} Triggers an event if a memory threshold is
crossed. See also the “Configuring Memory
Example:
switch(config-applet)# event memory
Thresholds” section on page 16-263.
critical
16-256 OL-20635-03
Configuring EEM
Command Purpose
event module [tag tag] status {online | Triggers an event if the specified module enters
offline | any} module {all | module-num} the selected status.
switch(config-applet)# event module status specific event when multiple events are included
offline module all
in the policy.
event module-failure [tag tag] type Triggers an event if a module experiences the
failure-type module {slot | all} count failure type configured. See the Cisco Nexus 7000
repeats [time seconds]
Series NX-OS System Management Command
Example: Reference for information on the failure types.
switch(config-applet)# event module-failure
The tag tag keyword-argument pair identifies this
type lc-failed module 3 count 1
in the policy.
The repeats range is from 0 to 4294967295. The
seconds range is from 0 to 4294967295, where 0
indicates no time limit.
event oir [tag tag] {fan | module | Triggers an event if the configured device element
powersupply} {anyoir | insert | remove} (fan, module, or power supply) is inserted or
[number]
removed from the device.
switch(config-applet)# event oir fan remove
4
in the policy.
You can optionally configure a specific fan,
module, or power supply number. The number
range is as follows:
• Fan number—Module dependent.
• Module number—Device dependent.
• Power supply number—The range is from 1
to 3.
event policy-default count repeats [time Uses the event configured in the system policy.
seconds] Use this option for overriding policies.
Example: The repeats range is from 1 to 65000. The seconds
switch(config-applet)# event policy-default range is from 0 to 4294967295, where 0 indicates
count 3
no time limit.
event poweroverbudget Triggers an event if the power budget exceeds the
capacity of the configured power supplies.
Example:
switch(config-applet)# event
poweroverbudget
OL-20635-03 16-257
Configuring EEM
Command Purpose
event snmp [tag tag] oid oid get-type Triggers an event if the SNMP OID crosses the
{exact | next} entry-op {eq | ge | gt | le entry threshold based on the entry operation. The
| lt |ne} entry-val entry [exit-comb {and |
or}] exit-op {eq | ge | gt | le | lt |ne}
event resets immediately, or optionally you can
exit-val exit exit-time time configure the event to reset after the counter
polling-interval interval passes the exit threshold. The OID is in dotted
decimal notation.
Example:
switch(config-applet)# event snmp oid The tag tag keyword-argument pair identifies this
1.3.6.1.2.1.31.1.1.1.6 get-type next specific event when multiple events are included
entry-op lt 300 entry-val 0 exit-op eq 400 in the policy.
exit-time 30 polling-interval 300
The entry and exit value ranges are from 0 to
18446744073709551615. The time, in seconds, is
from 0 to 2147483647. The interval, in seconds, is
from 1 to 2147483647.
event storm-control Triggers an event if traffic on a port exceeds the
configured storm control threshold.
Example:
switch(config-applet)# event storm-control
event sysmgr memory [module module-num] Triggers an event if the specified system manager
major major-percent minor minor-percent memory threshold is exceeded. The range for the
clear clear-percent
percentage is from 1 to 99.
Example:
switch(config-applet)# event sysmgr memory
minor 80
event sysmgr switchover count count time Triggers an event if the specified switchover count
interval is exceeded within the time interval specified. The
Example:
switchover count is from 1 to 65000. The time
switch(config-applet)# event sysmgr interval is from 0 to 2147483647.
switchover count 10 time 1000
event temperature [module slot] [sensor Triggers an event if the temperature sensor
number] threshold {any | major | minor} exceeds the configured threshold. The sensor
Example:
range is from 1 to 18.
switch(config-applet)# event temperature
module 2 threshold any
event track [tag tag] object-number state Triggers an event if the tracked object is in the
{any | down | up} configured state.
switch(config-applet)# event track 1 state specific event when multiple events are included
down
in the policy.
The object-number range is from 1 to 500.
16-258 OL-20635-03
Configuring EEM
Configuring Action Statements

Use the following commands in EEM configuration mode to configure action statements:
Command Purpose
action number[.number2] cli command1 Runs the configured CLI commands. You can
[command2...] [local] optionally run the commands on the module
Example:
where the event occurred. The action label is in
switch(config-applet)# action 1.0 cli “show the format number1.number2.
interface e 3/1“
number can be any number up to 16 digits. The
range for number2 is from 0 to 9.
action number[.number2] counter name Modifies the counter by the configured value and
counter value val op {dec | inc | nop | operation. The action label is in the format
set}
number1.number2.
Example: number can be any number up to 16 digits. The
switch(config-applet)# action 2.0 counter
name mycounter value 20 op inc
The counter name can be any case-sensitive,
alphanumeric string up to 28 characters. The val
can be an integer from 0 to 2147483647 or a
substituted parameter.
action number[.number2] event-default Executes the default action for the associated
event. The action label is in the format
Example:
switch(config-applet)# action 1.0
number1.number2.
event-default number can be any number up to 16 digits. The
action number[.number2] forceshut [module Forces a module, crossbar, or the entire system to
slot | xbar xbar-number] reset-reason shut down. The action label is in the format
seconds
number1.number2.
switch(config-applet)# action 1.0 forceshut
module 2 reset-reason “flapping links”
The reset reason is a quoted alphanumeric string
action number[.number2] overbudgetshut Forces one or more modules or the entire system
[module slot [- slot]] to shut down because of a power overbudget issue.
switch(config-applet)# action 1.0 range for number2 is from 0 to 9.
overbudgetshut module 3-5
action number[.number2] policy-default Executes the default action for the policy that you
are overriding. The action label is in the format
Example:
switch(config-applet)# action 1.0
number1.number2.
policy-default number can be any number up to 16 digits. The
OL-20635-03 16-259
Configuring EEM
Command Purpose
action number[.number2] reload [module slot Forces one or more modules or the entire system
[- slot]] to reload.
switch(config-applet)# action 1.0 reload range for number2 is from 0 to 9.
module 3-5
action number[.number2] snmp-trap Sends an SNMP trap with the configured data.
{[intdata1 data [intdata2 data] [strdata number can be any number up to 16 digits. The
string]}
Example: The data arguments can by any number up to 80
switch(config-applet)# action 1.0 snmp-trap
digits. The string can be any alphanumeric string
strdata “temperature problem”
action number[.number2] syslog [priority Sends a customized syslog message at the
prio-val] msg error-message configured priority. number can be any number up
Example:
to 16 digits. The range for number2 is from 0 to 9.
switch(config-applet)# action 1.0 syslog The error-message can be any quoted
priority notifications msg “cpu high”
policy to allow the default action. For example, if you match a CLI command in a match statement, you
must add the event-default action statement to the EEM policy or EEM will not allow the CLI command
to execute. You can use the terminal event-manager bypass command to allow all EEM policies with
CLI matches to execute the CLI command.
Defining a Policy using a VSH Script

You can define a policy using a VSH script.
BEFORE YOU BEGIN
Ensure that you are logged in with administrator privileges.
Ensure that your script name is the same name as the script filename.
DETAILED STEPS
Step 1 In a text editor, list the commands that define the policy.
Step 2 Name the text file and save it.
Step 3 Copy the file to the following system directory:
bootflash://eem/user_script_policies
16-260 OL-20635-03
Configuring EEM
Registering and Activating a VSH Script Policy

You can register and activate a policy defined in a VSH script.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. event manager policy policy-script
3. (Optional) show event manager policy internal name
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 event manager policy policy-script Registers and activates an EEM script policy. The
policy-script can be any case-sensitive alphanumeric
Example:
switch(config)# event manager policy
moduleScript
Step 3 show event manager policy internal name (Optional) Displays information about the configured
policy.
Example:
switch(config)# show event manager
policy internal moduleScript
Example:
startup-config
Overriding a Policy
You can override a system policy.
BEFORE YOU BEGIN
OL-20635-03 16-261
Configuring EEM
SUMMARY STEPS
1. config t
2. (Optional) show event manager policy-state system-policy
3. event manager applet applet-name override system-policy
4. (Optional) description policy-description
5. event event-statement
6. action number action-statement
(Repeat Step 6 for multiple action statements.)
7. (Optional) show event manager policy-state name
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 show event manager policy-state (Optional) Displays information about the system
system-policy policy that you want to override, including thresholds.
Example:
Use the show event manager system-policy
switch(config-applet)# show event command to find the system policy names. For
manager policy-state __ethpm_link_flap information about system policies, see the “Embedded
Policy __ethpm_link_flap Event Manager System Events and Configuration
Cfg count : 5 Examples” appendix.
Cfg time interval : 10.000000
(seconds)
Hash default, Count 0
Step 3 event manager applet applet-name Overrides a system policy and enters applet
override system-policy configuration mode. The applet-name can be any
Example:
switch(config)# event manager applet The system-policy must be one of the existing system
ethport override __ethpm_link_flap policies.
Step 4 description policy-description (Optional) Configures a descriptive string for the
policy. The string can be any alphanumeric string up to
Example:
switch(config-applet)# description
80 characters. Enclose the string in quotation marks.
“Overrides link flap policy.”
Step 5 event event-statement Configures the event statement for the policy. See the
“Configuring Event Statements” section on
Example:
switch(config-applet)# event
page 16-256.
policy-default count 2 time 1000
16-262 OL-20635-03
Configuring EEM
Command Purpose
Step 6 action number action-statement Configures an action statement for the policy. See the
“Configuring Action Statements” section on
Example:
switch(config-applet)# action 1.0 syslog
page 16-259.
priority warnings msg “Link is Repeat Step 6 for multiple action statements.
flapping.”
Step 7 show event manager policy-state name (Optional) Displays information about the configured
policy.
Example:
switch(config-applet)# show event
manager policy-state ethport
Example:
startup-config
Configuring Memory Thresholds

You can set the memory thresholds used to trigger events and set whether the operating system should
kill processes if it cannot allocate memory.
BEFORE YOU BEGIN
Ensure that you are logged in with administrator privileges.
SUMMARY STEPS
1. config t
2. system memory-thresholds minor minor severe severe critical critical
3. (Optional) system memory-thresholds threshold critical no-process-kill
4. (Optional) show running-config | include “system memory”
OL-20635-03 16-263
Configuring EEM
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 system memory-thresholds minor minor Configures the system memory thresholds that
severe severe critical critical generate EEM memory events. The default values are
Example:
as follows:
switch(config)# system memory-thresholds • Minor—85
minor 60 severe 70 critical 80
• Severe—90
• Critical—95
When these memory thresholds are exceeded, the
system generates the following syslogs:
• 2009 May 7 17:06:30 switch %$ VDC-1 %$
%PLATFORM-2-MEMORY_ALERT: Memory
Status Alert : MINOR
• 2009 May 7 17:06:30 switch %$ VDC-1 %$
Status Alert : SEVERE
• 2009 May 7 17:06:30 switch %$ VDC-1 %$
Status Alert : CRITICAL
• 2009 May 7 17:06:35 switch %$ VDC-1 %$
Status Alert : MINOR ALERT RECOVERED
• 2009 May 7 17:06:35 switch %$ VDC-1 %$
Status Alert : SEVERE ALERT RECOVERED
• 2009 May 7 17:06:35 switch %$ VDC-1 %$
Status Alert : CRITICAL ALERT RECOVERED
Step 3 system memory-thresholds threshold (Optional) Configures the system to not kill processes
critical no-process-kill when the memory cannot be allocated. The default
Example:
value is to allow the system to kill processes, starting
switch(config)# system memory-thresholds with the one that consumes the most memory.
threshold critical no-process-kill
16-264 OL-20635-03
Configuring EEM
Command Purpose
Step 4 show running-config | include “system (Optional) Displays information about the system
memory” memory configuration.
Example:
switch(config-applet)# show
running-config | include “system memory”
Example:
startup-config
Configuring Syslog as EEM Publisher

You can monitor syslog messages from the switch.
BEFORE YOU BEGIN
EEM should be available for registration by syslog.

The syslog daemon must be configured and executed.
RESTRICTIONS
The maximum number of searchable strings to monitor syslog messages is 10.
SUMMARY STEPS
1. config t
2. event manager applet applet-name
3. event syslog [tag tag] {occurs number | period seconds | pattern msg-text | priority priority}
DETAILED STEPS
Command Purpose
Step 1 config t Enters global configuration mode.
Example:
switch# config t
switch(config)#
Step 2 event manager applet applet-name Registers an applet with EEM and enters applet
configuration mode.
Example:
switch(config)# event manager applet abc
OL-20635-03 16-265
Verifying the EEM Configuration
Command Purpose
Step 3 event syslog [tag tag] {occurs number | Monitors syslog messages and invokes the policy
period seconds | pattern msg-text | based on the search string in the policy.
priority priority}
• The tag tag keyword-argument pair identifies this
Example: specific event when multiple events are included
switch(config-applet)# event syslog
in the policy.
occurs 10
• The occurs number keyword-argument pair
specifies the number of occurrences. The range is
from 1 to 65000.
• The period seconds keyword-argument pair
specifies the interval during which the event
occurs. The range is from 1 to 4294967295.
• The pattern msg-text keyword-argument pair
specifies the matching regular expression. The
pattern can contain character text, an environment
variable, or a combination of the two. If the string
contains embedded blanks, it is enclosed in
quotation marks.
• The priority priority keyword-argument pair
specifies the priority of the syslog messages. If
this keyword is not selected, all syslog messages
are set at the informational priority level.
Example:
switch(config-applet)# copy
Verifying the EEM Configuration

To display EEM configuration information, perform one of the following tasks:
Command Purpose
show event manager environment Displays information about the event manager
[variable-name | all] environment variables.
show event manager event-types [event | all | Displays information about the event manager
module slot] event types.
show event manager history events [detail] Displays the history of events for all policies.
[maximum num-events] [severity {catastrophic
| minor | moderate | severe}]
show event manager policy internal Displays information about the configured
[policy-name] [inactive] policies.
show event manager policy-state policy-name Displays information about the policy state,
including thresholds.
show event manager script system [policy-name Displays information about the script policies.
| all]
16-266 OL-20635-03
Configuration Examples for EEM
Command Purpose
show event manager system-policy [all] Displays information about the predefined system
policies.
show running-config eem Displays information about the running
configuration for EEM.
show startup-config eem Displays information about the startup
configuration for EEM.
Configuration Examples for EEM

This example shows how to override the __lcm_module_failure system policy by changing the threshold
for just module 3 hitless upgrade failures. This example also sends a syslog message. The settings in the
system policy, __lcm_module_failure, apply in all other cases.
event manager applet example2 override __lcm_module_failure
event module-failure type hitless-upgrade-failure module 3 count 2
action 1 syslog priority errors msg module 3 “upgrade is not a hitless upgrade!”
action 2 policy-default
This example shows how to override the __ethpm_link_flap system policy and shuts down the interface.
event manager applet ethport override __ethpm_link_flap
event policy-default count 2 time 1000
action 1 cli conf t
action 2 cli int et1/1
action 3 cli no shut
This example creates an EEM policy that allows the CLI command to execute but triggers an SNMP
notification when a user enters configuration mode on the device:
event manager applet TEST
event cli match "conf t"
action 1.0 snmp-trap strdata "Configuration change"
action 2.0 event-default
Note You must add the event-default action statement to the EEM policy, or EEM will not allow the
CLI command to execute.
This example shows how to correlate multiple events in an EEM policy and execute the policy based on
a combination of the event triggers. In this example, the EEM policy is triggered if one of the specified
syslog patterns occurs within 120 seconds.
event manager applet eem-correlate
event syslog tag one pattern "copy bootflash:.* running-config.*”
event syslog tag two pattern “copy run start”
event syslog tag three pattern “hello”
tag one or two or three happens 1 in 120
action 1.0 reload module 1
Note For additional EEM configuration examples, see Appendix 1, “Embedded Event Manager System
Events and Configuration Examples.”
OL-20635-03 16-267
For additional information related to implementing EEM, see the following sections:
Related Documents
EEM commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Standards
Standards Title
Feature History for EEM

Table 16-2 Feature History for EEM

EEM event correlation 5.2(1) Added support for multiple event triggers in a single EEM
policy.
Syslog as EEM publisher 5.1(1) Added support to monitor syslog messages from the switch.
EEM 5.0(2) No change from Release 4.2.
EEM 4.2(1) No change from Release 4.1.
Memory thresholds configuration 4.1(3) Added a configuration section for memory thresholds.
See the “Configuring Memory Thresholds” section on
page 16-263.
16-268 OL-20635-03
CHAPTER 17
Configuring Onboard Failure Logging
This chapter describes how to configure the onboard failure logging (OBFL) features on Cisco NX-OS
devices.
• Information About OBFL, page 17-269
• Licensing Requirements for OBFL, page 17-270
• Prerequisites for OBFL, page 17-270
• Configuring OBFL, page 17-271
• Verifying the OBFL Configuration, page 17-274
• Configuration Example for OBFL, page 17-275
• Feature History for OBFL, page 17-276
Information About OBFL

• OBFL Overview, page 17-269
OBFL Overview
Cisco NX-OS provides the ability to log failure data to persistent storage, which you can retrieve and
display for analysis at a later time. This onboard failure logging (OBFL) feature stores failure and
environmental information in nonvolatile memory on the module. The information will help analyze
failed modules.
The data stored by OBFL include the following:
• Time of initial power-on
• Slot number of the module in the chassis
OL-20635-03 17-269
Chapter 17 Configuring Onboard Failure Logging
Licensing Requirements for OBFL
• Initial temperature of the module

• Firmware, BIOS, FPGA, and ASIC versions
• Serial number of the module
• Stack trace for crashes
• CPU hog information
• Memory leak information
• Software error messages
• Hardware exception logs
• Environmental history
• OBFL-specific history information
• ASIC interrupt and error statistics history
• ASIC register dumps
OBFL stores a kernel trace in case Cisco NX-OS crashes.
You must be in the default virtual device context (VDC) to configure and display OBFL information. See
the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration Guide, Release 5.x for more
information on VDCs.
Licensing Requirements for OBFL

The following table shows the licensing requirements for this feature:

Cisco NX-OS OBFL requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for OBFL

You must have network-admin user privileges and be logged into the default VDC.
17-270 OL-20635-03

OBFL has the following guidelines and limitations:
• OBFL is enabled by default.
• OBFL flash supports a limited number of writes and erases. The more logging you enable, the faster
you use up this number of writes and erases.
Cisco IOS.
Default Settings
Table 17-1 lists the default settings for OBFL parameters.
Table 17-1 Default OBFL Parameters
Parameters Default
OBFL All features enabled
Configuring OBFL
You can configure the OBFL features on Cisco NX-OS devices.
BEFORE YOU BEGIN
Make sure you are in global configuration mode.
SUMMARY STEPS
1. hw-module logging onboard

2. hw-module logging onboard environmental-history
3. hw-module logging onboard error-stats
4. hw-module logging onboard interrupt-stats
5. hw-module logging onboard module slot
6. hw-module logging onboard module obfl-log
7. show logging onboard
OL-20635-03 17-271
Configuring OBFL
DETAILED STEPS
Command Purpose
Step 1 config t Places you in global
configuration mode.
Example:
switch# config t
Enter configuration commands, one per line. End with
CNTL/Z.
switch(config)#
Step 2 hw-module logging onboard Enables all OBFL features.
Example:
switch(config)# hw-module logging onboard
Module: 7 Enabling ... was successful.
Step 3 hw-module logging onboard environmental-history Enables the OBFL
environmental history.
Example:
switch(config)# hw-module logging onboard
environmental-history
Module: 7 Enabling environmental-history ... was
successful.
successful.
successful.
Step 4 hw-module logging onboard error-stats Enables the OBFL error
statistics.
Example:
switch(config)# hw-module logging onboard error-stats
Module: 7 Enabling error-stats ... was successful.
Step 5 hw-module logging onboard interrupt-stats Enables the OBFL interrupt
statistics.
Example:
switch(config)# hw-module logging onboard interrupt-stats
Module: 7 Enabling interrupt-stats ... was
successful.
successful.
successful.
Step 6 hw-module logging onboard module slot Enables the OBFL information
for a module.
Example:
switch(config)# hw-module logging onboard module 7
Step 7 hw-module logging onboard obfl-log Enables the boot uptime, device
version, and OBFL history.
Example:
switch(config)# hw-module logging onboard obfl-log
Module: 7 Enabling obfl-log ... was successful.
17-272 OL-20635-03
Configuring OBFL
Command Purpose
Step 8 show logging onboard (Optional) Displays information
about OBFL.
Example:
switch(config)# show logging onboard
----------------------------
OBFL Status
----------------------------
Switch OBFL Log:
Enabled
Module: 7 OBFL Log: Enabled

cpu-hog Enabled
environmental-history Enabled
error-stats Enabled
exception-log
.
.
.
Fri Mar 21 19:07:33 2008 (957597 us)

Module 2 SecondaryBootROM test has failed 20 times with
error BIOS file checksum
error
Library could not be opened

*** /lc/isan/lib/libcrdcfg.so: undefined symbol:
get_slot_id ***
plog_show_data_type: Error opening library statcl,
func_name statcl_disp_func
Step 9 copy running-config startup-config (Optional) Saves this
configuration change.
Example:
OL-20635-03 17-273
Verifying the OBFL Configuration
Verifying the OBFL Configuration

Use the show logging onboard status command to display the configuration status of OBFL.
switch# show logging onboard status
----------------------------
OBFL Status
----------------------------
Switch OBFL Log: Enabled

cpu-hog Enabled
error-stats Enabled
exception-log Enabled
interrupt-stats Enabled
mem-leak Enabled
miscellaneous-error Enabled
obfl-log (boot-uptime/device-version/obfl-history) Enabled
register-log Enabled
stack-trace Enabled
system-health Enabled

cpu-hog Enabled
error-stats Enabled
exception-log Enabled
interrupt-stats Enabled
mem-leak Enabled
miscellaneous-error Enabled
obfl-log (boot-uptime/device-version/obfl-history) Enabled
register-log Enabled
stack-trace Enabled
system-health Enabled
temp Error Enabled
To display OBFL information stored in flash on a module, perform one of the following tasks:
Command Purpose
show logging onboard boot-uptime Displays the boot and uptime information.
show logging onboard counter-stats Displays statistics on all ASIC counters.
show logging onboard device-version Displays device version information.
show logging onboard endtime Displays OBFL logs to a specified end time.
show logging onboard environmental-history Displays environmental history.
show logging onboard error-stats Displays error statistics.
show logging onboard exception-log Displays exception log information.
show logging onboard interrupt-stats Displays interrupt statistics.
show logging onboard kernel-trace Displays kernel trace information.
show logging onboard module slot Displays OBFL information for a specific
module.
show logging onboard obfl-history Displays history information.
show logging onboard obfl-logs Displays log information.
17-274 OL-20635-03
Configuration Example for OBFL
Command Purpose
show logging onboard stack-trace Displays kernel stack trace information.
show logging onboard starttime Displays OBFL logs from a specified start time.
show logging onboard status Displays OBFL status information.
Note Use the clear logging onboard command to clear the OBFL information for each of the show command
options listed.
Configuration Example for OBFL

This example shows how to enable OBFL on module 2 for environmental information:
conf t
hw-module logging onboard module 2 environmental-history
For additional information related to implementing OBFL, see the following sections:
Related Documents
OBFL CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Guide, Release 5.x
Standards
Standards Title
OL-20635-03 17-275
Feature History for OBFL
Feature History for OBFL

Table 17-2 Feature History for OBFL

OBFL 5.2(1) No change from Release 5.1.
17-276 OL-20635-03
CHAPTER 18
Configuring SPAN
Revised: January 31, 2014

This chapter describes how to configure an Ethernet switched port analyzer (SPAN) to analyze traffic
between ports on Cisco NX-OS devices.
• Information About SPAN, page 18-277
• Licensing Requirements for SPAN, page 18-281
• Prerequisites for SPAN, page 18-281
• Configuring SPAN, page 18-284
• Verifying the SPAN Configuration, page 18-297
• Configuration Examples for SPAN, page 18-298
• Feature History for SPAN, page 18-301
Information About SPAN

SPAN analyzes all traffic between source ports by directing the SPAN session traffic to a destination port
with an external analyzer attached to it.
You can define the sources and destinations to monitor in a SPAN session on the local device.
• SPAN Sources, page 18-278
• SPAN Destinations, page 18-278
• SPAN Sessions, page 18-279
• Virtual SPAN Sessions, page 18-279
• Multiple SPAN Sessions, page 18-280
OL-20635-03 18-277
Chapter 18 Configuring SPAN
SPAN Sources
The interfaces from which traffic can be monitored are called SPAN sources. Sources designate the
traffic to monitor and whether to copy ingress, egress, or both directions of traffic. SPAN sources include
the following:
• Ethernet ports
• Port channels
• The inband interface to the control plane CPU—You can monitor the inband interface only from the
default VDC. Inband traffic from all VDCs is monitored.
• VLANs—When a VLAN is specified as a SPAN source, all supported interfaces in the VLAN are
SPAN sources.
• Remote SPAN (RSPAN) VLANs
• Fabric port channels connected to the Cisco Nexus 2000 Series Fabric Extender
• Satellite ports and host interface port channels on the Cisco Nexus 2000 Series Fabric Extender—
These interfaces are supported in Layer 2 access mode, Layer 2 trunk mode, and Layer 3 mode.
Note Layer 3 subinterfaces are not supported.
Note A single SPAN session can include mixed sources in any combination of the above.
Characteristics of Source Ports

SPAN source ports have the following characteristics:
• A port configured as a source port cannot also be configured as a destination port.
• An RSPAN VLAN can only be used as a SPAN source.
• If you use the supervisor inband interface as a SPAN source, the following packets are monitored:
– All packets that arrive on the supervisor hardware (ingress)
– All packets generated by the supervisor hardware (egress)
SPAN Destinations
SPAN destinations refer to the interfaces that monitor source ports. Destination ports receive the copied
traffic from SPAN sources.
Characteristics of Destination Ports

SPAN destination ports have the following characteristics:
• Destinations for a SPAN session include Ethernet ports or port-channel interfaces in either access
or trunk mode.
• A port configured as a destination port cannot also be configured as a source port.
• A destination port can be configured in only one SPAN session at a time.
18-278 OL-20635-03
• Destination ports do not participate in any spanning tree instance. SPAN output includes Bridge
Protocol Data Unit (BPDU) Spanning-Tree Protocol hello packets.
• An RSPAN VLAN cannot be used as a SPAN destination.
• You can configure SPAN destinations to inject packets to disrupt a certain TCP packet stream in
support of the Intrusion Detection System (IDS).
• You can configure SPAN destinations to enable a forwarding engine to learn the MAC address of
the IDS.
• F1 Series module FabricPath core ports, Fabric Extender HIF ports, HIF port channels, and Fabric
PO ports are not supported as SPAN destination ports.
• Shared interfaces cannot be used as SPAN destinations.
• VLAN ACL redirects to SPAN destination ports are not supported.
• All SPAN destinations configured for a given session will receive all spanned traffic. For more
information, see the “Virtual SPAN Sessions” section below.
SPAN Sessions
You can create up to 48 SPAN sessions designating sources and destinations to monitor.
Note Only two SPAN sessions, two ERSPAN sessions, or one SPAN session and one ERSPAN session can be
running simultaneously.
Figure 18-1 shows a SPAN configuration. Packets on three Ethernet ports are copied to destination port
Ethernet 2/5. Only traffic in the direction specified is copied.
Figure 18-1 SPAN Configuration

.
Source Direction Destination

Port Ports
E 2/1 Rx E 2/5
E 2/5
E 2/2 Rx, Tx
186283
E 2/3 Tx
Network analyzer
Virtual SPAN Sessions

You can create a virtual SPAN session to monitor multiple VLAN sources and choose only VLANs of
interest to transmit on multiple destination ports. For example, you can configure SPAN on a trunk port
and monitor traffic from different VLANs on different destination ports.
Figure 18-2 shows a virtual SPAN configuration. The virtual SPAN session copies traffic from the three
VLANs to the three specified destination ports. You can choose which VLANs to allow on each
destination port to limit the traffic that the device transmits on it. In Figure 18-2, the device transmits
packets from one VLAN at each destination port.
OL-20635-03 18-279
Note Virtual SPAN sessions cause all source packets to be copied to all destinations, whether the packets are
required at the destination or not. VLAN traffic filtering occurs at the egress destination port level.
Figure 18-2 Virtual SPAN Configuration

.
Network analyzer
VLAN 10
E 2/5
Source Traffic Destination
VLAN Direction Ports
E 2/6
10 Rx E 2/5
Network analyzer
E 2/7 E 2/6
VLAN 11 11 Rx, Tx
E 2/7
186284
12 Tx
Rx is ingress
Network analyzer Tx is egress
VLAN 12
For information about configuring a virtual SPAN session, see the “Configuring a Virtual SPAN Session”
Multiple SPAN Sessions

Although you can define up to 48 SPAN sessions, only two SPAN or ERSPAN sessions can be running
simultaneously. You can shut down an unused SPAN session.
For information about shutting down SPAN sessions, see the “Shutting Down or Resuming a SPAN
Session” section on page 18-291.
High Availability
The SPAN feature supports stateless and stateful restarts. After a reboot or supervisor switchover, the
running configuration is applied. For more information on high availability, see the Cisco Nexus 7000
Series NX-OS High Availability and Redundancy Guide, Release 5.x.
A virtual device context (VDC) is a logical representation of a set of system resources. SPAN applies
only to the VDC where the commands are entered.
Note You can monitor the inband interface only from the default VDC. Inband traffic from all VDCs is
monitored.
18-280 OL-20635-03
Licensing Requirements for SPAN
Licensing Requirements for SPAN


Cisco NX-OS SPAN requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for SPAN

SPAN has the following prerequisite:
• You must first configure the ports on each device to support the desired SPAN configuration. For
more information, see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release
5.x.

SPAN has the following configuration guidelines and limitations:
• For SPAN session limits, see the Cisco Nexus 7000 Series NX-OS Verified Scalability Guide.
• SPAN is not supported for management ports.
• All SPAN replication is performed in the hardware. The supervisor CPU is not involved.
• A destination port can only be configured in one SPAN session at a time.
• You cannot configure a port as both a source and destination port.
• A single SPAN session can include mixed sources in any combination of the following:
– Ethernet ports, but not subinterfaces.
– VLANs, which can be assigned to port channel subinterfaces
– The inband interface to the control plane CPU
OL-20635-03 18-281
• Destination ports do not participate in any spanning tree instance. SPAN output includes Bridge
Protocol Data Unit (BPDU) Spanning-Tree Protocol hello packets.
• When a SPAN 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 SPAN 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
• For VLAN SPAN sessions with both ingress and egress configured, two packets (one from ingress
and one from egress) are forwarded from the destination port if the packets get switched on the same
VLAN.
• VLAN SPAN monitors only the traffic that leaves or enters Layer 2 ports in the VLAN.
• You can monitor the inband interface only from the default VDC. Inband traffic from all VDCs is
monitored.
• You can configure an RSPAN VLAN for use only as a SPAN session source.
• You can configure a SPAN session on the local device only.
• Multiple SPAN destinations are not supported when an F1 Series module is present in a VDC. If
multiple SPAN destinations are configured in a SPAN session, the session is disabled until the F1
Series module is powered down or moved to another VDC or the multiple SPAN destinations are
reduced to a single destination.
• A maximum of two bidirectional sessions are supported when an F1 Series module is present in a
VDC.
• A FabricPath core port is not supported as a SPAN destination when an F1 Series module is present
in a VDC. However, a FabricPath core port can be configured as a SPAN source interface.
• F1 Series modules are Layer 2 domain line cards. Packets from Layer 3 sources can be spanned and
directed to an F1 Series module SPAN destination. An F1 Series module interface cannot be
configured as Layer 3, but it can receive Layer 3 traffic in a SPAN destination mode.
• When using SPAN sessions on F1 Series modules, ensure that the total amount of source traffic in
a given session is less than or equal to the capacity of the SPAN destination interface or port channel
for that session. If the SPAN source traffic exceeds the capacity of the SPAN destination, packet
drops might occur on the SPAN source interfaces.
• If you span a core interface when inter-VLAN routing is enabled across L2MP, it is not possible to
capture the traffic egressing out of the core interface.
• Beginning with Cisco NX-OS Release 5.2, the Cisco Nexus 2000 Series Fabric Extender interfaces
and the fabric port channels connected to the Cisco Nexus 2000 Series Fabric Extender can be
configured as SPAN sources. However, they cannot be configured as SPAN destinations.
Note SPAN on Fabric Extender interfaces and fabric port channels is supported on the 32-port,
10-Gigabit M1 and M1 XL modules (N7K-M132XP-12 and N7K-M132XP-12L). SPAN
runs on the Cisco Nexus 7000 Series device, not on the Fabric Extender.
• SPAN is supported on Fabric Extender interfaces in Layer 2 access mode, Layer 2 trunk mode, and
Layer 3 mode. Layer 3 subinterfaces are not supported.
18-282 OL-20635-03
Default Settings
• If a port channel is the SPAN destination interface for SPAN traffic that is sourced from a Cisco
Nexus 7000 M1 Series module, only a single member interface will receive copied source packets.
The same limitation does not apply to SPAN traffic sourced from other Cisco Nexux modules,
including the Cisco Nexus 7000 M1-XL Series modules.
• Cisco NX-OS does not span Link Layer Discovery Protocol (LLDP) or Link Aggregation Control
Protocol (LACP) packets when the source interface is a Fabric Extender HIF (downlink) port or HIF
port channel.
• SPAN sessions cannot capture packets with broadcast or multicast MAC addresses that reach the
supervisor, such as ARP requests and Open Shortest Path First (OSPF) protocol hello packets, if the
source of the session is the supervisor ethernet in-band interface. To capture these packets, you must
use the physical interface as the source in the SPAN sessions.
• The rate limit percentage of a SPAN session is based on 10G for all modules (that is, 1% corresponds
to 0.1G), and the value is applied per every forwarding engine instance.
• MTU truncation and the SPAN rate limit are supported only on F1 Series modules.
Note MTU truncation and the SPAN rate limit cannot be enabled for the same SPAN session. If
you configure both for one session, only the rate limit is allowed on F1 Series modules, and
MTU truncation is disabled until you disable the rate limit configuration.
• MTU truncation on egress spanned FabricPath (core) packets is 16 bytes less than the configured
value because the SPAN destination removes the core header. In addition, when trunk ports are used
as the SPAN destination, the spanned ingress packets have 4 more bytes than the configured MTU
truncation size.
• For certain rate limit and packet size values, the SPAN packet rate is less than the configured value
because of the internal accounting of packet sizes and internal headers.
• Multicast best effort mode applies only to M1 Series modules.
• SPAN does not capture pause frames in a Fibre Channel over Ethernet (FCoE) network because
pause frames sent from the virtual expansion (VE) port are generated and terminated by the
outermost MAC layer. For more information on FCoE, see the Cisco NX-OS FCoE Configuration
Guide for Cisco Nexus 7000 and Cisco MDS 9500.
Default Settings
Table 18-1 lists the default settings for SPAN parameters.
Table 18-1 Default SPAN Parameters
Parameters Default
SPAN sessions Created in the shut state
MTU truncation Disabled
Multicast best effort mode Disabled
SPAN rate limit Disabled
OL-20635-03 18-283
Configuring SPAN
Configuring SPAN
• Configuring a SPAN Session, page 18-284
• Configuring a Virtual SPAN Session, page 18-287
• Configuring an RSPAN VLAN, page 18-290
• Shutting Down or Resuming a SPAN Session, page 18-291
• Configuring MTU Truncation for Each SPAN Session, page 18-292
• Configuring a Source Rate Limit for Each SPAN Session, page 18-294
• Configuring the Multicast Best Effort Mode for a SPAN Session, page 18-296
Note Cisco NX-OS commands for this feature may differ from those in Cisco IOS.
Configuring a SPAN Session

You can configure a SPAN session on the local device only. By default, SPAN sessions are created in the
shut state.
For sources, you can specify Ethernet ports, port channels, the supervisor inband interface, VLANs, and
RSPAN VLANs. You can specify private VLANs (primary, isolated, and community) in SPAN sources.
A single SPAN session can include mixed sources in any combination of Ethernet ports, VLANs, or the
inband interface to the control plane CPU. You cannot specify Ethernet port subinterfaces as sources for
a SPAN session.
Note To use a Layer 3 port-channel sub-interface or a normal Layer 3 sub-interface as a SPAN source in the
monitor session, configure the VLAN filter on the parent Layer 3 Port channel or Layer 3 interface with
the same VLAN as the IEEE 802.1q VLAN encapsulation that is configured on the sub-interface. The
VLAN filter configured on the parent interface as source will ensure that the monitored traffic on the
SPAN destination port will be only for the VLANs that are configured.
When you specify the supervisor inband interface for a SPAN source, the device monitors all packets
that arrive on the supervisor hardware (ingress) and all packets generated by the supervisor hardware
(egress).
For destination ports, you can specify Ethernet ports or port-channels in either access or trunk mode.
You must enable monitor mode on all destination ports.
BEFORE YOU BEGIN
Make sure that you are in the correct VDC. To switch VDCs, use the switchto vdc command.
You must have already configured the destination ports in access or trunk mode. For more information,
see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x.
SUMMARY STEPS
1. config t
18-284 OL-20635-03
Configuring SPAN
2. interface ethernet slot/port[-port]

3. switchport
4. switchport mode [access | trunk | private-vlan]
5. switchport monitor [ingress [learning]]
6. (Optional) Repeat Steps 2 and 3 to configure monitoring on additional SPAN destinations.
7. no monitor session session-number
8. monitor session session-number
9. description description
10. source {interface type | vlan {number | range} [rx | tx | both]
11. (Optional) Repeat Step 8 to configure all SPAN sources.
12. (Optional) filter vlan {number | range}
13. (Optional) Repeat Step 10 to configure all source VLANs to filter.
14. destination interface type {number | range}
15. (Optional) Repeat Step 12 to configure all SPAN destination ports.
16. no shut
17. (Optional) show monitor session {all | session-number | range session-range} [brief]
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 interface ethernet slot/port[-port] Enters interface configuration mode on the selected
slot and port or range of ports.
Example:
switch(config-if)#
Step 3 switchport Configures switchport parameters for the selected
Example:
switch(config-if)# switchport
switch(config-if)#
Step 4 switchport mode [access | trunk | Configures the switchport mode for the selected slot
private-vlan] and port or range of ports.
Example: • access
switch(config-if)# switchport mode trunk
switch(config-if)# • trunk
• private-vlan
OL-20635-03 18-285
Configuring SPAN
Command Purpose
Step 5 switchport monitor [ingress [learning]] Configures the switchport interface as a SPAN
destination:
Example:
switch(config-if)# switchport monitor • ingress
Allows the SPAN destination port to inject
packets that disrupt a certain TCP packet
stream, for example, in networks with IDS.
• ingress learning
Allows the SPAN destination port to inject
packets, and allows the learning of MAC
addresses, for example, the IDS MAC address.
Step 6 (Optional) Repeat Steps 2 and 3 to configure —
monitoring on additional SPAN destinations.
Step 7 no monitor session session-number Clears the configuration of the specified SPAN
session. The new session configuration is added to
Example:
switch(config)# no monitor session 3
the existing session configuration.
Step 8 monitor session session-number Enters the monitor configuration mode. The new
session configuration is added to the existing session
Example:
switch(config)# monitor session 3
configuration. By default, the session is created in
switch(config-monitor)# the shut state.
Step 9 description description Configures a description for the session. By default,
no description is defined. The description can be up
Example:
switch(config-monitor)# description
to 32 alphanumeric characters.
my_span_session_3
Step 10 source {interface type | vlan Configures sources and the traffic direction in which
{1-3967,4048-4093}} [rx | tx | both] to copy packets. You can enter a range of Ethernet
Example 1:
ports, a port channel, an inband interface, a range of
switch(config-monitor)# source interface VLANs, a Cisco Nexus 2000 Series Fabric Extender
ethernet 2/1-3, ethernet 3/1 rx interface, or a fabric port channel connected to a
Cisco Nexus 2000 Series Fabric Extender.
Example 2:
switch(config-monitor)# source interface You can configure one or more sources, as either a
port-channel 2 series of comma-separated entries or a range of
numbers. You can specify up to 128 interfaces. The
Example 3:
VLAN range is from 1 to 3967 and 4048 to 4093.
switch(config-monitor)# source interface
sup-eth 0 both You can specify the traffic direction to copy as
ingress (tx), egress (tx), or both. By default, the
Example 4:
switch(config-monitor)# source vlan 3, 6-8
direction is both.
tx Note You can monitor the inband interface only
from the default VDC. The inband traffic
Example 5:
switch(config-monitor)# source interface from all VDCs is monitored.
ethernet 101/1/1-3
Step 11 (Optional) Repeat Step 8 to configure all SPAN —
sources.
18-286 OL-20635-03
Configuring SPAN
Command Purpose
Step 12 filter vlan {number | range} (Optional) Configures which VLANs to select from
the configured sources. You can configure one or
Example:
switch(config-monitor)# filter vlan 3-5, 7
more VLANs, as either a series of comma-separated
entries, or a range of numbers. The VLAN range is
from 1 to 3967 and 4048 to 4093.
Step 13 (Optional) Repeat Step 10 to configure all source —
VLANs to filter.
Step 14 destination interface type {number | Configures destinations for copied source packets.
range} You can configure one or more destinations, as
Example:
either a series of comma-separated entries or a range
switch(config-monitor)# destination of numbers. You can specify up to 128 interfaces.
interface ethernet 2/5, ethernet 3/7
Note SPAN destination ports must be either
access or trunk ports.
Note The Cisco Nexus 2000 Series Fabric

Extender interfaces and the fabric port
channels connected to the Cisco Nexus 2000
Series Fabric Extender cannot be configured
as SPAN destinations.
Step 15 (Optional) Repeat Step 12 to configure all SPAN —
destination ports.
Step 16 no shut Enables the SPAN session. By default, the session is
created in the shut state.
Example:
switch(config-monitor)# no shut Note Only two SPAN sessions can be running
simultaneously.
Step 17 show monitor session {all | session-number (Optional) Displays the SPAN configuration.
| range session-range} [brief]
Example:
switch(config-monitor)# show monitor
session 3
Example:
switch(config-monitor)# copy
Configuring a Virtual SPAN Session

You can configure a virtual SPAN session to copy packets from source ports, VLANs, and RSPAN
VLANs to destination ports on the local device. By default, SPAN sessions are created in the shut state.
For sources, you can specify ports, VLANs, or RSPAN VLANs.
For destination ports, you can specify Ethernet ports. You can choose which VLANs to allow on each
destination port to limit the traffic that the device transmits on it.
BEFORE YOU BEGIN
Ensure that you are in the correct VDC (or use the switchto vdc command).
OL-20635-03 18-287
Configuring SPAN
You have already configured the destination ports in trunk mode. For more information, see the Cisco
Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x.
You have already configured the destination ports to monitor a SPAN session with the switchport
monitor command.
SUMMARY STEPS
1. config t
2. no monitor session session-number
4. source {interface type | vlan} {number | range} [rx | tx | both]
5. (Optional) Repeat Step 4 to configure all virtual SPAN VLAN sources.
6. destination interface type {number | range}
7. (Optional) Repeat Step 6 to configure all virtual SPAN destination ports.
8. no shut
9. (Optional) show monitor session {all | session-number | range session-range} [brief]
11. switchport trunk allowed vlan {{number | range} | add {number | range} | except {number |
range} | remove {number | range} | all | none}
12. (Optional) Repeat Steps 10 and 11 to configure the allowed VLANs on each destination port.
13. (Optional) show interface ethernet slot/port[-port] trunk
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 no monitor session session-number Clears the configuration of the specified SPAN
session. New session configuration is added to the
Example:
existing session configuration.
Step 3 monitor session session-number Enters the monitor configuration mode. A new
Example:
configuration.
switch(config-monitor)#
18-288 OL-20635-03
Configuring SPAN
Command Purpose
Step 4 source {interface type | vlan} {number | Configures sources and the traffic direction in which
range} [rx | tx | both] to copy packets. You can configure one or more
Example:
sources, as either a series of comma-separated
switch(config-monitor)# source vlan 3, 6-8 entries, or a range of numbers. You can specify up to
tx 128 interfaces. The VLAN range is from 1 to 3967
and 4048 to 4093.
You can specify the traffic direction to copy as
ingress (tx), egress (tx), or both. By default, the
direction is both.
Step 5 (Optional) Repeat Step 4 to configure all virtual —
SPAN source VLANs.
Step 6 destination interface type {number | Configures destinations for copied source packets.
range} You can configure one or more interfaces, as either
Example:
a series of comma-separated entries, or a range of
switch(config-monitor)# destination numbers. The allowable range is from 1 to 128.
Note Configure destination ports as trunk ports.
For more information, see the Cisco Nexus
7000 Series NX-OS Interfaces Configuration
Guide, Release 5.x.
Step 7 (Optional) Repeat Step 6 to configure all virtual —
SPAN destination ports.
Example:
simultaneously.
Step 9 show monitor session {all | session-number (Optional) Displays the virtual SPAN configuration.
| range session-range} [brief]
Example:
session 3
Example:
switch(config-if)#
Step 11 switchport trunk allowed vlan {{number | Configures the range of VLANS that are allowed on
range} | add {number | range} | except the interface. You can add to or remove from the
{number | range} | remove {number | range}
| all | none}
existing VLANs, you can select all VLANs except
those VLANs that you specify, or you can select all
Example: or none of the VLANs. By default, all VLANs are
switch(config-if)# switchport trunk allowed on the interface.
allowed vlan 3-5
You can configure one or more VLANs, as either a
series of comma-separated entries, or a range of
numbers. The VLAN range is from 1 to 3967 and
4048 to 4093.
Step 12 (Optional) Repeat Steps 10 and 11 to configure —
the allowed VLANs on each destination port.
OL-20635-03 18-289
Configuring SPAN
Command Purpose
Step 13 show interface ethernet slot/port[-port] (Optional) Displays the interface trunking
trunk configuration for the selected slot and port or range
Example:
of ports.
switch(config-if)# show interface ethernet
2/5 trunk
Example:
startup-config
Configuring an RSPAN VLAN

You can specify a remote SPAN (RSPAN) VLAN as a SPAN session source.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. vlan vlan
3. remote-span
4. exit
5. (Optional) show vlan
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 vlan vlan Enters VLAN configuration mode for the VLAN
specified.
Example:
switch(config)# vlan 901
switch(config-vlan)#
Step 3 remote-span Configures the VLAN as an RSPAN VLAN.
Example:
switch(config-vlan)# remote-span
18-290 OL-20635-03
Configuring SPAN
Command Purpose
Step 4 exit Exits VLAN configuration mode.
Example:
switch(config-vlan)# exit
switch(config)#
Step 5 show vlan (Optional) Displays the VLAN configuration.
Remote SPAN VLANs are listed together.
Example:
switch(config)# show vlan
Example:
startup-config
Shutting Down or Resuming a SPAN Session

You can shut down SPAN sessions to discontinue the copying of packets from sources to destinations.
Because only two SPAN sessions can be running simultaneously, you can shut down one session in order
to free hardware resources to enable another session. By default, SPAN sessions are created in the shut
state.
You can resume (enable) SPAN sessions to resume the copying of packets from sources to destinations.
In order to enable a SPAN session that is already enabled but operationally down, you must first shut it
down and then enable it.
You can configure the shut and enabled SPAN session states with either a global or monitor configuration
mode command.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. monitor session {session-range | all} shut
3. no monitor session {session-range | all} shut
5. shut
6. no shut
7. (Optional) show monitor
OL-20635-03 18-291
Configuring SPAN
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 monitor session {session-range | all} shut Shuts down the specified SPAN sessions. The
session ranges from 1 to 48. By default, sessions are
Example:
switch(config)# monitor session 3 shut
created in the shut state. Only two sessions can be
running at a time.
Step 3 no monitor session {session-range | all} Resumes (enables) the specified SPAN sessions. The
shut session ranges from 1 to 48. By default, sessions are
Example:
created in the shut state. Only two sessions can be
switch(config)# no monitor session 3 shut running at a time.
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 Enters the monitor configuration mode. The new
Example:
configuration.
Step 5 shut Shuts down the SPAN session. By default, the
session is created in the shut state.
Example:
switch(config-monitor)# shut
Example:
simultaneously.
Step 7 show monitor (Optional) Displays the status of SPAN sessions.
Example:
Example:
Configuring MTU Truncation for Each SPAN Session

To reduce the SPAN traffic bandwidth, you can configure the maximum bytes allowed for each replicated
packet in a SPAN session. This value is called the maximum transmission unit (MTU) truncation size.
Any SPAN packet larger than the configured size is truncated to the configured size.
18-292 OL-20635-03
Configuring SPAN
Note MTU truncation and the SPAN rate limit cannot be enabled for the same SPAN session. If you configure
both for one session, only the rate limit is allowed on F1 Series modules, and MTU truncation is disabled
until you disable the rate limit configuration.
BEFORE YOU BEGIN
OL-20635-03 18-293
Configuring SPAN
SUMMARY STEPS
1. config t
3. [no] mtu mtu
4. (Optional) show monitor session-number
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 monitor session session-number Enters the monitor configuration mode and specifies
the SPAN session for which the MTU truncation size
Example:
is to be configured.
Step 3 [no] mtu mtu Configures the MTU truncation size for packets in
the specified SPAN session. The range is from 64 to
Example:
switch(config-monitor)# mtu 64
1500 bytes.
Step 4 show monitor session session-number (Optional) Displays the status of SPAN sessions,
including the configuration status of MTU
Example:
truncation, the maximum bytes allowed for each
session 3 packet per session, and the modules on which MTU
truncation is and is not supported.
Example:
Configuring a Source Rate Limit for Each SPAN Session

When a SPAN session is configured with multiple interfaces or VLANs as the sources in a high-traffic
environment, the destination port can be overloaded, causing the normal data traffic to be disrupted at
the source port. You can alleviate this problem as well as traffic overload on the source forwarding
instance by configuring a source rate limit for each SPAN session.
Note MTU truncation and the SPAN rate limit cannot be enabled for the same SPAN session. If you configure
both for one session, only the rate limit is allowed on F1 Series modules, and MTU truncation is disabled
until you disable the rate limit configuration.
18-294 OL-20635-03
Configuring SPAN
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
3. [no] rate-limit {auto | rate-limit}
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
the SPAN session for which the source rate limit is
Example:
to be configured.
OL-20635-03 18-295
Configuring SPAN
Command Purpose
Step 3 [no] rate-limit {auto | rate-limit} Configures the source rate limit for SPAN packets in
the specified SPAN session in automatic or manual
Example:
switch(config-monitor)# rate-limit auto
mode:
• Auto mode—Automatically calculates the rate
limit on a per-gigabyte basis as follows:
destination bandwidth / aggregate source
bandwidth. For example, if the rate limit per
gigabyte is 0.5, then for every 1G of source
traffic, only 0.5G of packets are spanned.
For ingress traffic, the per-gigabyte limit is
applied to each forwarding engine of the F1
Series module based on how many ports are
used as the SPAN source so that source can be
spanned at the maximum available bandwidth.
For egress traffic, the per-gigabyte limit is
applied to each forwarding engine of the F1
Series module without considering how many
ports are used as the SPAN source.
• Manual mode—Specifies the percentage of the
maximum rate of SPAN packets that can be sent
out from each forwarding engine on a line card.
The range is from 1 to 100. For example, if the
rate limit is 10%, the maximum rate of SPAN
packets that can be sent out from each of the
forwarding engines on an F1 Series module is
1G (or 10% of the 10G line rate).
including the configuration status of the rate limit,
Example:
the percentage of the maximum SPAN rate allowed
session 3 per session, and the modules on which the rate limit
is and is not supported.
Example:
Configuring the Multicast Best Effort Mode for a SPAN Session

You can configure the multicast best effort mode for any SPAN session. By default, SPAN replication
occurs on both the ingress and egress line card. When you enable the multicast best effort mode, SPAN
replication occurs only on the ingress line card for multicast traffic or on the egress line card for packets
egressing out of Layer 3 interfaces (that is, on the egress line card, packets egressing out of Layer 2
interfaces are not replicated for SPAN).
BEFORE YOU BEGIN
18-296 OL-20635-03
Verifying the SPAN Configuration
SUMMARY STEPS
1. config t
3. [no] multicast best-effort
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
the SPAN session for which the multicast best effort
Example:
mode is to be configured.
Step 3 [no] multicast best-effort Configures the multicast best effort mode for the
specified SPAN session.
Example:
switch(config-monitor)# multicast
best-effort
including the configuration status of the multicast
Example:
best effort mode and the modules on which the best
session 3 effort mode is and is not supported.
Example:
Verifying the SPAN Configuration

To display the SPAN configuration, perform one of the following tasks:
Command Purpose
show monitor session {all | session-number | Displays the SPAN session configuration.
range session-range} [brief]
OL-20635-03 18-297
Configuration Examples for SPAN

• Configuration Example for a SPAN Session, page 18-298
• Configuration Example for a Virtual SPAN Session, page 18-298
• Configuration Example for a SPAN Session with a Private VLAN Source, page 18-299
Configuration Example for a SPAN Session

To configure a SPAN session, follow these steps:
Step 1 Configure destination ports in access or trunk mode, and enable SPAN monitoring.
switch# config t
switch(config-if)# switchport monitor
switch(config-if)# no shut
switch(config)#
Step 2 Configure a SPAN session.

switch(config-monitor)# source interface ethernet 2/1-3, ethernet 3/1 rx
switch(config-monitor)# source interface port-channel 2
switch(config-monitor)# source interface sup-eth 0 both
switch(config-monitor)# source vlan 3, 6-8 tx
switch(config-monitor)# source interface ethernet 101/1/1-3
switch(config-monitor)# filter vlan 3-5, 7
switch(config-monitor)# destination interface ethernet 2/5
switch(config-monitor)# no shut
switch(config-monitor)# mtu 500
switch(config-monitor)# rate-limit 10
switch(config-monitor)# multicast best-effort
switch(config-monitor)# exit
switch(config)# show monitor session 3
Configuration Example for a Virtual SPAN Session

To configure a virtual SPAN session, follow these steps:
switch# config t
switch(config-if)# switchport trunk allowed vlan add 100-200
18-298 OL-20635-03

switch(config)#

switch(config-monitor)# source vlan 100-300
switch(config-monitor)# destination interface ethernet 3/1-2
Configuration Example for a SPAN Session with a Private VLAN Source

To configure a SPAN session that includes a private VLAN source, follow these steps:
Step 1 Configure source VLANs.

switch# config t
switch(config)# vlan 100
switch(config-vlan)# private-vlan primary
switch(config-vlan)# exit
switch(config-if)# switchport access vlan 100
switch(config-if)# switchport trunk native vlan 100
switch(config)#
switch# config t
switch(config)#
OL-20635-03 18-299

switch(config-monitor)# source vlan 100
switch(config-monitor)# destination interface ethernet 3/3
For additional information related to implementing SPAN, see the following sections:
Related Documents
Fabric Extender Configuring the Cisco Nexus 2000 Series Fabric Extender
SPAN commands: complete command syntax, Cisco Nexus 7000 Series NX-OS System Management Command
command modes, command history, defaults, usage Reference
guidelines, and examples
Standards
Standards Title
18-300 OL-20635-03
Feature History for SPAN

Table 18-2 Feature History for SPAN

SPAN 5.2(1) Added SPAN source support for Cisco Nexus 2000 Series
Fabric Extender interfaces.
SPAN 5.2(1) Added the ability to configure MTU truncation, the source
rate limit, and the multicast best effort mode for each SPAN
session.
SPAN 5.1(1) Added support for F1 Series modules and increased the
number of supported SPAN sessions from 18 to 48.
SPAN 5.0(2) No change from Release 4.2.
SPAN 4.2(1) No change from Release 4.1.
Guidelines and Limitations 4.1(3) Added a table of SPAN session limits.
OL-20635-03 18-301
18-302 OL-20635-03
CHAPTER 19
Configuring ERSPAN
This chapter describes how to configure an encapsulated remote switched port analyzer (ERSPAN) to
transport mirrored traffic in an IP network on Cisco NX-OS devices.
• Information About ERSPAN, page 19-303
• Licensing Requirements for ERSPAN, page 19-306
• Prerequisites for ERSPAN, page 19-306
• Configuring ERSPAN, page 19-308
• Verifying the ERSPAN Configuration, page 19-317
• Configuration Examples for ERSPAN, page 19-317
• Feature History for ERSPAN, page 19-320
Information About ERSPAN

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 separately configure ERSPAN
source sessions and destination sessions on different switches.
• ERSPAN Sources, page 19-304
• ERSPAN Destinations, page 19-304
• ERSPAN Sessions, page 19-304
• Multiple ERSPAN Sessions, page 19-305
OL-20635-03 19-303
Chapter 19 Configuring ERSPAN
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
• The inband interface to the control plane CPU—You can monitor the inband interface only from the
default VDC. Inband traffic from all VDCs is monitored.
• VLANs—When a VLAN is specified as an ERSPAN source, all supported interfaces in the VLAN
are ERSPAN sources.
• Fabric port channels connected to the Cisco Nexus 2000 Series Fabric Extender
• Satellite ports and host interface port channels on the Cisco Nexus 2000 Series Fabric Extender—
These interfaces are supported in Layer 2 access mode, Layer 2 trunk mode, and Layer 3 mode.
Note Layer 3 subinterfaces are not supported.
Note A single ERSPAN session can include mixed sources in any combination of the above.
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
Destination ports receive the copied traffic from ERSPAN sources.
ERSPAN destination ports have the following characteristics:
• Destinations for an ERSPAN session include Ethernet ports or port-channel interfaces in either
access or trunk mode.
• A port configured as a destination port cannot also be configured as a source port.
• A destination port can be configured in only one ERSPAN session at a time.
• 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.
• F1 Series module core ports, Fabric Extender HIF ports, HIF port channels, and Fabric PO ports are
not supported as SPAN destination ports.
ERSPAN Sessions
You can create ERSPAN sessions that designate sources and destinations to monitor.
19-304 OL-20635-03
Note Only two ERSPAN or SPAN source sessions can run simultaneously across all VDCs. Only 23 ERSPAN
destination sessions can run simultaneously across all VDCs.
Figure 19-1 shows an ERSPAN configuration.
Figure 19-1 ERSPAN Configuration

.
Destination switch
Switch D
(data center)
Routed D1 D2
GRE-encapsulated
traffic Probe
Routed
Network
Routed
Routed GRE-encapsulated
GRE-encapsulated traffic
traffic
A3 B4
Source switch(es)
Switch A Switch B
(access)
A1 A2 B1 B2 B3
199755
Multiple ERSPAN Sessions
Although you can define up to 48 ERSPAN sessions, only two ERSPAN or SPAN sessions can be
running simultaneously. You can shut down an unused ERSPAN session.
For information about shutting down ERSPAN sessions, see the “Shutting Down or Activating an
ERSPAN Session” section on page 19-314.
High Availability
The ERSPAN feature supports stateless and stateful restarts. After a reboot or supervisor switchover, the
For more information on high availability, see the Cisco Nexus 7000 Series NX-OS High Availability and
Redundancy Guide, Release 5.x.
A virtual device context (VDC) is a logical representation of a set of system resources. ERSPAN applies
only to the VDC where the commands are entered.
Note You can monitor the inband interface only from the default VDC. Inband traffic from all VDCs is
monitored.
OL-20635-03 19-305
Licensing Requirements for ERSPAN
Licensing Requirements for ERSPAN


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 Cisco NX-OS Licensing Guide.
Prerequisites for ERSPAN

ERSPAN has the following prerequisite:
• You must first configure the ports on each device to support the desired ERSPAN configuration. For
more information, see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release
5.x.

ERSPAN has the following configuration guidelines and limitations:
• For ERSPAN session limits, see the Cisco Nexus 7000 Series NX-OS Verified Scalability Guide.
• All ERSPAN replication is performed in the hardware. The supervisor CPU is not involved.
• ERSPAN and ERSPAN ACLs are not supported on F1 Series modules.
• The encapsulation or decapsulation of generic routing encapsulation (GRE) or ERSPAN packets
received on an F1 Series module is not supported.
• ERSPAN and ERSPAN ACLs are not supported for packets generated by the supervisor.
19-306 OL-20635-03
• ERSPAN and ERSPAN ACL 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 inband interface or 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
• For VLAN ERSPAN sessions with both ingress and egress configured, two packets (one from
ingress and one from egress) are forwarded from the destination port if the packets get switched on
the same VLAN.
• VLAN ERSPAN monitors only the traffic that leaves or enters Layer 2 ports in the VLAN.
• You can monitor the inband interface only from the default VDC. Inband traffic from all VDCs is
monitored.
• Beginning with Cisco NX-OS Release 5.2, the Cisco Nexus 2000 Series Fabric Extender interfaces
and the fabric port channels connected to the Cisco Nexus 2000 Series Fabric Extender can be
configured as ERSPAN sources. However, they cannot be configured as ERSPAN destinations.
Note ERSPAN on Fabric Extender interfaces and fabric port channels is supported on the 32-port,
10-Gigabit M1 and M1 XL modules (N7K-M132XP-12 and N7K-M132XP-12L). ERSPAN
runs on the Cisco Nexus 7000 Series device, not on the Fabric Extender.
• ERSPAN is supported on Fabric Extender interfaces in Layer 2 access mode, Layer 2 trunk mode,
and Layer 3 mode. Layer 3 subinterfaces are not supported.
• Multicast best effort mode applies only to M1 Series modules.
• If ERSPAN is enabled on a vPC and ERSPAN packets need to be routed to the destination through
the vPC, packets coming through the vPC peer-link cannot be captured.
• ERSPAN ACLs are not supported for use with OTV.
OL-20635-03 19-307
Default Settings
Default Settings
Table 19-1 lists the default settings for ERSPAN parameters.
Table 19-1 Default ERSPAN Parameters
Parameters Default
ERSPAN sessions Created in the shut state
Multicast best effort mode Disabled
Configuring ERSPAN
• Configuring an ERSPAN Source Session, page 19-308
• Configuring an ERSPAN Destination Session, page 19-311
• Shutting Down or Activating an ERSPAN Session, page 19-314
• Configuring the Multicast Best Effort Mode for an ERSPAN Session, page 19-316
Configuring an ERSPAN Source Session

You can configure an ERSPAN session on the local device only. By default, ERSPAN sessions are
For sources, you can specify Ethernet ports, port channels, the supervisor inband interface, and VLANs.
A single ERSPAN session can include mixed sources in any combination of Ethernet ports, VLANs, or
the inband interface to the control plane CPU.
Note ERSPAN does not monitor any packets that are generated by the supervisor, regardless of their source.
BEFORE YOU BEGIN
Ensure that you are in the correct VDC. To switch VDCs, use the switchto vdc command. For more
Release 5.x.
SUMMARY STEPS
1. config t
2. monitor erspan origin ip-address ip-address global
3. no monitor session {session-number | all}
4. monitor session {session-number | all} type erspan-source
6. source {[interface [type slot/port[-port][, type slot/port[-port]]] [port-channel channel-number] |
[vlan {number | range}]} [rx | tx | both]
19-308 OL-20635-03
Configuring ERSPAN
7. (Optional) Repeat Step 6 to configure all ERSPAN sources.

8. (Optional) filter vlan {number | range}
9. (Optional) Repeat Step 8 to configure all source VLANs to filter.
10. (Optional) filter access-group acl-filter
11. destination ip ip-address
12. erspan-id erspan-id
13. vrf vrf-name
14. (Optional) ip ttl ttl-number
15. (Optional) ip dscp dscp-number
16. no shut
17. (Optional) show monitor session {all | session-number | range session-range}
18. (Optional) show running-config monitor
19. (Optional) show startup-config monitor
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 monitor erspan origin ip-address Configures the ERSPAN global origin IP address.
ip-address global
Note The global origin IP address can be
Example: configured only in the default VDC. The
switch(config)# monitor erspan origin value that is configured in the default VDC
ip-address 10.0.0.1 global
is valid across all VDCs. Any change made
in the default VDC is applied across all
nondefault VDCs.
Step 3 no monitor session {session-number | all} Clears the configuration of the specified ERSPAN
Example:
Step 4 monitor session {session-number | all} Configures an ERSPAN source session.
type erspan-source
Example:
switch(config)# monitor session 3 type
erspan-source
switch(config-erspan-src)#
Example:
switch(config-erspan-src)# description
erspan_src_session_3
OL-20635-03 19-309
Configuring ERSPAN
Command Purpose
Step 6 source {[interface [type Configures the sources and traffic direction in which
slot/port[-port][, type slot/port[-port]]] to copy packets. You can enter a range of Ethernet
[port-channel channel-number]] | [vlan
{number | range}]} [rx | tx | both]
ports, a port channel, an inband interface, a range of
VLANs, a Cisco Nexus 2000 Series Fabric Extender
Example 1: interface, or a fabric port channel connected to a
switch(config-erspan-src)# source Cisco Nexus 2000 Series Fabric Extender.
interface ethernet 2/1-3, ethernet 3/1 rx
You can configure one or more sources, as either a
Example 2: series of comma-separated entries or a range of
switch(config-erspan-src)# source numbers. You can specify up to 128 interfaces. For
interface port-channel 2
information on the VLAN range, see the Cisco
Example 3: Nexus 7000 Series NX-OS Layer 2 Switching
switch(config-erspan-src)# source Configuration Guide, Release 5.x.
interface sup-eth 0 both
You can specify the traffic direction to copy as
Example 4: ingress, egress, or both. The default direction is
switch(config-erspan-src)# source vlan 3, both.
6-8 tx
Note You can monitor the inband interface only
Example 5: from the default VDC. The inband traffic
switch(config-monitor)# source interface from all VDCs is monitored.
ethernet 101/1/1-3
Step 7 (Optional) Repeat Step 6 to configure all —
ERSPAN sources.
Step 8 filter vlan {number | range} (Optional) Configures which VLANs to select from
the configured sources. You can configure one or
Example:
switch(config-erspan-src)# filter vlan
more VLANs, as either a series of comma-separated
3-5, 7 entries or a range of numbers. For information on the
VLAN range, see the Cisco Nexus 7000 Series
NX-OS Layer 2 Switching Configuration Guide,
Release 5.x.
Step 9 (Optional) Repeat Step 8 to configure all source —
VLANs to filter.
Step 10 filter access-group acl-filter (Optional) Associates an ACL with the ERSPAN
session.
Example:
switch(config-erspan-src)# filter Note You can create an ACL using the standard
access-group ACL1 ACL configuration process. For more
information, see the Cisco Nexus 7000
Series NX-OS Security Configuration Guide,
Release 5.x.
Step 11 destination ip ip-address Configures the destination IP address in the
ERSPAN session. Only one destination IP address is
Example:
switch(config-erspan-src)# destination ip
supported per ERSPAN source session.
10.1.1.1 Note The Cisco Nexus 2000 Series Fabric
Extender interfaces and the fabric port
channels connected to the Cisco Nexus 2000
Series Fabric Extender cannot be configured
as SPAN destinations.
19-310 OL-20635-03
Configuring ERSPAN
Command Purpose
Step 12 erspan-id erspan-id Configures the ERSPAN ID for the ERSPAN
session. The ERSPAN range is from 1 to 1023.
Example:
switch(config-erspan-src)# erspan-id 5
Step 13 vrf vrf-name Configures the VRF that the ERSPAN source
session uses for traffic forwarding.
Example:
switch(config-erspan-src)# vrf default
Step 14 ip ttl ttl-number (Optional) Configures the IP time-to-live (TTL)

value for the ERSPAN traffic. The range is from 1 to
Example:
switch(config-erspan-src)# ip ttl 25
255.
Step 15 ip dscp dscp-number (Optional) Configures the differentiated services
code point (DSCP) value of the packets in the
Example:
switch(config-erspan-src)# ip dscp 42
ERSPAN traffic. The range is from 0 to 63.
Step 16 no shut Enables the ERSPAN source session. By default, the
Example:
switch(config-erspan-src)# no shut Note Only two ERSPAN source sessions can be
running simultaneously.
Step 17 show monitor session {all | session-number (Optional) Displays the ERSPAN session
| range session-range} configuration.
Example:
switch(config-erspan-src)# show monitor
session 3
Step 18 show running-config monitor (Optional) Displays the running ERSPAN
configuration.
Example:
switch(config-erspan-src)# show
running-config monitor
Step 19 show startup-config monitor (Optional) Displays the ERSPAN startup
configuration.
Example:
startup-config monitor
Example:
switch(config-erspan-src)# copy
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
OL-20635-03 19-311
Configuring ERSPAN
Ensure that you have already configured the destination ports in monitor mode. For more information,
see the Cisco Nexus 7000 Series NX-OS Interfaces Configuration Guide, Release 5.x.
SUMMARY STEPS
1. config t
3. switchport
4. switchport mode [access | trunk]
5. switchport monitor
6. (Optional) Repeat Steps 2 to 5 to configure monitoring on additional ERSPAN destinations.
7. no monitor session {session-number | all}
8. monitor session {session-number | all} type erspan-destination
10. source ip ip-address
11. destination {[interface [type slot/port[-port][, type slot/port[-port]]] | [port-channel
channel-number]]}
12. (Optional) Repeat Step 11 to configure all ERSPAN destination ports.
13. erspan-id erspan-id
14. vrf vrf-name
15. no shut
16. (Optional) show monitor session {all | session-number | range session-range}
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Example:
switch(config-if)#
Step 3 switchport Configures switchport parameters for the selected
Example:
19-312 OL-20635-03
Configuring ERSPAN
Command Purpose
Step 4 switchport mode [access | trunk] Configures the following switchport modes for the
selected slot and port or range of ports:
Example:
switch(config-if)# switchport mode trunk • access
• trunk
Step 5 switchport monitor Configures the switchport interface as an ERSPAN
destination.
Example:
Step 6 (Optional) Repeat Steps 2 to 5 to configure —
monitoring on additional ERSPAN destinations.
Step 7 no monitor session {session-number | all} Clears the configuration of the specified ERSPAN
Example:
switch(config-if)# no monitor session 3
Step 8 monitor session {session-number | all} Configures an ERSPAN destination session.
type erspan-destination
Example:
switch(config-if)# monitor session 3 type
erspan-destination
switch(config-erspan-dst)#
Example:
switch(config-erspan-dst)# description
erspan_dst_session_3
Step 10 source ip ip-address Configures the source IP address in the ERSPAN
session. Only one source IP address is supported per
Example:
switch(config-erspan-dst)# source ip
ERSPAN destination session.
10.1.1.1
Step 11 destination {[interface [type Configures a destination for copied source packets.
slot/port[-port][, type slot/port[-port]]] You can configure one or more interfaces as a series
[port-channel channel-number]]}
of comma-separated entries.
Example: Note You can configure destination ports as trunk
switch(config-erspan-dst)# destination
ports. For more information, see the Cisco
Nexus 7000 Series NX-OS Interfaces
Step 12 (Optional) Repeat Step 11 to configure all —
ERSPAN destinations.
Step 13 erspan-id erspan-id Configures the ERSPAN ID for the ERSPAN
session. The range is from 1 to 1023.
Example:
switch(config-erspan-dst)# erspan-id 5
Step 14 vrf vrf-name Configures the VRF that the ERSPAN destination
session uses for traffic forwarding.
Example:
switch(config-erspan-dst)# vrf default
OL-20635-03 19-313
Configuring ERSPAN
Command Purpose
Step 15 no shut Enables the ERSPAN destination session. By
default, the session is created in the shut state.
Example:
switch(config)# no shut Note Only 23 ERSPAN destination sessions
across VDCs can be running simultaneously.
Step 16 show monitor session {all | session-number (Optional) Displays the ERSPAN session
| range session-range} configuration.
Example:
Step 17 show running-config monitor (Optional) Displays the running ERSPAN
configuration.
Example:
switch(config)# show running-config
monitor
configuration.
Example:
switch(config)# show startup-config
monitor
Example:
startup-config
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 two ERSPAN sessions can be running simultaneously, you can shut down one session in
order 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.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. monitor session {session-range | all} shut
3. no monitor session {session-range | all} shut
4. monitor session session-number type erspan-source
5. monitor session session-number type erspan-destination
6. shut
7. no shut
19-314 OL-20635-03
Configuring ERSPAN
8. (Optional) show monitor session all

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 monitor session {session-range | all} shut Shuts down the specified ERSPAN sessions. The
session range is from 1 to 48. By default, sessions
Example:
switch(config)# monitor session 3 shut
are created in the shut state. Only two sessions can
be running at a time.
Step 3 no monitor session {session-range | all} Resumes (enables) the specified ERSPAN sessions.
shut The session range is from 1 to 48. By default,
Example:
sessions are created in the shut state. Only two
switch(config)# no monitor session 3 shut sessions can be running at a time.
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 Enters the monitor configuration mode for the
erspan-source ERSPAN source type. The new session
Example:
configuration is added to the existing session
switch(config)# monitor session 3 type configuration.
erspan-source
switch(config-erspan-src)#
Step 5 monitor session session-number type Enters the monitor configuration mode for the
erspan-destination ERSPAN destination type.
Example:
switch(config-erspan-src)# monitor session
3 type erspan-destination
Step 6 shut Shuts down the ERSPAN session. By default, the
Example:
switch(config-erspan-src)# shut
Step 7 no shut Enables the ERSPAN session. By default, the
Example:
switch(config-erspan-src)# no shut Note Only two ERSPAN sessions can be running
simultaneously.
OL-20635-03 19-315
Configuring ERSPAN
Command Purpose
Step 8 show monitor session all (Optional) Displays the status of ERSPAN sessions.
Example:
switch(config-erspan-src)# show monitor
session all
Step 9 show running-config monitor (Optional) Displays the ERSPAN running
configuration.
Example:
running-config monitor
configuration.
Example:
startup-config monitor
Example:
switch(config-erspan-src)# copy
Configuring the Multicast Best Effort Mode for an ERSPAN Session

You can configure the multicast best effort mode for any ERSPAN session. By default, ERSPAN
replication occurs on both the ingress and egress line card. When you enable the multicast best effort
mode, ERSPAN replication occurs only on the ingress line card for multicast traffic or on the egress line
card for packets egressing out of Layer 3 interfaces (that is, on the egress line card, packets egressing
out of Layer 2 interfaces are not replicated for ERSPAN).
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
3. [no] multicast best-effort
19-316 OL-20635-03
Verifying the ERSPAN Configuration
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
the ERSPAN session for which the multicast best
Example:
effort mode is to be configured.
Step 3 [no] multicast best-effort Configures the multicast best effort mode for the
specified ERSPAN session.
Example:
switch(config-monitor)# multicast
best-effort
Step 4 show monitor session session-number (Optional) Displays the status of ERSPAN sessions,
including the configuration status of the multicast
Example:
best effort mode and the modules on which the best
session 3 effort mode is and is not supported.
Example:
Verifying the ERSPAN Configuration

To display the ERSPAN configuration, perform one of the following tasks:
Command Purpose
show monitor session {all | session-number | Displays the ERSPAN session configuration.
range session-range}
show running-config monitor Displays the running ERSPAN configuration.
show startup-config monitor Displays the ERSPAN startup configuration.
Configuration Examples for ERSPAN

• Configuration Example for an ERSPAN Source Session, page 19-318
• Configuration Example for an ERSPAN Destination Session, page 19-318
OL-20635-03 19-317
Configuration Examples for ERSPAN
• Configuration Example for an ERSPAN ACL, page 19-318

• Configuration Example for ERSPAN Using the Multicast Best Effort Mode, page 19-319
Configuration Example for an ERSPAN Source Session

This example shows how to configure an ERSPAN source session:
switch# config t
switch(config)# interface e14/30
switch(config)# monitor erspan origin ip-address 3.3.3.3 global
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
Configuration Example for an ERSPAN Destination Session

This example shows how to configure an ERSPAN destination session:
switch# config t
switch(config)# interface e14/29
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
Configuration Example for an ERSPAN ACL

This example shows how to configure an ERSPAN ACL:
switch# config t
switch(config)# ip access-list match_11_pkts
switch(config-acl)# permit ip 11.0.0.0 0.255.255.255 any
switch(config-acl)# exit
switch(config)# ip access-list match_12_pkts
switch(config-acl)# permit ip 12.0.0.0 0.255.255.255 any
switch(config-acl)# exit
switch(config)# vlan access-map erspan_filter 5
switch(config-access-map)# match ip address match_11_pkts
switch(config-access-map)# action forward
switch(config-access-map)# exit
19-318 OL-20635-03
switch(config)# vlan access-map erspan_filter 10

switch(config-access-map)# match ip address match_12_pkts
switch(config-access-map)# action forward
switch(config-access-map)# exit
switch(config)# monitor session 1 type erspan-source
switch(config-erspan-src)# filter access_group erspan_filter
Configuration Example for ERSPAN Using the Multicast Best Effort Mode
This example shows how to configure the multicast best effort mode for an ERSPAN session:
switch# config t
switch(config-monitor)# multicast best-effort
switch(config-monitor)# show monitor session 1
For additional information related to implementing ERSPAN, see the following sections:
Related Documents
ERSPAN commands: complete command syntax, Cisco Nexus 7000 Series NX-OS System Management Command
Standards
Standards Title
OL-20635-03 19-319
Feature History for ERSPAN
Feature History for ERSPAN

Table 19-2 Feature History for ERSPAN

ERSPAN 5.2(1) Added ERSPAN source support for Cisco Nexus 2000
Series Fabric Extender interfaces.
ERSPAN 5.2(1) Added the ability to configure the multicast best effort
mode for an ERSPAN session.
ERSPAN and ERSPAN ACLs 5.1(1) This feature was introduced.
19-320 OL-20635-03
CHAPTER 20
Configuring LLDP
This chapter describes how to configure the Link Layer Discovery Protocol (LLDP) in order to discover
other devices on the local network.
Note The Cisco NX-OS release that is running on a managed device may not support all of the features or
settings described in this chapter. For the latest feature information and caveats, see the documentation
and release notes for your platform and software release.

• Information About LLDP, page 20-321
• Licensing Requirements for LLDP, page 20-323
• Configuring LLDP, page 20-324
• Verifying the LLDP Configuration, page 20-329
• Configuration Example for LLDP, page 20-329
• Feature History for LLDP, page 20-330
Information About LLDP

• LLDP Overview, page 20-322
• DCBXP Overview, page 20-322
OL-20635-03 20-321
Chapter 20 Configuring LLDP
Information About LLDP
LLDP Overview
The Cisco Discovery Protocol (CDP) is a device discovery protocol that runs over the data-link layer
(Layer 2) on all Cisco-manufactured devices (routers, bridges, access servers, and switches). CDP allows
network management applications to automatically discover and learn about other Cisco devices that are
connected to the network.
To permit the discovery of non-Cisco devices, the switch also supports the Link Layer Discovery
Protocol (LLDP), a vendor-neutral device discovery protocol that is defined in the IEEE 802.1ab
standard. LLDP allows network devices to advertise information about themselves to other devices on
the network. This protocol runs over the data-link layer, which allows two systems running different
network layer protocols to learn about each other.
LLDP is a one-way protocol that transmits information about the capabilities and current status of a
device and its interfaces. LLDP devices use the protocol to solicit information only from other LLDP
devices.
LLDP supports a set of attributes that it uses to discover other devices. These attributes contain type,
length, and value (TLV) descriptions. LLDP devices can use TLVs to send and receive information to other
devices on the network. Details such as configuration information, device capabilities, and device
identity can be advertised using this protocol.
LLDP advertises the following TLVs by default:
• DCBXP
• Management address
• Port description
• Port VLAN
• System capabilities
• System description
• System name
DCBXP Overview
The Data Center Bridging Exchange Protocol (DCBXP) is an extension of LLDP. It is used to announce,
exchange, and negotiate node parameters between peers. DCBXP parameters are packaged into a
specific DCBXP TLV. This TLV is designed to provide an acknowledgement to the received LLDP
packet. In this way, DCBXP adds a lightweight acknowledgement mechanism on top of LLDP so that
any application that needs a request-response semantic from a link-level protocol can make use of
DCBXP.
Other applications that need to exchange and negotiate parameters with peer nodes using DCBXP are as
follows:
• Priority-based Flow Control (PFC)—PFC is an enhancement to the existing Pause mechanism in
Ethernet. It enables Pause based on user priorities or classes of service. A physical link divided into
eight virtual links with PFC provides the capability to use Pause on a single virtual link without
affecting traffic on the other virtual links. Enabling Pause on a per-user-priority basis allows
administrators to create lossless links for traffic requiring no-drop service while retaining
packet-drop congestion management for IP traffic.
20-322 OL-20635-03
Licensing Requirements for LLDP
• Enhanced Transmission Selection (ETS)—ETS enables optimal bandwidth management of virtual

links. ETS is also called priority grouping. It enables differentiated treatments within the same
priority classes of PFC. ETS provides prioritized processing based on bandwidth allocation, low
latency, or best effort, resulting in per-group traffic class allocation. For example, an Ethernet class
of traffic may have a high-priority designation and a best effort within that same class. ETS allows
differentiation between traffic of the same priority class, thus creating priority groups.
• Application Priority Configuration TLV—Carries information about which VLANs will be used by
specific protocols.
Note For more information on the QoS features, see the Cisco Nexus 7000 Series NX-OS Quality of Service
DCBXP is enabled by default, provided LLDP is enabled. When LLDP is enabled, DCBXP can be
enabled or disabled using the [no] lldp tlv-select dcbxp command. DCBXP is disabled on ports where
LLDP transmit or receive is disabled.
High Availability
The LLDP feature supports stateless and stateful restarts. After a reboot or supervisor switchover, the
For more information on high availability, see the Cisco Nexus 7000 Series NX-OS High Availability and
Redundancy Guide, Release 5.x.
One instance of LLDP is supported per virtual device context (VDC). You are automatically placed in
the default VDC unless you specify otherwise.
For information on VDCs, see the Cisco Nexus 7000 Series NX-OS Virtual Device Context Configuration
Guide, Release 5.x.
Licensing Requirements for LLDP


Cisco NX-OS LLDP requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
OL-20635-03 20-323

LLDP has the following configuration guidelines and limitations:
• LLDP must be enabled on the device before you can enable or disable it on any interfaces.
• LLDP is supported only on physical interfaces.
• LLDP can discover up to one device per port.
• LLDP can discover Linux servers, provided they are not using a converged network adapter (CNA).
LLDP cannot discover other types of servers.
• DCBXP is not supported for the Cisco Nexus 2000 Series Fabric Extender.
• Beginning with Cisco NX-OS Release 5.2, LLDP is supported for the Cisco Nexus 2000 Series
Fabric Extender. LLDP packets can now be sent and received through the Fabric Extender ports for
neighbor discovery.
– All LLDP configuration on Fabric Extender ports occurs on the supervisor. LLDP configuration
and show commands are not visible on the Fabric Extender console.
– LLDP is not supported for a Fabric Extender-virtual port channel (vPC) connection.
Default Settings
Table 20-1 lists the LLDP default settings.
Table 20-1 LLDP Default Settings
Parameter Default
Global LLDP Disabled
LLDP on interfaces Enabled, after LLDP is enabled globally
LLDP hold time (before discarding) 120 seconds
LLDP reinitialization delay 2 seconds
LLDP timer (packet update frequency) 30 seconds
LLDP TLVs Enabled
LLDP receive Enabled, after LLDP is enabled globally
LLDP transmit Enabled, after LLDP is enabled globally
DCBXP Enabled, provided LLDP is enabled
Configuring LLDP
• Enabling or Disabling LLDP Globally, page 20-325
• Enabling or Disabling LLDP on an Interface, page 20-326
• Configuring Optional LLDP Parameters, page 20-327
20-324 OL-20635-03
Configuring LLDP
Note Cisco NX-OS commands for this feature may differ from Cisco IOS commands for a similar feature.
Enabling or Disabling LLDP Globally

You can enable or disable LLDP globally on a device. You must enable LLDP globally to allow a device
to send and receive LLDP packets.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. [no] feature lldp
3. (Optional) show running-config lldp
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 [no] feature lldp Enables or disables LLDP on the device. LLDP is
disabled by default.
Example:
switch(config)# feature lldp
Step 3 show running-config lldp (Optional) Displays the global LLDP configuration.
If LLDP is enabled, it shows “feature lldp.” If LLDP
Example:
switch(config)# show running-config lldp
is disabled, it shows an “Invalid command” error.
Example:
startup-config
This example shows how to enable LLDP globally on the device:

switch# config t
OL-20635-03 20-325
Configuring LLDP
Enabling or Disabling LLDP on an Interface

After you globally enable LLDP, it is enabled on all supported interfaces by default. However, you can
enable or disable LLDP on individual interfaces or selectively configure an interface to only send or only
receive LLDP packets.
Note If the interface is configured as a tunnel port, LLDP is disabled automatically.
BEFORE YOU BEGIN
Make sure that you have globally enabled LLDP on the device.
SUMMARY STEPS
1. config t
2. interface ethernet slot/port
3. [no] lldp transmit
4. [no] lldp receive
5. (Optional) show lldp interface ethernet slot/port
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 interface ethernet slot/port Specifies the interface on which you are enabling
LLDP and enters the interface configuration mode.
Example:
switch(config-if)
Step 3 [no] lldp transmit Enables or disables the transmission of LLDP
packets on an interface. After you globally enable
Example:
switch(config-if)# lldp transmit
LLDP, it is enabled on all supported interfaces by
default.
Step 4 [no] lldp receive Enables or disables the reception of LLDP packets
on an interface. After you globally enable LLDP, it
Example:
switch(config-if)# lldp receive
is enabled on all supported interfaces by default.
20-326 OL-20635-03
Configuring LLDP
Command Purpose
Step 5 show lldp interface ethernet slot/port (Optional) Displays the LLDP configuration on the
interface.
Example:
switch(config-if)# show lldp interface
ethernet 7/1
Example:
startup-config
This example shows how to disable the transmission of LLDP packets on an interface:
switch# config t
switch(config-if)# no lldp transmit
Configuring Optional LLDP Parameters

You can configure the frequency of LLDP updates, the amount of time for a receiving device to hold the
information before discarding it, and the initialization delay time. You can also select the TLVs to
include in LLDP packets.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. (Optional) [no] lldp holdtime seconds
3. (Optional) [no] lldp reinit seconds
4. (Optional) [no] lldp timer seconds
5. (Optional) show lldp timers
6. (Optional) [no] lldp tlv-select tlv
7. (Optional) show lldp tlv-select
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
OL-20635-03 20-327
Configuring LLDP
Command Purpose
Step 2 [no] lldp holdtime seconds (Optional) Specifies the amount of time in seconds
that a receiving device should hold the information
Example:
switch(config)# lldp holdtime 200
sent by your device before discarding it.
The range is 10 to 255 seconds; the default is 120
seconds.
Step 3 [no] lldp reinit seconds (Optional) Specifies the delay time in seconds for
LLDP to initialize on any interface.
Example:
switch(config)# lldp reinit 5 The range is 1 to 10 seconds; the default is 2
seconds.
Step 4 [no] lldp timer seconds (Optional) Specifies the transmission frequency of
LLDP updates in seconds.
Example:
switch(config)# lldp timer 50 The range is 5 to 254 seconds; the default is 30
seconds.
Step 5 show lldp timers (Optional) Displays the LLDP hold time, delay time,
and update frequency configuration.
Example:
switch(config)# show lldp timers
Step 6 [no] lldp tlv-select tlv (Optional) Specifies the TLVs to send and receive in
LLDP packets. The available TLVs are dcbxp,
Example:
switch(config)# lldp tlv-select
management-address, port-description, port-vlan,
system-name system-capabilities, system-description, and
system-name. All available TLVs are enabled by
default.
Note For more information about using these
TLVs, see the Cisco Nexus 7000 Series
NX-OS System Management Command
Reference.
Step 7 show lldp tlv-select (Optional) Displays the LLDP TLV configuration.
Example:
switch(config)# show lldp tlv-select
Example:
startup-config
This example shows how to configure a hold time of 200 seconds, a delay time of 5 seconds, and an
update frequency of 50 seconds as well as how to disable the port-vlan TLV:
switch# config t
switch(config)# lldp reinit 5
switch(config)# lldp timer 50
switch(config)# no lldp tlv-select port-vlan
20-328 OL-20635-03
Verifying the LLDP Configuration
Verifying the LLDP Configuration

To display the LLDP configuration, perform one of the following tasks:
Command Purpose
show running-config lldp Displays the global LLDP configuration.
show lldp interface ethernet slot/port Displays the LLDP interface configuration.
show lldp timers Displays the LLDP hold time, delay time, and
update frequency configuration.
show lldp tlv-select Displays the LLDP TLV configuration.
show lldp dcbx interface ethernet slot/port Displays the local DCBX control status.
show lldp neighbors {detail | interface ethernet Displays the LLDP neighbor device status.
slot/port}
show lldp traffic Displays the LLDP counters, including the
number of LLDP packets sent and received by the
device, the number of discarded packets, and the
number of unrecognized TLVs.
show lldp traffic interface ethernet slot/port Displays the number of LLDP packets sent and
received on the interface.
Use the clear lldp counters command to clear the LLDP statistics.
Configuration Example for LLDP

This example shows how to enable LLDP on a device; disable LLDP on some interfaces; configure
optional parameters such as hold time, delay time, and update frequency; and disable several LLDP
TLVs:
switch# config t
switch(config-if)# no lldp receive
switch(config-if)# no lldp receive
switch(config)# lldp reinit 5
switch(config)# lldp timer 50
switch(config)# no lldp tlv-select port-vlan
switch(config)# no lldp tlv-select system-name
OL-20635-03 20-329
For additional information related to implementing LLDP, see the following sections:
Related Documents
LLDP commands: complete command syntax, Cisco Nexus 7000 Series NX-OS System Management Command
Standards
Standards Title
Feature History for LLDP

Table 20-2 Feature History for LLDP

LLDP 5.2(1) Added LLDP support for the Cisco Nexus 2000 Series
Fabric Extender.
DCBXP 5.1(1) This feature was introduced.
LLDP 5.0(2) This feature was introduced.
20-330 OL-20635-03
CHAPTER 21
Configuring NetFlow
This chapter describes how to configure the NetFlow feature on Cisco NX-OS devices.
• Information About NetFlow, page 21-331
• Licensing Requirements for NetFlow, page 21-334
• Prerequisites for NetFlow, page 21-334
• Configuring NetFlow, page 21-335
• Verifying the NetFlow Configuration, page 21-348
• Monitoring NetFlow, page 21-349
• Configuration Example for NetFlow, page 21-349
• Feature History for NetFlow, page 21-350
Information About NetFlow

NetFlow identifies packet flows for both ingress and egress IP packets and provides statistics based on
these packet flows. NetFlow does not require any change to either the packets themselves or to any
networking device.
• NetFlow Overview, page 21-331
NetFlow Overview
NetFlow uses flows to provide statistics for accounting, network monitoring, and network planning. A
flow is a unidirectional stream of packets that arrives on a source interface (or VLAN) and has the same
values for the keys. A key is an identified value for a field within the packet. You create a flow using a
flow record to define the unique keys for your flow.
OL-20635-03 21-331
Chapter 21 Configuring NetFlow
Cisco NX-OS supports the Flexible NetFlow feature that enables enhanced network anomalies and
security detection. Flexible NetFlow allows you to define an optimal flow record for a particular
application by selecting the keys from a large collection of predefined fields. For more information on
the flow records, see the “Flow Records” section on page 21-332.
All key values must match for the packet to count in a given flow. A flow might gather other fields of
interest, depending on the export record version that you configure. Flows are stored in the NetFlow
cache.
You can export the data that NetFlow gathers for your flow by using an exporter and export this data to
a remote NetFlow collector. Cisco NX-OS exports a flow as part of a NetFlow export User Datagram
Protocol (UDP) datagram under the following circumstances:
• The flow has been inactive or active for too long.
• The flow cache is getting full.
• One of the counters (packets or bytes) has exceeded its maximum value.
• You have forced the flow to export.
For more information on exporters, see the “Exporters” section on page 21-332.
You define the size of the data that you want to collect for a flow using a monitor. The monitor combines
the flow record and exporter with the NetFlow cache information. For more information on monitors,
see the “Monitors” section on page 21-333.
Cisco NX-OS can gather NetFlow statistics in either full or sampled mode. Cisco NX-OS analyzes all
packets on the interface or subinterface for full NetFlow mode. For sampled mode, you configure the
sampling algorithm and rate that Cisco NX-OS analyzes packets. For more information on samplers, see
the “Samplers” section on page 21-333.
Flow Records
A flow record defines the keys that NetFlow uses to identify packets in the flow as well as other fields
of interest that NetFlow gathers for the flow. You can define a flow record with any combination of keys
and fields of interest. Cisco NX-OS supports a rich set of keys. A flow record also defines the types of
counters gathered per flow. You can configure 32-bit or 64-bit packet or byte counters. Cisco NX-OS
enables the following match fields as the defaults when you create a flow record:
• match interface input
• match interface output
• match flow direction
For more information, see the “Creating a Flow Record” section on page 21-336.
Exporters
An exporter contains network layer and transport layer details for the NetFlow export packet. You can
configure the following information in an exporter:
• Export destination IP address
• Source interface
• UDP port number (where the collector is listening for NetFlow packets)
• Export format
21-332 OL-20635-03
Note NetFlow export packets use the IP address that is assigned to the source interface. If the source interface
does not have an IP address assigned to it, the exporter will be inactive.
Cisco NX-OS exports data to the collector whenever a timeout occurs or when the flow is terminated
(TCP Fin or Rst received, for example). You can configure the following timers to force a flow export:
• Active timeout—Cisco NX-OS does not remove the cache entries from the cache.
• Inactive timeout—Cisco NX-OS removes the cache entries from the cache.
Export Formats
Cisco NX-OS supports the Version 5 and Version 9 export formats. We recommend that you use the
Version 9 export format for the following reasons:
• Variable field specification format
• Support for IPv6, Layer 2, and MPLS fields
• More efficient network utilization
If you configure the Version 5 export format, you have these limitations:
• Fixed field specifications
• No support for IPv6, Layer 2, or MPLS fields
• The Netflow.InputInterface and Netflow.OutputInterface represent a 16-bit I/O descriptor (IOD) of
the interface.
Note The IOD information of the interface can be retrieved using the show system internal im
info global command.
For information about the Version 9 export format, see RFC 3954.
Note Cisco NX-OS supports UDP as the transport protocol for exports to up to two collectors.
Monitors
A monitor references the flow record and flow exporter. You apply a monitor to an interface.
Samplers
If you are using sampled mode, you use the sampler to specify the rate at which packets are sampled. On
high bandwidth interfaces, applying NetFlow processing to every single packet can result in high CPU
utilization. Sampler configuration is for high-speed interfaces. You can configure samples for M out of
N. For example, 100 out of every 10,000 packets are sampled.
OL-20635-03 21-333
Licensing Requirements for NetFlow
High Availability
Cisco NX-OS supports stateful restarts for NetFlow. After a reboot or supervisor switchover, Cisco
A virtual device context (VDC) is a logical representation of a set of system resources. Within each
VDC, you can configure NetFlow. By default, Cisco NX-OS places you in the default VDC and any
flows that you define in this mode are only available for interfaces in the default VDC.
Licensing Requirements for NetFlow

Cisco NX-OS NetFlow requires no license. Any feature not included in a license package is bundled with the Cisco NX-OS
Prerequisites for NetFlow

NetFlow has the following prerequisites:
• You must understand the resources required on your device because NetFlow consumes additional
memory and CPU resources.
• If you configure VDCs, install the Advanced Services license and enter the desired VDC. For more
Release 5.x.

NetFlow has the following configuration guidelines and limitations:
• You must configure a source interface. If you do not configure a source interface, the exporter will
remain in a disabled state.
• You must configure a valid record name for every flow monitor.
• A rollback will fail if you try to modify a record that is programmed in the hardware during a
rollback.
• Only Layer 2 NetFlow is applied on Layer 2 interfaces, and only Layer 3 NetFlow is applied on
Layer 3 interfaces.
• If you add a member to a port channel that is already configured for Layer 2 NetFlow, its NetFlow
configuration is removed and the Layer 2 configuration of the port channel is added to it.
21-334 OL-20635-03
Default Settings
• If you change a Layer 2 interface to a Layer 3 interface, the software removes the Layer 2 NetFlow
configuration from the interface.
• Use v9 export to see the full 32-bit SNMP ifIndex values at the NetFlow connector.
• The maximum number of supported NetFlow entries is 512K.
• The Cisco Nexus 2000 Series Fabric Extender supports bridged NetFlow.
• Beginning with Cisco NX-OS Release 5.2, NetFlow is supported on switch virtual interfaces (SVIs)
for F1 Series ports. Bridged NetFlow on F1 Series ports is not supported.
Default Settings
Table 21-1 lists the default settings for NetFlow parameters.
Table 21-1 Default NetFlow Parameters
Parameters Default
Egress and Ingress cache size 512K
Flow active timeout 1800 seconds
Flow timeout aggressive threshold disabled
Flow timeout fast threshold disabled
Flow timeout inactive 15 seconds
Flow timeout session aging disabled
Configuring NetFlow
To configure NetFlow, follow these steps:
Step 1 Enable the NetFlow feature (see the “Enabling the NetFlow Feature” section on page 21-336).
Step 2 Define a flow record by specifying keys and fields to the flow (see the “Creating a Flow Record” section
on page 21-336).
Step 3 Define an optional flow exporter by specifying the export format, protocol, destination, and other
parameters (see the “Creating a Flow Exporter” section on page 21-339).
Step 4 Define a flow monitor based on the flow record and flow exporter (see the “Creating a Flow Monitor”
section on page 21-341).
Step 5 Apply the flow monitor to a source interface, subinterface, VLAN interface (see the “Applying a Flow
to an Interface” section on page 21-343), or a VLAN (see the “Configuring Bridged NetFlow on a
VLAN” section on page 21-344).

• Enabling the NetFlow Feature, page 21-336
• Creating a Flow Record, page 21-336
• Creating a Flow Exporter, page 21-339
OL-20635-03 21-335
Configuring NetFlow
• Creating a Flow Monitor, page 21-341

• Creating a Sampler, page 21-342
• Applying a Flow to an Interface, page 21-343
• Configuring Bridged NetFlow on a VLAN, page 21-344
• Configuring Layer 2 NetFlow, page 21-345
• Configuring NetFlow Timeouts, page 21-347
Note Be aware that the Cisco NX-OS commands for this feature may differ from those used in Cisco IOS.
Enabling the NetFlow Feature

You must globally enable NetFlow before you can configure any flows.
Use the following command in global configuration mode to enable NetFlow:
Command Purpose
feature netflow Enables the NetFlow feature.
Example:
switch(config)# feature netflow
Use the following command in global configuration mode to disable NetFlow and remove all flows:
Command Purpose
no feature netflow Disables the NetFlow feature. The default is
disabled.
Example:
switch(config)# no feature netflow
Creating a Flow Record

You can create a flow record and add keys to match on and fields to collect in the flow.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. flow record name
3. description string
4. match type
5. collect type
21-336 OL-20635-03
Configuring NetFlow
6. show flow record [name] [record-name | netflow-original | netflow protocol-port | netflow {ipv4
| ipv6} {original-input | original-output}}
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 flow record name Creates a flow record and enters flow record
configuration mode.
Example:
switch(config)# flow record Test
switch(config-flow-record)#
Step 3 description string (Optional) Describes this flow record as a maximum
63-character string.
Example:
switch(config-flow-record)# description
Ipv4Flow
Step 4 match type Specifies a match key. See the “Specifying the Match
Parameters” section on page 21-337 for more
Example:
switch(config-flow-record)# match
information on the type argument.
transport destination-port
Step 5 collect type Specifies the collection field. See the “Specifying the
Collect Parameters” section on page 21-338 for more
Example:
switch(config-flow-record)# collect
information on the type argument.
counter packets
Step 6 show flow record [name] [record-name | (Optional) Displays information about NetFlow flow
netflow-original | netflow protocol-port records.
| netflow {ipv4 | ipv6} {original-input
| original-output}}
Example:
switch(config-flow-exporter)# show flow
record netflow protocol-port
Example:
switch(config-flow-exporter)# copy
Specifying the Match Parameters

You must configure at least one of the following match parameters for flow records:
OL-20635-03 21-337
Configuring NetFlow
Command Purpose
match ip {protocol | tos} Specifies the IP protocol or ToS fields as keys.
Example:
switch(config-flow-record)# match ip
protocol
match ipv4 {destination address | source Specifies the IPv4 source or destination address as a
address} key.
Example:
switch(config-flow-record)# match ipv4
destination address
match ipv6 {destination address | source Specifies the IPv6 key.
address | flow-label | options}
Example:
switch(config-flow-record)# match ipv6
flow-label
match transport {destination-port | Specifies the transport source or destination port as a
source-port} key.
Example:
transport destination-port
match datalink {mac source-address | mac Specifies the Layer 2 attribute as a key.
destination-address | ethertype | vlan}
Example:
datalink ethertype
Specifying the Collect Parameters

You must configure at least one of the following collect parameters for flow records:
Command Purpose
collect counter {bytes | packets} [long] Collects either packet-based or byte counters from the
flow. You can optionally specify that 64-bit counters
Example:
are used.
counter packets
collect flow {direction | sampler id} Collects the direction of the flow or the sampler
identifier used for the flow.
Example:
switch(config-flow-record)# collect flow
direction
collect interface {input | output} Collects the input or output interface attribute.
Example:
interface input
21-338 OL-20635-03
Configuring NetFlow
Command Purpose
collect routing {destination | source} Collects the source or destination AS number of the
as [peer] local device or the peer.
Example:
routing destination as
collect routing forwarding-status Collects the forwarding status of the packet.
Example:
routing forwarding-status
collect routing next-hop address ipv4 Collects the next-hop IPv4 address.
[bgp]
Example:
routing next-hop address ipv4
collect routing next-hop address ipv6 Collects the next-hop IPv6 address.
[bgp]
Example:
routing next-hop address ipv6
collect timestamp sys-uptime {first | Collects the system up time for the first or last packet
last} in the flow.
Example:
timestamp sys-uptime last
collect transport tcp flags Collects the TCP transport layer flags for the packets
in the flow.
Example:
transport tcp flags
Creating a Flow Exporter

You can create a flow export to define the export parameters for a flow.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. flow exporter name
3. destination {ipv4-address | ipv6-address} [use-vrf name]
4. source interface-type number
5. version {5 | 9}
OL-20635-03 21-339
Configuring NetFlow
6. show flow exporter [name]

DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 flow exporter name Creates a flow exporter and enters flow exporter
configuration mode.
Example:
switch(config)# flow exporter ExportTest
switch(config-flow-exporter)#
Step 3 destination {ipv4-address | Sets the destination IPv4 or IPv6 address for this
ipv6-address} [use-vrf name] exporter. You can optionally configure the VRF to use
Example:
to reach the NetFlow collector.
destination 192.0.2.1
Step 4 source interface-type number Specifies the interface to use to reach the NetFlow
collector at the configured destination.
Example:
switch(config-flow-exporter)# source
ethernet 2/1
Step 5 version {5 | 9} Specifies the NetFlow export version. Version 9 enters
the export version configuration submode.
Example:
switch(config-flow-exporter)# version 9
switch(config-flow-exporter-version-9)#
Step 6 show flow exporter [name] (Optional) Displays information about NetFlow flow
exporters.
Example:
switch(config-flow-exporter)# show flow
exporter
Example:
switch(config-flow-exporter)# copy
You can optionally configure the following parameters for flow exporters:
Command Purpose
description string Describes this flow exporter as a maximum
63-character string.
Example:
description ExportV9
21-340 OL-20635-03
Configuring NetFlow
Command Purpose
dscp value Specifies the differentiated services codepoint value.
The range is from 0 to 63.
Example:
switch(config-flow-exporter)# dscp 0
transport udp number Specifies the UDP port to use to reach the NetFlow
collector. The range is from 0 to 65535.
Example:
switch(config-flow-exporter)# transport
udp 200
You can optionally configure the following parameters in flow exporter version configuration submode:
Command Purpose
option {exporter-stats | interface-table Sets the exporter resend timer. The range is from 1 to
| sampler-table} timeout seconds 86400 seconds.
Example:
option exporter-stats timeout 1200
template data timeout seconds Sets the template data resend timer. The range is from
1 to 86400 seconds.
Example:
template data timeout 1200
Creating a Flow Monitor

You can create a flow monitor and associate it with a flow record and a flow exporter.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. flow monitor name
4. exporter name
5. record {name | netflow-original | netflow protocol-port | netflow {ipv4 | ipv6} {original-input |
original-output}}
6. show flow monitor [name]
OL-20635-03 21-341
Configuring NetFlow
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 flow monitor name Creates a flow monitor and enters flow monitor
configuration mode.
Example:
switch(config)# flow monitor MonitorTest
switch(config-flow-monitor)#
Step 3 description string (Optional) Describes the flow monitor with an
Example:
switch(config-flow-monitor)# description
Ipv4Monitor
Step 4 exporter name Associates a flow exporter with this flow monitor.
Example:
switch(config-flow-monitor)# exporter
Exportv9
Step 5 record {name | netflow-original | Associates a flow record with the specified flow
netflow protocol-port | netflow {ipv4 | monitor.
ipv6} {original-input |
original-output}}
Example:
switch(config-flow-monitor)# record
IPv4Flow
Step 6 show flow monitor [name] (Optional) Displays information about NetFlow flow
monitors.
Example:
switch(config-flow-monitor)# show flow
monitor
Example:
switch(config-flow-monitor)# copy
Creating a Sampler
You can create a sampler to define the NetFlow sampling rate for a flow.
BEFORE YOU BEGIN
21-342 OL-20635-03
Configuring NetFlow
SUMMARY STEPS
1. config t
2. sampler name
4. mode samples out-of packets
5. show sampler [name]
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 sampler name Creates a sampler and enters flow sampler
configuration mode.
Example:
switch(config)# sampler SampleTest
switch(config-flow-sampler)#
Step 3 description string (Optional) Describes the sampler with an
Example:
switch(config-flow-sampler)# description
Samples
Step 4 mode samples out-of packets Defines the number of samples to take per the number
of packets received. The samples range is from 1 to 64.
Example:
switch(config-flow-sampler)# mode 1
The packets range is from 1 to 8192 packets.
out-of 100
Step 5 show sampler [name] (Optional) Displays information about NetFlow
samplers.
Example:
switch(config-flow-sampler)# show
sampler
Example:
switch(config-flow-sampler)# copy
Applying a Flow to an Interface

You can apply a flow monitor and an optional sampler to an interface.
BEFORE YOU BEGIN
OL-20635-03 21-343
Configuring NetFlow
SUMMARY STEPS
1. config t
2. interface interface-type number
3. ip flow monitor name {input | output} [sampler name]
4. ipv6 flow monitor name {input | output} [sampler name]
5. show flow interface [interface-type number]
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 interface interface-type number Enters interface configuration mode. The interface
type can be Ethernet (including subinterfaces), port
Example:
channel, VLAN, VLAN interface, or tunnel.
switch(config-if)#
Step 3 ip flow monitor name {input | output} Associates an IPv4 flow monitor and an optional
[sampler name] sampler to the interface for input or output packets.
Example:
switch(config-if)# ip flow monitor
MonitorTest input
Step 4 ipv6 flow monitor name {input | output} Associates an IPv6 flow monitor and an optional
[sampler name] sampler to the interface for input or output packets.
Example:
switch(config-if)# ipv6 flow monitor
MonitorTest input
Step 5 show flow interface [interface-type (Optional) Displays information about NetFlow on an
number] interface.
Example:
switch(config-if# show flow interface
Example:
startup-config
Configuring Bridged NetFlow on a VLAN

You can apply a flow monitor and an optional sampler to a VLAN.
21-344 OL-20635-03
Configuring NetFlow
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. vlan [configuration] vlan-id
3. ip flow monitor name {input | output} [sampler name]
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 vlan [configuration] vlan-id Enters VLAN or VLAN configuration mode. The
vlan-id range is from 1 to 3967 or from 4048 to 4093.
Example:
switch(config)# vlan configuration 30 Note VLAN configuration mode enables you to
switch(config-vlan-config)# configure VLANs independently of their
creation, which is required for VTP client
support.
Step 3 ip flow monitor name {input | output} Associates a flow monitor and an optional sampler to
[sampler name] the VLAN for input or output packets.
Example:
switch(config-vlan-config)# ip flow
monitor MonitorTest input
Example:
switch(config-vlan-config)# copy
Configuring Layer 2 NetFlow

You can define Layer 2 keys in flexible NetFlow records that you can use to capture flows in Layer 2
interfaces. The Layer 2 keys are as follows:
• Source and destination MAC addresses
• Source VLAN ID
• EtherType from the Ethernet frame
You can apply Layer 2 NetFlow to the following interfaces for the ingress direction:
• Switch ports in access mode
OL-20635-03 21-345
Configuring NetFlow
• Switch ports in trunk mode

• Layer 2 port channels
Note You cannot apply Layer 2 NetFlow to VLANs, egress interfaces, or Layer 3 interfaces such as VLAN
interfaces.
BEFORE YOU BEGIN
SUMMARY STEPS
1. config t
2. flow record name
3. match datalink {mac source-address | mac destination-address | ethertype | vlan}
4. interface {ethernet slot/port} | {port-channel number}
5. switchport
6. mac packet-classify
7. layer2-switched flow monitor flow-name input [sampler sampler-name]
8. show flow record netflow layer2-switched input
DETAILED STEPS
Command Purpose
Example:
switch# config t
switch(config)#
Step 2 flow record name Enters flow record configuration mode. For more
information about configuring flow records, see the
Example:
switch(config)# flow record L2_record
“Creating a Flow Record” section on page 21-336.
Step 3 match datalink {mac source-address | mac Specifies the Layer 2 attribute as a key.
destination-address | ethertype | vlan}
Example:
datalink ethertype
21-346 OL-20635-03
Configuring NetFlow
Command Purpose
Step 4 interface {ethernet slot/port} | Enters interface configuration mode. The interface
{port-channel number} type can be a physical Ethernet port or a port channel.
Example 1:
switch(config-if)#
Example 2:
switch(config)# interface port-channel 8
switch(config-if)#
Step 5 switchport Changes the interface to a Layer 2 physical interface.
For information about configuring switch ports, see the
Example:
Cisco Nexus 7000 Series NX-OS Layer 2 Switching
Step 6 mac packet-classify Forces MAC classification of packets. For more
information about using the mac packet-classify
Example:
switch(config-if)# mac packet-classify
command, see the Cisco Nexus 7000 Series NX-OS
Security Configuration Guide, Release 5.x.
Step 7 layer2-switched flow monitor flow-name Associates a flow monitor and an optional sampler to
input [sampler sampler-name] the switch port input packets. For information about
Example:
flow monitors, see the “Creating a Flow Monitor”
switch(config-vlan)# layer2-switched section on page 21-341. For information about
flow monitor L2_monitor input sampler samplers, see the “Creating a Sampler” section on
L2_sampler page 21-342.
Step 8 show flow record netflow layer2-switched (Optional) Displays information about the Layer 2
input NetFlow default record.
Example:
switch(config-if# show flow record
netflow layer2-switched input
Example:
switch(config-vlan)# copy running-config
startup-config
Configuring NetFlow Timeouts

You can optionally configure global NetFlow timeouts that apply to all flows.
Use the following commands in global configuration mode to configure NetFlow timeout parameters:
Command Purpose
flow timeout active seconds Sets the active timeout value in seconds. The range is
from 60 to 4092. The default is 1800.
Example:
switch(config)# flow timeout active 90
flow timeout aggressive threshold Enables using a percentage that you want the NetFlow
percent table to be before aggressive aging starts. The range is
Example:
from 50 to 99. The default is disabled.
switch(config)# flow timeout aggressive
threshold 90
OL-20635-03 21-347
Verifying the NetFlow Configuration
Command Purpose
flow timeout fast seconds threshold Enables using a fast timeout value and the number of
packets packets in a flow before aging begins. The fast timeout
Example:
range in seconds is from 32 to 512. The packet range is
switch(config)# flow timeout fast 40 from 1 to 4000. The default is disabled.
threshold 1200
flow timeout inactive seconds Sets the inactive timeout value in seconds. The range
is from 15 to 4092. The default is 15.
Example:
switch(config)# flow timeout inactive
900
flow timeout session Enables TCP session aging. The default is disabled.
Example:
switch(config)# flow timeout session
Verifying the NetFlow Configuration

To display NetFlow configuration information, perform one of the following tasks:
Command Purpose
show flow exporter [name] Displays information about NetFlow flow
exporters and statistics.
show flow interface [interface-type number] Displays information about NetFlow interfaces.
show flow monitor [name] [cache [detailed]] Displays information about NetFlow flow
monitors and statistics.
show flow record [name] Displays information about NetFlow flow
records.
show flow record netflow layer2-switched Displays information about the Layer 2 NetFlow
input configuration.
show flow timeout Displays information about NetFlow timeouts.
show hardware flow aging [vdc vdc_id] [detail] Displays information about NetFlow aging flows
[module module] in the hardware.
show hardware flow entry address Displays information about NetFlow table entries
table-address type {ip | ipv6} [module module] in the hardware.
show hardware flow ip [detail | instance Displays information about NetFlow IPv4 flows
instance | interface type number | module module in the hardware.
| monitor monitor_name | profile profile-id | vdc
vdc_id | vlan vlan_id] [detail] [instance instance]
[module module]
show hardware flow sampler [all | count | index Displays information about the NetFlow sampler
number | name sampler-name | vdc vdc_id] in the hardware.
[detail] [module module]
show hardware flow utilization [module module Displays information about NetFlow table
| instance instance [module module]] utilization in the hardware.
show sampler [name] Displays information about NetFlow samplers.
21-348 OL-20635-03
Monitoring NetFlow
Monitoring NetFlow
Use the show flow exporter command to display NetFlow statistics.
Use the clear flow exporter command to clear NetFlow exporter statistics. Use the clear flow monitor
command to clear the monitor cache and statistics.
Configuration Example for NetFlow

This example shows how to create a flow and apply it to an interface:
feature netflow
flow exporter ee
version 9
flow record rr
match ipv4 source address
match ipv4 destination address
collect counter bytes
collect counter packets
flow monitor foo
record rr
exporter ee
interface Ethernet2/45
ip flow monitor foo output
ip address 10.20.1.1/24
no shutdown
For additional information related to implementing NetFlow, see the following sections:
Related Documents
NetFlow CLI commands Cisco Nexus 7000 Series NX-OS System Management Command
Reference
Standards
Standards Title
OL-20635-03 21-349
Feature History for NetFlow
Feature History for NetFlow

Table 21-2 Feature History for NetFlow

NetFlow 5.2(1) NetFlow is supported on switch virtual interfaces (SVIs) for
F1 Series ports.
Bridged NetFlow 5.1(1) VLAN configuration mode, which enables you to configure
VLANs independently of their creation, is supported when
configuring bridged NetFlow on a VLAN.
See the “Configuring Bridged NetFlow on a VLAN” section
on page 21-344.
NetFlow verification 5.0(2) You can specify the NetFlow instance for which you want to
display NetFlow IPv4 flows and NetFlow table utilization.
See the “Verifying the NetFlow Configuration” section on
page 21-348.
Layer 2 NetFlow 4.2(1) You can define Layer 2 keys in flexible NetFlow records
that you can use to capture flows in Layer 2 interfaces.
page 21-334 and the “Configuring Layer 2 NetFlow”
Rollback during NetFlow 4.1(3) Rollback fails for NetFlow if, during rollback, you try to
modify a record that is programmed in the hardware.
page 21-334.
21-350 OL-20635-03
A P P E NDIX 22
IETF RFCs supported by Cisco NX-OS
System Management
This appendix lists the IETF RFCs for system management supported in Cisco NX-OS.
RFCs
RFCs Title
RFC 2819 Remote Network Monitoring Management Information Base
RFC 3164 The BSD syslog Protocol
RFCs 3411 to 3418 An Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks
RFC 3954 Cisco Systems NetFlow Services Export Version 9
OL-20635-03 22-351
Appendix 22 IETF RFCs supported by Cisco NX-OS System Management
22-352 OL-20635-03
A P P E NDIX 23
Embedded Event Manager System Events and
Configuration Examples
This appendix describes the Embedded Event Manager (EEM) system policies, events, and policy
configuration examples.
This appendix includes the following sections:
• EEM System Policies, page 23-353
• EEM Events, page 23-355
• Configuration Examples for EEM Policies, page 23-356
• Feature History for EEM Policies, page 23-367
EEM System Policies

Table 23-1 lists the Embedded Event Manger (EEM) system policies.
Table 23-1 EEM System Policies
Event Description
__PortLoopback Do CallHome, log error in Syslog/OBFL/Exception Log, and
disable further HM testing on affected ports after 10 consecutive
failures of GOLD "PortLoopback" test
__RewriteEngineLoopback Do CallHome, log error in Syslog/OBFL/Exception Log, and
disable further HM testing on affected ports after 10 consecutive
failures of GOLD "RewriteEngine" test
__asic_register_check Do CallHome, log error, and disable further HM testing for that
ASIC device/instance after 20 consecutive failures of GOLD
"ASICRegisterCheck" test
__compact_flash Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "CompactFlash" test
__crypto_device Do CallHome and log error when GOLD "CryptoDevice" test
fails
__eobc_port_loopback Do CallHome and log error when GOLD "EOBCPortLoopback"
test fails
__ethpm_debug_1 Action: none
OL-20635-03 23-353
Appendix 23 Embedded Event Manager System Events and Configuration Examples
EEM System Policies
Table 23-1 EEM System Policies (continued)
Event Description
__ethpm_link_flap More than 30 link flaps in a 420-second interval. Action: Error.
Disable the port
__external_compact_flash Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "ExternalCompactFlash" test
__lamira_IDS_pkt_drop Generates syslogs on IDS drops
Note The system generates a maximum of one syslog every 30
minutes when an intrusion detection system (IDS) packet
is dropped. The syslog is generated as soon as the first
IDS packet drop occurs.
__lcm_module_failure Power cycle two times and then power down
__management_port_loopback Do CallHome and log error when GOLD
"ManagementPortLoopback" test fails
__nvram Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "NVRAM" test
__pfm_fanabsent_all_systemfan Shuts down if both fan trays (f1 and f2) are absent for 2 minutes
__pfm_fanabsent_all_xbarfan Cisco Nexus 7010 switch only: Shuts down if both fabric module
fan trays (f3 and f4) are absent for 2 minutes
__pfm_fanabsent_any_singlefan Cisco Nexus 7018 switch: Shuts down half-chassis if the fan tray
is absent for 3 minutes
Cisco Nexus 7010 switch: Syslog (The remaining fan tray
increases its speed if one fan tray is absent.)
__pfm_fanbad_all_systemfan Syslog when fan goes bad
__pfm_fanbad_all_xbarfan Cisco Nexus 7010 switch only: Shuts down if both fabric module
fans (f3 and f4) are bad for 2 minutes
__pfm_fanbad_any_singlefan Syslog when fan goes bad
__pfm_power_over_budget Syslog warning for insufficient power overbudget
__pfm_tempev_major TempSensor Major Threshold. Action: Shutdown
__pfm_tempev_minor TempSensor Minor Threshold. Action: Syslog
__primary_bootrom Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "PrimaryBootROM" test
__pwr_mgmt_bus Do CallHome, log error, and disable further HM testing for the
module or spine-card after 20 consecutive failures of GOLD
"PwrMgmtBus" test
__real_time_clock Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "RealTimeClock" test
__secondary_bootrom Do CallHome, log error, and disable further HM testing after 20
consecutive failures of GOLD "SecondaryBootROM" test
23-354 OL-20635-03
EEM Events
Table 23-1 EEM System Policies (continued)
Event Description
__spine_control_bus Do CallHome, log error, and disable further HM testing for that
module or spine-card after 20 consecutive failures of GOLD
"SpineControlBus" test
__standby_fabric_loopback Do CallHome, log error, and disable further HM testing after 10
consecutive failures
__status_bus Do CallHome, log error, and disable further HM testing after 5
consecutive failures of GOLD "StatusBus" test
__system_mgmt_bus Do Call Home, log error, and disable further HM testing for that
fan or power supply after 20 consecutive failures of GOLD
“SystemMgmtBus” test
__usb Do Call Home and log error when GOLD “USB” test fails
EEM Events
Table 23-2 describes the EEM events you can use on the device.
Table 23-2 EEM Events
EEM Event Description

cli CLI command is entered that matches a pattern with a wildcard.
counter EEM counter reaches a specified value or range.
fanabsent System fan tray is absent.
fanbad System fan generates a fault.
gold GOLD test failure condition is hit.
memory Available system memory exceeds a threshold.
module Specified module enters the selected status.
module-failure Module failure is generated.
oir Online insertion or removal occurs.
policy-default Default parameters and thresholds are used for the events in the
system policy you override.
poweroverbudget Platform software detects a power budget condition.
snmp SNMP object ID (OID) state changes.
storm-control Platform software detects an Ethernet packet storm condition.
syslog Monitors syslog messages and invokes the policy based on the
search string in the policy.
sysmgr System manager generates an event.
temperature Temperature level in the system exceeds a threshold.
track Tracked object changes state.
OL-20635-03 23-355
Configuration Examples for EEM Policies

• Configuration Examples for CLI Events, page 23-356
• Configuration Examples to Override (Disable) Major Thresholds, page 23-357
• Configuration Examples to Override (Disable) Shutdown for Fan Tray Removal, page 23-360
• Configuration Examples to Create a Supplemental Policy, page 23-363
• Configuration Examples for the Power Over-Budget Policy, page 23-363
• Configuration Examples to Select Modules to Shut Down, page 23-364
• Configuration Examples for the Online Insertion Removal Event, page 23-365
• Configuration Example to Generate a User Syslog, page 23-365
• Configuration Example to Monitor Syslog Messages, page 23-366
• Configuration Examples for SNMP Notification, page 23-366
• Configuration Example for Port Tracking, page 23-367
Configuration Examples for CLI Events

This section includes the following examples of CLI event configuration:
• Monitoring Interface Shutdown, page 23-356
• Monitoring Module Powerdown, page 23-356
• Adding a Trigger to Initiate a Rollback, page 23-357
Monitoring Interface Shutdown

This example shows how to monitor an interface shutdown:
switch# config t
switch(config)# event manager applet monitorShutdown
switch(config-applet)# description “Monitors interface shutdown.”
switch(config-applet)# event cli match “conf t; interface *; shutdown”
switch(config-applet)# action 1.0 cli show interface e 3/1
Note Outputs of show commands entered as part of EEM policy are archived in the logflash as text files with
the “eem_archive_” prefix. To view the archived output, use the show file logflash:eem_archive_n
command.
Monitoring Module Powerdown

This example shows how to monitor a module powerdown:
switch# config t
switch(config)# event manager applet monitorPoweroff
23-356 OL-20635-03
switch(config-applet)# description “Monitors module power down.”

switch(config-applet)# event cli match “conf t; poweroff *”
switch(config-applet)# action 1.0 cli show module
Adding a Trigger to Initiate a Rollback

This example shows how to add a trigger to initiate a rollback:
switch# config t
switch(config)#
switch(config)# event manager applet rollbackTrigger
switch(config-applet)# description “Rollback trigger.”
switch(config-applet)# event cli match “rollback *”
switch(config-applet)# action 1.0 cli copy running-config bootflash:last_config
Configuration Examples to Override (Disable) Major Thresholds

• Preventing a Shutdown When Reaching a Major Threshold, page 23-357
• Disabling One Bad Sensor, page 23-358
• Disabling Multiple Bad Sensors, page 23-358
• Overriding (Disabling) an Entire Module, page 23-358
• Overriding (Disabling) Multiple Modules and Sensors, page 23-359
• Enabling One Sensor While Disabling All Remaining Sensors of All Modules, page 23-359
• Enabling Multiple Sensors While Disabling All Remaining Sensors of All Modules, page 23-359
• Enabling All Sensors of One Module While Disabling All Sensors of the Remaining Modules,
page 23-360
• Enabling a Combination of Sensors on Modules While Disabling All Sensors of the Remaining
Modules, page 23-360
Preventing a Shutdown When Reaching a Major Threshold

This example shows how to prevent a shutdown caused by reaching a major threshold:
switch# config t
switch(config)# event manager applet myappletname override __pfm_tempev_major
switch(config)# end
This example shows how to revert to the default configuration:

switch# config t
switch(config)# no event manager applet myappletname override __pfm_tempev_major
switch(config)# end
OL-20635-03 23-357
Disabling One Bad Sensor

This example shows how to disable only sensor 3 on module 2 when sensor 3 is malfunctioning (all other
sensors are unaffected):
switch# config t
switch(config-applet)# event temperature module 2 sensor 3 threshold major
switch(config-applet)# end

switch# config t
switch(config)# end
Disabling Multiple Bad Sensors

This example shows how to disable sensors 5, 6, and 7 on module 2 when these sensors are
malfunctioning (all other sensors are unaffected):
switch# config t
switch# config t
switch# config t

switch# config t
switch(config)# end
Overriding (Disabling) an Entire Module

This example shows how to disable module 2 when it is malfunctioning:
switch# config t
switch(config-applet)# event temperature module 2 threshold major

switch# config t
switch(config)# end
23-358 OL-20635-03
Overriding (Disabling) Multiple Modules and Sensors

This example shows how to disable sensors 3, 4, and 7 on module 2 and all sensors on module 3 when
they are malfunctioning:
switch# config t
switch# config t
switch# config t
switch# config t

switch# config t
switch(config)# end
Enabling One Sensor While Disabling All Remaining Sensors of All Modules
This example shows how to disable all sensors on all modules except sensor 4 on module 9:
switch# config t
switch(config)# event manager applet myapplet1 override __pfm_tempev_major
switch# config t
switch(config-applet)# action 2 policy-default
Enabling Multiple Sensors While Disabling All Remaining Sensors of All Modules
This example shows how to disable all sensors on all modules except sensors 4, 6, and 7 on module 9:
switch# config t
switch# config t
switch# config t
switch# config t
OL-20635-03 23-359

Enabling All Sensors of One Module While Disabling All Sensors of the Remaining Modules
This example shows how to disable all sensors on all modules except all sensors on module 9:
switch# config t
switch# config t
Enabling a Combination of Sensors on Modules While Disabling All Sensors of the Remaining
Modules
This example shows how to disable all sensors on all modules except sensors 3, 4, and 7 on module 2
and all sensors on module 3:
switch# config t
switch# config t
switch# config t
switch# config t
switch# config t
Configuration Examples to Override (Disable) Shutdown for Fan Tray

Removal
• Overriding (Disabling) a Shutdown for Removal of One or More Fan Trays, page 23-361
• Overriding (Disabling) a Shutdown for Removal of a Specified Fan Tray, page 23-361
• Overriding (Disabling) a Shutdown for Removal of Multiple Specified Fan Trays, page 23-361
• Overriding (Disabling) a Shutdown for Removal of All Fan Trays Except One, page 23-362
23-360 OL-20635-03
• Overriding (Disabling) a Shutdown for Removal of Fan Trays Except for a Specified Set of Fan
Trays, page 23-362
• Overriding (Disabling) a Shutdown for Removal of All Fan Trays Except One from a Set of Fan
Trays, page 23-362
Note When you remove a fan tray from a Cisco Nexus 7010 switch, a shutdown does not occur. The remaining
fan tray increases its speed, and a message is written to the syslog.
Note When you remove a fan tray from a Cisco Nexus 7018 switch, the switch starts a 3-minute timer. If you
do not replace the fan tray within that 3 minutes, the switch shuts down the modules cooled by that timer
to prevent an overtemperature condition. If you override the timer with an EEM command, an
overtemperature condition can occur, which will cause a shutdown.
Overriding (Disabling) a Shutdown for Removal of One or More Fan Trays

This example shows how to disable a shutdown so that you can remove one or more (or all) fan trays:
switch# config t
switch(config)# event manager applet myappletname override __pfm_fanabsent_any_singlefan

switch# config t
switch(config)# no event manager applet myappletname override
__pfm_fanabsent_any_singlefan
Overriding (Disabling) a Shutdown for Removal of a Specified Fan Tray

This example shows how to disable a shutdown so that you can remove a specified fan tray (fan tray 3):
switch# config t
switch(config)# event manager applet myappletname override __pfm_fanabsent_any_singlefan
switch(config-applet)# event fanabsent fan 3 time 60

switch# config t
switch(config) no event manager applet myappletname override __pfm_fanabsent_any_singlefan
switch(config)# end
Overriding (Disabling) a Shutdown for Removal of Multiple Specified Fan Trays

This example shows how to disable a shutdown so that you can remove multiple specified fan trays (fan
trays 2, 3, and 4):
switch# config t
switch(config)# event manager applet myapplet1 override __pfm_fanabsent_any_singlefan
switch# config t
OL-20635-03 23-361
switch# config t

switch# config t
switch(config)# no event manager applet myappletname override
__pfm_fanabsent_any_singlefan
switch(config)# end
Overriding (Disabling) a Shutdown for Removal of All Fan Trays Except One
This example shows how to disable a shutdown so that you can remove all fan trays except one (fan tray
2):
switch# config t
switch# config t
Overriding (Disabling) a Shutdown for Removal of Fan Trays Except for a Specified Set of Fan
Trays
This example shows how to disable a shutdown so that you can remove fans except for a specified set of
fan trays (fan trays 2, 3, and 4):
switch# config t
switch(config-applet)# event fanabsent fan 2,3,4 time 60
Overriding (Disabling) a Shutdown for Removal of All Fan Trays Except One from a Set of Fan
Trays
This example shows how to disable a shutdown so that you can remove all fan trays except one from a
set of fan trays (fan trays 2, 3, or 4):
switch# config t
switch# config t
switch# config t
23-362 OL-20635-03
switch# config t
Configuration Examples to Create a Supplemental Policy

• Creating a Supplemental Policy for the Fan Tray Absent Event, page 23-363
• Creating a Supplemental Policy for the Temperature Threshold Event, page 23-363
Creating a Supplemental Policy for the Fan Tray Absent Event

This example shows how to create a supplemental policy using the event fanabsent command:
[no] event fanabsent [fan fan-tray-number] time time-interval
In addition to the default policy, this example shows how to execute the policy myappletname and action
3 if fan tray 1 is absent for 60 seconds:
switch# config t
switch(config)# event manager applet myappletname
switch(config-applet)# action 3 cli “show env fan”
Creating a Supplemental Policy for the Temperature Threshold Event

This example shows how to create a supplemental policy using the event temperature command:
[no] event temperature [mod module-number] [sensor sensor-number] threshold {major | minor
| any}
In addition to the default policy, this example shows how to execute the policy myappletname and action
1 if the temperature crosses the minor threshold on sensor 3 of module 2:
switch# config t
switch(config)# event manager applet myappletname
switch(config-applet)# event temperature module 2 sensor 3 threshold minor
switch(config-applet)# action 1 cli “show environ temperature”
Configuration Examples for the Power Over-Budget Policy

The power over-budget policy gets triggered when the available power capacity drops below zero and
the device is no longer able to keep the previously powered-up modules in the powered-up state. The
default action is to print a syslog to notify the user of the occurrence of power over budget.
You can enable an additional action to power down modules until the available power recovers from the
red (negative) zone.
OL-20635-03 23-363
• Shutting Down Modules, page 23-364

• Shutting Down a Specified List of Modules, page 23-364
Shutting Down Modules

If you do not specify any modules, the power over-budget shutdown starts from slot 1 and shuts down
modules until the power recovers from the red (negative) zone. Empty slots and slots that contain a
supervisor, standby supervisor, spine, or crossbar are skipped.
This example shows how to shut down modules starting from module 1 when the available power drops
below zero:
switch# config t
switch(config)# event manager applet <myappletname4a> override __pfm_power_over_budget
switch(config-applet)# event poweroverbudget
switch(config-applet)# action 4 overbudgetshut
Shutting Down a Specified List of Modules

You can specify a list of modules that the power over-budget action uses to shut down modules until the
power recovers from the red (negative) zone. Empty slots and slots that contain a supervisor, standby
supervisor, spine, or crossbar are skipped.
This example shows how to shut down modules from a specified list of modules (1, 2, 7, 8) when the
available power drops below zero:
switch# config t
switch(config)# event manager applet <myappletname4b> override __pfm_power_over_budget
switch(config-applet)# event poweroverbudget
switch(config-applet)# action 5 overbudgetshut module 1,2,7,8
Configuration Examples to Select Modules to Shut Down

• Using the Policy Default to Select Nonoverridden Modules to Shut Down, page 23-364
• Using Parameter Substitution to Select Nonoverridden Modules to Shut Down, page 23-365
Using the Policy Default to Select Nonoverridden Modules to Shut Down

This example shows how to use the policy default to select the nonoverridden modules to shut down
when a major threshold is exceeded:
switch# config t
switch(config)# event manager applet my5a1 override __pfm_tempev_major
switch# config t
switch(config)# event manager applet my5a2 override __pfm_tempev_major
switch(config-applet)# event temperature module 1-3 sensor 4 threshold major
23-364 OL-20635-03
Using Parameter Substitution to Select Nonoverridden Modules to Shut Down

This example shows how to use parameter substitution to select the nonoverridden modules to shut down
when a major threshold is exceeded:
switch# config t
switch(config)# event manager applet my5b1 override __pfm_tempev_major
switch# config t
switch(config)# event manager applet my5b2 override __pfm_tempev_major
switch(config-applet)# event temperature module 1-3 sensor 8 threshold major
switch(config-applet)# action 6 forceshut module my_module_list reset “temperature-sensor
policy trigger”
To create event manager parameters, use the event manager environment command. To display the
values of event manager parameters, use the show event manager environment all command.
Configuration Examples for the Online Insertion Removal Event

The online insertion removal (OIR) event does not have a default policy.
This example shows how to configure the OIR event using the event oir command:
event oir device-type event-type [device-number]
The device-type can be fan, module or powersupply.

The event-type can be insert, remove, or anyoir (insert or remove).
The optional device-number specifies a single device. If omitted, all devices are selected.
This example shows how to configure the insert event:
switch# config t
switch(config)# event manager applet myoir
switch(config-applet)# event oir module insert
switch(config-applet)# action 1 syslog priority critical msg “OIR insert event: A Module
is inserted”
This example shows how to configure the remove event:

switch# config t
switch(config-applet)# event oir module remove
switch(config-applet)# action 1 syslog priority critical msg “OIR remove event: A Module
is removed”
Configuration Example to Generate a User Syslog

This example shows how to generate a user syslog using the action syslog command:
switch# config t
switch(config-applet)# event oir module remove
switch(config-applet)# action 1 syslog priority critical msg “Module is removed”
When this event is triggered, the system generates a syslog as follows:

p1b-57(config)# 2008 Feb 20 00:08:27 p1b-57 %$ VDC-1 %$ %EEM_ACTION-2-CRIT: “Module is
removed”
OL-20635-03 23-365
Configuration Example to Monitor Syslog Messages

This example shows how to monitor syslog messages from the switch:
switch(config)# event manager applet a1
switch(config-applet)# event syslog occurs 6 period 4294967 pattern "authentication
failed"
When this event is triggered, the action defined in the policy is executed.
Configuration Examples for SNMP Notification

• Polling an SNMP OID to Generate an EEM Event, page 23-366
• Sending an SNMP Notification in Response to an Event in the Event Policy, page 23-366
Polling an SNMP OID to Generate an EEM Event

The SNMP object ID (OID) CISCO-SYSTEM-EXT-MIB::cseSysCPUUtilization is used for querying
the CPU utilization of the switch:
cseSysCPUUtilization OBJECT-TYPE
SYNTAX Gauge32 (0..100 )
UNITS "%"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The average utilization of CPU on the active supervisor."
::= { ciscoSysInfoGroup 1 }
This example shows the use of an SNMP OID that is polled at an interval of 10 seconds and has a
threshold value of 95 percent:
switch# config t
switch(config)# event manager applet test_policy
switch(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.305.1.1.1.0 get-type exact entry-op
gt entry-val 95 exit-op lt exit-val 90 poll-interval 10
Sending an SNMP Notification in Response to an Event in the Event Policy

You can use this type of configuration to cause a critical event trigger to generate an SNMP notification.
This example shows how to send an SNMP notification for an event from the Event Manager applet
configuration mode:
switch(config-applet)# action 1.1 snmp-trap intdata1 100 intdata2 300 strdata "CPU Hogging
at switch1"
switch(config-applet)# action 1.1 snmp-trap intdata1 100 intdata2 300 strdata "Port
Failure eth9/1"
This configuration triggers an SNMP notification (trap) from the switch to SNMP hosts. The SNMP
payload carries the values of user-defined fields intdata1, intdata2, and strdata.
23-366 OL-20635-03
Feature History for EEM Policies
Configuration Example for Port Tracking

This example shows how to configure the state of one port to match the state of another port (port
tracking).
To configure the port tracking of Ethernet interface 3/23 by Ethernet interface 1/2, follow these steps:
Step 1 Create an object to track the status of Ethernet interface 3/23.

switch# config t
switch(config)# track 1 interface ethernet 3/23
switch(config-track)# end
Step 2 Configure an EEM event to shut Ethernet interface 1/2 when the tracking object shuts down.
switch(config)# event manager applet track_3_23_down
switch(config-applet)# event track 1 state down
switch(config-applet)# action 1 syslog msg EEM applet track_3_23_down shutting down port
eth1/2 due to eth3/23 being down
switch(config-applet)# action 2 cli conf term
switch(config-applet)# action 3 cli interface ethernet 1/2
switch(config-applet)# action 4 cli shut
Step 3 Configure an EEM event to bring up Ethernet interface 1/2 when Ethernet interface 3/23 comes up.
switch# config t
switch(config)# event manager applet track_3_23_up
switch(config-applet)# event track 1 state up
switch(config-applet)# action 1 syslog msg EEM applet track_3_23_down bringing up port
eth1/2 due to eth3/23 being up
switch(config-applet)# action 2 cli conf term
switch(config-applet)# action 3 cli interface ethernet 1/2
switch(config-applet)# action 4 cli no shut

Table 23-3 Feature History for EEM Policies

EEM event correlation 5.2(1) Added support for multiple event triggers in a single EEM
policy. See the configuration example in Chapter 16,
“Configuring the Embedded Event Manager..’’
Syslog as EEM publisher 5.1(1) Added support to monitor syslog messages from the switch.
EEM system policies 5.0(2) Updated the fan EEM policies for the Cisco Nexus 7010
switch.
OL-20635-03 23-367
23-368 OL-20635-03
Send document comments to [email protected]
A P P E NDIX 24
Configuration Limits for Cisco NX-OS System
Management
The configuration limits are documented in the Cisco Nexus 7000 Series NX-OS Verified Scalability
Guide.
OL-20635-03 24-369
Appendix 24 Configuration Limits for Cisco NX-OS System Management
Send document comments to [email protected]
24-370 OL-20635-03

Nexus 7000 NX OS PDF

Uploaded by

Copyright:

Available Formats

Nexus 7000 NX OS PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nexus 7000 NX OS PDF

Uploaded by

Copyright:

Available Formats

Send document comments to [email protected].

coordinated distributions 2-3

Send document comments to [email protected].

enabling distribution for FC port security

enabling distribution for RSCN configurations 2-16 OBFL 15-3

enabling distribution for TACACS+ online diagnostics 13-6

Send document comments to [email protected].

description 14-1 to 14-5 guidelines 17-4

Send document comments to [email protected].

online diagnostics 13-5 guidelines 18-4

licensing requirements MIBs

Send document comments to [email protected].

creating an export map 19-9 configuring server 3-7

Send document comments to [email protected].

online diagnostics high availability 4-3

Send document comments to [email protected].

licensing requirements 8-3 discarding a session 9-6

Send document comments to [email protected].

Send document comments to [email protected].

configuring an RSPAN VLAN 16-14 configuring severity level to log 6-7

as EEM publisher 14-19 CFS 2-5

See system messages NTP 3-3

system checkpoints 8-2 PTP 4-4

system messages virtualization support

clearing a log file 6-11 LLDP 18-3

configuring (example) 6-12 VTP

configuring a syslog server 6-8 CDP 5-2

configuring a syslog server on a Linux system 6-10

Send document comments to [email protected].

New and Changed Information

Table 1 New and Changed Features for Release 5.x

Send document comments to [email protected].

Table 1 New and Changed Features for Release 5.x (continued)

Send document comments to [email protected].

Table 1 New and Changed Features for Release 5.x (continued)

Send document comments to [email protected].

Send document comments to [email protected].

Send document comments to [email protected].

Screen examples use these conventions:

This document uses the following conventions:

Cisco Nexus 7000 Series NX-OS Release Notes, Release 5.x

Send document comments to [email protected].

Cisco NX-OS Configuration Guides

Configuring the Cisco Nexus 2000 Series Fabric Extender

Cisco NX-OS Command References

Cisco Nexus 7000 Series NX-OS Command Reference Master Index

Send document comments to [email protected].

Cisco Nexus 7000 Series NX-OS System Management Command Reference

Other Software Document

Cisco NX-OS Licensing Guide

Obtaining Documentation and Submitting a Service Request

Send document comments to [email protected].

Send document comments to [email protected].

Cisco NX-OS Device Configuration Methods

Figure 3-1 Cisco NX-OS Device Configuration Methods

User configuration path

Table 3-1 Configuration Methods Book Links

Configuration Method Document