Professional Documents
Culture Documents
Nexus Network Management Best Practices: Advanced Services
Nexus Network Management Best Practices: Advanced Services
Advanced Services
Corporate Headquarters
Cisco
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Contents .................................................................................................................................................................... 2
Tables......................................................................................................................................................................... 4
About This Document .......................................................................................................................................... 5
1. Introduction ................................................................................................................................................... 6
1.1 Document Purpose .................................................................................................................................. 6
1.2 Intended Audience .................................................................................................................................. 6
1.3 Scope ............................................................................................................................................................. 6
2. Executive Summary ..................................................................................................................................... 7
2.1 Network Management............................................................................................................................ 7
2.2 Detecting required Actions .................................................................................................................. 7
3. Network Monitoring ................................................................................................................................... 9
3.1 Overview ..................................................................................................................................................... 9
3.2 System Resource Monitoring .............................................................................................................. 9
3.2.1 CPU ............................................................................................................................................................ 9
3.2.2 Memory ................................................................................................................................................... 9
3.2.3 Network Interfaces .......................................................................................................................... 10
3.2.4 Statistics and Connections details .............................................................................................. 10
4. Nexus 7000 .................................................................................................................................................. 11
4.1 Target Equipment ................................................................................................................................. 11
4.2 CPU Utilization ....................................................................................................................................... 11
4.3 Memory Availability............................................................................................................................. 13
4.3.1 Line card memory monitoring .................................................................................................... 16
4.4 Network Interfaces............................................................................................................................... 16
4.4.1 vPC and Peer link .............................................................................................................................. 18
4.5 Environmental Parameters ............................................................................................................... 19
4.6 Module Status ......................................................................................................................................... 23
4.7 HSRP........................................................................................................................................................... 25
4.8 COPP ........................................................................................................................................................... 26
4.9 Hardware rate-limiters....................................................................................................................... 27
4.10 Summary .................................................................................................................................................. 28
4.11 Other useful CLI commands .............................................................................................................. 38
History
Revision History
Review
Revision Review
The objective of this document is to provide a detailed view of the metrics that should
be monitored on Cisco Nexus 7000, Nexus 5000 and Nexus 2000 series switches for
network performance, capacity planning and fault management.
The intended audience for the document is the Advanced Services Data Center
Networking Team. This document is intended for use by network engineers who are
responsible in providing Network Monitoring/Management and Capacity planning
services in an enterprise.
1.3 Scope
The scope of this document will focus on the key management features that should be
tracked / monitored for network performance, capacity planning and fault
management. This document is to provide the recommended information on SNMP
(preferred) or CLI command for better network management. The idea is that the
customer can build monitoring tools based on the information provided in this
document.
The following platforms with the NX-OS code running are targeted in this document:
The methodology should however be applicable and reusable for validation against
future software releases.
Fault Management
The goal of Fault Management is to detect, log, notify users of, and (to the extent
possible) automatically fix network problems to keep the network running effectively.
Because faults can cause downtime or unacceptable network degradation, fault
management is perhaps the most widely implemented of the ISO network
management elements.
Performance Management
While SNMP is primarily used to gather the data required, Syslog messages and CLI
commands also offer a wealth of information for Fault and Performance management.
The purpose of monitoring can be seen around two main objectives characterized by
their short- or long-term focus.
On long-term, the goal is to gather data that will help in the planning of network
upgrades, for example to achieve expected performance levels and preserve security
margins.
The goal of this document is to identify the key metrics that should be considered for
evaluating the Network performance. The data collected can then be used to establish
baseline values and threshold for the Network parameters.
3.1 Overview
In this section, we will describe the various aspects to be considered when talking about
monitoring. Monitoring can be requested for several reasons, which are typically
independent and provide best results when implemented using a global approach as the
tools and methods are similar.
Performance / capacity management and fault detection are applicable to all network
devices. Further down in the document, we will develop technical details and
procedures to evaluate the Network performance/planning.
The CPU utilization should be periodically monitored in order to both detect unusual
behavior as well as control long term resource management (track evolution over a long
period of time). Several metrics are available, each one being an average over a given
time period.
Although spikes will occur during normal operations, we recommend setting the
warning threshold around 80% on average to guarantee a correct mode of operation.
3.2.2 Memory
First, any Cisco device has a total and finite amount of memory that can be used by the
various processes. It is mostly important to monitor the amount of available (free)
memory. Although it is difficult to define a threshold value as it would depend on many
factors, it is recommended to monitor the evolution of the available memory pool. A
continuous decrease of available memory could be the symptom of:
On the Nexus 7000/5000 switches, statistics can be retrieved directly by a user issuing
show commands at the command line interface (CLI). Most of the statistics can also be
retrieved from a remote station through an SNMP request, the relevant MIBs and OIDs
are provided later in this document.
MIB: CISCOPROCESSMIB
Object: cpmCPUTotalEntry
OID: 1.3.6.1.4.1.9.9.109.1.1.1.1
Descriptions:
‘cpmCPUTotal5sec’: Average CPU utilization over the last 5 seconds
‘cpmCPUTotal1min’: Average CPU utilization over the last 60 seconds.
‘cpmCPUTotal5min’: Average CPU utilization over the last 5 minutes
The Nexus 7000 switch running 5.x does not currently support CPU-related traps defined
in the CISCO-PROCESS-MIB: cpmCPURisingThreshold and cpmCPUFallingThreshold.
Therefore, asynchronous notifications of violations of user-defined thresholds are not
possible.
There is no Syslog event message defined for chassis-level CPU monitoring on the Nexus
7000 switch.
CLI Command
The show system resources command displays the high level CPU utilization for the
supervisor module. The show process cpu command with the sort option lists all of the
processes sorted by the highest CPU utilization per process. The show process cpu
history command displays the CPU history in three increments: 60 seconds, 60 minutes,
72 hours. Viewing the CPU history is valuable when correlating a network event with the
past CPU utilization.
It should be noted that Cisco NX-OS takes advantage of preemptive CPU multitasking, so
processes can take advantage of an Idle CPU to complete tasks faster. Therefore, the
history option may report CPU spikes that do not necessarily mean there is an issue.
Additional investigation should take place if the average CPU remains close to 100%.
The state of the memory status can be monitored with the following MIB.
MIB : CISCOSYSTEMEXTMIB
Object: ciscoSysInfoGroup
OID : 1.3.6.1.4.1.9.9.305.1.1
Description:
‘cseSysCPUUtilization’: The average utilization of CPU on the active supervisor.
Thresholds for RMON probes should be set based on baselining the CPU
utilization within a production environment
MIB : CISCOENTITYEXTMIB
Object: ceExtPhysicalProcessorEntry
OID : 1.3.6.1.4.1.9.9.195.1.1.1
Description:
‘ceExtNVRAMSize’: Total number of bytes of NVRAM in the entity. A value of 0
for this object means the entity does not support NVRAM or NVRAM information
is not available.
Nexus 7000 does not support the notifications defined in the CISCO-ENHANCED-
MEMPOOL-MIB or CISCO-MEMORY-POOL-MIB. Thus, asynchronous alerts of system- or
customer-defined threshold violations are not possible. Use EEM scripts to create these
notifications if desired.
If a memory threshold has been passed (OK -> MINOR, MINOR -> SEVERE, SEVERE ->
CRITICAL), the Cisco NX-OS platform manager will capture a snapshot of memory
utilization and log an alert to SYSLOG. This snapshot is useful in determining why
memory utilization is high. The log is generated and this log is very useful for
determining if memory utilization is high due to the memory that was consumed by the
page cache, kernel, or Cisco NX-OS user processes.
The show system internal memory-alerts-log command displays the memory alerts log.
CLI Command
To assess the overall level of memory utilization, use the basic CLI commands
show system resources and show processes memory.
The show process memory command displays the memory allocation per process for
the current VDC. While this output is more detailed, it is only useful for verifying
process-level memory allocation within a specific VDC.
The show system internal kernel command or the show system internal memory-
alerts-log command for a more detailed representation of memory utilization in Cisco
NX-OS.
MemTotal (kB)- Total amount of memory in the system (4 GB in the Cisco Nexus
7000 Series Sup1)
Cached (kB) - Amount of memory used by the page cache (includes files in tmpfs
mounts and data cached from persistent storage /bootflash)
RamCached (kB) - Amount of memory used by the page cache that cannot be
released (data not backed by persistent storage)
Available (Pages) - Amount of free memory in pages (includes the space that
could be made available in the page cache and free lists)
Mapped (Pages) - Memory mapped into page tables (data being used by
nonkernel processes)
Slab (Pages) - Rough indication of kernel memory consumption
Memory Thresholds
Prior to Release 4.2(4), the default memory alert thresholds were as follows:
70% MINOR
80% SEVERE
90% CRITICAL
From Release 4.2(4) and later releases, the memory alert thresholds were changed to
the following:
85% MINOR
90% SEVERE
95% CRITICAL
This change was introduced in part due to baseline memory requirements when many
features/VDCs are deployed.
In NX-OS supports the MIB CISCO-MEMORY-POOL-MIB and two memory counters are
implemented in this MIB for each module present in the switch:
An example of line card Memory polling in Nexus 7000 with release 5.0(2) is provided
below:
MIB : IFMIB
Object: ifEntry
OID : 1.3.6.1.2.1.2.2.1
Descriptions:
‘ifOperStatus’: Returns the operational status of the interfaces.
‘ifInDiscards‘: Indicates ingress packets that have been discarded on interfaces
due to no buffer availability. Typically indicates that the device is overloaded.
‘ifInErrors’: Indicates input errors on interfaces.
‘ifOutDiscards’: Indicates egress packets that have been discarded on interfaces
due to no buffer availability. Possible cause is low memory.
‘ifOutErrors’: Indicates output error on interfaces.
MIB: IFMIB
Object: ifXEntry
OID: 1.3.6.1.2.1.31.1.1.1
Description:
Each possible return value is used to monitor the ingress/egress unicast/
multicast/ broadcast packets
Traps can be generated for the status of the interfaces using the IF-MIB. The linkup and
linkdown is used if the operational status of the interfaces changes.
Syslog messages are generated for many scenarios impacting the interface operational
status. An example for a Syslog message is as below
CLI Command
Use the below commands to verify information for any given interface
show interface brief displays the interface configuration information, including the
mode.
show interface capabilities displays information on the capabilities of the interfaces.
show interface counters [module module] displays input and output octets unicast
packets, multicast packets, and broadcast packets
show interface counters errors [module module] Displays information on the number
of error packets..
The vPC link and the peer-links are critical to maintaining the vPC infrastructure
deployed. Any change on these two links must be acted upon immediately.
The following “facility” strings can identify events related to the vPC and peer-link:
VPC
ETH_PORT_CHANNEL
ETHPORT
ETH_PM
The below CLI commands can also be used to verify any issues with vPC.
The Nexus 7000 switch implements the standard ENTITY-MIB, the CISCO-ENTITY-
SENSOR-MIB, the CISCO-ENTITY-EXT-MIB, and the CISCO-ENTITY-FRU-CONTROL-MIB.
These MIBs contain information about environmental status in the switch, such as
temperature sensors, fan tray status, power supply status, etc
The physical index for the Fan modules can be determined from the ENTITY-MIB
description or name
The Fan module status can then be obtained from the CISCO-ENTITY-FRU-CONTROL-
MIB, and the LED color status from the CISCO-ENTITY-EXT-MIB:
The physical index for the Power Supply modules can be determined from the ENTITY-
MIB description or name:
The Power Supply status can then be obtained from the CISCO-ENTITY-FRU-CONTROL-
MIB, and the LED color status from the CISCO-ENTITY-EXT-MIB:
Temperature
The Nexus 7000 switch supports the environmental SNMP trap notifications listed in the
table below.
Syslog messages are generated for various Environmental conditions. An example for a
Syslog message is as below
CLI Command
The Nexus 7000 switch implements the standard ENTITY-MIB and the CISCO-ENTITY-
FRU-CONTROL-MIB. These MIBs contain information about field replaceable units (FRU)
in the switch, such as supervisor cards, linecards, fans, power supplies, etc.
The module-related MIB objects that should be monitored are listed in the table below
The Nexus 7000 switch supports the module-related SNMP trap notifications listed
Syslog event messages can be generated for various events related to modules in the
Nexus 7000 switch.
PLATFORM
BOOTUP_TEST
BOOTVAR
CMPPROXY
DIAGMGR
MODULE
CLI Command
Use the show module command to determine the status of each module
Use the show module xbar command to determine the status of each fabric module
Use the “show environment fan ” command to verify temperature threshold’s per
module. Sylogs and Traps are generated if a threshold is met.
4.7 HSRP
For HSRP we want to monitor SNMP Traps and syslog event messages, and do SNMP
polling for Neighbor Status and number of neighbors.
The primary MIB for HSRP management is the CISCO-HSRP-MIB.For Nexus 7010 running
NX-OS the following MIB objects are supported and recommended
The string HSRP_ENGINE can be used to identify any events related to system generated
HSRP messages.
CLI Commands
Use the show standby command to verify the HSRP status on the switches.
4.8 COPP
The MIB OID for CoPP information will be enabled, in the future release of NX-OS
software.
Use the CLI command show policy-map interface control-plane to display the control
plane statistics.
Hardware Rate Limits can be optionally monitored in addition to CoPP statistics, in order
to have further insight on the type of packets that are reaching the Supervisor. For
instance, dropped counters in hardware rate limiters can provide explanations for
issues.
Hardware Rate Limiters can complement CoPP functionality, and the corresponding
counters may be added to the monitoring of the full CoPP policies.
However, monitoring of Hardware Rate Limiters is only possible via CLI currently.
The MIB OID for Hardware Rate Limiters information will be enabled in a future release
of NX-OS software.
Use the CLI command show hardware rate-limit to display the rate limit statistics.
4.10 Summary
The Summary of the recommended SNMP OIDs for Nexus 7000 has been listed in the
below table.
CISCO- cseSysMemo 1.3.6.1.4.1.9.9.3 0..100 The average once every 5-15 minutes
SYSTEM- ryUtilization 05.1.1.2 utilization of
EXT-MIB memory on the
active
supervisor.
Thresholds for
RMON should
probes should
be set based on
baselining the
memory
utilization
within a
production
environment
CISCO- callHomeAle 1.3.6.1.4.1.9.9.3 The number once every hour
CALLHOME- rts 00.1.2.2 of Call Home
MIB alerts sent.
If this has
incremented
then investigate
the root cause
of what caused
the increment.
CISCO- ceExtSysBoo 1.3.6.1.4.1.9.9.1 These provide a once per day
ENTITY-EXT- tImageList 95.3.2.5 record of the
MIB kickstart/syste
ceExtKicksta 1.3.6.1.4.1.9.9.1 m image that
rtImageList 95.1.2.1.4 the system is
running.
CISCO- cefcPowerRe 1.3.6.1.4.1.9.9.1 Should be in at least once every hour
ENTITY- dundancyMo 17.1.1.1.1.1 redundant(2)
FRU- de
CONTROL-
MIB
CISCO- cefcTotalAva 1.3.6.1.4.1.9.9.1 cefcTotalDrawn at least once every hour
ENTITY- ilableCurrent 17.1.1.1.1.3 Current should
FRU- remain within
CONTROL- cefcTotalDra 1.3.6.1.4.1.9.9.1 cefcTotalAvaila
MIB wnCurrent 17.1.1.1.1.4 bleCurrent
Best practice
would be to
gather trend
data here to
ensure that
facilities/coolin
g/power are
being
maintained.
CISCO- ciscoFlashPa 1.3.6.1.4.1.9.9.1 Provides at least once every hour
FLASH-MIB rtitionSize 0.1.1.4.1.1.13 information on
flash
ciscoFlashPa 1.3.6.1.4.1.9.9.1 filesystems
rtitionFreeSp 0.1.1.4.1.1.14 within the
ace system.
Best practice is
to ensure
ciscoFlashPartit
ionFreeSpace
does not drop
below 10% of
ciscoFlashPartit
ionSize
testing(3
)
unknow
n(4)
dormant
(5)
notPrese
nt(6)
lowerLay
erDown(
7)
IF-MIB ifLastChange 1.3.6.1.2.1.2.2.1. The value of
9 sysUpTime at
the time the
interface
entered its
current
operational
state
IF-MIB ifHCInOctets 1.3.6.1.2.1.31.1. The total
1.1.6 number of
octets received
on the interface,
including
framing
characters.
IF-MIB ifHCOutOctet 1.3.6.1.2.1.31.1. The total
s 1.1.10 number of
octets
transmitted out
of the interface,
including
framing
characters
IF-MIB ifHCInUcastP 1.3.6.1.2.1.31.1. The number of
kts 1.1.7 packets,
delivered by
this sub-layer to
a higher (sub-
)layer, which
were not
addressed to a
multicast or
broadcast
address at this
sub-layer.
IF-MIB ifHCOutUcast 1.3.6.1.2.1.31.1. The total
Pkts 1.1.11 number of
packets that
higher-level
protocols
requested be
transmitted,
and which were
not addressed
to a multicast or
broadcast
address at this
sub-layer,
including those
that were
discarded or not
sent.
were chosen to
be discarded
even though no
errors had been
detected to
prevent their
being
deliverable to a
higher-layer
protocol. One
possible reason
for discarding
such a packet
could be to free
up buffer space
IF-MIB ifInErrors 1.3.6.1.2.1.2.2.1. The number of
14 inbound
packets that
contained
errors
preventing
them from
being
deliverable to a
higher-layer
protocol..
IF-MIB ifInUnknown 1.3.6.1.2.1.2.2.1. The number of
Protos 15 packets
received via the
interfaces
which were
discarded
because of an
unknown or
unsupported
protocol.
IF-MIB ifOutDiscard 1.3.6.1.2.1.2.2.1. The number of
s 19 outbound
packets which
were chosen to
be discarded
even though no
errors had been
detected to
prevent their
being
transmitted. On
e possible
reason for
discarding such
a packet could
be to free up
buffer space.
The Summary of the recommended SNMP Traps for Nexus 7000 has been listed in
the below table.
The following CLI commands do not have any SNMP OIDs to monitor and these
commands will be useful to monitor the network performance and the future growth.
The Cisco Nexus 7000 Series uses a distributed forwarding architecture in which each
module has a forwarding engine responsible for forwarding packets. A forwarding
engine on an M series module is capable of storing 128,000 MAC Address entries. MAC
address tables are synchronized between Ethernet M series modules that have ports
configured in the same Virtual Device Context (VDC). The following command is useful
for verifying the MAC address table capacity for all modules in a chassis .
The Cisco Nexus 7000 Series uses a distributed forwarding architecture in which each
Ethernet M series module has a forwarding engine responsible for forwarding packets. A
forwarding engine on an M series module is capable of storing 128,000 IPv4/IPv6
routing entries or 1,000,000 entries if it is an XL module with a Scalable-Feature license
installed. IPv4/IPv6 unicast/multicast tables are synchronized between Ethernet M
series modules that have ports configured in the same Virtual Device Context (VDC). The
following example displays the default TCAM allocation for a non-XL module. Cisco NX-
OS supports dynamic TCAM allocation. This allows for better resource utilization in the
event and address family (i.e. IPv6 unicast) requires additional entries.
The Cisco Nexus 7000 Series uses a distributed forwarding architecture in which each
module has a forwarding engine responsible for forwarding packets. A forwarding
engine on an M series module is capable of storing 64,000 (non-XL) or 128,000 ACL QoS
entries if it is an XL module with the Scalable Feature license installed .
Fabric Utilization
The fabric utilization can be monitored to verify the ingress and egress bandwidth
utilization. The show hardware fabric-utilization commands are useful for verifying the
high-level and detailed utilization. The show hardware capacity fabric-utilization is
useful for verifying the peak utilization history.
1 1 1 B 0% 11-01@23:09:42 0% 11-
01@23:09:42
1 2 1 A 0% 11-01@23:09:42 0% 11-
01@23:09:42
1 2 1 B 0% 11-01@23:09:42 0% 11-
01@23:09:42
1 2 1 A 0% 11-01@23:09:42 0% 11-
01@23:09:42
1 2 1 B 0% 11-01@23:09:42 0% 11-
01@23:09:42
1 3 1 A 0% 11-01@23:09:42 0% 11-
01@23:09:42
Global VDC resources can be verified with the show vdc resource command. This is
useful to know, since VDCs can contend for common resources such as memory, SPAN
sessions, etc.).
4.12 References
The following MIBs used to monitor the Overall information about the CPU load.
MIB : CISCOPROCESSMIB
Object: cpmCPUTotalEntry
OID : 1.3.6.1.4.1.9.9.109.1.1.1.1
Description:
‘cpmCPUTotal5sec’: Average CPU utilization over the last 5 seconds
‘cpmCPUTotal1min’: Average CPU utilization over the last 60 seconds.
‘cpmCPUTotal5min’: Average CPU utilization over the last 5 minutes
CLI Command
The show system resources command displays the high level CPU utilization for the
supervisor module. The show process cpu command with the sort option lists all of the
processes sorted by the highest CPU utilization per process. The show process cpu
history command displays the CPU history in three increments: 60 seconds, 60 minutes,
72 hours. Viewing the CPU history is valuable when correlating a network event with the
past CPU utilization.
MIB: CISCOSYSTEMEXTMIB
Object: ciscoSysInfoGroup
OID: 1.3.6.1.4.1.9.9.305.1.1
Description:
‘cseSysCPUUtilization’: The average utilization of CPU on the active
supervisor. Thresholds for RMON should probes should be set based on
baselining the CPU utilization within a production environment.
MIB: CISCOENTITYEXTMIB
Object: ceExtPhysicalProcessorEntry
OID: 1.3.6.1.4.1.9.9.195.1.1.1
Description:
‘ceExtNVRAMSize’: Total number of bytes of NVRAM in the entity.A value of 0
for this object means the entity does not support NVRAM or NVRAM
information is not available.
CLI Command
To assess the overall level of memory utilization, use the basic CLI commands
show system resources and show processes memory.
The show process memory command displays the memory allocation per process and it
is only useful for verifying process-level memory allocation.
MIB : IFMIB
Object: ifEntry
OID : 1.3.6.1.2.1.2.2.1
Descriptions:
‘ifOperStatus’: Returns the operational status of the interfaces.
‘ifInDiscards‘: Indicates ingress packets that have been discarded on interfaces
due to no buffer availability. Typically indicates that the device is overloaded.
‘ifInErrors’: Indicates input errors on interfaces.
‘ifOutDiscards’: Indicates egress packets that have been discarded on interfaces
due to no buffer availability. Possible cause is low memory.
‘ifOutErrors’: Indicates output error on interfaces.
MIB: IFMIB
Object: ifXEntry
OID: 1.3.6.1.2.1.31.1.1.1
Description:
Each possible return value is used to monitor the ingress/egress unicast/
multicast/ broadcast packets
Traps can be generated for the status of the Interfaces using the IF-MIB. The linkup and
linkdown is used if the operational status of the Interfaces changes.
CLI Command
Use the below commands to verify information for any given interface
show interface brief displays the interface configuration information, including the
mode.
show interface capabilities displays information on the capabilities of the interfaces.
show interface counters [module module] displays input and output octets unicast
packets, multicast packets, and broadcast packets
show interface counters errors [module module] Displays information on the number
of error packets.
The following “facility” strings can identify events related to the vPC and peer-link:
VPC
ETH_PORT_CHANNEL
ETHPORT
ETH_PM
The below CLI commands can also be used to verify any issues with vPC.
MIB: CISCOENTITYFRUCONTROLMIB
Object: cefcMIBObjects
OID: 1.3.6.1.4.1.9.9.117.1
Description:
‘cefcFRUPower’: will have possible return value ‘cefcPowerRedundancyMode’,
‘cefcTotalAvailableCurrent’ & ‘cefcTotalDrawnCurrent’ for power related
information.
CLI Command
Use the Show environment command to display the environment statistics. An example
of displaying the details of Power usage is shown below
Power Supply:
Voltage: 12 Volts
-----------------------------------------------------------
PS Model Input Power Power Status
Type (Watts) (Amp)
-----------------------------------------------------------
1 N55-PAC-750W-B AC 744.00 62.00 ok
2 -- -- -- --
fail/shutdown
-------------
Total Power Available 108.00 W
The Nexus 7000 switch implements the standard ENTITY-MIB and the CISCO-ENTITY-
FRU-CONTROL-MIB. These MIBs contain information about field replaceable units (FRU)
in the switch, such as supervisor cards, linecards, fans, power supplies, etc.
The module-related MIB objects that should be monitored are listed in the table below
The Nexus 5000 switch supports the module-related SNMP trap notifications listed
Syslog event messages can be generated for various events related to modules in the
Nexus 5000 switch.
The following “facility” strings can identify module-related events:
PLATFORM
BOOTUP_TEST
BOOTVAR
CMPPROXY
DIAGMGR
MODULE
CLI Command
Use the show module command to determine the status of each module
SJMGMTSW01# sh module
Mod Ports Module-Type Model
Status
--- ----- -------------------------------- ---------------------- -
-----------
1 32 O2 32X10GE/Modular Universal Pla N5K-C5548UP-SUP
active *
3 0 O2 Daughter Card with L3 ASIC N55-D160L3
ok
5.7 Summary
The Summary of the recommended SNMP OIDs for Nexus 5000 has been listed in the
below table.
Best practice
would be to
gather trend data
here to ensure
that
facilities/cooling/
power are being
maintained.
Best practice is to
ensure
ciscoFlashPartitio
nFreeSpace does
not drop below
10% of
ciscoFlashPartitio
nSize
IF-MIB ifDescr 1.3.6.1.2.1.2.2.1.2 A textual string Poll IF-MIB values every 5
containing the minutes for historical data.
interface
IF-MIB ifAlias 1.3.6.1.2.1.31.1.1. This object is an
1.18 'alias' name for Suggest making use of RMON
the interface as probes for specific
specified by a interfaces/counters to trigger
network alerts based on error
manager, and counters incrementing
provides a non- beyond a certain threshold
volatile 'handle' (determine via baseline), as
for the interface. well as interfaces with
IF-MIB ifSpeed 1.3.6.1.2.1.2.2.1.5 sustained performance
IF-MIB ifAdminStatus 1.3.6.1.2.1.2.2.1.7 up(1) The desired state above a high water mark.
of the interface.
down(2)
testing(3)
testing(3)
unknown(
4)
dormant(
5)
notPresen
t(6)
lowerLaye
rDown(7)
IF-MIB ifLastChange 1.3.6.1.2.1.2.2.1.9 The value of
sysUpTime at the
ifOperStatus
The Cisco Nexus 2000 Series uses the Cisco Fabric Extender architecture to provide a
highly scalable unified server-access platform across a range of 100 Megabit Ethernet,
Gigabit Ethernet, 10 Gigabit Ethernet, unified fabric, copper and fiber connectivity, rack,
and blade server environments.
The Cisco Nexus 2000 Series Fabric Extenders behave as remote line cards for a parent
Cisco Nexus switch. The fabric extenders are essentially extensions of the parent Cisco
Nexus switch fabric, with the fabric extenders and the parent Cisco Nexus switch
together forming a distributed modular system.
The Cisco Nexus 2000 Series is managed through the parent Cisco Nexus Series Switch
using standard SNMP, XML interfaces, and command-line interface (CLI).
• ENTITY-MIB
• IF-MIB
• FABRIC-EXTENDER MIB
• CISCO-ENTITY-EXT-MIB
• CISCO-ENTITY-FRU-CONTROL-MIB
• CISCO-ENTITY-SENSOR-MIB
• CISCO-ETHERNET-FABRIC-EXTENDER-MIB
To display a detailed status of the Fabric extender use the show fex detail command
To view the module information about all connected Fabric extender units use the show
module fex command
switch# show module fex
FEX Mod Ports Card
Type Model Status.
--- --- ----- ---------------------------------- ------------------ -
----------
100 1 48 Fabric Extender 48x1GE Module N2K-C2148T-
1GE ok
To view the environment status for a specific Fabric Extender unit use the show
environment fex command
switch# show environment fex 100
PS-2 N5K-PAC-200W -- ok
Mod
Model Power Power Power Power Stat
us
Requested Requested Allocated Allocated
(Watts) (Amp) (Watts) (Amp)
--- ------------------- ------- ---------- --------- ----------
----------
1 N5K-C5110T-BF-
1GE 96.00 8.00 96.00 8.00 powered-up
-------------
Total Power Available 104.04 W
-------------
To view diagnostic test results for a specific Fabric Extender unit use the show
diagnostic result fex command
TestForwardingPorts:
Eth 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
22 23 24
Port ----------------------------------------------------------------
--------
. . . . . . . . . . . . . . . . . . . . .
. . .
Eth 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
46 47 48
Port ----------------------------------------------------------------
--------
. . . . . . . . . . . . . . . . . . . . .
. . .
TestFabricPorts:
Fabric 1 2 3 4
Port ------------
. . . .
In the previous sections, we have identified the critical parameters that should be
monitored and managed for ensuring optimal Network performance.
The next steps must be to integrate these in the overall monitoring processes and
define thresholds for alerts or actions.The recommended plan is to
If the alert is the result of a normal long-term evolution, the alert level
must probably be revisited, along with an evaluation of the long-term
performance of the overall equipment.
Consider CPU utilization, a possible short-term alert level at 80% would indicate
heavy activity on the device. However for long-term planning, you could also
consider that a device performing always at 60-80% CPU utilization would deserve
attention so that it is replaced on time (i.e. before operations are impacted) by a
more powerful one. There will be new SNMP MIBs introduced for future NX-OS
releases. The link below will provide the details for respective MIB’s. Please refer
this to see what new MIB’s have been added and can be used for future NX-OS
releases.
Details for a specific OID or object can be found using the SNMP Object Navigator
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en
If you have any questions or comments regarding this report, please contact your
Cisco Advanced Services Network Consulting Engineer.
Document Acceptance
Name Name
Title Title
Company Company
Signature Signature
Date Date
Name Name
Title Title
Company Company
Signature Signature
Date Date
Name Name
Title Title
Company Company
Signature Signature
Date Date