Cisco UCS Manager System Monitoring Guide Using the CLI, Release 3.1

Transcription

1 Cisco UCS Manager System Monitoring Guide Using the CLI, Release 3.1 First Published: Last Modified: Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA Tel: NETS (6387) Fax:

2 THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R) Cisco Systems, Inc. All rights reserved.

3 CONTENTS Preface Preface xi Audience xi Conventions xi Related Cisco UCS Documentation xiii Documentation Feedback xiii CHAPTER 1 New and Changed Information for This Release 1 New and Changed Information for This Release 1 CHAPTER 2 System Monitoring Overview 3 System Monitoring Overview 3 The Cisco UCS Manager Core and Fault Generation 4 Cisco UCS Manager User CLI Documentation 6 CHAPTER 3 Syslog 9 Enabling Syslog Messages to Store In a Local File 9 CHAPTER 4 System Event Log 13 System Event Log 13 Viewing the System Event Log for a Server 14 Viewing the System Event Log for an Individual Server 14 Viewing the System Event Log for All of the Servers in a Chassis 14 Configuring the SEL Policy 15 Backing Up the System Event Log for a Server 17 Backing Up the System Event Log for an Individual Server 17 Backing Up the System Event Log for All of the Servers in a Chassis 17 Clearing the System Event Log for a Server 18 iii

4 Contents Clearing the System Event Log for an Individual Server 18 Clearing the System Event Log for All of the Servers in a Chassis 18 CHAPTER 5 Audit Logs 21 Audit Logs 21 Viewing Audit Logs 21 CHAPTER 6 Log File Exporter 23 Log File Exporter 23 Exporting Log Files to a Remote Server 24 CHAPTER 7 Core File Exporter 27 Core File Exporter 27 Configuring the Core File Exporter 27 Disabling the Core File Exporter 28 CHAPTER 8 Fault Collection and Suppression 31 Global Fault Policy 31 Configuring the Fault Collection Policy 32 Fault Suppression 32 Configuring Fault Suppression for a Chassis 34 Configuring Fault Suppression Tasks for a Chassis Using a Fixed Time Interval 34 Configuring Fault Suppression Tasks for a Chassis Using a Schedule 35 Modifying Fault Suppression Tasks for a Chassis 36 Viewing Suppressed Faults and Fault Suppression Tasks for a Chassis 38 Deleting Fault Suppression Tasks for a Chassis 39 Configuring Fault Suppression for an I/O Module 39 Configuring Fault Suppression Tasks for an IOM Using a Fixed Time Interval 39 Configuring Fault Suppression Tasks for an IOM Using a Schedule 40 Modifying Fault Suppression Tasks for an IOM 42 Viewing Suppressed Faults and Fault Suppression Tasks for an IOM 43 Deleting Fault Suppression Tasks for an IOM 45 Configuring Fault Suppression for a FEX 45 Configuring Fault Suppression Tasks for a FEX Using a Fixed Time Interval 45 Configuring Fault Suppression Tasks for a FEX Using a Schedule 47 iv

5 Contents Modifying Fault Suppression Tasks for a FEX 48 Viewing Suppressed Faults and Fault Suppression Tasks for a FEX 49 Deleting Fault Suppression Tasks for a FEX 50 Configuring Fault Suppression for a Server 50 Configuring Fault Suppression Tasks for a Server Using a Fixed Time Interval 50 Configuring Fault Suppression Tasks for a Server using a Schedule 51 Modifying Fault Suppression Tasks for a Server 52 Creating a Schedule 54 Viewing Suppressed Faults and Fault Suppression Tasks for a Server 54 Deleting Fault Suppression Tasks for a Server 55 Configuring Fault Suppression for a Service Profile 55 Configuring Fault Suppression Tasks for a Service Profile Using a Fixed Time Interval 55 Configuring Fault Suppression Tasks for a Service Profile Using a Schedule 57 Modifying Fault Suppression Tasks for a Service Profile 58 Viewing Suppressed Faults and Fault Suppression Tasks for a Service Profile 60 Deleting Fault Suppression Tasks for a Service Profile 61 Configuring Fault Suppression for an Organization 61 Configuring Fault Suppression Tasks for an Organization Using a Fixed Time Interval 61 Configuring Fault Suppression Tasks for an Organization Using a Schedule 62 Modifying Fault Suppression Tasks for an Organization 63 Viewing Suppressed Faults and Fault Suppression Tasks for an Organization 64 Deleting Fault Suppression Tasks for an Organization 65 CHAPTER 9 SNMP Configuration 67 SNMP Overview 67 SNMP Functional Overview 67 SNMP Notifications 68 SNMP Security Levels and Privileges 68 Supported Combinations of SNMP Security Models and Levels 69 SNMPv3 Security Features 70 SNMP Support 70 Configuring SNMP 71 Enabling SNMP and Configuring SNMP Properties 71 Creating an SNMP Trap 72 Deleting an SNMP Trap 73 v

6 Contents Creating an SNMPv3 User 73 Deleting an SNMPv3 User 74 CHAPTER 10 Statistics Collection Policy Configuration 77 Statistics Collection Policy 77 Configuring a Statistics Collection Policy 78 CHAPTER 11 Call Home and Smart Call Home Configuration 79 Call Home in UCS Overview 79 Call Home Considerations and Guidelines 81 Cisco UCS Faults and Call Home Severity Levels 82 Cisco Smart Call Home 83 Anonymous Reporting 85 Configuring Call Home 85 Enabling Call Home 87 Disabling Call Home 88 Configuring System Inventory Messages 88 Configuring System Inventory Messages 88 Sending a System Inventory Message 89 Configuring Call Home Profiles 90 Call Home Profiles 90 Call Home Alert Groups 90 Configuring a Call Home Profile 91 Deleting a Call Home Profile 92 Sending a Test Call Home Alert 93 Configuring Call Home Policies 94 Call Home Policies 94 Configuring a Call Home Policy 94 Disabling a Call Home Policy 95 Enabling a Call Home Policy 95 Deleting a Call Home Policy 96 Configuring Anonymous Reporting 97 Enabling Anonymous Reporting 97 Disabling Anonymous Reporting 97 Viewing Anonymous Reports 98 vi

7 Contents Configuring Smart Call Home 99 Configuring Smart Call Home 99 Configuring the Default Cisco TAC-1 Profile 101 Configuring a System Inventory Message for Smart Call Home 102 Registering Smart Call Home 103 CHAPTER 12 Database Health Monitoring 105 Cisco UCS Manager Database Health Monitoring 105 Changing Internal Backup Interval 105 Triggering Health Check 106 Changing Health Check Interval 106 CHAPTER 13 Hardware Monitoring 109 System Monitoring CLI Command Cheat Sheet 109 Managing the Chassis 111 Turning On the Locator LED for a Chassis 111 Turning Off the Locator LED for a Chassis 111 Managing Blade Servers 112 Turning On the Locator LED for a Blade Server 112 Turning Off the Locator LED for a Blade Server 112 Managing Rack-Mount servers 113 Turning On the Locator LED for a Rack-Mount Server 113 Turning Off the Locator LED for a Rack-Mount Server 113 Showing the Status for a Rack-Mount Server 114 Monitoring Fan Modules 114 Monitoring Management Interfaces 116 Management Interfaces Monitoring Policy 116 Configuring the Management Interfaces Monitoring Policy 117 Local Storage Monitoring 119 Support for Local Storage Monitoring 119 Prerequisites for Local Storage Monitoring 120 Legacy Disk Drive Monitoring 121 Turning On the Local Disk Locator LED 121 Turning Off the Local Disk Locator LED 122 Viewing the Local Disk Locator LED State 122 vii

8 Contents Flash Life Wear Level Monitoring 123 Viewing Flash Life Status 123 Viewing the Status of Local Storage Components 124 Viewing the Status of a Disk Drive 128 Viewing RAID Controller Operations 128 Viewing RAID Controller Stats 129 Monitoring RAID Battery Status 129 Graphics Card Monitoring 130 Graphics Card Server Support 130 Viewing Graphics Card Properties 131 Viewing Graphics Controller Properties 131 Managing Transportable Flash Module and Supercapacitor 132 TFM and Supercap Guidelines and Limitations 132 TPM Monitoring 133 Viewing TPM Properties 133 CHAPTER 14 Netflow Monitoring 135 NetFlow Monitoring 135 NetFlow Monitoring Limitations 136 Configuring a Flow Record Definition 137 Configuring an Exporter Profile 138 Configuring a Netflow Collector 139 Configuring a Flow Exporter 140 Configuring a Flow Monitor 140 Configuring a Flow Monitor Session 141 Configuring a NetFlow Cache Active and Inactive Timeout 142 Associating a Flow Monitor Session to a vnic 142 CHAPTER 15 Traffic Monitoring 145 Traffic Monitoring 145 Guidelines and Recommendations for Traffic Monitoring 147 Creating an Ethernet Traffic Monitoring Session 148 Creating a Fibre Channel Traffic Monitoring Session 149 Adding Traffic Sources to a Monitoring Session 150 Adding an Uplink Source Port to a Monitoring Session 150 viii

9 Contents Adding a vnic or vhba Source to a Monitoring Session 151 Adding a VLAN or VSAN Source to a Monitoring Session 153 Adding a Storage Port Source to a Monitoring Session 154 Activating a Traffic Monitoring Session 155 Deleting a Traffic Monitoring Session 156 SPAN Restrictions for the Cisco UCS Mini 156 ix

10 Contents x

11 Preface Audience, page xi Conventions, page xi Related Cisco UCS Documentation, page xiii Documentation Feedback, page xiii Audience This guide is intended primarily for data center administrators with responsibilities and expertise in one or more of the following: Server administration Storage administration Network administration Network security Conventions Text Type Indication GUI elements GUI elements such as tab titles, area names, and field labels appear in this font. Main titles such as window, dialog box, and wizard titles appear in this font. Document titles Document titles appear in this font. TUI elements In a Text-based User Interface, text the system displays appears in this font. System output Terminal sessions and information that the system displays appear in this font. xi

12 Conventions Preface Text Type CLI commands [ ] {x y z} [x y z] string < > [ ]!, # Indication CLI command keywords appear in this font. Variables in a CLI command appear in this font. Elements in square brackets are optional. Required alternative keywords are grouped in braces and separated by vertical bars. Optional alternative keywords are grouped in brackets and separated by vertical bars. A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks. 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. Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the document. Tip Means the following information will help you solve a problem. The tips information might not be troubleshooting or even an action, but could be useful information, similar to a Timesaver. Timesaver Means the described action saves time. You can save time by performing the action described in the paragraph. Caution Means reader be careful. In this situation, you might perform an action that could result in equipment damage or loss of data. xii

13 Preface Related Cisco UCS Documentation Warning IMPORTANT SAFETY INSTRUCTIONS This warning symbol means danger. You are in a situation that could cause bodily injury. Before you work on any equipment, be aware of the hazards involved with electrical circuitry and be familiar with standard practices for preventing accidents. Use the statement number provided at the end of each warning to locate its translation in the translated safety warnings that accompanied this device. SAVE THESE INSTRUCTIONS Related Cisco UCS Documentation Documentation Roadmaps For a complete list of all B-Series documentation, see the Cisco UCS B-Series Servers Documentation Roadmap available at the following URL: For a complete list of all C-Series documentation, see the Cisco UCS C-Series Servers Documentation Roadmap available at the following URL: For information on supported firmware versions and supported UCS Manager versions for the rack servers that are integrated with the UCS Manager for management, refer to Release Bundle Contents for Cisco UCS Software. Other Documentation Resources Follow Cisco UCS Docs on Twitter to receive document update notifications. Documentation Feedback To provide technical feedback on this document, or to report an error or omission, please send your comments to ucs-docfeedback@cisco.com. We appreciate your feedback. xiii

14 Documentation Feedback Preface xiv

15 CHAPTER 1 New and Changed Information for This Release New and Changed Information for This Release, page 1 New and Changed Information for This Release The following table provides an overview of the significant changes to this guide for this current release. The table does not provide an exhaustive list of all changes made to this guide or of all new features in this release. Table 1: New Features and Changed Behavior in Cisco UCS Manager, Release 3.1(3) Feature Description Where Documented Database Health Monitoring Cisco UCS Manager provides proactive Cisco UCS Manager Database health check and recovery mechanisms Health Monitoring, on page to improve the integrity of the Cisco 105 UCS Manager database. 1

16 New and Changed Information for This Release New and Changed Information for This Release 2

17 CHAPTER 2 System Monitoring Overview System Monitoring Overview, page 3 The Cisco UCS Manager Core and Fault Generation, page 4 Cisco UCS Manager User CLI Documentation, page 6 System Monitoring Overview This guide describes how to configure and use system monitoring to manage a Cisco UCS Manager environment. Cisco UCS Manager can detect system faults: critical, major, minor, and warnings. We recommend that: You monitor all faults of either critical or major severity status, as immediate action is not required for minor faults and warnings. You monitor faults that are not of type Finite State Machine (FSM), as FSM faults will transition over time and resolve. This guide covers the following information: System Log System logs including faults, failures, and alarm thresholds (Syslog) The three types of Syslogs: Fault, Event, and Audit logs The Global Fault Policy and settings that control Syslogs System Event Log System hardware events for servers and chassis components and their internal components (System Event Log [SEL] logs) The SEL policy that controls SEL logs Simple Network Management Protocol 3

18 The Cisco UCS Manager Core and Fault Generation System Monitoring Overview SNMP for monitoring devices from a central network management station and the host and user settings Fault suppression policies for SNMP traps, Call Home notifications, and specific devices Core File Exporter and logs, such as Syslog, Audit Log, and the System Event Log Statistics Collection and Threshold Policies for adapters, chassis, host, ports, and servers Call Home and Smart Call Home Cisco embedded device support Hardware monitoring using the Cisco UCS Manager user interface Traffic Monitoring sessions for analysis by a network analyzer Cisco Netflow Monitor for IP network traffic accounting, usage-based network billing, network planning, security, Denial of Service monitoring capabilities, and network monitoring The Cisco UCS Manager Core and Fault Generation The Cisco UCS Manager core is made up of three elements, which are the Data Management Engine, Application Gateway, and user accessible northbound interface. The northbound interface comprises of SNMP, Syslog, XML API, and UCSM CLI. You can monitor the Cisco UCS Manager servers through XML API, SNMP, and Syslog. Both SNMP and Syslog are interfaces used only used for monitoring as they are read-only, so no configuration changes are 4

19 System Monitoring Overview The Cisco UCS Manager Core and Fault Generation allowed from these interfaces. Alternatively, the XML API is a monitoring interface that is read-write, which allows you to monitor Cisco UCS Manager, and change the configuration if needed. Figure 1: Cisco UCS Manager Core and Monitoring Interfaces Data Management Engine (DME) The DME is the center of the Cisco UCS Manager system, which maintains: The Cisco UCS XML database which houses the inventory database of all physical elements (blade and rack mount servers, chassis, modules, and fabric interconnects). The logical configuration data for profiles, policies, pools, vnic, and vhba templates. The various networking-related configuration details like VLANs, VSANs, port channels, network uplinks, and server downlinks. The DME monitors: The current health and state of all components of all physical and logical elements in a Cisco UCS domain. The transition information of all Finite State Machine (FSM) tasks occurring. 5

20 Cisco UCS Manager User CLI Documentation System Monitoring Overview Only the current information of inventory, health, and configuration data of the managed endpoints are stored in the Cisco UCS XML database resulting in near real time. By default the DME does not store a historical log of faults that have occurred on a Cisco UCS domain. As fault conditions are raised on the endpoints, the DME creates faults in the Cisco UCS XML database. As those faults are mitigated, the DME clears and removes the faults from the Cisco UCS XML database. Application Gateway (AG) Application Gateways are software agents that communicate directly with the endpoints to relay the health and state of the endpoints to the DME. AG-managed endpoints include servers, chassis, modules, fabric extenders, fabric interconnects, and NX-OS. The AGs actively monitor the server through the IPMI and SEL logs using the Cisco Integrated Management Controller (CIMC). They provide the DME with the health, state, configuration, and potential fault conditions of a device. The AGs manage configuration changes from the current state to the desired state during FSM transitions when changes are made to the Cisco UCS XML database. The module AG and chassis AG communicate with the Chassis Management Controller (CMC) to get information about the health, state, configuration, and fault conditions observed by the CMC. The fabric interconnect NX-OS AG communicates directly with NX-OS to get information about the health, state, configuration, statistics, and fault conditions observed by NX-OS on the fabric interconnects. All AGs provide the inventory details to the DME about the endpoints during the various discovery processes. The AGs perform the state changes necessary to configure an endpoint during FSM-triggered transitions, monitor the health and state of the endpoints, and notify the DME of any faults. Northbound Interfaces The northbound interfaces include SNMP, Syslog, CLI, and XML API. The XML API present in the Apache webserver layer sends login, logout, query, and configuration requests using HTTP or HTTPS. SNMP and Syslog are both consumers of data from the DME. SNMP informs and traps are translated directly from the fault information stored in the Cisco UCS XML database. SNMP GET requests are sent through the same object translation engine in reverse, where the DME receives a request from the object translation engine. The data is translated from the XML database to an SNMP response. Syslog messages use the same object translation engine as SNMP, where the source of the data (faults, events, audit logs) is translated from XML into a Cisco UCS Manager-formatted Syslog message. Cisco UCS Manager User CLI Documentation Cisco UCS Manager offers you a new set of smaller, use-case based documentation described in the following table: Guide Cisco UCS Manager Getting Started Guide Description Discusses Cisco UCS architecture and Day 0 operations, including Cisco UCS Manager initial configuration, and configuration best practices. 6

21 System Monitoring Overview Cisco UCS Manager User CLI Documentation Guide Cisco UCS Manager Administration Guide Cisco UCS Manager Infrastructure Management Guide Cisco UCS Manager Firmware Management Guide Cisco UCS Manager Server Management Guide Cisco UCS Manager Storage Management Guide Cisco UCS Manager Network Management Guide Cisco UCS Manager System Monitoring Guide Description Discusses password management, role-based access configuration, remote authentication, communication services, CIMC session management, organizations, backup and restore, scheduling options, BIOS tokens and deferred deployments. Discusses physical and virtual infrastructure components used and managed by Cisco UCS Manager. Discusses downloading and managing firmware, upgrading through Auto Install, upgrading through service profiles, directly upgrading at endpoints using firmware auto sync, managing the capability catalog, deployment scenarios, and troubleshooting. Discusses the new licenses, registering Cisco UCS domains with Cisco UCS Central, power capping, server boot, server profiles and server-related policies. Discusses all aspects of storage management such as SAN and VSAN in Cisco UCS Manager. Discusses all aspects of network management such as LAN and VLAN connectivity in Cisco UCS Manager. Discusses all aspects of system and health monitoring including system statistics in Cisco UCS Manager. 7

22 Cisco UCS Manager User CLI Documentation System Monitoring Overview 8

23 CHAPTER 3 Syslog Enabling Syslog Messages to Store In a Local File, page 9 Enabling Syslog Messages to Store In a Local File UCS-A# scope monitoring Enters monitoring mode. UCS-A /monitoring # {enable disable} Enables or disables the sending of syslogs to the console. syslog console UCS-A /monitoring # set syslog console (Optional) Select the lowest message level that you want level {emergencies alerts critical} displayed. If syslogs are enabled, the system displays that level and above on the console. The level options are listed in order of decreasing urgency.the default level is Critical. Step 4 UCS-A /monitoring # {enable disable} Enables or disables the monitoring of syslog information by the operating system. syslog monitor Step 5 UCS-A /monitoring # set syslog monitor level {emergencies alerts critical errors warnings notifications information debugging} (Optional) Select the lowest message level that you want displayed. If the monitor state is enabled, the system displays that level and above. The level options are listed in order of decreasing urgency.the default level is Critical. Note Messages at levels below Critical are displayed on the terminal monitor only if you have entered the terminal monitor command. 9

24 Enabling Syslog Messages to Store In a Local File Syslog Step 6 UCS-A /monitoring # {enable disable} syslog file Enables or disables the writing of syslog information to a syslog file. Step 7 UCS-A /monitoring # set syslog file name filename The name of the file in which the messages are logged. Up to 16 characters are allowed in the file name. Step 8 Step UCS-A /monitoring # set syslog file level {emergencies alerts critical errors warnings notifications information debugging} UCS-A /monitoring # set syslog file size filesize UCS-A /monitoring # {enable disable} syslog remote-destination {server-1 server-2 server-3} (Optional) Select the lowest message level that you want stored to a file. If the file state is enabled, the system stores that level and above in the syslog file. The level options are listed in order of decreasing urgency.the default level is Critical. (Optional) The maximum file size, in bytes, before the system begins to write over the oldest messages with the newest ones. The range is 4096 to bytes. Enables or disables the sending of syslog messages to up to three external syslog servers. UCS-A /monitoring # set syslog (Optional) remote-destination {server-1 server-2 Select the lowest message level that you want stored server-3} level{emergencies alerts to the external log. If the remote-destination is enabled, critical errors warnings notifications the system sends that level and above to the external information debugging} server. The level options are listed in order of decreasing urgency.the default level is Critical. UCS-A /monitoring # set syslog remote-destination {server-1 server-2 server-3} hostname hostname UCS-A /monitoring # set syslog remote-destination {server-1 server-2 server-3} facility {local0 local1 local2 local3 local4 local5 local6 local7} UCS-A /monitoring # {enable disable} syslog source {audits events faults} The hostname or IP address of the specified remote syslog server. Up to 256 characters are allowed in the hostname. (Optional) The facility level contained in the syslog messages sent to the specified remote syslog server. This can be one of the following: audits Enables or disables the logging of all audit log events. events Enables or disables the logging of all system events. faults Enables or disables the logging of all system faults. 5 UCS-A /monitoring # commit-buffer Commits the transaction. 10

25 Syslog Enabling Syslog Messages to Store In a Local File This example shows how to enable the storage of syslog messages in a local file and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # disable syslog console UCS-A /monitoring* # disable syslog monitor UCS-A /monitoring* # enable syslog file UCS-A /monitoring* # set syslog file name SysMsgsUCSA UCS-A /monitoring* # set syslog file level notifications UCS-A /monitoring* # set syslog file size UCS-A /monitoring* # disable syslog remote-destination server-1 UCS-A /monitoring* # disable syslog remote-destination server-2 UCS-A /monitoring* # disable syslog remote-destination server-3 UCS-A /monitoring* # commit-buffer UCS-A /monitoring # 11

26 Enabling Syslog Messages to Store In a Local File Syslog 12

