R3.3 Beta Draft—Cisco Confidential Information
Cisco IOS XR System Management Configuration Guide Cisco IOS XR Software Release 3.3
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
Text Part Number: OL-5550-05
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.
qgg g y ggy y iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website 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. (0601R)
Cisco IOS XR System Management Configuration Guide Copyright © 2005 Cisco Systems, Inc. All rights reserved. R3.3 Beta Draft—Cisco Confidential Information
Preface SMR-xiii Changes to This Document SMR-xiii Obtaining Documentation SMR-xiv Cisco.com SMR-xiv Product Documentation DVD SMR-xv Ordering Documentation SMR-xv Documentation Feedback SMR-xv Cisco Product Security Overview SMR-xv Reporting Security Problems in Cisco Products SMR-xvi Obtaining Technical Assistance SMR-xvi Cisco Technical Support & Documentation Website SMR-xvii Submitting a Service Request SMR-xvii Definitions of Service Request Severity SMR-xvii Obtaining Additional Publications and Information SMR-xviii
Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software SMR-1 Contents SMR-1 Prerequisites for Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software SMR-2 Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software SMR-2 Alarm Logging and Debugging Event Management System SMR-2 Logging Correlation SMR-4 Alarm Severity Level and Filtering SMR-5 Bistate Alarms SMR-6 Capacity Threshold Setting for Alarms SMR-6 How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software SMR-6 Configuring Logging Correlation Rules SMR-7 Applying Logging Correlation Rules SMR-10 Modifying Logging Events Buffer Settings SMR-11 Modifying Logging Correlator Buffer Settings SMR-13 Displaying Alarms by Severity and Severity Range SMR-15 Displaying Alarms According to a Time Stamp Range SMR-16 Displaying Alarms According to Message Group and Message Code SMR-18
Cisco IOS XR System Management Configuration Guide OL-5550-05 iii Contents
Displaying Alarms According to a First and Last Range SMR-19 Displaying Alarms by Location SMR-20 Displaying Alarms by Event Record ID SMR-20 Displaying the Logging Correlation Buffer Size, Messages, and Rules SMR-21 Clearing Alarm Event Records and Resetting Bistate Alarms SMR-22 Configuration Examples for Alarm Management and Logging Correlation SMR-24 Increasing the Severity Level for Alarm Filtering to Display Fewer Events and Modifying the Alarm Buffer Size and Capacity Threshold: Example SMR-25 Configuring a Correlation Rule for the SYS CONFIG_I Alarm: Example SMR-25 Configuring a Correlation Rule for LINK UPDOWN and SONET ALARM Alarms: Example SMR-26 Additional References SMR-29 Related Documents SMR-29 Standards SMR-29 MIBs SMR-29 RFCs SMR-30 Technical Assistance SMR-30
Implementing CDP on Cisco IOS XR Software SMR-31 Contents SMR-31 Prerequisites for Implementing CDP on Cisco IOS XR Software SMR-32 Information About Implementing CDP on Cisco IOS XR Software SMR-32 CDP Functional Overview SMR-32 How to Implement CDP on Cisco IOS XR Software SMR-33 Enabling CDP SMR-33 Modifying CDP Default Settings SMR-35 Monitoring CDP SMR-36 Configuration Examples for Implementing CDP on Cisco IOS XR Software SMR-39 Enabling CDP: Example SMR-39 Modifying Global CDP Settings: Example SMR-39 Additional References SMR-40 Related Documents SMR-40 Standards SMR-40 MIBs SMR-40 RFCs SMR-41 Technical Assistance SMR-41
Implementing IP Service Level Agreements on Cisco IOS XR Software SMR-43 Contents SMR-43 Prerequisites for Implementing IP Service Level Agreements SMR-44
Cisco IOS XR System Management Configuration Guide iv OL-5550-05 Contents
Restrictions for Implementing IP Service Level Agreements SMR-44 Information About Implementing IP Service Level Agreements SMR-44 About IP Service Level Agreements Technology SMR-44 Service Level Agreements SMR-45 Benefits of IP Service Level Agreements SMR-46 Measuring Network Performance with IP Service Level Agreements SMR-46 Operation Types for IP Service Level Agreements SMR-48 IP SLA Responder and IP SLA Control Protocol SMR-48 Response Time Computation for IP SLA SMR-49 IP SLA Operation Scheduling SMR-49 How to Implement IP Service Level Agreements SMR-49 Configuring IP Service Levels Using the UDP Jitter Operation SMR-50 Configuring the IP SLA for a UDP Echo Operation SMR-60 Configuring an ICMP Echo Operation SMR-68 Configuring the ICMP Path Echo Operation SMR-75 Configuring the ICMP Path Jitter Operation SMR-82 Configuration Examples for Implementing IP Service Level Agreements SMR-90 Configuring IP Service Level Agreements: Example SMR-90 Additional References SMR-90 Related Documents SMR-91 Standards SMR-91 MIBs SMR-91 RFCs SMR-91 Technical Assistance SMR-91
Configuring and Managing Fault Management Policies on Cisco IOS XR Software SMR-93 Contents SMR-94 Prerequisites for Configuring and Managing Fault Management Policies SMR-94 Information About Configuring and Managing Fault Management Policies SMR-95 Fault Management SMR-95 Fault Management Policies SMR-96 Fault Management Scripts and the Scripting Interface (Tcl) SMR-96 Fault Manager Built-In Actions SMR-99 Application-Specific Fault Management SMR-99 Fault Detection and Recovery SMR-99 Fault Manager Event Scheduling and Notification SMR-102 Reliability Statistics SMR-102 How to Configure and Manage Fault Management Policies SMR-104 Configuring Environmental Variables SMR-104
Cisco IOS XR System Management Configuration Guide OL-5550-05 v Contents
Registering Fault Manager Policies SMR-106 Configuration Examples for Fault Management Policies SMR-110 Environmental Variables Configuration: Example SMR-110 User-Defined Fault Management Policy Registration: Example SMR-110 Display Available Policies: Example SMR-110 Display Fault Manager Process: Example SMR-110 Additional References SMR-111 Related Documents SMR-111 Standards SMR-112 MIBs SMR-112 RFCs SMR-112 Technical Assistance SMR-112
Implementing Logging Services on Cisco IOS XR Software SMR-113 Contents SMR-113 Prerequisites for Implementing Logging Services on Cisco IOS XR Software SMR-114 Information About Implementing Logging Services on Cisco IOS XR Software SMR-114 System Logging Process SMR-114 Format of System Logging Messages SMR-114 Syslog Message Destinations SMR-115 Syslog Messages Sent to Syslog Servers SMR-116 UNIX Syslog Daemon Configuration SMR-118 Severity Levels SMR-118 How to Implement Logging Services on Cisco IOS XR Software SMR-120 Configuring Logging to the Console Terminal and the Logging Buffer SMR-120 Setting Up Destinations for System Logging Messages SMR-122 Configuring Logging to a Remote Server SMR-124 Configuring the Settings for the Logging History Table SMR-126 Modifying the Format of Time Stamps SMR-129 Disabling Time Stamps SMR-131 Suppressing Duplicate Syslog Messages SMR-132 Disabling the Logging of Link-Status Syslog Messages SMR-133 Displaying System Logging Messages SMR-134 Configuration Examples for Implementing Logging Services on Cisco IOS XR Software SMR-138 Configuring Logging to the Console Terminal and the Logging Buffer: Example SMR-139 Setting Up Destinations for Syslog Messages: Example SMR-139 Configuring the Settings for the Logging History Table: Example SMR-139 Modifying Time Stamps: Example SMR-139 Where to Go Next SMR-140
Cisco IOS XR System Management Configuration Guide vi OL-5550-05 Contents
Additional References SMR-140 Related Documents SMR-140 Standards SMR-140 MIBs SMR-140 RFCs SMR-141 Technical Assistance SMR-141
Implementing NTP on Cisco IOS XR Software SMR-143 Contents SMR-143 Prerequisites for Implementing NTP on Cisco IOS XR Software SMR-144 Information About Implementing NTP on Cisco IOS XR Software SMR-144 NTP Functional Overview SMR-144 How to Implement NTP on Cisco IOS XR Software SMR-145 Configuring Poll-Based Associations SMR-145 Configuring Broadcast-Based NTP Associations SMR-147 Configuring NTP Access Groups SMR-149 Configuring NTP Authentication SMR-152 Disabling NTP Services on a Specific Interface SMR-154 Configuring the Source IP Address for NTP Packets SMR-156 Configuring the System as an Authoritative NTP Server SMR-158 Updating the Hardware Clock SMR-159 Verifying the Status of the External Reference Clock SMR-161 Configuration Examples for Implementing NTP on Cisco IOS XR Software SMR-162 Configuring Poll-Based Associations: Example SMR-162 Configuring Broadcast-Based Associations: Example SMR-162 Configuring NTP Access Groups: Example SMR-163 Configuring NTP Authentication: Example SMR-163 Disabling NTP on an Interface: Example SMR-165 Configuring the Source IP Address for NTP Packets: Example SMR-165 Configuring the System as an Authoritative NTP Server: Example SMR-165 Updating the Hardware Clock: Example SMR-166 Additional References SMR-166 Related Documents SMR-166 Standards SMR-166 MIBs SMR-166 RFCs SMR-167 Technical Assistance SMR-167
Implementing Performance Management on Cisco IOS XR Software SMR-169 Contents SMR-169
Cisco IOS XR System Management Configuration Guide OL-5550-05 vii Contents
Prerequisites for Implementing Performance Management on Cisco IOS XR Software SMR-170 Information About Implementing Performance Management on Cisco IOS XR Software SMR-170 PM Functional Overview SMR-170 PM Statistics Collection Overview SMR-172 PM Entity Instance Monitoring Overview SMR-177 PM Threshold Monitoring Overview SMR-181 How to Implement Performance Management on Cisco IOS XR Software SMR-190 Configuring an External TFTP Server for PM Statistic Collections SMR-190 Creating PM Statistics Collection Templates SMR-192 Enabling and Disabling PM Statistics Collection Templates SMR-193 Enabling PM Entity Instance Monitoring SMR-196 Creating PM Threshold Monitoring Templates SMR-198 Enabling and Disabling PM Threshold Monitoring Templates SMR-199 Configuration Examples for Implementing Performance Management on Cisco IOS XR Software SMR-202 Creating and Enabling PM Statistics Collection Templates: Example SMR-202 Creating and Enabling PM Threshold Monitoring Templates: Example SMR-202 Additional References SMR-203 Related Documents SMR-203 Standards SMR-203 MIBs SMR-203 RFCs SMR-204 Technical Assistance SMR-204
Process Placement on Cisco IOS XR Software SMR-205 Contents SMR-205 Prerequisites for Configuring Cisco IOS XR Process Placement SMR-206 Restrictions for Cisco IOS XR Process Placement SMR-206 Information About Cisco IOS XR Process Placement SMR-206 What Is a Process? SMR-206 What Is Process Placement? SMR-207 Default Placement Policy SMR-207 Reasons to Change the Default Process Placement SMR-207 Reoptimizing Process Placements SMR-208 Reconfiguring Process Placements SMR-208 How to Configure Cisco IOS XR Process Placement SMR-211 Reomptimizing Process Placement SMR-211 Setting Memory Consumption Thresholds SMR-212 Creating a Location Set Affinity SMR-213
Cisco IOS XR System Management Configuration Guide viii OL-5550-05 Contents
Creating a Location Type Affinity SMR-215 Creating a Program Affinity SMR-217 Creating a Self Affinity SMR-218 Additional References SMR-220 Related Documents SMR-220 Standards SMR-220 MIBs SMR-221 RFCs SMR-221 Technical Assistance SMR-221
Configuring Secure Domain Routers on Cisco IOS XR Software 223 Contents 223 Prerequisites for Configuring Secure Domain Routers 224 Information About Configuring Secure Domain Routers 224 What Is a Secure Domain Router? 225 Owner SDR and Admin Configuration Mode 225 Non-owner SDRs 226 SDR Access Privileges 226 Designated Secure Domain Router System Controller (DSDRSC) 227 High Availability Implications 230 Cisco IOS XR Software Installation 231 Caveats 231 How to Configure Secure Domain Routers 232 Contents 232 Creating SDRs 232 Adding Nodes to a Non-owner SDR 241 Removing Nodes and SDRs 245 Configuring a Username and Password for a Non-owner SDR 251 Disabling Remote Login for SDRs 255 Configuration Examples for Secure Domain Routers 257 Additional References 258 Related Documents 258 Standards 259 MIBs 259 RFCs 259 Technical Assistance 259
Implementing Physical and Virtual Terminals on Cisco IOS XR Software SMR-261 Contents SMR-261
Cisco IOS XR System Management Configuration Guide OL-5550-05 ix Contents
Prerequisites for Implementing Physical and Virtual Terminals on Cisco IOS XR Software SMR-262 Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software SMR-262 Line Templates SMR-262 Line Template Configuration Mode SMR-262 Line Template Guidelines SMR-263 Terminal Identification SMR-264 vty Pools SMR-264 How to Implement Physical and Virtual Terminals on Cisco IOS XR Software SMR-266 Modifying Templates SMR-266 Creating and Modifying vty Pools SMR-268 Monitoring Terminals and Terminal Sessions SMR-270 Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software SMR-271 Modifying the Console Template: Example SMR-272 Modifying the Aux Template: Example SMR-272 Modifying the Default Template: Example SMR-273 Configuring a User-Defined Template to Reference the Default vty Pool: Example SMR-273 Configuring a User-Defined Template to Reference a User-Defined vty Pool: Example SMR-273 Configuring a User-Defined Template to Reference the Fault Manager vty Pool: Example SMR-274 Additional References SMR-274 Related Documents SMR-275 Standards SMR-275 MIBs SMR-275 RFCs SMR-276 Technical Assistance SMR-276
Implementing SNMP on Cisco IOS XR Software SMR-277 Contents SMR-277 Prerequisites for Implementing SNMP on Cisco IOS XR Software SMR-278 Information About Implementing SNMP on Cisco IOS XR Software SMR-278 SNMP Functional Overview SMR-278 SNMP Notifications SMR-279 SNMP Versions SMR-280 SNMPv3 Benefits SMR-282 SNMPv3 Costs SMR-282 How to Implement SNMP on Cisco IOS XR Software SMR-284 Configuring SNMPv3 SMR-284 Configuring SNMP Trap Notifications SMR-287 Setting the Contact, Location, and Serial Number of the SNMP Agent SMR-289
Cisco IOS XR System Management Configuration Guide x OL-5550-05 Contents
Defining the Maximum SNMP Agent Packet Size SMR-290 Changing Notification Operation Values SMR-292 Configuration Examples for Implementing SNMP on Cisco IOS XR Software SMR-293 Configuring SNMPv3: Example SMR-293 Configuring Trap Notifications: Example SMR-296 Additional References SMR-297 Related Documents SMR-297 Standards SMR-297 MIBs SMR-297 RFCs SMR-298 Technical Assistance SMR-298
Cisco IOS XR System Management Configuration Guide OL-5550-05 xi Contents
Cisco IOS XR System Management Configuration Guide xii OL-5550-05 R3.3 Beta Draft—Cisco Confidential Information
Preface
Beta Draft Cisco Confidential Information
This book presents configuration information and examples for System Management of the Cisco IOS XR software. The preface for the Cisco IOS XR System Management Configuration Guide consists of the following sections: • Changes to This Document, page xiii • Obtaining Documentation, page xiv • Documentation Feedback, page xv • Cisco Product Security Overview, page xv • Obtaining Technical Assistance, page xvi • Obtaining Additional Publications and Information, page xviii
Changes to This Document
The Document Revision History table below records technical changes to this document. The table shows the document revision number for the change, the date of the change, and a brief summary of the change. Note that not all Cisco documents use a Document Revision History table.
Table 1 Document Revision History
Revision Date Change Summary OL-5557-05 February 2005 “Implementing IP Service Level Agreements on Cisco IOS XR Software”. This feature was introduced on the Cisco CRS-1. “Configuring and Managing Fault Management Policies on Cisco IOS XR Software”. Support was added for AAA au- thentication when executing a script.
Cisco IOS XR System Management Configuration Guide xiii Preface Obtaining Documentation
Table 1 Document Revision History
Revision Date Change Summary “Configuring Secure Domain Routers on Cisco IOS XR Software”. Added this module to the System Management book, including the following revisions: • The term Logical Router (LR) was changed to Secure Domain Router (SDR). • Support was added for the Cisco CRS-1. – Support was added for DRPs and DRP pairs in the Cisco CRS-1. – The primary designation is now required for the dSDRSC in each SDR in the Cisco CRS-1. – Support was added for Cisco CRS-1 multishelf configuration. • Added support for SDR-specific software package activation. “Process Placement on Cisco IOS XR Software”. This feature was introduced. Editorial changes were made to the document. OL-5557-05 May 2005 Added new Implementing CDP module. Added new Implenting Logging Services module. Added new Implementing NTP module. Modified the examples in Implementing Performance Man- agement module to reflect the changes in command syntax.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL: http://www.cisco.com/techsupport You can access the Cisco website at this URL: http://www.cisco.com You can access international Cisco websites at this URL: http://www.cisco.com/public/countries_languages.shtml
Cisco IOS XR System Management Configuration Guide xiv Preface Documentation Feedback
Product Documentation DVD
Cisco documentation and additional literature are available in the Product Documentation DVD package, which may have shipped with your product. The Product Documentation DVD is updated regularly and may be more current than printed documentation. The Product Documentation DVD is a comprehensive library of technical product documentation on portable media. The DVD enables you to access multiple versions of hardware and software installation, configuration, and command guides for Cisco products and to view technical documentation in HTML. With the DVD, you have access to the same documentation that is found on the Cisco website without being connected to the Internet. Certain products also have .pdf versions of the documentation available. The Product Documentation DVD is available as a single unit or as a subscription. Registered Cisco.com users (Cisco direct customers) can order a Product Documentation DVD (product number DOC-DOCDVD=) from Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/
Ordering Documentation
Beginning June 30, 2005, registered Cisco.com users may order Cisco documentation at the Product Documentation Store in the Cisco Marketplace at this URL: http://www.cisco.com/go/marketplace/ Nonregistered Cisco.com users can order technical documentation from 8:00 a.m. to 5:00 p.m. (0800 to 1700) PDT by calling 1 866 463-3487 in the United States and Canada, or elsewhere by calling 011 408 519-5055. You can also order documentation by e-mail at [email protected] or by fax at 1 408 519-5001 in the United States and Canada, or elsewhere at 011 408 519-5001.
Documentation Feedback
You can rate and provide feedback about Cisco technical documents by completing the online feedback form that appears with the technical documents on Cisco.com. You can send comments about Cisco documentation to [email protected]. You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address: Cisco Systems Attn: Customer Document Ordering 170 West Tasman Drive San Jose, CA 95134-9883 We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL: http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
Cisco IOS XR System Management Configuration Guide xv Preface Obtaining Technical Assistance
From this site, you can perform these tasks: • Report security vulnerabilities in Cisco products. • Obtain assistance with security incidents that involve Cisco products. • Register to receive security information from Cisco. A current list of security advisories and notices for Cisco products is available at this URL: http://www.cisco.com/go/psirt If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL: http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT: • Emergencies—[email protected] An emergency is either a condition in which a system is under active attack or a condition for which a severe and urgent security vulnerability should be reported. All other conditions are considered nonemergencies. • Nonemergencies—[email protected] In an emergency, you can also reach PSIRT by telephone: • 1 877 228-7302 • 1 408 525-6532
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one linked in the Contact Summary section of the Security Vulnerability Policy page at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
The link on this page has the current PGP key ID in use.
Obtaining Technical Assistance
Cisco Technical Support provides 24-hour-a-day award-winning technical assistance. The Cisco Technical Support & Documentation website on Cisco.com features extensive online support resources. In addition, if you have a valid Cisco service contract, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not have a valid Cisco service contract, contact your reseller.
Cisco IOS XR System Management Configuration Guide xvi Preface Obtaining Technical Assistance
Cisco Technical Support & Documentation Website
The Cisco Technical Support & Documentation website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, at this URL: http://www.cisco.com/techsupport Access to all tools on the Cisco Technical Support & Documentation website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL: http://tools.cisco.com/RPF/register/register.do
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support & Documentation website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco engineer. The TAC Service Request Tool is located at this URL: http://www.cisco.com/techsupport/servicerequest For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly. To open a service request by telephone, use one of the following numbers: Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227) EMEA: +32 2 704 55 55 USA: 1 800 553-2447 For a complete list of Cisco TAC contacts, go to this URL: http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Cisco IOS XR System Management Configuration Guide xvii Preface Obtaining Additional Publications and Information
Severity 1 (S1)—Your network is “down,” or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation. Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation. Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels. Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources. • Cisco Marketplace provides a variety of Cisco books, reference guides, documentation, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL: http://www.cisco.com/go/marketplace/ • Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL: http://www.ciscopress.com • Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL: http://www.cisco.com/packet • iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL: http://www.cisco.com/go/iqmagazine or view the digital edition at this URL: http://ciscoiq.texterity.com/ciscoiq/sample/ • Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL: http://www.cisco.com/ipj • Networking products offered by Cisco Systems, as well as customer support services, can be obtained at this URL: http://www.cisco.com/en/US/products/index.html
Cisco IOS XR System Management Configuration Guide xviii Preface Obtaining Additional Publications and Information
• Networking Professionals Connection is an interactive website for networking professionals to share questions, suggestions, and information about networking products and technologies with Cisco experts and other networking professionals. Join a discussion at this URL: http://www.cisco.com/discuss/networking • World-class networking training is available from Cisco. You can view current offerings at this URL: http://www.cisco.com/en/US/learning/index.html
Cisco IOS XR System Management Configuration Guide xix Preface Obtaining Additional Publications and Information
Cisco IOS XR System Management Configuration Guide xx R3.3 Beta Draft—Cisco Confidential Information
Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
This module describes the concepts and tasks related to configuring alarm log correlation and monitoring alarm logs and correlated event records. Alarm log correlation extends system logging to include the ability to group and filter messages generated by various applications and system servers and isolate root messages on the router. This module describes the new and revised tasks you need to implement logging correlation and monitor alarms on your Cisco IOS XR network.
Note For more information about system logging on the Cisco IOS XR software and complete descriptions of the alarm management and logging correlation commands listed in this module, you can see the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of performing a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification Release 3.2 This feature was supported on the Cisco XR 12000 Series Router. Release 3.3 No modification.
Contents
• Prerequisites for Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software, page 2 • Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software, page 2 • How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software, page 6
Cisco IOS XR System Management Configuration Guide SMR-1 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Prerequisites for Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
• Configuration Examples for Alarm Management and Logging Correlation, page 24 • Additional References, page 29
Prerequisites for Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software
You must be in a user group associated with a task group that includes the proper task IDs for alarm management and logging correlation commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software
To implement alarms and alarm correlation, you should be familiar with the following concepts: • Alarm Logging and Debugging Event Management System, page 2 • Logging Correlation, page 4 • Alarm Severity Level and Filtering, page 5 • Bistate Alarms, page 6 • Capacity Threshold Setting for Alarms, page 6
Alarm Logging and Debugging Event Management System
Alarm log correlation is one aspect of the Cisco IOS XR software Alarm Logging and Debugging Event Management System (ALDEMS), which is used to monitor and store alarm messages that are emitted by system servers and applications and correlate alarm messages emitted due to a single root cause. ALDEMS enlarges on the basic logging and monitoring functionality of the Cisco IOS XR software, providing the level of alarm and event management necessary for a highly distributed system with potentially hundreds of modular service cards (MSCs) and thousands of interfaces. The Cisco IOS XR software achieves this necessary level of alarm and event management by distributing logging applications across the nodes on the system.
Cisco IOS XR System Management Configuration Guide SMR-2 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Figure 1 illustrates the relationship between the components that constitute ALDEMS.
Figure 1 ALDEMS Component Communications
Remote Craft Web Interface Console Server
Route Processor XML agent
Alarm logger
Syslog process
Correlator
Syslog helper process
RP 117361
MSC MSC
Correlator
The correlator receives messages from system logging (syslog) helper processes that are distributed across the nodes on the router and forwards syslog messages to the syslog process. If a logging correlation rule is configured, the correlator captures messages, beginning with the first occurrence of a message from the set of messages specified in the correlation rule, and continuing for the interval specified in the timeout interval of the correlation rule.The logging correlator buffer, which resides in the correlator, stores all correlated messages captured after a root message is received. The correlator tags correlated messages in the logging correlator buffer with the correlation ID that it assigns to the originating root message.
Note For more information about logging correlation, see the “Logging Correlation” section.
Cisco IOS XR System Management Configuration Guide SMR-3 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
System Logging Process
By default, routers are configured to send system logging messages to a system logging (syslog) process. Syslog messages are gathered by syslog helper processes that are distributed across the nodes on the system. The system logging process controls the distribution of logging messages to the various destinations, such as the system logging buffer, the console, terminal lines, or a syslog server, depending on the network device configuration.
Alarm Logger
The alarm logger is the final destination for system logging messages emitted on the router. The alarm logger stores alarm messages in the logging events buffer. The logging events buffer is circular; that is, when full it overwrites the oldest messages in the buffer.
Note Alarms are prioritized in the logging events buffer. When it is necessary to overwrite an alarm record, the logging events buffer will overwrite messages in the following order: normal alarms first, then bistate alarms in the CLEAR state, and, finally, bistate alarms in the SET state. For more information about bistate alarms, see the “Bistate Alarms” section.
When the table becomes full of messages caused by bistate alarms in the SET state, the earliest bistate message (based on the message time stamp, not arrival time) is reclaimed before others. The buffer size for the logging events buffer and the logging correlation buffer, thus, should be adjusted so that memory consumption is within your requirements. A table-full alarm is generated each time the logging events buffer wraps around. A threshold crossing notification is generated each time the logging events buffer reaches the capacity threshold. Messages stored in the logging events buffer can be queried by clients to locate records matching specific criteria. The alarm logging mechanism assigns a sequential, unique ID to each alarm message.
Logging Correlation
Logging correlation groups messages emitted due to a shared root cause. One instance of the correlator runs on the active route processor (RP). The correlator receives messages from system logging helper processes that are distributed across each node on the system. When correlation rules are configured, the correlator scans messages for the target fields matching the specifications defined in correlation rules. Logging correlation can be used to isolate the most significant root messages for events affecting system performance. For example, the original message describing a card online insertion and removal (OIR) of a Modular Service Card (MSC) can be isolated so that only the root message is displayed and all subsequent messages reiterating the same event are correlated. When correlation rules are configured, a common root event that is generating larger volumes of follow-on error messages can be isolated and sent to the logging events buffer. An operator can pull up all correlated messages from the logging correlator buffer for display, should the need arise.
Correlation Rules
Correlation rules can be configured to isolate root messages that may generate system alarms. Correlation rules prevent unnecessary stress on ALDEMS caused by the accumulation of unnecessary messages. Each correlation rule hinges on a message identification, consisting of a message category,
Cisco IOS XR System Management Configuration Guide SMR-4 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Information About Implementing Alarms and Alarm Log Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
message group name, and message code. The correlator process scans messages for occurrences of the message. Up to 10 messages may be specified in a correlation rule, to give the rule a narrow (fewer messages) or a wide (more messages) scope. The first message in the correlation rule configuration is considered the root message. If the correlator receives a root message, the correlator stores it in the logging correlator buffer and also forwards it to the syslog process on the RP. From there, the syslog process forwards the root message to the alarm logger in which it is stored in the logging events buffer. From the syslog process, the root message may also be forwarded to destination such as the console, remote terminals, remote servers, the fault management system, and the Simple Network Management Protocol (SNMP) agent, depending on the network device configuration. Subsequent messages meeting the same criteria (including another occurrence of the root message) are stored in the logging correlation buffer and are forwarded to syslog process on the RP. If a message matches multiple correlation rules, all matching rules apply and the message becomes a part of all matching correlation queues in the logging correlator buffer. The message fields that are used to define a message in a logging correlation rule are as follows: • Message category • Message group • Message code Wildcards can be used for any of the message fields to cover wider set of messages. Configure the appropriate set of messages in a logging correlation rule configuration to achieve correlation with a narrow or wide scope (depending on your objective).
Root Message and Correlated Messages
When a correlation rule is applied, the timeout for the rule begins with the first occurrence of a message from the set of messages specified in a correlation rule. The first message (with category, group, and code triplet) configured in a correlation rule defines the root message. A root message is always forwarded to the logging events buffer. See the “Correlation Rules” section to learn how the root message is forward and stored. When the timeout for the correlation rule expires, leaf messages that do not have an associated root message are forwarded to the logging events buffer. All subsequent messages from the message set in the correlation rule are stored in the logging correlation buffer.
Alarm Severity Level and Filtering
Filter settings can be used to display information based on severity level. The alarm filter display indicates the severity level settings used to report alarms, the number of records, and the current and maximum log size. Alarms can be filtered according to the severity level shown in Table 2. Table 2 Alarm Severity Levels for Event Logging
Severity Level System Condition 0 Emergencies 1Alerts 2 Critical
Cisco IOS XR System Management Configuration Guide SMR-5 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Table 2 Alarm Severity Levels for Event Logging (continued)
Severity Level System Condition 3 Errors 4 Warnings 5 Notifications 6 Informational
Bistate Alarms
Bistate alarms are generated by state changes associated with system hardware, such as a change of interface state from active to inactive, the online insertion and removal (OIR) of a modular service card (MSC), or a change in component temperature. Bistate alarm events are reported to the logging events buffer by default; informational and debug messages are not. The Cisco IOS XR software provides the ability to reset and clear alarms. Clients interested in monitoring alarms in the system can register with the alarm logging mechanism to receive asynchronous notifications when a monitored alarm changes state. Bistate alarm notifications provide the following information: • The origination ID, which uniquely identifies the resource that causes an alarm to be raised or cleared. This resource may be an interface, a line card, or an application-specific integrated circuit (ASIC). The origination ID is a unique combination of the location, job ID, message group, and message context. • The alarm state, which may be in the SET state or CLEAR state.
Capacity Threshold Setting for Alarms
The capacity threshold setting determines when the alarm system begins reporting threshold crossing alarms. The capacity threshold for generating warning alarms is generally set at 80 percent of buffer capacity, but individual configurations may require different settings.
How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software
This section contains the following tasks: • Configuring Logging Correlation Rules, page 7 (required) • Applying Logging Correlation Rules, page 10 (required) • Modifying Logging Events Buffer Settings, page 11 (optional) • Modifying Logging Correlator Buffer Settings, page 13 (optional) • Displaying Alarms by Severity and Severity Range, page 15 (optional) • Displaying Alarms According to a Time Stamp Range, page 16 (optional) • Displaying Alarms According to Message Group and Message Code, page 18 (optional)
Cisco IOS XR System Management Configuration Guide SMR-6 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
• Displaying Alarms According to a First and Last Range, page 19 (optional) • Displaying Alarms by Location, page 20 (optional) • Displaying Alarms by Event Record ID, page 20 (optional) • Displaying the Logging Correlation Buffer Size, Messages, and Rules, page 21 (optional) • Clearing Alarm Event Records and Resetting Bistate Alarms, page 22 (optional)
Configuring Logging Correlation Rules
This task explains how to configure logging correlation rules. The purpose of configuring logging correlation rules is to specify the messages (with message category, group and code combinations) for logging correlation. The originating root message (a message containing the same message category, group, and code, as defined in the root message in correlation rule configuration) is sent to the logging events buffer and all subsequent messages are sent to the logging correlation buffer. The fields inside a message that can be used for configuring correlation rules are as follows: Message category (for example, PKT_INFRA, MGBL, OS) Message group (for example, LINK, LINEPROTO, or OIR) Message code (for example, UPDOWN or GO_ACTIVE). The logging correlator mechanism, running on the active RP, begins queueing messages matching the ones specified in the correlation rules for the time specified in the timeout interval of the correlation rule. The timeout interval begins once the correlator captures the root message. The first message category, group, and code message triplet in the correlation rule configuration defines the root message. Subsequent triplets define the leaves.
SUMMARY STEPS
1. show logging correlator rule all 2. show logging correlator rule correlation-rule 3. configure 4. logging correlator rule correlation-rule timeout milliseconds message-category message-group message-code [message-category message-group message-code] 5. end or commit 6. show logging correlator rule [all | correlation-rule]
Cisco IOS XR System Management Configuration Guide SMR-7 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show logging correlator rule all (Optional) Displays all logging correlation rules that are configured. Example: • The output describes the configuration of each rule RP/0/RP0/CPU0:router# show logging correlator name, including the message category, group, and code rule all information. Step 2 show logging correlator rule correlation-rule (Optional) Displays the specified logging correlation rule. • Correlation rules can also be displayed individually, by Example: rule name. RP/0/RP0/CPU0:router# show logging correlator rule oir Step 3 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 4 logging correlator rule correlation-rule Configures a logging correlation rule. timeout milliseconds message-category message-group message-code • In this example, a correlation rule named test with a timeout of 60,000 milliseconds is configured. The rule defines the message MGBL LIBTARCFG COMMIT Example: as the root message and the message MGBL SYS RP/0/RP0/CPU0:router(config)# logging CONFIG_I as a leaf message. correlator rule test timeout 60000 MGBL LIBTARCFG COMMIT MGBL SYS CONFIG_I
Cisco IOS XR System Management Configuration Guide SMR-8 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 6 show logging correlator rule {all | (Optional) Displays the correlator rules that are defined. correlation-rule}
Example: RP/0/RP0/CPU0:router# show logging correlator rule all
What to Do Next
To activate a defined correlation rule, you must apply it using the logging correlator apply-rule command.
Cisco IOS XR System Management Configuration Guide SMR-9 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Applying Logging Correlation Rules
This task explains how to apply logging correlation rules. Applying a correlation rule activates it and gives a scope. A single correlation rule can be given multiple scopes on the router; that is, a rule can be applied to the entire router, a location on the router, or a context. When a correlation rule is applied to the entire router, the rule is applied by each correlator instance to all messages. When a defined correlation rule is applied to a specific location with the location keyword and node-id argument, the rule is applied by correlator instance only to the messages from the specified location. You can apply a logging correlation rule to a maximum of 32 locations. When a correlation is applied to a specific context with the context keyword and name argument, the rule is applied by correlator instance only to the messages that contain the specified context. You can apply a logging correlation rule to a maximum of 32 contexts. The logging correlator apply-rule command is cumulative; that is, the same rule name can be applied to multiple scopes.
SUMMARY STEPS
1. show logging correlator rule all 2. configure 3. logging correlator apply-rule correlation-rule all-of-router 4. logging correlator apply-rule correlation-rule location node-id 5. logging correlator apply-rule correlation-rule content name 6. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 show logging correlator rule all (Optional) Displays all logging correlation rules that have been configured. Example: • The output describes the configuration of all defined RP/0/RP0/CPU0:router# show logging correlator correlation rules, including the message pairs that are rule all used to search alarm messages in the logging events buffer. Step 2 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 3 logging correlator apply-rule correlation-rule Applies a logging correlation rule to all nodes on the router. all-of-router
Example: RP/0/RP0/CPU0:router(config)# logging correlator apply-rule rule1 all-of-router
Cisco IOS XR System Management Configuration Guide SMR-10 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 logging correlator apply-rule correlation-rule Applies a logging correlation rule to a specific node on the location node-id router. • The location of the node is specified in the format Example: rack/slot/module. RP/0/RP0/CPU0:router(config)# logging correlator apply-rule rule1 location 0/2/CPU0 Step 5 logging correlator apply-rule correlation-rule Applies a logging correlation rule to a specific context. context name • In this example, a logging correlation rule named rule2 is applied to the context POS_0_0_0_0. Example: RP/0/RP0/CPU0:router(config)# logging correlator apply-rule rule2 context POS_0_0_0_0 Step 6 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Modifying Logging Events Buffer Settings
Logging events buffer settings can be adjusted to respond to changes in user activity, network events, or system configuration events that affect network performance, or in network monitoring requirements. The appropriate settings depend on the configuration and requirements of the system. This task involves the following steps: • Modifying logging events buffer size • Setting threshold for generating alarms • Setting the alarm filter (severity)
Caution Modifications to alarm settings that lower the severity level for reporting alarms and threshold for generating capacity warning alarms may slow system performance.
Cisco IOS XR System Management Configuration Guide SMR-11 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Caution Modifying the logging events buffer size clears the buffer of all event records except for the bistate alarms in the SET state.
SUMMARY STEPS
1. show logging events info 2. configure 3. logging events buffer-size bytes 4. logging events threshold percent 5. logging events level severity 6. end or commit 7. show logging events info
DETAILED STEPS
Command or Action Purpose Step 1 show logging events info (Optional) Displays the size of logging events buffer (in bytes), percentage of the buffer that is occupied by alarm event records, capacity threshold for reporting alarms, total Example: RP/0/RP0/CPU0:router# show logging events info number of records in the buffer, and severity filter, if any. Step 2 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 3 logging events buffer-size bytes Specifies the size of the alarm record buffer. • In this example, the buffer size is set to 50000 bytes. Example: RP/0/RP0/CPU0:router(config)# logging events buffer-size 50000 Step 4 logging events threshold percent Specifies the percentage of the logging events buffer that must be filled before the alarm logger will generate a threshold crossing alarm. Example: RP/0/RP0/CPU0:router(config)# logging events • In this example, the alarm logger generates a threshold 85 threshold-crossing alarm notification when the event buffer reaches 85 percent of capacity.
Cisco IOS XR System Management Configuration Guide SMR-12 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 5 logging events level severity Sets the severity level that determines which logging events are displayed (see Table 2 under the “Alarm Severity Level and Filtering” section for a list of the severity levels). Example: RP/0/RP0/CPU0:router(config)# logging events • Keyword options are as follows: emergencies, alerts, level warnings critical, errors, warnings, notifications, and informational. • In this example, messages with a warning (level 4) severity or greater are written to the alarm log. Messages of a lesser severity (notifications and informational messages) are not recorded. Step 6 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 7 show logging events info (Optional) Displays the size of the logging events buffer (in bytes), percentage of the buffer that is occupied by alarm event records, capacity threshold for reporting alarms, total Example: RP/0/RP0/CPU0:router# show logging events info number of records in the buffer, and severity filter, if any. • This command is used to verify that all settings have been modified and that the changes have been accepted by the system.
Modifying Logging Correlator Buffer Settings
This task explains how to modify the logging correlator buffer settings. The size of the logging correlator buffer can be adjusted to accommodate the anticipated volume of incoming correlated messages. Records can be removed from the buffer by correlation ID, or the buffer can be cleared of all records.
Cisco IOS XR System Management Configuration Guide SMR-13 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
SUMMARY STEPS
1. configure 2. logging correlator buffer-size bytes 3. exit 4. show logging correlator info 5. clear logging correlator delete correlation-id 6. clear logging correlator delete all-in-buffer 7. show logging correlator buffer all-in-buffer
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 logging correlator buffer-size bytes Specifies the size of the logging correlator buffer. • In this example, the size of the logging correlator buffer Example: is set to 100,000 bytes. RP/0/RP0/CPU0:router(config)# logging correlator buffer-size 100000 Step 3 exit Exits global configuration mode and returns the router to EXEC mode. Example: RP/0/RP0/CPU0:router(config)# exit Step 4 show logging correlator info (Optional) Displays information about the size of the logging correlator buffer and percentage of the buffer occupied by correlated messages Example: RP/0/RP0/CPU0:router# show logging correlator info Step 5 clear logging correlator delete correlation-id (Optional) Removes a particular correlated event record or records from the logging correlator buffer. Example: • A range of correlation IDs can also be specified for RP/0/RP0/CPU0:router# clear logging correlator removal (up to 32 correlation IDs, separated by a delete 48 49 50 space).
Cisco IOS XR System Management Configuration Guide SMR-14 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 6 clear logging correlator delete all-in-buffer (Optional) Clears all correlated event messages from the logging correlator buffer. Example: RP/0/RP0/CPU0:router# clear logging correlator delete all-in-buffer Step 7 show logging correlator buffer all-in-buffer (Optional) Displays the contents of the correlated event record. Example: • Use this step to verify that records for particular RP/0/RP0/CPU0:router# show logging correlator correlation IDs have been removed from the correlated buffer all-in-buffer event log.
Displaying Alarms by Severity and Severity Range
This task explains how to display alarms by severity and severity range. Alarms can be displayed according to severity level or a range of severity levels. Severity levels and their respective system conditions are listed in Table 2 under the “Alarm Severity Level and Filtering” section.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging events buffer severity-lo-limit severity 2. show logging events buffer severity-hi-limit severity 3. show logging events buffer severity-hi-limit severity severity-lo-limit severity 4. show logging events buffer severity-hi-limit severity severity-lo-limit severity timestamp-lo-limit hh:mm:ss [month] [day] [year]
Cisco IOS XR System Management Configuration Guide SMR-15 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer severity-lo-limit (Optional) Displays logging events with a severity at or severity below the numeric value of the specified severity level. • In this example, alarms with a severity of notifications Example: (severity of 5) or lower are displayed. Informational RP/0/RP0/CPU0:router# show logging events (severity of 6) messages are omitted. buffer severity-lo-limit notifications Note Use the severity-lo-limit keyword and the severity argument to specify the severity level description, not the numeric value assigned to that severity level. Step 2 show logging events buffer severity-hi-limit (Optional) Displays logging events with a severity at or severity above the numeric value specified severity level. • In this example, alarms with a severity of critical Example: (severity of 2) or greater are displayed. Alerts (severity RP/0/RP0/CPU0:router# show logging events of 1) and emergencies (severity of 0) are omitted. buffer severity-hi-limit critical Note Use the severity-hi-limit keyword and the severity argument to specify the severity level description, not the numeric value assigned to that severity level. Step 3 show logging events buffer severity-hi-limit (Optional) Displays logging events within a severity range. severity severity-lo-limit severity • In this example, alarms with a severity of critical (severity of 2) and alerts (severity of 1) are displayed. Example: All other event severities are omitted. RP/0/RP0/CPU0:router# show logging events buffer severity-hi-limit alerts severity-lo-limit critical Step 4 show logging events buffer severity-hi-limit (Optional) Displays logging events occurring after the severity severity-lo-limit severity specified time stamp and within a severity range. The timestamp-lo-limit hh:mm:ss [month] [day] [year] month, day, and year arguments default to the current month, date, and year if not specified. • In this example, alarms with a severity of a warnings Example: (severity of 4), errors (severity of 3), and critical RP/0/RP0/CPU0:router# show logging events buffer severity-lo-limit warnings (severity of 2) that occur after 22:00:00 on May 7, 2004 severity-hi-limit critical timestamp-lo-limit are displayed. All other messages occurring before the 22:00:00 may 07 04 time stamp are omitted.
Displaying Alarms According to a Time Stamp Range
Alarms can be displayed according to a time stamp range. Specifying a specific beginning and end point can be useful in isolating alarms occurring during a particular known system event. This task explains how to display alarms according to a time stamp range.
Note The commands can be entered in any order.
Cisco IOS XR System Management Configuration Guide SMR-16 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
SUMMARY STEPS
1. show logging events buffer timestamp-lo-limit hh:mm:ss [month] [day] [year] 2. show logging events buffer timestamp-hi-limit hh:mm:ss [month] [day] [year] 3. show logging events buffer timestamp-hi-limit hh:mm:ss [month] [day] [year] timestamp-lo-limit hh:mm:ss [month] [day] [year]
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer timestamp-lo-limit (Optional) Displays logging events with a time stamp after hh:mm:ss [month] [day] [year] the specified time and date. • The month, day, and year arguments default to the Example: current month, date, and year if not specified. RP/0/RP0/CPU0:router# show logging events buffer timestamp-lo-limit 21:28:00 april 18 04 • The sample output displays events logged after 21:28:00 on April 18, 2004. Step 2 show logging events buffer timestamp-hi-limit (Optional) Displays logging events with a time stamp hh:mm:ss [month] [day] [year] before the specified time and date. • The month, day, and year arguments default to the Example: current month, date, and year if not specified. RP/0/RP0/CPU0:router# show logging events buffer timestamp-hi-limit 21:28:03 april 18 04 • The sample output displays events logged before 21:28:03 on April 18, 2004. Step 3 show logging events buffer timestamp-hi-limit (Optional) Displays logging events with a time stamp after hh:mm:ss [month] [day] [year] and before the specified time and date. timestamp-lo-limit hh:mm:ss [month] [day] [year] • The month, day, and year arguments default to the current month, day, and year if not specified. Example: • The sample output displays events logged after RP/0/RP0/CPU0:router# show logging events 21:16:00 on April 18, 2003 and before 21:28:00 on buffer timestamp-hi-limit 21:28:00 april 18 04 April 18, 2004. timestamp-lo-limit 21:16:00 april 18 03
Cisco IOS XR System Management Configuration Guide SMR-17 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Displaying Alarms According to Message Group and Message Code
This task explains how to display alarms in the logging events buffer according to message code and message group. Displaying alarms by message group and message code can be useful in isolating related events.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging events buffer group message-group 2. show logging events buffer message message-code 3. show logging events buffer group message-group message message-code
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer group message-group (Optional) Displays logging events matching the specified message group. Example: • In this example, all events that contain the message RP/0/RP0/CPU0:router# show logging events group SONET are displayed. buffer group SONET Step 2 show logging events buffer message message-code (Optional) Displays logging events matching the specified message code. Example: • In this example, all events that contain the message RP/0/RP0/CPU0:router# show logging events code ALARM are displayed. buffer message ALARM Step 3 show logging events buffer group message-group (Optional) Displays logging events matching the specified message message-code message group and message code. • In this example, all events that contain the message Example: group SONET and message code ALARM are RP/0/RP0/CPU0:router# show logging events displayed. buffer group SONET message ALARM
Cisco IOS XR System Management Configuration Guide SMR-18 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Displaying Alarms According to a First and Last Range
This task explains how to display alarms according to a range of the first and last alarms in the logging events buffer. Alarms can be displayed according to a range, beginning with the first or last alarm in the logging events buffer.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging events buffer first event-count 2. show logging events buffer last event-count 3. show logging events buffer first event-count last event-count
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer first event-count (Optional) Displays logging events beginning with the first event in the logging events buffer. Example: • For the event-count argument, enter the number of RP/0/RP0/CPU0:router# show logging events events to be displayed. buffer first 15 • In this example, the first 15 events in the logging events buffer are displayed. Step 2 show logging events buffer last event-count (Optional) Displays logging events beginning with the last event in the logging events buffer. Example: • For the event-count argument, enter the number of RP/0/RP0/CPU0:router# show logging events events to be displayed. buffer last 20 • In this example, the last 20 events in the logging events buffer are displayed. Step 3 show logging events buffer first event-count (Optional) Displays the first and last events in the logging last event-count events buffer. • For the event-count argument, enter the number of Example: events to be displayed. RP/0/RP0/CPU0:router# show logging events buffer first 20 last 20 • In this example, both the first 20 and last 20 events in the logging events buffer are displayed.
Cisco IOS XR System Management Configuration Guide SMR-19 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Displaying Alarms by Location
This task explains how to display alarms by location.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging events buffer location node-id 2. show logging events buffer location node-id event-hi-limit event-id event-lo-limit event-id
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer location node-id (Optional) Isolates the occurrence of the range of event IDs to a particular node. Example: • The location of the node is specified in the format RP/0/RP0/CPU0:router# show logging events rack/slot/module. buffer 0/2/CPU0 Step 2 show logging events buffer location node-id (Optional) Isolates the occurrence of the range of event IDs event-hi-limit event-id event-lo-limit event-id to a particular node and narrows the range by specifying a high and low limit of event IDs to be displayed. Example: • The location of the node is specified in the format RP/0/RP0/CPU0:router# show logging events rack/slot/module. buffer location 0/2/CPU0 event-hi-limit 100 event-lo-limit 1
Displaying Alarms by Event Record ID
This task explains how to display alarms by event record ID.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging events buffer all-in-buffer 2. show logging events buffer event-hi-limit event-id event-lo-limit event-id
Cisco IOS XR System Management Configuration Guide SMR-20 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer all-in-buffer (Optional) Displays all messages in the logging events buffer. Example: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer Caution Depending on the alarm severity settings, use of this command can create a large amount of output.
Step 2 show logging events buffer event-hi-limit (Optional) Narrows the range by specifying a high and low event-id event-lo-limit event-id limit of event IDs to be displayed.
Example: RP/0/RP0/CPU0:router# show logging events buffer event-hi-limit 100 event-lo-limit 1
Displaying the Logging Correlation Buffer Size, Messages, and Rules
This task explains how to display the logging correlation buffer size, messages in the logging correlation buffer, and correlation rules.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging correlator info 2. show logging correlator buffer all-in-buffer 3. show logging correlator buffer correlationID correlation-id 4. show logging correlator buffer rule-name correlation-rule 5. show logging correlator rule all 6. show logging correlator rule correlation-rule
Cisco IOS XR System Management Configuration Guide SMR-21 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show logging correlator info (Optional) Displays the size of the logging correlation buffer (in bytes) and the percentage occupied by correlated messages. Example: RP/0/RP0/CPU0:router# show logging correlator info Step 2 show logging correlator buffer all-in-buffer (Optional) Displays all messages in the logging correlation buffer. Example: RP/0/RP0/CPU0:router# show logging correlator buffer all-in-buffer Step 3 show logging correlator buffer correlationID (Optional) Displays specific messages matching a correlation-id particular correlation ID in the correlation buffer.
Example: RP/0/RP0/CPU0:router# show logging correlator buffer correlationID 37 Step 4 show logging correlator buffer rule-name (Optional) Displays specific messages matching a correlation-rule particular rule in the correlation buffer.
Example: RP/0/RP0/CPU0:router# show logging correlator buffer rule-name rule7 Step 5 show logging correlator rule all (Optional) Displays all defined correlation rules.
Example: RP/0/RP0/CPU0:router# show logging correlator rule all Step 6 show logging correlator rule correlation-rule (Optional) Displays the specified correlation rule.
Example: RP/0/RP0/CPU0:router# show logging correlator rule rule7
Clearing Alarm Event Records and Resetting Bistate Alarms
This task explains how to clear alarm event records and bistate alarms. Unnecessary and obsolete messages can be cleared to reduce the size of the event logging buffer and make it more searchable, and thus more navigable. The filtering capabilities available for clearing events in the logging events buffer (with the clear logging events delete command) are also available for displaying events in the logging events buffer (with the show logging events buffer command).
Note The commands can be entered in any order.
Cisco IOS XR System Management Configuration Guide SMR-22 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software How to Implement and Monitor Alarm Management and Logging Correlation on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
SUMMARY STEPS
1. show logging events buffer all-in-buffer 2. clear logging events delete timestamp-lo-limit hh:mm:ss [month] [day] [year] 3. clear logging events delete event-hi-limit severity event-lo-limit severity 4. clear logging events delete location node-id 5. clear logging events delete first event-count 6. clear logging events delete last event-count 7. clear logging events delete message message-code 8. clear logging events delete group message-group 9. clear logging events reset all-in-buffer 10. show logging events buffer all-in-buffer
DETAILED STEPS
Command or Action Purpose Step 1 show logging events buffer all-in-buffer (Optional) Displays all messages in the logging events buffer. Example: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer Step 2 clear logging events delete timestamp-lo-limit (Optional) Deletes logging events occurring before the hh:mm:ss [month] [day] [year] specified time and date from the logging events buffer. • The month, day, and year arguments default to the Example: current month, day, and year if not specified. RP/0/RP0/CPU0:router# clear logging events delete timestamp-lo-limit 20:00:00 april 01 • In this example, all events occurring before April 1, 2004 2004 are removed. Step 3 clear logging events delete event-hi-limit (Optional) Deletes logging events within a range of severity severity event-lo-limit severity levels for logging alarm messages. • In this example, all events with a severity level of Example: warnings, notifications, and informational are deleted. RP/0/RP0/CPU0:router# clear logging events delete event-hi-limit warnings event-lo-limit informational Step 4 clear logging events delete location node-id (Optional) Deletes logging events from the logging events that have occurred on a particular node. Example: • The location of the node is specified in the format RP/0/RP0/CPU0:router# clear logging events rack/slot/module. delete location 0/2/CPU0 Step 5 clear logging events delete first event-count (Optional) Deletes logging events beginning with the first event in the logging events buffer. Example: • In this example, the first 10 events in the logging events RP/0/RP0/CPU0:router# clear logging events buffer are cleared. delete first 10
Cisco IOS XR System Management Configuration Guide SMR-23 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Configuration Examples for Alarm Management and Logging Correlation R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 6 clear logging events delete last event-count (Optional) Deletes logging events beginning with the last event in the logging events buffer. Example: • In this example, the last 20 events in the logging events RP/0/RP0/CPU0:router# clear logging events buffer are cleared. delete last 20 Step 7 clear logging events delete message (Optional) Deletes logging events that contain the specified message-code message code. • In this example, all events that contain the message Example: code SYS are deleted from the logging events buffer. RP/0/RP0/CPU0:router# clear logging events delete message sys Step 8 clear logging events delete group message-group (Optional) Deletes logging events that contain the specified message group. Example: • In this example, all events that contain the message RP/0/RP0/CPU0:router# clear logging events group CONFIG_I are deleted from the logging events delete group config_i buffer. Step 9 clear logging events reset all-in-buffer (Optional) Clears all bistate alarms in the SET state from the logging events buffer. Example: RP/0/RP0/CPU0:router# clear logging events reset all-in-buffer Step 10 show logging events buffer all-in-buffer (Optional) Displays all messages in the logging events buffer. Example: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer
Configuration Examples for Alarm Management and Logging Correlation
This section provides the following configuration examples: • Increasing the Severity Level for Alarm Filtering to Display Fewer Events and Modifying the Alarm Buffer Size and Capacity Threshold: Example, page 25 • Configuring a Correlation Rule for the SYS CONFIG_I Alarm: Example, page 25 • Configuring a Correlation Rule for LINK UPDOWN and SONET ALARM Alarms: Example, page 26
Cisco IOS XR System Management Configuration Guide SMR-24 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Configuration Examples for Alarm Management and Logging Correlation R3.3 Beta Draft—Cisco Confidential Information Increasing the Severity Level for Alarm Filtering to Display Fewer Events and Modifying the Alarm Buffer Size and Capacity Threshold: Example
The following configuration example shows how to set the capacity threshold to 90 percent, to reduce the size of the logging events buffer to 10,000 bytes from the default, and to increase the severity level to errors: ! logging events threshold 90 logging events buffer-size 10000 logging events level errors ! Increasing the severity level to errors reduces the number of alarms that are displayed in the logging events buffer because only alarms with a severity of errors or higher are displayed. Increasing the threshold capacity to 90 percent reduces the time interval between the threshold crossing and wraparound events; the logging events buffer thus does not generate a threshold crossing alarm until it reaches 90 percent capacity. Reducing the size of the logging events buffer to 10,000 bytes decreases the number of alarms that will be displayed in the logging events buffer and reduces the memory requirements for the component.
Configuring a Correlation Rule for the SYS CONFIG_I Alarm: Example
The following example shows how to configure a correlation rule for the MGBL-SYS-5-CONFIG_I alarm. Notice that the category of this alarm is MGBL, group is SYS, severity is 5, and code is CONFIG_I. ! logging correlator rule configalrm timeout 60000 MGBL-SYS-5-CONFIG_I logging correlator apply-rule configalrm all-of-router !
In this configuration example, the correlation rule named configalrm is configured to correlate the MGBL-SYS-5-CONFIG_I alarm (the alarm that is generated each time a user enters and then exits global configuration mode), and the configalrm correlation rule is applied to the entire router. When the correlation rule for an alarm is configured, the alarm specified with the message-category, message-group, and message-code arguments must be included in the rule. The first message that you specify is set as the root message. In this configuration example, the message indentified as MGBL (category), SYS (the message group) and CONFIG_I (the message code) is set as the root message. The message group and message code information are embedded within the alarms that are sent to the logging events buffer and can be obtained from the output of the show logging events buffer command. For example, the MGBL-SYS-5 -CONFIG_I alarm appears as follows in the logging events buffer: #ID :C_id:Source :Time :%GROUP-SEVERITY-MESSAGECODE: Text ... #135 :40 :RP/0/RP0/CPU0 :Jan 30 16:16:38 2004:config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61)
The configalrm correlation rule in this example specifies that if a user enters and exits global configuration mode more than once within the timeout interval of 60,000 milliseconds (one minute), only the first MGBL- SYS-5-CONFIG_I root message received during the timeout interval by the correlator is sent to the logging events buffer because it is the root message. Subsequent CONFIG_I alarms that are received during the timeout interval are not emitted to the logging events buffer because they would be classified as leaf messages, and thus would remain in the logging events correlator.
Cisco IOS XR System Management Configuration Guide SMR-25 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Configuration Examples for Alarm Management and Logging Correlation R3.3 Beta Draft—Cisco Confidential Information
Suppose that after configuring the correlation rule, a user enters and exits global configuration mode multiple times within the 1-minute period. Given the configalrm correlation rule that has been configured, the first CONFIG_I root message is sent immediately to the logging events buffer and displayed on the console. Subsequent CONFIG_I alarms generated during the timeout interval are stored in the logging correlator buffer because they are leaf messages, and thus are not emitted to the logging events buffer. To display the configuration operation alarms sent to the correlation buffer for the configalrm correlation rule, use the show logging correlator buffer command: RP/0/RP0/CPU0:router# show logging correlator buffer rule configalrm
#CORR_ID.ID:Source :Time :RULENAME : Text #40.1 :RP/0/RP0/CPU0:Jan 30 16:16:38 2004:configalrm :config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61) #40.2 :RP/0/RP0/CPU0:Jan 30 16:16:49 2004:configalrm :config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61) #40.3 :RP/0/RP0/CPU0:Jan 30 16:16:55 2004:configalrm :config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61) #40.4 :RP/0/RP0/CPU0:Jan 30 16:17:02 2004:configalrm :config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61)
Note The output displays four MGBL-SYS-5-CONFIG_I alarms in the logging correlation buffer, indicating that a user had entered and exited from global configuration four times within the configured timeout interval of 1 minute.
Because the configalrm correlation rule correlates the MGBL-SYS-5-CONFIG_I root message, only the first MGBL-SYS-5-CONFIG_I root message is emitted to the logging events buffer: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer
#ID :C_id:Source :Time :%CATEGORY-GROUP-SEVERITY-MESSAGECODE: Text ... #135 :40 :RP/0/RP0/CPU0:Jan 30 16:16:38 2004:config[65696]: %MGBL-SYS-5-CONFIG_I : Configured from console by lab on vty0 (12.26.25.61)
Configuring a Correlation Rule for LINK UPDOWN and SONET ALARM Alarms: Example
The following example shows how to configure a correlation rule for the LINK UPDOWN and SONET ALARM messages: ! logging correlator rule updown timeout 60000 PKT_INFRA LINK UPDOWN L2 SONET ALARM logging correlator apply-rule updown all-of-router !
In this example, suppose that two routers are connected using Packet-over-SONET (POS) interface 0/7/0/0. When a correlation rule is configured, the first message that is specified (with the message-category, message-code, and message group arguments) is set as the root message. Any additional messages included in the rule are set as leaf messages. When the correlator receives a root message, the correlator sends it directly to the logging events buffer. Subsequent PKT_INFRA-LINK- UPDOWN or L2-SONET- ALARM messages matching the rule would be considered leaf messages and are stored in
Cisco IOS XR System Management Configuration Guide SMR-26 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Configuration Examples for Alarm Management and Logging Correlation R3.3 Beta Draft—Cisco Confidential Information
the logging correlator buffer. If, for any reason, a leaf message (such as the L2-SONET-ALARM alarm in this example) is received first, the correlator does not send it to the logging events buffer immediately; the correlator, instead, waits until the timeout interval expires. During the timeout, two events can occur: • If only the root message is received, that message is sent to the logging events buffer because it is the root message. • If the root message is never received, all messages in the logging correlator buffer received during the timeout interval are forwarded to the logging events buffer. In this example, the correlation rule named updown is configured to correlate the PKT_INFRA-LINK -UPDOWN alarm (the root message) and L2-SONET-ALARM alarms (leaf messages associated with PKT_INFRA-LINK-UPDOWN alarms). logging correlator rule updown timeout 60000 LINK UPDOWN SONET ALARM
In this example, the updown correlation rule is applied to the entire router: logging correlator apply-rule updown all-of-router
Suppose that a physical layer interface module (PLIM) card is removed from slot 7 on the adjacent remote router, the PLIM slot in the remote router chassis in which the port for POS interface 0/7/0/0 resides. This action brings down the link for POS interface 0/7/0/0. When the link goes down, PKT_INFRA-LINK-UPDOWN and L2- SONET-ALARM messages are generated, which together indicate that the POS interface link is down. The first PKT_INFRA-LINK-UPDOWN message is emitted to the logging events buffer. Subsequent PKT_INFRA- LINK-UPDOWN and L2-SONET-ALARM messages, which are set as leaf alarms, remain in the logging correlator buffer and are not sent to the logging events buffer. This example shows sample output from the show logging events buffer all-in-buffer command. The output displays the alarms stored in the logging events buffer after the 1 minute time period expires for the updown correlation rule configured in this example: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer
#ID :C_id:Source :Time :%CATEGORY-GROUP-SEVERITY-MESSAGECODE: Text #144 :46 :LC/0/7/CPU0:Jan 30 16:35:39 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Down
Note Only the first LINK UPDOWN root message is emitted to the logging events buffer after the 1 minute time interval for the updown correlation rule expires.
This example shows output from the show logging correlator buffer correlationID command generated after the 1 minute interval elapses. The output displays the alarms assigned correlation ID 46 in the logging correlator buffer. In the example, the PKT_INFRA-LINK-UPDOWN root message and L2-SONET-ALARM leaf messages generated during the timeout interval assigned correlation ID 46 are displayed: RP/0/RP0/CPU0:router# show logging correlator buffer correlationID 46
#C_id.id:Rule Name:Source :Time : Text #46.1 :updown :LC/0/7/CPU0:Jan 30 16:35:39 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Down #46.2 :updown :LC/0/7/CPU0:Jan 30 16:35:41 2004:DI_Partner[50]: %L2-SONET-4-ALARM : SONET0_7_0_0: SLOS
Note The subsequent PKT_INFRA-LINK-UPDOWN and L2-SONET-ALARM leaf messages generated during the timeout interval remain in the logging correlator buffer because they are leaf messages.
Cisco IOS XR System Management Configuration Guide SMR-27 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Configuration Examples for Alarm Management and Logging Correlation R3.3 Beta Draft—Cisco Confidential Information
Suppose then that the PLIM card is reinserted into slot 7 on the adjacent remote router. This action brings the link for POS interface 0/7/0/0 back up. When the POS interface comes back up, the PKT_INFRA-LINK-UPDOWN root alarm and associated L2- SONET-ALARM alarms are generated, which together indicate that the link is back up. The first PKT_INFRA-LINK-UPDOWN root message is emitted to the logging events buffer. Subsequent PKT_INFRA-LINK-UPDOWN and L2-SONET- ALARM leaf messages remain in the logging correlator buffer and are not sent to the logging events buffer. This example shows output from the show logging correlator buffer correlationID command. The output displays the alarms assigned to correlation ID 46 and 47, the correlation IDs associated with the PKT_INFRA-LINK-UPDOWN and L2-SONET-ALARM root messages: RP/0/RP0/CPU0:router# show logging correlator buffer correlationID 46 47
#C_id.id:Rule Name:Source :Time : Text #46.1 :updown :LC/0/7/CPU0:Jan 30 16:35:39 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Down #46.2 :updown :LC/0/7/CPU0:Jan 30 16:35:41 2004:DI_Partner[50]: %L2-SONET-4-ALARM : SONET0_7_0_0: SLOS #47.1 :updown :LC/0/7/CPU0:Jan 30 16:37:51 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Up #47.2 :updown :LC/0/7/CPU0:Jan 30 16:38:01 2004:DI_Partner[50]: %L2-SONET-4-ALARM : SONET0_7_0_0: SLOS cleared #47.3 :updown :LC/0/7/CPU0:Jan 30 16:38:21 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Down #47.4 :updown :LC/0/7/CPU0:Jan 30 16:38:21 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Up #47.5 :updown :LC/0/7/CPU0:Jan 30 16:38:22 2004:DI_Partner[50]: %L2-SONET-4-ALARM : SONET0_7_0_0: B2_BER #47.6 :updown :LC/0/7/CPU0:Jan 30 16:38:33 2004:DI_Partner[50]: %L2-SONET-4-ALARM : SONET0_7_0_0: B2_BER cleared
Because the updown correlation rule correlates the PKT_INFRA-LINK-UPDOWN message, only the first PKT_INFRA-LINK-UPDOWN root message (indicating that link had gone down during the first timeout interval) and the first PKT_INFRA-LINK-UPDOWN root message (indicating that link had come back up during a subsequent timeout interval) are sent to the logging events buffer: RP/0/RP0/CPU0:router# show logging events buffer all-in-buffer
#ID :C_id:Source :Time :%CATEGORY-GROUP-SEVERITY-MESSAGECODE: Text #144 :46 :LC/0/7/CPU0:Jan 30 16:35:39 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Down #145 :47 :LC/0/7/CPU0:Jan 30 16:37:51 2004:ifmgr[130]: %PKT_INFRA-LINK-3-UPDOWN : Interface POS0/7/0/0, changed state to Up
Cisco IOS XR System Management Configuration Guide SMR-28 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Additional References
The following sections provide references related to implementing and monitoring alarm logs and logging correlation on Cisco IOS XR software.
Related Documents
Related Topic Document Title Cisco IOS XR alarm management and logging Alarm Management and Logging Correlation Commands on correlation commands Cisco IOS XR Software, Release 3.2 Cisco IOS XR logging commands Logging Services Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR logging configuration tasks Implementing Logging Services on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Cisco IOS XR XML API material Cisco IOS XR XML API Guide, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2
Standards
Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature.
MIBs
MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Cisco IOS XR System Management Configuration Guide SMR-29 Implementing and Monitoring Alarms and Alarm Log Correlation on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs
RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature.
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMR-30 R3.3 Beta Draft—Cisco Confidential Information
Implementing CDP on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
Cisco Discovery Protocol (CDP) is a media- and protocol-independent protocol that runs on all Cisco-manufactured equipment including routers, bridges, access and communication servers, and switches. Using CDP, you can view information about all the Cisco devices that are directly attached to the device. This module describes the new and revised tasks you need to implement CDP on your Cisco IOS XR network.
Note For more information about CDP on the Cisco IOS XR software and complete descriptions of the CDP commands listed in this module, you can refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing CDP on Cisco IOS XR Software Contents Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification Release 3.2 This feature was supported on the Cisco XR 12000 Series Router. Release 3.3 No modification.
Contents
• Prerequisites for Implementing CDP on Cisco IOS XR Software, page 32 • Information About Implementing CDP on Cisco IOS XR Software, page 32 • How to Implement CDP on Cisco IOS XR Software, page 33 • Configuration Examples for Implementing CDP on Cisco IOS XR Software, page 39 • Additional References, page 40
Cisco IOS XR System Management Configuration Guide SMR-31 Implementing CDP on Cisco IOS XR Software Prerequisites for Implementing CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Implementing CDP on Cisco IOS XR Software
You must be in a user group associated with a task group that includes the proper task IDs for CDP commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
Information About Implementing CDP on Cisco IOS XR Software
To implement CDP you need to understand the following concept: • CDP Functional Overview, page 32
CDP Functional Overview
CDP is primarily used to obtain protocol addresses of neighboring devices and discover the platform of those devices. CDP can also be used to display information about the interfaces your router uses. CDP is media- and protocol-independent, and runs on all equipment manufactured by Cisco, including routers, bridges, access servers, and switches. Use of SNMP with the CDP MIB allows network management applications to learn the device type and the SNMP agent address of neighboring devices, and to send SNMP queries to those devices. CDP uses the CISCO-CDP-MIB. CDP runs on all media that support Subnetwork Access Protocol (SNAP), including LAN, Frame Relay, and ATM physical media. CDP runs over the data link layer only. Therefore, two systems that support different network-layer protocols can learn about each other. Each device configured for CDP sends periodic messages, known as advertisements, to a multicast address. Each device advertises at least one address at which it can receive SNMP messages. The advertisements also contain time-to-live, or hold-time, information, which indicates the length of time a receiving device should hold CDP information before discarding it. Each device also listens to the periodic CDP messages sent by others to learn about neighboring devices and determine when their interfaces to the media go up or down. CDP Version-2 (CDPv2) is the most recent release of the protocol and provides more intelligent device tracking features. These features include a reporting mechanism that allows for more rapid error tracking, thereby reducing costly downtime. Reported error messages can be sent to the console or to a logging server, and can cover instances of unmatching native VLAN IDs (IEEE 802.1Q) on connecting ports, and unmatching port duplex states between connecting devices. CDPv2 show commands can provide detailed output on VLAN Trunking Protocol (VTP) management domain and duplex modes of neighbor devices, CDP-related counters, and VLAN IDs of connecting ports. Type-length-value fields (TLVs) are blocks of information embedded in CDP advertisements. Table 3 summarizes the TLV definitions for CDP advertisements.
Cisco IOS XR System Management Configuration Guide SMR-32 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Table 3 Type-Length-Value Definitions for CDPv2
TLV Definition Device-ID TLV Identifies the device name in the form of a character string. Address TLV Contains a list of network addresses of both receiving and sending devices. Port-ID TLV Identifies the port on which the CDP packet is sent. Capabilities TLV Describes the functional capability for the device in the form of a device type; for example, a switch. Version TLV Contains information about the software release version on which the device is running. Platform TLV Describes the hardware platform name of the device, for example, Cisco 4500. VTP Management Domain TLV Advertises the system’s configured VTP management domain name-string. Used by network operators to verify VTP domain configuration in adjacent network nodes. Native VLAN TLV Indicates, per interface, the assumed VLAN for untagged packets on the interface. CDP learns the native VLAN for an interface. This feature is implemented only for interfaces that support the IEEE 802.1Q protocol. Full/Half Duplex TLV Indicates status (duplex configuration) of CDP broadcast interface. Used by network operators to diagnose connectivity problems between adjacent network elements.
How to Implement CDP on Cisco IOS XR Software
This section contains the following procedures: • Enabling CDP, page 33 (required) • Modifying CDP Default Settings, page 35 (optional) • Monitoring CDP, page 36 (optional)
Enabling CDP
To enable CDP, you must first enable CDP globally on the router and then enable CDP on a per-interface basis. This task explains how to enable CDP globally on the router and then enable CDP on an interface.
SUMMARY STEPS
1. configure 2. cdp 3. interface type number 4. cdp
Cisco IOS XR System Management Configuration Guide SMR-33 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
5. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 cdp Enables CDP globally.
Example: RP/0/RP0/CPU0:router(config)# cdp Step 3 interface type instance Enters interface configuration mode.
Example: RP/0/RP0/CPU0:router(config)# interface pos 0/0/0/1 Step 4 cdp Enables CDP on an interface.
Example: RP/0/RP0/CPU0:router(config-if)# cdp enable Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config-if)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-if)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-34 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Modifying CDP Default Settings
This task explains how to modify the default version, hold-time setting, and timer settings.
Note The commands can be entered in any order.
SUMMARY STEPS
1. configure 2. cdp advertise v1 3. cdp holdtime seconds 4. cdp timer seconds 5. end or commit 6. show cdp
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 cdp advertise v1 Configures CDP to use only version 1 (CDPv1) in communicating with neighboring devices. Example: • By default, when CDP is enabled, the router sends RP/0/RP0/CPU0:router(config)# cdp advertise v1 CDPv2 packets. CDP also sends and receives CDPv1 packets if the device with which CDP is interacting does not process CDPv2 packets. • In this example, the router is configured to send and receive only CDPv1 packets. Step 3 cdp holdtime seconds Specifies the amount of time that the receiving networking device will hold a CDP packet sent from the router before discarding it. Example: RP/0/RP0/CPU0:router(config)# cdp holdtime 30 • By default, when CDP is enabled, the receiving networking device holds a CDP packet for 180 seconds before discarding it. Note The CDP hold time must be set to a higher number of seconds than the time between CDP transmissions, which is set with the cdp timer command.
• In this example, the value of hold-time for the seconds argument is set to 30 seconds.
Cisco IOS XR System Management Configuration Guide SMR-35 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 cdp timer seconds Specifies the frequency at which CDP update packets are sent. Example: • By default, when CDP is enabled, CDP update packets RP/0/RP0/CPU0:router(config)# cdp timer 20 are sent at a frequency of once every 60 seconds. Note A lower timer setting causes CDP updates to be sent more frequently.
• In this example, CDP update packets are configured to be sent at a frequency of once every 20 seconds. Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 6 show cdp (Optional) Displays global CDP information. • The output displays the CDP version running on the Example: router, the hold time setting, and the timer setting. RP/0/RP0/CPU0:router# show cdp
Monitoring CDP
This task shows how to monitor CDP.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show cdp entry {* | entry-name} [protocol | version] 2. show cdp interface [type instance | location node-id] [detail] 3. show cdp neighbors [type instance | location node-id] [detail]
Cisco IOS XR System Management Configuration Guide SMR-36 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
4. show cdp traffic [location node-id]
DETAILED STEPS
Command or Action Purpose Step 1 show cdp entry {* | entry-name} [protocol | Displays information about a specific neighboring device or version] all neighboring devices discovered using CDP.
Example: RP/0/RP0/CPU0:router# show cdp entry * Step 2 show cdp interface [type instance | location Displays information about the interfaces on which CDP is node-id] enabled.
Example: RP/0/RP0/CPU0:router# show cdp interface pos 0/0/0/1 Step 3 show cdp neighbors [type instance | location Displays detailed information about neighboring devices node-id] [detail] discovered using CDP.
Example: RP/0/RP0/CPU0:router# show cdp neighbors Step 4 show cdp traffic [location node-id] Displays information about the traffic gathered between devices using CDP. Example: RP/0/RP0/CPU0:router# show cdp traffic
Examples
The following is sample ouput for the show cdp neighbors command: RP/0/0/CPU0:router# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater
Device ID Local Intrfce Holdtme Capability Platform Port ID router1 Mg0/0/CPU0/0 177 T S WS-C2924M Fa0/12 router2 PO0/4/0/0 157 R 12008/GRP PO0/4/0/1
The following is sample output for the show cdp neighbors command. In this example, the optional type instance arguments are used in conjunction with the detail optional keyword to display detailed information about a CDP neighbor . RP/0/0/CPU0:router# show cdp neighbors POS 0/4/0/0 detail
------Device ID: router2 SysName : router2 Entry address(es): Platform: cisco 12008/GRP, Capabilities: Router Interface: POS0/4/0/0 Port ID (outgoing port): POS0/4/0/1
Cisco IOS XR System Management Configuration Guide SMR-37 Implementing CDP on Cisco IOS XR Software How to Implement CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Holdtime : 134 sec
Version : Cisco IOS XR Software, Version 0.48.0[Default] Copyright (c) 2004 by cisco Systems, Inc.
advertisement version: 2
The following is sample output for the show cdp entry command. In this example, the optional entry argument is used to display entry information related to a specific CDP neighbor. RP/0/0/CPU0:router# show cdp entry router2
advertisement version: 2
------Device ID: router2 SysName : router2 Entry address(es): Platform: cisco 12008/GRP, Capabilities: Router Interface: POS0/4/0/0 Port ID (outgoing port): POS0/4/0/1 Holdtime : 145 sec
Version : Cisco IOS XR Software, Version 0.48.0[Default] Copyright (c) 2004 by cisco Systems, Inc.
advertisement version: 2
The following is sample output for the show cdp interface command. In this example, CDP information related to Packet-over-SONET (PoS) interface 0/4/0/0 is displayed. RP/0/0/CPU0:router# show cdp interface pos 0/4/0/0
POS0/4/0/0 is Up Encapsulation HDLC Sending CDP packets every 60 seconds Holdtime is 180 seconds
Cisco IOS XR System Management Configuration Guide SMR-38 Implementing CDP on Cisco IOS XR Software Configuration Examples for Implementing CDP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
The following is sample output for the show cdp traffic command: RP/0/0/CPU0:router# show cdp traffic
CDP counters : Packets output: 194, Input: 99 Hdr syntax: 0, Chksum error: 0, Encaps failed: 0 No memory: 0, Invalid packet: 0, Truncated: 0 CDP version 1 advertisements output: 0, Input: 0 CDP version 2 advertisements output: 194, Input: 99 Unrecognize Hdr version: 0, File open failed: 0
The following is sample output for the show cdp traffic command. In this example, the optional location keyword and node-id argument are used to display information about the traffic gathered between devices using CDP from the specified node. RP/0/0/CPU0:router# show cdp traffic location 0/4/cpu0
CDP counters : Packets output: 16, Input: 13 Hdr syntax: 0, Chksum error: 0, Encaps failed: 0 No memory: 0, Invalid packet: 0, Truncated: 0 CDP version 1 advertisements output: 0, Input: 0 CDP version 2 advertisements output: 16, Input: 13 Unrecognize Hdr version: 0, File open failed: 0
Configuration Examples for Implementing CDP on Cisco IOS XR Software
This section provides the following configuration examples: • Enabling CDP: Example, page 39 • Modifying Global CDP Settings: Example, page 39
Enabling CDP: Example
The following example shows how to configure CDP globally and then enable CDP on Packet-over-SONET (POS) interface 0/3/0/0. cdp interface POS0/3/0/0 cdp
Modifying Global CDP Settings: Example
The following example shows how to modify global CDP settings. In this example, the timer setting is set to 20 seconds, the hold-time setting is set 30 seconds, and the version of CDP used to communicate with neighboring devices is set to CDPv1. cdp timer 20 cdp holdtime 30 cdp advertise v1
Cisco IOS XR System Management Configuration Guide SMR-39 Implementing CDP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
The following example shows how to use the show cdp command to verify the CDP global settings: RP/0/0/CPU0:router# show cdp
Global CDP information: Sending CDP packets every 20 seconds Sending a holdtime value of 30 seconds Sending CDPv2 advertisements is not enabled
Additional References
The following sections provide references related to implementing CDP on Cisco IOS XR software.
Related Documents
Related Topic Document Title Cisco IOS XR CDP commands CDP Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Cisco IOS XR XML API material Cisco IOS XR XML API Guide, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2
Standards
Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature.
MIBs
MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Cisco IOS XR System Management Configuration Guide SMR-40 Implementing CDP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs
RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature.
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMR-41 Implementing CDP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
Cisco IOS XR System Management Configuration Guide SMR-42 R3.3.0 Beta Draft—Cisco Confidential Information
Implementing IP Service Level Agreements on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
IP Service Level Agreements (IP SLAs) is a portfolio of technology embedded in most devices that run Cisco IOS XR software, which allows you to analyze IP service levels for IP applications and services, increase productivity, lower operational costs, and reduce the frequency of network outages. Using IP SLA, service provider customers can measure and provide service level agreements. IP SLA can perform network assessments, verify quality of service (QoS), ease the deployment of new services, and assist administrators with network troubleshooting.
Note For a complete description of the IP SLA commands used in this chapter, refer to the IP Service Level Agreement Commands on Cisco IOS XR Software module of Cisco IOS XR System Management Command Reference. To locate documentation for other commands that appear in this chapter, use the command reference master index or search online.
Feature History for Implementing IP Service Level Agreements on Cisco IOS XR Software Release Modification Release 3.3.0 This feature was introduced on the Cisco CRS-1.
Contents
• Prerequisites for Implementing IP Service Level Agreements, page SMC-44 • Restrictions for Implementing IP Service Level Agreements, page SMC-44 • Information About Implementing IP Service Level Agreements, page SMC-44 • How to Implement IP Service Level Agreements, page SMC-49 • Configuration Examples for Implementing IP Service Level Agreements, page SMC-90 • Additional References, page SMC-90
Cisco IOS XR System Management Configuration Guide SMC-43 Implementing IP Service Level Agreements on Cisco IOS XR Software Prerequisites for Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information Prerequisites for Implementing IP Service Level Agreements
Knowledge of general networking protocols and your specific network design is assumed. Familiarity with network management applications is helpful. We do not recommend scheduling all the operations at the same time as this could negatively affect your performance.
Restrictions for Implementing IP Service Level Agreements
The maximum number of operations that is supported on Cisco IOS XR is 2000.
Information About Implementing IP Service Level Agreements
To implement IP SLA, you must understand the following concepts: • About IP Service Level Agreements Technology, page SMC-44 • Service Level Agreements, page SMC-45 • Benefits of IP Service Level Agreements, page SMC-46 • Measuring Network Performance with IP Service Level Agreements, page SMC-46 • IP SLA Responder and IP SLA Control Protocol, page SMC-48 • Response Time Computation for IP SLA, page SMC-49 • IP SLA Operation Scheduling, page SMC-49
About IP Service Level Agreements Technology
IP SLA uses active traffic monitoring, which generates traffic in a continuous, reliable, and predictable manner to measure network performance. IP SLA sends data across the network to measure performance between multiple network locations or across multiple network paths. It simulates network data and IP services, and collects network performance information in real time. The following information is collected: • Response times • One-way latency, jitter (interpacket delay variance) • Packet loss • Network resource availability IP SLA originated from the technology previously known as Service Assurance Agent (SAA). IP SLA performs active monitoring by generating and analyzing traffic to measure performance, either between the router or from a router to a remote IP device such as a network application server. Measurement statistics, which are provided by the various IP SLA operations, are used for troubleshooting, problem analysis, and designing network topologies. Depending on the specific IP SLA operation, statistics of delay, packet loss, jitter, packet sequence, connectivity, and path are monitored within the router and stored in the router and provided through command-line interface (CLI), Extensive Markup Language (XML), SNMP MIBs. IP SLA uses the Cisco RTTMON MIB to interact between external Network Management System (NMS) applications
Cisco IOS XR System Management Configuration Guide SMC-44 Implementing IP Service Level Agreements on Cisco IOS XR Software Information About Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
and the IP SLA operations that are running on Cisco devices. For a complete description of the object variables that are referenced by IP SLA, see the text of the CISCO-RTTMON-MIB.my file that is available from the Cisco MIB Locator.
Service Level Agreements
Internet commerce has grown significantly in the past few years as the technology has advanced to provide faster, more reliable access to the Internet. Many companies need online access and conduct most of their business online and any loss of service can affect the profitability of the company. Internet service providers (ISPs) and even internal IT departments now offer a defined level of service—a service level agreement—to provide their customers with a degree of predictability. Network administrators are required to support service level agreements that support application solutions. Figure 2 shows how IP SLA has taken the traditional concept of Layer 2 service level agreements and applied a broader scope to support end-to-end performance measurement, including support of applications.
Figure 2 Scope of Traditional Service Level Agreement Versus IP SLA
Traditional Layer 2 SLA
Customer Frame ATM Customer site 1 Relay site 2
Application-aware 149612 IP SLA
Table 4 lists the improvements with IP SLA over a traditional service level agreement.
Table 4 IP SLA Improvements Over a Traditional Service Level Agreement
Type of Improvement Description End-to-end measurements The ability to measure performance from one end of the network to the other allows a broader reach and more accurate representation of the end-user experience. Sophistication Statistics such as delay, jitter, packet sequence, Layer 3 connectivity, and path and download time that are broken down into bidirectional and round-trip numbers provide more data than just the bandwidth of a Layer 2 link. Accuracy Applications that are sensitive to slight changes in network performance require the precision of the sub-millisecond measurement of IP SLA. Ease of deployment Leveraging the existing Cisco devices in a large network makes IP SLA easier to implement than the physical operations that are often required with traditional service level agreements.
Cisco IOS XR System Management Configuration Guide SMC-45 Implementing IP Service Level Agreements on Cisco IOS XR Software Information About Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Table 4 IP SLA Improvements Over a Traditional Service Level Agreement (continued)
Type of Improvement Description Application-aware monitoring IP SLA can simulate and measure performance statistics generated by applications running over Layer 3 through Layer 7. Traditional service level agreements can only measure Layer 2 performance. Pervasiveness IP SLA support exists in Cisco networking devices ranging from low-end to high-end routers and switches. This wide range of deployment gives IP SLA more flexibility over traditional service level agreements.
Benefits of IP Service Level Agreements
Table 5 lists the benefits of implementing IP SLA.
Table 5 List of Benefits for IP SLA
Benefit Description IP SLA monitoring Provides service level agreement monitoring, measurement, and verification. Network performance monitoring Measure the jitter, latency, or packet loss in the network. In addition, IP SLA provides continuous, reliable, and predictable measurements along with proactive notification. IP service network health Verifies that the existing QoS is sufficient for the new IP services. assessment Troubleshooting of network Provides consistent, reliable measurement that immediately operation identifies problems and saves troubleshooting time.
Measuring Network Performance with IP Service Level Agreements
IP SLA uses generated traffic to measure network performance between two networking devices such as routers. Figure 3 shows how IP SLA starts when the IP SLA device sends a generated packet to the destination device. After the destination device receives the packet and if the operation uses an IP SLA component at the receiving end (for example, IP SLA Responder), the reply packet includes information about the delay at the target device. The source device uses this information to improve the accuracy of the measurements. An IP SLA operation is a network measurement to a destination in the network from the source device using a specific protocol such as User Datagram Protocol (UDP) for the operation.
Cisco IOS XR System Management Configuration Guide SMC-46 Implementing IP Service Level Agreements on Cisco IOS XR Software Information About Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Figure 3 IP SLA Operations
Performance Any IP device management application
IP SLA measurement and IP SLA responder to IP SLA Responder SNMP
IP SLA IP SLA IP network
IP SLA responder IP SLA source IP SLA measurement and IP SLA responder to IP SLA Responder 149614
Operations are divided into two classes, which depends on whether they rely on the IP SLA Responder component to be running at the target device or not. The former is used only with Cisco devices; whereas, the latter is used with any device that has IP connectivity. Operations that are based on the Internet Control Message Protocol (ICMP) protocol are an example of those in the second category; whereas, UDP-based operations are an example of the first. In responder-based operations, the IP SLA Responder is enabled in the destination device and provides information such as the processing delays of IP SLA packets. The responder-based operation has improved accuracy over the ICMP operation discussed above, and offers the capability of unidirectional measurements. In replies to the IP SLA source device, the responder includes information about processing delays. The IP SLA source device removes the delays in its final performance calculation. Use of the responder is optional for the UDP Echo operation, but it is required for the UDP Jitter operation. If no IP SLA Responder is used, the target device should support the UDP Echo operation. In ICMP operations, the source IP SLA device sends several ICMP packets to the destination. The destination device, which is any IP device, echoes with replies. The source IP SLA device uses the sent and received time stamps to calculate the response time. The ICMP Echo operation resembles the traditional extended ping utility, and it measures only the response time between the source device and the destination device. ICMP Path Echo and Path Jitter operations use the traceroute mechanism to identify the whole path. Subsequent ICMP packets are sent to each path node, and the measurements are correlated to provide hop-by-hop round-trip delay and jitter information. To implement IP SLA network performance measurement, perform these tasks: 1. Enable the IP SLA Responder, if appropriate. 2. Configure the required IP SLA operation type. 3. Configure any options available for the specified IP SLA operation type. 4. Configure reaction conditions, if required. 5. Schedule the operation to run. Then, let the operation run for a period of time to gather statistics. 6. Display and interpret the results of the operation using Cisco IOS XR CLI, XML, or an NMS system with SNMP.
Cisco IOS XR System Management Configuration Guide SMC-47 Implementing IP Service Level Agreements on Cisco IOS XR Software Information About Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information Operation Types for IP Service Level Agreements
IP SLA configures various types of operations to measure response times, jitter, throughput, and packet loss. Table 6 lists the various types of IP SLA operations. In addition, each operation maps to multiple applications.
Table 6 Types of Operations for IP SLA
Operation Description UDP Echo Measures round-trip delay and helps in accurate measurement of response time of UDP traffic. UDP Jitter Measures round-trip delay, one-way delay, one-way jitter, two-way jitter, and one-way packet loss. ICMP Echo Measures round-trip delay for the full path. ICMP Path Echo Calculates the hop-by-hop response time between the router and any IP device on the network. The path is discovered using the traceroute algorithm, and then by measuring the response time between the source router and each intermediate hop in the path. If there are multiple equal cost routes between source and destination devices, the ICMP Path Echo operation can select one of the paths by using the Loose Source Routing (LSR) option, which is configurable. ICMP Path Jitter Measures hop-by-hop jitter, packet loss, and delay measurement statistics in an IP network.
IP SLA Responder and IP SLA Control Protocol
The IP SLA Responder is a component embedded in the destination Cisco routing device that allows the system to anticipate and respond to IP SLA request packets. IP SLA Responder provides accurate measurements without the need for dedicated operations and additional statistics are not available through standard ICMP-based measurements. The patented IP SLA Control Protocol is used by the IP SLA Responder, providing a mechanism through which the responder is notified on which port it should listen and respond. Only a Cisco IOS device or Cisco IOS XR device can be a source for a destination IP SLA Responder. Figure 3 shows where the IP SLA Responder fits in relation to the IP network. The IP SLA Responder listens on a specific port for control protocol messages sent by an IP SLA operation. Upon receipt of the control message, the responder enables the UDP port specified in the control message for the specified duration. During this time, the responder accepts the requests and responds to them. The responder disables the port after it responds to the IP SLA packet(s), or when the specified time expires. For added security, MD5 authentication for control messages is available. The IP SLA Responder must be used with the UDP Jitter operation, but it is optional for UDP Echo operation. If services that are already provided by the target router are chosen, the IP SLA Responder need not be enabled. For devices that are not Cisco devices, the IP SLA Responder cannot be configured, and the IP SLA can send operational packets only to services native to those devices.
Cisco IOS XR System Management Configuration Guide SMC-48 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information Response Time Computation for IP SLA
Due to other high-priority processes, routers can take tens of milliseconds to process incoming packets. The delay affects the response times, because the reply to test packets might be sitting on queue while waiting to be processed. In this situation, the response times would not accurately represent true network delays. IP SLA minimizes these processing delays on the source router as well as on the target router (if IP SLA Responder is being used), to determine true round-trip times. Some IP SLA probe packets contain delay information that are used in the final computation to make measurements more accurate. When enabled, the IP SLA Responder allows the target device to take two time stamps, both when the packet arrives on the interface and again just as it is leaving, and allows to account for it when calculating the statistics. This time stamping is made with a granularity of submilliseconds. At times of high network activity, an ICMP ping test often shows a long and inaccurate response time, while an IP SLA based responder shows an accurate response time. Figure 4 demonstrates how the responder works. Four time stamps are taken to make the calculation for round-trip time. At the target router, with the responder functionality enabled time stamp 2 (TS2) is subtracted from time stamp 3 (TS3) to produce the time spent processing the test packet as represented by delta. This delta value is then subtracted from the overall round-trip time. Notice that the same principle is applied by IP SLA on the source router where the incoming time stamp 4 (TS4) is taken in a high priority path to allow for greater accuracy.
Figure 4 IP SLA Responder Time Stamping
Source router Target router T2 Responder T1 T3 T4 =T3-T2
RTT (Round-trip time) = T4 (Time stamp 4) - T1 (Time stamp 1) - 149613
IP SLA Operation Scheduling
After an IP SLA operation is configured, you must schedule the operation to begin capturing statistics and collecting error information. When scheduling an operation, the operation starts immediately or starts at a certain month, day, and hour. In addition, an operation can be scheduled to be in pending state, which is used when the operation is a reaction (threshold) operation waiting to be triggered. Normal scheduling of IP SLA operations lets you schedule one operation at a time.
How to Implement IP Service Level Agreements
This section contains the following procedures: • Configuring IP Service Levels Using the UDP Jitter Operation, page SMC-50 • Configuring the IP SLA for a UDP Echo Operation, page SMC-60 • Configuring an ICMP Echo Operation, page SMC-68 • Configuring the ICMP Path Echo Operation, page SMC-75 • Configuring the ICMP Path Jitter Operation, page SMC-82
Cisco IOS XR System Management Configuration Guide SMC-49 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information Configuring IP Service Levels Using the UDP Jitter Operation
The IP SLA UDP Jitter monitoring operation is designed to diagnose network suitability for real-time traffic applications such as VoIP, Video over IP, or real-time conferencing. Jitter means interpacket delay variance. When multiple packets are sent consecutively from source to destination—for example, 10 ms apart—and if the network is behaving ideally, the destination can receive them 10 ms apart. But if there are delays in the network (for example, queuing, arriving through alternate routes, and so on), the arrival delay between packets can be greater than or less than 10 ms. Using this example, a positive jitter value indicates that the packets arrived more than 10 ms apart. If the packets arrive 12 ms apart, positive jitter is 2 ms; if the packets arrive 8 ms apart, negative jitter is 2 ms. For delay-sensitive networks like VoIP, positive jitter values are undesirable, and a jitter value of 0 is ideal. However, the IP SLA UDP Jitter operation does more than just monitor jitter. If the UDP Jitter operation includes the data returned by the IP SLA UDP operation, the UDP Jitter operation is used to gather data for the operation. The packets that IP SLA generates carry sending sequence and receiving sequence information for the packets, and sending and receiving time stamps from the source and the operational target. Based on these, UDP Jitter operations are capable of measuring the following functions: • Per-direction jitter (source to destination and destination to source) • Per-direction packet-loss • Per-direction delay (one-way delay) • Round-trip delay (average round-trip time) As the paths for the sending and receiving of data may be different (asymmetric), the per-direction data allows you to more readily identify where congestion or other problems are occurring in the network. The UDP Jitter operation functions by generating synthetic (simulated) UDP traffic. By default, ten packet-frames (N), each with a payload size of 32 bytes (S) are generated every 20 ms (T), and the operation is repeated every 60 seconds (F). Each of these parameters is user-configurable, so as to best simulate the IP service you are providing, or want to provide. This section contains the following procedures: • Enabling the IP SLA Responder on the Destination Device, page SMC-50 (required) • Configuring and Scheduling a UDP Jitter Operation on the Source Device, page SMC-52
Enabling the IP SLA Responder on the Destination Device
The IP SLA Responder must be enabled on the target device, which is the operational target. By configuring the ipsla responder command, you make the IP SLA Responder open a UDP port 1967 and wait for a control request (not for probes). You can open or close a port dynamically through the IP SLA control protocol (through UDP port 1967). In addition, you can configure permanent ports. Permanent ports are open until the configuration is removed. Agents can send IP SLA probe packets to the permanent port directly without a control request packet because the port can be opened by the configuration. If you do not use permanent ports, you only have to configure the ipsla responder command. To use a dynamic port, use the ipsla responder command as shown in the following example: configure ipsla responder
Cisco IOS XR System Management Configuration Guide SMC-50 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
The dynamic port is opened through the IP SLA control protocol on the responder side when you start an operation on the agent side. The example is configured as a permanent port on the responder, but a dynamic port is required for UDP Jitter. For UDP Echo, you can use a dynamic port or a permanent port. For UDP Jitter, you can use a dynamic port. If you use a permanent port for UDP Jitter, not all of the statistics are collected. For example, RTT is collected even if you use a permanent port for UDP Jitter.
SUMMARY STEPS
1. configure 2. ipsla responder 3. type udp ipv4 address ipaddress port port 4. end (optional) or commit (optional)
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla responder Enables the IP SLA Responder for UDP Echo or Jitter operations. Example: RP/0/RP0/CPU0:router(config)# ipsla responder RP/0/RP0/CPU0:router(config-ipsla-resp)#
Cisco IOS XR System Management Configuration Guide SMC-51 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 type udp ipv4 address ipaddress port port Enables the permanent address and port on the IP SLA Responder. Example: RP/0/RP0/CPU0:router(config-ipsla-resp)# type udp ipv4 address 12.7.34.13 port 11111 Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session
What to Do Next
After enabling the IP SLA Responder, see the “Configuring and Scheduling a UDP Jitter Operation on the Source Device” section on page SMC-52.
Configuring and Scheduling a UDP Jitter Operation on the Source Device
The IP SLA operations function by generating synthetic (simulated) network traffic. A single IP SLA operation (for example, IP SLA operation 10) repeats at a given frequency for the lifetime of the operation. A single UDP Jitter operation consists of N UDP packets, each of size S, sent T milliseconds apart, from a source router to a target router, at a given frequency of F. By default, ten packets (N), each with an RTP payload size of 32 bytes (S), are generated every 20 ms (T), and the operation is repeated every 60 seconds (F). Each of these parameters is user-configurable, as shown in Table 7.
Table 7 UDP Jitter Operation Parameters
UDP Jitter Operation Parameter Default Configured Using: Number of packets (N) 10 packets ipsla operation command; packet command with count keyword Payload size per packet (S) 32 bytes ipsla operation command; datasize command with request keyword
Cisco IOS XR System Management Configuration Guide SMC-52 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Table 7 UDP Jitter Operation Parameters (continued)
UDP Jitter Operation Parameter Default Configured Using: Time between packets, in 20 ms ipsla operation command; packet command with milliseconds (T) interval keyword Elapsed time before the operation 60 seconds ipsla operation command; frequency command repeats, in seconds (F)
Prerequisites for Configuring a UDP Jitter Operation on the Source Device
Use of the UDP Jitter operation requires that the IP SLA Responder be enabled on the target Cisco device. To enable the IP SLA Responder, perform the task in the “Enabling the IP SLA Responder on the Destination Device” section on page SMC-50.
Configuring and Scheduling a Basic UDP Jitter Operation on the Source Device
Perform this task to configure and schedule a UDP Jitter operation. To run an IP SLA operation, the ipsla reaction operation command and the ipsla reaction trigger command are not mandatory. If you want IP SLA to set some threshold and inform them of a threshold violation, the ipsla reaction operation command and the ipsla reaction trigger command are required.
SUMMARY STEPS
1. configure 2. ipsla operation number 3. type udp jitter 4. destination address ipv4address 5. destination port port 6. packet [count count | interval interval] 7. frequency seconds 8. exit 9. ipsla schedule operation op-num 10. life [forever | seconds] 11. ageout seconds 12. recurring 13. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 14. end (optional) or commit (optional)
Cisco IOS XR System Management Configuration Guide SMC-53 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 432 Step 3 type udp jitter Configures the operation as a UDP Jitter operation, and configures characteristics for the operation. Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type udp jitter Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# destination address 1.1.1.1 Step 5 destination port port Specifies the destination port number, in the range from 1 to 65535. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# destination port 11111 Step 6 packet [count count | interval interval] (Optional) Use the packet command with the following keywords: Example: • (Optional) Use the count keyword to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# number of packets to be transmitted during a probe. The packet count 5 default number of packets sent is 10. RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# • (Optional) Use the interval keyword to specify the time packet interval 20 between packets. The default interval between packets is 20 milliseconds. Step 7 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# number of seconds between the IP SLA operations. frequency 99 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds.
Cisco IOS XR System Management Configuration Guide SMC-54 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 8 exit Exits from IP SLA configuration mode and operational mode, and returns the CLI to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 9 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 10 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 30 Step 11 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 5 Step 12 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring
Cisco IOS XR System Management Configuration Guide SMC-55 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 13 start-time {hh:mm:[ss] month day} {now | Specifies a time for the operation to start. The following pending | after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. The RP/0/RP0/CPU0:router(config-ipsla-sched)# default is inactive. If the start-time command is not start-time 0:0:0 jan 1 specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information. Step 14 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session
Configuring and Scheduling a UDP Jitter Operation with Additional Characteristics
Perform this task to configure and schedule a UDP Jitter operation.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type udp jitter 4. destination address ipv4address 5. destination port port 6. frequency seconds
Cisco IOS XR System Management Configuration Guide SMC-56 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
7. statistics hourly [buckets hours | distribution {count interval | interval interval}] 8. datasize request size 9. tos number 10. timeout milliseconds 11. exit 12. ipsla schedule operation op-num 13. life [forever | seconds] 14. ageout seconds 15. recurring 16. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 17. end (optional) or commit (optional) 18. show ipsla statistics operation-number 19. show ipsla statistics aggregated operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 1 Step 3 type udp jitter Configures the operation as a UDP Jitter operation, and configures characteristics for the operation. Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type udp jitter Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# destination address 1.1.1.1 Step 5 destination port port Specifies the destination port number, in the range from 1 to 65535. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# destination port 11111
Cisco IOS XR System Management Configuration Guide SMC-57 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 6 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 7 statistics hourly [buckets hours | distribution (Optional) Specifies the statistics collection parameters for {count interval | interval interval}] UDP Jitter operation. • (Optional) Use the buckets keyword to set the number Example: of hours in which statistics are maintained for the IP RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# SLA operations. The range is 0 to 25 hours. The default statistics hourly value is 2 hours. RP/0/RP0/CPU0:router(config-ipsla-op-stats)# buckets 2 • (Optional) Use the distribution count keyword to set RP/0/RP0/CPU0:router(config-ipsla-op-stats)# the number of statistic distributions that are kept per distribution count 5 RP/0/RP0/CPU0:router(config-ipsla-op-stats)# hop during the life time of the IP SLA operation. The distribution interval 20 range is 1 to 20. The default value is 1 distribution. • (Optional) Use the distribution distribution interval keyword to set the time interval for each statistical distribution. The range is 1 to 100 ms. The default value is 20 ms. Step 8 datasize request size (Optional) Sets the data size in the payload of the operation's request packets. For UDP Jitter, the range is from 16 to 1500 bytes. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# datasize request 16 Step 9 timeout milliseconds (Optional) Sets the amount of time that the specified IP SLA operation waits for a response from its request packet. Example: • (Optional) Use the milliseconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# number of milliseconds that the operation waits to timeout 5000 receive a response. Step 10 tos number (Optional) Specifies the type of service number.
Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# tos 255 Step 11 exit Exits from IP SLA configuration mode and operational mode, and returns the CLI to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-jitter)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)#
Cisco IOS XR System Management Configuration Guide SMC-58 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 12 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 13 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 30 Step 14 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 5 Step 15 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 16 start-time {hh:mm:[ss] month day} {now | (Optional) Specifies a time for the operation to start. The pending | after hh:mm:ss} following keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. The RP/0/RP0/CPU0:router(config-ipsla-sched)# default is inactive. If the start-time command is not start-time 0:0:0 jan 1 specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-59 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 17 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 18 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1 Step 19 show ipsla statistics aggregated Returns the hourly statistics (aggregated data) on the operation-number performance of the network. The UDP Jitter operation provides the following hourly Example: statistics: RP/0/RP0/CPU0:router# show ipsla statistics aggregated 1 • Jitter statistics—Interprets telephony and multimedia conferencing requirements. • Packet loss and packet sequencing statistics—Interprets telephony, multimedia conferencing, streaming media, and other low-latency data requirements. • One-way latency and delay statistics—Interprets telephony, multimedia conferencing, and streaming media requirements.
Configuring the IP SLA for a UDP Echo Operation
To measure UDP performance on a network, use the IP SLA UDP Echo operation. A UDP Echo operation measures round-trip delay times and tests connectivity to Cisco devices and devices that are not Cisco devices. The results of a UDP Echo operation can be useful in troubleshooting issues with business-critical applications.
Cisco IOS XR System Management Configuration Guide SMC-60 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Note The UDP Echo operation requires a Cisco device that is running the IP SLA Responder, or a nonCisco device which is running the UDP Echo service.
Depending on whether you want to configure a basic UDP Echo operation or to configure a UDP Echo operation with optional parameters, perform one of the following tasks: • Configuring and Scheduling a UDP Echo Operation on the Source Device, page SMC-61 • Configuring and Scheduling a UDP Echo Operation with Optional Parameters on the Source Device, page SMC-64
Prerequisites for Configuring a UDP Echo Operation on the Source Device
If you are using the IP SLA Responder, ensure that you have completed the “Enabling the IP SLA Responder on the Destination Device” section on page SMC-50.
Configuring and Scheduling a UDP Echo Operation on the Source Device
Perform this task to enable a UDP Echo operation without any optional parameters.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type udp echo 4. destination address ipv4address 5. destination port port 6. frequency seconds 7. exit 8. ipsla schedule operation op-num 9. life [forever | seconds] 10. ageout seconds 11. recurring 12. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 13. end (optional) or commit (optional) 14. show ipsla statistics enhanced aggregated operation-number interval seconds 15. show ipsla statistics operation-number
Cisco IOS XR System Management Configuration Guide SMC-61 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 99 Step 3 type udp echo Configures the operation as a UDP Echo operation, and configures characteristics for the operation. Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type udp echo Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation.You can configure a permanent port on the IP SLA Responder side or you can use an UDP Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# Echo server. destination address 1.1.1.1 Step 5 destination port port Specifies the destination port number, in the range from 1 to 65535. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# destination port 11111 Step 6 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 7 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 8 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)#
Cisco IOS XR System Management Configuration Guide SMC-62 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 9 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 1 Step 10 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 1 Step 11 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 12 start-time {hh:mm:[ss] month day} {now | (Optional) Specifies a time for the operation to start. The pending | after hh:mm:ss} following keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. This RP/0/RP0/CPU0:router(config-ipsla-sched)# is the default value. If the start-time command is not start-time 0:0:0 jan 1 specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-63 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 13 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 14 show ipsla statistics enhanced aggregated Displays the enhanced history statistics. operation-number interval seconds
Example: RP/0/RP0/CPU0:router# show ipsla statistics enhanced aggregated 1 Step 15 show ipsla statistics operation-number Displays the current statistics. You must configure the enhanced history statistics to display the sample output. Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring and Scheduling a UDP Echo Operation with Optional Parameters on the Source Device
Perform this task to enable a UDP Echo operation on the source device and configure some optional IP SLA parameters. The source device is the location at which the measurement statistics are stored.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type udp echo 4. control disable 5. destination address ipv4address 6. destination port port 7. frequency seconds 8. datasize request size
Cisco IOS XR System Management Configuration Guide SMC-64 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
9. tos number 10. timeout milliseconds 11. tag text 12. exit 13. ipsla schedule operation op-num 14. life [forever | seconds] 15. ageout seconds 16. recurring 17. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 18. end (optional) or commit (optional) 19. show ipsla statistics enhanced aggregated operation-number interval seconds 20. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 99 Step 3 type udp echo Configures the operation as a UDP Echo operation, and configures characteristics for the operation. Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type udp echo Step 4 control disable (Optional) Disables the control packets.
Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# control disable Step 5 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# destination address 1.1.1.1
Cisco IOS XR System Management Configuration Guide SMC-65 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 6 destination port port Specifies the destination port number, in the range from 1 to 65535. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# destination port 11111 Step 7 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 8 datasize request size (Optional) Sets the protocol data size in the payload of the IP SLA operation's request packet. Example: • Use the size argument to specify the protocol data size RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# in bytes. The range is from 0 to the maximum of the datasize request 16 protocol. The default is 1 byte. Step 9 tos number (Optional) Defines a type of service (ToS) byte in the IP header of IP SLA operations. Example: Note The ToS byte is converted to a Differentiated RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# Services Code Point (DSCP) value, but you cannot tos 255 enter the DSCP value directly. To use a DSCP value, multiply it by 4 and enter the result as the value of the number argument. Step 10 timeout milliseconds (Optional) Sets the amount of time that the specified IP SLA operation waits for a response from its request packet. Example: • Use the milliseconds argument to specify the number of RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# milliseconds that the operation waits to receive a timeout 5000 response. Step 11 tag text (Optional) Creates a user-specified identifier for an IP SLA operation. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# type udp echo tag ipsla Step 12 exit Exits IP SLA operation configuration mode and IPSLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-udp-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 13 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)#
Cisco IOS XR System Management Configuration Guide SMC-66 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 14 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 30 Step 15 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 5 Step 16 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 17 start-time {hh:mm:[ss] month day} {now | Specifies a time for the operation to start. The following pending | after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. The RP/0/RP0/CPU0:router(config-ipsla-sched)# default value is inactive. If the start-time command is start-time 0:0:0 jan 1 not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-67 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 18 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 19 show ipsla statistics enhanced aggregated Displays the enhanced history statistics. operation-number interval seconds
Example: RP/0/RP0/CPU0:router# show ipsla statistics enhanced aggregated 1 Step 20 show ipsla statistics operation-number Displays the current statistics. You must configure the enhanced history statistics to display the sample output. Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring an ICMP Echo Operation
To monitor IP connections on a device, use the IP SLA ICMP Echo operation. An ICMP Echo operation measures end-to-end response times between a Cisco router and devices using IP. ICMP Echo is used to troubleshoot network connectivity issues.
Note The ICMP Echo operation does not require the IP SLA Responder to be enabled.
Depending on whether you want to configure and schedule a basic ICMP Echo operation or configure and schedule an ICMP Echo operation with optional parameters, perform one of the following procedures: • Configuring and Scheduling a Basic ICMP Echo Operation on the Source Device, page SMC-69 • Configuring and Scheduling an ICMP Echo Operation with Optional Parameters on the Source Device, page SMC-71
Cisco IOS XR System Management Configuration Guide SMC-68 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Configuring and Scheduling a Basic ICMP Echo Operation on the Source Device
Perform this task to enable and schedule an ICMP Echo operation without any optional parameters.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type icmp echo 4. destination address ipv4address 5. frequency seconds 6. exit 7. ipsla schedule operation op-num 8. life [forever | seconds] 9. ageout seconds 10. recurring 11. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 12. end (optional) or commit (optional) 13. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 1 Step 3 type icmp echo Defines an ICMP Echo operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp echo Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# destination address 1.1.1.1
Cisco IOS XR System Management Configuration Guide SMC-69 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 5 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-echo) number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 6 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 7 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 8 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 30 Step 9 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 5 Step 10 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring
Cisco IOS XR System Management Configuration Guide SMC-70 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 11 start-time {hh:mm:[ss] month day} {now | Specifies a time for the operation to start. The following pending | after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. The RP/0/RP0/CPU0:router(config-ipsla-sched)# default value is inactive. If the start-time command is start-time 0:0:0 jan 1 not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information. Step 12 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 13 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring and Scheduling an ICMP Echo Operation with Optional Parameters on the Source Device
Perform this task to enable an ICMP Echo operation on the source device and configure some optional IP SLA parameters.
SUMMARY STEPS
1. configure
Cisco IOS XR System Management Configuration Guide SMC-71 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
2. ipsla operation operation-number 3. type icmp echo 4. destination address ipv4address 5. frequency seconds 6. datasize request size 7. tos number 8. timeout milliseconds 9. tag text 10. exit 11. ipsla schedule operation op-num 12. life [forever | seconds] 13. ageout seconds 14. recurring 15. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 16. end or commit 17. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 1 Step 3 type icmp echo Defines an ICMP Echo operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp echo Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# destination address 1.1.1.1
Cisco IOS XR System Management Configuration Guide SMC-72 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 5 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 6 datasize request size (Optional) Sets the protocol data size in the payload of the request packet for the specified IP SLA operation. Example: • Use the bytes argument to specify the protocol data size RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# in bytes. The range is from 0 to 16384. The default is datasize request 28 36 bytes for ICMP Echo operation. Step 7 tos number (Optional) Defines a type of service (ToS) byte in the IP header of IP SLA operations. Example: Note The ToS byte can be converted to a Differentiated RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# Services Code Point (DSCP) value, but you cannot tos 1 enter the DSCP value directly. To use a DSCP value, multiply it by 4 and enter the result as the value of the number argument. Step 8 timeout milliseconds (Optional) Sets the amount of time that the IP SLA operation waits for a response from its request packet. Example: • Use the milliseconds argument to specify the number of RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# milliseconds that the operation waits to receive a timeout 2000 response. Step 9 tag text (Optional) Creates a user-specified identifier for an IP SLA operation. Example:
Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# tag ipsla Step 10 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 11 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)#
Cisco IOS XR System Management Configuration Guide SMC-73 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 12 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime of Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life an operation is 3600 seconds (one hour). 30 Step 13 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that the Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# operation never times out. ageout 5 Step 14 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 15 start-time {hh:mm:[ss] month day} {now | Specifies a time for the operation to start. The following pending | after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure the Example: operation to remain in a pending (unstarted) state. The RP/0/RP0/CPU0:router(config-ipsla-sched)# default value is inactive. If the start-time command is start-time 0:0:0 jan 1 not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-74 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 16 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 17 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring the ICMP Path Echo Operation
The IP SLA ICMP Path Echo operation records statistics for each hop along the path that the IP SLA operation takes to reach its destination. The ICMP Path Echo operation determines the hop-by-hop response time between a Cisco router and any IP device on the network by discovering the path using the traceroute facility. The source IP SLA device uses traceroute to discover the path to the destination IP device. A ping is then used to measure the response time between the source IP SLA device and each subsequent hop in the path to the destination IP device. By using the statistics that is recorded for the response times and availability, the ICMP Path Echo operation can identify a hop in the path, which identifies the delay that is introduced at each hop.
Note The ICMP Path Echo operation does not require the IP SLA Responder to be enabled.
Depending on whether you want to configure and schedule a basic ICMP Path Echo operation or configure and schedule an ICMP Path Echo operation with optional parameters, perform one of the following procedures: • Configuring and Scheduling a Basic ICMP Echo Operation on the Source Device, page SMC-69 • Configuring and Scheduling an ICMP Echo Operation with Optional Parameters on the Source Device, page SMC-71
Cisco IOS XR System Management Configuration Guide SMC-75 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Configuring and Scheduling a Basic ICMP Path Echo Operation on the Source Device
Perform this task to enable and schedule an ICMP Path Echo operation without any optional parameters.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type icmp path-echo 4. destination address ipv4address 5. frequency seconds 6. exit 7. ipsla schedule operation op-num 8. life [forever | seconds] 9. ageout seconds 10. recurring 11. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 12. end (optional) or commit (optional) 13. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 12 Step 3 type icmp path-echo Defines an ICMP Path Echo operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp path-echo RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)#
Cisco IOS XR System Management Configuration Guide SMC-76 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# destination address 1.1.1.1 Step 5 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 6 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 7 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 8 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default lifetime Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life 30 of an operation is 3600 seconds (one hour). Step 9 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# ageout 5 the operation never times out. Step 10 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring
Cisco IOS XR System Management Configuration Guide SMC-77 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 11 start-time {hh:mm:[ss] month day} {now | pending | Specifies a time for the operation to start. The following after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure Example: the operation to remain in a pending (unstarted) RP/0/RP0/CPU0:router(config-ipsla-sched)# state. The default value is inactive. If the start-time start-time 0:0:0 jan 1 command is not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information. Step 12 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 13 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring and Scheduling an ICMP Path Echo Operation with Optional Parameters on the Source Device
Perform this task to enable an ICMP Path Echo operation on the source device and configure some optional IP SLA parameters.
SUMMARY STEPS
1. configure
Cisco IOS XR System Management Configuration Guide SMC-78 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
2. ipsla operation operation-number 3. type icmp path-echo 4. destination address ipv4address 5. frequency seconds 6. datasize request size 7. tos number 8. timeout milliseconds 9. tag text 10. lsr-path ip address 11. exit 12. ipsla schedule operation op-num 13. life [forever | seconds] 14. ageout seconds 15. recurring 16. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 17. end or commit 18. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 12 Step 3 type icmp path-echo Defines an ICMP Path Echo operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp path-echo RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)#
Cisco IOS XR System Management Configuration Guide SMC-79 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# destination address 1.1.1.1 Step 5 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# number of seconds between the IP SLA operations. frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 6 datasize request size (Optional) Sets the protocol data size in the payload of the request packet for the specified IP SLA operation. Example: • Use the bytes argument to specify the protocol data RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# size in bytes. The range is from 0 to 16384. The datasize request 4 default is 36 bytes. Step 7 tos number (Optional) Defines a type of service (ToS) byte in the IP header of IP SLA operations. Example: Note The ToS byte can be converted to a RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# Differentiated Services Code Point (DSCP) tos 5 value, but you cannot enter the DSCP value directly. To use a DSCP value, multiply it by 4 and enter the result as the number argument. Step 8 timeout milliseconds (Optional) Sets the amount of time that the IP SLA operation waits for a response from its request packet. Example: • Use the milliseconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# number of milliseconds that the operation waits to timeout 2000 receive a response. Step 9 tag text (Optional) Creates a user-specified identifier for an IP SLA operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# tag ipsla Step 10 lsr-path ip address (Optional) Specifies the path in which to measure the ICMP Echo response time. Example: • (Optional) Use the ip address argument of the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# intermediate node. lsr-path 1.1.1.1 Step 11 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-echo)# exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)#
Cisco IOS XR System Management Configuration Guide SMC-80 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 12 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 13 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The default Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life 1 lifetime of an operation is 3600 seconds (one hour). Step 14 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# ageout 1 the operation never times out. Step 15 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 16 start-time {hh:mm:[ss] month day} {now | pending | Specifies a time for the operation to start. The following after hh:mm:ss} keywords are described: • (Optional) Use the pending keyword to configure Example: the operation to remain in a pending (unstarted) RP/0/RP0/CPU0:router(config-ipsla-sched)# state. The default value is inactive. If the start-time start-time 0:0:0 jan 1 command is not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-81 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 17 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 18 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring the ICMP Path Jitter Operation
The IP SLA ICMP Path Jitter operation provides hop-by-hop jitter, packet loss, and delay measurement statistics in an IP network. The Path Jitter operation functions differently than the standard UDP Jitter operation, which provides total one-way data and total round-trip data. The ICMP Path Jitter operation is used as a supplement to the standard UDP Jitter operation. For example, results from the UDP Jitter operation can indicate unexpected delays or high jitter values; the ICMP Path Jitter operation can then be used to troubleshoot the network path and determine if traffic is bottlenecking in a particular segment along the transmission path. The operation first discovers the hop-by-hop IP route from the source to the destination using a traceroute utility, and uses ICMP echoes to determine the response times, packet loss and approximate jitter values for each hop along the path. The jitter values obtained using the ICMP Path Jitter operation are approximate, because does not account for delays at the target nodes. The ICMP Path Jitter operation functions by tracing the IP path from a source device to a specified destination device, then sending N number of Echo probes to each hop along the traced path, with a time interval of T milliseconds between each Echo probe. The operation as a whole is repeated at a frequency of once every F seconds. The attributes are user-configurable, as described in Table 8.
Cisco IOS XR System Management Configuration Guide SMC-82 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Table 8 ICMP Path Jitter Operation Parameters
ICMP Path Jitter Operation Parameter Default Configured Using: Number of echo probes (N) 10 echoes ipsla operation command; packet command with count keyword Time between Echo probes, in 20 ms ipsla operation command; packet command milliseconds (T) with interval keyword; The frequency of how often the once every 60 ipsla operation command; frequency operation is repeated (F) seconds command
Depending on whether you want to configure and schedule a basic ICMP Path Jitter operation or configure and schedule an ICMP Jitter Operation with additional parameters, perform one of the following procedures: • Configuring and Scheduling a Basic ICMP Path Jitter Operation, page SMC-83 • Configuring and Scheduling an ICMP Path Jitter Operation with Additional Parameters, page SMC-86
Configuring and Scheduling a Basic ICMP Path Jitter Operation
Perform this task to configure and schedule an ICMP Path Jitter operation using the general default characteristics for the operation.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type icmp path-jitter 4. destination address ipv4address 5. packet [count count | interval interval] 6. frequency seconds 7. exit 8. ipsla schedule operation op-num 9. life [forever | seconds] 10. ageout seconds 11. recurring 12. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 13. end (optional) or commit (optional) 14. show ipsla statistics operation-number
Cisco IOS XR System Management Configuration Guide SMC-83 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 12 Step 3 type icmp path-jitter Defines an ICMP Path Jitter operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp path-jitter Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) # destination address 1.1.1.1 Step 5 packet [count count | interval interval] (Optional) Use the packet command with the following keywords: Example: • (Optional) Use the count keyword to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) number of packets to be transmitted during a probe. # packet count 5 The default number of packets sent is 10. RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) • (Optional) Use the interval keyword to specify the # packet interval 20 time between packets. The default interval between packets is 20 milliseconds. Step 6 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) number of seconds between the IP SLA operations. # type icmp path-jitter frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds. Step 7 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) # exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)#
Cisco IOS XR System Management Configuration Guide SMC-84 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 8 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 9 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life 30 default lifetime of an operation is 3600 seconds (one hour). Step 10 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# ageout 5 the operation never times out. Step 11 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 12 start-time {hh:mm:[ss] month day} {now | pending | (Optional) Specifies a time for the operation to start. after hh:mm:ss} The following keywords are described: • (Optional) Use the pending keyword to configure Example: the operation to remain in a pending (unstarted) RP/0/RP0/CPU0:router(config-ipsla-sched)# state. The default value is inactive. If the start-time 0:0:0 jan 1 start-time command is not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information.
Cisco IOS XR System Management Configuration Guide SMC-85 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 13 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 14 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Configuring and Scheduling an ICMP Path Jitter Operation with Additional Parameters
Perform this task to enable an ICMP Path Echo operation on the source device and configure some optional IP SLA parameters.
SUMMARY STEPS
1. configure 2. ipsla operation operation-number 3. type icmp path-jitter 4. destination address ipv4address 5. packet [count count | interval interval] 6. frequency seconds 7. datasize request size 8. tos number 9. timeout milliseconds 10. tag text 11. exit 12. ipsla schedule operation op-num
Cisco IOS XR System Management Configuration Guide SMC-86 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
13. life [forever | seconds] 14. ageout seconds 15. recurring 16. start-time {hh:mm:[ss] month day} {now | pending | after hh:mm:ss} 17. end or commit 18. show ipsla statistics operation-number
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ipsla operation operation-number Specifies the operation number. The range is from 1 to 2048. Example: RP/0/RP0/CPU0:router(config)# ipsla operation 12 Step 3 type icmp path-jitter Defines an ICMP Path Jitter operation type.
Example: RP/0/RP0/CPU0:router(config-ipsla-op)# type icmp path-jitter Step 4 destination address ipv4address Specifies the IP address or IP hostname of the destination for the UDP Jitter operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) # destination address 1.1.1.1 Step 5 packet [count count | interval interval] (Optional) Use the packet command with the following keywords: Example: • (Optional) Use the count keyword to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) number of packets to be transmitted during a # packet count 5 probe. The default number of packets sent is 10. RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) • (Optional) Use the interval keyword to specify the # packet interval 20 time between packets. The default interval between packets is 20 milliseconds Step 6 frequency seconds (Optional) Sets the rate at which a specified IP SLA operation is sent into the network. Example: • (Optional) Use the seconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) number of seconds between the IP SLA operations. # frequency 60 Valid values are in the range from 1 to 12604800 seconds. The default is 60 seconds.
Cisco IOS XR System Management Configuration Guide SMC-87 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 7 datasize request size (Optional) Sets the protocol data size in the payload of the request packet for the specified IP SLA operation. Example: • Use the size argument to specify the protocol data RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) size in bytes. The default for jitter is 36 bytes. The # datasize request 1 range is 0 to 16384 bytes. Step 8 tos number (Optional) Defines a type of service (ToS) byte in the IP header of IP SLA operations. Example: Note The ToS byte can be converted to a RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) Differentiated Services Code Point (DSCP) # tos 1 value, but you cannot enter the DSCP value directly. To use a DSCP value, multiply it by 4 and enter the result as the number argument. Step 9 timeout milliseconds (Optional) Sets the amount of time that the IP SLA operation waits for a response from its request packet. Example: • Use the milliseconds argument to specify the RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) number of milliseconds that the operation waits to # timeout 2000 receive a response. Step 10 tag text (Optional) Creates a user-specified identifier for an IP SLA operation. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) # tag ipsla Step 11 exit Exits IP SLA operation configuration mode and IP SLA configuration mode. Returns to global configuration mode. Example: RP/0/RP0/CPU0:router(config-ipsla-icmp-path-jitter) # exit RP/0/RP0/CPU0:router(config-ipsla-op)# exit RP/0/RP0/CPU0:router(config-ipsla)# exit RP/0/RP0/CPU0:router(config)# Step 12 ipsla schedule operation op-num Schedules the start time of the operation. You can configure a basic schedule or schedule multiple operations using group scheduling. Example: RP/0/RP0/CPU0:router(config)# ipsla schedule operation 1 RP/0/RP0/CPU0:router(config-ipsla-sched)# Step 13 life [forever | seconds] (Optional) The forever keyword schedules the operation to run indefinitely. The seconds argument schedules the lifetime of the operation, in seconds. The Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# life 30 default lifetime of an operation is 3600 seconds (one hour). Step 14 ageout seconds (Optional) Specifies the number of seconds to keep the operation in memory when it is not actively collecting information. The default value of 0 seconds means that Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# ageout 5 the operation never times out.
Cisco IOS XR System Management Configuration Guide SMC-88 Implementing IP Service Level Agreements on Cisco IOS XR Software How to Implement IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 15 recurring (Optional) Specifies that the operation starts automatically at the specified time and for the specified duration every day. Example: RP/0/RP0/CPU0:router(config-ipsla-sched)# recurring Step 16 start-time {hh:mm:[ss] month day} {now | pending | Specifies a time for the operation to start. The after hh:mm:ss} following keywords are described: • (Optional) Use the pending keyword to configure Example: the operation to remain in a pending (unstarted) RP/0/RP0/CPU0:router(config-ipsla-sched)# state. The default value is inactive. If the start-time 0:0:0 jan 1 start-time command is not specified, no information is collected until the start time is configured or a trigger occurs that performs an immediate start. • (Optional) Use the now keyword to indicate that the operation should start immediately. • (Optional) Use the after keyword and associated arguments to specify the time after which the operation starts collecting information. Step 17 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session Step 18 show ipsla statistics operation-number Displays the current statistics.
Example: RP/0/RP0/CPU0:router# show ipsla statistics 1
Cisco IOS XR System Management Configuration Guide SMC-89 Implementing IP Service Level Agreements on Cisco IOS XR Software Configuration Examples for Implementing IP Service Level Agreements R3.3.0 Beta Draft—Cisco Confidential Information Configuration Examples for Implementing IP Service Level Agreements
• Configuring IP Service Level Agreements: Example, page SMC-90
Configuring IP Service Level Agreements: Example
The following example shows how to configure and schedule a UDP Echo operation: configure ipsla operation 1 type udp echo destination address 1.1.1.1 destination port 11111 frequency 60 exit ipsla schedule operation 1 life 30 ageout 5 recurring start-time after 0:0:1 commit show ipsla statistics 1
Additional References
The following sections provide references related to IP Service Level Agreements.
Cisco IOS XR System Management Configuration Guide SMC-90 Implementing IP Service Level Agreements on Cisco IOS XR Software Additional References R3.3.0 Beta Draft—Cisco Confidential Information Related Documents
Related Topic Document Title IP Service Level Agreement Commands on Cisco IOS XR System Management Command Reference Cisco IOS XR Software
Standards
Standards Title ——
MIBs
MIBs MIBs Link • CISCO-RTTMON-MIB To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature.
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMC-91 Implementing IP Service Level Agreements on Cisco IOS XR Software Additional References R3.3.0 Beta Draft—Cisco Confidential Information
Cisco IOS XR System Management Configuration Guide SMC-92 R3.3 Beta Draft—Cisco Confidential Information
Configuring and Managing Fault Management Policies on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
The Cisco IOS XR Fault Manager is the central clearinghouse for events detected by any portion of Cisco IOS XR software route processor (RP) failover services. The Fault Manager is responsible for detection of fault events, fault recovery, and process reliability statistics in the Cisco IOS XR system. Fault Manager events are notifications that something significant has occurred within the system, such as: • Operating or performance statistics outside allowable values (for example, free memory dropping below a critical threshold). • Online insertion or removal (OIR) of a modular services card (MSC). • Termination of a process. The Fault Manager relies on software agents, “fault detectors,” to notify it when certain system events occur. Once the Fault Manager has detected an event, it can initiate corrective actions. Actions are prescribed in routines called policies. Policies must be registered before any action can be applied to collected events. No action occurs unless a policy is registered. A registered policy informs the Fault Manager about a particular event to detect and the corrective action to take if that event is detected. When such an event is detected, the Fault Manager enables the policy. You can disable a registered policy at any time. The Fault Manager monitors the reliability rates achieved by each process in the system, allowing the system to detect any components that compromise overall reliability or availability. This module describes the new and revised tasks you need to configure and manage fault management policies on your Cisco IOS XR network.
Note For complete descriptions of the fault management commands listed in this module, you can refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Cisco IOS XR System Management Configuration Guide SMR-93 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Contents R3.3 Beta Draft—Cisco Confidential Information
Feature History for Configuring and Managing Fault Management Policies on Cisco IOS XR Software Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification Release 3.2 This feature was supported on the Cisco XR 12000 Series Router. Release 3.3 Support was added for AAA authentication when executing a script.
Contents
• Prerequisites for Configuring and Managing Fault Management Policies, page 94 • Information About Configuring and Managing Fault Management Policies, page 95 • How to Configure and Manage Fault Management Policies, page 104 • Configuration Examples for Fault Management Policies, page 110 • Additional References, page 111
Prerequisites for Configuring and Managing Fault Management Policies
Before configuring fault management policies in your network operations center (NOC), ensure that the following prerequisites are met: • You must install and activate the Package Installation Envelope (PIE) for the manageability software. For detailed information about optional PIE installation, refer to the Cisco IOS XR Getting Started Guide. • You must be in a user group associated with a task group that includes the proper task IDs for fault management commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide.
Cisco IOS XR System Management Configuration Guide SMR-94 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information Information About Configuring and Managing Fault Management Policies
To implement fault management policies, you need to understand the following concepts: • Fault Management, page 95 • Fault Management Policies, page 96 • Fault Management Scripts and the Scripting Interface (Tcl), page 96 • Fault Manager Built-In Actions, page 99 • Application-Specific Fault Management, page 99 • Fault Detection and Recovery, page 99 • Fault Manager Event Scheduling and Notification, page 102 • Reliability Statistics, page 102
Fault Management
Fault management in the Cisco IOS XR system essentially involves system event management. An event can be any significant occurrence (not limited to errors) that has happened within the system. The Cisco IOS XR Fault Manager detects those events and implements appropriate responses. The Fault Manager can also be used to prevent or contain faults and assist in fault recovery. The Fault Manager enables a system administrator to specify appropriate action based on the current state of the system. For example, a system administrator can use fault management to request notification by e-mail when a hardware device needs replacement. The Fault Manager also maintains reliability metrics for each process in the system.
System Event Detection
The Fault Manager interacts with routines, “fault detectors,” that actively monitor the system for events. The Fault Manager relies on a fault detector that it has provided to syslog to detect that a certain system event has occurred. It uses a pattern match with the syslog messages. It also relies on a timer fault detector to detect that a certain time and date has occurred.
Policy-Based Event Response
Once the Fault Manager has detected an event, it can initiate actions in response. These actions are contained in routines called policy handlers. While the data for event detection is collected, no action occurs unless a policy for responding to that event has been registered. At registration, a policy informs the Fault Manager that it is looking for a particular event. When the Fault Manager detects the event, it enables the policy.
Reliability Metrics
The Fault Manager monitors the reliability rates achieved by each process in the system. These metrics can be used during testing to determine which components do not meet their reliability or availability goals so that corrective action can be taken.
Cisco IOS XR System Management Configuration Guide SMR-95 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
System Event Processing
When the Fault Manager receives an event notification, it takes the following actions: • Checks for established policy handlers: – If a policy handler exists, the Fault Manager initiates callback routines (Fault Manager handlers) or runs Tool Command Language (Tcl) scripts (Fault Manager scripts) that implement policies. The policies can include built-in Fault Manager actions. – If a policy handler does not exist, the Fault Manager does nothing. • Notifies the processes that have subscribed for event notification.
Note A difference exists between scripts with policy actions and scripts that subscribe to receive events. Scripts with policy actions are expected to implement a policy. They are bound by a rule to prevent recursion. Scripts that subscribe to notifications are not bound by such a rule.
• Records reliability metric data for each process in the system. • Provides access to Fault Manager maintained system information through an application program interface (API).
Fault Management Policies
Once the Fault Manager has detected an event, it can initiate corrective actions. Actions are prescribed in routines called policies. Policies are defined by Tcl scripts (Fault Manager scripts) written by the user through a Tcl API. (See the “Fault Management Scripts and the Scripting Interface (Tcl)” section.) Policies must be registered before any action can be applied to collected events. No action occurs unless a policy is registered. A registered policy informs the Fault Manager about a particular event to detect and the corrective action to take if that event is detected. When such an event is detected, the Fault Manager runs the policy. You can disable a registered policy at any time.
Fault Management Scripts and the Scripting Interface (Tcl)
Fault Manager scripts are used to implement policies when a Fault Manager event is published. Fault Manager scripts and policies are identified to the Fault Manager using the fault manager policy configuration command. A Fault Manager script remains available to be scheduled by the Fault Manager until the no fault manager policy command is entered. The Fault Manager uses the following two types of Fault Manager scripts: • Regular Fault Manager scripts identified to the Fault Manager through the fm script CLI command. Regular Fault Manager scripts are standalone scripts that incorporate the definition of the event they will handle. • Fault Manager callback scripts identified to the Fault Manager when a process or Fault Manager script registers to handle an event. Fault Manager callback scripts are essentially named functions that are identified to the Fault Manager through the C Language API.
Cisco IOS XR System Management Configuration Guide SMR-96 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Script Language
The scripting language is Tcl as implemented within the Cisco IOS XR software. This full Tcl implementation has been extended by Cisco, and an fm command has been added to provide the interface between Tcl scripts and the Fault Manager. To find out more about the Tcl language and its history, refer to the following URL: http://www.scriptics.com/scripting/tclHistory.html
Regular Fault Manager Scripts
Regular Fault Manager scripts are used to implement policies when a Fault Manager event is published. Fault Manager scripts are identified to the Fault Manager using the fault manager policy configuration command. A Fault Manager script remains available to be scheduled by the Fault Manager until the no fault manager policy command is entered. Fault Manager scripts are stored in the /tcl/fm_scripts directory within the lib directory for each Cisco IOS XR component. The first executable line of code within a Fault Manager script must be the fm event register keyword. This keyword identifies the Fault Manager event for which that script should be scheduled. The keyword is used by the fault manager policy configuration command to register to handle the specified Fault Manager event. Fault Manager scripts are free to use any of the Fault Manager script services listed in the “Fault Manager Script Services” section. When a Fault Manager script exits, it is responsible for setting a return code that is used to tell the Fault Manager whether to run the default action for this Fault Manager event (if any) or no other action. If multiple event handlers are scheduled for a given event, the return code from the previous handler is passed into the next handler, which can leave the value as is or update it.
Note A Fault Manager script cannot register to handle an event other than the event that caused it to be scheduled.
Fault Manager Callback Scripts
Fault Manager callback scripts are entered as a result of a Fault Manager event being raised for a previously registered Fault Manager event that specifies the name of this script in the fm_handler_spec. When a Fault Manager callback script exits, it is responsible for setting a return code that is used to tell the Fault Manager whether to run the default action for this Fault Manager event (if any). If multiple event handlers are scheduled for a given event, the return code from the previous handler is passed into the next handler, which can leave the value as is or update it.
Note Fault Manager callback scripts are free to use any of the Fault Manager script services listed in Table 9, except for the fm event register keyword, which is not allowed in a Fault Manager callback script.
Cisco IOS XR System Management Configuration Guide SMR-97 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Fault Manager Script Services
Table 9 lists script services that are available for defining policies through a Fault Manager script
. Table 9 Fault Manager Script Services
Fault Manager Script Service Tcl Built-In Keyword Description Register a Fault fm event register Called to register a Fault Manager event. This Manager event keyword must be the first keyword within a regular Fault Manager script. It should not be used within a Fault Manager callback script. Request information fm event reqinfo Called to receive information about the Fault about a Fault Manager Manager event that caused this Fault Manager event script to be entered. Request a Fault fm action Called to request a built-in Fault Manager action. Manager action Arm or rearm a Fault fm timer arm Called to arm or rearm a Fault Manager timer for Manager timer the Fault Manager event that caused this script to be scheduled. Cancel a Fault Manager fm timer cancel Called to cancel a Fault Manager timer for the timer Fault Manager event that caused this script to be scheduled. Read Fault Manager fm sys reqinfo Called to read system-specific information. system-specific information Set application state fm appl setinfo Called to set application-specific information. information Read application state fm appl reqinfo Called to read application-specific information. information Publish a Fault Manager fm event publish Called to publish an application-specific Fault event Manager event.
Cisco IOS XR System Management Configuration Guide SMR-98 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information Fault Manager Built-In Actions
Fault Manager built-in actions can be requested from Fault Manager handlers when the handlers run. Each Fault Manager handler request, or action, is described in Table 10
. Table 10 Fault Manager Built-In Actions
Fault Manager Built-In Action Description Log a message to syslog Sends a message to the syslog. Arguments to this action are priority and the message to be logged. Dump the version table Interfaces with the Version Manager to dump the version table to the syslog.
Fault Manager handlers require the ability to run CLI commands. A command is available to the Tcl shell to allow execution of CLI commands from within Tcl scripts.
Application-Specific Fault Management
Any Cisco IOS XR application can define and publish application-defined events. Application-defined events are identified by a name that includes both the component name and event name to allow application developers to assign their own event identifiers. Application-defined events can be raised by an Cisco IOS XR component even when there are no subscribers. In this case, the Fault Manager dismiss the event, which allows subscribers to receive application-defined events on an as-needed basis. A Fault Manager script that subscribes to receive system events is processed in the following order: 1. The following CLI configuration command is entered: fault manager policy scriptfilename. 2. The Fault Manager scans the Fault Manager script looking for an fm event event_type keyword and subscribes the Fault Manager script to be scheduled for the specified event. 3. The Fault Detector detects an event and contacts the Fault Manager. 4. The Fault Manager schedules event processing, causing the Fault Manager script to be run. 5. The Fault Manager script routine returns.
Fault Detection and Recovery
Faults and events are detected by routines called fault detectors. Fault detectors are separate programs that provide an interface between other Cisco IOS XR components and the Fault Manager. They process information that can be used to publish events, if necessary. A Fault Manager event is defined as a notification that something significant has happened within the system. Two categories of events exist: • System Fault Manager events • Application-defined events System Fault Manager events are built in to the Fault Manager and are grouped based on the fault detector that raises them. They are identified by a symbolic identifier defined within the API.
Cisco IOS XR System Management Configuration Guide SMR-99 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Any Cisco IOS XR application can define and publish application-defined events. Application-defined events are identified by a name that includes both the component name and event name to allow application developers to assign their own event identifiers. Application-defined events can be raised by a Cisco IOS XR component even when there are no subscribers. In this case, the Fault Manager dismisses the event, which allows subscribers to receive application-defined events on an as-needed basis. Some Fault Manager system events are monitored by the Fault Manager whether or not an application has requested monitoring. These are called built-in Fault Manager events. Other Fault Manager events are monitored only if an application has requested Fault Manager event monitoring. Fault Manager event monitoring is requested through a Fault Manager application API or the Fault Manager scripting interface. Some fault detectors can be distributed to other hardware cards within the same logical router or within the Admin plane to provide support for distributed components running on those cards.
System Manager Fault Detector
The System Manager Fault Detector has four roles: • Records process reliability metric data. • Screens for processes that have Fault Manager event monitoring requests outstanding. • Publishes events for those processes that match the screening criteria. • Asks the System Manager to perform its default action for those events that do not match the screening criteria. The System Manager Fault Detector interfaces with the System Manager to receive process startup and termination notifications. The interfacing is made through a private API available to the System Manager. To minimize overhead, a portion of the API resides within the System Manager process space. When a process terminates, the System Manager invokes a helper process (if specified in the process.startup file) before calling the Fault Detector API. Processes can be identified by component ID, System Manager assigned job ID, or load module pathname plus process instance ID. POSIX wildcard filename pattern support using *, ?, or [...] is provided for load module pathnames. Process instance ID is an integer assigned to a process to differentiate it from other processes with the same pathname. The first instance of a process is assigned an instance ID value of 1, the second 2, and so on. The System Manager Fault Detector handles Fault Manager event monitoring requests for the Fault Manager events shown in Table 11
. Table 11 System Manager Fault Detector Event Monitoring Requests
Fault Manager Event Description Normal process termination Fault Manager Occurs when a process matching the screening criteria event—built in terminates. Abnormal process termination Fault Occurs when a process matching the screening criteria Manager event—built in terminates abnormally. Process startup Fault Manager Occurs when a process matching the screening criteria event—built in starts.
Cisco IOS XR System Management Configuration Guide SMR-100 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
When System Manager Fault Detector abnormal process termination events occur, the default action restarts the process according to the built-in rules of the System Manager. The relationship between the Fault Manager and System Manager is strictly through the private API provided by the Fault Manager to the System Manager for the purpose of receiving process start and termination notifications. When the System Manager calls the API, reliability metric data is collected and screening is performed for a Fault Manager event match. If a match occurs, a message is sent to the System Manager Fault Detector, and for the case of abnormal process terminations, a return is made indicating that the Fault Manager handles process restart. If a match does not occur, a return is made indicating that the System Manager should apply the default action.
Timer Services Fault Detector
The Timer Services Fault Detector implements time-related Fault Manager events. These events are identified through user-defined identifiers so that multiple processes can await notification for the same Fault Manager event. The Timer Services Fault Detector handles Fault Manager event monitoring requests for the Date/Time Passed Fault Manager event. This event occurs when the current date or time passes the specified date or time requested by an application.
Syslog Fault Detector
The syslog Fault Detector implements syslog message screening for syslog Fault Manager events. This routine interfaces with the syslog daemon through a private API. To minimize overhead, a portion of the API resides within the syslog daemon process. Screening is provided for the message severity code or the message text fields. POSIX regular expression pattern support is provided for the message text field. The Syslog Fault Detector handles Fault Manager event monitoring requests for the events shown in Table 12.
Table 12 Syslog Fault Detector Event Monitoring Requests
Fault ManagerFault Manager Event Description Syslog message Fault Manager Occurs for a just-logged message. It occurs when there is a match event for either the syslog message severity code or the syslog message text pattern. Both can be specified when an application requests a syslog message Fault Manager event. Process event manager Fault Occurs when the event-processed count for a specified process is Manager event—built in either greater than or equal to a specified maximum or is less than or equal to a specified minimum. Process percent CPU Fault Occurs when the CPU time for a specified process is either greater Manager event—built in than or equal to a specified maximum percentage of available CPU time or is less than or equal to a specified minimum percentage of available CPU time. Total percent CPU Fault Occurs when the CPU time for a specified processor complex is Manager event—built in either greater than or equal to a specified maximum percentage of available CPU time or is less than or equal to a specified minimum percentage of available CPU time.
Cisco IOS XR System Management Configuration Guide SMR-101 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Table 12 Syslog Fault Detector Event Monitoring Requests
Fault ManagerFault Manager Event Description Process percent memory Fault Occurs when the memory used for a specified process has either Manager event—built in increased or decreased by a specified value. Total percent available Memory Occurs when the available memory for a specified processor Fault Manager event—built in complex has either increased or decreased by a specified value. Total percent used memory Fault Occurs when the used memory for a specified processor complex Manager event—built in has either increased or decreased by a specified value.
Distributed Fault Detectors
Cisco IOS XR components that interface to Fault Manager fault detectors and that have substantially independent implementations running on a distributed hardware card should have a distributed Fault Manager fault detector. The distributed fault detector permits scheduling of Fault Manager events for local processes without requiring that the local hardware card to the Fault Manager communication channel be active. The following fault detectors run on a Cisco IOS XR line card: • System Manager Fault Detector • Timer Services Fault Detector • Wdsysmon Fault Detector
Fault Manager Event Scheduling and Notification
When a Fault Manager handler is scheduled, it runs under the context of the process that creates the event request (or for Fault Manager scripts under the Tcl shell process context). For events that occur for a process running a Fault Manager handler, event scheduling is blocked until the handler exits. The defined default action (if any) is performed instead. The Fault Manager Server maintains queues containing event scheduling and notification items across client process restarts, if requested.
Reliability Statistics
Reliability metric data for the entire processor complex is maintained by the Fault Manager. The data is periodically written to checkpoint.
Cisco IOS XR System Management Configuration Guide SMR-102 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Information About Configuring and Managing Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Hardware Card Reliability Metric Data
Reliability metric data is kept for each hardware card in a processor complex. Data is recorded in a table indexed by disk ID. Data maintained by the hardware card is as follows: • Most recent start time • Most recent normal end time (controlled switchover) • Most recent abnormal end time (asynchronous switchover) • Most recent abnormal type • Cumulative available time • Cumulative unavailable time • Number of times hardware card started • Number of times hardware card shut down normally • Number of times hardware card shut down abnormally
Process Reliability Metric Data
Reliability metric data is kept for each process handled by the System Manager. This data includes standby processes running on either the primary or backup hardware card. Data is recorded in a table indexed by hardware card disk ID plus process pathname plus process instance for those processes that have multiple instances. Process terminations include the following cases: • Normal termination—Process exits with an exit value equal to 0. • Abnormal termination by process—Process exits with an exit value not equal to 0. • Abnormal termination by QNX—Neutrino operating system aborts the process. • Abnormal termination by kill process API—API kill process terminates the process. Data to be maintained by process is as follows: • Most recent process start time • Most recent normal process end time • Most recent abnormal process end time • Most recent abnormal process end type • Previous ten process end times and types • Cumulative process available time • Cumulative process unavailable time • Cumulative process run time (the time when the process is actually running on the CPU) • Number of times started • Number of times ended normally • Number of times ended abnormally
Cisco IOS XR System Management Configuration Guide SMR-103 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
• Number of abnormal failures within the past 60 minutes • Number of abnormal failures within the past 24 hours • Number of abnormal failures within the past 30 days
How to Configure and Manage Fault Management Policies
This section contains the following procedures: • Configuring Environmental Variables, page 104 • Registering Fault Manager Policies, page 106
Configuring Environmental Variables
Fault Manager environmental variables are Tcl global variables that are defined external to the policy before the policy is run. The Fault Manager policy engine receives notifications when faults and other events occur. Fault Manager policies implement recovery based on the current state of the system and actions specified in the policy for a given event. Recovery actions are triggered when the policy is run..
Environment Variables
By convention, the names of all environment variables defined by Cisco begin with an underscore character to set them apart; for example, _show_cmd. Spaces may be used in the var-value argument of the fault manager environment command. The command interprets everything after the var-name argument to the end of the line to be part of the var-value argument. Use the show fault manager environment command to display the name and value of all Fault Manager environment variables after they have been set using the fault manager environment command.
SUMMARY STEPS
1. show fault manager environment 2. configure 3. fault manager environment var-name var-value 4. Repeat Step 3 for every environment value to be reset. 5. end or commit 6. show fault manager environment
Cisco IOS XR System Management Configuration Guide SMR-104 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show fault manager environment Displays the names and values of all Fault Manager environment variables. Example: RP/0/RP0/CPU0:router# show fault manager environment Step 2 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 3 fault manager environment var-name var-value Resets environment variables to new values. • The var-name argument is the name assigned to the Example: Fault Manager environment configuration variable. RP/0/RP0/CPU0:router(config)# fault manager environment _cron_entry 0-59/2 0-23/1**0-7 • The var-value argument is the series of characters, including embedded spaces, to be placed in the environment variable var-name. • By convention, the names of all environment variables defined by Cisco begin with an underscore character to set them apart; for example, _show_cmd. • Spaces may be used in the var-value argument. The command interprets everything after the var-name argument to the end of the line to be part of the var-value argument. Step 4 Repeat Step 3 for every environment value to be reset. —
Cisco IOS XR System Management Configuration Guide SMR-105 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Command or Action (continued) Purpose (continued) Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 6 show fault manager environment Displays the reset names and values of all Fault Manager environment variables; allows you to verify the environment variable names and values set in Step 3. Example: RP/0/RP0/CPU0:router# show fault manager environment
What to Do Next
After setting up Fault Manager environment variables, find out what policies are available to be registered and then register those policies, as described in the “Registering Fault Manager Policies” section.
Registering Fault Manager Policies
Register a Fault Manager policy in order to run a policy when an event is triggered.
Fault Manager Policies
Registering a Fault Manager policy is performed with the fault manager policy command in global configuration mode. A Fault Manager script is available to be scheduled by the Fault Manager until the no form of this command is entered. Prior to registering a policy, display Fault Manager policies that are available to be registered with the show fault manager policy available command. The Fault Manager schedules and runs policies on the basis of an event specification that is contained within the policy itself. When the fault manager policy command is invoked, the Fault Manager examines the policy and registers it to be run when the specified event occurs.
Cisco IOS XR System Management Configuration Guide SMR-106 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Username To register a Fault Manager policy , you must specify the username that is used to run the script. This name can be different from the user who is currently logged in, but the registering user must have permissions that are a superset of the username that will run the script. Otherwise, the script is not registered and the command be rejected. In addition, the username that will run the script must have access privileges to the commands run by the Fault Manager policy being registered.
Persist-time An optional persist-time for the username can also be defined. The persist-time defines the number of seconds the username authentication is valid. When a script is first registered, the configured username for the script is authenticated. After the script is registered, the username is authenticated again each time a script is run. If the AAA server is down, the username authentication can be read from memory. The persist-time determines the number of seconds this username authentication is held in memory. • If the AAA server is down and the persist-time has not expired, then the username is authenticated from memory and the script runs. • If the AAA server is down, and the persist-time has expired, then user authentication will fail and the script will not run. The following values can be used for persist-time. • The default persist-time is 3600 seconds (1 hour). Enter the fault manager policy command without the persist-time keyword to set the persist-time to 1 hour. • Enter 0 to stop the username authentication from being cached. If the AAA server is down, the username will not authenticate and the script will not run. • Enter infinite to stop the username from being marked as invalid. The username authentication held in the cache will not expire. If the AAA server is down, the username will be authenticated from the cache.
System or user keywords If you enter the fault manager policy command without specifying either the system or user keyword, the Fault Manager first tries to locate the specified policy file in the system policy directory. If the Fault Manager finds the file in the system policy directory, it registers the policy as a system policy. If the Fault Manager does not find the specified policy file in the system policy directory, it looks in the user policy directory. If the Fault Manager locates the specified file in the user policy directory, it registers the policy file as a user policy. If the Fault Manager finds policy files with the same name in both the system policy directory and the user policy directory, the policy file in the system policy directory takes precedence and is registered as a system policy. Once policies have been registered, their registration can be verified through the show fault manager policy registered command. The output displays registered policy information in two parts. The first line in each policy description lists the index number assigned to the policy, the policy type (system or user), the type of event registered, the time when the policy was registered, and the name of the policy file. The remaining lines of each policy description display information about the registered event and how the event is to be handled, and come directly from the Tcl command arguments that make up the policy file.
SUMMARY STEPS
1. show fault manager policy available [system | user] 2. configure
Cisco IOS XR System Management Configuration Guide SMR-107 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
3. fault manager policy {username username} [persist-time {seconds | infinite}] policy-name [system | user] 4. Repeat Step 3 for every Fault Manager policy to be registered. 5. end or commit 6. show fault manager policy registered
DETAILED STEPS
Command or Action Purpose Step 1 show fault manager policy available [system | Displays all Fault Manager policies that are available to be user] registered. • Entering the optional system keyword displays all Example: available system policies. RP/0/RP0/CPU0:router# show fault manager policy available • Entering the optional user keyword displays all available user policies. Step 2 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 3 fault manager policy policy-name {username Registers a Fault Manager policy with the Fault Manager. username} [persist-time {seconds | infinite}] [system | user] • A Fault Manager script is available to be scheduled by the Fault Manager until the no form of this command is entered. Example: RP/0/RP0/CPU0:router(config)# fault manager • Enter the required username keyword and argument, policy username tom cron.tcl user where username is the username that will run the script. • Enter the optional persist-time keyword to dtermine how long the username authentication will be held in memory: – enter the number of seconds for the persist-time. – enter infinite to make the authentication permanent (the authentication will not expire). • Entering the optional system keyword registers a Cisco-defined system policy. • Entering the optional user keyword registers a user-defined policy. Step 4 Repeat Step 3 for every Fault Manager policy to be — registered.
Cisco IOS XR System Management Configuration Guide SMR-108 Configuring and Managing Fault Management Policies on Cisco IOS XR Software How to Configure and Manage Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information
Command or Action (continued) Purpose (continued) Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 6 show fault manager policy registered Displays all Fault Manager policies that are already registered, allowing verification of Step 3. Example: RP/0/RP0/CPU0:router# show fault manager policy registered
Cisco IOS XR System Management Configuration Guide SMR-109 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Configuration Examples for Fault Management Policies R3.3 Beta Draft—Cisco Confidential Information Configuration Examples for Fault Management Policies
This section contains the following configuration examples: • Environmental Variables Configuration: Example, page 110 • User-Defined Fault Management Policy Registration: Example, page 110 • Display Available Policies: Example, page 110 • Display Fault Manager Process: Example, page 110
Environmental Variables Configuration: Example
The following configuration sets the environment variable cron_entry: RP/0/RP0/CPU0:router# configure RP/0/RP0/CPU0:router#(config)# fault manager environment _cron_entry 0-59/2 0-23/1 * * 0-7
User-Defined Fault Management Policy Registration: Example
The following configuration registers a user-defined fault management policy: RP/0/RP0/CPU0:router# configure RP/0/RP0/CPU0:router(config)# fault manager policy username tom cron.tcl user
Display Available Policies: Example
The following is sample output from the show fault manager policy available displaying available policies: RP/0/RP0/CPU0:router# show fault manager policy available
No. Type Time Created Name 1 system Mon Mar 15 21:32:14 2004 periodic_diag_cmds.tcl 2 system Mon Mar 15 21:32:14 2004 periodic_proc_avail.tcl 3 system Mon Mar 15 21:32:16 2004 periodic_sh_log.tcl 4 system Mon Mar 15 21:32:16 2004 tm_cli_cmd.tcl 5 system Mon Mar 15 21:32:16 2004 tm_crash_hist.tcl
Display Fault Manager Process: Example
Reliability metric data is kept for each process handled by the System Manager. This data includes standby processes running on either the primary or backup hardware card. Data is recorded in a table indexed by hardware card disk ID plus process pathname plus process instance for those processes that have multiple instances. The following is sample output from the show fault manager metric process command displaying reliability metric data: RP/0/RP0/CPU0:router# show fault manager metric process
job id: 258, node name: 0/RP0/CPU0 process name: msdp, instance: 1 comp id: 0, version: 00.00.0000 ------last event type: process start
Cisco IOS XR System Management Configuration Guide SMR-110 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
recent end type: abnormal exit (exit status 1) recent start time: Mon Feb 2 10:31:24 2004 recent normal end time: n/a recent abnormal end time: Mon Feb 2 10:31:24 2004 recent abnormal end type: terminated by signal (SIGIOT) number of times started: 12 number of times ended normally: 0 number of times ended abnormally: 11 most recent 10 process start times: ------Mon Jan 26 11:56:20 2004 Wed Jan 28 11:24:36 2004 Wed Jan 28 13:43:02 2004 Sat Jan 31 09:12:56 2004 Sat Jan 31 09:18:51 2004 Sat Jan 31 09:26:15 2004 Sat Jan 31 09:33:33 2004 Sat Jan 31 11:08:59 2004 Sat Jan 31 12:44:35 2004 Mon Feb 2 10:31:24 2004 ------
most recent 10 process end times and types: ------Mon Jan 26 11:56:20 2004, terminated by signal (SIGIOT) Wed Jan 28 11:24:36 2004, terminated by signal (SIGIOT) Wed Jan 28 13:43:02 2004, terminated by signal (SIGIOT) Sat Jan 31 09:12:55 2004, abnormal exit (exit status 1) Sat Jan 31 09:18:50 2004, abnormal exit (exit status 1) Sat Jan 31 09:26:15 2004, abnormal exit (exit status 1) Sat Jan 31 09:33:32 2004, abnormal exit (exit status 1) Sat Jan 31 11:08:59 2004, abnormal exit (exit status 1) Sat Jan 31 12:44:34 2004, abnormal exit (exit status 1) Mon Feb 2 10:31:24 2004, abnormal exit (exit status 1) ------
cumulative process available time: 340 hours 15 minutes 19 seconds 443 milliseconds cumulative process unavailable time: 0 hours 0 minutes 4 seconds 853 milliseconds process availability: 0.999996038 number of abnormal ends within the past 60 minutes (since reload): 0 number of abnormal ends within the past 24 hours (since reload): 1 number of abnormal ends within the past 30 days (since reload): 11
Additional References
The following sections provide references related to configuring and managing fault management policies.
Related Documents
Related Topic Document Title Cisco IOS XR Fault Manager commands Fault Manager Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR Route Processor failover commands Hardware Redundancy and Node Administration Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2
Cisco IOS XR System Management Configuration Guide SMR-111 Configuring and Managing Fault Management Policies on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
Related Topic Document Title Cisco IOS XRXML API material Cisco IOS XR XML API Guide, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2
Standards
Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature.
MIBs
MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
RFCs
RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature.
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMR-112 R3.3 Beta Draft—Cisco Confidential Information
Implementing Logging Services on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
The Cisco IOS XR software provides basic logging services. Logging services provide a means to gather logging information for monitoring and troubleshooting, to select the type of logging information captured, and to specify the destinations of captured system logging (syslog) messages. This module describes the new and revised tasks you need to implement logging services on your Cisco IOS XR network.
Note For more information about logging services on the Cisco IOS XR software and complete descriptions of the logging commands listed in this module, see the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing Logging Services on Cisco IOS XR Software Contents Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification. Release 3.2 Support was added for the Cisco XR 12000 Series Router. Release 3.3 No modification.
Contents
• Prerequisites for Implementing Logging Services on Cisco IOS XR Software, page 114 • Information About Implementing Logging Services on Cisco IOS XR Software, page 114 • How to Implement Logging Services on Cisco IOS XR Software, page 120 • Configuration Examples for Implementing Logging Services on Cisco IOS XR Software, page 138 • Where to Go Next, page 140 • Additional References, page 140
Cisco IOS XR System Management Configuration Guide SMR-113 Implementing Logging Services on Cisco IOS XR Software Prerequisites for Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Implementing Logging Services on Cisco IOS XR Software
The following prerequisites are required to implement logging services in your network operating center (NOC): • You must be in a user group associated with a task group that includes the proper task IDs for logging commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide. • You must have connectivity with syslog servers to configure syslog server hosts as the recipients for syslog messages.
Information About Implementing Logging Services on Cisco IOS XR Software
To implement logging services, you need to understand the following concepts: • System Logging Process, page 114 • Format of System Logging Messages, page 114 • Syslog Message Destinations, page 115 • Syslog Messages Sent to Syslog Servers, page 116 • UNIX Syslog Daemon Configuration, page 118 • Severity Levels, page 118
System Logging Process
By default, routers are configured to send syslog messages to a syslog process. The syslog process controls the distribution of messages to the destination of syslog messages such as the logging buffer, terminal lines, or a syslog server. The syslog process also sends messages to the console terminal by default.
Note For more information about how the syslog process functions within the Alarms and Debugging Event Management System (ALDEMS) infrastructure on Cisco IOS XR software, see the Implementing and Monitoring Alarm Logs and Logging Correlation on Cisco IOS XR software module.
Format of System Logging Messages
By default, the general format of syslog messages generated by the syslog process on the Cisco IOS XR software is as follows: node-id:timestamp : process-name [pid] : %message-group-severity-message-code : message-text
Cisco IOS XR System Management Configuration Guide SMR-114 Implementing Logging Services on Cisco IOS XR Software Information About Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
The following is a sample syslog message: RP/0/0/CPU0:Nov 28 23:56:53.826 : config[65710]: %SYS-5-CONFIG_I : Configured from console by console
Table 13 describes the general format of syslog messages on Cisco IOS XR software.
Table 13 General Syslog Message Format
Field Description node-id Node from which the syslog message originated. timestamp Time stamp in the form month day HH:MM:SS, indicating when the message was generated. Note The time-stamp format can be modified using the service timestamps command. See the “Modifying the Format of Time Stamps” section. process-name Process that generated the syslog message. [pid] Process ID (pid) of the process that generated the syslog message. %message-group-severity-message-code Message group name, severity, and message code associated with the syslog message. message-text Text string describing the syslog message.
Syslog Message Destinations
Syslog message logging to the console terminal is enabled by default. To disable logging to the console terminal, use the no logging console command in global configuration mode. To reenable logging to the console terminal, use the logging console command in global configuration mode. Syslog messages can be sent to destinations other than the console, such as the logging buffer, syslog servers, and terminal lines other than the console (such as vtys). Table 14 lists the commands used to specify syslog destinations.
Table 14 Commands Used to Set Syslog Destinations
Command Description logging buffered Specifies the logging buffer as a destination for syslog messages. logging {hostname | ip-address} Specifies a syslog server host as a destination for syslog messages. logging monitor Specifies terminal lines other than the console as destinations for syslog messages.
The logging buffered command copies logging messages to the logging buffer. The buffer is circular, so newer messages overwrite older messages after the buffer is full. To display the syslog messages that are logged in the logging buffer, use the show logging command. The first message displayed is the oldest message in the buffer. To clear the current contents of the logging buffer, use the clear logging command. To disable logging to the logging buffer, use the no logging buffered command in global configuration mode.
Cisco IOS XR System Management Configuration Guide SMR-115 Implementing Logging Services on Cisco IOS XR Software Information About Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
The logging command identifies a syslog server host to receive logging messages. By issuing this command more than once, you build a list of syslog servers that receive logging messages. To delete the syslog server with the specified IP address or hostname from the list of available syslog servers, use the no logging command in global configuration mode. The logging monitor command globally enables the logging of syslog messages to terminal lines other than the console, such as vtys. To disable logging to terminal lines other than the console, use the no logging monitor command in global configuration mode.
Guidelines for Sending Syslog Messages to Destinations Other Than the Console
The logging process must be enabled to send syslog messages to destinations other than the console terminal. To enable logging to destinations other than the console terminal, use the logging on command in global configuration mode. The logging on command enables logging to the logging buffer, terminal lines and syslog servers. To disable message logging to destinations other than the console terminal, use the no logging on command in global configuration mode. When the logging process is disabled, messages are sent only to the console terminal. The messages are sent as they are generated, so error and debug output will be interspersed with prompts or output from the command. To reenable message logging after it has been disabled, use the logging on command.
Logging for the Current Terminal Session
The logging monitor command and logging on commands globally enable the logging of syslog messages to terminal lines other than console terminal. Once the logging monitor and logging on commands have been enabled, use the terminal monitor command to display syslog messages during a terminal session. To disable the logging of syslog messages to a terminal during a terminal session, use the terminal monitor disable command in EXEC mode.The terminal monitor disable command disables logging for only the current terminal session. To reenable the logging of syslog messages for the current terminal session, use the terminal monitor command in EXEC mode.
Note The terminal monitor and terminal monitor disable commands are set locally and will not remain in effect after the terminal session is ended.
Syslog Messages Sent to Syslog Servers
The Cisco IOS XR software provides the following features to help manage syslog messages sent to syslog servers: • UNIX system facilities • Hostname prefix logging • Source interface logging
Cisco IOS XR System Management Configuration Guide SMR-116 Implementing Logging Services on Cisco IOS XR Software Information About Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
UNIX System Logging Facilities
You can configure the syslog facility in which syslog messages are sent by using the logging facility command. Consult the operator manual for your UNIX operating system for more information about these UNIX system facilities. The syslog format is compatible with Berkeley Standard Distribution (BSD) UNIX version 4.3. Table 15 describes the facility type keywords that can be supplied for the type argument.
Table 15 Logging Facility Type Keywords
Facility Type Keyword Description auth Indicates the authorization system. cron Indicates the cron facility. daemon Indicates the system daemon. kern Indicates the Kernel. local0–7 Reserved for locally defined messages. lpr Indicates line printer system. mail Indicates mail system. news Indicates USENET news. sys9 Indicates system use. sys10 Indicates system use. sys11 Indicates system use. sys12 Indicates system use. sys13 Indicates system use. sys14 Indicates system use. syslog Indicates the system log. user Indicates user process. uucp Indicates UNIX-to-UNIX copy system.
Hostname Prefix Logging
To help manage system logging messages sent to syslog servers, Cisco IOS XR software supports hostname prefix logging. When enabled, hostname prefix logging appends a hostname prefix to syslog messages being sent from the router to syslog servers. You can use hostname prefixes to sort the messages being sent to a given syslog server from different networking devices. To append a hostname prefix to syslog messages sent to syslog servers, use the logging hostname command in global configuration mode.
Syslog Source Address Logging
By default, a syslog message contains the IP address of the interface it uses to leave the router when sent to syslog servers. To set all syslog messages to contain the same IP address, regardless of which interface the syslog message uses to exit the router, use the logging source-interface command in global configuration mode.
Cisco IOS XR System Management Configuration Guide SMR-117 Implementing Logging Services on Cisco IOS XR Software Information About Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information UNIX Syslog Daemon Configuration
To configure the syslog daemon on a 4.3 BSD UNIX system, include a line such as the following in the /etc/syslog.conf file: local7.debug /usr/adm/logs/cisco.log
The debugging keyword specifies the syslog level; see Table 18 for a general description of other keywords. The local7 keyword specifies the logging facility to be used; see Table 15 for a general description of other keywords. The syslog daemon sends messages at this level or at a more severe level to the file specified in the next field. The file must already exist, and the syslog daemon must have permission to write to it.
Severity Levels
You can limit the number of messages sent to a logging destination by specifying the severity level of syslog messages sent to a destination (see Table 18 for severity level definitions). Table 16 lists the commands used to control the severity level of syslog messages.
Table 16 Commands Used to Control the Severity Level of Syslog Messages
Command Description logging buffered [severity] Limits the syslog messages sent to the logging buffer based on severity. logging console [severity] Limits the syslog messages sent to the console terminal based on severity. logging monitor [severity] Limits the syslog messages sent to terminal lines based on severity. logging trap [severity] Limits the syslog messages sent to syslog servers based on severity.
The logging buffered, logging console, logging monitor, and logging traps commands limit syslog messages sent to their respective destinations to messages with a level number at or below the specified severity level, which is specified with the severity argument.
Note Syslog messages of lower severity level indicate events of higher importance. See Table 18 for severity level definitions.
Logging History Table
If you have enabled syslog messages traps to be sent to a Simple Network Management Protocol (SNMP) network management station (NMS) with the snmp-server enable traps syslog command, you can change the level of messages sent and stored in a history table on the router. You can also change the number of messages that get stored in the history table. Messages are stored in the history table, because SNMP traps are not guaranteed to reach their destination. By default, one message of the level warning and above (see Table 18) is stored in the history table even if syslog traps are not enabled.
Cisco IOS XR System Management Configuration Guide SMR-118 Implementing Logging Services on Cisco IOS XR Software Information About Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Table 17 lists the commands used to change the severity level and table size defaults of the logging history table.
Table 17 Logging History Table Commands
Command Description logging history severity Changes the default severity level of syslog messages stored in the history file and sent to the SNMP server. logging history size number Changes the number of syslog messages that can be stored in the history table.
Note Table 18 lists the level keywords and severity level. For SNMP usage, the severity level values use +1. For example, emergency equals 1 not 0 and critical equals 3 not 2.
Syslog Message Severity Level Definitions
Table 18 lists the severity level keywords that can be supplied for the severity argument and corresponding UNIX syslog definitions in order from the most severe level to the least severe level.
Table 18 Syslog Message Severity Levels
Severity Keyword Level Description Syslog Definition emergencies 0 System unusable LOG_EMERG alerts 1 Immediate action needed LOG_ALERT critical 2 Critical conditions LOG_CRIT errors 3 Error conditions LOG_ERR warnings 4 Warning conditions LOG_WARNING notifications 5 Normal but significant condition LOG_NOTICE informational 6 Informational messages only LOG_INFO debugging 7 Debugging messages LOG_DEBUG
Cisco IOS XR System Management Configuration Guide SMR-119 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Syslog Severity Level Command Defaults
Table 19 lists the default severity level settings for the commands that support the severity argument.
Table 19 Severity Level Command Defaults
Command Default Severity Keyword Level logging buffered debugging 7 logging console informational 6 logging history warnings 4 logging monitor debugging 7 logging trap informational 6
How to Implement Logging Services on Cisco IOS XR Software
This section contains the following procedures: • Configuring Logging to the Console Terminal and the Logging Buffer, page 120 (required) • Setting Up Destinations for System Logging Messages, page 122 (required) • Configuring Logging to a Remote Server, page 124 (required) • Configuring the Settings for the Logging History Table, page 126 (required) • Modifying the Format of Time Stamps, page 129 (optional) • Disabling Time Stamps, page 131 (optional) • Suppressing Duplicate Syslog Messages, page 132 (optional) • Disabling the Logging of Link-Status Syslog Messages, page 133 (optional) • Displaying System Logging Messages, page 134 (optional)
Configuring Logging to the Console Terminal and the Logging Buffer
This task explains how to configure logging to the console terminal and the logging buffer.
SUMMARY STEPS
1. configure 2. logging buffered [size | severity] 3. logging on 4. logging console [severity] 5. end or commit
Cisco IOS XR System Management Configuration Guide SMR-120 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 logging buffered [size | severity] Specifies the logging buffer as a destination for syslog messages, sets the size of the logging buffer, and limits the the syslog messages sent to the logging buffer based on Example: RP/0/RP0/CPU0:router(config)# logging buffered severity. size 60000 • The default for the size argument is 4096 bytes. • The default for the severity argument is debugging. • Keyword options for the severity argument are emergencies, alerts, critical, errors, warnings, notifications, informational, and debugging. • By default, entering this command without specifying a severity level for the severity argument or specifying the size of the buffer for the size argument sets the severity level to debugging and the buffer size to 4096 bytes. Step 3 logging on Enables logging to destinations other than the console terminal. Example: • This command enables logging to the logging buffer, RP/0/RP0/CPU0:router(config)# logging on terminal lines, and syslog servers.
Cisco IOS XR System Management Configuration Guide SMR-121 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 logging console [severity] Limits messages sent to the console terminal based on severity. Example: • Syslog messages are logged to the console terminal at RP/0/RP0/CPU0:router(config)# logging console the informational severity level by default. alerts • Keyword options for the severity argument are emergencies, alerts, critical, errors, warnings, notifications, informational, and debugging. • Entering this command without specifying a severity level for the severity argument sets the severity level to informational. Note Use this command to reenable logging to the console terminal if it was disabled with the no logging console command. Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Setting Up Destinations for System Logging Messages
This task explains how to configure logging to destinations other than the console terminal. For conceptual information, see the “Syslog Message Destinations”.
SUMMARY STEPS
1. configure 2. logging buffered [size | severity] 3. logging monitor [severity] 4. logging on
Cisco IOS XR System Management Configuration Guide SMR-122 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
5. end or commit 6. terminal monitor
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 logging buffered [size | severity] Specifies the logging buffer as a destination for syslog messages, sets the size of the logging buffer, and limits syslog messages sent to the logging buffer based on Example: RP/0/RP0/CPU0:router(config)# logging buffered severity. severity warnings • The default for the size argument is 4096 bytes. • The default for the severity argument is debugging. • Keyword options for the severity argument are emergencies, alerts, critical, errors, warnings, notifications, informational, and debugging. • By default, entering this command without specifying a severity level for the severity argument or specifying the size of the buffer for the size argument sets the severity level to debugging and the buffer size to 4096 bytes. Step 3 logging monitor [severity] Specifies terminal lines other than console terminal as destinations for syslog messages and limits the number of messages sent to terminal lines based on severity. Example: RP/0/RP0/CPU0:router(config)# logging monitor • Keyword options for the severity argument are critical emergencies, alerts, critical, errors, warnings, notifications, informational, and debugging. • By default, entering this command without specifying a severity level for the severity argument sets the severity level to debugging. Step 4 logging on Enables logging to destinations other than the console terminal. Example: • This command enables logging to the logging buffer, RP/0/RP0/CPU0:router(config)# logging on terminal lines, and syslog servers.
Cisco IOS XR System Management Configuration Guide SMR-123 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 6 terminal monitor Enables the display of syslog messages for the current terminal session. Example: • Syslog messages are not sent to terminal lines unless RP/0/RP0/CPU0:router# terminal monitor the logging monitor and logging on commands have been enabled. Note The logging of syslog message for the current terminal can be disabled with the terminal monitor disable command.
• Use this command to reenable the display of syslog messages for the current session if the logging of messages for the current session was disabled with terminal monitor disable command. Note Because this command is an EXEC mode command, it is set locally and will not remain in effect after the current session is ended.
Configuring Logging to a Remote Server
This task explains how to configure logging to remote syslog servers.
Prerequisites
You must have connectivity with syslog servers to configure syslog server hosts as the recipients for syslog messages.
Cisco IOS XR System Management Configuration Guide SMR-124 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
SUMMARY STEPS
1. configure 2. logging [ip-address | hostname} 3. logging trap [severity] 4. logging on 5. logging facility type 6. logging hostnameprefix hostname 7. logging source-interface type instance 8. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# Step 2 logging {ip-address | hostname} Specifies a syslog server host as a destination for syslog messages. Example: • By issuing this command more than once, you build a RP/0/RP0/CPU0:router(config)# logging list of syslog servers that receive logging messages. 10.3.32.154 Step 3 logging trap [severity] Limits the syslog messages sent to syslog servers based on severity. Example: • By default, entering this command without specifying a RP/0/RP0/CPU0:router(config)# severity level for the severity argument sets the severity level to informational. Step 4 logging on Enables logging to destinations other than the console terminal. Example: • This command enables logging to the logging buffer, RP/0/RP0/CPU0:router(config)# logging on terminal lines and syslog servers. Step 5 logging facility [type] (Optional) Configures syslog facilities. • By default, entering this command without specifying a Example: facility type for the type argument sets the facility to RP/0/RP0/CPU0:router(config)# logging facility local-7. kern Step 6 logging hostnameprefix hostname (Optional) Appends a hostname prefix to syslog messages being sent from the router to syslog servers. Example: Tip Hostname prefix logging can be useful for sorting RP/0/RP0/CPU0:router(config)# syslog messages received by syslog servers.
Cisco IOS XR System Management Configuration Guide SMR-125 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 7 logging source-interface type instance (Optional) Sets the syslog source address. • By default, a syslog message sent to a syslog server Example: contains the IP address of the interface it uses to leave RP/0/RP0/CPU0:router(config)# the router. • Use this command to set all syslog messages being sent from the router to contain the same IP address, regardless of which interface the syslog message uses to exit the router. Step 8 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Configuring the Settings for the Logging History Table
This task explains how to configure the settings for the logging history table. For conceptual information, see the “Severity Levels” section.
Prerequisites
Logging of messages to an SNMP NMS is enabled by the snmp-server enable traps syslog command. For more information about SNMP, see the “Related Documents” section of this module.
SUMMARY STEPS
1. configure 2. logging history severity 3. logging history size number
Cisco IOS XR System Management Configuration Guide SMR-126 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
4. end or commit 5. show logging history
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 logging history severity Changes the default severity level of syslog messages stored in the history file and sent to the SNMP server. Example: • By default, syslog messages at or below the warnings RP/0/RP0/CPU0:router(config)# logging history severity level are stored in the history file and sent to the SNMP server. Step 3 logging history size number Changes the number of syslog messages that can be stored in the history table. Example: • By default, one syslog message is stored in the history RP/0/RP0/CPU0:router(config)# logging history table. size Note When the history table is full (that is, when it contains the maximum number of messages specified with this command), the oldest message is deleted from the table to allow the new message to be stored.
Cisco IOS XR System Management Configuration Guide SMR-127 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 5 show logging history (Optional) Displays information about the state of the syslog history table. Example: RP/0/RP0/CPU0:router# show logging history
Cisco IOS XR System Management Configuration Guide SMR-128 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Modifying the Format of Time Stamps
This task explains how to modify the time-stamp format for syslog and debugging messages.
SUMMARY STEPS
1. configure 2. service timestamps log datetime [localtime] [msec] [show-timezone] or service timestamps log uptime 3. service timestamps debug datetime [localtime] [msec] [show-timezone] or service timestamps debug uptime 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 service timestamps log datetime [localtime] [msec] Modifies the time-stamp format for syslog messages. [show-timezone] or • By default, time stamps are enabled. The default time-stamp format is month day HH:MM:SS. service timestamps log uptime • Issuing the service timestamps log datetime command configures syslog messages to be Example: time-stamped with the date and time. RP/0/RP0/CPU0:router(config)# service timestamps log datetime localtime msec – The optional localtime keyword includes the local or time zone in time stamps. RP/0/RP0/CPU0:router(config)# service – The optional msec keyword includes milliseconds timestamps log uptime in time stamps. – The optional show-timezone keyword includes time zone information in time stamps. • Issuing the service timestamps log uptime command configures syslog messages to be time-stamped with the time that has elapsed since the router last rebooted. – The service timestamps log uptime command configures time-stamps to be configured in HHHH:MM:SS, indicating the time since the router last rebooted.
Cisco IOS XR System Management Configuration Guide SMR-129 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 service timestamps debug datetime [localtime] Modifies the time-stamp format for debugging messages. [msec] [show-timezone] or • By default, time-stamps are enabled. The default time stamp format is month day HH:MM:SS. service timestamps debug uptime • Issuing the service timestamps log datetime command configures debugging messages to be Example: time-stamped with the date and time. RP/0/RP0/CPU0:router(config)# service timestamps debug datetime msec show-timezone – The optional localtime keyword includes the local or time zone in time stamps. RP/0/RP0/CPU0:router(config)# service – The optional msec keyword includes milliseconds timestamps debug uptime in time stamps. – The optional show-timezone keyword includes time zone information in time stamps. • Issuing the service timestamps log uptime command configures debugging messages to be time-stamped with the time that has elapsed since the networking device last rebooted. Tip Entering the service timestamps command without any keywords or arguments is equivalent to entering the service timestamps debug uptime command. Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-130 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Disabling Time Stamps
This tasks explains how to disable the inclusion of time stamps in syslog messages.
SUMMARY STEPS
1. configure 2. service timestamps disable or no service timestamps [debug | log] [datetime [localtime] [msec] [show-timezone]] | uptime] 3. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 service timestamps disable Disables the inclusion of time stamps in syslog messages. or Note Both commands disable the inclusion of time no service timestamps [debug | log] [datetime stamps in syslog messages; however, specifying the [localtime] [msec] [show-timezone]] | uptime] service timestamps disable command saves the command to the configuration, whereas specifying the no form of the service timestamps command removes the command from the configuration. Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-131 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Suppressing Duplicate Syslog Messages
This task explains how to suppress the consecutive logging of duplicate syslog messages.
SUMMARY STEPS
1. configure 2. logging suppress duplicates 3. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 logging suppress duplicates Prevents the consecutive logging of duplicate syslog messages. Example: RP/0/RP0/CPU0:router(config)# logging suppress duplicates Caution If this command is enabled during debugging sessions, you could miss important information related to problems that you are attempting to isolate and resolve. In such a case, you might consider disabling this command.
Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-132 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Disabling the Logging of Link-Status Syslog Messages
This task explains how to disable the logging of link-status syslog messages for logical and physical links. When the logging of link-status messages is enabled, the router can generate a high volume of link-status updown syslog messages. Disabling the logging of link-status syslog messages reduces the number of messages logged.
SUMMARY STEPS
1. configure 2. no logging events link-status [logical | physical] 3. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router## configure
Cisco IOS XR System Management Configuration Guide SMR-133 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 2 no logging events link-status [logical | Disables the logging of link-status syslog messages for physical] logical and physical links. • The logging of link-status syslog messages for both Example: logical and physical links is enabled by default. RP/0/RP0/CPU0:router(config)# no logging events link-status • Entering this command without specifying either the logical or physical optional keywords disables the logging of link-status messages for both logical and physical links. Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Displaying System Logging Messages
This task explains how to display the syslog messages stored in the logging buffer.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show logging 2. show logging location node-id 3. show logging process name 4. show logging string string 5. show logging lower-limit-timestamp month day hh:mm:ss 6. show logging upper-limit-timestamp month day hh:mm:ss 7. show logging lower-limit-timestamp month day hh:mm:ss upper-limit-timestamp month day hh:mm:ss
Cisco IOS XR System Management Configuration Guide SMR-134 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 show logging Displays all syslog messages stored in the buffer.
Example: RP/0/RP0/CPU0:router# show logging Step 2 show logging location node-id Displays syslog messages that have originated from the designated node. Example: RP/0/RP0/CPU0:router# show logging location 0/1/CPU0 Step 3 show logging process name Displays syslog messages that are related to the specified process. Example: RP/0/RP0/CPU0:router# show logging process init Step 4 show logging string string Displays syslog messages that contain the specified string.
Example: RP/0/RP0/CPU0:router# show logging string install Step 5 show logging lower-limit-timestamp month day Displays syslog messages in the logging buffer that were hh:mm:ss generated on or after the specified date and time.
Example: RP/0/RP0/CPU0:router# show logging lower-limit-timestamp december 1 10:30:00 Step 6 show logging upper-limit-timestamp month day Displays syslog messages in the logging buffer that were hh:mm:ss generated on or before the specified date and time.
Example: RP/0/RP0/CPU0:router# show logging upper-limit-timestamp december 2 22:16:00 Step 7 show logging upper-limit-timestamp month day Displays syslog messages in the logging buffer that were hh:mm:ss lower-limit-timestamp month day generated on or between the specified dates and times. hh:mm:ss
Example: RP/0/RP0/CPU0:router# show logging upper-limit-timestamp december 2 22:00:00 lower-limit-timestamp december 2 10:00:00
Examples
In this example, the output displays all syslog messages stored in the logging buffer: RP/0/0/CPU0:router# show logging
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns)
Cisco IOS XR System Management Configuration Guide SMR-135 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points. RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88% RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1 . . .
In this example, the output displays s syslog messages stored in the logging buffer that originated from node 0/0/CPU0: RP/0/0/CPU0:router# show logging location 0/0/CPU0
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points. RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88% RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1 RP/0/0/CPU0:Dec 3 10:30:35.068 : locald[210]: %LOCALD-3-ROOT_USERDB_INIT_FAIL : Failed to create aaa directory: File exists RP/0/0/CPU0:Dec 3 10:30:41.023 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure not ready to consume configuration. RP/0/0/CPU0:Dec 3 10:31:10.504 : sip[252]: sxa_iox_chkpt_init 154 SIP-LOG: SIP started - performing a cold start. . . .
In this example, the output displays syslog messages stored in the logging buffer that were related to the wdsysmon process: RP/0/0/CPU0:router# show logging process wdsysmon
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
Cisco IOS XR System Management Configuration Guide SMR-136 Implementing Logging Services on Cisco IOS XR Software How to Implement Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points. RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88% LC/0/2/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MB LC/0/7/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MB LC/0/6/CPU0:wdsysmon[186]: %HA_WD-6-MEMORY_RECOVERY_DISABLED : Node physical memory 256MB . . .
In this example, the output displays syslog messages stored in the logging buffer that contained the string MgmtEth: RP/0/0/CPU0:router# show logging string MgmtEth
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 10:32:15.608 : ifmgr[171]: %LINK-3-UPDOWN : Interface MgmtEth0/0/CPU0/0, changed state to Down RP/0/0/CPU0:Dec 3 10:32:15.642 : ifmgr[171]: %LINK-3-UPDOWN : Interface MgmtEth0/0/CPU0/0, changed state to Up . . . In this example, the output displays syslog messages stored in the logging buffer that were logged on or after 11:00 on December 3: RP/0/0/CPU0:router# show logging lower-limit-timestamp december 3 11:00:00
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 11:48:44.513 : sysmgr[76]: sip(1) (jid 252) abnormally terminated, restart scheduled RP/0/0/CPU0:Dec 3 11:48:48.431 : sip[252]: sxa_iox_chkpt_init 130 SIP-LOG: SIP restart - warm start - 2 sessions so far. LC/0/5/CPU0:Dec 3 13:28:19.070 : DI_Partner[50]: %SONET-4-ALARM : SONET0_5_0_0: SLOS LC/0/5/CPU0:Dec 3 13:34:12.281 : DI_Partner[50]: %SONET-4-ALARM : SONET0_5_0_0: SLOS cleared . . .
In this example, the output displays syslog messages stored in the logging buffer that were logged on or before 10:29:00 on December 3: RP/0/0/CPU0:router# show logging upper-limit-timestamp december 3 10:29:00
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged
Cisco IOS XR System Management Configuration Guide SMR-137 Implementing Logging Services on Cisco IOS XR Software Configuration Examples for Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 10:28:24.245 : wdsysmon[296]: %HA_WD-4-DISK_ALARM : A monitored disk is above 80% utilization. Please remove unwanted user files and configuration rollback points. RP/0/0/CPU0:Dec 3 10:28:24.247 : wdsysmon[296]: %HA_WD-6-DISK_USAGE : /disk0: usage 88% RP/0/0/CPU0:Dec 3 10:28:31.247 : lrd[215]: LRd waited 40 seconds for inventory... rc = 1082230272 nCount = -1 . . .
In this example, the output displays syslog messages stored in the logging buffer that were logged on or between 10:30 and 11:00 on December 3: RP/0/0/CPU0:router# show logging lower-limit-timestamp december 3 10:30:00 upper-limit-timestamp december 3 11:00:00
Syslog logging: enabled (20 messages dropped, 0 flushes, 0 overruns) Console logging: level debugging, 45 messages logged Monitor logging: level debugging, 0 messages logged Trap logging: level informational, 10 messages logged Logging to 172.19.72.224, 10 message lines logged Buffer logging: level debugging, 30 messages logged
Log Buffer (16384 bytes):
RP/0/0/CPU0:Dec 3 10:30:35.068 : locald[210]: %LOCALD-3-ROOT_USERDB_INIT_FAIL : Failed to create aaa directory: File exists RP/0/0/CPU0:Dec 3 10:30:41.023 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure not ready to consume configuration. RP/0/0/CPU0:Dec 3 10:31:10.504 : sip[252]: sxa_iox_chkpt_init 154 SIP-LOG: SIP started - performing a cold start. RP/0/0/CPU0:Dec 3 10:31:33.782 : config[129]: %CONFIGCLI-7-INFRA_READY : Infrastructure ready to consume configuration. . . .
Configuration Examples for Implementing Logging Services on Cisco IOS XR Software
This section provides the following configuration examples: • Configuring Logging to the Console Terminal and the Logging Buffer: Example, page 139 • Setting Up Destinations for Syslog Messages: Example, page 139 • Configuring the Settings for the Logging History Table: Example, page 139 • Modifying Time Stamps: Example, page 139
Cisco IOS XR System Management Configuration Guide SMR-138 Implementing Logging Services on Cisco IOS XR Software Configuration Examples for Implementing Logging Services on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring Logging to the Console Terminal and the Logging Buffer: Example
The following example shows a logging configuration where logging to the logging buffer is enabled, the severity level of syslog messages sent to the console terminal is limited to syslog messages at or below the critical severity level, and the size of the logging buffer is set to 60,000 bytes. ! logging on logging console critical logging buffered 60000 !
Setting Up Destinations for Syslog Messages: Example
The following example shows a logging configuration where logging is configured to destinations other than the console terminal. In this configuration, the following is configured: • Logging is enabled to destinations other than the console terminal. • Syslog messages at or below the warnings severity level are sent to syslog server hosts. • Syslog messages at or below the critical severity level are sent to terminal lines. • The size of the logging buffer is set to 60,000 bytes. • The syslog server host at IP address 172.19.72.224 is configured as a recipient for syslog messages. ! logging on logging trap warnings logging monitor critical logging buffered 60000 logging 172.19.72.224 !
Configuring the Settings for the Logging History Table: Example
The following example shows a logging configuration in which the size of the logging history table is to 200 entries and the severity of level of syslog messages sent to the logging history table is limited to messages at or below the errors severity level: logging history size 200 logging history errors
Modifying Time Stamps: Example
The following example shows a time-stamp configuration in which time stamps are configured to follow the format month date HH:MM:SS time zone: service timestamps log datetime show-timezone
The following example shows a time-stamp configuration in which time stamps are configured to follow the format month date HH:MM:SS.milliseconds time zone: service timestamps log datetime msec show-timezone
Cisco IOS XR System Management Configuration Guide SMR-139 Implementing Logging Services on Cisco IOS XR Software Where to Go Next R3.3 Beta Draft—Cisco Confidential Information Where to Go Next
To configure alarm log correlation, see the Implementing and Monitoring Alarms and Logging Correlation on Cisco IOS XR Software module in the Cisco IOS XR System Management Configuration Guide.
Additional References
The following sections provide references related to implementing logging services on Cisco IOS XR software.
Related Documents
Related Topic Document Title Cisco IOS XR alarm and logging correlation Alarm Management and Logging Correlation Commands on commands Cisco IOS XR Software, Release 3.2 Cisco IOS XR alarm and logging correlation Implementing and Monitoring Alarms and Logging Correlation on configuration and monitoring tasks Cisco IOS XR Software, Release 3.2 Cisco IOS XR SNMP commands SNMP Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR SNMP configuration tasks Implementing SNMP on Cisco IOS XR Software, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master Command List, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2
Standards
Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature.
MIBs
MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Cisco IOS XR System Management Configuration Guide SMR-140 Implementing Logging Services on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs
RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature.
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMR-141 Implementing Logging Services on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
Cisco IOS XR System Management Configuration Guide SMR-142 R3.3 Beta Draft—Cisco Confidential Information
Implementing NTP on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
Network Time Protocol (NTP) is a protocol designed to time-synchronize devices within a network. The Cisco IOS XR software implements NTPv4. NTPv4 retains backwards compatibility with the older versions of NTP, including NTPv3 and NTPv2 but excluding NTPv1, which has been discontinued due to security vulnerabilities. This module describes the new and revised tasks you need to implement NTP on your Cisco IOS XR network.
Note For more information about NTP on the Cisco IOS XR software and complete descriptions of the NTP commands listed in this module, you can refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing NTP on Cisco IOS XR Software Contents Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification. Release 3.2 Support was added for the Cisco XR 12000 Series Router. Release 3.3 No modification.
Contents
• Prerequisites for Implementing NTP on Cisco IOS XR Software, page 144 • Information About Implementing NTP on Cisco IOS XR Software, page 144 • How to Implement NTP on Cisco IOS XR Software, page 145 • Configuration Examples for Implementing NTP on Cisco IOS XR Software, page 162 • Additional References, page 166
Cisco IOS XR System Management Configuration Guide SMR-143 Implementing NTP on Cisco IOS XR Software Prerequisites for Implementing NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Implementing NTP on Cisco IOS XR Software
The following prerequisites are required to implement NTP in your network operating center (NOC): • You must be in a user group associated with a task group that includes the proper task IDs for CDP commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide. • You must have connectivity with at least one server that is running NTP.
Information About Implementing NTP on Cisco IOS XR Software
To implement NTP, you need to understand the following concept: • “NTP Functional Overview” section on page 144
NTP Functional Overview
NTP synchronizes timekeeping among a set of distributed time servers and clients. This synchronization allows events to be correlated when system logs are created and other time-specific events occur. NTP uses the User Datagram Protocol (UDP) as its transport protocol. All NTP communication uses Coordinated Universal Time (UTC). An NTP network usually receives its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of each other. NTP uses the concept of a “stratum” to describe how many NTP “hops” away a machine is from an authoritative time source. A “stratum 1” time server typically has an authoritative time source (such as a radio or atomic clock, or a GPS time source) directly attached, a “stratum 2” time server receives its time via NTP from a “stratum 1” time server, and so on. NTP avoids synchronizing to a machine whose time may not be accurate in two ways. First, NTP will never synchronize to a machine that is not in turn synchronized itself. Second, NTP compares the time reported by several machines and does not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers. The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend that time service for your network be derived from the public NTP servers available in the IP Internet. If the network is isolated from the Internet, the Cisco implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines can then synchronize to that machine via NTP. A number of manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco routers.
Cisco IOS XR System Management Configuration Guide SMR-144 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
The communications between machines running NTP (known as “associations”) are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association. However, in a LAN environment, NTP can be configured to use IP broadcast messages instead. This alternative reduces configuration complexity, because each machine can simply be configured to send or receive broadcast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only. The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism. When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.
How to Implement NTP on Cisco IOS XR Software
This section contains the following procedures: • “Configuring Poll-Based Associations” section on page 145 (optional) • “Configuring Broadcast-Based NTP Associations” section on page 147 (optional) • “Configuring NTP Access Groups” section on page 149 (optional) • “Configuring NTP Authentication” section on page 152 (optional) • “Disabling NTP Services on a Specific Interface” section on page 154 (optional) • “Configuring the Source IP Address for NTP Packets” section on page 156 (optional) • “Configuring the System as an Authoritative NTP Server” section on page 158 (optional) • “Updating the Hardware Clock” section on page 159 (optional) • “Verifying the Status of the External Reference Clock” section on page 161 (optional)
Configuring Poll-Based Associations
This task explains how to configure poll-based NTP associations.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
Poll-Based Associations
Networking devices running NTP can be configured to operate in variety of association modes when synchronizing time with reference time sources. There are two ways that a networking device can obtain time information on a network: by polling host servers and by listening to NTP broadcasts. In this task, we will focus on the poll-based association modes. Broadcast-based NTP associations will be discussed in the next task, “Configuring Broadcast-Based NTP Associations.”
Cisco IOS XR System Management Configuration Guide SMR-145 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
The following are two most commonly used, poll-based association modes: • Client mode • Symmetric active mode The client and the symmetric active modes should be used when NTP is required to provide a high level of time accuracy and reliability. When a networking device is operating in the client mode, it polls its assigned time serving hosts for the current time. The networking device then picks a host from all the polled time servers to synchronize with. Because the relationship that is established in this case is a client-host relationship, the host does not capture or use any time information sent by the local client device. This mode is most suited for file-server and workstation clients that are not required to provide any form of time synchronization to other local clients. Use the server command to individually specify the time-serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the client mode. When a networking device is operating in the symmetric active mode, it polls its assigned time-serving hosts for the current time and it responds to polls by its hosts. Because this is a peer-to-peer relationship, the host also retains time-related information about the local networking device that it is communicating with. This mode should be used when there is a number of mutually redundant servers that are interconnected via diverse network paths. Most stratum 1 and stratum 2 servers on the Internet today adopt this form of network setup. Use the peer command to individually specify the time-serving hosts that you want your networking device to consider synchronizing with and to set your networking device to operate in the symmetric active mode.
SUMMARY STEPS
1. configure 2. ntp 3. server ip-address [version number] [key key-id] [minpoll interval] [maxpoll interval] [source interface-type interface-instance] [prefer] 4. peer ip-address [version number] [key key-id] [minpoll interval] [maxpoll interval] [source interface-type interface-instance] [prefer] 5. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp
Cisco IOS XR System Management Configuration Guide SMR-146 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 server ip-address [version number] [key key-id] Forms a server association with another system. [minpoll interval] [maxpoll interval] [source interface-type interface-instance] [prefer]
Example: RP/0/RP0/CPU0:router(config-ntp)# server 172.16.22.44 minpoll 8 maxpoll 12 Step 4 peer ip-address [version number] [key key-id] Forms a peer association with another system. [minpoll interval] [maxpoll interval] [source interface-type interface-instance] [prefer]
Example: RP/0/RP0/CPU0:router(config-ntp)# peer 192.168.22.33 minpoll 8 maxpoll 12 source pos 0/0/0/1 Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Configuring Broadcast-Based NTP Associations
This task explains how to configure broadcast-based NTP associations.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
Broadcast-Based NTP Associations
Broadcast-based NTP associations should be used when time accuracy and reliability requirements are modest and if your network is localized and has a large number of clients (more than 20). Broadcast-based NTP associations also are recommended for use on networks that have limited bandwidth, system memory, or CPU resources.
Cisco IOS XR System Management Configuration Guide SMR-147 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
When a networking device is operating in the broadcastclient mode, it does not engage in any polling. Instead, it listens for NTP broadcast packets transmitted by broadcast time servers. Consequently, time accuracy can be marginally reduced, because time information flows only one way. Use the broadcast client command to set your networking device to listen for NTP broadcast packets propagated through a network. For broadcastclient mode to work, the broadcast server and its clients must be located on the same subnet. The time server that is transmitting NTP broadcast packets must be enabled on the interface of the given device using the broadcast command.
SUMMARY STEPS
1. configure 2. ntp 3. broadcastdelay microseconds 4. interface type instance 5. broadcast client 6. broadcast [destination ip-address] [key key-id] [version number] 7. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp Step 3 broadcastdelay microseconds Adjusts the estimated round-trip delay for NTP broadcasts.
Example: RP/0/RP0/CPU0:router(config-ntp)# broadcastdelay 5000 Step 4 interface type instance Enters NTP interface configuration mode.
Example: RP/0/RP0/CPU0:router(config-ntp)# interface POS 0/1/0/0 Step 5 broadcast client Configures the specified interface to receive NTP broadcast packets. Example: RP/0/RP0/CPU0:(config-ntp-int)# broadcast client
Cisco IOS XR System Management Configuration Guide SMR-148 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 6 broadcast [destination ip-address] [key key-id] Configures the specified interface to send NTP broadcast [version number] packets.
Example: RP/0/RP0/CPU0:(config-ntp-int)# broadcast destination 10.50.32.149 Step 7 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Configuring NTP Access Groups
This task explains how to configure NTP access groups.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
NTP Access Groups
The access list-based restriction scheme allows you to grant or deny certain access privileges to an entire network, a subnet within a network, or a host within a subnet. The access group options are scanned in the following order, from least restrictive to most restrictive: 1. peer—Allows time requests and NTP control queries and allows the system to synchronize itself to a system whose address passes the access list criteria. 2. serve—Allows time requests and NTP control queries, but does not allow the system to synchronize itself to a system whose address passes the access list criteria. 3. serve-only—Allows only time requests from a system whose address passes the access list criteria. 4. query-only—Allows only NTP control queries from a system whose address passes the access list criteria.
Cisco IOS XR System Management Configuration Guide SMR-149 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
If the source IP address matches the access lists for more than one access type, the first type is granted. If no access groups are specified, all access types are granted to all systems. If any access groups are specified, only the specified access types are granted. For details on NTP control queries, see RFC 1305 (NTP version 3).
SUMMARY STEPS
1. configure 2. ntp 3. access-group {peer | query-only | serve | serve-only} access-list-name 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp
Cisco IOS XR System Management Configuration Guide SMR-150 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 access-group {peer | query-only | serve | Creates an access group and applies a basic IP access list to serve-only} access-list-name it.
Example: RP/0/RP0/CPU0:router(config-ntp)# access-group peer access1 Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-151 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring NTP Authentication
This task explains how to configure NTP authentication.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
NTP Authentication
The encrypted NTP authentication scheme should be used when a reliable form of access control is required. Unlike the access-list-based restriction scheme that is based on IP addresses, the encrypted authentication scheme uses authentication keys and an authentication process to determine if NTP synchronization packets sent by designated peers or servers on a local network are deemed as trusted, before the time information that it carries along is accepted. The authentication process begins from the moment an NTP packet is created. Cryptographic checksum keys are generated using the MD5 Message Digest Algorithm and are embedded into the NTP synchronization packet that is sent to a receiving client. When a packet is received by a client, its cryptographic checksum key is decrypted and checked against a list of trusted keys. If authentication is enabled and a key is trusted, the system is allowed to sync to the server that uses this key in its packets. It is important to note that the encryption and decryption processes used in NTP authentication can be very CPU-intensive and can seriously degrade the accuracy of the time that is propagated within a network. If your network setup permits a more comprehensive model of access control, you should consider the use of the access-list-based form of control instead. After NTP authentication is properly configured, your networking device only synchronizes with and provides synchronization to trusted time sources.
SUMMARY STEPS
1. configure 2. ntp 3. authenticate 4. authentication-key key-number md5 [clear | encrypted] key-name 5. trusted-key key-number 6. end or commit
Cisco IOS XR System Management Configuration Guide SMR-152 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp Step 3 authenticate Enables the NTP authentication feature.
Example: RP/0/RP0/CPU0:router(config-ntp)# authenticate Step 4 authentication-key key-number md5 [clear | Defines the authentication keys. encrypted] key-name • Each key has a key number, a type, a value, and, optionally, a name. Currently the only key type Example: supported is md5. RP/0/RP0/CPU0:router(config-ntp)# authentication-key 42 md5 clear key1 Step 5 trusted-key key-number Defines trusted authentication keys. • If a key is trusted, this router only synchronizes to a Example: system that uses this key in its NTP packets. RP/0/RP0/CPU0:router(config-ntp)# trusted-key 42 Step 6 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-153 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Disabling NTP Services on a Specific Interface
This task explains how to disable NTP services on a specific interface. NTP services are disabled on all interfaces by default. NTP is enabled globally when any NTP commands are entered. You can selectively prevent NTP packets from being received through a specific interface by turning off NTP on a given interface.
SUMMARY STEPS
1. configure 2. ntp 3. no interface type instance or interface type instance disable 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp
Cisco IOS XR System Management Configuration Guide SMR-154 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 no interface type instance Disables NTP services on the specified interface. or interface type instance disable
Example: RP/0/RP0/CPU0:router(config-ntp)# no interface pos 0/0/0/1 or RP/0/RP0/CPU0:router(config-ntp)# interface POS 0/0/0/1 disable Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-155 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring the Source IP Address for NTP Packets
This task explains how configure the source IP address for NTP packets. When the system sends an NTP packet, the source IP address is normally set to the address of the interface through which the NTP packet is sent.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
SUMMARY STEPS
1. configure 2. ntp 3. source interface-type interface-instance 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp
Cisco IOS XR System Management Configuration Guide SMR-156 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 source interface-type interface-instance Configures an interface from which the IP source address will be taken. Example: Note This interface will be used for the source address for RP/0/RP0/CPU0:router(config-ntp)# source POS all packets sent to all destinations. If a source 0/0/0/1 address is to be used for a specific association, use the source parameter on the peer or server command shown in the “Configuring Poll-Based Associations” task. Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-157 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring the System as an Authoritative NTP Server
This task explains how to configure the router as an authoritative NTP server. You can configure the router to act as an authoritative NTP server, even if the system is not synchronized to an outside time source
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
SUMMARY STEPS
1. configure 2. ntp 3. master stratum 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp
Cisco IOS XR System Management Configuration Guide SMR-158 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Command or Action Purpose Step 3 master stratum Makes the router an authoritative NTP server. Note Use the master command with caution. It is very Example: easy to override valid time sources using this RP/0/RP0/CPU0:router(config-ntp)# master 9 command, especially if a low stratum number is configured. Configuring multiple machines in the same network with the master command can cause instability in timekeeping if the machines do not agree on the time. Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Updating the Hardware Clock
This task explains how to configure the hardware clock to be periodically updated from the software clock running NTP. On devices that have hardware clocks (system calendars), you can configure the hardware clock to be periodically updated from the software clock. This is advisable for any device using NTP, because the time and date on the software clock (set using NTP) is more accurate than the hardware clock, because the time setting on the hardware clock has the potential to drift slightly over time.
Note No specific command enables NTP; the first NTP configuration command that you issue enables NTP.
Cisco IOS XR System Management Configuration Guide SMR-159 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
SUMMARY STEPS
1. configure 2. ntp 3. update-calendar 4. end or commit
DETAILED STEPS
Command or Action Purpose Step 1 configure Enters global configuration mode.
Example: RP/0/RP0/CPU0:router# configure Step 2 ntp Enters NTP configuration mode.
Example: RP/0/RP0/CPU0:router(config)# ntp Step 3u update-calendar Configures the system to update its hardware clock from the software clock at periodic intervals. Example: RP/0/RP0/CPU0:router(config-ntp)# update-calendar Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
Cisco IOS XR System Management Configuration Guide SMR-160 Implementing NTP on Cisco IOS XR Software How to Implement NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Verifying the Status of the External Reference Clock
This task explains how to verify the status of NTP components.
Note The commands can be entered in any order.
SUMMARY STEPS
1. show ntp associations [detail] [location node-id] 2. show ntp status [location node-id]
DETAILED STEPS
Command or Action Purpose Step 1 show ntp associations [detail] [location Displays the status of NTP associations. node-id]
Example: RP/0/RP0/CPU0:router# show ntp associations Step 2 show ntp status [location node-id] Displays the status of NTP.
Example: RP/0/RP0/CPU0:router# show ntp status
Examples
The following is sample output from the show ntp associations command: RP/0/0/CPU0:router# show ntp associations
address ref clock st when poll reach delay offset disp +~127.127.1.1 127.127.1.1 5 5 1024 37 0.0 0.00 438.3 *~172.19.69.1 172.24.114.33 3 13 1024 1 2.0 67.16 0.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured
The following is sample output from the show ntp status command: RP/0/0/CPU0:router# show ntp status
Clock is synchronized, stratum 4, reference is 172.19.69.1 nominal freq is 1000.0000 Hz, actual freq is 999.9988 Hz, precision is 2**26 reference time is C54C131B.9EECF6CA (07:26:19.620 UTC Mon Nov 22 2004) clock offset is 66.3685 msec, root delay is 7.80 msec root dispersion is 950.04 msec, peer dispersion is 3.38 msec
Cisco IOS XR System Management Configuration Guide SMR-161 Implementing NTP on Cisco IOS XR Software Configuration Examples for Implementing NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuration Examples for Implementing NTP on Cisco IOS XR Software
This section contains the following examples: • Configuring Poll-Based Associations: Example, page 162 • Configuring Broadcast-Based Associations: Example, page 162 • Configuring NTP Access Groups: Example, page 163 • Configuring NTP Authentication: Example, page 163 • Disabling NTP on an Interface: Example, page 165 • Configuring the Source IP Address for NTP Packets: Example, page 165 • Configuring the System as an Authoritative NTP Server: Example, page 165 • Updating the Hardware Clock: Example, page 166
Configuring Poll-Based Associations: Example
The following example shows an NTP configuration in which the router’s system clock is configured to form a peer association with the time server host at IP address 192.168.22.33, and to allow the system clock to be synchronized by time server hosts at IP address 10.0.2.1 and 172.19.69.1: ! ntp server 10.0.2.1 minpoll 5 maxpoll 7 peer 192.168.22.33
server 172.19.69.1 !
Configuring Broadcast-Based Associations: Example
The following example shows an NTP client configuration in which Gigabit Ethernet interface 0/2/0/0 is configured to receive NTP broadcast packets, and the estimated round-trip delay between an NTP client and an NTP broadcast server is set to 2 microseconds: ntp interface GigabitEthernet0/2/0/0 broadcast client ! broadcastdelay 2
The following example shows an NTP server configuration where Gigabit Ethernet interface 0/2/0/2 is configured to be a broadcast server: ntp interface GigabitEthernet0/2/0/2 broadcast !
Cisco IOS XR System Management Configuration Guide SMR-162 Implementing NTP on Cisco IOS XR Software Configuration Examples for Implementing NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring NTP Access Groups: Example
The following example shows a NTP access group configuration where the following access group restrictions are applied: • Peer restrictions are applied to IP addresses that pass the criteria of the access list named peer-acl. • Serve restrictions are applied to IP addresses that pass the criteria of access list named serve-acl. • Serve-only restrictions are applied to IP addresses that pass the criteria of the access list named serve-only-acl. • Query-only restrictions are applied to IP addresses that pass the criteria of the access list named query-only-acl. ! ntp peer 10.1.1.1 peer 10.2.2.2 peer 10.3.3.3 peer 10.4.4.4 peer 10.5.5.5 peer 10.6.6.6 peer 10.7.7.7 peer 10.8.8.8 access-group peer peer-acl access-group serve serve-acl access-group serve-only serve-only-acl access-group query-only query-only-acl ! ipv4 access-list peer-acl 10 permit ip host 10.1.1.1 any 20 permit ip host 10.8.8.8 any ! ipv4 access-list serve-acl 10 permit ip host 10.4.4.4 any 20 permit ip host 10.5.5.5 any ! ipv4 access-list query-only-acl 10 permit ip host 10.2.2.2 any 20 permit ip host 10.3.3.3 any ! ipv4 access-list serve-only-acl 10 permit ip host 10.6.6.6 any 20 permit ip host 10.7.7.7 any !
Configuring NTP Authentication: Example
The following example shows an NTP authentication configuration. In this example, the following is configured: • NTP authentication is enabled. • Two authentication keys are configured (key 2 and key 3). • The router is configured to allow its software clock to be synchronized with the clock of the peer (or vice versa) at IP address 10.3.32.154 using authentication key 2. • The router is configured to allow its software clock to be synchronized with the clock by the device at IP address 10.32.154.145 using authentication key 3.
Cisco IOS XR System Management Configuration Guide SMR-163 Implementing NTP on Cisco IOS XR Software Configuration Examples for Implementing NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
• The router is configured to synchronize only to systems providing authentication key 3 in their NTP packets. ! ntp authentication-key 2 md5 encrypted 06120A2D40031D10081240 authentication-key 3 md5 encrypted 1311121E074110232621 authenticate trusted-key 3 server 10.3.32.154 key 3 peer 10.32.154.145 key 2 !
Cisco IOS XR System Management Configuration Guide SMR-164 Implementing NTP on Cisco IOS XR Software Configuration Examples for Implementing NTP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Disabling NTP on an Interface: Example
The following example shows an NTP configuration in which Gigabit Ethernet 0/2/0/0 interface is disabled: ! ntp interface GigabitEthernet0/2/0/0 disable ! authentication-key 2 md5 encrypted 06120A2D40031D10081240 authentication-key 3 md5 encrypted 1311121E074110232621 authenticate trusted-key 3 server 10.3.32.154 key 3 peer 10.32.154.145 key 2 !
Configuring the Source IP Address for NTP Packets: Example
The following example shows an NTP configuration in which Ethernet management interface 0/0/CPU0/0 is configured as the source address for NTP packets: ! ntp ! authentication-key 2 md5 encrypted 06120A2D40031D10081240 authentication-key 3 md5 encrypted 1311121E074110232621 authenticate trusted-key 3 server 10.3.32.154 key 3 peer 10.32.154.145 key 2 source MgmtEth0/0/CPU0/0 !
Configuring the System as an Authoritative NTP Server: Example
The following example shows a NTP configuration in which the router is configured to use its own NTP master clock to synchronize with peers when an external NTP source becomes unavailable: ! ntp master 6 !
Cisco IOS XR System Management Configuration Guide SMR-165 Implementing NTP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Updating the Hardware Clock: Example
The following example shows an NTP configuration in which the router is configured to update its hardware clock from the software clock at periodic intervals: ! ntp server 10.3.32.154 master 6 update-calendar !
Additional References
The following sections provide references related to implementing NTP on Cisco IOS XR software.
Related Documents
Related Topic Document Title Cisco IOS XR clock commands Clock Commands on Cisco IOS XR Software module of Cisco IOS XR System Management Command Reference, Release 3.2 Cisco IOS XR NTP commands NTP Commands on Cisco IOS XR Software module of the Cisco IOS XR System Management Command Reference, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2
Standards
Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature.
MIBs
MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Cisco IOS XR System Management Configuration Guide SMR-166 Implementing NTP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs
RFCs Title RFC 1305 Network Time Protocol, Version 3: Specification, Implementation, and Analysis RFC 1119 Network Time Protocol, Version 2: Specification and Implementation RFC 1059 Network Time Protocol, Version 1: Specification and Implementation
Technical Assistance
Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
Cisco IOS XR System Management Configuration Guide SMR-167 Implementing NTP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information
Cisco IOS XR System Management Configuration Guide SMR-168 R3.3 Beta Draft—Cisco Confidential Information
Implementing Performance Management on Cisco IOS XR Software
Beta Draft Cisco Confidential Information
Performance management (PM) on the Cisco IOS XR software provides a framework to perform the following tasks: • Collect and export PM statistics to a TFTP server for data storage and retrieval • Monitor the system using extensible markup language (XML) queries • Configure threshold conditions that generate system logging messages when a threshold condition is matched. The PM system collects data that is useful for graphing or charting system resource utilization, for capacity planning, for traffic engineering, and for trend analysis. This module describes the new and revised tasks you need to implement PM on your Cisco IOS XR network.
Note For more information about PM on the Cisco IOS XR software and complete descriptions of the PM commands listed in this module, you can refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index.
Feature History for Implementing Performance Management on Cisco IOS XR Software Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification. Release 3.2 Support was added for the Cisco XR 12000 Series Router. Release 3.3 No modification.
Contents
• Prerequisites for Implementing Performance Management on Cisco IOS XR Software, page 170 • Information About Implementing Performance Management on Cisco IOS XR Software, page 170 • How to Implement Performance Management on Cisco IOS XR Software, page 190
Cisco IOS XR System Management Configuration Guide SMR-169 Implementing Performance Management on Cisco IOS XR Software Prerequisites for Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
• Configuration Examples for Implementing Performance Management on Cisco IOS XR Software, page 202 • Additional References, page 203
Prerequisites for Implementing Performance Management on Cisco IOS XR Software
Before implementing performance management in your network operations center (NOC), ensure that the following prerequisites are met: • You must install and activate the Package Installation Envelope (PIE) for the manageability software. For detailed information about optional PIE installation, refer to the Cisco IOS XR Getting Started Guide. • You must be in a user group associated with a task group that includes the proper task IDs for performance management commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide. • You must have connectivity with a TFTP server.
Information About Implementing Performance Management on Cisco IOS XR Software
To implement performance management, you need to understand the following concepts: • PM Functional Overview, page 170 • PM Statistics Collection Overview, page 172 • PM Entity Instance Monitoring Overview, page 177 • PM Threshold Monitoring Overview, page 181
PM Functional Overview
The PM frameworks consists of two major components: • PM statistics server • PM statistics collectors
PM Statistics Server
The PM statistics server is the front end for statistic collections, entity instance monitoring collections, and threshold monitoring. All PM statistic collections and threshold conditions configured through the command-line interface (CLI) or through XML schemas are processed by the PM statistics server and distributed among the PM statistics collectors.
Cisco IOS XR System Management Configuration Guide SMR-170 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
PM Statistics Collector
The PM statistics collector collects statistics from entity instances and stores that data in memory. The memory contents are checkpointed so that information is available across process restarts. In addition, the PM statistics collector is responsible for exporting operational data to the XML agent and to the TFTP server. Figure 5 illustrates the relationship between the components that constitute the PM system.
Figure 5 PM Component Communications
Data export
Remote TFTP Server
CLI XML agent
Configurationconfiguration Configurationconfiguration
OperationalOperational OOperationalperational PM statistics server Ddataata Ddataata
Collection
PM statistics collector
Statistics Statistics
Application Application 117362
Cisco IOS XR System Management Configuration Guide SMR-171 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
PM Benefits
The PM system provides the following benefits: • Configurable data collection policies • Efficient transfer of statistical data in the binary format via TFTP • Entity instance monitoring support • Threshold monitoring support • Data persistency across process restarts and Route Processor (RP) failovers
PM Statistics Collection Overview
A PM statistics collection gathers statistics from all the attributes associated with all the instances of an entity in the PM system and exports the statistical data in the binary file format to a TFTP server. For example, a Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) statistics collection gathers statistical data from all the attributes associated with all MPLS LDP sessions on the router. Table 20 lists the entities and the associated instances in the PM system.
Table 20 Entity Classes and Associated Instances
Entity Classes Instance BGP Neighbors or Peers Interface Data Rates Interfaces Interface Generic Counters Interfaces MPLS Interface MPLS Interfaces MPLS LDP LDP Sessions Node CPU Nodes Node Memory Nodes Node Process Processes OSPFv2 Process OSPFv3 Process
Note For a list of all the attributes associated with the entities that constitute the PM system, refer to Table 28.
PM Statistics Collection Templates
PM statistics collections are configured through PM statistics collection templates. A PM statistics collection template contains the entity, the sample interval, and the number of sampling operations to be performed before exporting the data to a TFTP server. When a PM statistics collection template is enabled, the PM statistics collection gathers statistics for all attributes from all instances associated with the entity configured in the template.
Cisco IOS XR System Management Configuration Guide SMR-172 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Guidelines for Creating PM Statistics Collection Templates
When creating PM statistics collection templates, follow these guidelines: • Use the performance-mgmt statistics command to create a PM statistics collection template. • You can define multiple templates for any given entity; however, only one PM statistics collection template for a given entity can be enabled at a time. • When configuring a template, you must name the template. You can designate the template for the entity as the default template using the default keyword or name the template with the template keyword and template-name argument. The default template contains the following default settings: – A sample interval of 10 minutes. – A sample size of five sampling operations. • Configure the settings for the sample interval and sample size in the template. – The sample interval sets the frequency of the sampling operations performed during the sampling cycle. You can configure the sample interval with the sample-interval keyword and minutes argument. The range is from 1 to 60 minutes. The default is 10 minutes. – The sample size sets the number of sampling operations to be performed before exporting the data to the TFTP server. You can configure the sample size with the sample-size keyword and minutes argument. The range is from 1 to 60 samples. The default is five samples. • The export cycle determines how often PM statistics collection data is exported to the TFTP server. The export cycle can be calculated by multiplying the sample interval and sample size (sample interval x sample size = export cycle). For example, suppose that the sample interval is set at a frequency of 10 minutes, and the sample size is set to five sampling operations. Given that, a total of five sampling operations would be performed at a frequency of one sampling operation every 10 minutes. This cycle is referred to as the sampling cycle. A binary file containing the data collected from those samples would be exported to the TFTP server once every 50 (5 x 10) minutes. This cycle is referred to as the export cycle.
Caution Specifying a small sample interval increases CPU utilization, whereas specifying a large sample size increases memory utilization. The sample size and sample interval, therefore, may need to be adjusted to prevent system overload.
Guidelines for Enabling and Disabling PM Statistics Collection Templates
When enabling PM statistics collection templates, follow these guidelines: • Use the performance-mgmt apply statistics command to enable a PM statistics collection template. • Only one PM statistics collection template for a given entity can be enabled at a time.
Note Data collection will begin one sampling cycle after you enable the PM statistics collection template with the performance-mgmt enable statistics command.
• Once a template has been enabled, the sampling and export cycles continue until the template is disabled with the no form of the performance-mgmt apply statistics command. • You must specify either a location with the location keyword and node-id argument or the location all keywords when enabling or disabling a PM statistic collections for the following entities:
Cisco IOS XR System Management Configuration Guide SMR-173 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
– Node CPU – Node memory – Node process The location keyword with the node-id argument enables the PM statistic collections for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keywords enable the PM statistic collections for all nodes. • Because only one PM statistics collection can be enabled for any given entity at any given time, you are not required to specify the template name with the default keyword or template keyword and template-name argument when disabling a PM statistics collection.
Binary File Format
The following sample describes the binary file format: Version : 4 Bytes NoOf Entities : 1 Byte (e.g. . 4 ) Entity Identifier : 1 Byte (e.g NODE=1,Interface=2,BGP=3,MPLS=4) Options :2 Bytes NoOf SubEntities :1 Byte (2) SubEntity Identifier :1 Byte (e.g BGP-PEERS ) Time Stamp 4 Bytes (Reference Time : Start Ref Time) No Of Instances :2 Byte (e.g 100) Key Instance :Variable NoOfSamples: 1 Byte (e.g 10 Samples) SampleNo : 1 Byte (e.g Sample No 1) Time Stamp 4 Bytes (Sample Time) StatCounterName :1 Byte (PeerSessionsEst=1) StatCounterValue :8 Bytes ( for all counters) Repeat for Each StatCounterName Repeat for Each Sample No(Time Interval) Repeat for All Instances Repeat for All SubTypes Repeat for All Entities
Cisco IOS XR System Management Configuration Guide SMR-174 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information
Binary File ID Assignments for Entity, Subentity, and StatsCounter Names
Table 21 describes the assignment of the various values and keys which will be present in the binary file.
Table 21 Binary Format Values and Keys
Entity Subentity Key StatsCounters Node (1) CPU (1) CPU Key Note The numbers in parenthesis (the numbers that are associated with each entity and subentity in Table 21) denote the entity and subEntity IDs that are displayed in the TFTP File. Cisco IOS XR System Management Configuration Guide SMR-175 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 22 describes the supported StatsCounters that are collected in the binary file for entities and subentities. Table 22 Supported StatsCounters for Entities and Subentites Entity Subentity StatsCounters Node (1) CPU (1) AverageCPUUsed, NoProcesses Memory (2) CurrMemory, PeakMemory Process (3) AvgCPUUsed, NoThreads, PeakMemory Interface (2) Generic InPackets, InOctets, OutPackets, OutOctets, InUcastPkts, Counters (1) InMulticastPkts, InBroadcastPkts, OutUcastPkts, OutMulticastPkts, OutBroadcastPkts, OutputTotalDrops, InputTotalDrops, InputQueueDrops, InputUnknownProto, OutputTotalErrors, OutputUnderrunInputTotalErrors, InputCRC,InputOverrun, InputFrame Data Rate InputDataRate, InputPacketRate, OutputDataRate, Counters (2) OutputPacketRate, InputPeakRate, InputPeakPkts, OutputPeakRate, OutputPeakPkts, Bandwidth BGP (3) Peer (1) InputUpdateMessages, OutputUpdateMessages,InputMessages, OutputMessages, ConnEstablished, ConnDropped, ErrorsReceived, ErrorsSent MPLS (4) Interface (3) FailedLabelLookup, FragmentedPkts LDP (4) TotalMsgsSent, TotalMsgsRcvd, InitMsgsSent, InitMsgsRcvd, AddressMsgsSent, AddressMsgsRcvd, AddressWithdrawMsgsSent, AddressWithdrawMsgsRcvd, LabelMappingMsgsSent, LabelMappingMsgsRcvd, LabelWithdrawMsgsSent, LabelWithdrawMsgsRcvd, LabelReleaseMsgsSent, LabelReleaseMsgsRcvd, NotificationMsgsSent, NotificationMsgsRcvd KeepAliveMsgsSent, KeepAliveMsgsRcvd OSPF (5) v2protocol (1) InputPackets, OutputPackets, InputHelloPackets, OutputHelloPackets, InputDBDs, InputDBDsLSA, OutputDBDs, OutputDBDsLSA, InputLSRequests, InputLSRequestsLSA, OutputLSRequests, OutputLSRequestsLSA, InputLSAUpdates, InputLSAUpdatesLSA, OutputLSAUpdates, OutputLSAUpdatesLSA, InputLSAAcks, InputLSAAcksLSA, OutputLSAAcks, OutputLSAAcksLSA, ChecksumErrors v3protocol (2) InputPackets, OutputPackets, InputHelloPackets, OutputHelloPackets, InputDBDs, InputDBDsLSA, OutputDBDs, OutputDBDsLSA, InputLSRequests, InputLSRequestsLSA, OutputLSRequests, OutputLSRequestsLSA, InputLSAUpdates, InputLSAUpdatesLSA, OutputLSAUpdates, OutputLSAUpdatesLSA, InputLSAAcks, InputLSAAcksLSA, OutputLSAAcks, OutputLSAAcksLSA Cisco IOS XR System Management Configuration Guide SMR-176 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Filenaming Convention Applied to Binary Files The following filenaming convention is applied to PM statistics collections that are sent to the directory location configured on the TFTP server: PM Entity Instance Monitoring Overview Entity instance monitoring gathers statistics from the attributes associated with a specific entity instance. When an entity instance has been enabled for monitoring, the PM system gathers statistics from only the attributes associated with the specified entity instance. The PM system uses the sampling cycle configured in the PM statistics collection template for the entity being monitored. Entity instance monitoring, however, is separate process from the PM statistics collection; thus, it will not interfere with PM statistic collections. The data from entity instance monitoring collections, furthermore, is independent from PM statistics collections. Unlike PM statistic collections, the data from entity instance monitoring is not exported to the TFTP server. Note The data from entity instance monitoring can be retrieved only through the XML interface. Table 23 describes the command used to enable entity instance monitoring for the BGP entity instance. Table 23 BGP Entity Instance Monitoring Entity Command Description BGP Use the performance-mgmt apply monitor bgp command in global configuration mode to enable entity instance monitoring for a BGP entity instance. Syntax: performance-mgmt apply monitor bgp ip-address {template-name | default} Example: RP/0/RP0/CPU0:router(config)# performance-mgmt apply monitor bgp 10.12.0.4 default Cisco IOS XR System Management Configuration Guide SMR-177 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 24 describes the commands used to enable entity instance monitoring for the interface entity instances. Table 24 Interface Entity Instance Monitoring Entity Command Descriptions Interface Data Rates Use the performance-mgmt apply monitor data-rates command in global configuration mode to enable entity instance monitoring for an interface data rates entity instance. Syntax: performance-mgmt apply monitor interface data-rates interface-type interface-instance {template-name | default} Example: RP/0/RP0/CPU0:router(config)# performance-mgmt apply monitor interface data-rates POS 0/2/0/0 default Interface Generic Counters Use the performance-mgmt apply monitor interface generic-counters command in global configuration mode to enable entity instance monitoring for an interface generic counters entity instance. Syntax: performance-mgmt apply monitor interface generic-counters interface-type interface-instance {template-name | default} Example: RP/0/RP0/CPU0:router(config)# performance-mgmt apply monitor interface generic-counters POS 0/2/0/0 default Cisco IOS XR System Management Configuration Guide SMR-178 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 25 describes the commands used to enable entity instance monitoring for the MPLS entity instances. Table 25 MPLS Entity Instance Monitoring Entity Command Descriptions MPLS Interface Use the performance-mgmt apply monitor mpls interface command in global configuration mode to enable entity instance monitoring for an MPLS interface entity instance. Syntax: performance-mgmt apply monitor mpls interface interface-type interface-instance {template-name | default} Example: RP/0/RP0/CPU0:router(config)# performance-mgmt apply monitor mpls interface POS 0/2/0/0 default MPLS LDP Use the performance-mgmt apply monitor mpls ldp command in global configuration mode to enable entity instance monitoring for an MPLS LDP entity instance. Syntax: performance-mgmt apply monitor mpls ldp ip-address {template-name | default} Example: RP/0/RP0/CPU0:router(config)# performance-mgmt apply monitor mpls ldp 10.34.64.154 default Cisco IOS XR System Management Configuration Guide SMR-179 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 26 describes the commands used to enable entity instance monitoring for the Node entity instances. Table 26 Node Entity Instance Monitoring Entity Command Descriptions Node CPU Use the performance-mgmt apply monitor node cpu command in global configuration mode to enable entity instance monitoring for a node CPU entity instance. Syntax: performance-mgmt apply monitor node cpu node-id {template-name | default} Example: RP/0/RP1/CPU0:router(config)# performance-mgmt apply monitor node cpu 0/RP1/CPU0 default Node Memory Use the performance-mgmt apply monitor node memory command in global configuration mode to enable an entity instance monitoring for a node memory entity instance. Syntax: performance-mgmt apply monitor node memory node-id {template-name | default} Example: RP/0/RP1/CPU0:router(config)# performance-mgmt apply monitor node memory 0/RP1/CPU0 default Node Process Use the performance-mgmt apply monitor node process command in global configuration mode to enable an entity instance monitoring collection for a node process entity instance. Syntax: performance-mgmt apply monitor node process node-id pid {template-name | default} Example: RP/0/RP1/CPU0:router(config)# performance-mgmt apply monitor node process 0/RP1/CPU0 275 default Cisco IOS XR System Management Configuration Guide SMR-180 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information PM Threshold Monitoring Overview The PM system supports the configuration of threshold conditions to monitor an attribute (or attributes) for threshold violations. Threshold conditions are configured through PM threshold monitoring templates. When a PM threshold template is enabled, the PM system monitors all instances of the attribute (or attributes) for the threshold condition configured in the template. If at end of the sample interval a threshold condition is matched, the PM system generates a system logging message for each instance that matches the threshold condition. Guidelines for Creating PM Threshold Monitoring Templates When creating a PM threshold template, follow these guidelines: • Use the performance-mgmt thresholds command to create a PM threshold template. • Specify the entity for the entity argument. • You can define multiple PM thresholds templates for an entity; however, only one PM threshold template for an entity can be enabled at a time. • When configuring a template, you must name the template. You can designate the template for the entity as the default template using the default keyword or name the template with the template keyword and template-name argument. The default setting for the default template is a sample interval of 10 minutes. • Specify the attribute associated with the entity to be monitored for threshold violations for the attribute argument. Note For a list of the attributes associated for each entity, refer to Table 28. • Configure the sample interval for PM threshold monitoring with the sample-interval keyword and interval argument. The sample interval sets the frequency (in minutes) that the PM system waits before determining if any instances of the attribute match the threshold condition. • Specify the threshold condition for the attribute (or attributes) to be monitored. A threshold condition consists of an attribute, an operation, and the threshold value. The threshold condition applies to all instances of the attribute. Note A PM threshold template may contain multiple threshold conditions. You must define each threshold condition to be monitored and apply it to the specified template with the performance-mgmt thresholds command. • Specify the operation to be performed in the threshold condition. The supported operations are as follows: – EQ—Equal to – GE—Greater than or equal to – GT—Greater than – LE—Less than or equal to – LT—Less than Cisco IOS XR System Management Configuration Guide SMR-181 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information – NE—Not equal to – RG—Not in range • Specify a value for the value argument. If you express the value argument, the PM system considers the threshold condition absolute, and determines after each sample interval if any instance of the attribute matches the threshold condition. If you specify the not in range operation with the RG keyword, you must supply a pair of values that specify the range. • If you specify the optional percent keyword, the value argument must be expressed as a percent from 0 to 100. If you express the value as a percentage with the value argument and percent keyword, the threshold condition compares the value with the difference between the current and previous sample for each instance of attribute as a percentage. • You can also specify the optional rearm toggle keywords or the optional rearm window keywords and window-size argument: – rearm toggle— Suppresses system logging messages for an instance of an attribute once an instance of the attribute matches the threshold condition. System logging messages for that instance of the attribute are suppressed in successive sample intervals until that instance of the attribute does not match the threshold condition. – rearm window window-size—Suppresses system logging messages for the number of intervals specified for the window-size argument once an instance of attribute matches the threshold condition. Note For more information on how the PM system determines if a threshold condition is met, refer to Table 27. Table 27 describes how the PM system determines if a threshold condition is met. Table 27 How the PM System Determines if a Threshold Condition Is Met If the threshold condition is composed of... Then...... an attribute, an operation, and a specific The threshold condition is absolute because the PM value, system determines if any instance of the attribute exactly matches the threshold condition after each sample interval elapses; the threshold value, thus, is absolute. • For example, suppose that a threshold condition for an entity is configured to check if an attribute for any instance is greater than 2000. After the sample interval elapses, the PM system, accordingly, determines if any instance of the attribute matches the condition. • The PM system generates a system logging message for each instance of the attribute that matches the threshold condition after the sample interval elapses. • If no instances of the attribute match the threshold condition, no system logging messages are generated for that sample interval. Cisco IOS XR System Management Configuration Guide SMR-182 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 27 How the PM System Determines if a Threshold Condition Is Met (continued) If the threshold condition is composed of... Then...... an attribute, an operation, and a value The threshold condition is relative because the threshold expressed as a percentage, value used for comparison is taken as a percentage from the previous sample. • For example, suppose that a threshold condition for an entity is configured to check if an attribute for any instance increases more than 50 percent of the threshold value in the previous sample. Now, suppose that after the sample interval elapses, the value of an instance of the attribute is 250. Because the threshold condition is configured to generate a system logging message if any instance of the attribute is greater than 50 percent of the previous threshold value, the PM system would check to see if that particular instance of the attribute is greater than 375 (250 + 125 [50 percent of 250]) in the following sample interval. Note The PM system matches the threshold condition against all instances of the attribute; thus, the threshold value for this type of threshold condition is relative to the value of each instance of the attribute. • The PM system generates a system logging message for each instance of the attribute that matches the threshold condition after the sample interval elapses. • If no instances of the attribute match the threshold condition, no system logging messages are generated for that sample interval. ...an attribute, an operation, a specific The threshold condition is modified such that if an value, and the rearm toggle keywords... instance of an attribute matches the threshold condition, a system logging message is generated for that instance of the attribute after the sample interval elapses. However, if the same instance of the attribute matches the threshold condition in successive sample intervals following the initial match, system logging messages for that instance of the attribute are suppressed until the instance does not match the threshold condition for a sample interval. ...an attribute, an operation, a specific The threshold condition is modified such that if an value, and the rearm window keywords instance of an attribute matches the threshold condition, a and window-size argument... system logging message is generated. However, once an instance of the attribute matches the threshold condition, system logging messages for that instance of the attribute are suppressed for the number of intervals specified with the window-size argument. Cisco IOS XR System Management Configuration Guide SMR-183 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 describes the attributes and value ranges associated with each attribute for all the entities that constitute the PM system. \ Table 28 Attributes and Values Entity Attributes Description Values bgp ConnDropped Number of times the Range is from 0 connection was dropped. to 4294967295. ConnEstablished Number of times the Range is from 0 connection was established. to 4294967295. ErrorsReceived Number of error notifications Range is from 0 received on the connection. to 4294967295. ErrorsSent Number of error notifications Range is from 0 sent on the connection. to 4294967295. InputMessages Number of messages received. Range is from 0 to 4294967295. InputUpdateMessages Number of update messages Range is from 0 received. to 4294967295. OutputMessages Number of messages sent. Range is from 0 to 4294967295. OutputUpdateMessages Number of update messages Range is from 0 sent. to 4294967295. interface Bandwidth Bandwidth in kbps. Range is from 0 data-rates to 4294967295. InputDataRate Input data rate in kbps. Range is from 0 to 4294967295. InputPacketRate Input packets per second. Range is from 0 to 4294967295. InputPeakRate Peak input data rate. Range is from 0 to 4294967295. InputPeakPkts Peak input packet rate. Range is from 0 to 4294967295. OutputDataRate Output data rate in kbps. Range is from 0 to 4294967295. OutputPacketRate Output packets per second. Range is from 0 to 4294967295. OutputPeakPkts Peak output packet rate. Range is from 0 to 4294967295. OutputPeakRate Peak output data rate. Range is from 0 to 4294967295. Cisco IOS XR System Management Configuration Guide SMR-184 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 Attributes and Values (continued) Entity Attributes Description Values interface InBroadcastPkts Broadcast packets received. Range is from 0 generic-counters to 4294967295. InMulticastPkts Multicast packets received. Range is from 0 to 4294967295. InOctets Bytes received. Range is from 0 to 4294967295. InPackets Packets received. Range is from 0 to 4294967295. InputCRC Inbound packets discarded with Range is from 0 incorrect CRC. to 4294967295. InputFrame Inbound framing errors. Range is from 0 to 4294967295. InputOverrun Input overruns. Range is from 0 to 4294967295. InputQueueDrops Input queue drops. Range is from 0 to 4294967295. InputTotalDrops Inbound correct packets Range is from 0 discarded. to 4294967295. InputTotalErrors Inbound incorrect packets Range is from 0 discarded. to 4294967295. InUcastPkts Unicast packets received. Range is from 0 to 4294967295. InputUnknownProto Inbound packets discarded with Range is from 0 unknown protocol. to 4294967295. OutBroadcastPkts Broadcast packets sent. Range is from 0 to 4294967295. OutMulticastPkts Multicast packets sent. Range is from 0 to 4294967295. OutOctets Bytes sent. Range is from 0 to 4294967295. OutPackets Packets sent. Range is from 0 to 4294967295. OutputTotalDrops Outbound correct packets Range is from 0 discarded. to 4294967295. OutputTotalErrors Outbound incorrect packets Range is from 0 discarded. to 4294967295. OutUcastPkts Unicast packets sent. Range is from 0 to 4294967295. OutputUnderrun Output underruns. Range is from 0 to 4294967295. Cisco IOS XR System Management Configuration Guide SMR-185 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 Attributes and Values (continued) Entity Attributes Description Values mpls interface FailedLabelLookup Failed label lookups. Range is from 0 to 4294967295. FragmentedPkts Packets fragmented. Range is from 0 to 4294967295. mpls ldp AddressMsgsRcvd Address messages received. Range is from 0 to 4294967295. AddressMsgsSent Address messages sent. Range is from 0 to 4294967295. AddressWithdrawMsgsRcd Address withdraw messages Range is from 0 received. to 4294967295. AddressWithdrawMsgsSent Address withdraw messages Range is from 0 sent. to 4294967295. InitMsgsSent Initial messages sent. Range is from 0 to 4294967295. InitMsgsRcvd Initial messages received. Range is from 0 to 4294967295. KeepaliveMsgsRcvd Keepalive messages received. Range is from 0 to 4294967295. KeepaliveMsgsSent Keepalive messages sent. Range is from 0 to 4294967295. LabelMappingMsgsRcvd Label mapping messages Range is from 0 received. to 4294967295. LabelMappingMsgsSent Label mapping messages sent. Range is from 0 to 4294967295. LabelReleaseMsgsRcvd Label release messages Range is from 0 received. to 4294967295. LabelReleaseMsgsSent Label release messages sent. Range is from 0 to 4294967295. LabelWithdrawMsgsRcvd Label withdraw messages Range is from 0 received. to 4294967295. LabelWithdrawMsgsSent Label withdraw messages sent. Range is from 0 to 4294967295. NotificationMsgsRcvd Notification messages Range is from 0 received. to 4294967295. NotificationMsgsSent Notification messages sent. Range is from 0 to 4294967295. TotalMsgsRcvd Total messages received. Range is from 0 to 4294967295. TotalMsgsSent Total messages sent. Range is from 0 to 4294967295. Cisco IOS XR System Management Configuration Guide SMR-186 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 Attributes and Values (continued) Entity Attributes Description Values node cpu AverageCPUUsed Average percent CPU Range is a utilization. percentage from 0 to 100. NoProcesses Number of processes. Range is from 0 to 4294967295. node memory CurrMemory Current application memory (in Range is from 0 bytes) in use. to 4294967295. PeakMemory Maximum system memory (in Range is from 0 MB) used since bootup. to 4194304. node process AverageCPUUsed Average percent CPU Range is a utilization. percentage from 0 to 100. NoThreads Number of threads. Range is from 0 to 4294967295. PeakMemory Maximum dynamic memory (in Range is from 0 KB) used since startup time. to 4194304. ospf v2protocol InputPackets Total number of packets Range is from 0 received. to 4294967295. OutputPackets Total number of packets sent. Range is from 0 to 4294967295. InputHelloPackets Number of Hello packets Range is from 0 received. to 4294967295. OutputHelloPackets Number of Hello packets sent. Range is from 0 to 4294967295. InputDBDs Number of DBD packets Range is from 0 received. to 4294967295. InputDBDsLSA Number of LSA received in Range is from 0 DBD packets. to 4294967295. OutputDBDs Number of DBD packets sent. Range is from 0 to 4294967295. OutputDBDsLSA Number of LSA sent in DBD Range is from 0 packets. to 4294967295. InputLSRequests Number of LS requests Range is from 0 received. to 4294967295. InputLSRequestsLSA Number of LSA received in LS Range is from 0 requests. to 4294967295. OutputLSRequests Number of LS requests sent. Range is from 0 to 4294967295. OutputLSRequestsLSA Number of LSA sent in LS Range is from 0 requests. to 4294967295. InputLSAUpdates Number of LSA updates Range is from 0 received. to 4294967295. Cisco IOS XR System Management Configuration Guide SMR-187 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 Attributes and Values (continued) Entity Attributes Description Values InputLSAUpdatesLSA Number of LSA received in Range is from 0 LSA updates. to 4294967295. OutputLSAUpdates Number of LSA updates sent. Range is from 0 to 4294967295. OutputLSAUpdatesLSA Number of LSA sent in LSA Range is from 0 updates. to 4294967295. InputLSAAcks Number of LSA Range is from 0 acknowledgements received. to 4294967295. InputLSAAcksLSA Number of LSA received in Range is from 0 LSA acknowledgements. to 4294967295. OutputLSAAcks Number of LSA Range is from 0 acknowledgements sent to 4294967295. OutputLSAAcksLSA Number of LSA sent in LSA Range is from 0 acknowledgements. to 4294967295. ChecksumErrors Number of packets received Range is from 0 with checksum errors. to 4294967295. ospf v3protocol InputPackets Total number of packets Range is from 0 received. to 4294967295. OutputPackets Total number of packets sent. Range is from 0 to 4294967295. InputHelloPackets Number of Hello packets Range is from 0 received. to 4294967295. OutputHelloPackets Number of Hello packets sent. Range is from 0 to 4294967295. InputDBDs Number of DBD packets Range is from 0 received. to 4294967295. InputDBDsLSA Number of LSA received in Range is from 0 DBD packets. to 4294967295. OutputDBDs Number of DBD packets sent. Range is from 0 to 4294967295. OutputDBDsLSA Number of LSA sent in DBD Range is from 0 packets. to 4294967295. InputLSRequests Number of LS requests Range is from 0 received. to 4294967295. InputLSRequestsLSA Number of LSA received in LS Range is from 0 requests. to 4294967295. OutputLSRequests Number of LS requests sent. Range is from 0 to 4294967295. OutputLSRequestsLSA Number of LSA sent in LS Range is from 0 requests. to 4294967295. InputLSAUpdates Number of LSA updates Range is from 0 received. to 4294967295. Cisco IOS XR System Management Configuration Guide SMR-188 Implementing Performance Management on Cisco IOS XR Software Information About Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 28 Attributes and Values (continued) Entity Attributes Description Values InputLSRequestsLSA Number of LSA received in LS Range is from 0 requests. to 4294967295. OutputLSAUpdates Number of LSA updates sent. Range is from 0 to 4294967295. OutputLSAUpdatesLSA Number of LSA sent in LSA Range is from 0 updates. to 4294967295. InputLSAAcks Number of LSA Range is from 0 acknowledgements received. to 4294967295. InputLSAAcksLSA Number of LSA received in Range is from 0 LSA acknowledgements. to 4294967295. OutputLSAAcks Number of LSA Range is from 0 acknowledgements sent to 4294967295. OutputLSAAcksLSA Number of LSA sent in LSA Range is from 0 acknowledgements. to 4294967295. Guidelines for Enabling and Disabling PM Threshold Monitoring Templates When enabling PM threshold monitoring templates, follow these guidelines: • Use the performance-mgmt apply thresholds command to enable a PM threshold monitoring template. • Once a template has been enabled, the threshold monitoring continues until the template is disabled with the no form of the performance-mgmt apply thresholds command. • Only one PM threshold template for an entity can be enabled at a time. • You must specify either a location with the location keyword and node-id argument or with location all keywords when enabling or disabling a PM threshold monitoring template for the following entities: – Node CPU – Node memory – Node process The location keyword and node-id argument enables or disables PM statistic collections for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keywords enable or disable the PM statistic collections for all nodes. • Because only one PM threshold monitoring template for an entity at any given time, you are not required to specify the template name with the default keyword or template keyword and template-name argument when disabling a PM statistics collection. Cisco IOS XR System Management Configuration Guide SMR-189 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information How to Implement Performance Management on Cisco IOS XR Software This section contains the following procedures: • Configuring an External TFTP Server for PM Statistic Collections, page 190 (required) • Creating PM Statistics Collection Templates, page 192 (required) • Enabling and Disabling PM Statistics Collection Templates, page 193 (required) • Enabling PM Entity Instance Monitoring, page 196 (required) • Creating PM Threshold Monitoring Templates, page 198 (required) • Enabling and Disabling PM Threshold Monitoring Templates, page 199 (required) Configuring an External TFTP Server for PM Statistic Collections This task explains how to configure an external TFTP server for PM statistic collections. Note Perform this task before enabling a PM statistics collection template for PM statistic collections. For more information about enabling a PM statistics collection templates, see the “Enabling and Disabling PM Statistics Collection Templates” task. Prerequisites You must have access to and connectivity with a TFTP server before performing this task. SUMMARY STEPS 1. configure 2. performance-mgmt resources tftp-server ip-address directory dir-name 3. end or commit Cisco IOS XR System Management Configuration Guide SMR-190 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt resources tftp-server Sets the IP address and the directory path for PM data ip-address directory dir-name collection. • Include the entire directory path name for the dir-name Example: argument. RP/0/RP0/CPU0:router(config)# performance-mgmt resources tftp-server 10.3.40.161 directory Note Files copied to the TFTP server contain a timestamp mypmdata/datafiles in their name, which makes them unique. For that reason the TFTP server used should support creation of files as data is transferred, without requiring users to manually create them at the TFTP server host in advance. Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration – session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-191 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Creating PM Statistics Collection Templates This task explains how to create a PM statistics collection template. SUMMARY STEPS 1. configure 2. performance-mgmt statistics entity {default | template name} [sample-size size] [sample-interval minutes] 3. end or commit DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt statistics entity {default | Creates a PM statistics collection template for the specified template template-name} [sample-size size] entity. [sample-interval minutes] • Use the entity argument to specify the entity for which you want to create a PM statistics collection template. Example: RP/0/RP0/CPU0:router(config)# performance-mgmt • Use the default keyword to apply the default template statistics interface data-rates default to the PM statistics template for the specified entity. The default template contains a default sample interval of 10 minutes and a default sample size of 5 sampling operations. • Use the template keyword and template-name argument to designate a unique name for a template. • The sample-size keyword and size argument set the number of sampling operations to be performed before exporting the data to the TFTP server. The range is from 1 to 60 samples. The default is 5 samples. • The sample-interval keyword and minutes argument set the frequency of the sampling operations performed during the sampling cycle. The range is from 1 to 60 minutes. The default is 10 minutes. Note For more information about creating PM collection templates, refer to the “Guidelines for Creating PM Statistics Collection Templates” section. Cisco IOS XR System Management Configuration Guide SMR-192 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. What to Do Next After creating a PM statistics collection template, you must enable the template to start the PM statistics collection. Refer to the “Enabling and Disabling PM Statistics Collection Templates” task for more information about enabling PM statistics collection templates. Enabling and Disabling PM Statistics Collection Templates This task explains how to enable and disable PM statistics collection templates. Prerequisites You must configure a TFTP server resource and create a PM statistics collection template before performing this task. Refer to the “Configuring an External TFTP Server for PM Statistic Collections” and “Creating PM Statistics Collection Templates” tasks for more information. SUMMARY STEPS 1. configure 2. performance-mgmt apply statistics entity [location {all | node-id}] {template-name | default} or no performance-mgmt apply statistics entity [location {all | node-id}] 3. end or commit Cisco IOS XR System Management Configuration Guide SMR-193 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt apply statistics entity Enables or disables a PM statistics collection template. [location {all | node-id}] {template-name | default} • Only one PM statistics collection template for a given or entity can be enabled at a time. no performance-mgmt apply statistics entity • You must specify either a location with the location [location {all | node-id}] keyword and node-id argument or the location all keywords when enabling a PM statistic collections for Example: the following entities: RP/0/RP0/CPU0:router(config)# performance-mgmt – Node CPU apply statistics mpls ldp default or – Node memory RP/0/RP0/CPU0:router(config)# no – Node process performance-mgmt apply statistics mpls ldp The location keyword with the node-id argument enables PM statistic collections for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keywords enable a PM statistic collection for all nodes. • Because only one PM statistics collection can be enabled for any given entity at any given time, you are not required to specify the template name with the default keyword or template keyword and template-name argument when disabling a PM statistics collection. Note Data collection will begin one sampling cycle after you enable the PM statistics collection template with the performance-mgmt apply statistics command. Cisco IOS XR System Management Configuration Guide SMR-194 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action (continued) Purpose (continued) • When a template has been enabled, the sampling and export cycles continue until the template is disabled with the no form of the performance-mgmt apply statistics command. • You must specify either a location with the location keyword and node-id argument or the location all keywords when disabling a PM statistic collections for the following entities: – Node CPU – Node memory – Node process The location keyword with the node-id argument disables PM statistic collections for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keyword disables the PM statistic collections for all nodes. • Since only one PM statistics collection can be enabled for any given entity at any given time, you are not required to specify the template name with the default keyword or template keyword and template-name argument when disabling a PM statistics collection Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-195 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Enabling PM Entity Instance Monitoring This task explains how to enable entity instance monitoring. Prerequisites You must create PM statistics collection template for an entity before performing this task. SUMMARY STEPS 1. configure 2. performance-mgmt apply monitor entity instance {template-name | default} 3. end or commit Cisco IOS XR System Management Configuration Guide SMR-196 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt apply monitor entity instance Enables entity instance monitoring for the specified {template-name | default} instance. • Use the entity and instance arguments to specify the Example: name of the entity and the instance to be monitored, RP/0/RP0/CPU0:router(config)# performance-mgmt respectively. apply monitor node cpu 0/RP1/CPU0 default • Use either the default keyword or the template-name argument to specify the template associated with the entity instance to be monitored. Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-197 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Creating PM Threshold Monitoring Templates This task explains how to create a PM threshold monitoring template. SUMMARY STEPS 1. configure 2. performance-mgmt thresholds entity {default | template name} attribute operation value [value2] [percent] [rearm {toggle | window window-size}] 3. end or commit DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt thresholds entity template Creates a PM threshold monitoring template. name attribute operation value [value2] [percent] [rearm {toggle | window window-size}] Note For more detailed information about creating PM threshold monitoring templates, see the “Guidelines for Creating PM Threshold Monitoring Templates” Example: section. RP/0/RP0/CPU0:router(config)# performance-mgmt thresholds node cpu template cpu_thresh1 RP/0/RP0/CPU0:router(config-threshold-bgp)# AverageCPUUsed GT 25 percent Step 3 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-198 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information What to Do Next After creating a PM threshold monitoring template, you must enable the template to start PM threshold monitoring. Refer to the “Enabling and Disabling PM Threshold Monitoring Templates” task for more information about enabling PM statistics threshold monitoring templates. Enabling and Disabling PM Threshold Monitoring Templates This task explains how to enable and disable PM threshold monitoring templates. Prerequisites You must create a PM threshold template before performing this task. Refer to “Creating PM Threshold Monitoring Templates” tasks for more information. SUMMARY STEPS 1. configure 2. performance-mgmt apply thresholds entity [location {all | node-id}] {template-name | default} or no performance-mgmt apply thresholds entity [location {all | node-id}] 3. end or commit Cisco IOS XR System Management Configuration Guide SMR-199 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 performance-mgmt apply thresholds entity Enables or disables PM threshold monitoring templates for [location {all | node-id}] {template-name | the specified template. default} or • Only one PM threshold monitoring template for an no performance-mgmt apply thresholds entity entity can be enabled at a time. [location {all | node-id}] • You must specify either a location with the location keyword and node-id argument or the location all keywords when enabling a PM threshold monitoring template for the following entities: – Node CPU – Node memory – Node process The location keyword with the node-id argument enables the PM threshold monitoring template for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keywords enable the PM threshold monitoring template for all nodes. Cisco IOS XR System Management Configuration Guide SMR-200 Implementing Performance Management on Cisco IOS XR Software How to Implement Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action (continued) Purpose (continued) Step 3 Example: • Because only one PM threshold monitoring template RP/0/RP0/CPU0:router(config)# performance-mgmt for an entity at any given time, you are not required to enable thresholds node cpu location all template20 specify the template name with the default keyword or or template keyword and template-name argument when disabling a PM statistics collection. RP/0/RP0/CPU0:router(config)# no performance-mgmt apply thresholds node cpu • Once a template has been enabled, threshold location all monitoring continues until the template is disabled with the no form of the performance-mgmt apply thresholds command. • You must specify either a location with the location keyword and node-id argument or the location all keywords when disabling a PM threshold monitoring template for the following entities: – Node CPU – Node memory – Node process The location keyword with the node-id argument disables the PM threshold monitoring template for the specified node. The node-id argument is expressed in the rack/slot/module notation. The location all keywords disable the PM threshold monitoring template for all nodes. • Because only one PM threshold monitoring template for an entity can be enabled at a time, you are not required to specify the template name with default keyword or template-name argument when disabling a PM statistics collection. Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-201 Implementing Performance Management on Cisco IOS XR Software Configuration Examples for Implementing Performance Management on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuration Examples for Implementing Performance Management on Cisco IOS XR Software This section provides the following configuration examples: • Creating and Enabling PM Statistics Collection Templates: Example, page 202 • Creating and Enabling PM Threshold Monitoring Templates: Example, page 202 Creating and Enabling PM Statistics Collection Templates: Example The following example shows how to configure the TFTP server resource, and how to create and enable a PM statistics collection templates. In this example, the following PM template collection templates are created and enabled: • A template named template1 with a sample size of 10 and a sample interval of 5 for the interface generic counters entity. • A template named template2 with a sample size of 30 and a sample interval of 2 for the node memory entity. The template is enabled globally. • A template name template3 with a sample size of 10 and a sample interval of 5 for the node process entity. The template is enabled for node 0/0/CPU0. performance-mgmt resources tftp-server 10.30.62.154 directory pm/pm_data/pmtest performance-mgmt statistics interface generic-counters template template1 sample-size 10 sample-interval 5 ! performance-mgmt statistics node memory template template2 sample-size 30 sample-interval 2 ! performance-mgmt statistics node process template template3 sample-size 10 sample-interval 5 ! performance-mgmt apply statistics interface generic-counters template1 performance-mgmt apply statistics node memory global template2 performance-mgmt apply statistics node process 0/0/CPU0 template3 Creating and Enabling PM Threshold Monitoring Templates: Example The following example shows how to create and enable a PM threshold monitoring template. In this example, a PM threshold template is created for the AverageCpuUsed attribute of the node CPU entity. The threshold condition in this PM threshold condition monitors the AverageCpuUsed attribute to determine if average CPU use is greater than 75 percent. The sample interval for the template is set to 5 minutes, and the template is enabled globally. performance-mgmt thresholds node cpu template template20 AverageCpuUsed GT 75 sample-interval 5 ! performance-mgmt apply thresholds node cpu global template20 Cisco IOS XR System Management Configuration Guide SMR-202 Implementing Performance Management on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Additional References The following sections provide references related to implementing performance management on Cisco IOS XR software. Related Documents Related Topic Document Title Cisco IOS XR performance management commands Performance Management Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Cisco IOS XR XML API material Cisco IOS XR XML API Guide, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2 Standards Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature. MIBs MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml Cisco IOS XR System Management Configuration Guide SMR-203 Implementing Performance Management on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature. Technical Assistance Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. Cisco IOS XR System Management Configuration Guide SMR-204 R3.3 Beta Draft—Cisco Confidential Information Process Placement on Cisco IOS XR Software Beta Draft Cisco Confidential Information This module describes conceptual information and configuration tasks for process placement on a multishelf system. The Cisco IOS XR Process Placement feature uses a mechanism (called PlaceD) that maps application processes to distributed Route Processors (DRPs) that exist on multishelf systems. PlaceD balances process load and optimizes resource utilization. This feature allows you to specify the process placement for applications and override the default placement policies (predetermined placements) that are available on your multishelf system at startup time. Note For complete descriptions of the commands listed in this module, see the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of performing a configuration task, search online in the Cisco IOS XR software master command index for Release 3.3. Feature History for Configuring Cisco IOS XR Process Placement Release Modification Release 3.3 The feature was introduced. Contents • Prerequisites for Configuring Cisco IOS XR Process Placement, page 206 • Restrictions for Cisco IOS XR Process Placement, page 206 • Information About Cisco IOS XR Process Placement, page 206 • How to Configure Cisco IOS XR Process Placement, page 211 • Additional References, page 220 Cisco IOS XR System Management Configuration Guide SMR-205 Process Placement on Cisco IOS XR Software Prerequisites for Configuring Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Configuring Cisco IOS XR Process Placement Before configuring process placement on your multishelf system, ensure that the following prerequisites are met: • You must install and activate the Package Installation Envelope (PIE) for the manageability software. • For detailed information about optional PIE installation, refer to the Cisco IOS XR Getting Started Guide, Release 3.3. • You must be in a user group associated with a task group that includes the proper task IDs for process placement commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide, Release 3.3. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.3. Restrictions for Cisco IOS XR Process Placement • Only processes that are identified in the Cisco IOS XR software as placeable can be controlled through process placement configuration. Nonplaceable processes are not affected by placement policy. To learn the processes that are placeable, issue the show placement program all command. Information About Cisco IOS XR Process Placement To configure process placement policies, you need to understand the following concepts: • What Is a Process?, page 206 • What Is Process Placement?, page 207 • Default Placement Policy, page 207 • Reasons to Change the Default Process Placement, page 207 • Reoptimizing Process Placements, page 208 • Reconfiguring Process Placements, page 208 – Recommended Guidelines for Process Placement, page 208 – Process Placement Based on Memory Consumption, page 209 – Changing Process Affinities, page 209 – Hierarchical Placement Policy, page 210 What Is a Process? To achieve high availability and performance, the Cisco IOS XR software is built on a modular system of processes. Each process provides specific functionality for the system and runs in a protected memory space to ensure that problems with one process cannot impact the entire system. Multiple instances of a process can run on a single node, and multiple threads of execution can run on each process instance. Cisco IOS XR System Management Configuration Guide SMR-206 Process Placement on Cisco IOS XR Software Information About Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Under normal operating conditions, processes are managed automatically by the Cisco IOS XR software. Processes are started, stopped, or restarted as required by the running configuration of the router. In addition, processes are checkpointed to optimize performance during process restart and automatic switchover. What Is Process Placement? Process placement is the assignment of placeable processes to specific locations on a multishelf system. Placeable processes for Release 3.3 are identified as all routing processes, such as Open Shortest Path First Protocol (OSPF), Border Gateway Protocol (BGP), and multicast routing. Default Placement Policy In a new system, processes are placed according to the available hardware and the size of the system. Processes are distributed evenly among the available RP and DRP nodes and node pairs. Note The default process policy that is shipped on the system upon startup is suitable for general purposes. While customizing is possible, there is no requirement to change the process placement. If you believe the a change is required, you should work closely with Cisco personnel to ensure that the impact to your system is contained to just an instance of a process to avoid any undesirable results. The default placement policy is specified in this way: • Initial placement of processes happens in round-robin fashion, because at system startup all processes use one megabyte of memory. • The location type for process placement is a node pair (active and standby nodes). • The process does not move automatically (current = 100) unless a solo node fails and the process needs to be started on a different node. • When a new node pair is added, the following rules apply: – The currently running processes are not automatically moved to the new cards. – The general preference is for new processes (such as a new ISIS instance) to start on the new node pair, which contains the most available CPU and memory resources in the system. – Other affinity settings may override the general preference. For example, if the ISIS process has a strong affinity to run on the same node where ipv4_io is running, then ISIS would be started on that node, and not the new node-pair. Reasons to Change the Default Process Placement Although the default process policy that is shipped on the system upon startup is suitable for general purposes, changes to the router configuration can result in the need for processes to be rebalanced among the available CPU and memory resources. When a system is initially booted, the system assumes that all processes use the same amount of memory, thereby treating each process as equivalent. As the configuration grows, however, the CPU load and memory requirements of some application processes increase. Centralized applications may need a larger portion of the RP and DRP resources, or distributed applications may require additional instances of processes to be started on new DRPs. Cisco IOS XR System Management Configuration Guide SMR-207 Process Placement on Cisco IOS XR Software Information About Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information In addition, when a new RP or DRP is added to a system, only new processes or process or process instances are added to the node. This could result in some processes with too few resources, while the newer RP and DRP cards are under-utilized. Therefore, as the software configuration changes, or hardware is added, it may become necessary to rebalance processes among the available RPs and DRPs in a multishelf system. Reoptimizing Process Placements The easiest and most reliable method for users to redistribute processes in a multishelf system is using the command placement reoptimize in EXEC mode. During router operation, the actual resource usage of each process is collected and compared to the router configuration and network topology. An ideal configuration for process placement is created and updated in real time. This up-to-date configuration can be viewed and implemented at any time with the EXEC mode command placement reoptimize. Before the changes are made, the system displays a summary of the predicted changes. You can either accept the changes or cancel the operation. See Reomptimizing Process Placement, page 211 for detailed instructions. Reconfiguring Process Placements You can also change the process placement affinities, or preferences, to override the default policies. For example, you may learn that some placeable processes may perform better on the dLRSC of a node pair (active RP and standby) to fulfill high availability obligations or that some processes may do better on the standby RP. Other processes might benefit from collocation or far apart from each other. Note Consult with your technical support representative before changing the default process placement configuration. Incorrect configurations can cause system error, poor performance or downtime. • Recommended Guidelines for Process Placement, page 208 • Process Placement Based on Memory Consumption, page 209 • Changing Process Affinities, page 209 Recommended Guidelines for Process Placement The following are a few recommended guidelines for changes to the process placement configuration: • Generally, the process placement feature functions well upon system startup so fine tuning is seldom required. • Use the EXEC mode command placement reoptimize, as described in the “Reoptimizing Process Placements” section on page 208. • Keep process placement updates to a minimum and always consult technical support personnel before implementation. • Ensure that affinity values are below 100 points. • Location set affinities are not recommended because the command hardcodes placement to a node or node pair and disallows automatic process placement. Cisco IOS XR System Management Configuration Guide SMR-208 Process Placement on Cisco IOS XR Software Information About Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Process Placement Based on Memory Consumption You can change process placements based on memory use of processes in a multishelf system. Memory use is expressed in terms of the memory “footprint” of the placeable process. The system attempts to spread the load among the nodes without exceeding their memory capacity. In addition, the system computes the affinity values to determine the best placement. For Release 3.3, the software assumes that every placeable process uses one megabyte of memory. For detailed instructions, refer to Setting Memory Consumption Thresholds, page 212. Changing Process Affinities Process placement can also be controlled by changing the affinities, or preferences, of a process or process group. The following types of process affinities are operator configurable: • affinity location set • affinity location type • affinity program • affinity self affinity location set This affinity assigns a process to run on a specific node pair. A node pair is either an active and standby pair of nodes [hosted on route processors (RPs) or distributed RPs], or a single active node on an RP or DRP that does not have a standby. This affinity overrides the placement process logic for determining optimal placement for processes. It forces a process to remain in or away from a location on the router regardless of what might occur in the system. This command also makes the configuration more specific to a router and less general. affinity location type This affinity assigns a process to a particular location. The default policy is that the location type be a node pair (active and standby nodes), and that the process does not move automatically (current = 100) unless a solo node fails and the process needs to be started on a different node. You can configure the placement policy to allow certain processes to stay where they are (current) or move just by indicating so through the various affinity choices. The higher the positive value of an affinity, the stronger the requirement that the process run at a location, and so on. A low or zero point value indicates a weaker requirement (or no preference) that a process run at a location. affinity program This affinity collocates processes or keeps them apart. You would want to use this affinity because you have learned that certain processes perform better when they are running together on the same node (attract); or on different nodes, apart from each other (repulse). affinity self This affinity adjusts placement decisions when multiple instances of a process are started. An attract (positive) affinity indicates a preference to have all instances of a process run on the same node, while a repulse (negative) affinity indicates a preference to have each instance of a process run on different nodes. Cisco IOS XR System Management Configuration Guide SMR-209 Process Placement on Cisco IOS XR Software Information About Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Hierarchical Placement Policy When you configure placement policies, you must remember that affinities are applied to the software in a hierarchical way. Affinities applied to process instances take precedence over affinities applied to a process class. In the following example, all OSPF instances are placed on the primary RP, but OSPF instance 10 are placed on a node pair: program placement ospf affinity location-type primary attract 200 program placement ospf 10 affinity location-type paired attract 200 Class affinities take precedence over default process affinities. In the following example, all OSPF instances are placed on a single node. This placement overrides the default policy that places processes on node pairs. program placement ospf affinity location-type paired repulse 200 Cisco IOS XR System Management Configuration Guide SMR-210 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information How to Configure Cisco IOS XR Process Placement This section contains instructions for the following tasks: • Reomptimizing Process Placement, page 211 (required) • Setting Memory Consumption Thresholds, page 212 (required) • Creating a Location Set Affinity, page 213 (required) • Creating a Location Type Affinity, page 215 (required) • Creating a Program Affinity, page 217 (required) • Creating a Self Affinity, page 218 (required Reomptimizing Process Placement This task reoptimizes the placeable processes among the available RP and DRP nodes according to memory and CPU usage. SUMMARY STEPS 1. placement reoptimize {{maximum | threshold} value} 2. yes or no Cisco IOS XR System Management Configuration Guide SMR-211 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 placement reoptimize Displays the predicted changes of the optimization. Example: RP/0/RP0/CPU0:router# placement reoptimize Predicted changes to the placement: bpm 0/RP0/CPU0 (0/RP1/CPU0) --> 0/2/CPU0 (0/3/CPU0) bgp instance 0 0/RP0/CPU0 (0/RP1/CPU0) --> 0/2/CPU0 (0/3/CPU0) ipv4_rib 0/RP0/CPU0 (0/RP1/CPU0) --> 0/2/CPU0 (0/3/CPU0) ipv4_arm 0/RP0/CPU0 (0/RP1/CPU0) --> 0/2/CPU0 (0/3/CPU0) rcp_fs 0/RP0/CPU0 (0/RP1/CPU0) --> 0/2/CPU0 (0/3/CPU0) Continue? [yes/no] Step 2 yes Accespt or rejects the changes. or no Example: RP/0/RP0/CPU0:router# yes RP/0/RP0/CPU0:Nov 12 1:1:1.1 : placed[170]: %PLACED_PLACE-6- REOP_START: Re-optimization of the placement requested. You will be notified on completion. RP/0/RP0/CPU0:Nov 12 1:1:1.1 : placed[254]: %OS-PLACED_PLACE-6-REOP_COMPLETE : Re-optimization of the placement complete. Use 'show placement' to view the ne w placement Setting Memory Consumption Thresholds SUMMARY STEPS 1. show placement policy global 2. configure 3. placement memory {{maximum | threshold} value} 4. end or commit Cisco IOS XR System Management Configuration Guide SMR-212 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 show placement policy global Displays the current memory settings. Example: RP/0/RP0/CPU0:router# show placement policy global Step 2 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 3 placement memory {{maximum | threshold} value} Use the placement memory command with the maximum value keyword and argument to set the maximum percentage of memory that can be used on a node (based on Example: RP/0/RP0/CPU0:router(config)# placement memory the estimated memory usage of the processes). maximum 80 Use the placement memory command with the threshold value keyword and argument to define the memory load level to trigger migration. The system attempts to balance all nodes at or below the threshold memory percentage. In other words, the system does not place a process on a node that has exceeded the threshold value, unless all other nodes have also reached their thresholds (or unless some other large affinity overrides this consideration). Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting (yes/no/cancel)? RP/0/RP0/CPU0:router(config-place)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-place)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Creating a Location Set Affinity This task sets the affinity of a placement program (process) to or from node pairs. Cisco IOS XR System Management Configuration Guide SMR-213 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information SUMMARY STEPS 1. configure 2. placement program program {instance instance | default} 3. affinity location-set node-id1 {node-id2 | {attract | repulse} strength} | default | none} 4. end or commit 5. show placement location {node-id | all} 6. show placement program {program | all} DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 placement program program {instance instance | Enters placement program configuration mode. default} Example: RP/0/RP0/CPU0:router(config)# placement program ospf Step 3 affinity location-set node-id1 [node-id2] Sets the affinity of a placement program (process) to or {attract | repulse} strength} | default | none} from node pairs. To specify multiple nodes, enter the value of the node-id Example: argument for each node. You can specify up to 5 nodes. RP/0/RP0/CPU0:router(config-place)# affinity location-set 0/1/cpu0 0/1/cpu1 attract 200 Cisco IOS XR System Management Configuration Guide SMR-214 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting (yes/no/cancel)? RP/0/RP0/CPU0:router(config-place)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-place)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 5 show placement location {node-id | all} Displays the location of a placement process. Example: RP/0/RP0/CPU0:router# show placement location all Step 6 show placement program {program | all} Displays the operational state for each placement program. Example: RP/0/RP0/CPU0:router# show placement program ospf Creating a Location Type Affinity This task sets affinity of a placement program (process) to or from a location type. SUMMARY STEPS 1. configure 2. placement program program {instance instance | default} 3. affinity location-type {current | paired | primary} {{{attract | repulse} strength} | default | none} 4. end or commit 5. show placement location {node-id | all} 6. show placement program {program | all} Cisco IOS XR System Management Configuration Guide SMR-215 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 7 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 8 placement program program {instance instance | Enters placement program configuration mode. default} Example: RP/0/RP0/CPU0:router(config)# placement program bgp Step 9 affinity location-type {current | paired | Sets the affinity of a placement program (process) to or primary} {{{attract | repulse} strength} | from a location type. default | none} • This example shows how to place Border Gateway Protocol (BGP) in the most optimal location at run time Example: when load balancing is required. BGP will not be tied RP/0/RP0/CPU0:router(config-place)# affinity to a node pair but move when necessary. location-type current attract 10 Step 10 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting (yes/no/cancel)? RP/0/RP0/CPU0:router(config-place)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-place)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-216 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 11 show placement location {node-id | all} Displays the location of a placement process. Example: RP/0/RP0/CPU0:router# show placement location all Step 12 show placement program {program | all} Displays the operational state for each placement program. Example: RP/0/RP0/CPU0:router# show placement program bgp Creating a Program Affinity This task sets the affinity of a placement program (process) to or from another program. SUMMARY STEPS 1. configure 2. placement program program {instance instance | default} 3. affinity existence [attract attract-strength | default | none] 4. end or commit 5. show placement location {node-id | all} 6. show placement program {program | all} DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 placement program program {instance instance | Enters placement program configuration mode. default} Example: RP/0/RP0/CPU0:router(config)# placement program ipv4_rib Cisco IOS XR System Management Configuration Guide SMR-217 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 3 affinity program {program | default {{attract | Sets the affinity of a placement program (process) to or repulse} strength} | default | none} from another program. • This example shows how to keep IPv4 and IPv6 Example: Routing Information Bases (RIBs) apart. RP/0/RP0/CPU0:router(config-place)# affinity program ipv6_rib repulse 200 Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting (yes/no/cancel)? RP/0/RP0/CPU0:router(config-place)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-place)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 5 show placement location {node-id | all} Displays the location of a placement process. Example: RP/0/RP0/CPU0:router# show placement location all Step 6 show placement program {program | all} Displays the operational state for each placement program. Example: RP/0/RP0/CPU0:router# show placement program all Creating a Self Affinity This task sets the affinity of a placement program (process) to or from one of its own instances. SUMMARY STEPS 1. configure 2. placement program program {instance instance | default} 3. affinity self {{attract | repulse} strength} | default | none} Cisco IOS XR System Management Configuration Guide SMR-218 Process Placement on Cisco IOS XR Software How to Configure Cisco IOS XR Process Placement R3.3 Beta Draft—Cisco Confidential Information 4. end or commit 5. show placement location {node-id | all} 6. show placement program {program | all} DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 placement program program {instance instance | Enters placement program configuration mode. default} Example: RP/0/RP0/CPU0:router(config)# placement program bgp Step 3 affinity self {{attract | repulse} strength} | Sets the affinity of a placement program (process) to or default | none} from one of its own instances. Example: RP/0/RP0/CPU0:router(config-place)# affinity self repulse 200 Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting (yes/no/cancel)? RP/0/RP0/CPU0:router(config-place)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config-place)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-219 Process Placement on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 5 show placement location {node-id | all} Displays the location of a placement process. Example: RP/0/RP0/CPU0:router# show placement location all Step 6 show placement program {program | all} Displays the operational state for each placement program. Example: RP/0/RP0/CPU0:router# show placement program bgp Additional References The following sections provide references related to Cisco IOS XR Process Placement. Related Documents Related Topic Document Title Cisco IOS XR System Management Commands • Cisco IOS XR System Management Command Reference Addendum, Release 3.3 • Cisco IOS XR System Management Command Reference, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.0 Cisco IOS XR getting started material Cisco IOS XR Getting Started Addendum for Multishelf System Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.0 Standards Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature. Cisco IOS XR System Management Configuration Guide SMR-220 Process Placement on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information MIBs MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml RFCs RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature. Technical Assistance Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. Cisco IOS XR System Management Configuration Guide SMR-221 Process Placement on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Cisco IOS XR System Management Configuration Guide SMR-222 R3.3 Beta Draft—Cisco Confidential Information Configuring Secure Domain Routers on Cisco IOS XR Software Beta Draft Cisco Confidential Information Secure Domain Routers (SDRs) are a means of dividing a single physical system into multiple logically separated routers. SDRs are isolated from each other in terms of their resources, performance, and availability. Note Secure Domain Routers (SDRs) were previously known as Logical Routers (LRs). The name was changed for release 3.3. Feature History for Configuring Secure Domain Routers on Cisco IOS XR Software Release Modification Release 3.2 This feature was supported on Cisco XR 12000 Series Routers. Release 3.3 This feature was supported on the Cisco CRS-1. The term Logical Router (LR) was changed to Secure Domain Router (SDR). Support was added for DRPs and DRP pairs on the Cisco CRS-1. Support was added for SDR-specific software package activation on the Cisco CRS-1 and Cisco XR 12000 Series Routers. Contents • Prerequisites for Configuring Secure Domain Routers, page 224 • Information About Configuring Secure Domain Routers, page 224 • How to Configure Secure Domain Routers, page 232 • Configuration Examples for Secure Domain Routers, page 257 • Additional References, page 258 Cisco IOS XR System Management Configuration Guide SMR-223 Configuring Secure Domain Routers on Cisco IOS XR Software Prerequisites for Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Configuring Secure Domain Routers Before configuring SDRs, the following conditions must be met: Initial configuration • The router must be running the Cisco IOS XR software, including a Designated System Controller (DSC). • The root-system username and password must be assigned as part of the initial configuration. • For more information on booting a router and performing initial configuration, refer to the Cisco IOS XR Getting Started Guide. Required cards for each SDR • In Cisco CRS-1 routers, an additional RP pair, DRP or DRP pair must be installed in each line card (LC) chassis to manage each SDR in the system. • In Cisco XR 12000 Series Routers, an additional RP or RP pair must be installed to manage each SDR in the system. • For additional information on DRPs, refer to Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis System Description. For instructions on installing DRPs, refer to Installing the Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis. Task ID requirements • You must be in a user group associated with a task group that includes the proper task IDs for SDR commands. • Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. Software Version Requirements for the Cisco XR 12000 Series Router • Multiple SDRs, including non-owner SDRs, are supported on Cisco XR 12000 Series Router running Cisco IOS XR Software Release 3.2 or higher. Software Version Requirements for the Cisco CRS-1 • Cisco IOS XR Software Releases 2.0, 3.0, and 3.2 support only one owner SDR on the Cisco CRS-1. Multiple (non-owner) SDRs are not supported in these releases. The owner SDR cannot be added or removed from the configuration. • Multiple SDRs, including non-owner SDRs, are supported on Cisco CRS-1 running Cisco IOS XR Software Release 3.3 or higher. Information About Configuring Secure Domain Routers Review the following topics before configuring secure domain routers: • What Is a Secure Domain Router?, page 225 • Owner SDR and Admin Configuration Mode, page 225 • Non-owner SDRs, page 226 • SDR Access Privileges, page 226 – Root-System Users, page 226 Cisco IOS XR System Management Configuration Guide SMR-224 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information – Root-SDR Users, page 227 – Other SDR Users, page 227 • Designated Secure Domain Router System Controller (DSDRSC), page 227 – Using a RP Pair as the DSDRSC in a Cisco CRS-1 Router, page 228 – Using a DRP or DRP Pair as the DSDRSC in a Cisco CRS-1 Router, page 228 • High Availability Implications, page 230 • Cisco IOS XR Software Installation, page 231 • Caveats, page 231 What Is a Secure Domain Router? Cisco routers running Cisco IOS XR software can be partitioned into multiple, independent routers known as secure domain routers (SDRs). SDRs are a means of dividing a single physical system into multiple logically separated routers. SDRs perform routing functions the same as a physical router, but share resources with the rest of the system. For example, the software, configurations, protocols and routing tables assigned to an SDR belong to that SDR only, but other functions, such as chassis-control and switch fabric are shared with the rest of the system. Owner SDR and Admin Configuration Mode The owner SDR is created at system startup and cannot be removed. This owner SDR performs system-wide functions, including the creation of additional non-owner SDRs. You cannot create the owner SDR, because it always exists, nor can you completely remove the owner SDR, because it is necessary to manage the router. By default, all nodes in the system belong to the owner SDR. The owner SDR also provides access to the Admin EXEC and Admin configuration modes. Only users with root-system privileges can access the Admin modes by logging in to the primary Route Processor for the owner SDR (called the Designated Shelf Controller, or DSC). Admin modes are used for the following purposes: • Create and remove additional non-owner SDRs • Assign nodes to the non-owner SDRs • View the configured SDRs in the system. • View and manage system-wide resources and logs. See the “SDR Access Privileges” section on page 226 for more information. Note The Admin modes cannot be used to configure the features within a non-owner SDR, or view the router configuration for a non-owner SDR. After the SDR is created, users must log into the non-owner SDR directly to change the local configuration and manage the SDR. See Non-owner SDRs for more information. Cisco IOS XR System Management Configuration Guide SMR-225 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Non-owner SDRs To create a new, non-owner SDR, the root-system user enters admin configuration mode, defines a new SDR name, and assigns a set of cards to that SDR. Only a user with root-system privileges can access the commands in Admin configuration mode. Therefore, users without root-system privileges cannot create SDRs or assign cards to the SDRs. Once a non-owner SDR is created, the users configured on the non-owner SDR can log in and manage the router. The configuration for each non-owner SDR is seperate from the owner SDR and can only be accessed by logging in to the non-owner SDR. See the following section SDR Access Privileges for more information. Note See Software Version Requirements for the Cisco XR 12000 Series Router, page 224 for information regarding support for non-owner SDRs in the Cisco IOS XR software releases 2.0, 3.0, 3.2 and 3.3. SDR Access Privileges Each SDR in a router has a separate AAA configuration that defines usernames, passwords, and associated privileges. • Only users with root-system privileges can access the admin EXEC and Admin configuration modes. See Root-System Users, page 226 for more information. • Users with root-sdr privileges can only access the non-owner SDR where that username was created. See Root-SDR Users, page 227 for more information. • Users with other access privileges can access features according to their assigned privileges for a specific SDR. See Other SDR Users, page 227 for more information. For more information about AAA policies, refer to the “Configuring AAA Services on Cisco IOS XR Software” module of the Cisco IOS XR System Security Configuration Guide. Root-System Users Users with root-system privileges have access to system-wide features and resources, including the ability to create and remove secure domain routers. The root-system user is created during the initial boot and configuration of the router. The root-system user has the following privileges: • Access to Admin EXEC and Admin configuration commands. • Ability to create and delete non-owner SDRs. • Ability to assign nodes (RPs, DRPs, and LCs) to SDRs. • Ability to create other users with similar or lower privileges. • Complete authority over the chassis. • Ability to log in to non-owner SDRs using admin plane authentication. A root-system user can log in to a non-owner SDR, regardless of the configuration set by the root-sdr user. See Configuring a Username and Password for a Non-owner SDR, page 251 • Ability to install and activate software packages for all SDRs or for a specific SDR. • The following admin plane events appear on the owner SDR logging system only: Cisco IOS XR System Management Configuration Guide SMR-226 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information – Software installation operations and events. – System card boot operations, such as card booting notifications and errors, heartbeat missed notifications, and card reloads. – Card alpha-numeric display changes. – Environment monitoring events and alarms. – Fabric control events. – Upgrade progress information. Root-SDR Users Users with root-sdr privileges can log in to the non-owner SDR only and perform configuration tasks that are specific to that SDR. The root-sdr group has the following privileges: • Ability to configure interfaces and protocols. • Ability to create other users with similar or lower privileges on the non-owner SDR. • Ability to view the resources assigned to their particular SDR. The following restrictions apply to root-sdr users: • root-sdr users cannot enter Admin mode. • root-sdr users cannot create or remove SDRs. • root-sdr users cannot add or remove nodes from an SDR. • root-sdr users cannot create root-system users. • The highest privilege a non-owner SDR user can have is root-sdr. Other SDR Users Additional usernames and passwords can be created by the root-system or root-sdr users to provide more restricted access to the configuration and management capabilities of the owner SDR or the non-owner SDRs. Designated Secure Domain Router System Controller (DSDRSC) In a router running the Cisco IOS XR software, one Route Processor is assigned the role of Designated System Controller (DSC). The DSC provides system-wide administration and control capability, including access to the Admin EXEC and Admin configuration modes. For more information on DSCs, refer to the Cisco IOS XR Getting Started Guide. In each non-owner SDR, similar administration and control capabilities are provided by the Designated Secure Domain Router System Controller (DSDRSC). Each SDR must include a DSDRSC to operate and you must assign an RP or DRP to act as the DSDRSC. Note In the owner SDR, the DSC provides DSDRSC functionality. The following sections describe DSDRSC support: • Designated System Controller (DSC) in the Cisco CRS-1, page 228 Cisco IOS XR System Management Configuration Guide SMR-227 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information – Using a DRP or DRP Pair as the DSDRSC in a Cisco CRS-1 Router, page 228 – Using a RP Pair as the DSDRSC in a Cisco CRS-1 Router, page 228 • DSC and DSDRSCs in a Cisco XR 12000 Series Router, page 229 • Removing a DSDRSC Configuration, page 230 Designated System Controller (DSC) in the Cisco CRS-1 Cisco CRS-1 routers support the use of DRP pairs, single DRPs, or RP pairs for the DSDRSC role. Using a DRP or DRP Pair as the DSDRSC in a Cisco CRS-1 Router To create a DRP DSDRSC in a non-owner SDR, you must configure a DRP or DRP pair as the primary node for that SDR. The following guidelines apply: • DRPs are supported in the Cisco CRS-1 only. DRPs are not supported in the Cisco XR 12000 Series Routers. • Although a single DRP can be used as the DSDRSC, we recommend the use of a redundant DRP pair. • To create a DRP pair and configure it as the DSDRSC, complete the instructions in Creating SDRs in a Cisco CRS-1 Router, page 232. • DRPs cannot be used as the DSC in the owner SDR. Only RPs can be used as the DSC in the owner SDR. • DRPs cannot be assigned as the DSDRSC if an RP is present in the SDR. To assign a DRP as the DSDRSC, you must first remove any RPs from the SDR configuration, and then add the DRP or DRP pair as the primary node. After the DRP is assigned as the DSDRSC, the RPs can be added to the SDR. See How to Configure Secure Domain Routers, page 232 for more information. Note DRPs can also be used to provide additional processing capacity in a Cisco CRS-1 router. For additional information on DRPs, refer to Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis System Description. For instructions on installing DRPs, refer to Installing the Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis. For information on using DRPs for additional processing capacity, see the “Process Placement on Cisco IOS XR Software” module in the Cisco IOS XR System Management Configuration Guide. Using a RP Pair as the DSDRSC in a Cisco CRS-1 Router In a CRS-1 Series router, RP pairs can be used as the DSDRSC in non-owner SDRs. Single RPs cannot be used as the DSDRSC. Note Although an RP pair can be used as the DSDRSC in non-owner SDRs, we recommend the use of a redundant DRP pair. Cisco IOS XR System Management Configuration Guide SMR-228 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information RPs in the Owner SDR By default, the primary RP of the owner SDR is assigned the DSC role at system startup. The DSC is also the DSDRSC for the owner SDR. The RP pair for the owner SDR cannot be assigned to non-owner SDRs. For instructions to bring up a router for the first time and perform initial configuration, refer to the Cisco IOS XR Getting Started Guide. Redundant RPs in a non-owner SDR Redundant RPs in a CRS-1 Series router are installed in slots RP0 and RP1 of each line card chassis. To assign an RP pair as the DSDRSC, complete the instructions in the “How to Configure Secure Domain Routers” section on page 232. DSC and DSDRSCs in a Cisco XR 12000 Series Router In a Cisco XR 12000 Series Router, you can use a single RP or a redundant RP pair as the DSDRSC for each SDR. Redundant RP pairs must be installed in adjacent redundancy slots. The adjacent redundancy slots are as follows: – Slot 0 and Slot 1 – Slot 2 and Slot 3 – Slot 4 and Slot 5 – Slot 6 and Slot 7 – Slot 8 and Slot 9 – Slot 10 and Slot 11 – Slot 12 and Slot 13 – Slot 14 and Slot 15 Review the following information for RP usage in Cisco XR 12000 Series Routers. Note Only two RPs can be operational in any SDR on a Cisco XR 12000 Series Router. Note DRPs are not supported in Cisco XR 12000 Series Routers. Designated System Controller (DSC) in a Cisco XR 12000 Series Router • The first RP to be booted with the Cisco IOS XR software in a Cisco XR 12000 Series Router will become the Designated System Controller (DSC) for the router. This DSC is also the DSDRSC for the owner SDR. The DSC (owner DSDRSC) cannot be removed from the router configuration or reassigned to another SDR. For more information on bringing up a router for the first time, refer to the Cisco IOS XR Getting Started Guide. • A second RP can be used as the standby DSC. The standby DSC is also the standby DSDRSC for the owner SDR. The RP becomes the standby DSC if the following conditional are met: – The RP is installed in an adjacent redundancy slot to the DSC. – The RP is booted with the Cisco IOS XR software. • Additional RPs can be installed in the router, but they will be non-operational until the following conditionas are met: Cisco IOS XR System Management Configuration Guide SMR-229 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information – The additional RPs are booted with the Cisco IOS XR software. – The RPs are added to a non-owner SDR configuration. Designated Secure Domain Router System Controller (DSDRSC) in a Cisco XR 12000 Series Router • Up to two RPs can be added to a non-owner SDR configuration. • The first RP running the Cisco IOS XR software that is added to the SDR configuration will become the DSDRSC. • If a second RP running the Cisco IOS XR software is installed in an adjacent redundancy slot, it will become the standby DSDRSC when added to the SDR configuration. • If two RPs running the Cisco IOS XR software are installed in adjacent redundancy slots and are added to a new SDR at the same time, they will automatically elect a DSDRSC and standby DSDRSC between them. • Any RPs added to the SDR that are not in the adjacent redundancy slot to the DSDRSC will be non-operational. Note Additional RPs that are not the DSDRSC or standby DSDRSC can be added to an SDR configuration, but they will not be operational. These additional RPs will repeatitively reset to prevent them from booting and interfering with other cards in the SDR. In addition, the DSC console will display repeatitive error messages. We recommend that you either remove RP cards or assign them to a different SDR. • Once a DSDRSC is configured for an SDR, an RP installed in the adjacent redundancy slot can only be assigned to that SDR. This is because adjacent redundancy slots form a redundancy pair that cannot be separated by SDR boundaries. For example, if the DSDRSC is installed in slot 2, an RP installed in slot 3 can only be assigned to the same SDR (as the standby DSDRSC). • RPs that are installed on slots that are not adjacent redundancy slots can be assigned to different SDRs. For example, two RPs installed in slot 0 and slot 1 can only be configured as the DSDRSC and standby DSDRSC because they are installed in adjacent redundancy slots. However, two RPs installed in slot 1 and slot 2 can be used for different SDRs because these are not adjacent redundancy slots. Removing a DSDRSC Configuration There are two ways to remove a DSDRSC from an SDR: • First remove all other nodes from the SDR configuration, and then remove the DSDRSC node. You cannot remove the DSDRSC node when other nodes are in the SDR configuration. • Removal the entire SDR. Removing an SDR name deletes the SDR and moves all nodes back to the owner SDR inventory. See Removing Nodes and SDRs, page 245 for more information. High Availability Implications The advantages of SDR partitioning include the fault isolation properties of an SDR. Because an SDR’s CPU and memory are not shared, configuration problems that cause out-of-resources conditions in one SDR do not affect the other SDRs in the system. Each non-owner SDR is self-sufficient and can be rebooted independently of the other non-owner SDRs in the system. Cisco IOS XR System Management Configuration Guide SMR-230 Configuring Secure Domain Routers on Cisco IOS XR Software Information About Configuring Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information If you reboot the owner SDR, then all non-owner SDRs in the system automatically reboot, because the non-owner SDRs rely on the owner SDR for basic chassis management functionality. Each SDR must be assigned a DSDRSC. To achieve full redundancy, each SDR must be assigned two RP or DRP cards: one RP or DRP to act as the primary DSDRSC, and one RP or DRP to act as a standby DSDRSC. Note DRPs are supported in the Cisco CRS-1 only. DRPs are not supported in the Cisco XR 12000 Series Routers. Cisco IOS XR Software Installation As of Cisco IOS XR Software Release 3.3, software can be activated for the entire system, or for an individual SDR. To access all install commands, you must be a member of the root-system user group. To install and activate a software package for SDRs: 1. Install the package on the DSC of the owner SDR (primary RP of the owner SDR). 2. Activate the package for all SDRs, or for a specific SDR. For detailed instructions, see the “Managing Cisco IOS XR Software Packages” module of the Cisco IOS XR Getting Started Guide. Caveats The following caveats apply to SDR creation and configuration: • DRPs are supported for the DSDRSC in the Cisco CRS-1 only. DRPs are not supported in the Cisco XR 12000 Series Routers. • In the Cisco CRS-1 router, we recommend the configuration of DRP pairs as the DSDRSC for all non-owner SDRs, as described in Using a DRP or DRP Pair as the DSDRSC in a Cisco CRS-1 Router, page 228. • Single RPs are not supported for the DSDRSC in Cisco CRS-1 routers. RP must be installed and configured in redundant pairs. • Single RPs and redundant RP pairs are supported for the DSDRSC on the Cisco XR 12000 Series Routers. • LC admin plane events cannot be sent to the DSC. In this release, events are sent to the non-owner SDR only. • Some admin plane debug events cannot be sent to the DSC. For example, a non-owner card cannot send debug events to the DSC, which limits the debugging of Admin processes to the non-owner SDR. • If a nonredundant DSC dies, all SDRs in the chassis reload. This is because the infrastructure (for example, the group services protocol) cannot support headless SDRs and the DSC functionality cannot be migrated across SDRs. When reloading a whole chassis, you need to reload the non-owner SDR’s RP or DRP before reloading the DSC. Cisco IOS XR System Management Configuration Guide SMR-231 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information How to Configure Secure Domain Routers To create an SDR, configure an SDR name and then add nodes to the configuration. In the Cisco CRS-1,at least one node in each SDR must be explicitly configured as the DSDRSC. In the Cisco XR 12000 Series Router, the DSDRSC is created automatically when you add an RP to the configuration. Once the SDR is created, you can add or remove additional nodes, and create a username and password for the SDR. See the following sections for instructions. Contents This section includes the following topics: • Creating SDRs, page 232 – Creating SDRs in a Cisco CRS-1 Router, page 232 – Creating SDRs in a 12000 Series Router, page 237 – Adding Nodes to a Non-owner SDR, page 241 • Adding Nodes to a Non-owner SDR, page 241 – Adding nodes to an SDR in a Cisco CRS-1 Router, page 241 – Adding nodes to an SDR in a Cisco XR 12000 Series Router, page 244 • Removing Nodes and SDRs, page 245 – Removing Nodes from a Secure Domain Router in a Cisco CRS-1 Router, page 246 – Removing a Secure Domain Router, page 250 • Configuring a Username and Password for a Non-owner SDR, page 251 • Disabling Remote Login for SDRs, page 255 • Related Documents, page 258 Creating SDRs The following sections provide instructions to create new non-owner SDRs. • Creating SDRs in a Cisco CRS-1 Router, page 232 • Creating SDRs in a 12000 Series Router, page 237 Creating SDRs in a Cisco CRS-1 Router To create a non-owner SDR in a Cisco CRS-1 router, create an SDR name, add a DSDRSC, and then add additional nodes to the configuration. Once the SDR is created, you can create a username and password for the SDR to allow additional configuration. Complete the following steps to create a non-owner SDR. Cisco IOS XR System Management Configuration Guide SMR-232 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Note The procedures in this section can only be performed on a router that is already running the Cisco IOS XR software. For instructions to boot a router and perform the initial configuration, see the Cisco IOS XR Getting Started Guide. When a router is booted, the owner SDR is automatically created, and cannot be removed. The Cisco IOS XR Getting Started Guide also includes instructions to create owner SDR username and password. SUMMARY STEPS 1. admin 2. configure 3. (Optional) pairing pair-name 4. (Optional) location node-id node-id 5. (Optional) exit 6. sdr sdr-name 7. location partially-qualified-nodeid primary or pair pair-name primary 8. location partially-qualified-nodeid or pair pair-name 9. Repeat Step 8 as needed to add slots to an SDR. 10. exit 11. Repeat Step 3 through Step 10 as needed to create additional secure domain routers. 12. end or commit Cisco IOS XR System Management Configuration Guide SMR-233 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 3 pairing pair-name (Optional) Complete Step 3 through step 5 to create a DRP pair. DRP pairs can be used as the DSDRSC for a non-owner SDR, as described in Designated System Example: RP/0/RP0/CPU0:router(admin-config)# pairing drp1 Controller (DSC) in the Cisco CRS-1, page 228. Note Although a single DRP can be use as the DSDRSC in a non-owner SDR, Cisco systems recommends that two redundant DRPs be installed and assigned to the SDR. The pairing pair-name command enters DRP pairing configuration mode. If the DRP name does not exist, the DRP pair will be created when you add nodes, as described in the following step. Note DRPs can also be added to an SDR to provide additional processing capacity. See Related Documents, page 258 more information on DRP installation and configuration. Step 4 location partially-qualified-nodeid (Optional) Specifies the location of the DRPs in a DRP partially-qualified-nodeid pair. The partially-qualified-nodeid argument is entered in Example: the rack/slot/* notation. Node IDs are always specified RP/0/RP0/CPU0:router(admin-config-pairing:drp1)# at the slot level, so the wildcard (*) is used to specify location 0/3/* 0/4/* the CPU. Step 5 exit (Optional) Exits the DRP pairing configuration mode and returns to admin-config mode. Example: Complete this step only if you created a DRP pair. RP/0/RP0/CPU0:router(admin-config-pairing:drp1)# exit Step 6 sdr sdr-name Enters the admin configuration mode for the specified SDR. Example: • If this SDR does not yet exist, it is created when RP/0/RP0/CPU0:router(admin-config)# sdr rname2 you add a node as described in Step 7. • If this SDR existed previously, Step 7 and Step 8 adds slots to it. Cisco IOS XR System Management Configuration Guide SMR-234 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 7 To assign a DRP pair as the DSDRSC: Specifies a DSDRSC for the non-owner SDR. You can pair pair-name primary assign a redundant DRP pair, an RP pair, or a single DRP as the DSDRSC. You cannot assign a single RP as the DSDRSC. Every SDR must contain a DSDRSC. Example: RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# • We recommend the use of DRP pairs as the pair drp1 primary DSDRSC for all non-owner SDRs. • The primary keyword configures the RPs, or DRP pair or DRP as the DSDRSC. If the primary keyword is not used, the node will be assigned to To assign a single DRP node as the DSDRSC: the SDR, but it will not be the DSDRSC. location partially-qualified-nodeid primary • If an RP is already assigned to the SDR, it must be removed before a DRP or DRP pair can be Example: assigned as the DSDRSC. See Removing Nodes RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# from a Secure Domain Router in a Cisco CRS-1 location 0/0/* primary Router, page 246. or To assign a DRP pair as the DSDRSC To assign an RP pair as the DSDRSC To assign a DRP pair as the DSDRSC, you must first create a DRP pair as described in Step 3 and Step 4. location partially-qualified-nodeid primary Once the DRP pair is created, you can add the pair to the configuration with the command pair pair-name. Example: To assign the pair as the DSDRSC, use the primary RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# keyword. location 0/RP*/* primary To assign a single DRP node as the DSDRSC The value of the partially-qualified-nodeid argument is entered in the rack/slot/* notation. The node ID is specified at the slot level, so the wildcard (*) is used to specify the CPU. To assign an RP pair as the DSDRSC The value of the partially-qualified-nodeid argument for RPs is entered in the rack/RP*/* notation. This command assigns the redundant RP pair as the DSDRSC. One RP is automatically elected as the DSDRSC, and the second RP acts as the standby DSDRSC. Cisco IOS XR System Management Configuration Guide SMR-235 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 8 location partially-qualified-nodeid Adds additional nodes, DRP pairs, or RP pairs to the or SDR. location pair-name To add a single node Example: RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# Enter the location partially-qualified-nodeid location 0/0/* command. The value of the partially-qualified-nodeid or argument is entered in the rack/slot/* notation. Node RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# IDs are always specified at the slot level, so the location drp1 wildcard (*) is used to specify the CPU. or RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# location 0/RP*/* To add a DRP pair You must you must first create a pair as described in step 3 and step 4. Once the DRP pair is created, enter the location pair-name command. To add an RP pair Enter the location partially-qualified-nodeid command. The value of the partially-qualified-nodeid argument for RPs is entered in the rack/RP*/* notation. This command assigns the redundant RP pair to the SDR. You cannot assign single RPs to an SDR in the Cisco CRS-1. Note Refer to Adding Nodes to a Non-owner SDR, page 241 for more information. Step 9 Repeat Step 8 as needed. Adds additional nodes to the SDR. Step 10 exit (Optional) Exits the SDR configuration submode and returns to admin-config mode. Note Complete this step only if you need to create additional SDRs. Step 11 Repeat Step 3 through Step 10 as needed. Creates additional SDRs. Cisco IOS XR System Management Configuration Guide SMR-236 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 12 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to RP/0/RP0/CPU0:router (admin-config-sdr:rname2)# end the running configuration file, exits the or configuration session, and returns the router RP/0/RP0/CPU0:router(admin-config-sdr:rname)# to EXEC mode. commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 13 Create a username and password for the new SDR. (Optional) Refer to Configuring a Username and Password for a Non-owner SDR, page 251. Creating SDRs in a 12000 Series Router To create a non-owner SDR in a Cisco XR 12000 Series Router, create an SDR name, add an RP (that can act as DSDRSC) or 2 RPs in adjacent redundancy slots (that can act as the DSDRSC & standby DSDRSC) and then add additional (non-RP) nodes to the configuration Note The procedures in this section can only be performed on a router that is already running the Cisco IOS XR software. For instructions to boot a router and perform the initial configuration, see the Cisco IOS XR Getting Started Guide. When a router is booted, the owner SDR is automatically created, and cannot be removed. The Cisco IOS XR Getting Started Guide also includes instructions to create owner SDR username and password. Complete the following steps to create a non-owner SDR. SUMMARY STEPS 1. admin 2. configure 3. sdr sdr-name 4. location partially-qualified-nodeid 5. location partially-qualified-nodeid 6. Repeat Step 5 as needed to add additional nodes to an SDR. 7. exit Cisco IOS XR System Management Configuration Guide SMR-237 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information 8. Repeat Step 3 through Step 7 as needed to create additional secure domain routers. 9. end or commit DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/0/CPU0:router(admin)# configure Step 3 sdr sdr-name Enters the admin configuration mode for the specified SDR. Example: • If this SDR does not yet exist, it is created when RP/0/0/CPU0:router(admin-config)# sdr rname you add a node as described in the following step. • If this SDR existed previously, complete the following steps to add additional nodes. Step 4 Assign an RP node as the DSDRSC: Specifies a DSDRSC for the non-owner SDR. On a location partially-qualified-nodeid Cisco XR 12000 Series Router, you can assign a single RP or a redundant RP pair as the DSDRSC. • The first RP you assign to the SDR will become Example: RP/0/0/CPU0:router(admin-config-sdr:rname)# the DSDRSC. location 0/0/* • To add a redundant standby RP to the configuration, a second RP must be installed in the adjacent redundancy slot and added to the SDR configuration. See DSC and DSDRSCs in a Cisco XR 12000 Series Router, page 229 for information on redundancy slots. See Step 5 for instructions to add an additional RP to the configuration. • The value of the partially-qualified-nodeid argument is entered in the rack/slot/* notation. The node ID is specified at the slot level, so the wildcard (*) is used to specify the CPU. • DRPs are not supported in Cisco XR 12000 Series Routers. Cisco IOS XR System Management Configuration Guide SMR-238 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 5 Assign a second RP to act as the standby DSDRSC. If an RP is in an adjacent redundancy slot to the location partially-qualified-nodeid DSDRSC, then the RP will automatically become the standby DSDRSC. • See DSC and DSDRSCs in a Example: RP/0/0/CPU0:router(admin-config-sdr:rname)# Cisco XR 12000 Series Router, page 229 for more location 0/1/* information. • The value of the partially-qualified-nodeid argument is entered in the rack/slot/* notation. The node ID is specified at the slot level, so the wildcard (*) is used to specify the CPU. • Although single RPs are supported in Cisco XR 12000 Series Routers, we recommend the use of a redundant RP pair: one to act as the DSDRSC and the second to act as a standby DSDRSC. Step 6 location partially-qualified-nodeid Adds additional nodes to the SDR. • Enter the value of the partially-qualified-nodeid Example: argument to specify a single node. The value of the RP/0/0/CPU0:router(admin-config-sdr:rname)# nodeid argument is entered in the rack/slot/* location 0/5/* notation. Node IDs are always specified at the slot level, so the wildcard (*) is used to specify the CPU. • Refer to Adding Nodes to a Non-owner SDR, page 241 for more information. Step 7 Repeat Step 5 as needed. Adds additional nodes to the SDR. Step 8 exit (Optional) Exits the SDR configuration submode and returns to admin-config mode. Note Complete this step only if you need to create additional SDRs. Step 9 Repeat Step 3 through Step 7 as needed. Creates additional SDRs. Cisco IOS XR System Management Configuration Guide SMR-239 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 10 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to RP/0/0/CPU0:router (admin-config-sdr:rname)# end the running configuration file, exits the or configuration session, and returns the router RP/0/0/CPU0:router(admin-config-sdr:rname)# commit to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 11 Create a username and password for the new SDR. (Optional) Refer to Configuring a Username and Password for a Non-owner SDR, page 251. Cisco IOS XR System Management Configuration Guide SMR-240 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Adding Nodes to a Non-owner SDR When adding nodes to an existing non-owner SDR, the following rules apply: • By default, all nodes in a new system belong to the owner SDR. When a node is assigned to a non-owner SDR, the node is removed from the owner SDR inventory and added to the non-owner SDR. • When a node is removed from a non-owner SDR, it is automatically returned to the owner SDR inventory. • To add a node that already belongs to another non-owner SDR, you must first remove the node from the other SDR, and then reassign it to the new SDR. See Removing Nodes from a Secure Domain Router in a Cisco CRS-1 Router, page 246 for more information. • You cannot assign the DSC or standby DSC to a non-owner SDR. The DSC and standby DSC can cannot be removed and assigned to a non-owner SDR. • The main difference between adding a node in a Cisco CRS-1 and a Cisco XR 12000 Series Router is for DSDRSC support: – Cisco CRS-1 routers support DRPs and DRP pairs. – In a Cisco CRS-1 router, RPs can only be added in redundant pairs. – Cisco XR 12000 Series Routers do not support DRPs. – In a Cisco XR 12000 Series Router, RPs can be added individually, or in redundant sets. Only two RPs (if installed in the adjacent redundancy slots) can function in each SDR. Complete the following steps to add one or more nodes to an existing non-owner SDR: • Adding nodes to an SDR in a Cisco CRS-1 Router, page 241 • Adding nodes to an SDR in a Cisco XR 12000 Series Router, page 244 Adding nodes to an SDR in a Cisco CRS-1 Router SUMMARY STEPS 1. admin 2. configure 3. sdr sdr-name 4. location partially-qualified-nodeid or location pair-name 5. end or commit Cisco IOS XR System Management Configuration Guide SMR-241 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 3 sdr sdr-name Enters the SDR configuration submode for the specified SDR. Example: • sdr-name is the name assigned to the SDR. RP/0/RP0/CPU0:router(admin-config)# sdr rname Cisco IOS XR System Management Configuration Guide SMR-242 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 4 location partially-qualified-nodeid Adds additional nodes, DRP pairs, or RP pairs to an or SDR. location pair-name To add a single node Example: RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# Enter the location partially-qualified-nodeid command. location 0/0/* The value of the partially-qualified-nodeid argument is or entered in the rack/slot/* notation. Node IDs are always RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# specified at the slot level, so the wildcard (*) is used to location drp1 specify the CPU. or RP/0/RP0/CPU0:router(admin-config-sdr:rname)# location 0/RP*/* To add a DRP pair You must you must first create a pair as described in step 3 and step 4 of Creating SDRs in a Cisco CRS-1 Router, page 232. Once the DRP pair is created, enter the location pair-name command. pair-name is the name assigned to the DRP pair. To add an RP pair Enter the location partially-qualified-nodeid command. The value of the partially-qualified-nodeid argument for RPs is entered in the rack/RP*/* notation. This command assigns the redundant RP pair to the SDR. You cannot assign single RPs to an SDR in the Cisco CRS-1. Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router running configuration file, exits the (admin-config-sdr:rname2)# end configuration session, and returns the router to or EXEC mode. RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-243 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Adding nodes to an SDR in a Cisco XR 12000 Series Router SUMMARY STEPS 1. admin 2. configure 3. sdr sdr-name 4. location partially-qualified-nodeid 5. end or commit DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/0/CPU0:router(admin)# configure Step 3 sdr sdr-name Enters the SDR configuration submode for the specified SDR. Example: • sdr-name is the name assigned to the SDR. RP/0/0/CPU0:router(admin-config)# sdr rname Cisco IOS XR System Management Configuration Guide SMR-244 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 4 location partially-qualified-nodeid Adds additional nodes to the SDR. • Enter the value of the partially-qualified-nodeid Example: argument to specify a single node. The value of the RP/0/0/CPU0:router(admin-config-sdr:rname)# nodeid argument is entered in the rack/slot/* location 0/5/* notation. Node IDs are always specified at the slot level, so the wildcard (*) is used to specify the CPU. • If you add an RP installed in a redundancy slot next to the DSDRSC, then the second RP will become the standby DSDRSC. Refer to DSC and DSDRSCs in a Cisco XR 12000 Series Router, page 229 for more information. Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/0/CPU0:router running configuration file, exits the (admin-config-sdr:rname2)# end configuration session, and returns the router to or EXEC mode. RP/0/0/CPU0:router(admin-config-sdr:rname2)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Removing Nodes and SDRs This section contains the following instructions: • Removing Nodes from a Secure Domain Router in a Cisco CRS-1 Router, page 246 • Removing Nodes from a Secure Domain Router: Cisco XR 12000 Series Router, page 248 • Removing a Secure Domain Router, page 250 When removing a node or an entire SDR, the following rules apply: • When a node is removed from a non-owner SDR, it is automatically returned to the owner SDR inventory. • To remove a DSDRSC, first remove the other nodes in the SDR, and then remove the DSDRSC. This rule does not apply when the entire SDR is removed. • If all nodes are removed from a non-owner SDR, the SDR name is also removed. • To remove all nodes, including the DSDRSC, remove the SDR name. All nodes will be returned to the owner SDR inventory. Cisco IOS XR System Management Configuration Guide SMR-245 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information • You must first remove a node from a non-owner SDR before it can be re-assigned to another non-owner SDR. • To remove a node from the owner SDR inventory, assign the node to an non-owner SDR. • The owner SDR cannot be removed, and the owner DSDRSC (DSC) cannot be removed. Removing Nodes from a Secure Domain Router in a Cisco CRS-1 Router SUMMARY STEPS 1. admin 2. configure 3. sdr sdr-name 4. no location partially-qualified-nodeid or no location pair-name 5. end or commit DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 3 sdr sdr-name Enters the SDR configuration submode for the specified SDR. Example: RP/0/RP0/CPU0:router(admin-config)# sdr rname Cisco IOS XR System Management Configuration Guide SMR-246 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 4 no location partially-qualified-nodeid Removes a node, DRP pair or RP pair from a non-owner or SDR. no location pair-name • When a node is removed from an SDR, it is Example: automatically added to the owner SDR inventory. RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# This node may now be assigned to a different SDR no location 0/0/* as described in Adding nodes to an SDR in a or Cisco CRS-1 Router, page 241. RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# no location drp1 • Removing all the slots from an SDR deletes that or SDR. RP/0/RP0/CPU0:router(admin-config-sdr:rname)# no location 0/RP*/* To remove a DSDRSC The DSDRSC cannot be removed if other nodes are in the SDR configuration. To remove the DSDRSC, you must first remove all other nodes in the SDR. To remove a single node Enter the no location partially-qualified-nodeid command. The value of the partially-qualified-nodeid argument is entered in the rack/slot/* notation. Node IDs are always specified at the slot level, so the wildcard (*) is used to specify the CPU. To remove a DRP pair Enter the no location pair-name command. The pair-name argument is the name assigned to the DRP pair. To remove an RP pair Enter the no location partially-qualified-nodeid command. The value of the partially-qualified-nodeid argument for RPs is entered in the rack/RP*/* notation. This command removes both RPs in a pair. Cisco IOS XR System Management Configuration Guide SMR-247 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router running configuration file, exits the (admin-config-sdr:rname2)# end configuration session, and returns the router to or EXEC mode. RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Removing Nodes from a Secure Domain Router: Cisco XR 12000 Series Router SUMMARY STEPS 1. admin 2. configure 3. sdr sdr-name 4. no location partially-qualified-nodeid 5. end or commit DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/0/CPU0:router(admin)# configure Cisco IOS XR System Management Configuration Guide SMR-248 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 3 sdr sdr-name Enters the SDR configuration submode for the specified SDR. Example: RP/0/0/CPU0:router(admin-config)# sdr rname Step 4 no location partially-qualified-nodeid Removes a node from a non-owner SDR. • When a node is removed from an SDR, it is Example: automatically added to the owner SDR inventory. RP/0/0/CPU0:router(admin-config-sdr:rname2)# no location 0/0/* This node may now be assigned to a different SDR as described in Adding nodes to an SDR in a Cisco XR 12000 Series Router, page 244. • Removing all the slots from an SDR deletes that SDR. To remove a DSDRSC The DSDRSC cannot be removed if other nodes are in the SDR configuration. To remove the DSDRSC, you must first remove all other nodes in the SDR. To remove a single node Enter the no location partially-qualified-nodeid command. The value of the partially-qualified-nodeid argument is entered in the rack/slot/* notation. Node IDs are always specified at the slot level, so the wildcard (*) is used to specify the CPU. Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router running configuration file, exits the (admin-config-sdr:rname2)# end configuration session, and returns the router to or EXEC mode. RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-249 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Removing a Secure Domain Router This section provides instructions to remove a secure domain router from either a Cisco CRS-1 or a Cisco XR 12000 Series Router. To remove an SDR, you can either remove all the nodes in the SDR individually, or remove the SDR name. This section contains instructions to remove the SDR name and return all nodes to the owner SDR inventory. Note The owner SDR cannot be removed. Only non-owner SDRs can be removed. SUMMARY STEPS 1. admin 2. configure 3. no sdr sdr-name 4. end or commit Cisco IOS XR System Management Configuration Guide SMR-250 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 3 no sdr sdr-name Removes the specified SDR from the current owner SDR. Note All slots belonging to that SDR return to the owner Example: SDR inventory. RP/0/RP0/CPU0:router(admin-config)# no sdr rname Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router (admin-config)# end running configuration file, exits the configuration or session, and returns the router to EXEC mode. RP/0/RP0/CPU0:router(admin-config)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Configuring a Username and Password for a Non-owner SDR After you create an SDR, you can create a username and password on that SDR. When you assign root-sdr privileges to that username, the user can administer the non-owner SDR and create additional users if necessary. Note Only users with root-system privileges can access Admin mode to add or remove SDRs. SDR users cannot add or remove SDRs. To create a username and password for the new non-owner SDR. 1. On the owner SDR, enable admin plane authentication. This allows you to log in to the non-owner SDR and create local usernames and passwords. Cisco IOS XR System Management Configuration Guide SMR-251 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information 2. Log in to the non-owner SDR. 3. Configure a new username and password on the non-owner SDR. Assign the username to the root-sdr group to allow the creation of additional usernames on that SDR. 4. To verify the new username, log out and log back in to the non-owner SDR using the new username and password. 5. Provide the username and password to the SDR user. Complete the following steps to create usernames and passwords on a non-owner SDR. SUMMARY STEPS 1. Connect a terminal to the console port of the DSC on the owner SDR. 2. admin 3. configure 4. aaa authentication login remote local 5. end or commit 6. Connect a terminal to the console port of the non-owner SDR DSDRSC. 7. Log in to the non-owner SDR using admin plane authentication. Username:username@admin Password:password 8. configure 9. username 10. secret 11. group root-sdr 12. end or commit 13. exit 14. Username:username Password:password 15. quit Cisco IOS XR System Management Configuration Guide SMR-252 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 Connect to the DSC of the owner SDR. Note If an IP address has not yet been assigned to the Management Ethernet port, you must connect a terminal directly to the console port of the DSC. Step 2 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 3 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 4 aaa authentication login remote local Enables admin plane authentication. • The remote keyword specifies a method list that uses Example: remote non-owner SDR for authentication. RP/0/RP0/CPU0:router(admin-config)# aaa authentication login remote local • The local keyword specifies a method list that uses the local username database method for authentication. The local authentication cannot fail because the system always ensures that at least one user is present in the local database, and a rollover cannot happen beyond the local method. Note You can also use other methods to enable AAA system accounting, such as TACACS+ or RADIUS servers. See “Configuring AAA Services on Cisco IOS XR Software” module of the Cisco IOS XR System Security Configuration Guide for more information. Step 5 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router (admin-config)# end running configuration file, exits the configuration or session, and returns the router to EXEC mode. RP/0/RP0/CPU0:router(admin-config)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-253 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 6 Connect a terminal to the console port of the Note A terminal server connection is required for Telnet non-owner SDR DSDRSC. connections to the console port. This is because an IP address has not yet been assigned to the management Ethernet port. Step 7 Username:xxxx@admin Logs a root-system user into the SDR using admin plane Password:xxxx authentication. Note Where it says “Username:xxxx@admin,” replace Example: xxxx with your username. Username:xxxx@admin Password:xxxx Step 8 configure Enters configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 9 username user-name Defines an SDR username and enters username configuration mode. Example: The user-name argument can be only one word. Spaces and RP/0/RP0/CPU0:router(config)# username user1 quotation marks are not allowed. Step 10 secret password Defines a password for the user. Example: RP/0/RP0/CPU0:router(config-un)# secret 5 XXXX Step 11 group root-sdr Adds the user to the predefined root-sdr group. Note Only users with root-system authority or root-sdr Example: authority may use this option. RP/0/RP0/CPU0:router(config-un)# group root-sdr Step 12 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router (config)# end running configuration file, exits the configuration or session, and returns the router to EXEC mode. RP/0/RP0/CPU0:router(config)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-254 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 13 exit Closes the active terminal session and log off the router. Example: exit Step 14 Username:xxxx Logs back in with the SDR administrator username and Password:xxxx password you created. This username is used to configure the secure domain router and create other users with fewer Example: privileges. Press RETURN to get started. • This step verifies proper SDR administrator username Username:user1 and password configuration. Password:xxxxx • After you create the SDR username and password, you need to provide the SDR username and password to the operators who will use that SDR. Step 15 Provide the new username and password to the user. Step 16 Disable remote login. Disable admin plane authentication as described in Disabling Remote Login for SDRs, page 255. Disabling Remote Login for SDRs When you disable admin plane authentication ensures, the admin username cannot be used to log in to non-owner SDRs. Only local SDR usernames can be used to log into the SDR. SUMMARY STEPS 1. admin 2. configure 3. no aaa authentication login remote local 4. end or commit Cisco IOS XR System Management Configuration Guide SMR-255 Configuring Secure Domain Routers on Cisco IOS XR Software How to Configure Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 admin Enters admin mode. Example: RP/0/RP0/CPU0:router# admin Step 2 configure Enters admin configuration mode. Example: RP/0/RP0/CPU0:router(admin)# configure Step 3 no aaa authentication login remote local Disables remote login. Example: RP/0/RP0/CPU0:router(admin-config)# no aaa authentication login remote local Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found. Commit them? Example: – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router (admin-config)# end running configuration file, exits the configuration or session, and returns the router to EXEC mode. RP/0/RP0/CPU0:router(admin-config)# commit – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the user in the same command mode without committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-256 Configuring Secure Domain Routers on Cisco IOS XR Software Configuration Examples for Secure Domain Routers R3.3 Beta Draft—Cisco Confidential Information Configuration Examples for Secure Domain Routers Create a new SDR on a CRS-1 router RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# pairing drp1 RP/0/RP0/CPU0:router(admin-config-pairing:drp1)# location 0/3/* 0/4/* RP/0/RP0/CPU0:router(admin-config-pairing:drp1)#exit RP/0/RP0/CPU0:router(admin-config)# sdr rname2 RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# pair pair1 primary RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# location 0/0/* RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# end Create an SDR on a 12000 Series Router RP/0/0/CPU0:router# admin RP/0/0/CPU0:router(admin)# configure RP/0/0/CPU0:router(admin-config)# sdr rname RP/0/0/CPU0:router(admin-config-sdr:rname)# location 0/0/* RP/0/0/CPU0:router(admin-config-sdr:rname)# location 0/1/* RP/0/0/CPU0:router(admin-config-sdr:rname)# location 0/5/* RP/0/0/CPU0:router(admin-config-sdr:rname)# end Adding nodes to an SDR: Cisco CRS-1 Router RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# sdr rname2 RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# location 0/0/* RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# end Adding nodes to an SDR: Cisco XR 12000 Series Router RP/0/0/CPU0:router# admin RP/0/0/CPU0:router(admin)# configure RP/0/0/CPU0:router(admin-config)# sdr rname2 RP/0/0/CPU0:router(admin-config-sdr:rname2)# location 0/5/* RP/0/0/CPU0:router (admin-config-sdr:rname2)# end Removing Nodes from a Secure Domain Router: Cisco CRS-1 RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# sdr rname2 RP/0/RP0/CPU0:router(admin-config-sdr:rname2)# no location 0/0/* RP/0/RP0/CPU0:router (admin-config-sdr:rname2)# end Removing a Secure Domain Router: Cisco CRS-1 RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# no sdr rname2 RP/0/RP0/CPU0:router (admin-config)# end Configuring a Username and Password for a Non-owner SDR Connect to the DSC of the owner SDR. RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# aaa authentication login remote local RP/0/RP0/CPU0:router (admin-config)# end Cisco IOS XR System Management Configuration Guide SMR-257 Configuring Secure Domain Routers on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Connect a terminal to the console port of the non-owner SDR DSDRSC. Username:xxxx@admin Password:xxxx RP/0/RP0/CPU0:router# configure RP/0/RP0/CPU0:router(config)# username user1 RP/0/RP0/CPU0:router(config-un)# secret 5 XXXX RP/0/RP0/CPU0:router(config-un)# group root-sdr RP/0/RP0/CPU0:router (config)# end RP/0/RP0/CPU0:router# exit Press RETURN to get started. Username:user1 Password:xxxxx Disabling Remote Login for SDRs RP/0/RP0/CPU0:router# admin RP/0/RP0/CPU0:router(admin)# configure RP/0/RP0/CPU0:router(admin-config)# no aaa authentication login remote local RP/0/RP0/CPU0:router (admin-config)# end Additional References The following sections provide references related to SDR configuration. Related Documents Related Topic Document Title SDR command reference. Secure Domain Router Commands on Cisco IOS XR Software DRP pairing command reference. Distributed Route Processor Commands on Cisco IOS XR Software Initial system bootup and configuration information for Cisco IOS XR Getting Started Guide a router using the Cisco IOS XR software. DRP description and requirements. Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis System Description Instructions to install DRP and DRP PLIM cards. Installing the Cisco CRS-1 Carrier Routing System 16-Slot Line Card Chassis Information about user groups and task IDs Cisco IOS XR Task ID Reference Guide Cisco IOS XR master command reference Cisco IOS XR Master Commands List, Release 3.2 Cisco IOS XR interface configuration commands Cisco CRS-1 Series Interface and Hardware Component Command Reference Information about configuring interfaces and other Cisco CRS-1 Series Carrier Routing System Craft Works Interface components on the Cisco CRS-1 from a remote Craft Configuration Guide Works Interface (CWI) client management application Information about AAA policies, including “Configuring AAA Services on Cisco IOS XR Software” module of instructions to create and modify users and username the Cisco IOS XR System Security Configuration Guide. access privileges. Cisco IOS XR System Management Configuration Guide SMR-258 Configuring Secure Domain Routers on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Standards Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature. MIBs MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR Software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml RFCs RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature. Technical Assistance Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. Cisco IOS XR System Management Configuration Guide SMR-259 Configuring Secure Domain Routers on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Cisco IOS XR System Management Configuration Guide SMR-260 R3.3 Beta Draft—Cisco Confidential Information Implementing Physical and Virtual Terminals on Cisco IOS XR Software Beta Draft Cisco Confidential Information Line templates define standard attribute settings for incoming and outgoing transport over physical and virtual terminal lines (vtys). Vty pools are used to apply template settings to ranges of vtys. Note Before creating or modifying the vty pools, enable the telnet server using the telnet server command in global configuration mode. See the Cisco IOS XR IP Addresses and Services Configuration Guide and Cisco IOS XR IP Addresses and Services Command Reference for more information. This module describes the new and revised tasks you need to implement physical and virtual terminals on your Cisco IOS XR network. Note For more information about physical and virtual terminals on the Cisco IOS XR software and complete descriptions of the terminal services commands listed in this module, you can refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of running a configuration task, search online in the Cisco IOS XR software master command index. Feature History for Implementing Physical and Virtual Templates on Cisco IOS XR Software Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification Release 3.2 Support was added for the Cisco XR 12000 Series Router. Release 3.3 No modification. Contents • Prerequisites for Implementing Physical and Virtual Terminals on Cisco IOS XR Software, page 262 • Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software, page 262 • How to Implement Physical and Virtual Terminals on Cisco IOS XR Software, page 266 Cisco IOS XR System Management Configuration Guide SMR-261 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Prerequisites for Implementing Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information • Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software, page 271 • Additional References, page 274 Prerequisites for Implementing Physical and Virtual Terminals on Cisco IOS XR Software You must be in a user group associated with a task group that includes the proper task IDs for terminal services commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide. Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software To implement physical and virtual terminals, you need to understand the following concepts: • Line Templates, page 262 • Line Template Configuration Mode, page 262 • Line Template Guidelines, page 263 • Terminal Identification, page 264 • vty Pools, page 264 Line Templates The following line templates are available in the Cisco IOS XR software: • Default line template—The default line template that applies to a physical and virtual terminal lines. • Console line template—The line template that applies to the console line. • Aux line template—The line template that applies to the auxiliary line. • User-defined line templates—User-defined line templates that can be applied to a range of virtual terminal lines. Line Template Configuration Mode Changes to line template attributes are made in line template configuration mode. To enter line template configuration mode, issue the line command from global configuration mode, specifying the template to be modified. The line templates that are available to be configured with the line command can be displayed using the online help function (?): RP/0/0/CPU0:router(config)# line ? aux aux template console console template Cisco IOS XR System Management Configuration Guide SMR-262 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information default default template template user defined template Once you specify a template with the line command, the router will enter line template configuration mode where you can set the terminal attributes that will apply to specified line template. This example shows how to specify the console template and to enter line template configuration mode for the console template: RP/0/RP0/CPU0:router(config)# line console RP/0/RP0/CPU0:router(config-line)# From line template configuration mode, the following terminal attribute setting commands can be configured: RP/0/0/CPU0:router(config-line)# ? absolute-timeout Set absolute timeout for line disconnection. access-class Filter connections based on an IP access list accounting Accounting parameters authorization Authorization parameters commit Commit the configuration changes to running databits Set the nimber of databits. default Set a command to its defaults describe Describe a command without taking real actions disconnect-character Define the disconnect character do Run an exec command escape-character Change the current line template's escape character exec-timeout Set EXEC timeout exit Exit from this submode flowcontrol Configure flow control. length Set number of lines on a screen. login Line login configuration no Negate a command or set its defaults parity Set the parity used. password Specify the password for the user secret Provide a secure one way encrypted password session-limit Set the number of outgoing connections session-timeout Set interval for closing connection when there is no input traffic show Show contents of configuration speed Set the serial port inbound/outbound speed. stopbits Set the stopbits used. telnet Telnet protocol-specific configuration timeout Timeouts for the line transport Define transport protocols for line users Users characteristics width Set width of the display terminal. Line Template Guidelines The following guidelines apply to modifying the console and aux templates and to configuring a user-defined template: • Modify the templates for the physical terminal lines on the router (the console and auxiliary ports) from line template configuration mode. Use the line console command or the line auxiliary command from global configuration mode to enter line template configuration mode for the console and aux templates, respectively. Cisco IOS XR System Management Configuration Guide SMR-263 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information • Modify the template for virtual lines by configuring a user-defined template with the line template-name command, configuring the terminal attributes for the user-defined template from line template configuration, and applying the template to a range of virtual terminal lines using the vty pool command. Note Attributes not defined in the aux and console templates, or any virtual template, are taken from the default template. Note The default settings for the default template are described for all commands in line template configuration mode in the Terminal Services Commands on Cisco IOS XR Software module in the Cisco IOS XR System Management Command Reference. Note Before creating or modifying the vty pools, enable the telnet server using the telnet server command in global configuration mode. See the Cisco IOS XR IP Addresses and Services Configuration Guide and Cisco IOS XR IP Addresses and Services Command Reference for more information. Terminal Identification The physical terminal lines for the console and auxiliary ports are identified by their location, expressed in the format of rack/shelf/module, on the active or standby Route Processor (RP) where the respective console or auxiliary port resides. For virtual terminals, physical location is not applicable; the Cisco IOS XR software assigns a vty identifier to vtys according to the order in which the vty connection has been established. vty Pools Each virtual line is a member of a pool of connections using a common line template configuration. Multiple vty pools may exist, each containing a defined number of vtys as configured in the vty pool. The Cisco IOS XR software supports the following vty pools by default: • Default vty pool—The default vty pool consists of five vtys (vtys 0 through 4) that each reference the default line template. • Default fault manager pool—The default fault manager pool consists of six vtys (vtys 100 through 105) that each reference the default line template. In addition to the default vty pool and default fault manager pool, you can also configure a user-defined vty pool that can reference the default template or a user-defined template. When configuring vty pools, follow these guidelines: • The vty range for the default vty pool must start at vty 0 and must contain a minimum of five vtys. • The vty range from 0 through 99 can reference the default vty pool. • The vty range from 5 through 99 can reference a user-defined vty pool. • The vty range from 100 is reserved for the fault manager vty pool. • The vty range for fault manager vty pools must start at vty 100 and must contain a minimum of six vtys. Cisco IOS XR System Management Configuration Guide SMR-264 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Information About Implementing Physical and Virtual Terminals Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information • A vty can be a member of only one vty pool. A vty pool configuration will fail if the vty pool includes a vty that is already in another pool. • If you attempt to remove an active vty from the active vty pool when configuring a vty pool, the configuration for that vty pool will fail. Cisco IOS XR System Management Configuration Guide SMR-265 Implementing Physical and Virtual Terminals on Cisco IOS XR Software How to Implement Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information How to Implement Physical and Virtual Terminals on Cisco IOS XR Software This section contains the following procedures: • Modifying Templates, page 266 (required) • Creating and Modifying vty Pools, page 268 (required) • Monitoring Terminals and Terminal Sessions, page 270 (optional) Modifying Templates This task explains how to modify the terminal attributes for the aux, console, and default line templates. The terminal attributes that you set will modify the template settings for the specified template. SUMMARY STEPS 1. configure 2. line aux or line console or line default 3. Configure the terminal attribute settings for the specified template using the commands in line template configuration mode. 4. end or commit Cisco IOS XR System Management Configuration Guide SMR-266 Implementing Physical and Virtual Terminals on Cisco IOS XR Software How to Implement Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 line aux Enters line template configuration mode for the specified or line template. line console • Specifying the line aux command enters line template or configuration mode for the aux line template. line default or • Specifying the line console command enters line Example: template configuration mode for the console template. RP/0/RP0/CPU0:router(config)# line aux or or RP/0/RP0/CPU0:router(config)# line console • Specifying the line default commands enters line or template configuration mode for the default line RP/0/RP0/CPU0:router(config)# line default template. Step 3 Configure the terminal attribute settings for the — specified template using the commands in line template configuration mode. Step 4 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-267 Implementing Physical and Virtual Terminals on Cisco IOS XR Software How to Implement Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Creating and Modifying vty Pools This task explains how to create and modify vty pools. Note You can omit Steps 2 to 4 if you are configuring the default line template to reference a vty pool. Note Before creating or modifying the vty pools, enable the telnet server using the telnet server command in global configuration mode. See the Cisco IOS XR IP Addresses and Services Configuration Guide and Cisco IOS XR IP Addresses and Services Command Reference for more information. SUMMARY STEPS 1. configure 2. line template template-name 3. Configure the terminal attribute settings for the specified line template using the commands in line template configuration mode. 4. exit 5. vty-pool default first-vty last-vty [line-template {default | template-name}] or vty-pool pool-name first-vty last-vty [line-template {default | template-name}] or vty-pool fm first-vty last-vty [line-template {default | template-name}] 6. end or commit DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 line template template-name Enters line template configuration mode for a user-defined template. Example: RP/0/RP0/CPU0:router(config)# line template 1 Step 3 Configure the terminal attribute settings for the — specified line template using the commands in line template configuration mode. Step 4 exit Exits line template configuration mode and returns the router to global configuration mode. Example: RP/0/0/CPU0:router(config-line)# exit Cisco IOS XR System Management Configuration Guide SMR-268 Implementing Physical and Virtual Terminals on Cisco IOS XR Software How to Implement Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 5 vty-pool default first-vty last-vty Creates or modifies vty pools. [line-template {default | template-name}] or • If you do not specify a line template with the line-template keyword and the default keyword or vty-pool pool-name first-vty last-vty [line-template {default | template-name}] template-name argument (for any form of the vty-pool or command), a vty pool defaults to the default line template. vty-pool fm first-vty last-vty [line-template {default | template-name}] • Specifying the vty-pool default first-vty last-vty line-template template-name command configures the default vty pool to reference a user-defined template. Example: RP/0/RP0/CPU0:router(config)# vty-pool default – The default vty pool must start at vty 0 and must 0 5 line-template default contain a minimum of five vtys (vtys 0 through 5). or – You can resize the default vty pool by increasing RP/0/RP0/CPU0:router(config)# vty-pool pool1 5 the range of vtys that compose the default vty pool. 50 line-template template1 or or RP/0/RP0/CPU0:router(config)# vty-pool fm 100 • Specifying the vty-pool pool-name first-vty last-vty 105 line-template template1 line-template template-name command creates a user-defined vty pool and configures that vty pool to reference a user-defined template. – A user-defined pool must start at least at vty 5, depending on whether the default vty pool has been resized. – If the range of vtys for the default vty pool has been resized, use the first range value free from the default line template. For example, if the range of vtys for the default vty pool has been configured to include 10 vtys (vty 0 through 9), the range value for the user-defined vty pool must start with vty 10. or • Specifying the vty-pool fm first-vty last-vty line-template template-name command configures the fault manager pool to reference a user-defined line template. – The default fault manager vty pool must start at vty 100 and must contain a minimum of six vtys (vtys 100 through 105). Cisco IOS XR System Management Configuration Guide SMR-269 Implementing Physical and Virtual Terminals on Cisco IOS XR Software How to Implement Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 6 end Saves configuration changes. or • When you issue the end command, the system prompts commit you to commit changes: Uncommitted changes found, commit them before Example: exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to the RP/0/RP0/CPU0:router(config)# commit running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Monitoring Terminals and Terminal Sessions This task explains how to monitor terminals and terminal sessions using the show EXEC commands available for physical and terminal lines. Note The commands can be entered in any order. SUMMARY STEPS 1. show line [location node-id {aux | console} | vty number] 2. show terminal 3. show users Cisco IOS XR System Management Configuration Guide SMR-270 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 show line [location node-id {aux | console} | (Optional) Displays the terminal parameters of terminal vty number] lines. • Specifying the show line location node-id aux EXEC Example: command displays the terminal parameters of the RP/0/RP0/CPU0:router# show line auxiliary line. • Specifying the show line location node-id console EXEC command displays the terminal parameters of the console. – For the location keyword and node-id argument, enter the location of the Route Processor (RP) on which the respective auxiliary or console port resides. – The node-id argument is expressed in the format of rack/slot/module. • Specifying the show line vty number EXEC command displays the terminal parameters for the specified vty. Step 2 show terminal (Optional) Displays the terminal attribute settings for the current terminal line. Example: RP/0/RP0/CPU0:router# show terminal Step 3 show users (Optional) Displays information about the active lines on the router. Example: RP/0/RP0/CPU0:router# show user Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software This section provides the following configuration examples: • Modifying the Console Template: Example, page 272 • Modifying the Aux Template: Example, page 272 • Modifying the Default Template: Example, page 273 • Configuring a User-Defined Template to Reference the Default vty Pool: Example, page 273 • Configuring a User-Defined Template to Reference a User-Defined vty Pool: Example, page 273 • Configuring a User-Defined Template to Reference the Fault Manager vty Pool: Example, page 274 Cisco IOS XR System Management Configuration Guide SMR-271 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Modifying the Console Template: Example This configuration example shows how to modify the terminal attribute settings for the console line template. In the following configuration example, the following terminal attributes are applied to the console line template: • The EXEC time out for terminal sessions is set to 0 minutes, 0 seconds. Setting the EXEC timeout to 0 minutes 0 seconds disables the EXEC timeout function; thus, the EXEC session for the terminal session will never time out. • The escape character is set to the 0x5a hexadecimal value (the 0x5a hexadecimal value translates into the “Z” character). • The session limit for outgoing terminal sessions is set to 10 minutes. • The disconnect character is set to 0x59 hexadecimal value (the 0x59 hexidecimal character translates into the “Y” character). • The session time out for outgoing terminal sessions is set to 100 minutes (1 hour and 40 minutes). • The allowed transport protocol for incoming terminal sessions is Telnet. • The allowed transport protocol for outgoing terminal sessions is Telnet. ! line console exec-timeout 0 0 escape-character 0x5a session-limit 10 disconnect-character 0x59 session-timeout 100 transport input telnet transport output telnet ! To verify that the terminal attributes for the console line template have been applied to the console, use the show line command: RP/0/0/CPU0:router# show line location 0/0/CPU0 console Tty Speed Modem Uses Noise Overruns Acc I/O * con0/0/CPU0 9600 - - - 0/0 -/- Line con0_0_CPU0, Location "Unknown", Type "Unknown" Length: 24 lines, Width: 80 columns Baud rate (TX/RX) is 9600, 1 parity, 2 stopbits, 8 databits Template: console Config: Allowed transports are telnet. Modifying the Aux Template: Example This configuration example shows how to modify the aux template. In this example, the following terminal attributes are applied to the aux template: • The EXEC time for terminal sessions is set to 1000 minutes and 0 seconds (16 hours and 40 minutes). • The width of the aux terminal screen is set to 90 characters. • The length, the number of lines that will display at one time on the aux terminal screen, is set to 90 lines. Cisco IOS XR System Management Configuration Guide SMR-272 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Configuration Examples for Implementing Physical and Virtual Terminals on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information ! line aux exec-timeout 1000 0 width 90 length 90 ! Modifying the Default Template: Example This configuration example shows how to override the terminal settings for the default line template. In this example, the following terminal attributes override the default line template’s default terminal attribute settings: • The EXEC timeout for terminal sessions is set to 0 minutes 0 seconds. Setting the EXEC timeout to 0 minutes 0 seconds disables the EXEC timeout function; thus, the EXEC session for the terminal session will never time out (the default EXEC timeout for the default line template is 10 minutes). • The width of the terminal screen for the terminals referencing the default template is set to 512 characters (the default width for the default line template is 80 characters). • The length, the number of lines that will display at one time on the terminal referencing the default template, is set to 512 lines (the default length for the default line template is 24 lines). ! line default exec-timeout 0 0 width 512 length 512 ! Configuring a User-Defined Template to Reference the Default vty Pool: Example This configuration example shows how to configure a user-defined line template (named test in this example) for vtys and to configure the line template test to reference the default vty pool: line template test exec-timeout 100 0 width 100 length 100 ! vty-pool default 0 4 line-template test ! Configuring a User-Defined Template to Reference a User-Defined vty Pool: Example This configuration example shows how to configure a user-defined line template (named test2 in this example) for vtys and to configure the line template test to reference a user-defined vty pool (named pool1 in this example): ! line template test2 exec-timeout 0 0 session-limit 10 session-timeout 100 Cisco IOS XR System Management Configuration Guide SMR-273 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information transport input all transport output all ! vty-pool pool1 5 50 line-template test2 ! Configuring a User-Defined Template to Reference the Fault Manager vty Pool: Example This configuration example shows how to configure a user-defined line template (named test3 in this example) for vtys and to configure the line template test to reference the fault manager vty pool: ! line template test3 width 110 length 100 session-timeout 100 ! vty-pool fm 100 106 line-template test3 ! Additional References The following sections provide references related to implementing physical and virtual terminals on Cisco IOS XR software. Cisco IOS XR System Management Configuration Guide SMR-274 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information Related Documents Related Topic Document Title Cisco IOS XR terminal services commands Terminal Services Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2 Standards Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature. MIBs MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml Cisco IOS XR System Management Configuration Guide SMR-275 Implementing Physical and Virtual Terminals on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs RFCs Title No new or modified RFCs are supported by this — feature, and support for existing RFCs has not been modified by this feature. Technical Assistance Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. Cisco IOS XR System Management Configuration Guide SMR-276 R3.3 Beta Draft—Cisco Confidential Information Implementing SNMP on Cisco IOS XR Software Beta Draft Cisco Confidential Information Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network. This module describes the new and revised tasks you need to implement SNMP on your Cisco IOS XR network. Note For detailed conceptual information about SNMP on the Cisco IOS XR software and complete descriptions of the SNMP commands listed in this module, refer to the “Related Documents” section of this module. To locate documentation for other commands that might appear in the course of performing a configuration task, search online in the Cisco IOS XR software master command index. Feature History for Implementing SNMP on Cisco IOS XR Software Release Modification Release 2.0 This feature was introduced on the Cisco CRS-1. Release 3.0 No modification Release 3.2 Support was added for the Cisco XR 12000 Series Router. Release 3.3 No modification. Contents • Prerequisites for Implementing SNMP on Cisco IOS XR Software, page 278 • Information About Implementing SNMP on Cisco IOS XR Software, page 278 • How to Implement SNMP on Cisco IOS XR Software, page 284 • Configuration Examples for Implementing SNMP on Cisco IOS XR Software, page 293 • Additional References, page 297 Cisco IOS XR System Management Configuration Guide SMR-277 Implementing SNMP on Cisco IOS XR Software Prerequisites for Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Prerequisites for Implementing SNMP on Cisco IOS XR Software You must be in a user group associated with a task group that includes the proper task IDs for SNMP commands. Task IDs for commands are listed in the Cisco IOS XR Task ID Reference Guide. For detailed information about user groups and task IDs, see the Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide. Information About Implementing SNMP on Cisco IOS XR Software To implement SNMP, you need to understand the following concepts: • SNMP Functional Overview, page 278 • SNMP Notifications, page 279 • SNMP Versions, page 280 • SNMPv3 Benefits, page 282 • SNMPv3 Costs, page 282 SNMP Functional Overview The SNMP framework consists of three parts: • An SNMP manager • An SNMP agent • A MIB SNMP Manager The SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a network management system (NMS). The term NMS can be applied to either a dedicated device used for network management, or the applications used on such a device. A variety of network management applications are available for use with SNMP. These features range from simple command-line applications to feature-rich graphical user interfaces (such as the CiscoWorks2000 line of products). SNMP Agent The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The agent and MIB reside on the router. To enable the SNMP agent, you must define the relationship between the manager and the agent. Cisco IOS XR System Management Configuration Guide SMR-278 Implementing SNMP on Cisco IOS XR Software Information About Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information MIB The MIB is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580. Note that individual MIB modules are also referred to as MIBs; for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system. The SNMP agent contains MIB variables whose values the SNMP manager can request or change through Get or Set operations. A manager can get a value from an agent or store a value into that agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to manager requests to get or set data. Figure 6 illustrates the communications relationship between the SNMP manager and agent. A manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited notifications (traps) to the manager to notify the manager of network conditions. Figure 6 Communication Between an SNMP Agent and Manager Getting and setting MIB values S3097 Sending responses and traps MIB SNMP manager SNMP agent 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. On the Cisco IOS XR software, unsolicited (asynchronous) notifications can be generated only as traps. Traps are messages alerting the SNMP manager to a condition on the network. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events. Note Inform requests (inform operations) are not supported on the Cisco IOS XR software. Traps are less reliable than informs because the receiver does not send any acknowledgment when it receives a trap. The sender 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 manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination. However, traps are often preferred because informs consume more resources in the router and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, and an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, traps and inform requests provide a trade-off between reliability and resources. In Figure 7, the agent router sends a trap to the SNMP manager. Although the manager receives the trap, it does not send any acknowledgment to the agent. The agent has no way of knowing that the trap reached its destination. Cisco IOS XR System Management Configuration Guide SMR-279 Implementing SNMP on Cisco IOS XR Software Information About Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Figure 7 Trap Recieved by the SNMP Manager Trap SNMP agent SNMP manager SNMP agent SNMP manager S6892 In Figure 8, the agent sends a trap to the manager, but the trap does not reach the manager. Because the agent has no way of knowing that the trap did not reach its destination, the trap is not sent again. The manager never receives the trap. Figure 8 Trap Not Received by the SNMP Manager Trap SNMP agent SNMP manager SNMP agent SNMP manager S6894 SNMP Versions The Cisco IOS XR software supports the following versions of SNMP: • Simple Network Management Protocol Version 1 (SNMPv1) • Simple Network Management Protocol Version 2c (SNMPv2c) • Simple Network Management Protocol Version 3 (SNMPv3) Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers able to access the agent MIB is defined by an IP address access control list and password. SNMPv2c support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required. The SNMPv2c improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions. SNMPv3 is a security model. A security model is an authentication strategy that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level will determine which security mechanism is employed when an SNMP packet is handled. See Table 30 for a list of security levels available in SNMPv3. The SNMPv3 feature supports RFCs 3411 to 3418. Cisco IOS XR System Management Configuration Guide SMR-280 Implementing SNMP on Cisco IOS XR Software Information About Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS-XR software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SMNPv3. Comparison of SNMPv1, v2c, and v3 SNMP v1, v2c, and v3 all support the following operations: • get-request—Retrieves a value from a specific variable. • get-next-request—Retrieves the value following the named variable; this operation is often used to retrieve variables from within a table. With this operation, an SNMP manager does not need to know the exact variable name. The SNMP manager searches sequentially to find the needed variable from within the MIB. • get-response—An operation that replies to a get-request, get-next-request, and set-request sent by an NMS. • set-request—An operation that stores a value in a specific variable. • trap—An unsolicited message sent by an SNMP agent to an SNMP manager when some event has occurred. Table 29 identifies other key SNMP features supported by the SNMP v1, v2c, and v3. Table 29 SNMPv1, v2c, and v3 Feature Support Feature SNMP v1 SNMP v2c SNMP v3 Get-Bulk Operation No Yes Yes Inform Operation No Yes (no on the Yes (no on the Cisco IOS XR software) Cisco IOS XR software) 64 Bit Counter No Yes Yes Textual Conventions No Yes Yes Authentication No No Yes Privacy (Encryption) No No Yes Authorization and Access No No Yes Controls (Views) Security Models and Levels for SNMPv1, v2, v3 The security level determines if an SNMP message needs to be protected from disclosure and if the message needs to be authenticated. The various security levels that exist within a security model are as follows: • noAuthNoPriv—Security level that does not provide authentication or encryption. • authNoPriv—Security level that provides authentication but does not provide encryption. • authPriv—Security level that provides both authentication and encryption. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. The security model combined with the security level determine the security mechanism applied when the SNMP message is processed. Table 30 identifies what the combinations of security models and levels mean. Cisco IOS XR System Management Configuration Guide SMR-281 Implementing SNMP on Cisco IOS XR Software Information About Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 30 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 No Provides authentication based on the HMAC-SHA Hash-Based Message Authentication Code (HMAC) Message Digest 5 (MD5) algorithm or the HMAC Secure Hash Algorithm (SHA). v3 authPriv HMAC-MD5 or DES Provides authentication based on the HMAC-SHA HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encyption Standard (DES) 56-bit encryption in addition to authentication based on the Cipher Block Chaining (CBC) DES (DES-56) standard . SNMPv3 Benefits SNMPv3 provides secure access to devices by providing authentication, encryption and access control. These added security benefits secure SNMP against the following security threats: • masquerade—The threat that an SNMP user may assume the identity of another SNMP user to perform management operations for which that SNMP user does not have authorization. • message stream modification—The threat that messages may be maliciously reordered, delayed, or replayed (to an extent that is greater than can occur through the natural operation of a subnetwork service) to cause SNMP to perform unauthorized management operations. • disclosure—The threat that exchanges between SNMP engines could be eavesdropped. Protecting against this threat may be required as a matter of local policy. In addition, SNMPv3 provides access control over protocol operations on SNMP managed objects. SNMPv3 Costs SNMPv3 authentication and encryption contribute to a slight increase in the response time when SNMP operations on MIB objects are performed. This cost is far outweighed by the security adavantages provided by SNMP v3. Table 31 shows the the order of response time (from least to greatest) for the various security model and security level combinations. Cisco IOS XR System Management Configuration Guide SMR-282 Implementing SNMP on Cisco IOS XR Software Information About Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Table 31 Order of Response Times from Least to Greatest Security Model Security Level SNMPv2c noAuthNoPriv SNMPv3 noAuthNoPriv SNMPv3 authNoPriv SNMPv3 authPriv User-Based Security Model SNMPv3 User-Based Security Model (USM) refers to SNMP message-level security and offers the following services: • Message integrity—Ensures that messages have not been altered or destroyed in an unauthorized manner and that data sequences have not been altered to an extent greater than can occur nonmaliciously. • Message origin authentication—Ensures that the claimed identity of the user on whose behalf received data was originated is confirmed. • Message confidentiality—Ensures that information is not made available or disclosed to unauthorized individuals, entities, or processes. SNMPv3 authorizes management operations only by configured users and encrypts SNMP messages. USM uses two authentication protocols: • HMAC-MD5-96 authentication protocol • HMAC-SHA-96 authentication protocol USM uses CBC-DES (DES-56) as the privacy protocol for message encryption. View-Based Access Control Model The View-Based Access Control Model (VACM) enables SNMP users to control access to SNMP managed objects by supplying read, write, or notify access to SNMP objects. It prevents access to objects restricted by views. These access policies can be set when user groups are configured with the snmp-server group command. MIB Views For security reasons, it is often valuable to be able to restrict the access rights of some groups to only a subset of the management information within the management domain. To provide this capability, access to a management objects is controlled through MIB views, which contain the set of managed object types (and, optionally, the specific instances of object types) that can be viewed. Access Policy Access policy determines the access rights of a group. The three types of access rights are as follows: • read-view access—The set of object instances authorized for the group when objects are read. • write-view access—The set of object instances authorized for the group when objects are written. Cisco IOS XR System Management Configuration Guide SMR-283 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information • notify-view access—The set of object instances authorized for the group when objects are sent in a notification. How to Implement SNMP on Cisco IOS XR Software This section contains the following procedures: • Configuring SNMPv3, page 284 (required) • Configuring SNMP Trap Notifications, page 287 (required) • Setting the Contact, Location, and Serial Number of the SNMP Agent, page 289 (optional) • Defining the Maximum SNMP Agent Packet Size, page 290 (optional) • Changing Notification Operation Values, page 292 (optional) Configuring SNMPv3 This task explains how to configure SNMPv3 for network management and monitoring. Note No specific command enables SNMPv3; the first snmp-server global configuration command that you issue enables SNMPv3. Therefore, the sequence in which you issue the snmp-server commands for this task does not matter. SUMMARY STEPS 1. configure 2. snmp-server engineid local engine-id 3. snmp-server view view-name oid-tree {included | excluded} 4. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify view] [access-list-name] 5. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha}{clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name] 6. end or commit 7. show snmp 8. show snmp engineid 9. show snmp group 10. show snmp users 11. show snmp view Cisco IOS XR System Management Configuration Guide SMR-284 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 snmp-server engineid local engine-id (Optional) Specifies the identification number of the local SNMP engine. Example: RP/0/RP0/CPU0:router(config)# snmp-server engineID local 00:00:00:09:00:00:00:a1:61:6c:20:61 Step 3 snmp-server view view-name oid-tree {included | Creates or modifies a view record. excluded} Example: RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 included Step 4 snmp-server group name {v1 | v2c | v3 {auth | Configures a new SNMP group, or a table that maps noauth | priv}} [read view] [write view] [notify SNMP users to SNMP views. view] [access-list-name] Example: RP/0/RP0/CPU0:router(config)# snmp-server group group_name v3 noauth read view_name1 write view_name2 Step 5 snmp-server user username groupname Configures a new user to an SNMP group. {v1 | v2c | v3 [auth {md5 | sha}{clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name] Example: RP/0/RP0/CPU0:router(config)# snmp-server user noauthuser group_name v3 Cisco IOS XR System Management Configuration Guide SMR-285 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 6 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 7 show snmp (Optional) Displays information about the status of SNMP. Example: RP/0/RP0/CPU0:router# show snmp Step 8 show snmp engineid (Optional) Displays information about the local SNMP engine. Example: RP/0/RP0/CPU0:router# show snmp engineid Step 9 show snmp group (Optional) Displays information about each SNMP group on the network. Example: RP/0/RP0/CPU0:router# show snmp group Step 10 show snmp users (Optional) Displays information about each SNMP username in the SNMP users table. Example: RP/0/RP0/CPU0:router# show snmp users Step 11 show snmp view (Optional) Displays information about the configured views, including the associated MIB view family name, storage type, and status. Example: RP/0/RP0/CPU0:router# show snmp view Cisco IOS XR System Management Configuration Guide SMR-286 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Configuring SNMP Trap Notifications This task explains how to configure the router to send SNMP trap notifications. Note You can omit steps 2 to 4 if you have already completed the steps documented under the “Configuring SNMPv3” task. SUMMARY STEPS 1. configure 2. snmp-server engineid local engine-id 3. snmp-server group name {v1 | v2c | v3 {auth | noauth | priv}} [read view] [write view] [notify view] [access-list-name] 4. snmp-server user username groupname {v1 | v2c | v3 [auth {md5 | sha}{clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name] 5. snmp-server host address [traps] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type] 6. snmp-server traps [notification-type] 7. end or commit 8. show snmp host DETAILED STEPS Command or Action Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 snmp-server engineid local engine-id (Optional) Specifies the identification number of the local SNMP engine. Example: RP/0/RP0/CPU0:router(config)# snmp-server engineID local 00:00:00:09:00:00:00:a1:61:6c:20:61 Step 3 snmp-server group name {v1 | v2c | v3 {auth | Configures a new SNMP group, or a table that maps noauth | priv}} [read view] [write view] [notify SNMP users to SNMP views. view] [access-list-name] Example: RP/0/RP0/CPU0:router(config)# snmp-server group group_name v3 noauth read view_name1 write view_name2 Cisco IOS XR System Management Configuration Guide SMR-287 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Action Purpose Step 4 snmp-server user username groupname Configures a new user to an SNMP group. {v1 | v2c | v3 [auth {md5 | sha}{clear | encrypted} auth-password [priv des56 {clear | encrypted} priv-password]]} [access-list-name] Example: RP/0/RP0/CPU0:router(config)# snmp-server user noauthuser group_name v3 Step 5 snmp-server host address [traps] [version {1 | 2c | Specifies SNMP trap notifications, the version of 3 [auth | noauth | priv]}] community-string SNMP to use, the security level of the notifications, [udp-port port] [notification-type] and the recipient (host) of the notifications. Example: RP/0/RP0/CPU0:router(config)# snmp-server host 12.26.25.61 traps version 3 noauth userV3noauth Step 6 snmp-server traps [notification-type] Enables the sending of trap notifications and specifies the type of trap notifications to be sent. Example: • If a trap is not specified with the notification-type RP/0/RP0/CPU0:router(config)# snmp-server traps bgp argument, all supported trap notifications are enabled on the router. To display which trap notifications are available on your router, enter the snmp-server traps ? command. Step 7 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Step 8 show snmp host (Optional) Displays information about the configured SNMP notification recipient (host), port number and security model. Example: RP/0/RP0/CPU0:router# show snmp host Cisco IOS XR System Management Configuration Guide SMR-288 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Setting the Contact, Location, and Serial Number of the SNMP Agent This task explains how to set the system contact string, system location string, and system serial number of the SNMP agent. Note The sequence in which you issue the snmp-server commands for this task does not matter. SUMMARY STEPS 1. configure 2. snmp-server contact system-contact-string 3. snmp-server location system-location 4. snmp-server chassis-id serial-number 5. end or commit DETAILED STEPS Command or Actions Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 snmp-server contact system-contact-string (Optional) Sets the system contact string. Example: RP/0/RP0/CPU0:router(config)# snmp-server contact Dial System Operator at beeper # 27345 Step 3 snmp-server location system-location (Optional) Sets the system location string. Example: RP/0/RP0/CPU0:router(config)# snmp-server location Building 3/Room 214 Cisco IOS XR System Management Configuration Guide SMR-289 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Actions Purpose Step 4 snmp-server chassis-id serial-number (Optional) Sets the system serial number. Example: RP/0/RP0/CPU0:router(config)# snmp-server chassis-id 1234456 Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Defining the Maximum SNMP Agent Packet Size This task shows how to configure the largest SNMP packet size permitted when the SNMP server is receiving a request or generating a reply. Note The sequence in which you issue the snmp-server commands for this task does not matter. SUMMARY STEPS 1. configure 2. snmp-server packetsize byte-count 3. end or commit Cisco IOS XR System Management Configuration Guide SMR-290 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information DETAILED STEPS Command or Actions Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 snmp-server packetsize byte-count (Optional) Sets the maximum packet size. Example: RP/0/RP0/CPU0:router(config)# snmp-server packetsize 1024 Step 3 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Cisco IOS XR System Management Configuration Guide SMR-291 Implementing SNMP on Cisco IOS XR Software How to Implement SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Changing Notification Operation Values Once SNMP notifications have been enabled, you can specify a value other than the default for the source interface, message queue length, or retransmission interval. This task explans how to specify a source interface for trap notifications, the message queue length for each host, and the retransmission interval. Note The sequence in which you issue the snmp-server commands for this task does not matter. SUMMARY STEPS 1. configure 2. snmp-server trap-source interface-type interface-number 3. snmp-server queue-length length 4. snmp-server trap-timeout seconds 5. end or commit DETAILED STEPS Command or Actions Purpose Step 1 configure Enters global configuration mode. Example: RP/0/RP0/CPU0:router# configure Step 2 snmp-server trap-source interface-type (Optional) Specifies a source interface for trap interface-number notifications. Example: RP/0/RP0/CPU0:router(config)# snmp-server trap-source POS 0/0/1/0 Step 3 snmp-server queue-length length (Optional) Establishes the message queue length for each notification. Example: RP/0/RP0/CPU0:router(config)# snmp-server queue-length 20 Cisco IOS XR System Management Configuration Guide SMR-292 Implementing SNMP on Cisco IOS XR Software Configuration Examples for Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Command or Actions Purpose Step 4 snmp-server trap-timeout seconds (Optional) Defines how often to resend notifications on the retransmission queue. Example: RP/0/RP0/CPU0:router(config)# snmp-server trap-timeout 20 Step 5 end Saves configuration changes. or • When you issue the end command, the system commit prompts you to commit changes: Uncommitted changes found, commit them Example: before exiting(yes/no/cancel)? RP/0/RP0/CPU0:router(config)# end [cancel]: or – Entering yes saves configuration changes to RP/0/RP0/CPU0:router(config)# commit the running configuration file, exits the configuration session, and returns the router to EXEC mode. – Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes. – Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes. • Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session. Configuration Examples for Implementing SNMP on Cisco IOS XR Software This section provides the following configuration examples: • Configuring SNMPv3: Example, page 293 • Configuring Trap Notifications: Example, page 296 Configuring SNMPv3: Example Setting an Engine ID This example shows how to set the identification of the local SNMP engine: RP/0/RP0/CPU0:MiniQ(config)# snmp-server engineID local 00:00:00:09:00:00:00:a1:61:6c:20:61 Note Once the engine ID has been configured, the SNMP agent restarts. Cisco IOS XR System Management Configuration Guide SMR-293 Implementing SNMP on Cisco IOS XR Software Configuration Examples for Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information Verifying the Identification of the Local SNMP Engines This example shows how to verify the identification of the local SNMP engine: RP/0/RP0/CPU0:router(config)# show snmp engineid SNMP engineID 00000009000000a1ffffffff Creating a View There are two ways to create a view: • You can include the object identifier (OID) of an ASN.1 subtree of a MIB family from a view by using the included keyword of the snmp-server view command. • You can exclude the OID subtree of the ASN.1 subtree of a MIB family from a view by using the excluded keyword of the snmp-server view command. This example shows how to create a view that includes the sysName (1.3.6.1.2.1.1.5) object: RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 included This example shows how to create a view that includes all the OIDs of a system group: RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included This example shows how to create a view that includes all the OIDs under the system group except the sysName object (1.3.6.1.2.1.1.5), which has been excluded: RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1 included RP/0/RP0/CPU0:router(config)# snmp-server view view_name 1.3.6.1.2.1.1.5 excluded Verifying Configured Views This example shows how to display information about the configured views: RP/0/RP0/CPU0:router# show snmp view v1default 1.3.6.1 - included nonVolatile active view_name 1.3.6.1.2.1.1 - included nonVolatile active view_name 1.3.6.1.2.1.1.5 - excluded nonVolatile active Creating Groups If you do not explicity specify a notify, read, or write view, the Cisco IOS XR software uses the v1 default (1.3.6.1). This example shows how to create a group that utilizes the default view: RP/0/RP0/CPU0:router(config)# snmp-server group group-name v3 auth The following configuration example shows how to create a group that has read access to all the OIDs in the system except the sysUpTime object (1.3.6.1.2.1.1.3), which has been excluded from the view applied to the group, but write access only to the sysName object (1.3.6.1.2.1.1.5): ! snmp-server view view_name1 1.3.6.1.2.1.1 included snmp-server view view_name1 1.3.6.1.2.1.1.3 excluded snmp-server view view_name2 1.3.6.1.2.1.1.5 included snmp-server group group_name v3 auth read view_name1 write view_name2 ! Verifying Groups This example shows how to verify the attributes of configured groups: RP/0/RP0/CPU0:router# show snmp group groupname: group_name security model:usm readview : view_name1 writeview: view_name2 Cisco IOS XR System Management Configuration Guide SMR-294 Implementing SNMP on Cisco IOS XR Software Configuration Examples for Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information notifyview: v1default row status: nonVolatile Creating and Verifying Users Given the following SNMPv3 view and SNMPv3 group configuration: ! snmp-server view view_name1 1.3.6.1.2.1.1 included snmp-server group group_name v3 noauth read view_name write view-name ! This example shows how to create a noAuthNoPriv user with read and write view access to a system group: RP/0/RP0/CPU0:router(config)# snmp-server user noauthuser group_name v3 Note The user must belong to a noauth group before a noAuthNoPriv user can be created. This example shows how to verify the attributes that apply to the SNMP user: RP/0/RP0/CPU0:router# show snmp user User name: noauthuser Engine ID: localSnmpID storage-type: nonvolatile active Given the following SNMPv3 view and SNMPv3 group configuration: ! snmp-server view view_name 1.3.6.1.2.1.1 included snmp group group_name v3 priv read view_name write view_name ! This example shows how to create authNoPriv user with read and write view access to a system group: RP/0/RP0/CPU0:router(config)# snmp-server user authuser group_name v3 auth md5 clear auth_passwd Note Because the group is configured at a security level of Auth, the user must be configured as auth at a minimum to access this group (priv users could also access this group). The authNoPriv user configured in this group, authuser, must supply an authentication password to access the view. In the example, auth_passwd is set as the authentication password string. Note that that clear keyword is specified before the auth_passwd password string. The clear keyword indicates that the password string being supplied is unencrypted. This example shows how to verify the attributes that apply to SNMP user: RP/0/RP0/CPU0:router# show snmp user User name: authuser Engine ID: localSnmpID storage-type: nonvolatile active Given the following SNMPv3 view and SNMPv3 group configuration: ! snmp view view_name 1.3.6.1.2.1.1 included snmp group group_name v3 priv read view_name write view_name ! Cisco IOS XR System Management Configuration Guide SMR-295 Implementing SNMP on Cisco IOS XR Software Configuration Examples for Implementing SNMP on Cisco IOS XR Software R3.3 Beta Draft—Cisco Confidential Information This example shows how to create an authPriv user with read and write view access to a system group: RP/0/RP0/CPU0:router(config)# snmp-server user privuser group_name v3 auth md5 clear auth_passwd priv des56 clear priv_passwd Note Because the group has a security level of Priv, the user must be configured as a priv user to access this group. In this example, the user, privuser, must supply both an authentication password and privacy password to access the OIDs in the view. This example shows how to verify the attributes that apply to the SNMP user: RP/0/RP0/CPU0:router# show snmp user User name: privuser Engine ID: localSnmpID storage-type: nonvolatile active Configuring Trap Notifications: Example The following example configures an SNMP agent to send out different types of traps. The configuration includes a v2c user , a noAuthNoPriv user, anauthNoPriv user, and an AuthPriv user: Note The default User Datagram Protocol (UDP) port is 161. If you do not a specify a UDP port with the udp-port keyword and port argument, then the configured SNMP trap notifications are sent to port 161. ! snmp-server host 10.50.32.170 version 2c userv2c udp-port 2345 snmp-server host 10.50.32.170 version 3 auth userV3auth udp-port 2345 snmp-server host 10.50.32.170 version 3 priv userV3priv udp-port 2345 snmp-server host 10.50.32.170 version 3 noauth userV3noauth udp-port 2345 snmp-server user userv2c groupv2c v2c snmp-server user userV3auth groupV3auth v3 auth md5 encrypted 140F0A13 snmp-server user userV3priv groupV3priv v3 auth md5 encrypted 021E1C43 priv des56 encrypted 1110001C snmp-server user userV3noauth groupV3noauth v3 LROwner snmp-server view view_name 1.3 included snmp-server community public RW snmp-server group groupv2c v2c read view_name snmp-server group groupV3auth v3 auth read view_name snmp-server group groupV3priv v3 priv read view_name snmp-server group groupV3noauth v3 noauth read view_name ! This example shows how to verify the configuration SNMP trap notification recipients host, the receipients of SNMP trap notifications. The output displays the following information: • The IP address of the configured notification host • The UDP port where SNMP notification messages are sent • The type of trap configured • The security level of the configured user • The security model configured RP/0/RP0/CPU0:router(config)# show snmp host Notification host: 10.50.32.170 udp-port: 2345 type: trap Cisco IOS XR System Management Configuration Guide SMR-296 Implementing SNMP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information user: userV3auth security model: v3 auth Notification host: 10.50.32.170 udp-port: 2345 type: trap user: userV3noauth security model: v3 noauth Notification host: 10.50.32.170 udp-port: 2345 type: trap user: userV3priv security model: v3 priv Notification host: 10.50.32.170 udp-port: 2345 type: trap user: userv2c security model: v2c Additional References The following sections provide references related to Implementing SNMP on Cisco IOS XRsoftware. Related Documents Related Topic Document Title Cisco IOS XR SNMP commands SNMP Server Commands on Cisco IOS XR Software, Release 3.2 Cisco IOS XR master command index Cisco IOS XR Commands Master List, Release 3.2 Cisco IOS XR getting started material Cisco IOS XR Getting Started Guide, Release 3.2 Information about user groups and task IDs Configuring AAA Services on Cisco IOS XR Software module of the Cisco IOS XR System Security Configuration Guide, Release 3.2 Standards Standards Title No new or modified standards are supported by this — feature, and support for existing standards has not been modified by this feature. MIBs MIBs MIBs Link There are no applicable MIBs for this module. To locate and download MIBs for selected platforms using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL: http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml Cisco IOS XR System Management Configuration Guide SMR-297 Implementing SNMP on Cisco IOS XR Software Additional References R3.3 Beta Draft—Cisco Confidential Information RFCs RFCs Title RFC 3411 An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks RFC 3412 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) RFC 3413 Simple Network Management Protocol (SNMP) Applications RFC 3414 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) RFC 3415 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) RFC 3416 Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP) RFC 3417 Transport Mappings for the Simple Network Management Protocol (SNMP) RFC 3418 Management Information Base (MIB) for the Simple Network Management Protocol (SNMP) Technical Assistance Description Link The Cisco Technical Support website contains http://www.cisco.com/techsupport thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. Cisco IOS XR System Management Configuration Guide SMR-298 INDEX broadcast command SMR-149 HC Cisco IOS XR Interface and Hardware Component Configuration Guide broadcastdelay command SMR-148 IC Cisco IOS XR IP Addresses and Services Configuration Guide MCC Cisco IOS XR Multicast Configuration Guide MPC Cisco IOS XR MPLS Configuration Guide C QC Cisco IOS XR Modular Quality of Service Configuration Guide CDP RC Cisco IOS XR Routing Configuration Guide enabling SMR-33, SMR-39 SC Cisco IOS XR System Security Configuration Guide functional overview SMR-32 SMC Cisco IOS XR System Management Configuration Guide modifying default settings SMR-35, SMR-39 A monitoring SMR-36 cdp (global) command SMR-34 access-group command SMR-151 cdp (interface) command SMR-34 admin-config-pairing submode cdp advertise v1 command SMR-35 location command 234 cdp holdtime command SMR-35 See pairing command cdp timer command SMR-36 admin-config-sdr submode clear logging correlator delete all-in-buffer location command 235, 236, 238, 239, 243, 245, 247, 249 command SMR-15 See sdr command clear logging correlator delete command SMR-14 admin-config submode clear logging delete command SMR-14 sdr command 234, 238, 251 clear logging events delete first command SMR-23 See admin configure command clear logging events delete group command SMR-24 admin configure command 234, 238, 242, 244, 246, 248, 251, clear logging events delete last command SMR-24 253, 256 clear logging events delete location command SMR-23 alarms clear logging events delete message command SMR-24 bi-state alarms SMR-6 clear logging events delete timestamp-lo-limit capacity threshold setting SMR-6 command SMR-23 severity level and filtering SMR-5 clear logging events reset all-in-buffer command SMR-24 ALDEMS (Alarm Management and Debugging Event System), description SMR-2 authenticate command SMR-153 E authentication-key command SMR-153 error messages levels SMR-119 B logging keywords (table) SMR-119 broadcast client command SMR-148 Cisco IOS XR System Management Configuration Guide OL-5550-05 IN-299 Index logging events buffer SMR-4 F buffer settings, modifying SMR-11 fault manager environment command SMR-104, SMR-105 logging events buffer-size command SMR-12 fault manager policy command SMR-106, SMR-108 logging events level command SMR-13 logging events threshold command SMR-12 logging facility command SMR-125 G logging history command SMR-127 get-next-request SMR-281 logging history size command SMR-127 get-request SMR-281 logging hostname prefix command SMR-125 get-response SMR-281 logging monitor command SMR-123 logging on command SMR-121 logging process SMR-4 L logging source-interface command SMR-126 line aux command SMR-262, SMR-267 logging suppress duplicates command SMR-132 line command SMR-262 logging trap command SMR-125 line console command SMR-262, SMR-267 line default command SMR-262, SMR-267 M line template command SMR-262, SMR-268 line template configuration submode SMR-262 master command SMR-159 description SMR-262 message logging See line aux command facility types See line command (table) SMR-117 See line console command syslog server SMR-117 to ?? See line default command MIB, description SMR-279 See line template command location command 234, 235, 236, 238, 239, 243, 245, 247, 249 N logging buffered command SMR-121 logging command SMR-125 no logging events link-status command SMR-133 logging console command SMR-122 NTP logging correlation SMR-4 configuring an authoritative NTP server SMR-158 correlation rules, configuring SMR-25, SMR-26 configuring broadcast-based NTP logging correlation rules SMR-4 associations SMR-147, SMR-162 applying SMR-7, SMR-10 configuring NTP access groups SMR-149 configuring SMR-7 configuring NTP authentication SMR-152, SMR-163 logging correlator apply-rule command SMR-10 configuring poll-based associations SMR-145, SMR-162 logging correlator buffer SMR-3 configuring the source IP address SMR-156, SMR-165 buffer settings, modifying SMR-13 disabling NTP services on an interface SMR-154 logging correlator buffer-size command SMR-14 functional overview SMR-144 logging correlator rule command SMR-8 updating the hardware clock SMR-159, SMR-166 Cisco IOS XR System Management Configuration Guide IN-300 OL-5550-05 Index default line template P description SMR-262 pairing command 234 modifying SMR-266, SMR-273 pairing-config submode line template configuration submode, pairing command 234 description SMR-262 peer command SMR-147 line template guidelines SMR-263 Performance Management (PM) benefits SMR-172 R functional overview SMR-170 PM entity instance monitoring RFC 3411, An Architecture for Describing Simple Network Management Protocol (SNMP) enabling SMR-196 Management Frameworks SMR-298 overview SMR-177 RFC 3412, Message Processing and Dispatching for the PM statistics collection, overview SMR-172 Simple Network Management Protocol (SNMP) SMR-298 PM statistics collection templates RFC 3413, Simple Network Management Protocol creating SMR-173, SMR-192, SMR-202 (SNMP) Applications SMR-298 description SMR-172 RFC 3414, User-based Security Model (USM) for version disabling SMR-173, SMR-193 3 of the Simple Network Management Protocol enabling SMR-173, SMR-193, SMR-202 (SNMPv3) SMR-298 TFTP server, configuring SMR-190 RFC 3415, View-based Access Control Model (VACM) for the Simple Network Management Protocol PM Statistics Collector, description SMR-171 (SNMP) SMR-298 PM Statistics Server, description SMR-170 RFC 3416, Version 2 of the Protocol Operations for the PM threshold monitoring, overview SMR-181 Simple Network Management Protocol (SNMP) SMR-298 PM threshold monitoring templates RFC 3417, Transport Mappings for the Simple Network creating SMR-181, SMR-196, SMR-198 Management Protocol (SNMP) SMR-298 disabling SMR-189, SMR-199 RFC 3418, Management Information Base (MIB) for the enabling SMR-189, SMR-199, SMR-202 Simple Network Management Protocol (SNMP) SMR-298 performance-mgmt apply monitor command SMR-197 performance-mgmt apply statistics command SMR-194 performance-mgmt apply thresholds command SMR-200 S performance-mgmt resources tftp-server SMR-191 sdr command 234, 238, 251 performance-mgmt statistics command SMR-192 server command SMR-147 performance-mgmt thresholds command SMR-198 service timestamps debug datetime command SMR-129 physical terminals service timestamps debug uptime command SMR-129 aux line template service timestamps disable command SMR-131 description SMR-262 service timestamps log datetime command SMR-129 modifying SMR-266, SMR-272 service timestamps log uptime command SMR-129 console line template set-request SMR-281 description SMR-262 show cdp command SMR-36 modifying SMR-266, SMR-272 Cisco IOS XR System Management Configuration Guide OL-5550-05 IN-301 Index show cdp entry command SMR-37 show ntp associations command SMR-161 show cdp interface command SMR-37 show ntp status command SMR-161 show cdp neighbors command SMR-37 show snmp command SMR-286 show cdp traffic command SMR-37 show snmp engineid command SMR-286 show fault manager environment command SMR-104, show snmp group command SMR-286 SMR-105 show snmp host command SMR-288 show fault manager policy available command SMR-108 show snmp users command SMR-286 show fault manager policy registered command SMR-109 show snmp view command SMR-286 show line command SMR-271 show terminal command SMR-271 show logging command SMR-134 show users command SMR-271 show logging correlator buffer all-in-buffer SNMP (Simple Network Management Protocol) command SMR-15, SMR-22 agent, description SMR-278 show logging correlator buffer correlationID command SMR-22 manager, description SMR-278 show logging correlator buffer rule-name MIB, description SMR-279 command SMR-22 trap notifications show logging correlator info command SMR-14, SMR-22 configuring SMR-287, SMR-296 show logging correlator rule all command SMR-8 versions SMR-280 show logging correlator rule command SMR-8, SMR-10 security models and levels SMR-281 show logging events buffer all-in-buffer SNMPv1,v2c, and v3 comparison SMR-281 command SMR-21 SNMPv3, configuring SMR-284, SMR-293 show logging events buffer first command SMR-19 SNMPv3, creating a view SMR-294 show logging events buffer group command SMR-18 SNMPv3, creating groups SMR-294 show logging events buffer last command SMR-19 SNMPv3, creating users SMR-295 show logging events buffer location command SMR-20 SNMPv3, setting an engine ID SMR-293 show logging events buffer message command SMR-18 SNMPv3 benefits SMR-282 show logging events buffer severity-hi-limit command SMR-16 SNMPv3 costs SMR-282 show logging events buffer severity-lo-limit snmp-server chassis-id command SMR-290 command SMR-16 snmp-server contact command SMR-289 show logging events buffer timestamp-hi-limit snmp-server enable traps command SMR-288 command SMR-17 snmp-server engineid local command SMR-285 show logging events buffer timestamp-lo-limit command SMR-17 snmp-server group command SMR-285 show logging events info command SMR-12 snmp-server host command SMR-288 show logging history command SMR-128 snmp-server location command SMR-289 show logging location command SMR-134 snmp-server packetsize command SMR-291 show logging lower-limit-timestamp command SMR-134 snmp-server queue-length command SMR-292 show logging process command SMR-134 snmp-server trap source command SMR-292 show logging string command SMR-134 snmp-server trap-timeout command SMR-293 show logging upper-limit-timestamp command SMR-134 snmp-server user command SMR-285 snmp-server view command SMR-285 Cisco IOS XR System Management Configuration Guide IN-302 OL-5550-05 Index SNMPv1 trusted-key command SMR-153 See SNMP SNMPv2c U See SNMP SNMPv3 update-calendar command SMR-160 See SNMP source command SMR-157 V Syslog configuring logging to a remote server SMR-122 virtual terminals configuring logging to the console SMR-120, SMR-139 default line template configuring the logging buffer SMR-120, SMR-139 description SMR-262 configuring the logging history table SMR-126, SMR-139 modifying SMR-266, SMR-273 disabling the logging of link-status messages SMR-133 line template configuration submode displaying system logging messages SMR-134 description SMR-262 enabling logging for the current terminal line template guidelines SMR-264 session SMR-116 user-defined line templates hostname prefix logging SMR-117 configuring SMR-273, SMR-274 logging history table SMR-118 description SMR-262 modifying time stamps SMR-129, SMR-131, SMR-139 vty pools sending syslog messages to destinations other than the console SMR-116 configuring SMR-273 setting up destinations for syslog messages SMR-122, creating SMR-268 SMR-139 default fault manager pool SMR-264 severity level command defaults SMR-120 default vty pool SMR-264 severity level definitions SMR-119 description SMR-264 severity levels SMR-118 modifying SMR-268 suppressing duplicate syslog messages SMR-132 vty pool command SMR-269 syslog message destinations SMR-115 vty pool default command SMR-269 syslog source address logging SMR-117 vty pool fm command SMR-269 system logging messages SMR-114 system logging process SMR-114 UNIX syslog daemon configuration SMR-118 UNIX system logging facilities SMR-117 T terminal monitor command SMR-124 trap SMR-281 trap notifications SMR-279 Cisco IOS XR System Management Configuration Guide OL-5550-05 IN-303