27 CHAPTER 4 System Event Log System Event Log, page 13 Viewing the System Event Log for a Server, page 14 Configuring the SEL Policy, page 15 Backing Up the System Event Log for a Server, page 17 Clearing the System Event Log for a Server, page 18 System Event Log The System Event Log (SEL) resides on the CIMC in NVRAM. The SEL is used for troubleshooting system health. It records most server-related events, such as instances of over or under voltage, temperature events, fan events, and BIOS events. The types of events supported by SEL include BIOS events, memory unit events, processor events, and motherboard events. The SEL logs are stored in the CIMC NVRAM, through a SEL log policy. It is best practice to periodically download and clear the SEL logs. The SEL file is approximately 40KB in size, and no further events can be recorded once it is full. It must be cleared before additional events can be recorded. You can use the SEL policy to back up the SEL to a remote server, and optionally to clear the SEL after a backup operation occurs. Backup operations can be triggered based on specific actions, or they can be set to occur at regular intervals. You can also manually back up or clear the SEL. The backup file is automatically generated. The filename format is sel-systemname-chassisid-serverid-serverserialnumber-timestamp. For example, sel-ucs-a-ch01-serv01-qci

28 Viewing the System Event Log for a Server System Event Log Viewing the System Event Log for a Server Viewing the System Event Log for an Individual Server UCS-A# show sel chassis-id / blade-id Displays the system event log for the specified server. The following example displays the system event log for blade 3 in chassis 1. UCS-A# show sel 1/3 1 01/01/ :23:27 System Event 0x83 Timestamp clock synch SEL timestamp clock updated, event is f irst of pair Asserted 2 01/01/ :23:28 Drive slot(bay) SAS0_LINK_STATUS Transition to Degraded Asserted 3 01/01/ :23:28 Drive slot(bay) SAS0_LINK_STATUS Transition to On Line Deasserted 4 01/01/ :23:28 Platform alert LED_SAS0_FAULT LED is blinking fast Asserted 5 01/01/ :23:28 Platform alert LED_SAS0_FAULT LED is on Deasserted 6 01/01/ :23:28 Platform alert LED_FPID LED is on Asserted 7 01/01/ :23:28 Platform alert LED_FPID LED is off Deasserted 8 01/01/ :23:29 Entity presence MAIN_POWER Device Absent Asserted 9 01/01/ :23:29 Entity presence MAIN_POWER Device Present Deasserted a 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED is on Asserted b 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED color is green Asserted c 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED is blinking fast Deasserted d 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED color is amber Deasserted e 01/01/ :00:22 Drive slot(bay) SAS0_LINK_STATUS Transition to Degraded Asserted f 01/01/ :00:22 Entity presence MEZZ_PRS Device Present Asserted 10 01/01/ :00:22 Entity presence HDD1_PRS Device Absent Asserted Viewing the System Event Log for All of the Servers in a Chassis UCS-A# scope server chassis-id / blade-id UCS-A /chassis/server # show sel Enters chassis server mode for the specified server. Displays the system event log. 14

29 System Event Log Configuring the SEL Policy The following example displays the system event log from chassis server mode for blade 3 in chassis 1. UCS-A# scope server 1/3 UCS-A /chassis/server # show sel 1 01/01/ :23:27 System Event 0x83 Timestamp clock synch SEL timestamp clock updated, event is f irst of pair Asserted 2 01/01/ :23:28 Drive slot(bay) SAS0_LINK_STATUS Transition to Degraded Asserted 3 01/01/ :23:28 Drive slot(bay) SAS0_LINK_STATUS Transition to On Line Deasserted 4 01/01/ :23:28 Platform alert LED_SAS0_FAULT LED is blinking fast Asserted 5 01/01/ :23:28 Platform alert LED_SAS0_FAULT LED is on Deasserted 6 01/01/ :23:28 Platform alert LED_FPID LED is on Asserted 7 01/01/ :23:28 Platform alert LED_FPID LED is off Deasserted 8 01/01/ :23:29 Entity presence MAIN_POWER Device Absent Asserted 9 01/01/ :23:29 Entity presence MAIN_POWER Device Present Deasserted a 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED is on Asserted b 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED color is green Asserted c 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED is blinking fast Deasserted d 01/01/ :23:29 Platform alert LED_SAS0_FAULT LED color is amber Deasserted e 01/01/ :00:22 Drive slot(bay) SAS0_LINK_STATUS Transition to Degraded Asserted f 01/01/ :00:22 Entity presence MEZZ_PRS Device Present Asserted 10 01/01/ :00:22 Entity presence HDD1_PRS Device Absent Asserted Configuring the SEL Policy UCS-A# scope org org-name Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name. Step 4 Step 5 UCS-A /org # scope ep-log-policy sel UCS-A /org/ep-log-policy # set description description UCS-A /org/ep-log-policy # set backup action [log-full] [on-change-of-association] [on-clear] [timer] [none] UCS-A /org/ep-log-policy # set backup clear-on-backup {no yes} Enters organization endpoint log policy mode and scopes the SEL policy. (Optional) Provides a description for the policy. Note If your description includes spaces, special characters, or punctuation, begin and end your description with quotation marks. The quotation marks will not appear in the description field of any show command output. Specifies an action or actions that will trigger a backup operation. Specifies whether to clear the system event log after a backup operation occurs. 15

30 Configuring the SEL Policy System Event Log Step 6 UCS-A /org/ep-log-policy # set backup destination URL Specifies the protocol, user, password, remote hostname, and remote path for the backup operation. Depending on the protocol used, specify the URL using one of the following syntaxes: ftp:// username@hostname / path scp:// hostname / path sftp:// hostname / path tftp:// hostname : port-num / path Step 7 Step 8 Step 9 UCS-A /org/ep-log-policy # set backup format {ascii binary} UCS-A /org/ep-log-policy # set backup hostname {hostname ip-addr} UCS-A /org/ep-log-policy # set backup interval {1-hour 2-hours 4-hours 8-hours 24-hours never} Note You can also specify the backup destination by using the set backup hostname, set backup password, set backup protocol, set backup remote-path, set backup user commands, or by using the set backup destination command. Use either method to specify the backup destination. Specifies the format for the backup file. Specifies the hostname or IP address of the remote server. Specifies the time interval for the automatic backup operation. Specifying the never keyword means that automatic backups will not be made UCS-A /org/ep-log-policy # set backup password password UCS-A /org/ep-log-policy # set backup protocol {ftp scp sftp tftp} UCS-A /org/ep-log-policy # set backup remote-path path UCS-A /org/ep-log-policy # set backup user username UCS-A /org/ep-log-policy # commit-buffer Specifies the password for the username. This step does not apply if the TFTP protocol is used. Specifies the protocol to use when communicating with the remote server. Specifies the path on the remote server where the backup file is to be saved. Specifies the username the system should use to log in to the remote server. This step does not apply if the TFTP protocol is used. Commits the transaction. 16

31 System Event Log Backing Up the System Event Log for a Server The following example configures the SEL policy to back up the system event log (in ASCII format) every 24 hours or when the log is full, clears the system event log after a backup operation occurs, and commits the transaction: UCS-A# scope org / UCS-A /org # scope ep-log-policy sel UCS-A /org/ep-log-policy # set backup destination scp://user@ /logs Password: UCS-A /org/ep-log-policy* # set backup action log-full UCS-A /org/ep-log-policy* # set backup clear-on-backup yes UCS-A /org/ep-log-policy* # set backup format ascii UCS-A /org/ep-log-policy* # set backup interval 24-hours UCS-A /org/ep-log-policy* # commit-buffer UCS-A /org/ep-log-policy # Backing Up the System Event Log for a Server Backing Up the System Event Log for an Individual Server Before You Begin Configure the system event log policy. The manual backup operation uses the remote destination configured in the system event log policy. UCS-A /chassis/server # backup sel chassis-id / blade-id UCS-A# commit-buffer Backs up the system event log. Commits the transaction. The following example backs up the system event log for blade 3 in chassis 1 and commits the transaction. UCS-A# backup sel 1/3 UCS-A* # commit-buffer UCS-A# Backing Up the System Event Log for All of the Servers in a Chassis Before You Begin Configure the system event log policy. The manual backup operation uses the remote destination configured in the system event log policy. 17

32 Clearing the System Event Log for a Server System Event Log UCS-A# scope server chassis-id / blade-id UCS-A /chassis/server # backup sel UCS-A /chassis/server # commit-buffer Enters chassis server mode for the specified server. Backs up the system event log. Commits the transaction. The following example backs up the system event log from chassis server mode for blade 3 in chassis 1 and commits the transaction. UCS-A# scope server 1/3 UCS-A /chassis/server # backup sel UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server # Clearing the System Event Log for a Server Clearing the System Event Log for an Individual Server UCS-A# clear sel chassis-id / blade-id UCS-A# commit-buffer Clears the system event log. Commits the transaction. The following example clears the system event log for blade 3 in chassis 1 and commits the transaction: UCS-A# clear sel 1/3 UCS-A* # commit-buffer UCS-A# Clearing the System Event Log for All of the Servers in a Chassis UCS-A# scope server chassis-id / blade-id Enters chassis server mode for the specified server. 18

33 System Event Log Clearing the System Event Log for All of the Servers in a Chassis UCS-A /chassis/server # clear sel UCS-A /chassis/server # commit-buffer Clears the system event log. Commits the transaction. The following example clears the system event log from chassis server mode for blade 3 in chassis 1 and commits the transaction: UCS-A# scope server 1/3 UCS-A /chassis/server # clear sel UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server # 19

34 Clearing the System Event Log for All of the Servers in a Chassis System Event Log 20

35 CHAPTER 5 Audit Logs Audit Logs, page 21 Viewing Audit Logs, page 21 Audit Logs Audit Logs record system events that occurred, where they occurred, and which users initiated them. Viewing Audit Logs UCS-A# scope security Enters security mode. UCS-A /security # show audit-logs Displays the audit logs. Note Use the id option to view a specific audit-log. Use the detail option to view more detailed information in the audit log output. The following example displays the audit logs: UCS-A# scope security UCS-A /security # show audit-logs Audit trail logs: Creation Time User ID Action Description T12:34: internal Creation Web A: local user admin logged i T11:26: admin Creation Server port A/1/21 created T11:26: admin Deletion Server Port Channel A/

36 Viewing Audit Logs Audit Logs delet T11:26: admin Modification Acknowledged chassis T11:25: admin Modification chassis discovery policy modifie T11:25: admin Deletion Server Member Port A/1/23 remove T11:04: admin Deletion Server port A/1/21 deleted T11:04: admin Creation Server Port Channel A/1025 creat T11:04: UCS-A /security # 22

37 CHAPTER 6 Log File Exporter Log File Exporter, page 23 Exporting Log Files to a Remote Server, page 24 Log File Exporter Cisco UCS Manager generates log files for each executable. The log files can be up to 20 MB in size, and up to five backups can be stored on the server. The log file exporter allows you to export the log files to a remote server before they are deleted. The log file names contain the following information: The name of the process Timestamp The name and ID of the fabric interconnect Note If you do not enable log exporting, the oldest log files are deleted whenever the maximum backup file limit is reached. Guidelines and Limitations We recommend that you use tftp or password-less scp or sftp for log export. When standard scp or sftp is used, the user password is stored in the configuration file in encrypted format. On a HA setup, the log files from each side are exported separately. If one side fails to export logs, the other side does not compensate. 23

38 Exporting Log Files to a Remote Server Log File Exporter Exporting Log Files to a Remote Server UCS-A# scope monitoring UCS-A /monitoring # scope sysdebug Enters monitoring mode. Enters monitoring system debug mode. Step 4 Step 5 Step 6 Step 7 Step 8 Step UCS-A /monitoring/sysdebug # scope log-export-policy UCS-A /monitoring/sysdebug/log-export-policy # set admin-state {disabled enabled} UCS-A /monitoring/sysdebug/log-export-policy # set desc description UCS-A /monitoring/sysdebug/log-export-policy # set hostname hostname UCS-A /monitoring/sysdebug/log-export-policy # set passwd UCS-A /monitoring/sysdebug/log-export-policy # set passwordless-ssh {no yes} UCS-A /monitoring/sysdebug/log-export-policy # set proto {scp ftp sftp tftp} UCS-A /monitoring/sysdebug/log-export-policy # set path path UCS-A /monitoring/sysdebug/log-export-policy # set user username Enters log file export mode. Whether log file exporting is enabled. (Optional) Provides a description for the log export policy Specifies the hostname of the remote server. After you press Enter, you are prompted to enter the password. Specifies the password for the remote server username. This step does not apply if the TFTP protocol is used. Enables SSH login without a password. Specifies the protocol to use when communicating with the remote server. Specifies the path on the remote server where the log file is to be saved. Specifies the username the system should use to log in to the remote server. This step does not apply if the TFTP protocol is used. 2 UCS-A /monitoring/sysdebug/log-export-policy # commit-buffer Commits the transaction. The following example shows how to enable the log file exporter, specify the remote server hostname, set the protocol to scp, enable passwordless login, and commit the transaction. UCS-A# scope monitoring UCS-A /monitoring # scope sysdebug UCS-A /monitoring/sysdebug # scope log-export-policy UCS-A /monitoring/sysdebug/log-export-policy # set admin-state enable UCS-A /monitoring/sysdebug/log-export-policy* # set hostname UCS-A /monitoring/sysdebug/log-export-policy* # set path / UCS-A /monitoring/sysdebug/log-export-policy* # set user testuser 24

39 Log File Exporter Exporting Log Files to a Remote Server UCS-A /monitoring/sysdebug/log-export-policy* # set proto scp UCS-A /monitoring/sysdebug/log-export-policy* # set passwd password: UCS-A /monitoring/sysdebug/log-export-policy* # set passwordless-ssh yes UCS-A /monitoring/sysdebug/log-export-policy* # commit-buffer UCS-A /monitoring/sysdebug/log-export-policy # 25

40 Exporting Log Files to a Remote Server Log File Exporter 26

41 CHAPTER 7 Core File Exporter Core File Exporter, page 27 Configuring the Core File Exporter, page 27 Disabling the Core File Exporter, page 28 Core File Exporter Critical failures in the Cisco UCS components, such as a fabric interconnect or an I/O module, can cause the system to create a core dump file. Cisco UCS Manager uses the Core File Exporter to immediately export the core dump files to a specified location on the network through TFTP. This functionality allows you to export the tar file with the contents of the core dump file. The Core File Exporter provides system monitoring and automatic export of core dump files that need to be included in TAC cases. Configuring the Core File Exporter UCS-A# scope monitoring Enters monitoring mode. UCS-A /monitoring # scope sysdebug Enters monitoring system debug mode. UCS-A /monitoring/sysdebug # enable core-export-target Enables the core file exporter. When the core file exporter is enabled and an error causes the server to perform a core dump, the system exports the core file via TFTP to the specified remote server. Step 4 UCS-A /monitoring/sysdebug # set core-export-target path path Specifies the path to use when exporting the core file to the remote server. 27

42 Disabling the Core File Exporter Core File Exporter Step 5 UCS-A /monitoring/sysdebug # set core-export-target port port-num Specifies the port number to use when exporting the core file via TFTP. The range of valid values is 1 to 65,535. Step 6 Step 7 UCS-A /monitoring/sysdebug # set core-export-target server-description description UCS-A /monitoring/sysdebug # set core-export-target server-name hostname Provides a description for the remote server used to store the core file. Specifies the hostname of the remote server to connect with via TFTP. Step 8 UCS-A /monitoring/sysdebug # commit-buffer Commits the transaction. The following example enables the core file exporter, specifies the path and port to use when sending the core file, specifies the remote server hostname, provides a description for the remote server, and commits the transaction. UCS-A# scope monitoring UCS-A /monitoring # scope sysdebug UCS-A /monitoring/sysdebug # enable core-export-target UCS-A /monitoring/sysdebug* # set core-export-target path /root/corefiles/core UCS-A /monitoring/sysdebug* # set core-export-target port UCS-A /monitoring/sysdebug* # set core-export-target server-description CoreFile UCS-A /monitoring/sysdebug* # set core-export-target server-name UCS-A /monitoring/sysdebug* # commit-buffer UCS-A /monitoring/sysdebug # Disabling the Core File Exporter Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope sysdebug UCS-A /monitoring/sysdebug # disable core-export-target UCS-A /monitoring/sysdebug # commit-buffer Enters monitoring mode. Enters monitoring system debug mode. Disables the core file exporter. When the core file exporter is disabled core files are not automatically exported. Commits the transaction. The following example disables the core file exporter and commits the transaction. UCS-A# scope monitoring UCS-A /monitoring # scope sysdebug UCS-A /monitoring/sysdebug # disable core-export-target 28

43 Core File Exporter Disabling the Core File Exporter UCS-A /monitoring/sysdebug* # commit-buffer UCS-A /monitoring/sysdebug # 29

44 Disabling the Core File Exporter Core File Exporter 30

45 CHAPTER 8 Fault Collection and Suppression Global Fault Policy, page 31 Fault Suppression, page 32 Global Fault Policy The global fault policy controls the lifecycle of a fault in a Cisco UCS domain, including when faults are cleared, the flapping interval (the length of time between the fault being raised and the condition being cleared), and the retention interval (the length of time a fault is retained in the system). A fault in Cisco UCS has the following lifecycle: 1 A condition occurs in the system and Cisco UCS Manager raises a fault. This is the active state. 2 When the fault is alleviated, it enters a flapping or soaking interval that is designed to prevent flapping. Flapping occurs when a fault is raised and cleared several times in rapid succession. During the flapping interval, the fault retains its severity for the length of time specified in the global fault policy. 3 If the condition reoccurs during the flapping interval, the fault returns to the active state. If the condition does not reoccur during the flapping interval, the fault is cleared. 4 The cleared fault enters the retention interval. This interval ensures that the fault reaches the attention of an administrator even if the condition that caused the fault has been alleviated and the fault has not been deleted prematurely. The retention interval retains the cleared fault for the length of time specified in the global fault policy. 5 If the condition reoccurs during the retention interval, the fault returns to the active state. If the condition does not reoccur, the fault is deleted. 31

46 Configuring the Fault Collection Policy Fault Collection and Suppression Configuring the Fault Collection Policy Step 4 Step 5 Step 6 UCS-A# scope monitoring UCS-A /monitoring # scope fault policy UCS-A /monitoring/fault-policy # set clear-action {delete retain} UCS-A /monitoring/fault-policy # set flap-interval seconds UCS-A /monitoring/fault-policy # set retention-interval {days hours minutes seconds forever} UCS-A /monitoring/fault-policy # commit-buffer Enters monitoring mode. Enters monitoring fault policy mode. Specifies whether to retain or delete all cleared messages. If the retain option is specified, then the length of time that the messages are retained is determined by the set retention-interval command. Specifies the time interval (in seconds) the system waits before changing a fault state. Flapping occurs when a fault is raised and cleared several times in rapid succession. To prevent this, the system does not allow a fault to change state until the flapping interval has elapsed after the last state change. If the fault is raised again during the flapping interval, it returns to the active state, otherwise, the fault is cleared. Specifies the time interval the system retains all cleared fault messages before deleting them. The system can retain cleared fault messages forever, or for the specified number of days, hours, minutes, and seconds. Commits the transaction. Fault Suppression This example configures the fault collection policy to retain cleared fault messages for 30 days, sets the flapping interval to 10 seconds, and commits the transaction. UCS-A# scope monitoring UCS-A /monitoring # scope fault policy UCS-A /monitoring/fault-policy # set clear-action retain UCS-A /monitoring/fault-policy* # set flap-interval 10 UCS-A /monitoring/fault-policy* # set retention-interval UCS-A /monitoring/fault-policy* # commit-buffer UCS-A /monitoring/fault-policy # Fault suppression allows you to suppress SNMP trap and Call Home notifications during a planned maintenance time. You can create a fault suppression task to prevent notifications from being sent whenever a transient fault is raised or cleared. 32

47 Fault Collection and Suppression Fault Suppression Faults remain suppressed until the time duration has expired, or the fault suppression tasks have been manually stopped by you. After the fault suppression has ended, Cisco UCS Manager will send notifications for any outstanding suppressed faults that have not been cleared. You can configure fault suppression using the following methods. Fixed Time Intervals or Schedules You can use the following to specify the maintenance window during which you want to suppress faults: Fixed time intervals allow you to create a start time and a duration when fault suppression is active. Fixed time intervals cannot be reused. Schedules are used for one time occurrences or recurring time periods. They can be saved and reused. Suppression Policies These policies define which causes and types of faults you want to suppress. Only one policy can be assigned to a task. The following policies are defined by Cisco UCS Manager: default-chassis-all-maint Suppresses faults for the chassis and all components installed into the chassis, including all servers, power supplies, fan modules, and IOMs. This policy applies only to chassis. default-chassis-phys-maint Suppresses faults for the chassis, all fan modules, and power supplies installed into the chassis. This policy applies only to chassis. default-fex-all-maint Suppresses faults for the FEX, all power supplies, fan modules, and IOMs in the FEX. This policy applies only to FEXes. default-fex-phys-maint Suppresses faults for the FEX, all fan modules and power supplies in the FEX. This policy applies only to FEXes. default-server-maint Suppresses faults for servers. This policy applies to chassis, organizations, and service profiles. Note When applied to a chassis, only servers are affected. Note Cisco UCS Manager does not suppress SNMP MIB-2 faults generated by NX-OS network operating system designed to support high performance, high reliability server access switches used in the data center. These SNMP MIB-2 faults have no association with this fault suppression policy. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. This policy applies only to chassis, FEXes, and IOMs. 33

48 Configuring Fault Suppression for a Chassis Fault Collection and Suppression Suppression Tasks You can use these tasks to connect the schedule or fixed time interval and the suppression policy to a component. Note After you create a suppression task, you can edit the fixed time interval or schedule of the task in both the Cisco UCS Manager GUI and Cisco UCS Manager CLI. However, you can only change between using a fixed time interval and using a schedule in the Cisco UCS Manager CLI. Configuring Fault Suppression for a Chassis Configuring Fault Suppression Tasks for a Chassis Using a Fixed Time Interval UCS-A# scope chassis chassis-num UCS-A/chassis # create fault-suppress-task name UCS-A/chassis/fault-suppress-task # set fault-suppress-policy policy-name Enters chassis mode for the specified chassis. Creates a fault-suppress-task on the chassis, and enters fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Specifies the fault suppression policy that you want to apply. This can be one of the following: default-chassis-all-maint Suppresses faults for the chassis and all components installed into the chassis, including all servers, power supplies, fan modules, and IOMs. default-chassis-phys-maint Suppresses faults for the chassis, all fan modules, and power supplies installed into the chassis. default-server-maint Suppresses faults for servers. Note When applied to a chassis, only servers are affected. 34

49 Fault Collection and Suppression Configuring Fault Suppression for a Chassis Step 4 UCS-A/chassis/fault-suppress-task # create local-schedule Step 5 UCS-A/chassis/fault-suppress-task/local-schedule # create occurrence single-one-time default-iom-maint Suppresses faults for IOMs in a chassis or FEX. Creates a local schedule and enters local-schedule mode. Creates a one-time occurrence, and enters single-one-time mode. Step 6 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 7 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 8 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task2 for the chassis, apply the default-chassis-all-maint policy to the task, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope chassis 1 UCS-A/chassis # create fault-suppress-task task2 UCS-A/chassis/fault-suppress-task* # set fault-suppress-policy default-chassis-all-maint UCS-A/chassis/fault-suppress-task* # create local-schedule UCS-A/chassis/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/chassis/fault-suppress-task/local-schedule* # set date jan UCS-A/chassis/fault-suppress-task/local-schedule* # commit-buffer Configuring Fault Suppression Tasks for a Chassis Using a Schedule UCS-A# scope chassis chassis-num UCS-A/chassis # create fault-suppress-task name Enters chassis mode for the specified chassis. Creates a fault-suppress-task on the chassis, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. 35

50 Configuring Fault Suppression for a Chassis Fault Collection and Suppression Step 4 UCS-A/chassis/fault-suppress-task # set schedule name UCS-A/chassis/fault-suppress-task # set fault-suppress-policy policy-name Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Selects the fault suppression policy you want to apply. This can be one of the following: default-chassis-all-maint Suppresses faults for the chassis and all components installed into the chassis, including all servers, power supplies, fan modules, and IOMs. default-chassis-phys-maint Suppresses faults for the chassis, all fan modules, and power supplies installed into the chassis. default-server-maint Suppresses faults for servers. Note When applied to a chassis, only servers are affected. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. Step 5 UCS-A/chassis/fault-suppress-task # commit-buffer Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task1 for the chassis, apply the scheduler called weekly_maint and the default-chassis-all-maint policy to the task, and commit the transaction: UCS-A# scope chassis 2 UCS-A/chassis # create fault-suppress-task task1 UCS-A/chassis/fault-suppress-task* # set schedule weekly_maint UCS-A/chassis/fault-suppress-task* # set fault-suppress-policy default-chassis-all-maint UCS-A/chassis/fault-suppress-task* # commit-buffer Modifying Fault Suppression Tasks for a Chassis UCS-A# scope chassis chassis-num UCS-A/chassis # scope fault-suppress-task name UCS-A/chassis/fault-suppress-task # set fault-suppress-policy policy-name Enters chassis mode for the specified chassis. Enters fault-suppress-task mode. Modifies the fault suppression policy. This can be one of the following: 36

51 Fault Collection and Suppression Configuring Fault Suppression for a Chassis Step 4 UCS-A/chassis/fault-suppress-task # set schedule name Step 5 UCS-A/chassis/fault-suppress-task # scope local-schedule Note default-chassis-all-maint Suppresses faults for the chassis and all components installed into the chassis, including all servers, power supplies, fan modules, and IOMs. default-chassis-phys-maint Suppresses faults for the chassis, all fan modules, and power supplies installed into the chassis. default-server-maint Suppresses faults for servers. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. To apply a different schedule to the fault suppression task, go to Step 4. To change the fixed time interval of the fault suppression task, go to Step 5. Applies the schedule you want to use. Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. Enters local-schedule mode. Step 6 UCS-A/chassis/fault-suppress-task/local-schedule # scope occurrence single-one-time Step 7 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 8 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 9 UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time # commit-buffer Enters single-one-time mode. Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. 37

52 Configuring Fault Suppression for a Chassis Fault Collection and Suppression The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2: UCS-A# scope chassis 1 UCS-A/chassis # scope fault-suppress-task task2 UCS-A/chassis/fault-suppress-task # set fault-suppress-policy default-server-maint UCS-A/chassis/fault-suppress-task* # scope local-schedule UCS-A/chassis/fault-suppress-task/local-schedule* # scope occurrence single-one-time UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time* # set date dec UCS-A/chassis/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1: UCS-A# scope chassis 1 UCS-A/chassis # scope fault-suppress-task task1 UCS-A/chassis/fault-suppress-task # set schedule monthly-maint UCS-A/chassis/fault-suppress-task* # commit-buffer Viewing Suppressed Faults and Fault Suppression Tasks for a Chassis UCS-A# scope chassis chassis-num Enters chassis mode for the specified chassis. Step 4 UCS-A/chassis # show fault suppressed UCS-A/chassis # scope fault-suppress-task name UCS-A/chassis/fault-suppress-task # show detail expand Displays the suppressed faults for the chassis. Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for a chassis: UCS-A# scope chassis 1 UCS-A/chassis # show fault suppressed Fault Suppress Task: Name Status Global Schedule Suppress Policy Name task1 Active test_schedule1 Default Chassis Phys Maint UCS-A/chassis # The following example shows how to display the fault suppression task called task1: UCS-A# scope chassis 1 UCS-A/chassis # scope fault-suppress-task task1 UCS-A/chassis/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Chassis Phys Maint UCS-A/chassis/fault-suppress-task # 38

53 Fault Collection and Suppression Configuring Fault Suppression for an I/O Module Deleting Fault Suppression Tasks for a Chassis UCS-A# scope chassis chassis-num Enters chassis mode for the specified chassis. UCS-A/chassis # delete fault-suppress-task name UCS-A/chassis # commit-buffer Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1: UCS-A# scope chassis 1 UCS-A/chassis # delete fault-suppress-task task1 UCS-A/chassis* # commit-buffer Configuring Fault Suppression for an I/O Module Configuring Fault Suppression Tasks for an IOM Using a Fixed Time Interval The default-iom-maint suppression policy is selected by default. UCS-A# scope [chassis chassis-num fex fex-num] UCS-A /chassis fex # scope iom iom-id UCS-A/chassis fex/iom # create fault-suppress-task name Enters chassis mode for the specified chassis or FEX. Enters chassis I/O module mode for the selected I/O module. Creates a fault-suppress-task on the IOM, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), 39

54 Configuring Fault Suppression for an I/O Module Fault Collection and Suppression Step 4 UCS-A/chassis fex/iom/fault-suppress-task # create local-schedule Step 5 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule # create occurrence single-one-time and you cannot change this name after the object is saved. Creates a local schedule and enters local-schedule mode. Creates a one-time occurrence, and enters single-one-time mode. Step 6 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 7 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 8 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task2 for the IOM on a chassis, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # create fault-suppress-task task2 UCS-A/chassis/iom/fault-suppress-task* # create local-schedule UCS-A/chassis/iom/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/chassis/iom/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/chassis/iom/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to create a fault suppression task called task2 for the IOM on a FEX, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope fex 1 UCS-A/fex # scope iom a UCS-A/fex/iom # create fault-suppress-task task2 UCS-A/fex/iom/fault-suppress-task* # create local-schedule UCS-A/fex/iom/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/fex/iom/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/fex/iom/fault-suppress-task/local-schedule/single-one-time* # commit-buffer Configuring Fault Suppression Tasks for an IOM Using a Schedule The default-iom-maint suppression policy is selected by default. 40

55 Fault Collection and Suppression Configuring Fault Suppression for an I/O Module UCS-A# scope [chassis chassis-num fex fex-num] UCS-A /chassis fex # scope iom iom-id Enters chassis mode for the specified chassis or FEX. Enters chassis I/O module mode for the selected I/O module. Step 4 Step 5 UCS-A/chassis fex/iom # create fault-suppress-task name UCS-A/chassis fex/iom/fault-suppress-task # set schedule name UCS-A/chassis fex/iom/fault-suppress-task # commit-buffer Creates a fault-suppress-task on the IOM, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task1 for the IOM on a chassis, apply the scheduler called weekly_maint to the task, and commit the transaction: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # create fault-suppress-task task1 UCS-A/chassis/iom/fault-suppress-task* # set schedule weekly_maint UCS-A/chassis/iom/fault-suppress-task* # commit-buffer The following example shows how to create a fault suppression task called task1 for the IOM on a FEX, apply the scheduler called weekly_maint to the task, and commit the transaction: UCS-A# scope fex 1 UCS-A/fex # scope iom a UCS-A/fex/iom # create fault-suppress-task task1 UCS-A/fex/iom/fault-suppress-task* # set schedule weekly_maint UCS-A/fex/iom/fault-suppress-task* # commit-buffer 41

56 Configuring Fault Suppression for an I/O Module Fault Collection and Suppression Modifying Fault Suppression Tasks for an IOM Step 4 Step 5 UCS-A# scope [chassis chassis-num fex fex-num] UCS-A /chassis fex # scope iom iom-id UCS-A/chassis fex/iom # scope fault-suppress-task name UCS-A/chassis fex/iom/fault-suppress-task # set schedule name UCS-A/chassis fex/iom/fault-suppress-task # scope local-schedule Enters chassis mode for the specified chassis or FEX. Enters chassis I/O module mode for the selected I/O module. Enters fault-suppress-task mode. Note To apply a different schedule to the fault suppression task, go to Step 4. To change the fixed time interval of the fault suppression task, go to Step 5. Applies a different schedule. Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. Enters local-schedule mode. 42

57 Fault Collection and Suppression Configuring Fault Suppression for an I/O Module Step 6 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule # scope occurrence single-one-time Enters single-one-time mode. Step 7 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 8 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 9 UCS-A/chassis fex/iom/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2 for an IOM on a chassis: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # scope fault-suppress-task task2 UCS-A/chassis/iom/fault-suppress-task # scope local-schedule UCS-A/chassis/iom/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/chassis/iom/fault-suppress-task/local-schedule/single-one-time # set date dec UCS-A/chassis/iom/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1 for an IOM on a FEX: UCS-A# scope fex 3 UCS-A/fex # scope iom a UCS-A/fex/iom # scope fault-suppress-task task1 UCS-A/fex/iom/fault-suppress-task # set schedule monthly-maint UCS-A/fex/iom/fault-suppress-task* # commit-buffer Viewing Suppressed Faults and Fault Suppression Tasks for an IOM UCS-A# scope [chassis chassis-num fex fex-num] UCS-A /chassis fex # scope iom iom-id Enters chassis mode for the specified chassis or FEX. Enters chassis I/O module mode for the selected I/O module. 43

58 Configuring Fault Suppression for an I/O Module Fault Collection and Suppression Step 4 Step 5 UCS-A/chassis fex/iom # show fault suppressed UCS-A/chassis fex/iom # scope fault-suppress-task name UCS-A/chassis fex/iom/fault-suppress-task # show detail expand Displays the suppressed faults for the IOM. Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for an IOM on a chassis: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # show fault suppressed Fault Suppress Task: Name Status Global Schedule Suppress Policy Name task1 Active test_schedule1 Default Iom Maint UCS-A/chassis/iom # The following example shows how to display the fault suppression task called task1 for an IOM on a chassis: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # scope fault-suppress-task task1 UCS-A/chassis/iom/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Iom Maint UCS-A/chassis/iom/fault-suppress-task # The following example shows how to display the fault suppression task called task1 for an IOM on a FEX: UCS-A# scope fex 3 UCS-A/fex # scope iom a UCS-A/fex/iom # scope fault-suppress-task task1 UCS-A/fex/iom/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Iom Maint UCS-A/chassis/iom/fault-suppress-task # 44

59 Fault Collection and Suppression Configuring Fault Suppression for a FEX Deleting Fault Suppression Tasks for an IOM Step 4 UCS-A# scope [chassis chassis-num fex fex-num] UCS-A /chassis fex # scope iom iom-id UCS-A/chassis fex/iom # delete fault-suppress-task name UCS-A/chassis fex/iom # commit-buffer Enters chassis mode for the specified chassis or FEX. Enters chassis I/O module mode for the selected I/O module. Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1 for an IOM on a chassis: UCS-A# scope chassis 1 UCS-A/chassis # scope iom a UCS-A/chassis/iom # delete fault-suppress-task task1 UCS-A/chassis/iom* # commit-buffer The following example shows how to delete the fault suppression task called task1 for an IOM on a FEX: UCS-A# scope fex 3 UCS-A/fex # scope iom a UCS-A/fex/iom # delete fault-suppress-task task1 UCS-A/fex/iom* # commit-buffer Configuring Fault Suppression for a FEX Configuring Fault Suppression Tasks for a FEX Using a Fixed Time Interval UCS-A# scope fex fex-num UCS-A/fex # create fault-suppress-task name Enters fex mode for the specified FEX. Creates a fault-suppress-task on the fex, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you 45

60 Configuring Fault Suppression for a FEX Fault Collection and Suppression UCS-A/fex/fault-suppress-task # set fault-suppress-policy policy-name cannot change this name after the object is saved. Specifies the fault suppression policy you want to apply. This can be one of the following: default-fex-all-maint Suppresses faults for the FEX, all power supplies, fan modules, and IOMs in the FEX. default-fex-phys-maint Suppresses faults for the FEX, all fan modules and power supplies in the FEX. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. Step 4 UCS-A/fex/fault-suppress-task # create local-schedule Creates a local schedule and enters local-schedule mode. Step 5 UCS-A/fex/fault-suppress-task/local-schedule # create occurrence single-one-time Creates a one-time occurrence, and enters single-one-time mode. Step 6 Step 7 Step 8 UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task2 for the FEX, apply the default-fex-all-maint policy to the task, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope fex 1 UCS-A/fex # create fault-suppress-task task2 UCS-A/fex/fault-suppress-task* # set fault-suppress-policy default-fex-all-maint UCS-A/fex/fault-suppress-task* # create local-schedule UCS-A/fex/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/fex/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/fex/fault-suppress-task/local-schedule/single-one-time* # commit-buffer 46

61 Fault Collection and Suppression Configuring Fault Suppression for a FEX Configuring Fault Suppression Tasks for a FEX Using a Schedule Step 4 Step 5 UCS-A# scope fex fex-num UCS-A/fex # create fault-suppress-task name UCS-A/fex/fault-suppress-task # set schedule name UCS-A/fex/fault-suppress-task # set fault-suppress-policy policy-name UCS-A/fex/fault-suppress-task # commit-buffer Enters fex mode for the specified FEX. Creates a fault-suppress-task on the fex, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Specifies the fault suppression policy that you want to apply. This can be one of the following: default-fex-all-maint Suppresses faults for the FEX, all power supplies, fan modules, and IOMs in the FEX. default-fex-phys-maint Suppresses faults for the FEX, all fan modules and power supplies in the FEX. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task1 for the FEX, apply the scheduler called weekly_maint and the default-fex-all-maint policy to the task, and commit the transaction: UCS-A# scope fex 1 UCS-A/fex # create fault-suppress-task task1 UCS-A/fex/fault-suppress-task* # set schedule weekly_maint UCS-A/fex/fault-suppress-task* # set fault-suppress-policy default-fex-all-maint UCS-A/fex/fault-suppress-task* # commit-buffer 47

62 Configuring Fault Suppression for a FEX Fault Collection and Suppression Modifying Fault Suppression Tasks for a FEX UCS-A# scope fex fex-num UCS-A/fex # scope fault-suppress-task name Enters fex mode for the specified FEX. Enters fault-suppress-task mode. UCS-A/fex/fault-suppress-task # set fault-suppress-policy policy-name Modifies the fault suppression policy. This can be one of the following: default-fex-all-maint Suppresses faults for the FEX, all power supplies, fan modules, and IOMs in the FEX. default-fex-phys-maint Suppresses faults for the FEX, all fan modules and power supplies in the FEX. default-iom-maint Suppresses faults for IOMs in a chassis or FEX. Step 4 Step 5 UCS-A/fex/fault-suppress-task # set schedule name UCS-A/fex/fault-suppress-task # scope local-schedule Note To apply a different schedule to the fault suppression task, go to Step 4. To change the fixed time interval of the fault suppression task, go to Step 5. Applies a different schedule. Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. Enters local-schedule mode. Step 6 Step 7 UCS-A/fex/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Enters single-one-time mode. Specifies the date and time that this occurrence should run. 48

63 Fault Collection and Suppression Configuring Fault Suppression for a FEX Step 8 Step 9 UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/fex/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2: UCS-A# scope fex 1 UCS-A/fex # scope fault-suppress-task task2 UCS-A/fex/fault-suppress-task # set fault-suppress-policy default-iom-maint UCS-A/fex/fault-suppress-task* # scope local-schedule UCS-A/fex/fault-suppress-task/local-schedule* # scope occurrence single-one-time UCS-A/fex/fault-suppress-task/local-schedule/single-one-time* # set date dec UCS-A/fex/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1: UCS-A# scope fex 1 UCS-A/fex # scope fault-suppress-task task1 UCS-A/fex/fault-suppress-task # set schedule monthly-maint UCS-A/fex/fault-suppress-task* # commit-buffer Viewing Suppressed Faults and Fault Suppression Tasks for a FEX Step 4 UCS-A# scope fex fex-num UCS-A/fex # show fault suppressed UCS-A/fex # scope fault-suppress-task name UCS-A/fex/fault-suppress-task # show detail expand Enters fex mode for the specified FEX. Displays the suppressed faults for the FEX. Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for a FEX: UCS-A# scope fex 1 UCS-A/fex # show fault suppressed Fault Suppress Task: Name Status Global Schedule Suppress Policy Name 49

64 Configuring Fault Suppression for a Server Fault Collection and Suppression task1 Active test_schedule1 Default FEX Phys Maint UCS-A/fex # The following example shows how to display the fault suppression task called task1: UCS-A# scope fex 1 UCS-A/fex # scope fault-suppress-task task1 UCS-A/fex/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default FEX Phys Maint UCS-A/fex/fault-suppress-task # Deleting Fault Suppression Tasks for a FEX UCS-A# scope fex fex-num UCS-A/fex # delete fault-suppress-task name UCS-A/fex # commit-buffer Enters fex mode for the specified FEX. Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1: UCS-A# scope fex 1 UCS-A/fex # delete fault-suppress-task task1 UCS-A/fex* # commit-buffer Configuring Fault Suppression for a Server Configuring Fault Suppression Tasks for a Server Using a Fixed Time Interval The default-server-maint suppression policy is selected by default. UCS-A# scope server [chassis-num/server-num dynamic-uuid] Enters server mode for the specified server. UCS-A/server # create fault-suppress-task name Creates a fault-suppress-task on the server, and enters the fault-suppress-task mode. 50

65 Fault Collection and Suppression Configuring Fault Suppression for a Server Step 4 UCS-A/server/fault-suppress-task # create local-schedule UCS-A/server/fault-suppress-task/local-schedule # create occurrence single-one-time This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Creates a local schedule and enters local-schedule mode. Creates a one-time occurrence, and enters single-one-time mode. Step 5 Step 6 Step 7 UCS-A/server/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds UCS-A/server/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/server/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task2 for the server, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope server 1/1 UCS-A/server # create fault-suppress-task task2 UCS-A/server/fault-suppress-task* # create local-schedule UCS-A/server/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/server/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/server/fault-suppress-task/local-schedule/single-one-time* # commit-buffer Configuring Fault Suppression Tasks for a Server using a Schedule The default-server-maint suppression policy is selected by default. UCS-A# scope server [chassis-num/server-num dynamic-uuid] UCS-A/server # create fault-suppress-task name Enters server mode for the specified server. Creates a fault-suppress-task on the server, and enters the fault-suppress-task mode. 51

66 Configuring Fault Suppression for a Server Fault Collection and Suppression This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Step 4 UCS-A/server/fault-suppress-task # set schedule name UCS-A/server/fault-suppress-task # commit-buffer Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Commits the transaction to the system configuration. The following example shows how to creates a fault suppression task called task1 for the server, apply the scheduler called weekly_maint to the task, and commit the transaction: UCS-A# scope server 1/1 UCS-A/server # create fault-suppress-task task1 UCS-A/server/fault-suppress-task* # set schedule weekly_maint UCS-A/server/fault-suppress-task* # commit-buffer Modifying Fault Suppression Tasks for a Server UCS-A# scope server [chassis-num/server-num dynamic-uuid] Enters server mode for the specified server. UCS-A/server # scope fault-suppress-task name UCS-A/server/fault-suppress-task # set schedule name Enters fault-suppress-task mode. Note To apply a different schedule to the fault suppression task, go to. To change the fixed time interval of the fault suppression task, go to Step 4. Applies a different schedule. 52

67 Fault Collection and Suppression Configuring Fault Suppression for a Server Step 4 UCS-A/server/fault-suppress-task # scope local-schedule Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. Enters local-schedule mode. Step 5 Step 6 Step 7 Step 8 UCS-A/server/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/server/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds UCS-A/server/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/server/fault-suppress-task/local-schedule/single-one-time # commit-buffer Enters single-one-time mode. Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2: UCS-A# scope server 1/1 UCS-A/server # scope fault-suppress-task task2 UCS-A/server/fault-suppress-task # scope local-schedule UCS-A/server/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/server/fault-suppress-task/local-schedule/single-one-time # set date dec UCS-A/server/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1: UCS-A# scope server 1/1 UCS-A/server # scope fault-suppress-task task1 UCS-A/server/fault-suppress-task # set schedule monthly-maint UCS-A/server/fault-suppress-task* # commit-buffer 53

68 Configuring Fault Suppression for a Server Fault Collection and Suppression Creating a Schedule UCS-A# scope system UCS-A /system # create scheduler sched-name UCS-A /system/scheduler # commit-buffer Enters system mode. Creates a scheduler and enters scheduler mode. Commits the transaction to the system configuration. The following example creates a scheduler called maintenancesched and commits the transaction: UCS-A# scope system UCS-A /system # create scheduler maintenancesched UCS-A /system/scheduler* # commit-buffer UCS-A /system/scheduler # What to Do Next Create a one time occurrence or recurring occurrence for the schedule. Viewing Suppressed Faults and Fault Suppression Tasks for a Server Step 4 UCS-A# scope server [chassis-num/server-num dynamic-uuid] UCS-A/server # show fault suppressed UCS-A/server # scope fault-suppress-task name UCS-A/server/fault-suppress-task # show detail expand Enters server mode for the specified server. Displays the suppressed faults for the server. Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for a server: UCS-A# scope server 1/1 UCS-A/server # show fault suppressed Fault Suppress Task: Name Status Global Schedule Suppress Policy Name

69 Fault Collection and Suppression Configuring Fault Suppression for a Service Profile task1 Active test_schedule1 Default Server Maint UCS-A/server # The following example shows how to display the fault suppression task called task1: UCS-A# scope server 1/1 UCS-A/server # scope fault-suppress-task task1 UCS-A/server/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Server Maint UCS-A/server/fault-suppress-task # Deleting Fault Suppression Tasks for a Server UCS-A# scope server [chassis-num/server-num dynamic-uuid] UCS-A/server # delete fault-suppress-task name UCS-A/server # commit-buffer Enters server mode for the specified server. Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1: UCS-A# scope server 1/1 UCS-A/server # delete fault-suppress-task task1 UCS-A/server* # commit-buffer Configuring Fault Suppression for a Service Profile Configuring Fault Suppression Tasks for a Service Profile Using a Fixed Time Interval The default-server-maint suppression policy is selected by default. UCS-A# scope org org-name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. 55

70 Configuring Fault Suppression for a Service Profile Fault Collection and Suppression UCS-A /org # scope service-profile profile-name UCS-A /org/service-profile # create fault-suppress-task name Enters service profile organization mode for the service profile. Creates a fault-suppress-task on the chassis, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Step 4 UCS-A/org/service-profile/fault-suppress-task # create local-schedule Step 5 UCS-A/org/service-profile/fault-suppress-task/local-schedule # create occurrence single-one-time Creates a local schedule and enters local-schedule mode. Creates a one-time occurrence, and enters single-one-time mode. Step 6 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 7 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 8 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. 56

71 Fault Collection and Suppression Configuring Fault Suppression for a Service Profile The following example shows how to create a fault suppression task called task2 under the accounting service profile, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # create fault-suppress-task task2 UCS-A/org/service-profile/fault-suppress-task* # create local-schedule UCS-A/org/service-profile/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time* # commit-buffer Configuring Fault Suppression Tasks for a Service Profile Using a Schedule The default-server-maint suppression policy is selected by default. UCS-A# scope org org-name UCS-A /org # scope service-profile profile-name UCS-A /org/service-profile # create fault-suppress-task name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters service profile organization mode for the service profile. Creates a fault-suppress-task on the chassis, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. Step 4 Step 5 UCS-A/org/service-profile/fault-suppress-task # set schedule name UCS-A/org/service-profile/fault-suppress-task # commit-buffer Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task1 under the accounting service profile, apply the scheduler called weekly_maint to the task, and commit the transaction: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # create fault-suppress-task task1 UCS-A/org/service-profile/fault-suppress-task* # set schedule weekly_maint UCS-A/org/service-profile/fault-suppress-task* # commit-buffer 57

72 Configuring Fault Suppression for a Service Profile Fault Collection and Suppression Modifying Fault Suppression Tasks for a Service Profile UCS-A# scope org org-name UCS-A /org # scope service-profile profile-name UCS-A/org/service-profile # scope fault-suppress-task name Step 4 UCS-A/org/service-profile/fault-suppress-task # set schedule name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters service profile organization mode for the service profile. Enters fault-suppress-task mode. Note To apply a different schedule to the fault suppression task, go to Step 4. To change the fixed time interval of the fault suppression task, go to Step 5. Applies a different schedule. 58

73 Fault Collection and Suppression Configuring Fault Suppression for a Service Profile Step 5 UCS-A/org/service-profile/fault-suppress-task # scope local-schedule Step 6 UCS-A/org/service-profile/fault-suppress-task/local-schedule # scope occurrence single-one-time Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. Enters local-schedule mode. Enters single-one-time mode. Step 7 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds Step 8 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} Step 9 UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # scope fault-suppress-task task2 UCS-A/org/service-profile/fault-suppress-task # scope local-schedule UCS-A/org/service-profile/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time # set date dec

74 Configuring Fault Suppression for a Service Profile Fault Collection and Suppression UCS-A/org/service-profile/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # scope fault-suppress-task task1 UCS-A/org/service-profile/fault-suppress-task # set schedule monthly-maint UCS-A/org/service-profile/fault-suppress-task* # commit-buffer Viewing Suppressed Faults and Fault Suppression Tasks for a Service Profile UCS-A# scope org org-name UCS-A /org # scope service-profile profile-name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters service profile organization mode for the service profile. Step 4 Step 5 UCS-A/org/service-profile # show fault suppressed UCS-A/org/service-profile # scope fault-suppress-task name UCS-A/org/service-profile/fault-suppress-task # show detail expand Displays the suppressed faults for the server. Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for a service profile: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # show fault suppressed UCS-A/org/service-profile # Fault Suppress Task: Name Status Global Schedule Suppress Policy Name task1 Active test_schedule1 Default Server Maint UCS-A/org/service-profile # The following example shows how to display the fault suppression task called task1: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # scope fault-suppress-task task1 UCS-A/org/service-profile/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Server Maint UCS-A/org/service-profile/fault-suppress-task # 60

75 Fault Collection and Suppression Configuring Fault Suppression for an Organization Deleting Fault Suppression Tasks for a Service Profile Step 4 UCS-A# scope org org-name UCS-A /org # scope service-profile profile-name UCS-A/org/service-profile # delete fault-suppress-task name UCS-A/org/service-profile # commit-buffer Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters service profile organization mode for the service profile. Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1: UCS-A# scope org / UCS-A/org # scope service-profile accounting UCS-A/org/service-profile # delete fault-suppress-task task1 UCS-A/org/service-profile* # commit-buffer Configuring Fault Suppression for an Organization Configuring Fault Suppression Tasks for an Organization Using a Fixed Time Interval The default-server-maint suppression policy is selected by default. UCS-A# scope org org-name UCS-A/org # create fault-suppress-task name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Creates a fault-suppress-task for the organization, and enters fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. 61

76 Configuring Fault Suppression for an Organization Fault Collection and Suppression (period), and you cannot change this name after the object is saved. Step 4 UCS-A/org/fault-suppress-task # create local-schedule UCS-A/org/fault-suppress-task/local-schedule # create occurrence single-one-time Creates a local schedule and enters local-schedule mode. Creates a one-time occurrence, and enters single-one-time mode. Step 5 Step 6 Step 7 UCS-A/org/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds UCS-A/org/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/org/fault-suppress-task/local-schedule/single-one-time # commit-buffer Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task2 under the Root organization, set the start date to January 1, 2013 at 11:00, and commit the transaction: UCS-A# scope org / UCS-A/org # create fault-suppress-task task2 UCS-A/org/fault-suppress-task* # create local-schedule UCS-A/org/fault-suppress-task/local-schedule* # create occurrence single-one-time UCS-A/org/fault-suppress-task/local-schedule/single-one-time* # set date jan UCS-A/org/fault-suppress-task/local-schedule/single-one-time* # commit-buffer Configuring Fault Suppression Tasks for an Organization Using a Schedule The default-server-maint suppression policy is selected by default. UCS-A# scope org org-name UCS-A/org # create fault-suppress-task name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Creates a fault-suppress-task for the organization, and enters the fault-suppress-task mode. This name can be between 1 and 16 alphanumeric characters. You cannot use spaces or any special characters other than - (hyphen), _ (underscore), : (colon), and. (period), and you cannot change this name after the object is saved. 62

77 Fault Collection and Suppression Configuring Fault Suppression for an Organization Step 4 UCS-A/org/fault-suppress-task # set schedule name UCS-A/org/fault-suppress-task # commit-buffer Specifies the schedule that you want to use. Note The schedule must exist before you can use it in a fault suppression task. For more information about creating schedules, see Creating a Schedule, on page 54. Commits the transaction to the system configuration. The following example shows how to create a fault suppression task called task1 under the Root organization, apply the scheduler called weekly_maint to the task, and commit the transaction: UCS-A# scope org / UCS-A/org # create fault-suppress-task task1 UCS-A/org/fault-suppress-task* # set schedule weekly_maint UCS-A/org/fault-suppress-task* # commit-buffer Modifying Fault Suppression Tasks for an Organization UCS-A# scope org org-name UCS-A/org # scope fault-suppress-task name UCS-A/org/fault-suppress-task # set schedule name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters fault-suppress-task mode. Note To apply a different schedule to the fault suppression task, go to Step 3. To change the fixed time interval of the fault suppression task, go to Step 4. Applies a different schedule. Note If you change from a fixed time interval to a schedule, the fixed time interval is deleted when you commit. If you change from a schedule to a fixed time interval, the reference to the schedule is cleared when you commit. 63

78 Configuring Fault Suppression for an Organization Fault Collection and Suppression Step 4 UCS-A/org/fault-suppress-task # scope local-schedule Enters local-schedule mode. Step 5 Step 6 Step 7 Step 8 UCS-A/org/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/org/fault-suppress-task/local-schedule/single-one-time # set date month day-of-month year hour minute seconds UCS-A/org/fault-suppress-task/local-schedule/single-one-time # set max-duration {none num-of-days num-of-hours num-of-minutes num-of-seconds} UCS-A/org/fault-suppress-task/local-schedule/single-one-time # commit-buffer Enters single-one-time mode. Specifies the date and time that this occurrence should run. Specifies the maximum length of time that this task can run. To run the task until it is manually stopped, enter none or omit this step. Commits the transaction to the system configuration. The following example shows how to change the date and the fault suppression policy of the fault suppression task called task2: UCS-A# scope org / UCS-A/org # scope fault-suppress-task task2 UCS-A/org/fault-suppress-task* # scope local-schedule UCS-A/org/fault-suppress-task/local-schedule # scope occurrence single-one-time UCS-A/org/fault-suppress-task/local-schedule/single-one-time # set date dec UCS-A/org/fault-suppress-task/local-schedule/single-one-time* # commit-buffer The following example shows how to apply a different schedule to the fault suppression task called task1: UCS-A# scope org UCS-A/org # scope fault-suppress-task task1 UCS-A/org/fault-suppress-task # set schedule monthly-maint UCS-A/org/fault-suppress-task* # commit-buffer Viewing Suppressed Faults and Fault Suppression Tasks for an Organization UCS-A# scope org org-name UCS-A/org # show fault suppressed UCS-A/org # scope fault-suppress-task name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Displays the suppressed faults for the organization Note Only faults owned by the selected component are displayed. Enters fault-suppress-task mode. 64

79 Fault Collection and Suppression Configuring Fault Suppression for an Organization Step 4 UCS-A/org/fault-suppress-task # show detail expand Displays the schedule or fixed time interval for the task. The following example shows how to display the suppressed faults for an organization: UCS-A# scope org Finance UCS-A/org # show fault suppressed UCS-A/org # Fault Suppress Task: Name Status Global Schedule Suppress Policy Name task1 Active test_schedule1 Default Server Maint UCS-A/org # The following example shows how to display the fault suppression task called task1: UCS-A# scope org Finance UCS-A/org # scope fault-suppress-task task1 UCS-A/org/fault-suppress-task # show detail expand Fault Suppress Task: Name: task1 Status: Active Global Schedule: test_schedule1 Suppress Policy Name: Default Server Maint UCS-A/org/fault-suppress-task # Deleting Fault Suppression Tasks for an Organization UCS-A# scope org org-name UCS-A/org # delete fault-suppress-task name UCS-A/org # commit-buffer Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Deletes the specified fault suppression task. Commits the transaction to the system configuration. The following example shows how to delete the fault suppression task called task1: UCS-A# scope org / UCS-A/org # delete fault-suppress-task task1 UCS-A/org* # commit-buffer 65

80 Configuring Fault Suppression for an Organization Fault Collection and Suppression 66

81 CHAPTER 9 SNMP Configuration SNMP Overview, page 67 SNMP Functional Overview, page 67 SNMP Notifications, page 68 SNMP Security Levels and Privileges, page 68 Supported Combinations of SNMP Security Models and Levels, page 69 SNMPv3 Security Features, page 70 SNMP Support, page 70 Configuring SNMP, page 71 SNMP Overview 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 for monitoring and managing devices in a network. 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 Cisco UCS, the managed device that maintains the data for Cisco UCS, and reports the data as needed to the SNMP manager. Cisco UCS includes the agent and a collection of MIBs. To enable the SNMP agent and create the relationship between the manager and agent, enable and configure SNMP in Cisco UCS Manager. A managed information base (MIB) The collection of managed objects on the SNMP agent. Cisco UCS release 1.4(1) and higher supports a larger number of MIBs than earlier releases. 67

82 SNMP Notifications SNMP Configuration Cisco UCS supports SNMPv1, SNMPv2c and SNMPv3. Both SNMPv1 and SNMPv2c use a community-based form of security. SNMP is defined in the following: RFC 3410 ( RFC 3411 ( RFC 3412 ( RFC 3413 ( RFC 3414 ( RFC 3415 ( RFC 3416 ( RFC 3417 ( RFC 3418 ( RFC 3584 ( SNMP Notifications A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events. Cisco UCS Manager generates SNMP notifications as either traps or informs. Traps are less reliable than informs because the SNMP manager does not send any acknowledgment when it receives a trap, and Cisco UCS Manager cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response Protocol Data Unit (PDU). If the Cisco UCS Manager does not receive the PDU, it can send the inform request again. SNMP Security Levels and Privileges SNMPv1, SNMPv2c, and SNMPv3 each represent a different security model. The security model combines with the selected security level to determine the security mechanism applied when the SNMP message is processed. The security level determines the privileges required to view the message associated with an SNMP trap. The privilege level determines whether the message requires protection from disclosure or whether the message is authenticated. The supported security level depends on which security model is implemented. SNMP security levels support one or more of the following privileges: noauthnopriv No authentication or encryption authnopriv Authentication but no encryption authpriv Authentication and encryption 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 68

83 SNMP Configuration Supported Combinations of SNMP Security Models and Levels 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. Supported Combinations of SNMP Security Models and Levels The following table identifies the combinations of security models and levels. Table 2: SNMP Security Models and Levels Model Level Authentication Encryption What Happens v1 noauthnopriv Community string No Uses a community string match for authentication. v2c noauthnopriv Community string No Uses a community string match for authentication. v3 noauthnopriv Username No Uses a username match for authentication. v3 authnopriv HMAC-MD5 or HMAC-SHA No Provides authentication based on the Hash-Based Message Authentication Code (HMAC) Message Digest 5 (MD5) algorithm or the HMAC Secure Hash Algorithm (SHA). v3 authpriv HMAC-MD5 or HMAC-SHA DES Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption in addition to authentication based on the Cipher Block Chaining (CBC) DES (DES-56) standard. 69

84 SNMPv3 Security Features SNMP Configuration SNMPv3 Security Features SNMPv3 provides secure access to devices through a combination of authenticating and encrypting frames over the network. SNMPv3 authorizes only configured users to perform management operations and encrypts SNMP messages. The SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services: Message integrity Ensures that messages are not altered or destroyed in an unauthorized manner, and that data sequences are not altered beyond what can occur non-maliciously. Message origin authentication Ensures that the identity of a message originator is verifiable. Message confidentiality and encryption Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes. SNMP Support Cisco UCS provides the following support for SNMP: Support for MIBs Cisco UCS supports read-only access to MIBs. For information about the specific MIBs available for Cisco UCS and where you can obtain them, see the for B-series servers, and C-Series_MIBRef.html C-series servers. Authentication Protocols for SNMPv3 Users Cisco UCS supports the following authentication protocols for SNMPv3 users: HMAC-MD5-96 (MD5) HMAC-SHA-96 (SHA) AES Privacy Protocol for SNMPv3 Users Cisco UCS uses Advanced Encryption Standard (AES) as one of the privacy protocols for SNMPv3 message encryption and conforms with RFC The privacy password, or priv option, offers a choice of DES or 128-bit AES encryption for SNMP security encryption. If you enable AES-128 configuration and include a privacy password for an SNMPv3 user, Cisco UCS Manager uses the privacy password to generate a 128-bit AES key. The AES privacy password can have a minimum of eight characters. If the passphrases are specified in clear text, you can specify a maximum of 64 characters. 70

85 SNMP Configuration Configuring SNMP Configuring SNMP Enabling SNMP and Configuring SNMP Properties SNMP messages from a Cisco UCS domain display the fabric interconnect name rather than the system name. Step 4 Step 5 Step 6 Step 7 UCS-A# scope monitoring UCS-A /monitoring # enable snmp UCS-A /monitoring # set snmp community UCS-A /monitoring # Enter a snmp community: community-name UCS-A /monitoring # set snmp syscontact system-contact-name UCS-A /monitoring # set snmp syslocation system-location-name UCS-A /monitoring # commit-buffer Enters monitoring mode. Enables SNMP. Enters snmp community mode. Specifies SNMP community. Use the community name as a password. The community name can be any alphanumeric string up to 32 characters. Specifies the system contact person responsible for the SNMP. The system contact name can be any alphanumeric string up to 255 characters, such as an address or name and telephone number. Specifies the location of the host on which the SNMP agent (server) runs. The system location name can be any alphanumeric string up to 512 characters. Commits the transaction to the system configuration. The following example enables SNMP, configures an SNMP community named SnmpCommSystem2, configures a system contact named contactperson, configures a contact location named systemlocation, and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # enable snmp UCS-A /monitoring* # set snmp community UCS-A /monitoring* # Enter a snmp community: SnmpCommSystem2 UCS-A /monitoring* # set snmp syscontact contactperson1 UCS-A /monitoring* # set snmp syslocation systemlocation UCS-A /monitoring* # commit-buffer UCS-A /monitoring # What to Do Next Create SNMP traps and users. 71

86 Creating an SNMP Trap SNMP Configuration Creating an SNMP Trap UCS-A# scope monitoring UCS-A /monitoring # enable snmp Enters monitoring mode. Enables SNMP. UCS-A /monitoring # create snmp-trap {hostname ip-addr ip6-addr} Creates an SNMP trap host with the specified host name, IPv4 address, or IPv6 address. The host name can be a fully qualified domain name of an IPv4 address. Step 4 UCS-A /monitoring/snmp-trap # set community community-name Specifies the SNMP community name to be used for the SNMP trap. Step 5 Step 6 UCS-A /monitoring/snmp-trap # set port port-num UCS-A /monitoring/snmp-trap # set version {v1 v2c v3} Specifies the port to be used for the SNMP trap. Specifies the SNMP version and model used for the trap. Step 7 UCS-A /monitoring/snmp-trap # set notification type {traps informs} (Optional) The type of trap to send. This can be: traps if you select v2c or v3 for the version. informs if you select v2c for the version. Note An inform notification can be sent only if you select v2c for the version. Step 8 UCS-A /monitoring/snmp-trap # set v3 privilege {auth noauth priv} (Optional) If you select v3 for the version, the privilege associated with the trap can be auth Authentication but no encryption noauth No authentication or encryption priv Authentication and encryption Step 9 UCS-A /monitoring/snmp-trap # commit-buffer Commits the transaction to the system configuration. The following example enables SNMP, creates an SNMP trap using an IPv4 address, specifies that the trap will use the SnmpCommSystem2 community on port 2, sets the version to v3, sets the notification type to traps, sets the v3 privilege to priv, and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # enable snmp 72

87 SNMP Configuration Deleting an SNMP Trap UCS-A /monitoring* # create snmp-trap UCS-A /monitoring/snmp-trap* # set community SnmpCommSystem2 UCS-A /monitoring/snmp-trap* # set port 2 UCS-A /monitoring/snmp-trap* # set version v3 UCS-A /monitoring/snmp-trap* # set notificationtype traps UCS-A /monitoring/snmp-trap* # set v3 privilege priv UCS-A /monitoring/snmp-trap* # commit-buffer UCS-A /monitoring/snmp-trap # The following example enables SNMP, creates an SNMP trap using an IPv6 address, specifies that the trap will use the SnmpCommSystem3 community on port 2, sets the version to v3, sets the notification type to traps, sets the v3 privilege to priv, and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # enable snmp UCS-A /monitoring* # create snmp-trap 2001::1 UCS-A /monitoring/snmp-trap* # set community SnmpCommSystem3 UCS-A /monitoring/snmp-trap* # set port 2 UCS-A /monitoring/snmp-trap* # set version v3 UCS-A /monitoring/snmp-trap* # set notificationtype traps UCS-A /monitoring/snmp-trap* # set v3 privilege priv UCS-A /monitoring/snmp-trap* # commit-buffer UCS-A /monitoring/snmp-trap # Deleting an SNMP Trap UCS-A# scope monitoring UCS-A /monitoring # delete snmp-trap {hostname ip-addr} UCS-A /monitoring # commit-buffer Enters monitoring mode. Deletes the specified SNMP trap host with the specified hostname or IP address. Commits the transaction to the system configuration. The following example deletes the SNMP trap at IP address and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # delete snmp-trap UCS-A /monitoring* # commit-buffer UCS-A /monitoring # Creating an SNMPv3 User UCS-A# scope monitoring UCS-A /monitoring # enable snmp Enters monitoring mode. Enables SNMP. 73

88 Deleting an SNMPv3 User SNMP Configuration UCS-A /monitoring # create snmp-user user-name Creates the specified SNMPv3 user. An SNMP username cannot be the same as a local username. Choose an SNMP username that does not match a local username. Step 4 Step 5 Step 6 Step 7 Step 8 UCS-A /monitoring/snmp-user # set aes-128 {no yes} UCS-A /monitoring/snmp-user # set auth {md5 sha} UCS-A /monitoring/snmp-user # set password UCS-A /monitoring/snmp-user # set priv-password UCS-A /monitoring/snmp-user # commit-buffer Enables or disables the use of AES-128 encryption. Specifies the use of MD5 or DHA authentication. Specifies the user password. After you enter the set password command, you are prompted to enter and confirm the password. Specifies the user privacy password. After you enter the set priv-password command, you are prompted to enter and confirm the privacy password. Commits the transaction to the system configuration. The following example enables SNMP, creates an SNMPv3 user named snmp-user14, disables AES-128 encryption, specifies the use of MD5 authentication, sets the password and privacy password, and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # enable snmp UCS-A /monitoring* # create snmp-user snmp-user14 UCS-A /monitoring/snmp-user* # set aes-128 no UCS-A /monitoring/snmp-user* # set auth md5 UCS-A /monitoring/snmp-user* # set password Enter a password: Confirm the password: UCS-A /monitoring/snmp-user* # set priv-password Enter a password: Confirm the password: UCS-A /monitoring/snmp-user* # commit-buffer UCS-A /monitoring/snmp-user # Deleting an SNMPv3 User UCS-A# scope monitoring UCS-A /monitoring # delete snmp-user user-name Enters monitoring mode. Deletes the specified SNMPv3 user. 74

89 SNMP Configuration Deleting an SNMPv3 User UCS-A /monitoring # commit-buffer Commits the transaction to the system configuration. The following example deletes the SNMPv3 user named snmp-user14 and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # delete snmp-user snmp-user14 UCS-A /monitoring* # commit-buffer UCS-A /monitoring # 75

90 Deleting an SNMPv3 User SNMP Configuration 76

91 CHAPTER 10 Statistics Collection Policy Configuration Statistics Collection Policy, page 77 Configuring a Statistics Collection Policy, page 78 Statistics Collection Policy A statistics collection policy defines how frequently statistics are collected (collection interval) and how frequently the statistics are reported (reporting interval). Reporting intervals are longer than collection intervals so that multiple statistical data points can be collected during the reporting interval. This provides Cisco UCS Manager with sufficient data to calculate and report minimum, maximum, and average values. For NIC statistics, Cisco UCS Manager displays the average, minimum, and maximum of the change since the last collection of statistics. If the values are 0, there has been no change since the last collection. Statistics can be collected and reported for the following five functional areas of the Cisco UCS system: Adapter Statistics related to the adapters Chassis Statistics related to the chassis Host This policy is a placeholder for future support Port Statistics related to the ports, including server ports, uplink Ethernet ports, and uplink Fibre Channel ports Server Statistics related to servers Note Cisco UCS Manager has one default statistics collection policy for each of the five functional areas. You cannot create additional statistics collection policies and you cannot delete the existing default policies. You can only modify the default policies. The values that are displayed for delta counter in Cisco UCS Manager are calculated as the difference between the last two samples in a collection interval. In addition, Cisco UCS Manager displays the average, minimum, and maximum delta values of the samples in the collection interval. 77

92 Configuring a Statistics Collection Policy Statistics Collection Policy Configuration Configuring a Statistics Collection Policy UCS-A# scope monitoring Enters monitoring mode. UCS-A/monitoring # scope stats-collection-policy {adapter chassis host port server} Enters statistics collection policy mode for the specified policy type. Step 4 Step 5 UCS-A /monitoring/stats-collection-policy # set collection-interval {1minute 2minutes 30seconds 5minutes} UCS-A /monitoring/stats-collection-policy # set reporting-interval {15minutes 30minutes 60minutes} UCS-A /monitoring/stats-collection-policy # commit-buffer Specifies the interval at which statistics are collected from the system. Specifies the interval at which collected statistics are reported. Commits the transaction to the system configuration. The following example creates a statistics collection policy for ports, sets the collection interval to one minute, the reporting interval to 30 minutes, and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope stats-collection-policy port UCS-A /monitoring/stats-collection-policy* # set collection-interval 1minute UCS-A /monitoring/stats-collection-policy* # set reporting-interval 30minutes UCS-A /monitoring/stats-collection-policy* # commit-buffer UCS-A /monitoring/stats-collection-policy # 78

93 CHAPTER 11 Call Home and Smart Call Home Configuration Call Home in UCS Overview, page 79 Call Home Considerations and Guidelines, page 81 Cisco UCS Faults and Call Home Severity Levels, page 82 Cisco Smart Call Home, page 83 Anonymous Reporting, page 85 Configuring Call Home, page 85 Enabling Call Home, page 87 Disabling Call Home, page 88 Configuring System Inventory Messages, page 88 Configuring Call Home Profiles, page 90 Sending a Test Call Home Alert, page 93 Configuring Call Home Policies, page 94 Configuring Anonymous Reporting, page 97 Configuring Smart Call Home, page 99 Call Home in UCS Overview Call Home provides an -based notification for critical system policies. A range of message formats are available for compatibility with pager services or XML-based automated parsing applications. You can use this feature to page a network support engineer, a Network Operations Center, or use Cisco Smart Call Home services to generate a case with the Technical Assistance Center. The Call Home feature can deliver alert messages containing information about diagnostics and environmental faults and events. The Call Home feature can deliver alerts to multiple recipients, referred to as Call Home destination profiles. Each profile includes configurable message formats and content categories. A predefined destination profile is provided for sending alerts to the Cisco TAC, but you also can define your own destination profiles. 79

94 Call Home in UCS Overview Call Home and Smart Call Home Configuration When you configure Call Home to send messages, Cisco UCS Manager executes the appropriate CLI show command and attaches the command output to the message. Cisco UCS delivers Call Home messages in the following formats: Short text format which provides a one or two line description of the fault that is suitable for pagers or printed reports. Full text format which provides fully formatted message with detailed information that is 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. The XML format enables communication with the Cisco Systems Technical Assistance Center. For information about the faults that can trigger Call Home alerts, see the Cisco UCS Faults and Error Messages Reference. 80

95 Call Home and Smart Call Home Configuration Call Home Considerations and Guidelines The following figure shows the flow of events after a Cisco UCS fault is triggered in a system with Call Home configured: Figure 2: Flow of Events after a Fault is Triggered Call Home Considerations and Guidelines How you configure Call Home depends on how you intend to use the feature. The information you need to consider before you configure Call Home includes the following: 81

96 Cisco UCS Faults and Call Home Severity Levels Call Home and Smart Call Home Configuration Destination Profile You must configure at least one destination profile. The destination profile or profiles that you use depends upon whether the receiving entity is a pager, , or automated service such as Cisco Smart Call Home. If the destination profile uses message delivery, you must specify a Simple Mail Transfer Protocol (SMTP) server when you configure Call Home. Contact Information The contact , phone, and street address information should be configured so that the receiver can determine the origin of messages received from the Cisco UCS domain. Cisco Smart Call Home sends the registration to this address after you send a system inventory to begin the registration process. If an address includes special characters, such as # (hash), spaces, or & (ampersand), the server might not be able to deliver messages to that address. Cisco recommends that you use addresses which comply with RFC2821 and RFC2822 and include only 7bit ASCII characters. IP Connectivity to Server or HTTP Server The fabric interconnect must have IP connectivity to an server or the destination HTTP server. In a cluster configuration, both fabric interconnects must have IP connectivity. This connectivity ensures that the current, active fabric interconnect can send Call Home messages. The source of these messages is always the IP address of a fabric interconnect. The virtual IP address assigned to Cisco UCS Manager in a cluster configuration is never the source of the . Smart Call Home If Cisco Smart Call Home is used, the following are required: An active service contract must cover the device being configured. The customer ID associated with the Smart Call Home configuration in Cisco UCS must be the CCO (Cisco.com) account name associated with a support contract that includes Smart Call Home. Cisco UCS Faults and Call Home Severity Levels Because Call Home is present across several Cisco product lines, Call Home has its own standardized severity levels. The following table describes how the underlying Cisco UCS fault levels map to the Call Home severity levels. You need to understand this mapping when you configure the Level setting for Call Home profiles. Table 3: Mapping of Faults and Call Home Severity Levels Call Home Severity (9) Catastrophic (8) Disaster (7) Fatal Cisco UCS Fault N/A N/A N/A Call Home Meaning Network-wide catastrophic failure. Significant network impact. System is unusable. 82

97 Call Home and Smart Call Home Configuration Cisco Smart Call Home Call Home Severity (6) Critical (5) Major (4) Minor (3) Warning (2) Notification (1) Normal (0) debug Cisco UCS Fault Critical Major Minor Warning Info Clear N/A Call Home Meaning Critical conditions, immediate attention needed. Major conditions. Minor conditions. Warning conditions. Basic notifications and informational messages. Possibly independently insignificant. Normal event, signifying a return to normal state. Debugging messages. Cisco Smart Call Home Cisco Smart Call Home is a web application which leverages the Call Home feature of Cisco UCS. Smart Call Home offers proactive diagnostics and real-time alerts of critical system events, which results in higher network availability and increased operational efficiency. Smart Call Home is a secure connected 83

98 Cisco Smart Call Home Call Home and Smart Call Home Configuration service offered by Cisco Unified Computing Support Service and Cisco Unified Computing Mission Critical Support Service for Cisco UCS. Figure 3: Cisco Smart Call Home Features Note Using Smart Call Home requires the following: A Cisco.com ID associated with a corresponding Cisco Unified Computing Support Service or Cisco Unified Computing Mission Critical Support Service contract for your company. Cisco Unified Computing Support Service or Cisco Unified Computing Mission Critical Support Service for the device to be registered. You can configure and register Cisco UCS Manager to send Smart Call Home alerts to either the Smart Call Home System or the secure Transport Gateway. alerts sent to the secure Transport Gateway are forwarded to the Smart Call Home System using HTTPS. Note For security reasons, we recommend using the Transport Gateway option. The Transport Gateway can be downloaded from Cisco.com. To configure Smart Call Home, do the following: Enable the Smart Call Home feature. 84

99 Call Home and Smart Call Home Configuration Anonymous Reporting Configure the contact information. Configure the information. Configure the SMTP server information. Configure the default CiscoTAC-1 profile. Send a Smart Call Home inventory message to start the registration process. Ensure that the Cisco.com ID you plan to use as the Call Home Customer ID for the Cisco UCS domain has the contract numbers from the registration added to its entitlements. You can update the ID in the Account Propertiesunder Additional Access in the Profile Manager on Cisco.com. Anonymous Reporting After you upgrade to the latest release of Cisco UCS Manager, by default, you are prompted with a dialog box to enable anonymous reporting. To enable anonymous reporting, you need to enter details about the SMTP server and the data file that is stored on the fabric switch. This report is generated every seven days and is compared with the previous version of the same report. When Cisco UCS Manager identifies changes in the report, the report is sent as an . Configuring Call Home Step 4 Step 5 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # enable UCS-A /monitoring/callhome # set contact name UCS-A /monitoring/callhome # set -addr Enters monitoring mode. Enters monitoring call home mode. Enables Call Home. Specifies the name of the main Call Home contact person. Specifies the address of the main Call Home contact person. Note If an address includes special characters, such as # (hash), spaces, or & (ampersand), the server might not be able to deliver messages to that address. Cisco recommends that you use addresses which comply with RFC2821 and RFC2822 and include only 7bit ASCII characters. 85

100 Configuring Call Home Call Home and Smart Call Home Configuration Step 6 Step 7 Step 8 Step UCS-A /monitoring/callhome # set phone-contact phone-num UCS-A /monitoring/callhome # set street-address street-addr UCS-A /monitoring/callhome # set customer-id id-num UCS-A /monitoring/callhome # set contract-id id-num UCS-A /monitoring/callhome # set site-id id-num UCS-A /monitoring/callhome # set from- -addr UCS-A /monitoring/callhome # set reply-to- -addr UCS-A /monitoring/callhome # set hostname {hostname ip-addr ip6-addr} UCS-A /monitoring/callhome # set port port-num UCS-A /monitoring/callhome # set throttling {off on} Specifies the phone number of the main Call Home contact person. The phone number must be in international format, starting with a + (plus sign) and a country code. Specifies the street address of the main Call Home contact person. Enter up to 255 ASCII characters. Specifies the CCO identification number that includes the contract numbers for the support contract in its entitlements. The number can be up to 255 alphanumeric characters in free format. Specifies the contract identification number from the service agreement. The number can be up to 255 alphanumeric characters in free format. Specifies the site identification number from the service agreement. The number can be up to 255 alphanumeric characters in free format. Specifies the address to use for the From field in Call Home messages. Specifies the address to use for the Reply To field in Call Home messages. Specifies the hostname, IPv4 or IPv6 address of the SMTP server that Call Home uses to send messages. Specifies the SMTP server port that Call Home uses to send messages. Valid port numbers are 1 to Enables or disables Call Home throttling. When enabled, throttling prevents too many Call Home messages from being sent for the same event. By default, throttling is enabled. 6 UCS-A /monitoring/callhome # set Specifies the urgency level for Call Home messages. urgency {alerts critical debugging In the context of a large UCS deployment with several emergencies errors information pairs of fabric interconnects, the urgency level potentially notifications warnings} allows you to attach significance to Call Home messages from one particular Cisco UCS domain versus another. In the context of a small UCS deployment involving only two fabric interconnects, the urgency level holds little meaning. 7 UCS-A /monitoring/callhome # commit-buffer Commits the transaction to the system configuration. 86

101 Call Home and Smart Call Home Configuration Enabling Call Home The following example configures Call Home with and IPv4 hostname and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # enable UCS-A /monitoring/callhome* # set contact "Steve Jones" UCS-A /monitoring/callhome* # set admin@mycompany.com UCS-A /monitoring/callhome* # set phone-contact UCS-A /monitoring/callhome* # set street-address "123 N. Main Street, Anytown, CA, 99885" UCS-A /monitoring/callhome* # set customer-id UCS-A /monitoring/callhome* # set contract-id UCS-A /monitoring/callhome* # set site-id UCS-A /monitoring/callhome* # set from- person@mycompany.com UCS-A /monitoring/callhome* # set reply-to- person@mycompany.com UCS-A /monitoring/callhome* # set hostname UCS-A /monitoring/callhome* # set port 25 UCS-A /monitoring/callhome* # set throttling on UCS-A /monitoring/callhome* # set urgency information UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # The following example configures Call Home with and IPv6 hostname and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # enable UCS-A /monitoring/callhome* # set contact "Steve Jones" UCS-A /monitoring/callhome* # set admin@mycompany.com UCS-A /monitoring/callhome* # set phone-contact UCS-A /monitoring/callhome* # set street-address "123 N. Main Street, Anytown, CA, 99885" UCS-A /monitoring/callhome* # set customer-id UCS-A /monitoring/callhome* # set contract-id UCS-A /monitoring/callhome* # set site-id UCS-A /monitoring/callhome* # set from- person@mycompany.com UCS-A /monitoring/callhome* # set reply-to- person@mycompany.com UCS-A /monitoring/callhome* # set hostname 2001::25 UCS-A /monitoring/callhome* # set port 25 UCS-A /monitoring/callhome* # set throttling on UCS-A /monitoring/callhome* # set urgency information UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # Enabling Call Home Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # enable UCS-A /monitoring/callhome # commit-buffer Enters monitoring mode. Enters monitoring call home mode. Enables Call Home. Commits the transaction to the system configuration. The following example enables Call Home and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # enable 87

102 Disabling Call Home Call Home and Smart Call Home Configuration UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # Disabling Call Home Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # disable UCS-A /monitoring/callhome # commit-buffer Enters monitoring mode. Enters monitoring call home mode. Enables Call Home. Commits the transaction to the system configuration. The following example disables Call Home and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # disable UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # Configuring System Inventory Messages Configuring System Inventory Messages Step 4 Step 5 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope inventory UCS-A /monitoring/callhome/inventory # set send-periodically {off on} UCS-A /monitoring/callhome/inventory # set interval-days interval-num Enters monitoring mode. Enters monitoring call home mode. Enters monitoring call home inventory mode. Enables or disables the sending of inventory messages. When the on keyword is specified, inventory messages are automatically sent to the Call Home database. Specifies the time interval (in days) at which inventory messages will be sent. 88

103 Call Home and Smart Call Home Configuration Sending a System Inventory Message Step 6 Step 7 Step 8 UCS-A /monitoring/callhome/inventory # set timeofday-hour hour UCS-A /monitoring/callhome/inventory # set timeofday-minute minute UCS-A /monitoring/callhome/inventory # commit-buffer Specifies the hour (using 24-hour format) that inventory messages are sent. Specifies the number of minutes after the hour that inventory messages are sent. Commits the transaction to the system configuration. The following example configures Call Home system inventory messages and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # scope inventory UCS-A /monitoring/callhome/inventory* # set send-periodically on UCS-A /monitoring/callhome/inventory* # set interval-days 15 UCS-A /monitoring/callhome/inventory* # set timeofday-hour 21 UCS-A /monitoring/callhome/inventory* # set timeofday-minute 30 UCS-A /monitoring/callhome/inventory* # commit-buffer UCS-A /monitoring/callhome/inventory # Sending a System Inventory Message Use this procedure if you need to manually send a system inventory message outside of the scheduled messages. Note The system inventory message is sent only to those recipients defined in CiscoTAC-1 profile. Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope inventory UCS-A /monitoring/callhome/inventory # send Enters monitoring mode. Enters monitoring call home mode. Enters monitoring call home inventory mode. Sends the system inventory message to the Call Home database. The following example sends the system inventory message to the Call Home database: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope inventory UCS-A /monitoring/callhome/inventory* # send 89

104 Configuring Call Home Profiles Call Home and Smart Call Home Configuration Configuring Call Home Profiles Call Home Profiles Call Home profiles determine which alerts are sent to designated recipients. You can configure the profiles to send alerts for events and faults at a desired severity level and for specific alert groups that represent categories of alerts. You can also use these profiles to specify the format of the alert for a specific set of recipients and alert groups. Alert groups and Call Home profiles enable you to filter the alerts and ensure that a specific profile only receives certain categories of alerts. For example, a data center may have a hardware team that handles issues with fans and power supplies. This hardware team does not care about server POST failures or licensing issues. To ensure that the hardware team only receives relevant alerts, create a Call Home profile for the hardware team and check only the "environmental" alert group. By default, you must configure the Cisco TAC-1 profile. You can also create additional profiles to send alerts to one or more alert groups, when events occur at the level that you specify and provide the recipients with the appropriate amount of information about those alerts. For example, you may want to configure two profiles for faults with a major severity: A profile that sends an alert to the Supervisor alert group in the short text format. Members of this group receive a one- or two-line description of the fault that they can use to track the issue. A profile that sends an alert to the CiscoTAC alert group in the XML format. Members of this group receive a detailed message in the machine-readable format preferred by the Cisco Systems Technical Assistance Center. Call Home Alert Groups An alert group is a predefined subset of Call Home alerts. Alert groups allow you to select the set of Call Home alerts that you want to send to a predefined or custom Call Home profile. Cisco UCS Manager sends Call Home alerts to destinations in a destination profile only under the following conditions: If the Call Home alert belongs to one of the alert groups associated with that destination profile. If the alert has a Call Home message severity at or above the message severity set in the destination profile. Each alert that Cisco UCS Manager generates fits into a category represented by an alert group. The following table describes those alert groups: Alert Group Cisco TAC Diagnostic Environmental Description All critical alerts from the other alert groups destined for Smart Call Home. Events generated by diagnostics, such as the POST completion on a server. Events related to power, fan, and environment-sensing elements such as temperature alarms. 90

105 Call Home and Smart Call Home Configuration Configuring a Call Home Profile Configuring a Call Home Profile By default, you must configure the Cisco TAC-1 profile, However, you can also create additional profiles to send alerts to one or more specified groups when events occur at the level that you specify. UCS-A# scope monitoring UCS-A /monitoring # scope callhome Enters monitoring mode. Enters monitoring call home mode. Step 4 UCS-A /monitoring/callhome # create profile profile-name UCS-A /monitoring/callhome/profile # set level {critical debug disaster fatal major minor normal notification warning} Enters monitoring call home profile mode. Specifies the event level for the profile. Each profile can have its own unique event level. Cisco UCS faults that are greater than or equal to the event level will trigger this profile. Step 5 UCS-A /monitoring/callhome/profile # set alertgroups group-name ciscotac diagnostic environmental inventory license lifecycle linecard supervisor syslogport system test Specifies one or more groups that are alerted based on the profile. The group-name argument can be one or more of the following keywords entered on the same command line: Step 6 UCS-A /monitoring/callhome/profile # add alertgroups group-names (Optional) Adds one or more groups to the existing list of groups that are alerted based on the Call Home profile. 91

106 Deleting a Call Home Profile Call Home and Smart Call Home Configuration Step 7 Step 8 Step 9 0 UCS-A /monitoring/callhome/profile # set format {shorttxt xml} UCS-A /monitoring/callhome/profile # set maxsize id-num UCS-A /monitoring/callhome/profile # create destination -addr UCS-A /monitoring/callhome/profile/destination # commit-buffer Note You must use the add alertgroups command to add more alert groups to the existing alert group list. Using the set alertgroups command will replace any pre-existing alert groups with a new group list. Specifies the formatting method to use for the messages. Specifies the maximum size (in characters) of the message. Specifies the address to which Call Home alerts should be sent. Use multiple create destination commands in monitoring call home profile mode to specify multiple recipients. Use the delete destination command in monitoring call home profile mode to delete a specified recipient. Commits the transaction to the system configuration. The following example configures a Call Home profile and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # create profile TestProfile UCS-A /monitoring/callhome/profile* # set level normal UCS-A /monitoring/callhome/profile* # set alertgroups test diagnostic UCS-A /monitoring/callhome/profile* # set format xml UCS-A /monitoring/callhome/profile* # set maxsize UCS-A /monitoring/callhome/profile* # create destination admin@mycompany.com UCS-A /monitoring/callhome/profile/destination* # commit-buffer UCS-A /monitoring/callhome/profile/destination # Deleting a Call Home Profile UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # delete profile profile-name Enters monitoring mode. Enters monitoring call home mode. Deletes the specified profile. 92

107 Call Home and Smart Call Home Configuration Sending a Test Call Home Alert Step 4 UCS-A /monitoring/callhome # commit-buffer Commits the transaction to the system configuration. The following example deletes the Call Home profile named TestProfile and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # delete profile TestProfile UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # Sending a Test Call Home Alert Before You Begin Configure Call Home and a Call Home Profile. UCS-A# scope monitoring UCS-A /monitoring # scope callhome Enters monitoring mode. Enters monitoring call home mode. UCS-A /monitoring/callhome # send-test-alert {[alert-group {diagnostic Sends a test Call Home alert. The test Call Home alert must specify all alert-* parameters or Cisco environmental}] [alert-level {critical debug UCS Manager cannot generate the test message. The fatal major minor normal notify alert-* parameters include the following: warning}] [alert-message-type {conf diag env inventory syslog test}] alert-description Alert description [alert-message-subtype {delta full alert-group Alert group goldmajor goldminor goldnormal major minor nosubtype test}] [alert-description alert-level Event severity level description]} alert-message-type Message type alert-message-subtype Message subtype When a test Call Home alert is sent, Call Home responds as it would to any other alert and delivers it to the configured destination addresses. The following example sends a test Call Home alert to the configured destination address of the environmental alert group: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # send-test-alert alert-group diagnostic 93

108 Configuring Call Home Policies Call Home and Smart Call Home Configuration alert-level critical alert-message-type test alert-message-subtype major alert-description "This is a test alert" Configuring Call Home Policies Call Home Policies Call Home policies determine whether or not Call Home alerts are sent for a specific type of fault or system event. By default, Call Home is enabled to send alerts for certain types of faults and system events. Note You can configure Cisco UCS Manager not to process the default faults and system events. To disable alerts for a type of fault or event, you must first create a Call Home policy for that type and then disable the policy. Configuring a Call Home Policy Tip By default, alerts are sent for all critical system events. However, you can optionally configure Call Home policies to enable or disable sending alerts for other critical system events. UCS-A# scope monitoring UCS-A /monitoring # scope callhome Enters monitoring mode. Enters monitoring call home mode. Step 4 UCS-A /monitoring/callhome # create policy {equipment-inoperable fru-problem identity-unestablishable thermal-problem voltage-problem} UCS-A /monitoring/callhome/policy # {disabled enabled} Creates the specified policy and enters monitoring call home policy mode. Disables or enables the sending of alerts for the specified policy. Step 5 UCS-A /monitoring/callhome/policy # commit-buffer Commits the transaction to the system configuration. The following example creates a Call Home policy that disables the sending of alerts for system events pertaining to voltage problems and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # create policy voltage-problem UCS-A /monitoring/callhome/policy* # disabled 94

109 Call Home and Smart Call Home Configuration Disabling a Call Home Policy UCS-A /monitoring/callhome/policy* # commit-buffer UCS-A /monitoring/callhome/policy # Disabling a Call Home Policy Step 4 Step 5 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope policy {equipment-inoperable fru-problem identity-unestablishable thermal-problem voltage-problem} UCS-A /monitoring/callhome/policy # disable UCS-A /monitoring/callhome/policy # commit-buffer Enters monitoring mode. Enters monitoring call home mode. Enters monitoring call home policy mode for the specified policy. Disables the specified policy. Commits the transaction to the system configuration. The following example disables the Call Home policy named voltage-problem and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope policy voltage-problem UCS-A /monitoring/callhome/policy # disable UCS-A /monitoring/callhome/policy* # commit-buffer UCS-A /monitoring/callhome/policy # Enabling a Call Home Policy Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope policy {equipment-inoperable fru-problem identity-unestablishable thermal-problem voltage-problem} UCS-A /monitoring/callhome/policy # enable Enters monitoring mode. Enters monitoring call home mode. Enters monitoring call home policy mode for the specified policy. Enables the specified policy. 95

110 Deleting a Call Home Policy Call Home and Smart Call Home Configuration Step 5 UCS-A /monitoring/callhome/policy # commit-buffer Commits the transaction to the system configuration. The following example enables the Call Home policy named voltage-problem and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # scope policy voltage-problem UCS-A /monitoring/callhome/policy # enable UCS-A /monitoring/callhome/policy* # commit-buffer UCS-A /monitoring/callhome/policy # Deleting a Call Home Policy Step 4 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # delete policy {equipment-inoperable fru-problem identity-unestablishable thermal-problem voltage-problem} UCS-A /monitoring/callhome # commit-buffer Enters monitoring mode. Enters monitoring call home mode. Deletes the specified policy Commits the transaction to the system configuration. The following example deletes the Call Home policy named voltage-problem and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # delete policy voltage-problems UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # 96

111 Call Home and Smart Call Home Configuration Configuring Anonymous Reporting Configuring Anonymous Reporting Enabling Anonymous Reporting Step 4 UCS-A # scope monitoring UCS-A/monitoring # scope callhome UCS-A/monitoring/callhome # show anonymous-reporting UCS-A/monitoring/callhome # enable anonymous-reporting Enters monitoring mode. Enters monitoring call home mode. (Optional) Displays if anonymous reporting is enabled or disabled. Enables anonymous reporting on Smart Call Home. Step 5 UCS-A/monitoring/callhome # commit-buffer Commits the transaction to the system configuration. The following example shows how to enable anonymous reporting on the Call Home server: UCS-A # scope monitoring UCS-A/monitoring #scope callhome UCS-A/mnitoring/callhome # show anonymous-reporting Anonymous Reporting: Admin State Off UCS-A/monitoring/callhome* # enable anonymous-reporting UCS-A/monitoring/callhome # commit-buffer UCS-A/monitoring/callhome # show anonymous-reporting Anonymous Reporting: Admin State On Disabling Anonymous Reporting UCS-A # scope monitoring UCS-A/monitoring # scope callhome Enters monitoring mode. Enters monitoring call home mode. 97

112 Viewing Anonymous Reports Call Home and Smart Call Home Configuration Step 4 Step 5 UCS-A/monitoring/callhome # show anonymous-reporting UCS-A/monitoring/callhome # disable anonymous-reporting UCS-A/monitoring/callhome # commit-buffer (Optional) Displays if anonymous reporting is enabled or disabled. Disables anonymous reporting on the Smart Call Home server. Commits the transaction to the system configuration. The following example shows how to disable anonymous reporting on the Call Home server: UCS-A # scope monitoring UCS-A/monitoring # scope callhome UCS-A/mnitoring/callhome # show anonymous-reporting Anonymous Reporting: Admin State On UCS-A/monitoring/callhome* # disable anonymous-reporting UCS-A/monitoring/callhome # commit-buffer UCS-A/monitoring/callhome # show anonymous-reporting Anonymous Reporting: Admin State Off Viewing Anonymous Reports UCS-A # scope monitoring UCS-A/monitoring # scope callhome Enters monitoring mode. Enters monitoring call home mode. Step 4 Step 5 Step 6 UCS-A/monitoring/callhome # scope anonymous-reporting UCS-A/monitoring/callhome/anonymous-reporting # show detail UCS-A/monitoring/callhome/anonymous-reporting # show inventory UCS-A/monitoring/callhome/anonymous-reporting # show content Enters anonymous reporting mode. Displays the SMTP server address and server port. Displays the anonymous reporting information. Displays the anonymous report sample information. 98

113 Call Home and Smart Call Home Configuration Configuring Smart Call Home The following example shows how to display anonymous reports from the Call Home server: UCS-A # scope monitoring UCS-A/monitoring # scope callhome UCS-A/monitoring/callhome # scope anonymous-reporting UCS-A/monitoring/callhome/anonymous-reporting # show detail UCS-A/monitoring/callhome/anonymous-reporting # show inventory UCS-A/monitoring/callhome/anonymous-reporting # show content <anonymousdata> <discretedata smartcallhomecontract="false" ethernetmode="endhost" fcmode="endhost" disjointl2used="false" fabricfailoverused="false" numvnicadapttempl="3" numserviceprofiles="7" updatingsptemplused="false" initialsptemplused="true" lanconnpolicyused="true" sanconnpolicyused="false" updatingadapttemplused="false" initialadapttemplused="true" nummsoftvmnets="10" numofvms="3" discretefex="false" ucscentralconnected="false"/> <bladeunit chassisid="1" slotid="4".. Configuring Smart Call Home Configuring Smart Call Home Step 4 Step 5 Step 6 UCS-A# scope monitoring UCS-A /monitoring # scope callhome UCS-A /monitoring/callhome # enable UCS-A /monitoring/callhome # set contact name UCS-A /monitoring/callhome # set -addr UCS-A /monitoring/callhome # set phone-contact phone-num Enters monitoring mode. Enters monitoring call home mode. Enables Call Home. Cisco Smart Call Home sends the registration to this address. Specifies the address of the main Call Home contact person. Cisco Smart Call Home sends the registration to this address. Specifies the phone number of the main Call Home contact person. The phone number must be in 99

114 Configuring Smart Call Home Call Home and Smart Call Home Configuration Step 7 Step 8 Step UCS-A /monitoring/callhome # set street-address street-addr UCS-A /monitoring/callhome # set customer-id id-num UCS-A /monitoring/callhome # set contract-id id-num UCS-A /monitoring/callhome # set site-id id-num UCS-A /monitoring/callhome # set from- -addr UCS-A /monitoring/callhome # set reply-to- -addr UCS-A /monitoring/callhome # set hostname {hostname ip-addr} international format, starting with a + (plus sign) and a country code. Specifies the street address of the main Call Home contact person. Specifies the CCO identification number that includes the contract numbers for the support contract in its entitlements. The number can be up to 255 alphanumeric characters in free format. Specifies the contract identification number from the service agreement. The number can be up to 255 alphanumeric characters in free format. Specifies the site identification number from the service agreement. The number can be up to 255 alphanumeric characters in free format. Specifies the address to use for the From field in Call Home messages. Specifies the address to use for the Reply To field in Call Home messages. Specifies the hostname or IP address of the SMTP server that Call Home uses to send messages. 4 UCS-A /monitoring/callhome # set port port-num Specifies the SMTP server port that Call Home uses to send messages. Valid port numbers are 1 to UCS-A /monitoring/callhome # set throttling {off on} Enables or disables Call Home throttling. When enabled, throttling prevents too many Call Home messages from being sent for the same event. By default, throttling is enabled. 6 7 UCS-A /monitoring/callhome # set urgency {alerts critical debugging emergencies errors information notifications warnings} UCS-A /monitoring/callhome # commit-buffer Specifies the urgency level for Call Home messages. Commits the transaction to the system configuration. The following example configures Call Home and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring* # scope callhome UCS-A /monitoring/callhome* # enable UCS-A /monitoring/callhome* # set contact "Steve Jones" UCS-A /monitoring/callhome* # set admin@mycompany.com UCS-A /monitoring/callhome* # set phone-contact

115 Call Home and Smart Call Home Configuration Configuring the Default Cisco TAC-1 Profile UCS-A /monitoring/callhome* # set street-address "123 N. Main Street, Anytown, CA, 99885" UCS-A /monitoring/callhome* # set customer-id UCS-A /monitoring/callhome* # set contract-id UCS-A /monitoring/callhome* # set site-id UCS-A /monitoring/callhome* # set from- person@mycompany.com UCS-A /monitoring/callhome* # set reply-to- person@mycompany.com UCS-A /monitoring/callhome* # set hostname UCS-A /monitoring/callhome* # set port 25 UCS-A /monitoring/callhome* # set throttling on UCS-A /monitoring/callhome* # set urgency information UCS-A /monitoring/callhome* # commit-buffer UCS-A /monitoring/callhome # What to Do Next Continue to "Configuring the Default Cisco TAC-1 Profile, on page 101" to configure a Call Home profile for use with Smart Call Home. Configuring the Default Cisco TAC-1 Profile The following are the default settings for the CiscoTAC-1 profile: Level is normal Only the CiscoTAC alert group is selected Format is xml Maximum message size is Before You Begin Complete the "Configuring Smart Call Home, on page 99" section. UCS-A /monitoring/callhome # scope profile CiscoTac-1 Enters monitoring call home profile mode for the default Cisco TAC-1 profile. UCS-A /monitoring/callhome/profile # set level normal Specifies the normal event level for the profile. Step 4 Step 5 UCS-A /monitoring/callhome/profile # set alertgroups ciscotac UCS-A /monitoring/callhome/profile # set format xml UCS-A /monitoring/callhome/profile # set maxsize Specifies the ciscotac alert group for the profile. Specifies the message format to xml. Specifies the maximum size of for messages. Step 6 UCS-A /monitoring/callhome/profile # create destination callhome@cisco.com Specifies the recipient to callhome@cisco.com. 101

116 Configuring a System Inventory Message for Smart Call Home Call Home and Smart Call Home Configuration Step 7 Step 8 UCS-A /monitoring/callhome/profile/destination # exit UCS-A /monitoring/callhome/profile # exit Exits to monitoring call home profile mode. Exits to monitoring call home mode. The following example configures the default Cisco TAC-1 profile for use with Smart Call Home: UCS-A /monitoring/callhome* # scope profile CiscoTac-1 UCS-A /monitoring/callhome/profile* # set level normal UCS-A /monitoring/callhome/profile* # set alertgroups ciscotac UCS-A /monitoring/callhome/profile* # set format xml UCS-A /monitoring/callhome/profile* # set maxsize UCS-A /monitoring/callhome/profile* # create destination callhome@cisco.com UCS-A /monitoring/callhome/profile/destination* # exit UCS-A /monitoring/callhome/profile* # exit UCS-A /monitoring/callhome* # What to Do Next Continue to "Configuring a System Inventory Message for Smart Call Home, on page 102" to configure system inventory messages for use with Smart Call Home. Configuring a System Inventory Message for Smart Call Home Before You Begin Complete the "Configuring the Default Cisco TAC-1 Profile, on page 101" section. Step 4 Step 5 UCS-A /monitoring/callhome # scope inventory UCS-A /monitoring/callhome/inventory # set send-periodically {off on} UCS-A /monitoring/callhome/inventory # set interval-days interval-num UCS-A /monitoring/callhome/inventory # set timeofday-hour hour UCS-A /monitoring/callhome/inventory # set timeofday-minute minute Enters monitoring call home inventory mode. Enables or disables the sending of inventory messages. When the on keyword is specified, inventory messages are automatically sent to the Call Home database. Specifies the the time interval (in days) at which inventory messages will be sent. Specifies the hour (using 24-hour format) that inventory messages are sent. Specifies the number of minutes after the hour that inventory messages are sent. 102

117 Call Home and Smart Call Home Configuration Registering Smart Call Home Step 6 UCS-A /monitoring/callhome/inventory # commit-buffer Commits the transaction to the system configuration. The following example configures Call Home system inventory messages and commits the transaction: UCS-A /monitoring/callhome* # scope inventory UCS-A /monitoring/callhome/inventory* # set send-periodically on UCS-A /monitoring/callhome/inventory* # set interval-days 15 UCS-A /monitoring/callhome/inventory* # set timeofday-hour 21 UCS-A /monitoring/callhome/inventory* # set timeofday-minute 30 UCS-A /monitoring/callhome/inventory* # commit-buffer UCS-A /monitoring/callhome/inventory # What to Do Next Continue to "Registering Smart Call Home, on page 103" to send an inventory message that starts the Smart Call Home registration process. Registering Smart Call Home Before You Begin Complete the "Configuring a System Inventory Message for Smart Call Home, on page 102" section. UCS-A /monitoring/callhome/inventory # send Sends the system inventory message to the Smart Call Home database. When Cisco receives the system inventory, a Smart Call Home registration is sent to the address that you configured as the address for the main Smart Call Home contact. The following example sends the system inventory message to the Smart Call Home database: UCS-A /monitoring/callhome/inventory # send What to Do Next When you receive the registration from Cisco, do the following to complete registration for Smart Call Home: 1 Click the link in the . The link opens the Cisco Smart Call Home portal in your web browser. 2 Log into the Cisco Smart Call Home portal. 103

118 Registering Smart Call Home Call Home and Smart Call Home Configuration 3 Follow the steps provided by Cisco Smart Call Home. After you agree to the terms and conditions, the Cisco Smart Call Home registration for the Cisco UCS domain is complete. 104

119 CHAPTER 12 Database Health Monitoring Cisco UCS Manager Database Health Monitoring, page 105 Changing Internal Backup Interval, page 105 Triggering Health Check, page 106 Changing Health Check Interval, page 106 Cisco UCS Manager Database Health Monitoring Cisco UCS Manager uses a SQLite database stored on the Fabric Interconnects to persist configuration and inventory. Data corruption on both the Flash and NVRAM storage devices can cause failures and loss of customer configuration data. Cisco UCS Manager provides several proactive health check and recovery mechanisms to improve the integrity of the Cisco UCS Manager database. These mechanisms enable active monitoring of the database health. Periodic Health Check A periodic check of database integrity ensures that any corruption is caught and recovered proactively. See Triggering Health Check, on page 106, and Changing Health Check Interval, on page 106. Periodic Backup A periodic internal full state backup of the system ensures a smoother route to recovery in the case of any unrecoverable errors. See Changing Internal Backup Interval, on page 105. Changing Internal Backup Interval You can change the interval at which the internal backup is done. To disable the backup the value can be set to 0. UCS-A# scope system Enters the system. 105

120 Triggering Health Check Database Health Monitoring UCS-A /system# set mgmt-db-check-policy internal-backup-interval days UCS-A /system* # commit-buffer Specifies the time interval (in days) at which the integrity backup is done. Commits the transaction. This example changes the time interval at which the check runs to two days, and commits the transaction. UCS-A# scope system UCS-A /system # set mgmt-db-check-policy health-check-interval 2 UCS-A /system* # commit-buffer UCS-A /system # Triggering Health Check Use the following commands to trigger an immediate full database integrity check. UCS-A# scope system UCS-A /system # start-db-check UCS-A /system # commit-buffer Enters the system. Triggers health check. Commits the transaction. Changing Health Check Interval You can change the interval at which the integrity check runs. To disable the periodic check entirely set the value for to 0. UCS-A# scope system UCS-A /system# set mgmt-db-check-policy health-check-interval hours UCS-A /system* # commit-buffer Enters the system. Specifies the time interval (in hours) at which the integrity check runs. Commits the transaction. 106

121 Database Health Monitoring Changing Health Check Interval This example changes the time interval at which the check runs to two hours, and commits the transaction. UCS-A# scope system UCS-A /system # set mgmt-db-check-policy health-check-interval 2 UCS-A /system* # commit-buffer UCS-A /system # 107

122 Changing Health Check Interval Database Health Monitoring 108

123 CHAPTER 13 Hardware Monitoring System Monitoring CLI Command Cheat Sheet, page 109 Managing the Chassis, page 111 Managing Blade Servers, page 112 Managing Rack-Mount servers, page 113 Monitoring Fan Modules, page 114 Monitoring Management Interfaces, page 116 Local Storage Monitoring, page 119 Graphics Card Monitoring, page 130 Managing Transportable Flash Module and Supercapacitor, page 132 TPM Monitoring, page 133 System Monitoring CLI Command Cheat Sheet The following table provides a brief summary of Cisco UCS Manager CLI commands you use to monitor managed objects in the system. Managed Object Monitoring Command Description Hardware Chassis show chassis [adaptor cmc Displays chassis information. decommissioned detail environment fabric fi-iom firmware fsm inventory psu version] Fabric Interconnect show fabric-interconnect [a b ] Displays Fabric Interconnect [detail environment firmware information. fsm inventory mac-aging mode version] 109

124 System Monitoring CLI Command Cheat Sheet Hardware Monitoring Managed Object FEX IOM Server System Monitoring Command show fex [detail firmware fsm inventory version] show iom [firmware health version] show server [actual-boot-order adapter assoc bios boot-order cpu decommissioned environment firmware health identity inventory memory status storage version] show system [detail firmware version] Description Displays Fabric Extender information Displays Fabric Input/Output Module information. Displays server information. Displays system information. System scope monitoring [show] [baseline-faults callhome event fault fault-suppress-policy fsm mgmt-if-mon-policy new-faults snmp snmp-trap snmp-user stats-collection-policy stats-threshold-policy syslog] Displays information about commands in Monitoring mode. Logs Event Fault SEL Syslog show event [event-id detail] show fault [fault-id cause detail severity suppressed] show sel [chassis-id/blade-id rack-id] scope monitoring [show ] [syslog] Displays the Event log. Displays the Fault log. Displays the System Event Log for the chassis, blade, or rack-mount server. Displays the Syslog. 110

125 Hardware Monitoring Managing the Chassis Managing the Chassis Turning On the Locator LED for a Chassis UCS-A# scope chassis chassis-num UCS-A /chassis # enable locator-led UCS-A /chassis # commit-buffer Enters chassis mode for the specified chassis. Turns on the chassis locator LED. Commits the transaction to the system configuration. The following example turns on the locator LED for chassis 2 and commits the transaction: UCS-A# scope chassis 2 UCS-A /chassis # enable locator-led UCS-A /chassis* # commit-buffer UCS-A /chassis # Turning Off the Locator LED for a Chassis UCS-A# scope chassis chassis-num UCS-A /chassis # disable locator-led UCS-A /chassis # commit-buffer Enters chassis mode for the specified chassis. Turns off the chassis locator LED. Commits the transaction to the system configuration. The following example turns off the locator LED for chassis 2 and commits the transaction: UCS-A# scope chassis 2 UCS-A /chassis # disable locator-led UCS-A /chassis* # commit-buffer UCS-A /chassis # 111

126 Managing Blade Servers Hardware Monitoring Managing Blade Servers Turning On the Locator LED for a Blade Server UCS-A# scope server chassis-num / server-num UCS-A /chassis/server # enable locator-led [multi-master multi-slave] UCS-A /chassis/server # commit-buffer Enters chassis server mode for the specified chassis. Turns on the blade server locator LED. Commits the transaction to the system configuration. The following example turns on the locator LED for blade server 4 in chassis 2 and commits the transaction: UCS-A# scope server 2/4 UCS-A /chassis/server # enable locator-led UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server # Turning Off the Locator LED for a Blade Server UCS-A# scope server chassis-num / server-num Enters chassis mode for the specified chassis. UCS-A /chassis/server # disable locator-led [multi-master multi-slave] UCS-A /chassis/server # commit-buffer Turns off the blade server locator LED. Commits the transaction to the system configuration. The following example turns off the locator LED for blade server 4 in chassis 2 and commits the transaction: UCS-A# scope chassis 2/4 UCS-A /chassis/server # disable locator-led UCS-A /chassis/server* # commit-buffer UCS-A /chassis/server # 112

127 Hardware Monitoring Managing Rack-Mount servers Managing Rack-Mount servers Turning On the Locator LED for a Rack-Mount Server UCS-A# scope server server-num UCS-A /server # enable locator-led UCS-A /server # commit-buffer Enters server mode for the specified rack-mount server. Turns on the rack-mount server locator LED. Commits the transaction to the system configuration. The following example turns on the locator LED for rack-mount server 2 and commits the transaction: UCS-A# scope server 2 UCS-A /server # enable locator-led UCS-A /server* # commit-buffer UCS-A /server # Turning Off the Locator LED for a Rack-Mount Server UCS-A# scope server server-num UCS-A /server # disable locator-led UCS-A /server # commit-buffer Enters server mode for the specified rack-mount server. Turns off the rack-mount server locator LED. Commits the transaction to the system configuration. The following example turns off the locator LED for rack-mount server 2 and commits the transaction: UCS-A# scope server 2 UCS-A /server # disable locator-led UCS-A /server* # commit-buffer UCS-A /server # 113

128 Showing the Status for a Rack-Mount Server Hardware Monitoring Showing the Status for a Rack-Mount Server UCS-A# show server status Shows the status for all servers in the Cisco UCS domain. The following example shows the status for all servers in the Cisco UCS domain. The servers numbered 1 and 2 do not have a slot listed in the table because they are rack-mount servers. Server Slot Status Availability Overall Status Discovery /1 Equipped Unavailable Ok Complete 1/2 Equipped Unavailable Ok Complete 1/3 Equipped Unavailable Ok Complete 1/4 Empty Unavailable Ok Complete 1/5 Equipped Unavailable Ok Complete 1/6 Equipped Unavailable Ok Complete 1/7 Empty Unavailable Ok Complete 1/8 Empty Unavailable Ok Complete 1 Equipped Unavailable Ok Complete 2 Equipped Unavailable Ok Complete Monitoring Fan Modules UCS-A# scope chassis chassis-num Enters chassis mode for the specified chassis. UCS-A /chassis # show environment fan UCS-A /chassis # scope fan-module tray-num module-num Displays the environment status for all fans within the chassis. This includes the following information: Overall status Operability Power state Thermal status Threshold status Voltage status Enters fan module chassis mode for the specified fan module. 114

129 Hardware Monitoring Monitoring Fan Modules Step 4 UCS-A /chassis/fan-module # show [detail expand] Note Each chassis contains one tray, so the tray number in this command is always 1. Displays the environment status for the specified fan module. The following example displays information about the fan modules in chassis 1: UCS-A# scope chassis 1 UCS-A /chassis # show environment fan Chassis 1: Overall Status: Power Problem Operability: Operable Power State: Redundancy Failed Thermal Status: Upper Non Recoverable Tray 1 Module 1: Threshold Status: OK Overall Status: Operable Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A Fan Module Stats: Ambient Temp (C): Fan 1: Threshold Status: OK Overall Status: Operable Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A Fan 2: Threshold Status: OK Overall Status: Operable Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A Tray 1 Module 2: Threshold Status: OK Overall Status: Operable Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A Fan Module Stats: Ambient Temp (C): Fan 1: Threshold Status: OK Overall Status: Operable Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A Fan 2: Threshold Status: OK Overall Status: Operable 115

130 Monitoring Management Interfaces Hardware Monitoring Operability: Operable Power State: On Thermal Status: OK Voltage Status: N/A The following example displays information about fan module 2 in chassis 1: UCS-A# scope chassis 1 UCS-A /chassis # scope fan-module 1 2 UCS-A /chassis/fan-module # show detail Fan Module: Tray: 1 Module: 2 Overall Status: Operable Operability: Operable Threshold Status: OK Power State: On Presence: Equipped Thermal Status: OK Product Name: Fan Module for UCS 5108 Blade Server Chassis PID: N20-FAN5 VID: V01 Vendor: Cisco Systems Inc Serial (SN): NWG14350B6N HW Revision: 0 Mfg Date: T08:41: Monitoring Management Interfaces Management Interfaces Monitoring Policy The management interfaces monitoring policy defines how the mgmt0 Ethernet interface on the fabric interconnect is monitored. If Cisco UCS Manager detects a management interface failure, a failure report is generated. If the configured number of failure reports is reached, the system assumes that the management interface is unavailable and generates a fault. By default, the management interfaces monitoring policy is enabled. When the management interface of a fabric interconnect which is currently the managing instance fails, Cisco UCS Manager first confirms if the status of the subordinate fabric interconnect is up. In addition, if there are no current failure reports logged against the fabric interconnect, Cisco UCS Manager modifies the managing instance for the endpoints. If the affected fabric interconnect is currently the primary in a high availability setup, a failover of the management plane is triggered. This failover does not affect the data plane. You can set the following properties related to monitoring the management interface: The type of mechanism used to monitor the management interface. The interval at which the status of the management interface is monitored. The maximum number of monitoring attempts that can fail before the system assumes that the management is unavailable and generates a fault message. 116

131 Hardware Monitoring Configuring the Management Interfaces Monitoring Policy Important When the management interface fails on a fabric interconnect, the managing instance may not change if one of the following occurs: A path to the endpoint through the subordinate fabric interconnect does not exist. The management interface for the subordinate fabric interconnect has failed. The path to the endpoint through the subordinate fabric interconnect has failed. Configuring the Management Interfaces Monitoring Policy Step 4 Step 5 Enter monitoring mode. UCS-A# scope monitoring Enable or disable the management interfaces monitoring policy. UCS-A /monitoring # set mgmt-if-mon-policy admin-state {enabled disabled} Specify the number of seconds that the system should wait between data recordings. UCS-A /monitoring # set mgmt-if-mon-policy poll-interval Enter an integer between 90 and 300. Specify the maximum number of monitoring attempts that can fail before the system assumes that the management interface is unavailable and generates a fault message. UCS-A /monitoring # set mgmt-if-mon-policy max-fail-reports num-mon-attempts Enter an integer between 2 and 5. Specify the monitoring mechanism that you want the system to use. UCS-A /monitoring # set mgmt-if-mon-policy monitor-mechanism {mii-status ping-arp-targets ping-gateway mii-status The system monitors the availability of the Media Independent Interface (MII). ping-arp-targets The system pings designated targets using the Address Resolution Protocol (ARP). ping-gateway The system pings the default gateway address specified for this Cisco UCS domain in the management interface. Step 6 If you selected mii-status as your monitoring mechanism, configure the following properties: a) Specify the number of seconds that the system should wait before requesting another response from the MII if a previous attempt fails. UCS-A /monitoring # set mgmt-if-mon-policy mii-retry-interval num-seconds Enter an integer between 3 and 10. b) Specify the number of times that the system polls the MII until the system assumes that the interface is unavailable. UCS-A /monitoring # set mgmt-if-mon-policy mii-retry-count num-retries 117

132 Configuring the Management Interfaces Monitoring Policy Hardware Monitoring Enter an integer between 1 and 3. Step 7 Step 8 Step 9 If you selected ping-arp-targets as your monitoring mechanism, configure the following properties: a) Specify the first IPv4 or IPv6 address the system pings. UCS-A /monitoring # set mgmt-if-mon-policy {arp-target1 ndisc-target1} {ipv4-addr ipv6-addr} Type for an IPv4 address to remove the ARP target or :: for an IPv6 address to remove the N-disc target. b) Specify the second IPv4 or IPv6 address the system pings. UCS-A /monitoring # set mgmt-if-mon-policy {arp-target2 ndisc-target2} {ipv4-addr ipv6-addr} Type for an IPv4 address to remove the ARP target or :: for an IPv6 address to remove the N-disc target. c) Specify the third IPv4 or IPv6 address the system pings. UCS-A /monitoring # set mgmt-if-mon-policy {arp-target3 ndisc-target3} {ipv4-addr ipv6-addr} Type for an IPv4 address to remove the ARP target or :: for an IPv6 address to remove the N-disc target. Note The ping IPv4 ARP or IPv6 N-disc targets must be in the same subnet or prefix, respectively, as the fabric interconnect. d) Specify the number of ARP requests to send to the target IP addresses. UCS-A /monitoring # set mgmt-if-mon-policy arp-requests num-requests Enter an integer between 1 and 5. e) Specify the number of seconds to wait for responses from the ARP targets before the system assumes that they are unavailable. UCS-A /monitoring # set mgmt-if-mon-policy arp-deadline num-seconds Enter a number between 5 and 15. If you selected ping-gateway as your monitoring mechanism, configure the following properties: a) Specify the number of times the system should ping the gateway. UCS-A /monitoring # set mgmt-if-mon-policy ping-requests Enter an integer between 1 and 5. b) Specify the number of seconds to wait for a response from the gateway until the system assumes that the address is unavailable. UCS-A /monitoring # set mgmt-if-mon-policy ping-deadline Enter an integer between 5 and 15. UCS-A /monitoring # commit-buffer Commits the transaction to the system configuration. The following example creates a monitoring interface management policy using the Media Independent Interface (MII) monitoring mechanism and commits the transaction: UCS-A# scope monitoring UCS-A /monitoring # set mgmt-if-mon-policy admin-state enabled UCS-A /monitoring* # set mgmt-if-mon-policy poll-interval 250 UCS-A /monitoring* # set mgmt-if-mon-policy max-fail-reports 2 UCS-A /monitoring* # set mgmt-if-mon-policy monitor-mechanism set mii-status UCS-A /monitoring* # set mgmt-if-mon-policy mii-retry-count 3 118

133 Hardware Monitoring Local Storage Monitoring UCS-A /monitoring* # set mgmt-if-mon-policy mii-retry-interval 7 UCS-A /monitoring* # commit-buffer UCS-A /monitoring # Local Storage Monitoring Local storage monitoring in Cisco UCS provides status information on local storage that is physically attached to a blade or rack server. This includes RAID controllers, physical drives and drive groups, virtual drives, RAID controller batteries (Battery Backup Unit), Transportable Flash Modules (TFM), supercapacitors, FlexFlash controllers, and SD cards. Cisco UCS Manager communicates directly with the LSI MegaRAID controllers and FlexFlash controllers using an out-of-band interface, which enables real-time updates. Some of the information that is displayed includes: RAID controller status and rebuild rate. The drive state, power state, link speed, operability, and firmware version of physical drives. The drive state, operability, strip size, access policies, drive cache, and health of virtual drives. The operability of a BBU, whether it is a supercap or battery, and information about the TFM. LSI storage controllers use a Transportable Flash Module (TFM) powered by a supercapacitor to provide RAID cache protection. Information on SD cards and FlexFlash controllers, including RAID health and RAID state, card health, and operability. Information on operations that are running on the storage component, such as rebuild, initialization, and relearning. Note After a CIMC reboot or build upgrades, the status, start time, and end times of operations running on the storage component may not be displayed correctly. Detailed fault information for all local storage components. Note All faults are displayed on the Faults tab. Support for Local Storage Monitoring The type of monitoring supported depends upon the Cisco UCS server. Supported Cisco UCS Servers for Local Storage Monitoring Through Cisco UCS Manager, you can monitor local storage components for the following servers: Cisco UCS B200 M3 blade server Cisco UCS B420 M3 blade server 119

134 Prerequisites for Local Storage Monitoring Hardware Monitoring Cisco UCS B22 M3 blade server Cisco UCS B200 M4 blade server Cisco UCS B260 M4 blade server Cisco UCS B460 M4 blade server Cisco UCS C460 M2 rack server Cisco UCS C420 M3 rack server Cisco UCS C260 M2 rack server Cisco UCS C240 M3 rack server Cisco UCS C220 M3 rack server Cisco UCS C24 M3 rack server Cisco UCS C22 M3 rack server Cisco UCS C220 M4 rack server Cisco UCS C240 M4 rack server Cisco UCS C460 M4 rack server Note Not all servers support all local storage components. For Cisco UCS rack servers, the onboard SATA RAID 0/1 controller integrated on motherboard is not supported. Supported Cisco UCS Servers for Legacy Disk Drive Monitoring Only legacy disk drive monitoring is supported through Cisco UCS Manager for the following servers: Cisco UCS B200 M1/M2 blade server Cisco UCS B250 M1/M2 blade server Note In order for Cisco UCS Manager to monitor the disk drives, the 1064E storage controller must have a firmware level contained in a Cisco UCS bundle with a package version of 2.0(1) or higher. Prerequisites for Local Storage Monitoring These prerequisites must be met for local storage monitoring or legacy disk drive monitoring to provide useful status information: The drive must be inserted in the server drive bay. The server must be powered on. The server must have completed discovery. 120

135 Hardware Monitoring Legacy Disk Drive Monitoring The results of the BIOS POST complete must be TRUE. Legacy Disk Drive Monitoring Note The following information is applicable only for B200 M1/M2 and B250 M1/M2 blade servers. The legacy disk drive monitoring for Cisco UCS provides Cisco UCS Manager with blade-resident disk drive status for supported blade servers in a Cisco UCS domain. Disk drive monitoring provides a unidirectional fault signal from the LSI firmware to Cisco UCS Manager to provide status information. The following server and firmware components gather, send, and aggregate information about the disk drive status in a server: Physical presence sensor Determines whether the disk drive is inserted in the server drive bay. Physical fault sensor Determines the operability status reported by the LSI storage controller firmware for the disk drive. IPMI disk drive fault and presence sensors Sends the sensor results to Cisco UCS Manager. Disk drive fault LED control and associated IPMI sensors Controls disk drive fault LED states (on/off) and relays the states to Cisco UCS Manager. Turning On the Local Disk Locator LED Step 4 UCS-A# scope server id Enters server mode for the specified server. UCS-A/server # scope local-disk id Enters the RAID controller for the specified local disk. UCS-A /server/local-disk # enable locator-led Turns on the disk locator LED. UCS-A/server/local-disk* # commit-buffer Commits the command to the system configuration. The following example displays how to turn on the local disk Locator LED: UCS-A# scope server 1 UCS-A /server/raid-controller # scope local-disk 2 USA-A /server/raid-controller/local-disk # enable locator-led USA-A /server/raid-controller/local-disk* # commit-buffer 121

136 Turning Off the Local Disk Locator LED Hardware Monitoring Turning Off the Local Disk Locator LED Step 4 UCS-A# scope server id Enters server mode for the specified server. UCS-A/server # scope local-disk id Enters the RAID controller for the specified local disk. UCS-A/server/local-disk # disable locator-led Turns off the disk locator LED. UCS-A/server/raid-controller/local-disk* # commit-buffer Commits the command to the system configuration. The following example displays how to disable the local disk Locator LED: UCS-A# server 1 UCS-A /server # scope local-disk 2 USA-A /server/local-disk # disable locator-led USA-A /server/local-disk* # commit-buffer Viewing the Local Disk Locator LED State UCS-A# scope server id Enters server mode for the specified server. UCS-A/server # scope local-disk id Enters the RAID controller for the specified local disk. UCS-A/server/local-disk # show locator-led Shows the state of the disk locator LED. The following example shows that the state of the local disk Locator LED is on: USA-A# scope server 1 USA-A /server # scope local-disk 2 USA-A /serverlocal-disk # show locator-led Locator LED: Equipment Operational State /SAS-1/2 On 122

137 Hardware Monitoring Flash Life Wear Level Monitoring Flash Life Wear Level Monitoring Flash life wear level monitoring enables you to monitor the life span of solid state drives. You can view both the percentage of the flash life remaining, and the flash life status. Wear level monitoring is supported on the Fusion IO mezzanine card with the following Cisco UCS blade servers: Cisco UCS B22 M3 blade server Cisco UCS B200 M3 blade server Cisco UCS B420 M3 blade server Cisco UCS B200 M4 blade server Cisco UCS B260 M4 blade server Cisco UCS B460 M4 blade server Note Wear level monitoring requires the following: Cisco UCS Manager must be at release 2.2(2a) or greater. The Fusion IO mezzanine card firmware must be at version or greater. Viewing Flash Life Status UCS-A# scope server chassis-id / server-id UCS-A /chassis/server # show raid-controller detail expand Enters chassis server mode for the specified server. Displays details for the RAID controller. The following example shows how to display the flash life status for server 3: UCS-A# scope server 1/3 UCS-A /chassis/server # show raid-controller detail expand RAID Controller: ID: 1 Type: FLASH PCI Addr: 131:00.0 Vendor: Cisco Systems Inc Model: UCSC-F-FIO-1205M Serial: 1315D2B52 HW Rev: FLASH Raid Support: No OOB Interface Supported: No Rebuild Rate: N/A 123

138 Viewing the Status of Local Storage Components Hardware Monitoring Controller Status: Unknown Flash Life: Flash Percentage: N/A FLash Status: Error(244) UCS-A /chassis/server # Viewing the Status of Local Storage Components UCS-A# scope server chassis-id / server-id Enters chassis server mode for the specified server. UCS-A /chassis/server # show inventory storage Displays the local and virtual storage information for the server. The following example shows how to display the local disk status for server 2: UCS-A# scope server 1/2 UCS-A /chassis/server # show inventory storage Server 1/2: Name: User Label: Equipped PID: UCSB-B200-M3 Equipped VID: V01 Equipped Serial (SN): FCH16207KXG Slot Status: Equipped Acknowledged Product Name: Cisco UCS B200 M3 Acknowledged PID: UCSB-B200-M3 Acknowledged VID: V01 Acknowledged Serial (SN): FCH16207KXG Acknowledged Memory (MB): Acknowledged Effective Memory (MB): Acknowledged Cores: 12 Acknowledged Adapters: 1 Motherboard: Product Name: Cisco UCS B200 M3 PID: UCSB-B200-M3 VID: V01 Vendor: Cisco Systems Inc Serial (SN): FCH16207KXG HW Revision: 0 RAID Controller 1: Type: SAS Vendor: LSI Logic Symbios Logic Model: LSI MegaRAID SAS 2004 ROMB Serial: LSIROMB-0 HW Revision: B2 PCI Addr: 01:00.0 Raid Support: RAID0, RAID1 OOB Interface Supported: Yes Rebuild Rate: 31 Controller Status: Optimal Local Disk 1: Product Name: 146GB 6Gb SAS 10K RPM SFF HDD/hot plug/drive sled mounted PID: A03-D146GA2 VID: V01 124

139 Hardware Monitoring Viewing the Status of Local Storage Components Vendor: SEAGATE Model: ST SS Vendor Description: Seagate Technology LLC Serial: 3SD31S4X HW Rev: 0 Block Size: 512 Blocks: Operability: Operable Oper Qualifier Reason: N/A Presence: Equipped Size (MB): Drive State: Online Power State: Active Link Speed: 6 Gbps Device Type: HDD Local Disk 2: Product Name: 600G AL12SE SAS Hard Disk Drive PID: A03-D600GA2 VID: V01 Vendor: TOSHIBA Model: MBF2600RC Vendor Description: Toshiba Corporation Serial: EA00PB109T4A HW Rev: 0 Block Size: 512 Blocks: Operability: Operable Oper Qualifier Reason: N/A Presence: Equipped Size (MB): Drive State: Online Power State: Active Link Speed: 6 Gbps Device Type: HDD Local Disk Config Definition: Mode: RAID 1 Mirrored Description: Protect Configuration: No Virtual Drive 0: Type: RAID 1 Mirrored Block Size: 512 Blocks: Operability: Operable Presence: Equipped Size (MB): Lifecycle: Allocated Drive State: Optimal Strip Size (KB): 64 Access Policy: Read Write Read Policy: Normal Configured Write Cache Policy: Write Through Actual Write Cache Policy: Write Through IO Policy: Direct Drive Cache: No Change Bootable: False UCS-A /chassis/server # The following example shows how to display the local disk status for server 2 with PCIe\NVMe Flash Storage: UCS-A# scope server 1/2 UCS-A /chassis/server # show inventory storage Server 1/2: Name: Acknowledged Serial (SN): FCH1901V0FK Acknowledged Product Name: Cisco UCS C240 M4S2 Acknowledged PID: UCSC-C240-M4S2 Acknowledged VID: 0 Acknowledged Memory (MB): Acknowledged Effective Memory (MB): Acknowledged Cores:

140 Viewing the Status of Local Storage Components Hardware Monitoring Acknowledged Adapters: 4 Motherboard: Product Name: Cisco UCS C240 M4S2 PID: UCSC-C240-M4S2 VID: V01 Vendor: Cisco Systems Inc Serial (SN): FCH1901V0FK HW Revision: 0 Raid Controller 1: Type: NVMe Vendor: HGST Model: HUSPR3280ADP301 Serial: STM0001A74F2 HW Revision: PCI Addr: 42:00.0 Raid Support: No OOB Interface Supported: Yes Rebuild Rate: 0 Controller Status: Optimal Local Disk 2: Product Name: Cisco UCS 800GB 2.5 in NVMe based PCIeSSD PID: UCS-SDHPCIE800GB VID: Vendor: HGST Model: HUSPR3280ADP301 Vendor Description: Serial: 14310CF8E975 HW Rev: 0 Block Size: 512 Blocks: Operability: NA Oper Qualifier Reason: N/A Presence: Equipped Size: Drive State: NA Power State: NA Link Speed: NA Device Type: SSD Thermal: N/A UCS-A /chassis/server # The following example shows how to display the local disk status for Cisco UCS (P3600) 2.5 inches 800 GB NVMe based PCIe SSD: RAID Controller: ID: 1 Type: NVME PCI Addr: 69:00.0 Vendor: Intel Model: SSDPE2ME800G4K Serial: CVMD D800GGN HW Rev: Raid Support: No OOB Interface Supported: Yes Mode: NVME Rebuild Rate: 0 Controller Status: Optimal Config State: Not Applied Pinned Cache Status: Disabled Sub OEM ID: 0 Supported Strip Sizes: Not Applicable Default Strip Size: Unknown PCI Slot: FrontPCIe5 Product Variant: default Product Name: Cisco UCS (P3600) 2.5 inches 800 GB NVMe based PCIe SSD PID: UCS-PCI VID: Part Number: Storage Controller Admin State: Unspecified Vendor Id: 0x

141 Hardware Monitoring Viewing the Status of Local Storage Components Subvendor Id: 0x1137 Device Id: 0x953 Subdevice Id: 0x15b Current Task: Local Disk: ID: 5 Block Size: 512 Physical Block Size: Unknown Blocks: Size: Technology: Operability: N/A Oper Qualifier Reason: N/A Presence: Equipped Connection Protocol: NVME Product Variant: default Product Name: Cisco UCS (P3600) 2.5 inches 800 GB NVMe based PCIe SSD PID: UCS-PCI VID: Vendor: Intel Model: SSDPE2ME800G4K Vendor Description: Serial: CVMD D800GGN HW Rev: 0 Drive State: Unknown Power State: Unknown Link Speed: Unknown Enclosure Association Type: Unknown Device Version: N/A Device Type: SSD Thermal: N/A Admin State Type: N/A Admin Virtual Drive ID: Unspecified Current Task: The following example shows how to display the status for Cisco UCS (P3600) HHHL 2000 GB NVMe based PCIe SSD: RAID Controller: ID: 3 Type: NVME PCI Addr: 01:00.0 Vendor: Intel Model: SSDPEDME020T401 Serial: CVMD543200AQ2P0EGN HW Rev: Raid Support: No OOB Interface Supported: Yes Mode: NVME Rebuild Rate: 0 Controller Status: Optimal Config State: Not Applied Pinned Cache Status: Disabled Sub OEM ID: 0 Supported Strip Sizes: Not Applicable Default Strip Size: Unknown PCI Slot: 2 Product Variant: default Product Name: Cisco UCS (P3600) HHHL 2000 GB NVMe based PCIe SSD PID: UCSC-F-I20003 VID: Part Number: Storage Controller Admin State: Unspecified Vendor Id: 0x8086 Subvendor Id: 0x1137 Device Id: 0x953 Subdevice Id: 0x1ac Current Task: Embedded Storage: Size:

142 Viewing the Status of a Disk Drive Hardware Monitoring Block Size: 512 Number Of Blocks: Viewing the Status of a Disk Drive Step 4 UCS-A# scope chassis chassis-num UCS-A /chassis # scope server server-num UCS-A /chassis/server # scope raid-controller raid-contr-id {sas sata} UCS-A /chassis/server/raid-controller # show local-disk [local-disk-id detail expand] Enters chassis mode for the specified chassis. Enters server chassis mode. Enters RAID controller server chassis mode. The following example shows the status of a disk drive: UCS-A# scope chassis 1 UCS-A /chassis # scope server 6 UCS-A /chassis/server # scope raid-controller 1 sas UCS-A /chassis/server/raid-controller # show local-disk 1 Local Disk: ID: 1 Block Size: 512 Blocks: Size (MB): Operability: Operable Presence: Equipped Viewing RAID Controller Operations UCS-A# scope server chassis-id / server-id UCS-A /chassis/server # show raid-controller operation Enters chassis server mode for the specified server. Displays the long running operations for the RAID controller. The following example shows how to display the RAID controller operations for server 3: UCS-A# scope server 1/3 UCS-A /chassis/server # show raid-controller operation 128

143 Hardware Monitoring Viewing RAID Controller Stats Name: Rebuild Affected Object: sys/chassis-1/blade-3/board/storage-sas-1/disk-1 State: In Progress Progress: 4 Start Time: T12:02: End Time: N/A UCS-A /chassis/server # Viewing RAID Controller Stats The following procedure shows how to display controller stats for a server with PCIe\NVMe Flash Storage: UCS-A# scope server chassis-id / server-id UCS-A /chassis/server # scope raid-controller raid-contr-id {flash sas sata sd unknown} UCS-A /chassis/server/raid-controller # show stats Enters chassis server mode for the specified server. Enters RAID controller server chassis mode. Displays the raid controller stats. The following example shows how to display the RAID controller stats: UCS-A# scope server 1/3 UCS-A /chassis/server # scope raid-controller UCS-A /chassis/server/raid-controller # show stats Nvme Stats: Time Collected: T12:37: Monitored Object: sys/rack-unit-6/board/storage-nvme-1/nvme-stats Suspect: Yes Temperature (C): Life Used Percentage: 0 Thresholded: 0 UCS-A /chassis/server/raid-controller # Monitoring RAID Battery Status This procedure applies only to Cisco UCS servers that support RAID configuration and TFM. If the Battery Backup Unit (BBU) has failed or is predicted to fail, you should replace the unit as soon as possible. UCS-A # scope chassis chassis-num Enters chassis mode for the specified chassis. 129

144 Graphics Card Monitoring Hardware Monitoring Step 4 UCS-A /chassis #scope server server-num UCS-A /chassis/server # scope raid-controller raid-contr-id {flash sas sata sd unknown} UCS-A /chassis/server/raid-controller # show raid-battery expand Enters server chassis mode. Enters RAID controller server chassis mode. Displays the RAID battery status. This example shows how to view information on the BBU of a server: UCS-A # scope chassis 1 UCS-A /chassis #scope server 3 UCS-A /chassis/server #scope raid-controller 1 sas UCS-A /chassis/server/raid-controller # show raid-battery expand RAID Battery: Battery Type: Supercap Presence: Equipped Operability: Operable Oper Qualifier Reason: Vendor: LSI Model: SuperCaP Serial: 0 Capacity Percentage: Full Battery Temperature (C): Transportable Flash Module: Presence: Equipped Vendor: Cisco Systems Inc Model: UCSB-RAID-1GBFM Serial: FCH164279W6 Graphics Card Monitoring Graphics Card Server Support With Cisco UCS Manager, you can view the properties for certain graphics cards and controllers. Graphics cards are supported on the following servers: Cisco UCS C240 M3 Rack Server Cisco UCS C460 M4 Rack Server Cisco UCS B200M4 Blade Server Note Certain NVIDIA Graphics Processing Units (GPU) do not support Error Correcting Code (ECC) and vgpu together. Cisco recommends that you refer to the release notes published by NVIDIA for the respective GPU to know whether it supports ECC and vgpu together. 130

145 Hardware Monitoring Viewing Graphics Card Properties Viewing Graphics Card Properties UCS-A# scope server blade-id UCS-A /server # show graphics-card detail Enters server mode for the specified server. Displays information about the graphics card. The following example shows how to display the graphics card properties on server 1: UCS-A# scope server 1 UCS-A /server # show graphics-card detail ID: 1 Slot Id: 2 Magma Expander Slot Id: Is Supported: Yes Vendor: Cisco Systems Inc Model: UCSB-GPU-M6 Serial: FHH B Mode: Graphics PID: UCSB-GPU-M6 Firmware Version: Vendor Id: 0x10de Subvendor Id: 0x10de Device Id: 0x13f3 Subdevice Id: 0x1143 UCS-A /server # Viewing Graphics Controller Properties UCS-A# scope server blade-id UCS-A /server # scope graphics-card card-id UCS-A /server/graphics-card # show graphics-controller detail Enters server mode for the specified server. Enters graphics card mode for the specified graphics card. Displays information about the graphics controllers. The following example shows how to display the graphics controller properties for graphics card 1 on server 1: UCS-A# scope server 1 UCS-A /server # scope graphics-card 1 UCS-A /server/graphics-card # show graphics-controller detail Graphics Controller: 131

146 Managing Transportable Flash Module and Supercapacitor Hardware Monitoring ID: 1 Pci Address: 07:00.0 ID: 2 Pci Address: 08:00.0 UCS-A /server/graphics-card # Managing Transportable Flash Module and Supercapacitor LSI storage controllers use a Transportable Flash Module (TFM) powered by a supercapacitor to provide RAID cache protection. With Cisco UCS Manager, you can monitor these components to determine the status of the battery backup unit (BBU). The BBU operability status can be one of the following: Operable The BBU is functioning successfully. Inoperable The TFM or BBU is missing, or the BBU has failed and needs to be replaced. Degraded The BBU is predicted to fail. TFM and supercap functionality is supported beginning with Cisco UCS Manager Release 2.1(2). TFM and Supercap Guidelines and Limitations TFM and Supercap Limitations The CIMC sensors for TFM and supercap on the Cisco UCS B420 M3 blade server are not polled by Cisco UCS Manager. If the TFM and supercap are not installed on the Cisco UCS B420 M3 blade server, or are installed and then removed from the blade server, no faults are generated. If the TFM is not installed on the Cisco UCS B420 M3 blade server, but the supercap is installed, Cisco UCS Manager reports the entire BBU system as absent. You should physically check to see if both the TFM and supercap is present on the blade server. Supported Cisco UCS Servers for TFM and Supercap The following Cisco UCS servers support TFM and supercap: Cisco UCS B420 M3 blade server Cisco UCS C22 M3 rack server Cisco UCS C24 M3 rack server Cisco UCS C220 M3 rack server Cisco UCS C240 M3 rack server Cisco UCS C420 M3 rack server Cisco UCS C460 M4 rack server Cisco UCS C220 M3 rack server Cisco UCS C240 M3 rack server 132

147 Hardware Monitoring TPM Monitoring TPM Monitoring Viewing TPM Properties Trusted Platform Module (TPM) is included on all Cisco UCS M3 blade and rack-mount servers. Operating systems can use TPM to enable encryption. For example, Microsoft's BitLocker Drive Encryption uses the TPM on Cisco UCS servers to store encryption keys. Cisco UCS Manager enables monitoring of TPM, including whether TPM is present, enabled, or activated. Step 4 UCS-A# scope server chassis-id / server-id UCS-A /chassis/server # scope tpm tpm-id UCS-A /chassis/server/tpm # show UCS-A /chassis/server/tpm # show detail Enters chassis server mode for the specified server. Enters TPM mode for the specified TPM ID. Displays the TPM properties. Displays detailed TPM properties. The following example shows how to display the TPM properties for blade 3 in chassis 1: UCS-A# scope server 1/3 UCS-A /chassis/server # scope tpm 1 UCS-A /chassis/server/tpm # show Trusted Platform Module: Presence: Equipped Enabled Status: Enabled Active Status: Activated Ownership: Unowned UCS-A /chassis/server/tpm # show detail Trusted Platform Module: Enabled Status: Enabled Active Status: Activated Ownership: Unowned Tpm Revision: 1 Model: UCSX-TPM1-001 Vendor: Cisco Systems Inc Serial: FCH16167DBJ UCS-A /chassis/server/tpm # 133

148 Viewing TPM Properties Hardware Monitoring 134

149 CHAPTER 14 Netflow Monitoring NetFlow Monitoring, page 135 NetFlow Monitoring Limitations, page 136 Configuring a Flow Record Definition, page 137 Configuring an Exporter Profile, page 138 Configuring a Netflow Collector, page 139 Configuring a Flow Exporter, page 140 Configuring a Flow Monitor, page 140 Configuring a Flow Monitor Session, page 141 Configuring a NetFlow Cache Active and Inactive Timeout, page 142 Associating a Flow Monitor Session to a vnic, page 142 NetFlow Monitoring Note For Release 3.0(2), NetFlow monitoring is supported for end-host mode only. NetFlow is a standard network protocol for collecting IP traffic data. NetFlow enables you to define a flow in terms of unidirectional IP packets that share certain characteristics. All packets that match the flow definition are then collected and exported to one or more external NetFlow collectors where they can be further aggregated, analyzed and used for application specific processing. Cisco UCS Manager uses NetFlow-capable adapters (Cisco UCS VIC 1240, Cisco UCS VIC 1280, and Cisco UCS VIC 1225) to communicate with the routers and switches that collect and export flow information. Network Flows A flow is a set of unidirectional IP packets that have common properties such as, the source or destination of the traffic, routing information, or the protocol used. Flows are collected when they match the definitions in the flow record definition. 135

150 NetFlow Monitoring Limitations Netflow Monitoring Flow Record Definitions A flow record definition contains all information about the properties used to define the flow, which can include both characteristic properties or measured properties. Characteristic properties, also called flow keys, are the properties that define the flow. Cisco UCS Manager supports IPv4, IPv6, and Layer 2 keys. Measured characteristics, also called flow values or nonkeys, are values that you can measure, such as the number of bytes contained in all packets of the flow, or the total number of packets. A flow record definition is a specific combination of flow keys and flow values. You can use the following type of flow record definitions: System-defined Default flow record definitions supplied by Cisco UCS Manager. User-defined Flow record definitions that you can create yourself. Flow Exporters, Flow Exporter Profiles, and Flow Collectors Flow exporters transfer the flows to the flow connector based on the information in a flow exporter profile. The flow exporter profile contains the networking properties used to export NetFlow packets. The networking properties include a VLAN, the source IP address, and the subnet mask for each fabric interconnect. Note In the Cisco UCS Manager GUI, the networking properties are defined in an exporter interface that is included in the profile. In the Cisco UCS Manager CLI, the properties are defined in the profile. Flow collectors receive the flows from the flow exporter. Each flow collector contains an IP address, port, external gateway IP, and VLAN that defines where the flows are sent. Flow Monitors and Flow Monitor Sessions A flow monitor consists of a flow definition, one or two flow exporters, and a timeout policy. You can use a flow monitor to specify which flow information you want to gather, and where you want to collect it from. Each flow monitor operates in either the egress or ingress direction. A flow monitor session contains up to four flow monitors: two flow monitors in the ingress direction and two flow monitors in the egress direction. A flow monitor session can also be associated with a vnic. NetFlow Monitoring Limitations Note For Release 3.0(2), NetFlow monitoring is supported for end-host mode only. The following limitations apply to NetFlow monitoring: NetFlow monitoring is not supported on the Cisco UCS 6100 Series Fabric Interconnect. NetFlow monitoring is supported only on the Cisco UCS VIC 1240, Cisco UCS VIC 1280, and Cisco UCS VIC 1225 adapters. Beginning with release 2.2(3a), NetFlow monitoring is also supported on the Cisco UCS VIC 1340, Cisco UCS VIC 1380, and Cisco UCS VIC 1227 adapters. 136

151 Netflow Monitoring Configuring a Flow Record Definition Note NetFlow monitoring is not supported on the Cisco UCS VIC 1200 adapters when configured with vhbas. You can have up to 64 flow record definitions, flow exporters, and flow monitors. NetFlow is not supported in vnic template objects. PVLANs and local VLANs are not supported for service VLANs. All VLANs must be public and must be common to both fabric interconnects. VLANs must be defined as an exporter interface before they can be used with a flow collector. You cannot use NetFlow with usnic, the Virtual Machine queue, or Linux ARFS. Configuring a Flow Record Definition UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-record flow-record-name Enters the ethernet flow monitor mode. Enters flow record mode for the specified flow record. Step 4 Step 5 Step 6 Step 7 UCS-A /eth-flow-mon/flow-record # set keytype {ipv4keys ipv6keys l2keys} UCS-A /eth-flow-mon/flow-record # set ipv4keys {dest-port ip-protocol ip-tos ipv4-dest-address ipv4-src-address src-port} UCS-A /eth-flow-mon/flow-record # set ipv6keys {dest-port ip-protocol ipv6-dest-address ipv6-src-address src-port} UCS-A /eth-flow-mon/flow-record # set l2keys {dest-mac-address ethertype src-mac-address} UCS-A /eth-flow-mon/flow-record # set nonkeys {counter-bytes-long counter-packets-long sys-uptime-first sys-uptime-last} Specifies the key type. Specifies the attributes for the key type that you selected in. Note Use this command only if you chose ipv4keys in step 3. Specifies the attributes for the key type that you selected in. Note Use this command only if you chose ipv6keys in. Specifies the attributes for the key type that you chose in. Note Use this command only if you selected l2keys in step 3. Specifies the nonkey attributes. 137

152 Configuring an Exporter Profile Netflow Monitoring Step 8 UCS-A /eth-flow-mon/flow-record # commit-buffer Commits the transaction to the system configuration. The following example shows how to create a flow record definition with Layer 2 keys and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-record r1 UCS-A /eth-flow-mon/flow-record* # set keytype l2keys UCS-A /eth-flow-mon/flow-record* #set l2keys dest-mac-address src-mac-address UCS-A /eth-flow-mon/flow-record* # set nonkeys sys-uptime counter-bytes counter-packets UCS-A /eth-flow-mon/flow-record* # commit-buffer UCS-A /eth-flow-mon/flow-record # Configuring an Exporter Profile Step 4 UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # scope flow-profile profile-name UCS-A /eth-flow-mon/flow-profile # show config UCS-A /eth-flow-mon/flow-profile # enter vlan vlan-name Enters the ethernet flow monitor mode. Enters the flow profile mode for the specified profile. Displays the flow profile configuration. Specifies the VLAN associated with the exporter profile. PVLANs and local VLAN are not supported. All VLAN must be public and must be common to both fabric interconnects. Step 5 Step 6 Step 7 UCS-A /eth-flow-mon/flow-profile/vlan # enter fabric {a b} UCS-A /eth-flow-mon/flow-profile/vlan/fabric/ # set addr ip-addr subnet ip-addr UCS-A /eth-flow-mon/flow-profile/vlan/fabric/ # commit-buffer Enters flow profile mode for the specified fabric. Specifies the source IP and subnet mask for the exporter profile on the fabric. Important Make sure the IP address you specify is unique within the Cisco UCS domain. IP address conflicts can occur if you specify an IP address that is already being used by Cisco UCS Manager. Commits the transaction to the system configuration. 138

153 Netflow Monitoring Configuring a Netflow Collector The following example shows how to configure the default exporter profile, set the source IP and subnet mask for the exporter interface on each fabric, and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # scope flow-profile default UCS-A /eth-flow-mon/flow-profile # enter vlan 100 UCS-A /eth-flow-mon/flow-profile/vlan* # enter fabric a UCS-A /eth-flow-mon/flow-profile/vlan/fabric* # set addr subnet UCS-A /eth-flow-mon/flow-profile/vlan/fabric* # up UCS-A /eth-flow-mon/flow-profile/vlan* # enter fabric b UCS-A /eth-flow-mon/flow-profile/vlan/fabric* # set addr subnet UCS-A /eth-flow-mon/flow-profile/vlan/fabric* # commit-buffer UCS-A /eth-flow-mon/flow-profile/vlan/fabric # Configuring a Netflow Collector UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-collector flow-collector-name UCS-A /eth-flow-mon/flow-collector # set dest-port port_number Enters the ethernet flow monitor mode. Enters the flow collector mode for the specified flow collector. Specifies the destination port for the flow collector. Step 4 Step 5 Step 6 Step 7 Step 8 UCS-A /eth-flow-mon/flow-collector # set vlan vlan_id UCS-A /eth-flow-mon/flow-collector # enter ip-if UCS-A /eth-flow-mon/flow-collector/ip-if # set addr ip-address UCS-A /eth-flow-mon/flow-collector/ip-if # set exporter-gw gw-address UCS-A /eth-flow-mon/flow-collector/ip-if # commit-buffer Specifies the VLAN ID for the flow collector. Enters IPv4 configuration mode. Specifies the exporter IP address. Specifies the exporter gateway address. Commits the transaction to the system configuration. The following example shows how to configure a NetFlow collector, set the exporter IP and gateway address, and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-collector c1 UCS-A /eth-flow-mon/flow-collector* # set dest-port 9999 UCS-A /eth-flow-mon/flow-collector* # set vlan vlan100 UCS-A /eth-flow-mon/flow-collector* # enter ip-if UCS-A /eth-flow-mon/flow-collector/ip-if* # set addr UCS-A /eth-flow-mon/flow-collector/ip-if* # set exporter-gw UCS-A /eth-flow-mon/flow-collector/ip-if* # commit-buffer UCS-A /eth-flow-mon/flow-collector/ip-if # 139

154 Configuring a Flow Exporter Netflow Monitoring Configuring a Flow Exporter UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-exporter flow-exporter-name Enters the ethernet flow monitor mode. Enters the flow exporter mode for the specified flow exporter. UCS-A /eth-flow-mon/flow-exporter # set dscp dscp_number Specifies the differentiated services code point. Step 4 Step 5 Step 6 Step 7 Step 8 UCS-A /eth-flow-mon/flow-exporter # set flow-collector flow-collector_name UCS-A /eth-flow-mon/flow-exporter # set exporter-stats-timeout timeout_number UCS-A /eth-flow-mon/flow-exporter # set interface-table-timeout timeout_number UCS-A /eth-flow-mon/flow-exporter # set template-data-timeout timeout_number UCS-A /eth-flow-mon/flow-exporter # commit-buffer Specifies the flow collector. Specifies the timeout period for resending NetFlow flow exporter data. Specifies the time period for resending the NetFlow flow exporter interface table. Specifies the timeout period for resending NetFlow template data. Commits the transaction to the system configuration. The following example shows how to configure a flow exporter, set the timeout values, and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-exporter ex1 UCS-A /eth-flow-mon/flow-exporter* # set dscp 6 UCS-A /eth-flow-mon/flow-exporter* # set flow-collector c1 UCS-A /eth-flow-mon/flow-exporter* # set exporter-stats-timeout 600 UCS-A /eth-flow-mon/flow-exporter* # set interface-table-timeout 600 UCS-A /eth-flow-mon/flow-exporter* # set template-data-timeout 600 UCS-A /eth-flow-mon/flow-exporter* # commit-buffer UCS-A /eth-flow-mon/flow-exporter # Configuring a Flow Monitor UCS-A# scope eth-flow-mon Enters the ethernet flow monitor mode. 140

155 Netflow Monitoring Configuring a Flow Monitor Session Step 4 Step 5 Step 6 UCS-A /eth-flow-mon # enter flow-monitor flow-monitor-name UCS-A /eth-flow-mon/flow-monitor # set flow-record flow-record-name UCS-A /eth-flow-mon/flow-monitor # create flow-exporter flow-exporter-name UCS-A /eth-flow-mon/flow-monitor # create flow-exporter flow-exporter-name UCS-A /eth-flow-mon/flow-monitor # commit-buffer Enters the flow monitor mode for the specified flow monitor. Specifies the flow record. Specifies the first flow exporter. Specifies the second flow exporter. Commits the transaction to the system configuration. The following example shows how to create a flow monitor and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-monitor m1 UCS-A /eth-flow-mon/flow-monitor* # set flow-record r1 UCS-A /eth-flow-mon/flow-monitor* # create flow-exporter ex1 UCS-A /eth-flow-mon/flow-monitor* # create flow-exporter ex2 UCS-A /eth-flow-mon/flow-monitor* # commit-buffer UCS-A /eth-flow-mon/flow-monitor # Configuring a Flow Monitor Session UCS-A# scope eth-flow-mon Enters the ethernet flow monitor mode. Step 4 Step 5 UCS-A /eth-flow-mon # enter flow-mon-session flow-monitor-session-name UCS-A /eth-flow-mon/flow-mon-session # create flow-monitor flow-monitor-1 UCS-A /eth-flow-mon/flow-mon-session # create flow-monitor flow-monitor-2 UCS-A /eth-flow-mon/flow-mon-session # commit-buffer Enters the flow monitor session mode for the specified flow monitor session. Specifies the first flow monitor. Specifies the second flow monitor. Commits the transaction to the system configuration. The following example shows how to create a flow monitor session with two flow monitors: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # enter flow-mon-session s1 UCS-A /eth-flow-mon/flow-mon-session* # create flow-monitor m1 UCS-A /eth-flow-mon/flow-mon-session* # create flow-monitor m2 141

156 Configuring a NetFlow Cache Active and Inactive Timeout Netflow Monitoring UCS-A /eth-flow-mon/flow-mon-session* # commit-buffer UCS-A /eth-flow-mon/flow-mon-session # Configuring a NetFlow Cache Active and Inactive Timeout UCS-A# scope eth-flow-mon Enters the ethernet flow monitor mode. UCS-A /eth-flow-mon # scope flow-timeout timeout-name Enters the flow timeout mode for the specified flow timeout. Step 4 Step 5 UCS-A /eth-flow-mon/flow-timeout # set cache-timeout-active timeout-value UCS-A /eth-flow-mon/flow-timeout # set cache-timeout-inactive timeout-value UCS-A /eth-flow-mon/flow-timeout # commit-buffer Specifies the active timeout value. This value can be between 60 and 4092 seconds. The default value is 120 seconds. Specifies the inactive timeout value. This value can be between 15 and 4092 seconds. The default value is 15 seconds. Commits the transaction to the system configuration. The following example shows how to change the NetFlow timeout values and commit the transaction: UCS-A# scope eth-flow-mon UCS-A /eth-flow-mon # scope flow-timeout default UCS-A /eth-flow-mon/flow-timeout # set cache-timeout-active 1800 UCS-A /eth-flow-mon/flow-timeout* # set cache-timeout-inactive 20 UCS-A /eth-flow-mon/flow-timeout* # commit-buffer UCS-A /eth-flow-mon/flow-timeout # Associating a Flow Monitor Session to a vnic UCS-A# scope org org-name UCS-A /org # scope service-profile profile-name UCS-A /org/service-profile # scope vnic vnic-name Enters the organization mode for the specified organization. To enter the root organization mode, enter / as the org-name. Enters the organization service profile mode for the specified service profile. Enters the organization service profile mode for the specified vnic. 142

157 Netflow Monitoring Associating a Flow Monitor Session to a vnic Step 4 Step 5 UCS-A /org/service-profile/vnic # enter flow-mon-src flow-monitor-session-name UCS-A /org/service-profile/vnic # commit-buffer Associates the flow monitor session to the vnic. Commits the transaction to the system configuration. The following example shows how to associate the flow monitor session s1 to the vnic eth5: UCS-A# scope org / UCS-A /org # scope service-profile sp1 UCS-A /org/service-profile # scope vnic eth5 UCS-A /org/service-profile/vnic # enter flow-mon-src s1 UCS-A /org/service-profile/vnic # commit-buffer 143

158 Associating a Flow Monitor Session to a vnic Netflow Monitoring 144

159 CHAPTER 15 Traffic Monitoring Traffic Monitoring, page 145 Guidelines and Recommendations for Traffic Monitoring, page 147 Creating an Ethernet Traffic Monitoring Session, page 148 Creating a Fibre Channel Traffic Monitoring Session, page 149 Adding Traffic Sources to a Monitoring Session, page 150 Activating a Traffic Monitoring Session, page 155 Deleting a Traffic Monitoring Session, page 156 SPAN Restrictions for the Cisco UCS Mini, page 156 Traffic Monitoring Traffic monitoring copies traffic from one or more source ports and sends the copied traffic to a dedicated destination port for analysis by a network analyzer. This feature is also known as Switched Port Analyzer (SPAN). Types of Traffic Monitoring Sessions There are two types of monitoring sessions: Ethernet Fibre channel The type of destination port determines what kind of monitoring session you need. For an Ethernet traffic monitoring session, the destination port must be an unconfigured physical port. For a Fibre Channel traffic monitoring session, the destination port must be a Fibre Channel uplink port except when you are using Cisco UCS 6300 Fabric Interconnects. Note For Cisco UCS 6332 and UP Fabric Interconnects, you cannot choose Fibre Channel destination ports. The destination port must be an unconfigured physical Ethernet port. 145