Adc Cuda 3 Users Manual Command
3 to the manual 3c76597a-c556-435c-a63e-864ed41d4b50
2015-02-05
: Adc Adc-Cuda-3-Users-Manual-504875 adc-cuda-3-users-manual-504875 adc pdf
Open the PDF directly: View PDF 
.
Page Count: 620
| Download | |
| Open PDF In Browser | View PDF |
Cuda 12000 IP Access Switch CLI-based Administration Guide Release 3.0 PART NO. 780-000052-00 PUBLISHED SEPTEMBER 2001 http://www.adc.com ADC Telecommunications, Inc. 8 Technology Drive Westborough, MA 01581 ADC Telecommunications, Inc. (herein referred to as “ADC”) may revise this manual at any time without notice. All statements, technical information, and recommendations contained herein are believed to be accurate and reliable at the time of publication but are presented without any warranty of any kind, express or implied, (including the warranties of merchantability and fitness and against infringement or interferrence with your enjoyment of the information) and you are solely responsible for your use of this manual with any equipment or software described herein. This manual (in whole or in part, including all files, data, documentation, and digital and printed copies made therefrom) is protected by United States copyright laws, international treaties and all other applicable national or international laws. With the exception of materials printed for use by a user who is authorized by separate license from ADC, this manual may not, in whole or part, be modified, excerpted, copied, photocopied, translated, or reduced to any electronic medium or machine readable form, without ADC’s written consent obtained prior thereto. The CUDA 12000 is listed to UL 1950 Third Edition and CAN/CSA-C22.2 No. 950-95 Third Edition compliance. The following information is for compliance by Class A devices with FCC regulations: the equipment described in this manual has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC regulations. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case you will be required to correct the interference at your own expense. You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following methods. ■ Turn television or radio antenna until the interference stops. ■ Move equipment to one side or the other of the television or radio. ■ Move equipment farther away from the television or radio. ■ Plug equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.) Modifications to this equipment that are not authorized by ADC could void the FCC certification and UL approval and negate your authority to operate the equipment. This manual is provided by ADC on an ”AS IS, WITH ALL FAULTS” basis, without any representation or warranty of any kind, either express or implied, including without limitation any representations or endorsements regarding use of, the results of, or performance of the equipment or software, its appropriateness, accuracy, reliability, or correctness. You assume the entire risk as to the use of this manual. ADC does not assume liability for the use of this manual beyond its original purchase price. In no event will ADC be liable for additional direct or indirect damages including any lost profits, lost savings, lost revenue or other incidental or consequential damages arising from any defects, or the use or inability to use this manual or the equipment or software described herein, even if ADC has been advised of the possibility of such damages. Cuda 12000, MeshFlow, CudaView, FastFlow Broadband Provisioning Manager and CableOnce are trademarks of ADC Telecommunications, Inc. CableLabs® is a registered trademark of Cable Television Laboratories, Inc. Java® is a registered trademark of Sun Microsystems, Inc. in the United States and other countries. Jini™ is a trademark of Sun Microsystems, Inc. in the United States and other countries. The Cuda 12000 includes RSA BSAFE cryptographic or security protocol software from RSA security. The Cuda 12000 contains an integrated DOCSIS-compliant provisioning server. Use of this provisioning functionality is restricted to licensed authorization. ADC will not support provisioning for for your use thereof if you are not authorized by the appropriate software license to use such provisioning. All other company and product names mentioned herein may be trademarks of their respective companies. The equipment and software described herein may be covered by an ADC warranty statement. You may obtain a copy of the applicable warranty by referring to www.adc.com/cable/support and selecting the technical assistance link. What follows is a summary of the warranty statement. The summary is not binding on ADC and is provided to you merely as a convenience. The equipment warranty usually lasts twelve (12) months from point of shipment and the software warranty usually lasts sixty (60) days from the point of shipment. The software warranty covers both functionality as well as the media on which the software is delivered. Neither warranty entitles the customer to receive free and unlimited access for technical assistance. A separate technical support agreement must be purchased for unlimited access to technical support resources. The equipment warranty only applies to the cost of a replacement component. It does not include the labor charge for installation of the replacement component. During the warranty period, warranty claims will be processed on a 10-day return to factory basis. Once the defective component is returned to the factory, ADC’s sole liability under the equipment warranty shall be either: ■ To repair or to replace, at ADC’s option, the defective equipment component with a new or refurbished component; or ■ If after repeated efforts ADC is unable to resolve the defect by repair or replacement, to refund the purchase price of the equipment or component upon return of the defective item. A working component will be returned to the customer within 10 days after it is received by ADC. The warranty period for repaired or replaced equipment components shall be the remainder of the original warranty period for the repaired or replaced item or ninety (90) days, whichever is greater. Equipment warranty claims can be processed on-line through a web interface or directly by a customer support representative of ADC. As part of the standard process for issuing a Return Materials Authorization (RMA), the Customer Support organization will verify all reported failures prior to authorizing a shipment of a replacement part. The equipment warranty does not cover any of the following events: ■ The equipment has been subject to abnormal use, abnormal conditions, improper storage, exposure to moisture or dampness, unauthorized modifications, unauthorized connections, unauthorized repair, misuse, neglect, abuse, accident, alteration, improper installation, or other events which are not the fault of ADC, including damage caused by shipping; ■ ADC or an authorized ADC distributor or reseller was not notified by the customer of the equipment defect during the applicable warranty period. If the software media is unusable such that the software cannot be loaded onto the equipment, ADC will replace the media within 1 business day after ADC is notified through Technical Assistance Center. During the software warranty period, ADC will provide software updates and/or maintenance releases at no additional charge to resolve any issues where the software does not function according to software specification. In order to receive on-going software maintenance releases after the 60-day warranty period, the customer must purchase the base level technical assistance agreement. The software warranty does not cover any of the following events: ■ Unauthorized modifications to the software or firmware; ■ Unauthorized installation of non-ADC software on the Cuda 12000 platform; ■ ADC or an authorized ADC distributor or reseller was not notified by the customer of the software defect during the applicable warranty period. Non-ADC software may be warranted by its developer, owner or other authorized entity as expressly provided in the documentation accompanying such software. Failures caused by non-ADC software are not covered by ADC’s warranty and service activities to remedy such failures will be billed to the customer. Remote technical assistance will be provided free of charge during the 60-day software warranty period. The hours for support during the warranty period are Monday through Friday from 8:00am to 5:00pm EST. Additional hardware and software services are available by purchasing an extended service agreement. Contact your account representative or call 1-877-227-9783 for further details. © 2001 ADC Telecommunications, Inc. All Rights Reserved. CONTENTS CUDA 12000 IP ACCESS SWITCH CLI-BASED ADMINISTRATION GUIDE ABOUT THIS GUIDE Document Objective 16 Audience 16 Document Organization 17 Notations 19 Command Syntax 20 Related Documentation 21 Contacting Customer Support 21 I ADMINISTRATION OVERVIEW 1 CUDA 12000 OVERVIEW Introducing the Cuda 12000 IP Access Switch 26 Hardware 27 Software 30 Minimum Chassis Configuration 31 Understanding the Cuda 12000 Within Your Network Cable Modem Termination System (CMTS) 33 IP Routing Configuration 33 2 ABOUT THE COMMAND LINE INTERFACE About the CLI 35 Accessing the CLI 37 Command Modes 40 Global Commands 42 Root Mode 44 Physical Interface Mode 46 32 IP Interface Mode 50 OSPF Global Configuration Mode 51 Import and Export OSPF Route Filter Modes 53 RIP Configuration Mode 54 Import and Export RIP Route Filter Modes 55 Slot Mode 56 3 MANAGING USER ACCOUNTS Understanding User Accounts 57 Configuring Access Profiles 58 Creating and Modifying Access Profiles 60 Displaying Access Profiles 61 Deleting a Profile 62 Managing User Accounts 63 Creating and Modifying User Accounts 64 Displaying User Accounts 65 Deleting User Accounts 66 Configuring User Authentication 67 Configuring Local Authentication 68 Configuring TACACS+ Authentication 69 Configuring RADIUS Authentication 71 II CHASSIS ADMINISTRATION 4 CHASSIS CONFIGURATION Understanding Chassis Identification 76 Understanding Management Module Redundancy Configuring Chassis Parameters 78 Displaying Current Chassis Configuration 81 Configuring Clock Sources 86 Starting and Stopping the HTTP Server 88 Enabling and Disabling Traffic Relay 89 Broadcasting Messages to Users 91 76 5 MULTI-CHASSIS SUPPORT About Multi-Chassis Support 94 Planning Multi-Chassis Support 96 Enabling the Jini Lookup Service 97 Configuring Multi-Chassis Support 98 Creating a Common User Account for the Group Viewing Chassis Details 101 6 100 MODULE ADMINISTRATION Cuda Application Modules 104 Configuring the 10/100 Ethernet and GigE Modules 105 Viewing Module Information 106 Viewing Installed Modules 106 Viewing Module Versions 108 Viewing Ethernet Interface Packet Statistics 110 Displaying Statistics for All System Interfaces 112 7 PACKET OVER SONET ADMINISTRATION About Packet Over SONET 116 Packet Over SONET (POS) Interface Administration Displaying POS Interface Information 119 Disabling and Enabling Interfaces 123 Viewing POS Interface Packet Statistics 124 Viewing SONET Line-Layer Information 126 Viewing SONET Path Layer Information 127 Section Layer Administration 129 Configuring and Viewing SONET Alarms 132 Configuring POS Alarm Reporting 133 Viewing Alarm Information 135 Configuring Point-to-Point Protocol (PPP) 137 Configuring PPP Security 138 Configuring LCP 144 Enabling NCP 146 117 8 TIMING AND ALARM CONTROLLER MANAGEMENT About Timing and Alarm Controller Fault Reporting Assertion Levels 150 Configuring the Power Assertion Level 151 Configuring Fan Unit Assertion Levels 152 Configuring Fault Reporting 153 Removing a Fault Notification 155 Viewing Fault Reporting Status 156 Configuring Alarms Out 157 Viewing Alarm Signals Out the DB-15 Connector 9 148 160 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) About SNMP 162 Configuring SNMP Access Control 164 Configuring SNMP Access Views 165 Configuring SNMP Groups 168 Configuring SNMP Communities 172 Configuring SNMPv3 Users 175 Configuring SNMPv3 Contexts 178 Configuring System Name, Contact, and Location 180 Configuring SNMP Event Notification Types 182 Monitoring SNMP 196 Sample SNMP Configurations 198 Sample SNMPv1/v2c Community Access Control 198 Sample SNMPv3 Access Control 199 Sample Notification Configuration 201 10 MANAGING SYSTEM EVENTS About System Events 204 Configuring the Syslog Server 205 Configuring SNMP Trap Recipients 206 Removing SNMP Trap Recipients 207 Configuring Event Transmission 208 Event Reporting 210 Event Classes 210 Reporting Actions 211 Configuring Event Reporting 211 Viewing Event Reporting Configuration 213 Event Classes and SNMP System Events 214 Clearing the Event Log 216 Displaying Event Transmission, Reporting, and Syslog Parameters Displaying the Event Log 218 III IP ROUTING 11 CREATING ROUTE FILTERS About RIP and OSPF Route Maps 224 Creating Route Maps 225 Using the Match Command 227 Using the Override Command 228 Creating OSPF Import Route Maps 229 Creating OSPF Export Route Maps 231 Creating RIP Import Route Maps 234 Creating RIP Export Route Maps 236 Creating Map Lists 239 Route Filter Configuration Example 241 12 CONFIGURING DHCP RELAY About DHCP Relay 244 Displaying DHCP Relay Configuration 245 Configuring DHCP Relay Options 247 Specifying DHCP Servers 249 Specifying External DHCP Servers 249 Specifying the Internal DHCP Server 250 DHCP and BOOTP Policies 251 About DHCP Policies 251 About BOOTP Policies 252 Configuring DHCP and BOOTP Policies 253 DHCP Policy Configuration Examples 259 216 13 CONFIGURING DHCP AUTHORITY About DHCP Authority 264 Enabling DHCP Authority 266 Configuring DHCP Authority Ranges 267 Removing DHCP Authority Ranges 268 DHCP Authority Configuration Examples 269 14 CONFIGURING IP Configuring IP Addresses 272 Viewing IP Interfaces 274 Deleting IP Addresses 276 Displaying the Routing Table 277 Configuring Static Routes 278 Adding Static Routes 278 Deleting Static Routes 280 Adding the Default Route 282 Deleting the Default Route 283 Managing the Address Resolution Protocol (ARP) Displaying the ARP Cache 285 Adding ARP Entries 286 Deleting ARP Entries 287 Configuring the ARP Timeout 288 Clearing the ARP Cache 289 Configuring RIP 290 About RIP 290 Configuring RIP on IP Interfaces 290 Disabling RIP on IP Interfaces 297 Removing RIP from IP Interfaces 297 Configuring OSPF 298 About OSPF 298 OSPF Configuration Task Overview 301 Configuring OSPF Global Parameters 301 Adding OSPF Areas 303 Removing OSPF Areas 305 Configuring OSPF on IP Interfaces 306 Removing OSPF from IP Interfaces 312 Configuring OSPF Virtual Interfaces 313 284 Removing OSPF Virtual Interfaces 317 Configuring OSPF Neighbor Traps 318 Configuring IP Source Routing 320 About IP Source Routing 321 Adding IP Source Routes 322 Displaying IP Source Routes 323 Removing IP Source Routes 324 Source Routing Configuration Example 325 15 IP PACKET FILTERING About IP Packet Filtering 328 Enabling and Disabling IP Packet Filtering 329 Understanding Access Lists 330 Creating Access Lists 331 Displaying Access Lists 335 Deleting Access Lists 335 Applying Access Lists to Interfaces 336 Displaying Access Classes 338 Removing Access Lists from Access Classes 339 Packet Filtering Considerations and Example 340 Implicit Deny 340 Match Sequence 341 Sample Access List 341 16 NETWORK-LAYER BRIDGING About Network-Layer Bridging 344 Creating Network-Layer Bridges 345 Creating Bridge Groups 347 Adding Interfaces to Bridge Groups 349 Assigning IP Addresses To Bridge Groups 351 17 MANAGING IP MULTICAST About IP Multicast 354 IGMP 354 IGMP Proxy 354 Managing IGMP Interfaces 356 Joining IGMP Groups 356 Configuring IGMP Interface Parameters 357 Displaying IGMP Groups and Interface Parameters Deleting IGMP Groups 362 Managing IGMP Proxies 363 Configuring Proxies 363 Displaying Proxies 365 Deleting Proxies 365 Displaying Multicast Routes 366 358 IV CABLE MODEM TERMINATION SYSTEMS 18 CONFIGURING CABLE MODEM TERMINATION SYSTEMS CMTS Upstream Frequency Reuse 369 Configuring the MAC Interface 370 Displaying MAC Interface Parameters and Statistics 370 Understanding MAC Interface Statistics 372 Configuring MAC Interface Parameters 374 Configuring the Downstream Channel 379 Displaying Downstream Configuration and Statistics 379 Understanding Downstream Channel Statistics 381 Configuring Downstream Parameters 382 Configuring Upstream Channels 390 Displaying Upstream Configuration and Statistics 390 Configuring Upstream Channel Parameters 392 Upstream Channel MAP Configuration 401 Upstream Channel Ranging Configuration 404 Configuring Admission Control 408 Configuring Frequency Hopping 411 Understanding Frequency Hopping Configuration 411 Understanding Frequency Hopping Parameters 412 Frequency Hopping Statistics 416 Defining Modulation Profiles 418 Example — Creating a Modulation Profile 424 Displaying Modulation Profiles 425 Deleting Modulation Profiles 427 Configuring CMTS Privacy Parameters Configuring Flap Control 428 19 428 MANAGING CABLE MODEMS Viewing Cable Modems 432 Displaying the Summary of Cable Modem Registration States 432 Displaying a Detailed Listing for an Interface 434 Displaying Specific Cable Modems 438 Displaying Cable Modem Statistics 439 Tracking Offline Cable Modems 441 Setting the Duration for Tracking Offline Cable Modems 441 Maintaining Statistics for Offline Cable Modems 442 Clearing Offline Cable Modems 442 Resetting Cable Modems 443 Resetting a Single Modem 443 Resetting Multiple Modems 444 Resetting All Modems on a Network 446 Changing Upstream Channels 447 Viewing Services 449 Configuring BPI and BPI+ Parameters 453 About BPI and BPI Plus 453 Configuring Authorization and Traffic Encryption Keys 455 Configuring Trust and Validity for Manufacturer Certificates 458 Configuring IP Multicast Address Mapping 461 Viewing Privacy Keys 464 Managing Flap Lists 466 Viewing the Flap List 466 Clearing the Flap List 469 Managing Quality of Service 470 Service Flows 471 Classifiers 480 Service Flow Logs 486 Dynamic Service 489 20 SUBSCRIBER MANAGEMENT About Subscriber Management Filtering 494 About CPE Control 495 Configuring Filter Groups 496 Viewing Filter Groups 502 Deleting Filter Groups and Filters 503 Modifying Existing Filter Groups 504 Assigning Default Filter Groups 505 Modifying Filter Groups Per Cable Modem 507 Viewing Filter Group Assignments 510 Configuring CPE Control Parameters 512 Modifying CPE Control Parameters Per Cable Modem 515 Viewing CPE Control Parameters and CPE Devices 518 Viewing CPE Control Parameters 518 Viewing CPE Devices 520 21 MIB BROWSING Cable Modem MIBs 522 MTA MIBs 524 Browsing Cable Modem and MTA Status 525 Cable Modem and MTA Command Output Descriptions A 528 COMMAND SUMMARY Access Control Commands 562 Mode Commands 563 General Commands 564 IP Administration and Route Filtering Commands 565 RIP Commands 568 OSPF Commands 570 DHCP Relay Commands 572 Cable Interface Administration Commands 573 Cable Modem and Subscriber Administration Commands Network-Layer Bridge Commands 580 Fault Management Commands 581 Chassis Commands 582 SNMP Commands 584 577 Packet Over SONET (POS) Commands Ethernet Commands 588 585 B CONFIGURING EXTERNAL PROVISIONING SERVERS C GLOSSARY INDEX ABOUT THIS GUIDE This chapter introduces you to the Cuda 12000 IP Access Switch CLI-based Administration Guide and contains the following sections: ■ Document Objective (page 16) ■ Audience (page 16) ■ Document Organization (page 17) ■ Notations (page 19) ■ Command Syntax (page 20) ■ Related Documentation (page 21) ■ Contacting Customer Support (page 21) 16 CHAPTER : ABOUT THIS GUIDE Document Objective The Cuda 12000 IP Access Switch CLI-based Administration Guide provides procedural information about the commands you can use to configure and manage the Cuda 12000 system using the command line interface (CLI). Before you use this guide, you should have already installed and brought the system online using the Cuda 12000 IP Access Switch Installation Guide. The Cuda 12000 IP Access Switch CLI-based Administration Guide is a companion to the Cuda 12000 IP Access Switch CLI Reference Guide, which provides detailed reference information on CLI command syntax and arguments. Audience This guide targets the network administrator, responsible for configuring and managing the Cuda 12000 within a cable television headend site. It assumes a working knowledge of network operations, although it does not assume prior knowledge of ADC’s network equipment. ADC Telecommunications, Inc. Document Organization 17 Document Organization The Cuda 12000 IP Access Switch CLI-based Administration Guide is organized as follows: Part I: Administration Overview Chapter 1: Cuda 12000 Overview — Provides an overview of product functionality and includes information on how the Cuda 12000 integrates into your network. Chapter 2: About the Command Line Interface — Introduces you to the Cuda 12000 command line interface (CLI). Chapter 3: Managing User Accounts — Provides information and procedures on how to create and configure user accounts for control of management access to the chassis. Part II: Chassis Administration Chapter 4: Chassis Configuration — Provides an overview of chassis-wide configuration and related tasks. Chapter 5: Multi-Chassis Support — Provides information and procedures on how to create groups of Cuda 12000 chassis. Chapter 6: Module Administration — Provides information and procedures for basic module administration, as well as Ethernet administration. Also includes information on how to view traffic statistics for each port. Chapter 7: Packet Over SONET Administration — Provides information and procedures for Packet Over SONET administration. Chapter 8: Timing and Alarm Controller Management — Describes the alarm management features that you can use to discover and troubleshoot cable modems, modules, and link problems. Also includes information on how to configure alarm reporting for attached fan tray and power supplies. Chapter 9: Simple Network Management Protocol (SNMP) — Provides procedures for configuring the Cuda 12000 for SNMPv1, SNMPv2, and SNMPv3 management. Chapter 10: Managing System Events — Describes how to manage event transmission and logging on the Cuda 12000. Cuda 12000 IP Access Switch CLI-based Administration Guide 18 CHAPTER : ABOUT THIS GUIDE Part III: IP Routing Chapter 11: Creating Route Filters — Provides information and procedures for creating RIP and OSPF policy-based route filters. Chapter 12: Configuring DHCP Relay — Provides information and procedures on how to configure DHCP relay on a cable interface. Chapter 13: Configuring DHCP Authority — Provides information and procedures on how to configure DHCP authority on a cable interface. Chapter 14: Configuring IP — Provides information and procedures on how to configure IP routing on your system. Includes information on Open Shortest Path First (OSPF) and Routing Information Protocol (RIP) configuration. Chapter 15: IP Packet Filtering — Provides information and procedures for creating packet filters for cable interfaces. Chapter 16: Network-Layer Bridging — Provides information and procedures for creating network-layer bridge groups. These bridge groups allow you to associate the same IP address with multiple system interfaces. A key value of this feature is the ability to span a single subnet across multiple system modules. Chapter 17: Managing IP Multicast — Provides information and procedures for configuring the Cuda 12000 to route multicast traffic, which delivers a single stream of information to multiple destinations at one time. Includes information on IGMP and multicast routes. Part IV: Cable Modem Termination Systems Chapter 18: Configuring Cable Modem Termination Systems — Provides information and procedures for configuring and managing CMTS RF parameters. Provides instruction on the configuration of downstream and upstream channels, admission control, and advanced CMTS parameters. Chapter 19: Managing Cable Modems — Provides information for managing and monitoring cable modems on the network. Chapter 20: Subscriber Management — Describes how to configure subscriber traffic filtering and Customer Premise Equipment (CPE) device management on the Cuda 12000. Chapter 21: MIB Browsing — Provides information on how to browse cable modem and MTA MIBs and the MIB objects that are returned. ADC Telecommunications, Inc. Notations 19 Appendices Appendix A: Command Summary — Provides a complete listing of CLI commands and a brief description of each; organized by function. Appendix B: Configuring External Provisioning Servers — Provides information on configuring external FastFlow BPM and third-party provisioning servers. Appendix C: Glossary — Provides a glossary of networking terms. Notations Table 1 lists the text notations that are used throughout the Cuda 12000 documentation set guide. Table 1 Notice Conventions Icon Notice Type Description Information Note Important or useful information, such as features or instructions Caution Information that alerts you to potential damage to the system Warning Information that alerts you to potential personal injury Cuda 12000 IP Access Switch CLI-based Administration Guide 20 CHAPTER : ABOUT THIS GUIDE Command Syntax Table 2 describes the command syntax conventions used in this guide. Table 2 Command Syntax Conventions Command Element Syntax Commands and keywords Expressed in bold. For example: Variables Enclosed in < > and expressed in plain text. For example: show chassis-config add arpIn this example, and are variables that follow the add arp command. Optional Arguments Enclosed in [ ]. For example: ip route default [ ] In this example, the variable is an optional argument. Set of Choices Enclosed in { | }. For example: loop {line | internal} In this example, the user can specify either the line keyword or the internal keyword following the loop command. List Expressed as three dots (...). For example: snmp-server host [ ...] In this example, the user can specify multiple notification types. In examples only, all user input — commands, keywords, and variables — are in bold to distinguish what the user enters from display-only screen text. In all other sections of this document, the conventions described above apply. ADC Telecommunications, Inc. Related Documentation 21 Related Documentation For more information on the Cuda 12000 system, refer to the following publications: ■ Cuda 12000 IP Access Switch Installation Guide: Provides the information you need to install the system and bring it online. Includes a test procedure to ensure that the system is operational and can provision modems. ■ Cuda 12000 IP Access Switch CLI Reference Guide: Provides detailed reference information on CLI command syntax and arguments. ■ Cuda 12000 IP Access Switch CudaView Administration Guide: Contains procedural information you need to configure and manage the system using CudaView. Contacting Customer Support To help you resolve any issues that you may encounter when installing, maintaining, and operating the Cuda 12000 system, you can reach Customer Support as follows: ■ Phone: (877) 227-9783 (option 4) ■ E-mail: support@basystems.com ■ Customer Support Web Site — To access Customer Support on the Web, go to http://www.adc.com/cable/support, then select the Technical Assistance Center link. You can then report the problem online, search the ADC Customer Support database for known problems and solutions, and check Frequently Asked Questions. When contacting Customer Support for technical assistance, be sure to have the following information ready: ■ List of system hardware and software components, including revision levels and serial numbers. ■ Diagnostic error messages. ■ Details about recent system configuration changes, if applicable. Cuda 12000 IP Access Switch CLI-based Administration Guide 22 CHAPTER : ABOUT THIS GUIDE ADC Telecommunications, Inc. ADMINISTRATION OVERVIEW I Chapter 1 Cuda 12000 Overview Chapter 2 About the Command Line Interface Chapter 3 Managing User Accounts 1 CUDA 12000 OVERVIEW This chapter explains the overall features of the Cuda 12000 IP Access Switch and describes how your Cuda 12000 IP Access Switch fits into your network. This chapter consists of the following sections: ■ Introducing the Cuda 12000 IP Access Switch (page 26) ■ Understanding the Cuda 12000 Within Your Network (page 32) 26 CHAPTER 1: CUDA 12000 OVERVIEW Introducing the Cuda 12000 IP Access Switch The Cuda 12000 IP Access Switch is a fully-meshed IP access switch that sits between the hybrid fiber coax cables (HFC) and the carrier’s IP backbone network. It serves as an integrated Cable Modem Termination System (CMTS) and IP router, and supports DOCSIS and EuroDOCSIS RFI Specification 1.0 and 1.1. To understand the Cuda 12000 IP Access Switch, you need to understand the following aspects of the switch: ■ Hardware ■ Software ■ Minimum Chassis Configuration ADC Telecommunications, Inc. Introducing the Cuda 12000 IP Access Switch 27 Hardware This section provides a brief overview of Cuda 12000 IP Access Switch hardware features and modules. For more information on Cuda 12000 IP Access Switch hardware, refer to the Cuda 12000 IP Access Switch Installation Guide. Features The Cuda 12000 provides the following hardware features: Table 1-1 Cuda 12000 Hardware Features Feature Description Total System Redundancy The entire system is architected for full redundancy to provide a highly fault-tolerant solution that includes: Distributed Processing Power ■ Dual-Power Sources: The system can be connected to two -48 VDC power sources to ensure uninterrupted power availability. ■ MeshFlowTM Fabric: Every application module is connected to every other application module via a high-speed serial mesh. This mesh supports a peak throughput capacity of 204.6 Gbps. (132 x 1.55 Gbps.), delivering IP packet routing with minimal latency and high availability to guarantee Quality of Service (QoS) across your core IP network. ■ Dual Management modules: The Cuda 12000 supports up to two Management modules to ensure uninterrupted system management. ■ Redundant Management Buses: The backplane consists of a 100-Mbps management BUS with redundant channels, over which the Management modules and system application modules communicate. Application modules consist of a network processor with dedicated Synchronous Burst SRAM. Unlike other systems that use a central system processor, processing power and memory scale with every application module that you install in the chassis. Cuda 12000 IP Access Switch CLI-based Administration Guide 28 CHAPTER 1: CUDA 12000 OVERVIEW Feature Description CableOnce Network Connections The system supports a CableOnce design that allows you to cable directly to the appropriate connector fixed to the rear of the chassis, or slot backplate. Cabling directly to these stationary connectors, instead of to the modules themselves, allows module replacement without recabling. You remove a module and then insert a new one while the cables remain attached to the system. This blind-mate design also lets you pre-cable chassis slots to prepare them in advance for module installation at a later time. Hot-swappable Modules All system modules can be replaced while the system is running without interruption to other interconnected networks. Both application modules and Management modules are hot-swappable. TM Modules The Cuda 12000 IP Access Switch chassis comprises 14 slots. Twelve of the slots are for application modules and two of the slots are for management modules, which control the operations of the chassis. The following is a list of the modules supported by the Cuda 12000 IP Access Switch: ■ Management Module ■ DOCSIS Modules - 1x4 DOCSIS Module - 1x4 DOCSIS SpectraFlow Module - 1x6 DOCSIS SpectraFlow Module with Spectrum Management ■ EuroDOCSIS Modules - 1x4 EuroDOCSIS Module - 1x4 EuroDOCSIS SpectraFlow Module - 1x4 EuroDOCSIS SpectraFlow Module with Spectrum Management ■ Egress Modules (Route Server Modules) - Octal 10/100 Ethernet SpectraFlow Module - Gigabit Ethernet SpectraFlow Module - Packet over SONET (POS) SpectraFlow Module ADC Telecommunications, Inc. Introducing the Cuda 12000 IP Access Switch 29 DOCSIS (Data Over Cable Service Interface Specification) is a CableLabs® standard for interoperability between a CMTS and cable modems. EuroDOCSIS (European Data Over Cable Service Interface Specification) is a CableLabs® and tComLabs® standard. DOCSIS and EuroDOCSIS modules serve as CMTS interface modules with your HFC network using upstream and downstream ports. Upstream ports support both QPSK and 16 QAM modulation; the downstream port supports 64/256 QAM modulation. Each application module has an independent network processor and Synchronous Burst RAM. As a result, processing power and memory scale with every module that you install in the chassis. The route server module functions in a dual role as both a forwarding device and a route server. The configured route server module is an egress (non-DOCSIS) module, such as an Octal 10/100 Ethernet SpectraFlow Module, Gigabit Ethernet SpectraFlow Module, or Packet over SONET (POS) SpectraFlow Module. While maintaining its original role as a forwarding module, the route server maintains a central routing table. This module then distributes the routing table to other application modules upon initialization, and incrementally updates the forwarding tables as new routes are discovered. Distributed forwarding tables on each application module provide an added level of fault tolerance; should the Management module or another application module fail, the existing operational modules forward traffic without interruption. Cuda 12000 IP Access Switch CLI-based Administration Guide 30 CHAPTER 1: CUDA 12000 OVERVIEW Software The Cuda 12000 IP Access Switch system software comprises two software components, as follows: ■ ■ Base System Software (required): The base system software is shipped with your Cuda and contains the operating system. The base software includes the command line interface (CLI) and provides you with the following functions: ■ User Account Management ■ Chassis Configuration ■ Multi-Chassis Support ■ Module Administration ■ Event Management ■ SNMP Management ■ IP Configuration ■ Packet and Route Filter Creation ■ DHCP Relay Configuration ■ CMTS Administration ■ Cable Modem Administration ■ Subscriber Management CudaView (optional): CudaView contains the graphical user interface (GUI) component of the element management system. CudaView provides full management functionality in graphical views that are easy for users to understand. CudaView provides an intuitive and “top-down” visual display that accelerates the management learning curve for new users and improves the productivity of all users. CudaView offers topology views, fault views, performance graphs, and many other useful features. For more information on CudaView, refer to the Cuda 12000 IP Access Switch CudaView Administration Guide. ADC Telecommunications, Inc. Introducing the Cuda 12000 IP Access Switch 31 Minimum Chassis Configuration The minimum configuration of a Cuda 12000 IP Access Switch comprises the following: ■ A minimum of one management module, plus the base software package. The module and base software are required to configure the Cuda 12000 IP Access Switch. ■ An Octal 10/100 Ethernet, Gigabit Ethernet, or POS module. Each of these modules offers these services: ■ ■ A link from the Cuda 12000 to your network backbone ■ May be configured as the route server ■ May function in a dual forwarding role One DOCSIS or EuroDOCSIS application module, which is required to perform CMTS functions. Cuda 12000 IP Access Switch CLI-based Administration Guide 32 CHAPTER 1: CUDA 12000 OVERVIEW Understanding the Cuda 12000 Within Your Network Cuda 12000 IP Access Switches are installed at the HFC end of a cable plant and are responsible for gateway operations between the headend and the Internet. Through the Cuda 12000 IP Access Switch, digital data signals are modulated onto RF channels for broadcast over the same infrastructure. Typically, the signals are broadcast through the HFC to fiber nodes in the network. Amplifiers, coaxial cable, and taps carry the signals to the subscriber premises. This example shows how the Cuda 12000 IP Access Switch can fit into your network. Optional FastFlow BPM Prov. Server Cuda 12000 Cable Modem/MTA Figure 1-1 How the Cuda 12000 IP Access Switch Fits into Your Network ADC Telecommunications, Inc. Understanding the Cuda 12000 Within Your Network 33 Cable Modem Termination System (CMTS) The Cuda 12000 implements DOCSIS and EuroDOCSIS CMTS functionality, providing connectivity and data forwarding for cable modems over the RF cable plant. The DOCSIS and EuroDOCSIS modules interface with your HFC network, using a 1-to-4 downstream-to-upstream port ratio (referred to as 1 x 4), or a 1-to-6 downstream-to-upstream port ratio (referred to as 1 x 6). Upstream ports support QPSK and 16 QAM modulation; the downstream port supports 64 and 256 QAM modulation. IP Routing Configuration The Cuda 12000 IP Access Switch uses the Internet Protocol (IP) to exchange data over computer networks consisting of cable and Ethernet interfaces. In addition, it supports RIP and OSPF routing protocols in order to exchange routing information with other routers in the IP network. In order to integrate the Cuda 12000 IP Access Switch into your network, the following configuration must be accomplished: ■ Configure the CMTS interfaces so that the cable modems range properly. ■ Provision cable modems, Multimedia Terminal Adapters (MTAs), and CPE (Customer Premise Equipment) devices, using the FastFlow Broadband Provisioning Manager or a third-party provisioning server. ■ Configure DHCP subnets, so that the DHCP server gives out IP addresses to cable modems, MTAs, and CPE devices. ■ Configure IP on your cable, Ethernet, and Packet Over SONET interfaces to connect the Cuda 12000 to your backbone network and provide the subscribers access to the Internet. ■ For the HFC segments, configure DHCP relay to specify the subnet to be used for assigning IP addresses to cable modems, MTAs, and CPE devices. IP, RIP and OSPF can currently be configured on any of the interfaces within the Cuda12000 IP Access Switch. Cuda 12000 IP Access Switch CLI-based Administration Guide 34 CHAPTER 1: CUDA 12000 OVERVIEW ADC Telecommunications, Inc. 2 ABOUT THE COMMAND LINE INTERFACE This chapter introduces you to the command line interface (CLI) and covers the following topics: ■ About the CLI (page 35) ■ Accessing the CLI (page 37) ■ Command Modes (page 40) About the CLI The Cuda 12000 management module runs the Linux operating system. The CLI operates within this environment. The CLI is a textual command line interface accessible through a local COM port or through remote Telnet or secure shell (SSH). The CLI operates within the command shell and offers a number of features to facilitate ease-of-use and configuration, including: ■ Context Sensitive Online Help — The CLI offers the following online Help mechanisms: ■ Individual Command Help — You can display help on most commands by typing help followed by the command name. For example: cli:172.16.19.10:root# help bridge-group bridge-group Creates a bridge group cli:172.16.19.10:root# The command name is listed on the left with a description on the right. Arguments are indented in standard syntax below the command name. 36 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE ■ ■ Command Mode Help — To view all commands available in the current mode with associated descriptions, type help. To show a list of available commands without descriptions, type ? at the prompt or press the Tab key twice. Configurable Prompt — By default, the prompt displays both the address assigned to the management module and the current command mode. You can configure the prompt so it does not display this information. When the address and mode is displayed in the prompt, you can issue set prompt to remove it. To configure the prompt to display address and mode information, issue set prompt mode. For example: cli:172.16.19.10:root# set prompt cli# cli# set prompt mode cli:172.16.19.10:root# ■ Command Completion — The system does not require that you type the entire command string. You simply need to type enough of the string to make it unique among the available commands so the system can recognize it. Once you type enough of the command string to distinguish it among other commands, simply press [Tab] to complete the command, or press [Enter] to execute it. For most commands within the CLI, hyphens are placed between nouns, (such as cpe-control), while no hyphen is placed between verbs and nouns (such as no shutdown and show ip). Also note that commands and their associated arguments are case-sensitive. ADC Telecommunications, Inc. Accessing the CLI 37 Accessing the CLI Your first form of access to the CLI (after installing the Cuda 12000) is through COM port 1 located on the front of the management module. Once you assign the Craft Ethernet port on the management module an IP address, you can access the CLI remotely through Telnet or SSH. Use the following procedure to logon to the system management module and access the CLI environment through COM port 1: 1. Ensure that you have cabled a console or a system running a terminal emulation program to COM port 1 and configured the correct serial transmission settings (57,600, 8, 1). 2. Access the system through the terminal emulator. Press [Enter] until you see the Linux login prompt. 3. You are then prompted for a login name and password to logon to the CLI. Enter your login name and password. The system ships with the following system defaults: ■ Account Name: administrator ■ Password: bas The Linux prompt is then displayed. Note that the default login name and password are case-sensitive — all lowercase. 4. From the command prompt, access the CLI environment by issuing the following command: bascli 5. Within the CLI environment, enter your Cuda 12000 login name and password, as follows: enable Note that the login name and password must be either defined locally on the Cuda 12000 or defined on a RADIUS or TACACS+ authentication server. Refer to Chapter 3 “Managing User Accounts” for more information on managing usernames and passwords. Cuda 12000 IP Access Switch CLI-based Administration Guide 38 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE The system ships with the following system defaults: Account Name: root Password: bas For example: [administrator@Tech2000 administrator]$ bascli cli:null:root> enable root password: *** Connecting to 172.16.19.10... Java Server version is compatible ClientMode: CLI logon complete Sending message: User root just logged in from Tech2000 FROM:root@Tech2000:: User root just logged in from Tech2000 Note that the default login name and password are case-sensitive — all lowercase. Use the following procedure to logon to the system management module and access the CLI environment through the Craft Ethernet port: 1. Ensure that you have assigned an IP address to the Ethernet craft port on the management module, and that the Telnet and SSH server processes are running. 2. Open a Telnet session or an SSH session with the IP address or hostname assigned to the management module. 3. When the cli:null:root prompt appears, enter your Cuda 12000 login name and password, as follows: enable The system ships with the following system defaults: Account Name: root Password: bas ADC Telecommunications, Inc. Accessing the CLI 39 For example: ADC Cuda 12000 cli:null:root> enable root password: *** Connecting to 192.168.208.3... Java Server version is compatible logon complete Sending message: User root just logged in from techpubs FROM:root@techpubs:: User root just logged in from techpubs Note that the default login name and password are case-sensitive — all lowercase. Cuda 12000 IP Access Switch CLI-based Administration Guide 40 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Command Modes The Cuda 12000 switches and routes IP traffic between cable modems on an analog HFC network, and an IP digital network. As a result, administration tasks range from configuring IP interfaces and routing protocols to managing subscribers. To support these administration tasks, the system provides a set of global commands and multiple command modes. Global commands can be accessed anywhere in the CLI, while each command mode provides access to a set of related commands that cover a particular configuration scope. The current command mode is displayed in the prompt by default; you can verify the current mode that you are in at anytime by using the show mode command. Command mode structure follows a hierarchy in which some modes run within others; all run within root mode. You can back up to the parent level from any sub mode using the up command. For local access, note that you can exit the CLI command shell and return to the Linux prompt at any time by typing quit. For Telnet or SSH access, the quit command terminates your session (you can also type q, which is a shortened form of quit). You can also display a list of all available commands within the current mode by using one of the following help commands: Help Command Description help Displays the commands and command descriptions. ? Displays all commands available within the current mode without descriptions; you can also display all commands by pressing the Tab key twice. ADC Telecommunications, Inc. Command Modes 41 The command modes that are available for system configuration depend on the product packages installed. Base package system management command modes include: ■ Root Mode ■ Physical Interface Mode ■ IP Interface Mode ■ OSPF Global Configuration Mode ■ Import and Export OSPF Route Filter Modes ■ RIP Configuration Mode ■ Import and Export RIP Route Filter Modes ■ Slot Mode If the FastFlow Broadband Provisioning Manager is installed on your Cuda 12000 IP Access Switch, additional command modes are available. Refer to the FastFlow Broadband Provisioning Manager CLI-based Administration Guide and the FastFlow Broadband Provisioning Manager CLI Reference Guide for more information on FastFlow Broadband Provisioning Manager command modes. Cuda 12000 IP Access Switch CLI-based Administration Guide 42 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Global Commands Global commands can be used anywhere in the CLI, regardless of your current command mode. Table 2-1 lists global commands as they appear when you type help at the command prompt. Note that the help command output displays many commands in their abbreviated form. Table 2-1 Global Commands Command Description basmonitor Starts the system monitor. boot Enables, disables, or reboots a module in an application slot. clear Clears a specified system resource (depending on the specified argument), such as ARP cache or statistics counters. cm-filter-default Sets the default cable modem filter values for the system. cpe-control Sets the default subscriber management values for the system. connect Connects you to another Cuda 12000 IP Access Switch chassis. echo Echoes a comment so that it displays. enable Enables a user session. help Displays CLI command help. interface Changes you to interface mode. ip Configures IP parameters for the system. no Specifies the no form of a command. ping Enables you to the send an ICMP echo request packet to a destination to determine if it is reachable. prov-server Changes you to provisioning server mode. This command is useful only if the FastFlow Broadband Provisioning Manager is installed on your Cuda 12000 IP Access Switch. q Shortened form of quit. quit Enables you to exit from the CLI. root Changes you to root mode. router Changes you to router mode. ADC Telecommunications, Inc. Command Modes 43 Table 2-1 Global Commands Command Description server Shortened form of prov-server. set Sets several user session parameters. show Specifies the show form of a command, which provides a read-only view of configuration parameters and other information. sleep Delays the display of the CLI prompt for a specified number of seconds. slot Changes you to slot mode. source Executes a script file. talk Enables and disables sending of broadcast messages. This command also allows you to send a message. traceroute Traces an IP route from a source to a destination. up Moves you up one level in the command mode hierarchy. Cuda 12000 IP Access Switch CLI-based Administration Guide 44 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Root Mode Root is the top-level mode in the CLI administration console; all other modes run within this mode. From within root mode you can access second-level command modes, such as slot configuration mode. To enter root mode from within any configuration mode, type root. Table 2-2 lists available root commands as they appear when you type help at the command prompt. Global commands are not listed and can be found in Table 2-1 on page 42. Note that the help command output displays many commands in their abbreviated form. Table 2-2 Root Mode Commands Command Description aaa Configures TACACS+ and RADIUS network authentication. access-list Creates an access list, which consists of IP filtering rules. access-profile Creates an access profile for a user. account Creates user accounts. alarm-throttle Configures alarm delivery and threshold parameters. aux-device Configures hardware alarm and clocking parameters. bridge-group Creates a bridge group. bridge-timeout Configures timers for bridge group broadcast flows. ccdown Shuts down the control module. chassis Configures multi-chassis support parameters. chassis-config Configures local chassis parameters. chassis-fault Configures chassis alarms. cm-filter Creates a cable modem filter. db-check Validates provisioning database information. db-connect Configures access to the provisioning database. event-config Configures event reporting, throttling, and syslog parameters. event-log Empties the event log. http-server Starts and stops the Web server. lookup Controls the Jini lookup service on the chassis. ADC Telecommunications, Inc. Command Modes 45 Table 2-2 Root Mode Commands Command Description modulation-profile Configures modulation profiles, which contain burst properties for upstream data channels. privacy Configures X.509 certificate parameters for BPI plus. radius-server Configures a RADIUS authentication server. reset Reboots a module. save Saves the system configuration for all slots to persistent storage. snmp-server Configures the SNMP agent. tacacs-server Configures the TACACS+ server. traffic-relay Configures traffic relay for processes (such as servers) on the chassis. Cuda 12000 IP Access Switch CLI-based Administration Guide 46 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Physical Interface Mode Physical interface mode allows for the administration of a specified interface, including interface-specific configuration and information displays. To enter this mode, you must specify the chassis/slot/port-number (c/s/i) combination that identifies the physical interface that you want to configure. After you enter this mode, all configuration that you perform pertains to the interface that you specified. To enter interface configuration mode, type interface from within any configuration mode. The CLI automatically displays the type of interface for the specific c/s/i. The following tables list interface commands by type: ■ Table 2-3 — Lists available DOCSIS interface mode commands as they appear when you type help at the command prompt. ■ Table 2-4 — Lists available Ethernet interface mode commands as they appear when you type help at the command prompt. ■ Table 2-5 — Lists available POS interface mode commands as they appear when you type help at the command prompt. Keep in mind that the help command output displays many commands in their abbreviated form. Also keep in mind that global commands are not listed in any of these tables and can be found in Table 2-1 on page 42. NOTE: The commands displayed via help, ?, and through the double Tab action are relevant to the selected interface. Table 2-3 DOCSIS Interface Mode Commands Command Description access-class Applies an access list to the current interface. access-list Creates an access list, which consists of IP filtering rules. admission-control Enables and disables admission control. analyzer Enables the protocol analyzer. arp Sets the ARP timeout parameter. bootp-policy Defines BOOTP request policies. cable Optional prefix to commands in this mode. ADC Telecommunications, Inc. Command Modes 47 Table 2-3 DOCSIS Interface Mode Commands Command Description cm First element in various cable modem and subscriber management commands, such as cm modify active, cm reset, and so on. cm-filter Creates a cable modem filter. cm-offline Configures several offline cable modem parameters for the current interface. dhcp-authority Adds a DHCP authority range. The command also enables and disables DHCP authority. dhcp-policy Configures several parameters in the DHCP packet and determines the list of servers to which the DHCP packet is sent. dhcp-relay Configures various DHCP relay agent options, such as the IP addresses of cable modem, CPE, and MTA gateways. downstream Configures the downstream channel. flap-list Controls the size of the flap list. insertion-interval Configures the modem insertion interval. link-trap Enables link traps for the interface. map-timer Configures the map timer interval. modulation-profile Configures modulation profiles, which contain burst properties for upstream data channels. periodic-ranginginterval Configures how the interface periodically invites modems to range. plant-delay Configures the estimated plant propagation delay. pll-state Configures the phase lock loop state for the interface. privacy Configures BPI plus parameters for the interface. proxy-arp Enable proxy ARP on the interface. qos Enables SNMP and cable modem access to the QoS tables on the CMTS. ranging-attempts Configures the number of times that a cable modem is invited to range before being removed from the system. shared-secret Configures a shared secret on the current CMTS interface. shutdown Enables you to administratively shut down an interface. Cuda 12000 IP Access Switch CLI-based Administration Guide 48 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Table 2-3 DOCSIS Interface Mode Commands Command Description spectrum-group Configures spectrum group rules. sync-interval Configures the time interval between synchronization message transmissions on the downstream channel. trace-log Configures event logging for the interface. ucd-interval Configures the time interval between transmission of successive Upstream Channel Descriptor (UCD) messages for each upstream channel. upstream Configures upstream channels. Table 2-4 Ethernet Interface Mode Commands Command Description access-class Applies an access list to the current interface. access-list Creates an access list, which consists of IP filtering rules. add Adds a static ARP entry for the current interface. arp Sets the ARP timeout parameter. bootp-policy Defines BOOTP request policies. dhcp-authority Adds a DHCP authority range. The command also enables and disables DHCP authority. dhcp-policy Configures several parameters in the DHCP packet and determines the list of servers to which the DHCP packet is sent. dhcp-relay Configures DHCP relay agent options. duplex Configures the duplex mode for the interface (full duplex, half duplex, or auto). link-trap Enables link traps for the interface. negotiation Configures an Ethernet port to automatically negotiate duplex and speed. shutdown Enables you to administratively shut down an interface. speed Configures the speed for an Ethernet port. ADC Telecommunications, Inc. Command Modes 49 Table 2-5 POS Interface Mode Commands Command Description access-class Applies an access list to the current interface. access-list Creates an access list, which consists of IP filtering rules. arp Sets the ARP timeout parameter. bootp-policy Defines BOOTP request policies. clock-source Configures the SONET transmission clock source. crc Configures cyclic redundancy checking (CRC). dhcp-authority Adds a DHCP authority range. The command also enables and disables DHCP authority. dhcp-policy Configures several parameters in the DHCP packet and determines the list of servers to which the DHCP packet is sent. dhcp-relay Configures DHCP relay agent options. link-trap Enables link traps for the interface. loop Configures the current interface for loopback testing. mtu Configures the maximum transmission unit (MTU) for the current interface. pos Configures POS parameters. ppp Configures PPP parameters. shutdown Enables you to administratively shut down an interface. Cuda 12000 IP Access Switch CLI-based Administration Guide 50 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE IP Interface Mode IP interface mode allows for the administration of a specified IP interface, including IP interface-specific configuration and information displays. To enter this mode, you must: 1. Enter physical interface mode for the physical interface associated with the IP interface. 2. Issue the ip address command. On the command line, you specify the IP address and network mask combination that identifies the IP interface. In IP address mode, the following commands are available: ■ All commands that are available in the associated physical interface mode (DOCSIS, Ethernet, or POS). ■ Commands for configuring RIP and OSPF on the interface (ip rip commands and ip ospf commands). ADC Telecommunications, Inc. Command Modes 51 OSPF Global Configuration Mode OSPF commands allow you to configure global OSPF (Open Shortest Path First) parameters. The system supports OSPF version 2 as defined in RFC 1583. OSPF global configuration mode allows you to enable the protocol on a system-wide basis, and set system-wide OSPF parameters — such as router ID — and default OSPF parameters. All OSPF areas to which you want this system to belong must be configured within this mode. You then assign areas to OSPF-enabled IP interfaces on an individual basis within IP interface mode. For example, if you want three IP interfaces to belong to three separate areas, you must first define the three areas using the ospf area command within this configuration mode. You can then use the ip ospf command within the IP interface configuration mode to assign the interface to one of the areas. You can also set OSPF cost and dead-interval on a per-area basis. Configuration on a per-IP-interface basis overrides the same values that you define in OSPF global configuration mode. To enter OSPF global configuration mode, type router ospf from any mode, or type ospf from router mode. Cuda 12000 IP Access Switch CLI-based Administration Guide 52 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Table 2-6 lists available OSPF global commands as they appear when you type help at the command prompt. CLI global commands are not listed and can be found in Table 2-1 on page 42. Note that the help command output displays many commands in their abbreviated form. Table 2-6 OSPF Global Configuration Mode Commands Command Description asbr Configures the Cuda 12000 IP Access Switch as an Autonomous System Boundary Router (ASBR). export Changes you to router export mode. import Changes you to router import mode. ospf Configures an OSPF area. ospf-vi Configures an OSPF virtual interface. report Enables sending of OSPF neighbor state and OSPF virtual neighbor state events. router-id Configures the OSPF router ID. ADC Telecommunications, Inc. Command Modes 53 Import and Export OSPF Route Filter Modes Route filters control the flow of routes to and from the routing table. Import route filters control which routes are stored in the routing table. Export filters control which routes are advertised to other routers. You can define route filters to control the flow of both OSPF and RIP routes. To create OSPF import route filters, enter import mode from within router:ospf mode, or type router ospf import from any mode. You can then use the available commands to create route filters to control which OSPF routes the system learns. To create OSPF export route filters, enter export mode from within router:ospf mode or type router ospf export from any mode. You can then use the available commands to create route filters to control which OSPF networks the router advertises to other OSPF routers. Table 2-7 lists available OSPF import and export route filter commands as they appear when you type help at the command prompt. CLI global commands are not listed and can be found in Table 2-1 on page 42. Note that the help command output displays many commands in their abbreviated form. Table 2-7 OSPF Import and Export Route Filter Mode Commands Command Description asbr Configures the Cuda 12000 IP Access Switch as an Autonomous System Boundary Router. map-list Adds a route map to a map list. match Specifies criteria that is matched against route entries. ospf Configures an OSPF area. ospf-vi Configures an OSPF virtual interface. override Enables you to override values for import or export filters. report Enables sending of OSPF neighbor state and OSPF virtual neighbor state events. route-map Creates a route map. router-id Configures the OSPF router ID. Cuda 12000 IP Access Switch CLI-based Administration Guide 54 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE RIP Configuration Mode RIP (Routing Information Protocol) is a broadcast-based protocol used by routers to update routing tables, which include information about the networks that are in their routing tables. The routing table is broadcast to the other routers on the network where RIP is configured over IP. The Cuda 12000 supports RIP version 2 as defined in RFC 1724. The Cuda can interoperate in a network of both RIPv1 and RIPv2 routers. A network composed of RIPv1 and RIPv2 routers is useful in supporting the transition from older routers to newer routers supporting RIPv2. In order to exchange RIP routes over an interface you must configure RIP over IP on that interface. After RIP is added to the interface, the Cuda 12000 begins to exchange RIP routes with adjacent RIP routers. To enter RIP configuration mode, type router rip from any mode, or type rip from router mode. RIP configuration mode allows you to enter RIP import and export route filter modes using the import and export commands. It does not allow you to set global parameters. RIP parameters are configured on a per-IP-interface basis within IP interface mode by means of the ip rip command. ADC Telecommunications, Inc. Command Modes 55 Import and Export RIP Route Filter Modes Route filters control the flow of routes to and from the routing table. Import route filters control which routes are stored in the routing table. Export filters control which routes are advertised to other routers. You can define route filters to control the flow of both OSPF and RIP routes. To create RIP import route filters, enter import mode from within router:rip mode or type router rip import from within any mode. You can then use the available commands to create route filters to control which RIP routes the system learns. To create RIP export route filters, enter export mode from within router rip mode or type router rip export from within any mode. You can then use the available commands to create route filters to control which RIP networks the router advertises to other RIP-enabled routers. Table 2-8 lists available RIP import and export route filter commands as they appear when you type help at the command prompt. CLI global commands are not listed and can be found in Table 2-1 on page 42. Note that the help command output displays many commands in their abbreviated form. Table 2-8 RIP Import and Export Route Filter Mode Commands Command Description map-list Adds a route map to a map list. match Specifies criteria that is matched against route entries. override Configures the override values for import or export filters. route-map Creates a route map. Cuda 12000 IP Access Switch CLI-based Administration Guide 56 CHAPTER 2: ABOUT THE COMMAND LINE INTERFACE Slot Mode Slot mode provides access to slot-specific commands. To enter this mode, you must specify a chassis/slot (c/s) combination that identifies the slot that you want to administer. Within this mode, you can do the following: ■ Persist (save) configuration for the current module, or all modules in the system ■ Configure and show trace log activity for the current slot ■ Reset the module contained in the slot, or all modules in the chassis. To enter slot mode, enter slot from within any mode. Table 2-9 lists available slot mode commands as they appear when you type help at the command prompt. CLI global commands are not listed and can be found in Table 2-1 on page 42. Note that the help command output displays many commands in their abbreviated form. Table 2-9 Slot Mode Commands Command Description copy Downloads a file from a TFTP server to flash. cpu-utilization Enables CPU utilization on the module. filter-aging Configures IP packet filtering for all interfaces in the slot. reset Reboots a module. save Saves the system configuration for all slots to persistent storage. trace-log Configures event logging for the slot. ADC Telecommunications, Inc. 3 MANAGING USER ACCOUNTS This chapter provides information and procedures on how to manage user accounts and consists of the following tasks: ■ Configuring Access Profiles (page 57) ■ Managing User Accounts (page 58) ■ Configuring User Authentication (page 63) Before you can effectively perform these tasks, you need to understand some concepts of user accounts. Understanding User Accounts You can manage security and control access to the system by creating and managing user accounts on the Cuda 12000. User accounts define both the functional areas the user can access and the types of access allowed for those areas. In addition to creating user accounts locally on the Cuda 12000, you can also create user accounts on a TACACS+ or RADIUS authentication server. Refer to “Configuring User Authentication” on page 67 for more information. Creating local accounts involves assigning access profiles to users. The accounts themselves are created using the account command. The access profiles that you assign to the account are created using the access-profile command. You must have root profile privileges, as defined below, to manage user accounts. 58 CHAPTER 3: MANAGING USER ACCOUNTS Configuring Access Profiles Access profiles define the type of access available to users. The access profile command allows you to configure access to the following functional areas: Table 3-1 Functional Areas Functional Area Description Admin Functions associated with administering user accounts, such as adding modifying, and deleting users and profiles, as well as chassis configuration. HFC Functions associated with configuring and monitoring DOCSIS/EuroDOCSIS-related (CMTS) parameters such as configuring upstream and downstream channels. Observer Functions associated with a limited command set. The user has access to root mode and slot mode only, and is restricted to a limited set of commands. The user can type help or ? to determine the available commands. Prov Functions associated with provisioning-related tasks, such as configuring DHCP servers and subnets. Router Functions associated with router-related tasks, such as configuring IP, RIP, and OSPF interfaces. For each functional area, you can provide the following privileges: ■ noaccess. Prevents the user from viewing or configuring the functional area. ■ readonly. The user can view information for the functional area, but not configure it. ■ read/write. The user can both configure and view the functional area. ADC Telecommunications, Inc. Configuring Access Profiles 59 The system ships with the following default access profiles. Note that these profiles are displayed in all capital letters when viewed to distinguish them from user-defined profiles. Also note that you cannot modify or remove these built-in profiles: ■ AUDITORPROFILE. Provides read-only access to DOCSIS, routing, and provisioning functionality; no access to administrative functions. ■ OPERATORPROFILE. Provides read-write access to DOCSIS, routing, and provisioning functionality; no access to administrative functions. ■ ROOTPROFILE. Provides read-write access to all functional areas, including DOCSIS, routing, provisioning, and administrative functions. ■ NOACCESSPROFILE. Denies access to all functional areas. You can add more than one access profile to a user account. When you do so, the more powerful privileges take precedence. For example, if you assign both the AUDITORPROFILE and the ROOTPROFILE to a single user account, the ROOTPROFILE overrides the AUDITORPROFILE and the user has read-write access to all four functional product areas. Cuda 12000 IP Access Switch CLI-based Administration Guide 60 CHAPTER 3: MANAGING USER ACCOUNTS Creating and Modifying Access Profiles To create or modify an access profile, use the access-profile command. To create a profile, specify a new profile name; to modify a profile specify an existing profile name. You create or modify a profile by performing the following tasks: Task Command 1. Enter root mode. root 2. Define the access profile. access-profile description {addprivilege | removeprivilege} {admin | hfc | observer | prov | router} {noaccess | read/write | readonly} Example The following example creates a profile with read only rights to routing functionality: cli:172.16.19.10:root# access-profile routemonitor description "Readonly" addprivilege router readonly PROFILE AFTER CREATE profileName: routemonitor profileDescription: Readonly PrivilegeList: router: readonly 'routemonitor' was successfully created cli:172.16.19.10:root# ADC Telecommunications, Inc. Configuring Access Profiles 61 Displaying Access Profiles You display access profile information by performing the following tasks: Task Command 1. Enter root mode. root 2. Display all access profiles. show access-profile 3. Display a specific access profile. show access-profile Example The following example displays a profile named routemonitor: cli:172.16.19.10:root# show access-profile routemonitor Showing single profile: profileName: routemonitor profileDescription: Readonly PrivilegeList: router: readonly cli:172.16.19.10:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 62 CHAPTER 3: MANAGING USER ACCOUNTS Deleting a Profile You remove an access profile by performing the following tasks: Task Command 1. Enter root mode. root 2. Remove a specified access profile. no access-profile Example The following example deletes an access profile named routemonitor: cli:172.16.19.10:root# no access-profile routemonitor 'routemonitor' was successfully removed cli:172.16.19.10:root# ADC Telecommunications, Inc. Managing User Accounts 63 Managing User Accounts You create and modify local user accounts on the Cuda 12000 using the account command. You must have root profile privileges to manage user accounts which the following: ■ Creating and Modifying User Accounts ■ Displaying User Accounts ■ Deleting User Accounts For each user account, you define the following parameters: Table 3-2 User Account Parameters Parameter Description username Name of the user as defined by the administrator that created the account. password Password required to access this account. Note that if you do not specify a password, a NULL value is added. This means that the user would simply press [Enter] to access the account. description Administrative description of the user account. access-profile Access profile that you want to assign to the user account. Note that you can add multiple profiles to a user account by reissuing the command. Cuda 12000 IP Access Switch CLI-based Administration Guide 64 CHAPTER 3: MANAGING USER ACCOUNTS Creating and Modifying User Accounts To create or modify a user account, use the account command. To create a new account, specify a new account name. To modify an existing account, specify an existing name. You create or modify a user account by performing the following tasks: Task Command 1. Enter root mode. root 2. Create a user account. account {add-profile | remove-profile | password | description } Example The following example creates a new user account named Route_1 that uses the password tech and applies a profile named routemonitor: cli:172.16.19.10:root# account Route_1 add-profile routemonitor password tech description "Read Only Routing Admin" ACCOUNT AFTER CREATE UserName: Route_1 UserDescription: Read Only Routing Admin PROFILE LIST profileName: routemonitor profileDescription: Readonly PrivilegeList: router: readonly 'Route_1' was successfully created cli:172.16.19.10:root# User account names and passwords are case-sensitive. ADC Telecommunications, Inc. Managing User Accounts Displaying User Accounts You view user accounts configured on the system by performing the following tasks: Task Command 1. Enter root mode. root 2. Show all user accounts. show account 3. Show a specified user account. show account Example The following example shows the user account named Route_1: cli:172.16.19.10:root# show account Route_1 Showing single account: UserName: Route_1 UserDescription: Read Only Routing Admin PROFILE LIST profileName: routemonitor profileDescription: Readonly PrivilegeList: router: readonly cli:172.16.19.10:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 65 66 CHAPTER 3: MANAGING USER ACCOUNTS Deleting User Accounts You may want to delete a user account when you no longer need it or want to remove a user from the system. After a user account is deleted that user is locked out of the system. Note that this is also true for the user with root profile privileges. If there is only one user with root profile privileges for your system and that user is locked out of the system, then you need to contact Customer Support for assistance. To remove a user account from the system, perform the following task: Task Command Delete account. no account Example The following example removes the user account Route_1 from the system: cli:172.16.19.10:root# no account Route_1 'Route_1' was successfully removed cli:172.16.19.10:root# ADC Telecommunications, Inc. Configuring User Authentication 67 Configuring User Authentication The Cuda 12000 IP Access Switch supports three types of user authentication: ■ Local authentication – Users are authenticated locally by the Cuda 12000. This is the default authentication type. ■ TACACS+ authentication – Users are authenticated by a TACACS+ server. When the user attempts to login to the Cuda 12000, the Cuda 12000 encrypts the username and pasword, and forwards them to the TACACS+ server for authentication. TACACS+ users are assigned the ROOTPROFILE access profile. ■ RADIUS authentication – Users are authenticated by a RADIUS server. When the user attempts to login to the Cuda 12000, the Cuda 12000 encrypts the password only, and forwards the username and password to the RADIUS server for authentication. RADIUS users are assigned the ROOTPROFILE access profile. The sections that follow describe how to configure user authentication. Cuda 12000 IP Access Switch CLI-based Administration Guide 68 CHAPTER 3: MANAGING USER ACCOUNTS Configuring Local Authentication By default, users are authenticated locally by the Cuda 12000 using the accounts and access profiles you create as described earlier in this chapter. If you configure TACACS+ or RADIUS authentication, and then decide to change back to local authentication, perform the following tasks: Task Command 1. Enter root mode. root 2. Enable local authentication. aaa authentication login default local 3. Verify that local authentication is enabled. show aaa Example cli:192.168.208.3:root# aaa authentication login default local cli:192.168.208.3:root# show aaa aaa authentication login default local ADC Telecommunications, Inc. Configuring User Authentication 69 Configuring TACACS+ Authentication Before you configure TACACS+ authentication on the Cuda 12000, make sure that: ■ At least one account for Cuda 12000 users has been created on the TACACS+ server. Users must login to the Cuda 12000 an account created on the TACACS+ server. Refer to your TACACS+ server documentation for more information. ■ You know the IP address of the TACACS+ server. ■ You know the shared key that the Cuda 12000 will use to encrypt TACACS+ usernames and passwords for transmission to the TACACS+ server. If TACACS+ authentication is unavailable due to problems with the TACACS+ server, local authentication is used. To configure TACACS+ authentication on the Cuda 12000, perform the following tasks: Task Command 1. Enter root mode. root 2. Specify the IP address of the TACACS+ server. tacacs-server host 3. Specify the encryption key that the Cuda 12000 will use to encrypt usernames and passwords. The key is an alphanumeric string. tacacs-server key 4. Verify TACACS+ server settings. show tacacs-server 5. Enable TACACS+ authentication. aaa authentication login default tacacs+ Cuda 12000 IP Access Switch CLI-based Administration Guide 70 CHAPTER 3: MANAGING USER ACCOUNTS Task Command 6. Verify that TACACS+ authentication is enabled. show aaa Example cli:192.168.208.3:root# tacacs-server host 192.168.220.200 cli:192.168.208.3:root# tacacs-server key one4me cli:192.168.208.3:root# show tacacs-server tacacs-server host 192.168.220.200 tacacs-server key one4me cli:192.168.208.3:root# aaa authentication login default tacacs+ cli:192.168.208.3:root# show aaa aaa authentication login default tacacs+ cli:192.168.208.3:root# ADC Telecommunications, Inc. Configuring User Authentication 71 Configuring RADIUS Authentication Before you configure RADIUS authentication on the Cuda 12000, make sure that: ■ At least one account for Cuda 12000 users has been created on the RADIUS server. Users must login to the Cuda 12000 an account created on the RADIUS server. Refer to your RADIUS server documentation for more information. ■ You know the IP address of the RADIUS server. ■ You know the shared key that the Cuda 12000 will use to encrypt RADIUS passwords for transmission to the RADIUS server. Usernames are not encrypted. If RADIUS authentication is unavailable due to problems with the RADIUS server, local authentication is used. To configure RADIUS authentication on the Cuda 12000, perform the following tasks: Task Command 1. Enter root mode. root 2. Specify the IP address of the RADIUS server. radius-server host 3. Specify the encryption key that the Cuda 12000 will use to encrypt passwords. The key is an alphanumeric string. radius-server key 4. Verify RADIUS server settings. show radius-server 5. Enable RADIUS authentication. aaa authentication login default radius Cuda 12000 IP Access Switch CLI-based Administration Guide 72 CHAPTER 3: MANAGING USER ACCOUNTS Task Command 6. Verify that RADIUS authentication is enabled. show aaa Example cli:192.168.208.3:root# radius-server host 192.168.220.202 cli:192.168.208.3:root# radius-server key one4me cli:192.168.208.3:root# show radius-server radius-server host 192.168.220.202 radius-server key one4me cli:192.168.208.3:root# aaa authentication login default radius cli:192.168.208.3:root# show aaa aaa authentication login default radius cli:192.168.208.3:root# ADC Telecommunications, Inc. II CHASSIS ADMINISTRATION Chapter 4 Chassis Configuration Chapter 5 Multi-Chassis Support Chapter 6 Module Administration Chapter 7 Packet Over SONET Administration Chapter 8 Timing and Alarm Controller Management Chapter 9 Simple Network Management Protocol (SNMP) Chapter 10 Managing System Events 4 CHASSIS CONFIGURATION This chapter explains the configuration features of the Cuda 12000 chassis and includes the following sections: ■ Understanding Chassis Identification (page 76) ■ Understanding Management Module Redundancy (page 76) ■ Configuring Chassis Parameters (page 78) ■ Displaying Current Chassis Configuration (page 81) ■ Configuring Clock Sources (page 86) ■ Starting and Stopping the HTTP Server (page 88) ■ Enabling and Disabling Traffic Relay (page 89) ■ Broadcasting Messages to Users (page 91) In addition to the features described in this chapter, you can group multiple chassis together to be managed through a single network management view. Refer to Chapter 5 “Multi-Chassis Support” for more information. 76 CHAPTER 4: CHASSIS CONFIGURATION Understanding Chassis Identification The Cuda 12000 chassis has two key identifiers: ■ Chassis Number — The Cuda 12000 chassis is shipped with a unique chassis-number, which is a fixed value assigned to each chassis during manufacturing at the ADC plant. ■ Chassis ID — Each Cuda 12000 switch should be configured with a unique chassis identification (ID) number. The chassis ID serves as a router management tool. Understanding Management Module Redundancy Each chassis is equipped with at least one management module, which controls the chassis. For management module redundancy, the Cuda 12000 supports installation of two management modules. When two management modules are installed, one acts as the primary management module and the other acts as the secondary management module. When a Cuda 12000 that is configured with two management modules reboots, the Cuda randomly determines which module acts as the primary and which module acts as the secondary. The STATUS DISPLAY LED on the management module indicates whether the management module is a primary or secondary (for example, the LED on a primary management module displays “PRIMARY”). The primary management module is the active management module on the Cuda 12000. When you issue CLI commands or use the Cuda Desktop GUI to manage the Cuda 12000, you are interacting with the primary management module. The secondary management module has two responsibilities: ■ Monitor the state of the primary management module ■ Keep its mirrored disk sectors synchronized with the primary management module ADC Telecommunications, Inc. Understanding Management Module Redundancy 77 A secondary management module can take over the primary role in two ways: ■ Automatically, when the secondary management module detects that the primary management module is not functioning properly. ■ Manually, through the chassis-config CLI command. In this case, you use the command to force the current primary management module into the secondary role, which in turn forces the current secondary management module into the primary role. When the secondary management module takes over the primary role, the secondary: ■ Activates its copy of the chassis software ■ Establishes connections with all other cards in the chassis When the secondary management module activates its copy of the BAS software and establishes connections to cards, the secondary management module also starts services, including disk-mirroring and LDAP. Through disk mirroring, the software on the two management modules share data. When a switch to a secondary management module occurs: ■ Services are unavailable for a brief period of time ■ Network management access is prevented for a brief period of time. The Cuda’s data-forwarding operation is not disrupted while a switchover to a backup occurs. Cuda 12000 IP Access Switch CLI-based Administration Guide 78 CHAPTER 4: CHASSIS CONFIGURATION Configuring Chassis Parameters Chassis configuration includes the following parameters: ■ Chassis Number — A fixed number assigned to the Cuda 12000 chassis during manufacturing at the ADC plant. ■ Chassis ID — User-defined. A unique identification number that you assign to the Cuda 12000 chassis in the network. The Cuda uses a multi-range numbering system. Acceptable chassis ID values are 1 to 128, or the number 255. ■ Cluster ID — User-defined. An ID of “0” is the default and is recommended. ■ Manager — Enables you to force the current primary management module into a secondary role, thereby forcing the current secondary management module into the primary role. ■ Scope — Currently, “Cluster” is the only supported value. Before you proceed to configure a chassis, you must know the number of the specific chassis. To display the current chassis configuration, including the current Chassis Number, use the show chassis-config command within root mode. For example: cli:172.16.19.10:root# show chassis-config Chassis Number: 101 Chassis Id: 1 Cluster Id: 0 Primary Manager Slot: 13 Secondary Manager Slot: 14 Scope: Cluster cli:172.16.19.10:root# ADC Telecommunications, Inc. Configuring Chassis Parameters 79 Configuration of chassis parameters is achieved using the chassis-config command within root mode. Perform the following tasks within root mode to configure chassis parameters: Task Command 1. Identify the chassis number. show chassis-config 2. Configure the chassis ID. chassis-config chassisid <1..128> 3. Configure the Cluster ID chassis-config clusterid 4. Switch the primary management module to a secondary role, thereby forcing the secondary management module into the primary role. chassis-config manager secondary 5. Define the management scope of chassis-config the primary or secondary chassis scope {chassis | cluster} controller. The following example steps you through the chassis configuration process: cli:172.16.19.10:root# show chassis-config Chassis Number: 101 Chassis Id: 5 Cluster Id: 20 Primary Manager Slot: 13 Secondary Manager Slot: 14 Scope: Chassis cli:172.16.19.10:root# chassis-config 101 chassisid 1 cli:172.16.19.10:root# chassis-config 101 clusterid 0 cli:172.16.19.10:root# chassis-config 101 scope cluster cli:172.16.19.10:root# show chassis-config Chassis Number: 101 Chassis Id: 1 Cluster Id: 0 Primary Manager Slot: 13 Secondary Manager Slot: 14 Scope: Cluster cli:172.16.19.10:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 80 CHAPTER 4: CHASSIS CONFIGURATION The following example shows you how to force a primary management module into a secondary role, thereby forcing the secondary management module into a primary role: cli:192.168.222.200:root# show chassis-config Chassis Number: 101 Chassis Id: 1 Cluster Id: 0 Primary Manager Slot: 13 Secondary Manager Slot: 14 Scope: Cluster cli:192.168.222.200:root# chassis-config 101 manager secondary Connection to 192.168.222.200 refused or closed! Note that you must reconnect to the Cuda 12000 after you force the management modules to change roles. ADC Telecommunications, Inc. Displaying Current Chassis Configuration 81 Displaying Current Chassis Configuration The Cuda 12000 allows you to generate a list of CLI commands that display the current running state of the chassis configuration. The command that supports this function is show running-config. Use the following procedure to display the complete current configuration: Task Command 1. Enter root mode. root 2. Display the current configuration. show running-config [{all | xml | server-name }] Note that: ■ When you issue the command with no arguments, the output does not display default values. Issue the command with the all argument to display all values. ■ The xml argument displays the output in XML format. ■ The server-name argument is reserved for ADC internal use only. In addition to displaying the running configuration, you have the ability to generate a script to a file. This script may be used to configure other chassis to use the same configuration. You can write the script within the bascli environment using the source command; or you may use -f within a telnet session. Cuda 12000 IP Access Switch CLI-based Administration Guide 82 CHAPTER 4: CHASSIS CONFIGURATION Example cli:192.168.208.3:root# show running-config ! ! BAS Chassis event-config reporting warning local|syslog|traps event-config reporting notice local|syslog|traps event-config reporting info none traffic-relay tftp port 69 traffic-relay time_of_day port 37 ! ! RIP Protocol router rip ! ! RIP Import filters import up ! ! RIP Export filters export up root ! ! OSPF Protocol router ospf ospf area 0.0.0.0 ! ! OSPF Import filters import up ! ! OSPF Export filters export up root ! ! IP Protocol ! ! Bridge Group Holder ! ! Bas SNMP Manager snmp-server group adc v1 read public write private notify public context adc s torage nonvolatile snmp-server group adc v2c read public write private notify public context adc storage nonvolatile ADC Telecommunications, Inc. Displaying Current Chassis Configuration 83 snmp-server group adc v3 noauth read public write private notify public contex t adc storage nonvolatile snmp-server group mgr v3 noauth read nosnmpconfig context monitor storage nonv olatile snmp-server group guitraps v1 notify guitraps storage readonly snmp-server group guitraps v2c notify guitraps storage readonly snmp-server group superman v3 priv read allaccess write allaccess context admi n storage nonvolatile snmp-server group admingroup v1 read allaccess write allaccess storage nonvola tile snmp-server group admingroup v2c read allaccess write allaccess storage nonvol atile snmp-server group monitorgroup v1 read nosnmpconfig storage nonvolatile snmp-server group monitorgroup v2c read nosnmpconfig storage nonvolatile snmp-server group trapcommunity v1 notify allaccess storage nonvolatile snmp-server group trapcommunity v2c notify allaccess storage nonvolatile snmp-server view public 1.3.6.1 included storage nonvolatile snmp-server view private 1.3.6.1 included storage nonvolatile snmp-server view guitraps 1.3.6.1 included storage readonly snmp-server view allaccess 1.3.6.1 included storage nonvolatile snmp-server view nosnmpconfig 1.3.6.1 included storage nonvolatile snmp-server view nosnmpconfig 1.3.6.1.6.3 excluded storage nonvolatile snmp-server community admincon admingroup address 192.168.212.0 mask 255.255.2 55.0 storage nonvolatile snmp-server community guitraps guitraps storage readonly snmp-server community justme admingroup address 100.100.10.5 address 100.100.1 0.8 address 192.168.212.109 storage nonvolatile snmp-server community monitor monitorgroup storage nonvolatile snmp-server community private adc context adc storage nonvolatile snmp-server community public adc context adc storage nonvolatile Cuda 12000 IP Access Switch CLI-based Administration Guide 84 CHAPTER 4: CHASSIS CONFIGURATION snmp-server community trapcommunity trapcommunity storage nonvolatile snmp-server host 127.0.0.1 guitraps udp-port 54321 storage readonly snmp-server host 201.1.1.20 trapcommunity version 1 udp-port 162 ! ! Fault Manager ! ! Controller Module slot 1/13 ! ! Gigabit Ethernet Module slot 1/3 ! ! Interface 1/3/1 Gigabit Ethernet Mac interface ethernet 1/3/1 root ! ! 10/100 Ethernet Module slot 1/11 ! ! Interface 1/11/1 10/100 Ethernet MAC interface ethernet 1/11/1 ! ! IP Address ip address 199.199.1.1 255.255.255.0 ip ospf area-id 0.0.0.1 up root ! ! Interface 1/11/2 10/100 Ethernet MAC interface ethernet 1/11/2 root ! ! Interface 1/11/3 10/100 Ethernet MAC interface ethernet 1/11/3 root ! ! Interface 1/11/4 10/100 Ethernet MAC interface ethernet 1/11/4 root ! ! Interface 1/11/5 10/100 Ethernet MAC interface ethernet 1/11/5 root ! ! Interface 1/11/6 10/100 Ethernet MAC ADC Telecommunications, Inc. Displaying Current Chassis Configuration 85 interface ethernet 1/11/6 root ! ! Interface 1/11/7 10/100 Ethernet MAC interface ethernet 1/11/7 root ! ! Interface 1/11/8 10/100 Ethernet MAC interface ethernet 1/11/8 root ! ! CMTS Module slot 1/1 ! ! Interface 1/1/1 CMTS MAC interface cable 1/1/1 dhcp-policy default permit forward-internal dhcp-relay add-agent-options enable ip source-route 201.1.2.0 255.255.255.0 201.1.3.1 ip source-route 201.1.4.0 255.255.255.0 201.1.5.0 ip source-route 201.4.6.0 255.255.255.0 201.2.7.0 admission-control disable privacy base auth-lifetime 604800 tek-lifetime 43200 cert-trust trusted enab le-cert-validity-periods true cm-offline timer 10 cpe-control max-ip 10 cpe-control active trace-log baseline-privacy true registration true ranging true ! ! Interface 1/1/1 CMTS Downstream downstream transmit-power 0 downstream no shutdown ! ! Interface 1/1/1 CMTS Upstream 1 upstream 1 frequency 42.0 voice-bw-reserve 65.0 upstream 1 no shutdown ! ! Interface 1/1/1 CMTS Upstream 2 upstream 2 voice-bw-reserve 60.0 upstream 2 no shutdown ! ! Interface 1/1/1 CMTS Upstream 3 ! ! Interface 1/1/1 CMTS Upstream 4 root ! Cuda 12000 IP Access Switch CLI-based Administration Guide 86 CHAPTER 4: CHASSIS CONFIGURATION ! POS Module slot 1/8 ! ! Interface 1/8/1 POS MAC interface pos 1/8/1 arp timeout 0 ! ! BasPppProtocol root Configuring Clock Sources The Cuda 12000 IP Access Switch backplane has a primary clock (A) and a secondary clock (B). For each of these clocks, you can configure one of the following clock sources: ■ External BITS-A clock source ■ External BITS-B clock source ■ External Packet-Over-SONET (POS) clock source ■ Internal Stratum-3 oscillator clock source on the management module If you do not configure any clock sources, each DOCSIS/EuroDOCSIS module uses its own clock. If you are using a BITS-A or BITS-B external clock source, make sure that the Cuda 12000 is connected to the appropriate clock sources via the BITS-A or BITS-B external clock connectors. Refer to the Cuda 12000 IP Access Switch Installation Guide for more information on these connectors. If you are using a POS module as the clock source, make sure that the interface on the POS module has been configured to receive clocking from the other (remote) side of the POS link. To do this, issue the following command from within POS interface mode: clock-source line Refer to Chapter 7 “Packet Over SONET Administration” for more information on configuring POS interfaces. ADC Telecommunications, Inc. Configuring Clock Sources 87 A typical configuration would be as follows: ■ Primary clock configured to use a BITS-A or BITS-B external clock source ■ Secondary clock configured to use the internal Stratum-3 oscillator clock source. The example at the end of this section illustrates the commands you would issue to create this typical configuration. To configure primary and secondary clock sources, perform the following tasks: Task Command 1. Enter root mode. root 2. Configure the clock source for the aux-device backplane-clock-a primary clock. {bits-a | bits-b | internal | none | slot {enable | disable}} Note that the slot {enable | disable} argument configures a POS module as the clock source. The variable specifies the POS module’s slot. Specify the enable keyword to enable the POS module as a clock source; specify the disable keyword to disable the POS module as a clock source. 3. Configure the clock source for the aux-device backplane-clock-b secondary clock. {bits-a | bits-b | internal | none | slot {enable | disable}} 4. Verify primary and secondary clock sources. show aux-device backplane-clocks Example In this example, the clock source for the primary clock is BITS-A, and the clock source for the secondary clock is the internal Stratum 3 oscillator. cli:192.168.220.244:root# aux-device backplane-clock-a bits-a cli:192.168.220.244:root# aux-device backplane-clock-b internal cli:192.168.220.244:root# show aux-device backplane-clocks Stratum-3 oscillator Installed Backplane clock A source bitsA Backplane clock B source internal Cuda 12000 IP Access Switch CLI-based Administration Guide 88 CHAPTER 4: CHASSIS CONFIGURATION Starting and Stopping the HTTP Server The chassis runs an HTTP server, which allows CudaView users to manage the chassis with their Web browsers. Refer to the Cuda 12000 IP Access Switch CudaView Administration Guide for more information on CudaView. You can start and stop the HTTP server using the http-server command. If you stop the HTTP server, the chassis cannot be managed through CudaView. By default, the HTTP server is enabled and running. To start and stop the HTTP server, perform these tasks: Task Command 1. Enter root mode. root 2. Start the HTTP server. http-server enable 3. Stop the HTTP server. http-server disable ADC Telecommunications, Inc. Enabling and Disabling Traffic Relay 89 Enabling and Disabling Traffic Relay You can configure processes, such as the HTTP server, to send and receive TCP or UDP packets using an internal address on the Cuda 12000. This method of sending and receiving packets is called traffic relay. If you are running a TFTP server on the Cuda 12000 as part of FastFlow BPM provisioning, you must enable traffic relay for the TFTP server in order to download configuration files to cable modems. The TFTP server sends and receives packets using an internal address. Refer to the FastFlow BPM documentation set for more information on the FastFlow BPM. The traffic-relay command also allows you to configure the Cuda 12000 for in-band management. For example, you can use this command to enable forwarding of Telnet traffic and HTTP traffic using an internal address, thereby allowing you to perform in-band management of the Cuda 12000 using the CLI or CudaView. To enable or disable traffic relay for a process, perform these tasks: Task Command 1. Enter root mode. root 2. Enable traffic relay for a process. traffic-relay {dns | ftp | http | snmp | snmp-trap | ssh | syslog | telnet | tftp | time_of_day} [port ] Refer to the Cuda 12000 IP Access Switch CLI Reference Guide for details on command syntax. 3. Disable traffic relay for a process. no traffic-relay {dns | ftp | http | snmp | snmp-trap | ssh | syslog | telnet | tftp | time_of_day} 4. Display traffic relay status. show traffic-relay Note that the port argument allows you to specify a port that the specified process uses to listen for incoming requests. Cuda 12000 IP Access Switch CLI-based Administration Guide 90 CHAPTER 4: CHASSIS CONFIGURATION Example In this example, traffic relay is enabled for Telnet. cli:192.168.208.3:root# traffic-relay telnet cli:192.168.208.3:root# show traffic-relay row count: 10 Protocol -----------tftp time_of_day syslog dns snmp telnet ssh http ftp snmp-trap State Port Number -------- ----------enable 69 enable 37 disable 514 disable 53 disable 161 enable 23 disable 22 disable 80 disable 21 disable 162 cli:192.168.208.3:root# ADC Telecommunications, Inc. Broadcasting Messages to Users 91 Broadcasting Messages to Users The talk command enables you to broadcast messages to all chassis users and to enable and disable the ability to broadcast messages. To broadcast messages to users, perform the following task: Task Command From any mode, send a broadcast talk message. Note that if the string contains spaces, enclose it in quotes. To enable or disable the broadcast capability, perform the following task: Task Command From any mode, enable or disable talk {enable | disable} the broadcast capability. Example cli:192.168.208.3:root# talk "Testing the broadcast message feature" @14:20:42 root@techpubs:: Testing the broadcast message feature cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 92 CHAPTER 4: CHASSIS CONFIGURATION ADC Telecommunications, Inc. 5 MULTI-CHASSIS SUPPORT This chapter describes multi-chassis support, and includes the following sections: ■ About Multi-Chassis Support (page 94) ■ Planning Multi-Chassis Support (page 96) ■ Enabling the Jini Lookup Service (page 97) ■ Configuring Multi-Chassis Support (page 98) ■ Creating a Common User Account for the Group (page 100) ■ Viewing Chassis Details (page 101) 94 CHAPTER 5: MULTI-CHASSIS SUPPORT About Multi-Chassis Support The purpose of multi-chassis support is to allow network administrators, from a single session, to access and manage multiple chassis as a single group. When a network administrator connects to a chassis that is a member of a multi-chassis group, the administrator can also access all other chassis in that group without having to connect to each chassis individually. To become a member of a multi-chassis group, each chassis must have multi-chassis support enabled and must be configured with the same group name. When a chassis is configured with a group name, the chassis registers its name with the Jini™ lookup service, which acts as a directory that enables all chassis in the same group to find each other. When planning multi-chassis support, consider that each Cuda 12000 can run the Jini lookup service, but the service does not have to be enabled on every Cuda 12000. Refer to “Planning Multi-Chassis Support” on page 96 for more information on planning multi-chassis support. To access the multi-chassis group, the network administrator logs in to one of the chassis in the group. The network administrator then can select either that chassis to manage or any other chassis in the group. The Cuda 12000 uses a proxy-based approach to communicate between the host chassis — the chassis to which you are currently logged in — and other chassis within the same group. The Java server on the management module in the host chassis forwards network management messages that are destined for other chassis to the appropriate chassis group member. You can manage SNMPv3 resources (contexts and users) on the host chassis only. In addition, you can manage hardware alarms/faults and user accounts on the host chassis only. You cannot manage SNMPv3, hardware alarms/faults, and user accounts by proxy. ADC Telecommunications, Inc. About Multi-Chassis Support 95 The multi-chassis group, MCS-Group1, in the example below consists of three chassis: A, B, and C. The group name “MCS-Group1” is configured on each chassis, and each chassis registers this name with the Jini lookup service running on Chassis C. In this example, the network administrator logs in to Chassis B (the host chassis), but keep in mind that the network administrator can also log in to Chassis A and Chassis C to access the group. When the network administrator performs network management operations (such as configuring an interface) on Chassis A and Chassis C, then Chassis B forwards network management messages to Chassis A and Chassis C. Chassis B also forwards messages to the network administrator’s workstation that originate from Chassis A and Chassis C. Chassis A Messages Messages Chassis B Host Chassis Network Administrator’s Workstation Chassis C Messages Figure 5-1 Sample Multi-Chassis Group Cuda 12000 IP Access Switch CLI-based Administration Guide MCS-Group1 Jini lookup service running on Chassis C 96 CHAPTER 5: MULTI-CHASSIS SUPPORT Planning Multi-Chassis Support Before you configure multi-chassis support, perform these planning tasks: ■ Identify each Cuda 12000 chassis that will be in the group. Make sure that all chassis in the group are running software versions that have multi-chassis support. ■ Decide on a group name. A descriptive name is suggested (for example, “MCS-Group-Net-Mgmt”). The name may not contain spaces. You will configure this name on each chassis in the group. ■ Decide on a user account for the group with the necessary access privileges for performing your desired network management tasks. All Cuda 12000s in the group must have a common, identical user account. When you connect to a chassis in the group, you must login to this account to access all members of the group. ■ Make sure that all chassis in the group share the same physical network (such as the same Ethernet LAN). Members of the same group cannot reside on different physical networks. ■ Identify two Cuda 12000 chassis that will run the Jini lookup service. The reason you should enable the Jini lookup service on two Cuda 12000 chassis (instead of one) is to put redundancy in place. Each chassis that runs the Jini lookup service must be on the same physical network as the multi-chassis group that it serves. After you finish planning multi-chassis support, perform these tasks: 1. Enable the Jini lookup service. Refer to “Enabling the Jini Lookup Service” on page 97. 2. Configure multi-chassis support on each Cuda 12000 chassis in the group. Refer to “Configuring Multi-Chassis Support” on page 98 for details. 3. Create a common user account on each chassis in the group. Refer to “Creating a Common User Account for the Group” on page 100. 4. Monitor the group as needed. Refer to “Viewing Chassis Details” on page 101. ADC Telecommunications, Inc. Enabling the Jini Lookup Service 97 Enabling the Jini Lookup Service Enable the Jini lookup service on at least two Cuda 12000 chassis. Each chassis that runs the Jini lookup service must be on the same physical network as the multi-chassis group that it serves. To enable the Jini lookup service on a chassis, perform the following tasks: Tasks Commands 1. Enter configuration mode. root 2. Enable the Jini lookup service. lookup enable 3. Verify the Jini status. show lookup Example In this example, the status of the Jini lookup service is displayed, then the Jini lookup service is started, and finally the Jini lookup status is displayed again. cli:192.168.208.3:root# show lookup # JINI lookup service (reggie) is stopped. cli:192.168.208.3:root# lookup enable Please wait, this may take some time ... # rmid is stopped # Starting RMI activation daemon: OK # # httpd (pid 4055 4054 4053 4052 4051 4050 4049 540 539 538 537 536 535 534 533 531) is running... # rmid (pid 5492 5491 5490 5489 5488 5487 5486 5485 5484 5483 5482 5481 5480 547 9 5478 5433) is running... # JINI lookup service (reggie) is stopped. # CODEBASE= http://192.168.208.3:80/jini/reggie-dl.jar # POLICY= /bas/data/java.policy # LOG_DIR= /var/log/reggie_log # GROUPS= Cuda12000 # Registering JINI lookup service: OK # # JINI lookup service (reggie) is running. cli:192.168.208.3:root# show lookup # JINI lookup service (reggie) is running. Cuda 12000 IP Access Switch CLI-based Administration Guide 98 CHAPTER 5: MULTI-CHASSIS SUPPORT Configuring Multi-Chassis Support The Cuda 12000 ships with multi-chassis support enabled. During the initial installation (or upgrade) of the Cuda operating system software, the Java server checks for a multi-chassis support service property. If the property is not found, the Java server automatically enables multi-chassis support, using Jini as the chassis discovery mechanism on the local network. When multi-chassis support is enabled, all chassis on the same physical network register with each Jini lookup service. Chassis that have the same group name form a multi-chassis group. By default, the Cuda 12000 ships with multi-chassis support activated, and the local group name of Cuda. You can use the CLI to manually enable and disable multi-chassis support and to override the default group name with one of your own choosing. If you override the default name, make sure that the new name you specify is the correct group name (that is, it matches the group names configured on other chassis in the group). In addition, you can also specify a group description and access additional chassis using the connect command. Perform these tasks to manually configure multi-service support on a chassis: Tasks Commands 1. Enter configuration mode. root 2. Enable or disable multi-chassis support, specify a group name, or specify a description. chassis {mcs {enable | disable} | group | description } 3. Display multi-chassis group status. show chassis {local | } 4. Access another chassis while in the current log-in session. connect ADC Telecommunications, Inc. Configuring Multi-Chassis Support 99 Example In this example, the administrator enables multi-chassis support, specifies a group name, and displays multi-chassis status on the chassis (local chassis) that the administrator is currently configuring. cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# Multi Chassis Host Name : IP Address : Group Name : Version : Description : chassis mcs enable chassis group Cuda-Group1 chassis description "Cuda Group 1" show chassis local Service : enable techpubs 192.168.208.3 Cuda-Group1 3.0.19 Release3.0_Beta 5 2001_09_13_1334 Cuda Group 1 Cuda 12000 IP Access Switch CLI-based Administration Guide 100 CHAPTER 5: MULTI-CHASSIS SUPPORT Creating a Common User Account for the Group On each chassis in the group, create the same user account (same username, same password, same access privileges). Then, to access all chassis in the group, log in to the host chassis using this account. You can manage user accounts on a chassis to which you are directly connected and logged into only (on the host chassis). You cannot manage user accounts by proxy. Refer to Chapter 3 “Managing User Accounts” for more information on creating user accounts. ADC Telecommunications, Inc. Viewing Chassis Details 101 Viewing Chassis Details You can view chassis details for a local chassis, a particular chassis within a group, or all the chassis in a group. Chassis details include the following information: Table 5-1 Chassis Details Parameter Description Multi Chassis Service Indicates whether or not multi-chassis support is activated on the particular chassis. This field appears only if you specify the local keyword on the show chassis command. Host Name The host name assigned to the chassis. IP Address Indicates the IP address of the particular chassis. Group Name The group name assigned to the chassis. Version The current Cuda software version that is running on the chassis. Description The description assigned to the chassis group. Perform the following tasks to view chassis details. Note that all commands are issued in root mode: Task Command 1. View details of the host chassis. show chassis local The host chassis is the chassis for which you currently have access. 2. View details for a particular show chassis chassis, within the same group in which you currently have access. 3. View details for all the show chassis chassis within the same group in which you currently have access. Cuda 12000 IP Access Switch CLI-based Administration Guide 102 CHAPTER 5: MULTI-CHASSIS SUPPORT Example The following is an example of a list of chassis in the group named “Cuda:” cli:192.168.220.208:root# show chassis Found 33 chassis. Host Name IP Address Group Name Version Description : : : : : jsl_cuda xxx.xxx.xxx.xxx cuda 3.0.6 R3dev_cmts 16 2001_07_16_1532 null Host Name IP Address Group Name Version Description : : : : : lynnebcm xxx.xxx.xxx.xxx cuda 3.0.6 release3.1_bgp 10 2001_08_10_0647 null Host Name IP Address Group Name Version Description : : : : : sw19_cuda xxx.xxx.xxx.xxx cuda 3.0.9 R3dev_cmts 10 2001_07_25_1610 null Host Name IP Address Group Name Version Description : : : : : adc_cuda xxx.xxx.xxx.xxx cuda 3.0.9 Release3.1 29 2001_07_24_1130 null Host Name IP Address Group Name Version Description : : : : : c0222 xxx.xxx.xxx.xxx cuda 3.0.13 Release3.0_Beta 140 2001_08_08_1331 null ADC Telecommunications, Inc. 6 MODULE ADMINISTRATION This chapter provides general information on how to view and manage Cuda application modules through the CLI and provides specific information on managing Ethernet modules. The chapter includes the following sections: ■ Cuda Application Modules (page 104) ■ Configuring the 10/100 Ethernet and GigE Modules (page 105) ■ Viewing Module Information (page 106) ■ Viewing Ethernet Interface Packet Statistics (page 110) Refer to Chapter 7 “Packet Over SONET Administration” for details on Packet Over SONET administration. Refer to Chapter 18 “Configuring Cable Modem Termination Systems” for details on CMTS administration. 104 CHAPTER 6: MODULE ADMINISTRATION Cuda Application Modules Cuda 12000 application modules interface with attached networks. The system supports installation of the following module types: ■ DOCSIS — Provides Cable Modem Terminating System (CMTS) functions for two-way data communication over domestic cable networks. ■ EuroDOCSIS — Provides Cable Modem Terminating System (CMTS) functions for two-way data communication over European cable networks. ■ 10/100 Octal Ethernet — Provides eight autosensing 10/100 Mbps. ports for connection to your Ethernet network. ■ Gigabit Ethernet — Provides 1000 Mbps connection to your Gigabit Ethernet network. ■ Packet-Over-SONET (POS) — Available in both OC-3 and OC-12 configurations, provides high-speed transmission of IP packets directly over SONET links. ADC Telecommunications, Inc. Configuring the 10/100 Ethernet and GigE Modules 105 Configuring the 10/100 Ethernet and GigE Modules The Cuda 12000 allows you to configure duplex mode for interfaces on the 10/100 module and the interface on the GigE modules. The Cuda 12000 also allows you to configure speed for interfaces on the 10/100 module. You may set duplex mode to full duplex, half duplex, or auto negotiation. You may set the speed of the 10/100 module to 10 Mbps, 100 Mbps, or auto negotiation. By default, the Cuda 12000 sets duplex mode and speed for auto negotiation. You use the following commands to change duplex mode and speed settings: Task Command 1. Enter interface configuration interface mode for the Ethernet interface. 2. Set interface duplex mode. duplex {half | full | auto} 3. Set interface speed. speed {10 | 100 | auto} 4. Enable interface auto negotiation. negotiation auto 5. Disable interface auto negotiation. no negotiation auto Refer to the Cuda 12000 IP Access Switch CLI Reference Guide for more information on these commands. Cuda 12000 IP Access Switch CLI-based Administration Guide 106 CHAPTER 6: MODULE ADMINISTRATION Viewing Module Information This section provides information on how to view module information, including: ■ Viewing Installed Modules ■ Viewing Module Versions Viewing Installed Modules You can display a listing of modules and their associated interfaces currently installed on the system by using the show topology command. To show the current physical configuration of the system, perform the following task from within any mode: Task Command Display system topology, including module and interface information. show topology You can pipe the output to an include utility to scope the display down to content of interest. For example, the command show topology | include Ethernet will scope the output to only Ethernet interfaces. Note that the string you specify is case-sensitive. ADC Telecommunications, Inc. Viewing Module Information 107 The following example shows the modules currently installed in the Cuda chassis: cli:172.16.19.10:root# show topology row count: 12 Chassis/Slot/ Interface ---------------1 / 1 / 1 1 / 3 / 1 1 / 6 / 1 1 / 8 / 1 1 / 11 / 1 1 / 11 / 2 1 / 11 / 3 1 / 11 / 4 1 / 11 / 5 1 / 11 / 6 1 / 11 / 7 1 / 11 / 8 Class Interface Type Status ---------Egress Egress Egress Egress Egress Egress Egress Egress Egress Egress Egress Egress -------------------docsCableMaclayer POS (OC3c) docsCableMaclayer Ethernet (Gigabit) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) Ethernet (100 Mb) -------------Active Not In Service Active Not In Service Not In Service Not In Service Not In Service Not In Service Not In Service Not In Service Not In Service Not In Service cli:172.16.19.10:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 108 CHAPTER 6: MODULE ADMINISTRATION Viewing Module Versions You can view the software version currently installed on each module. To do so, perform the following task within any mode. Task Command Show the firmware version installed on each module. show version For example: cli:172.16.19.10:root# show version 2.0.1 Release2 8 2000_10_10_2059 row count: 6 Chassis Slot LPort Boot Time Description ------- ------- ------- -------------- ---------------------------------------1 1 2 99-08-28 11:43 BAS CMTS, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 1 3 1 99-08-28 11:43 BAS Forwarder, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 1 6 2 99-08-28 11:43 BAS EURO-CMTS, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 1 8 1 99-08-28 11:43 BAS Forwarder, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 1 11 1 99-08-28 11:43 BAS Forwarder, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 1 11 2 99-08-28 11:43 BAS Route Server, Hardware V1, Software V2.0, Build #1 [Release2 8 ] built 2000_10_10_2059 cli:172.16.19.10:root# ADC Telecommunications, Inc. Viewing Module Information 109 Table 6-1 describes the information in the display. Table 6-1 Show Version Field Descriptions : Field Description Chassis Number assigned to the chassis in which each module resides. Slot Number of the physical chassis slot in which the module resides. For information on how slots are numbered, see the Cuda 12000 IP Access Switch Installation Guide. LPort Logical port utilized by the module. For ADC use only. Boot Time Indicates date and time of last module bootup. Description Specifies the following: ■ Cuda 12000 IP Access Switch CLI-based Administration Guide Hardware and software version of the module. ■ Module type (function) ■ Build Information (build number and date) 110 CHAPTER 6: MODULE ADMINISTRATION Viewing Ethernet Interface Packet Statistics You can view both incoming and outgoing packet statistics for a selected interface. To do so, perform the following tasks within either root mode or interface configuration mode: Task Command 1 Show incoming packet statistics for a selected Ethernet interface. show interface ethernet in-counters 2. Show outgoing packet statistics for a selected Ethernet interface. show interface ethernet out-counters The following example uses the show topology command piped to include to grep for all Ethernet interfaces. It then displays incoming packet statistics for Ethernet interface 8: ADC Telecommunications, Inc. Viewing Ethernet Interface Packet Statistics cli:172.16.19.10:root# show 1 / 8 / 1 Egress 1 / 11 / 1 Egress 1 / 11 / 2 Egress 1 / 11 / 3 Egress 1 / 11 / 4 Egress 1 / 11 / 5 Egress 1 / 11 / 6 Egress 1 / 11 / 7 Egress 1 / 11 / 8 Egress topology Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet Ethernet 111 | include Ethernet (Gigabit) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service (100 Mb) Not In Service cli:172.16.19.10:root# show interface ethernet 1/11/8 in-counters Interface 1 / 11 / 8 Type ethernet In octets 0 In unicast 0 In multicast 0 In broadcast 0 cli:172.16.19.10:root# show interface ethernet 1/11/8 out-counters Interface 1 / 11 / 8 Type ethernet Out octets 0 Out unicast 0 Out multicast 0 Out broadcast 0 cli:172.16.19.10:root# The following incoming statistics are displayed for each interface: ■ In Octets — Total number of Octets that have been received on this interface, including framing characters. ■ In Unicast Packets — Number of Unicast packets that have been received on this interface. ■ In Multicast Packets — Number of Multicast packets that have been received on this interface. ■ In Broadcast Packets — Number of Broadcast packets that have been received on this interface. The following outgoing statistics are displayed for each interface: ■ Out Octets — The total number of octets that have been transmitted out of this interface, including framing characters. ■ Out Unicast Packets — The total number of Unicast packets that have been transmitted out of this interface. Cuda 12000 IP Access Switch CLI-based Administration Guide 112 CHAPTER 6: MODULE ADMINISTRATION ■ Out Multicast Packets — The total number of Multicast packets that have been transmitted out of this interface. ■ Out Broadcast Packets — The total number of Broadcast packets that have been transmitted out of this interface. Displaying Statistics for All System Interfaces You can display incoming and outgoing statistics for all system interfaces. To do so, perform the following tasks within any mode: Task Command 1 Show incoming packet statistics for a selected Ethernet interface. show in-counters 2. Show outgoing packet statistics for a selected Ethernet interface. show out-counters The following example displays incoming statistics for all system interfaces, then pipes the output to include outgoing statistics for only cable (DOCSIS) interfaces: ADC Telecommunications, Inc. Viewing Ethernet Interface Packet Statistics 113 cli:172.16.19.10:root# show in-counters row count: 22 Interface ------------1 / 1 / 1 1 / 1 / 3 1 / 1 / 4 1 / 1 / 5 1 / 1 / 6 1 / 3 / 1 1 / 3 / 2 1 / 3 / 3 1 / 6 / 1 1 / 6 / 3 1 / 6 / 4 1 / 6 / 5 1 / 6 / 6 1 / 8 / 1 1 / 11 / 1 1 / 11 / 2 1 / 11 / 3 1 / 11 / 4 1 / 11 / 5 1 / 11 / 6 1 / 11 / 7 1 / 11 / 8 Type In octets In unicast In multicast In broadcast -------------- ---------- ---------- ------------ -----------docsCableMac 11512319 322192 0 0 docsCableUS(1) 6613451 186371 0 0 docsCableUS(2) 4898868 135821 0 0 docsCableUS(3) 0 0 0 0 docsCableUS(4) 0 0 0 0 sonet 0 0 0 0 sonetPath 0 0 0 0 ppp 0 0 0 0 docsCableMac 0 0 0 0 docsCableUS(1) 0 0 0 0 docsCableUS(2) 0 0 0 0 docsCableUS(3) 0 0 0 0 docsCableUS(4) 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 ethernet 0 0 0 0 cli:172.16.19.10:root# show out-counters | include docs 1 / 1 / 1 docsCableMac 1808872424 315544 1 / 1 / 2 docsCableDS 1808873040 315544 1 / 6 / 1 docsCableMac 0 0 1 / 6 / 2 docsCableDS 0 0 cli:172.16.19.10:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 330207364 330207378 0 0 7669 7669 0 0 114 CHAPTER 6: MODULE ADMINISTRATION ADC Telecommunications, Inc. 7 PACKET OVER SONET ADMINISTRATION This chapter provides information on how to configure Packet over SONET (POS) on the Cuda 12000 using the CLI and includes the following sections: ■ About Packet Over SONET (page 116) ■ Packet Over SONET (POS) Interface Administration (page 117) ■ Configuring and Viewing SONET Alarms (page 132) ■ Configuring Point-to-Point Protocol (PPP) (page 137) The section covers functionality available in the Cuda 12000 Base System Software. 116 CHAPTER 7: PACKET OVER SONET ADMINISTRATION About Packet Over SONET Packet Over SONET enables the Cuda 12000 to transmit IP packets over SONET links; essentially placing the IP layer over the SONET physical layer. POS makes efficient use of bandwidth, allowing for lower packet overhead and extremely fast transmission speeds. The system uses point-to-point protocol (PPP) to transport IP data over SONET point-to-point circuits, as described in RFC 2615. The IP over SONET transmission process consists of three primary steps: ■ Encapsulate the IP datagram into a PPP frame. ■ Place the PPP frame into the payload portion of the SONET frame. ■ Transmit the SONET frame over the point-to-point circuit. Figure 6-1 shows the POS transport structure in relation to the OSI network model: Figure 6-1 Packet Over SONET — Network Structure IP Datagram Layer 3 — Network Layer PPP Encapsulation Layer 2 — Data Link Layer SONET Layer 1 — Physical Transport Layer POS administration on the Cuda 12000 involves the following: ■ Administration of the physical SONET interface at layer 1, as described in “Packet Over SONET (POS) Interface Administration,” next. ■ Administration of the point-to-point protocol (PPP) used to encapsulate the IP data at layer 2, as described in “Configuring Point-to-Point Protocol (PPP)” on page 137. ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 117 Packet Over SONET (POS) Interface Administration Packet over Synchronous Optical Network (SONET) allows for high-speed transport of IP data packets over a SONET network. The OC-3 and OC-12 POS modules contain a single physical interface that supports connection to STS networks and supports transmission speeds of up to 155 Mbps. A SONET frame is 810 bytes represented as a grid of 9 rows by 90 columns. The frame consists of hierarchal layers, each providing services for the layer above it. Figure 6-2 shows the logical representation of the SONET layers. Figure 6-2 SONET Network Structure Path Line Section Photonic The layers that comprise a SONET frame include: ■ ■ ■ Path Layer — Maps the payload into the synchronous payload envelope (SPE) of the SONET frame and creates the STS-1 synchronous payload envelope (SPE). In POS transmission, the payload contained in the SPE is the PPP encapsulated IP datagram. It then passes the resulting STS-1 SPE to the Line layer. Line Layer — Combines 3 STS-1 SPEs and adds the appropriate line overhead. This multiplexing of 3 STS-1 SPEs is also referred to as concatenation. It then passes the concatenated SPE to the section layer. Section Layer — Adds section overhead, performs scrambling, and creates the actual STS frame, which it then passes to the photonic layer. Cuda 12000 IP Access Switch CLI-based Administration Guide 118 CHAPTER 7: PACKET OVER SONET ADMINISTRATION ■ Photonic Layer — Converts the electrical STS-n signal to an optical signal, referred to as Optical Carrier. This OC-n signal is then transmitted over the circuit. Each layer consists of its own overhead bytes. This overhead provides the powerful management and fault-tolerance capabilities inherent in a SONET network. SONET overhead also provides for various alarms and error messages — known as defects — to be reported. Alarms allow for the reporting of network failures; error messages report incomplete failures that may compromise data transmission. SONET interface administration on the Cuda 12000 includes: ■ Displaying POS Interface Information ■ Disabling and Enabling Interfaces ■ Viewing POS Interface Packet Statistics ■ Viewing SONET Line-Layer Information ■ Viewing SONET Path Layer Information ■ Viewing and Configuration Section Layer Administration ■ Configuring and Viewing SONET Alarms ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 119 Displaying POS Interface Information You can display information for each POS interface. To do so, perform the following task within root mode: Task Command Display POS interface statistics show interface pos and settings. The following example uses the show topology command to obtain a list of modules installed on the system, then uses the show interface command to display information for the select POS interface. cli:192.168.208.3:root# show topology row count: 11 Chassis/Slot/ Interface ---------------1 / 1 / 1 1 / 3 / 1 1 / 8 / 1 Class Interface Type Status ---------Egress Egress Egress -------------------docsCableMaclayer Ethernet (Gigabit) POS (OC3c) -------------Active Not In Service Not In Service cli:192.168.208.3:root# show interface pos 1/8/1 --------------------------------------------------------Interface Type sonet POS 1/8/1 (line protocol) closed --------------------------------------------------------Hardware is Packet Over Sonet Internet Address 155.144.1.1 Rx Giants 0 Bad FCS's 0 Bad Addresses 0 Bad Controls 0 Local MRU 1500 (bytes) Remote MRU 1500 (bytes) FCS Size 32 (bits) Transmission Errors (Tx) 0 Rx Abort 0 Rx Runts 0 Interface Type ppp Interface Speed 155520 (Kbits) Interface In Octets 0 Interface In Unicast Pkts 0 Interface In Multicast Pkt 0 Cuda 12000 IP Access Switch CLI-based Administration Guide 120 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Interface In Broadcast Pkt 0 Interface In Discards 0 Interface In Errors 0 Interface Out Octets 0 Interface Out Unicast Pkts 0 Interface Out Multicast Pk 0 Interface Out Broadcast Pk 0 Interface Out Discards 0 Interface Out Errors 0 LCP closed Open None Negotiation Attempts 10 Retry Timeout 3 IPCP IP Address Report Enabled Framing Sonet Line Type Single Mode (15km) Clock Source Line Path Signal Id - C2 0xCF Section Trace Byte - J0 0xCC Packet Scrambling Disabled Loopback None Last clearing of counters 431:47:9 (HH:MM:SS) PPP Authentication Security Mode: NONE ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 121 The display includes a number of statistics, as described in the following table. Table 7-1 POS Interface Statistics Display Element Description Interface Type Number representing Packet over SONET. POS 1/3/1 (line protocol) Indicates whether a SONET line-layer connection is open or closed. Hardware is Packet over SONET Indicates hardware module type. Internet Address IP address of the POS interface. Rx Giants The number of packets received on this link which are larger than the maximum packet size. Bad FCS’s This LCP statistic indicates the number of received packets that have been discarded due to having an incorrect FCS. Bad Addresses Number of packets discarded because they were received with incorrect address or control fields. Address field was not 0xFF or control field was not 0x03. Bad Controls Number of packets received on this link with an incorrect Control Field. Local MRU Local Maximum Receive Unit (MRU), which is the current value of the MRU for the local PPP Entity. The remote entity uses this MRU when sending packets to the local PPP entity. Value is only meaningful only when the link has reached the open state FCS Size Frame Check Sequence (FCS) in bits that the local entity generate s when sending and receiving packets to and from the remote entity. Value is only meaningful when the link has reached the open state. Transmission Errors (Tx) This Line-layer statistic calculates the sum of all transmit errors that caused the packet to not be transmitted. These errors consist of tx fifo error, link layer errors, minimum packet size violations, maximum packet size violations and tx parity errors. Cuda 12000 IP Access Switch CLI-based Administration Guide 122 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Display Element Description Rx Abort The number of packets received on this link in which the abort sequence is detected. Rx Runts The number of packets received on this link which are smaller than the minimum packet size. Interface Type Displays “ppp” (Point-to-Point Protocol). Interface Speed Transmission speed in Kbits. Interface in Unicast Pkts Number of Unicast packets received on this interface. Interface in Discards Total number of incoming packets that were discarded by this interface. Interface in Errors Number of incoming packet errors seen on this interface. Interface Out Unicast Pkts Number of Unicast packets transmitted from this interface. Interface Out Discards Total number of outgoing packets that were discarded by this interface. Interface Out Errors Number of outgoing packet errors seen on this interface. LCP Indicates whether the LCP layer is open or closed on this interface. Open Indicates which network layer protocols are open. For example IPCP would be displayed when IP is up. Negotiation Attempts The maximum number of link negotiation attempts allowed by this interface. Retry Timeout Interval to wait between link connection retries. IPCP IP Address Report Indicates whether NCP is enabled for the transmission of IP datagrams. IP Control Protocol (IPCP) is the network control protocol used. Line Type Indicates SONET line type. Clock Source Indicates the clock source configured for this interface. Path Signal Id - C2 byte C2 byte received in last packet. Packet Scrambling Indicates whether packet scrambling in enabled or disabled. ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 123 Display Element Description Loopback Indicates loopback configuration. Last clearing of counters Time (SysUpTime) since the counters were last cleared and reset to zero. PPP Authentication Security Mode Indicates authentication used on this interface — PAP or CHAP Clearing Interface Counters You can clear interface counters for a selected POS interface. To do so, perform the following task within interface pos mode: Task Command Clear all counters for the current POS interface. clear counters Disabling and Enabling Interfaces You can manually take an interface offline or bring it online. When an interface is enabled (online), it can forward traffic; when disabled (offline) it cannot. NOTE: Enabling a POS interface assumes the POS interface is already configured. To disable and enable a POS interface, perform the following tasks in interface pos mode: Task Command 1. Disable the POS interface so that the administrative status is down. shutdown 2. Enable the POS interface so that the no shutdown administrative status is up. In this example, the user disables the POS interface in slot 3 and then brings it back online: cli:172.16.19.10:root# interface 1/3/1 mode: interface:pos:csi(1/3/1) cli:172.16.19.10:interface:pos:csi(1/3/1)# shutdown cli:172.16.19.10:interface:pos:csi(1/3/1)# no shutdown Cuda 12000 IP Access Switch CLI-based Administration Guide 124 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Viewing POS Interface Packet Statistics You can view incoming and outgoing packet statistics for selected POS interfaces. These traffic statistics provide a snapshot overview as to the amount and type of traffic flowing across the interface. For each POS interface, incoming and outgoing statistics are shown for the physical SONET layer, the Path layer, and at the PPP layer. To display these statistics, perform the following tasks: Task Command 1. From within root mode, issue this command to display incoming statistics: show interface pos in-counters 2. From within interface mode, issue this command to display incoming statistics: show in-counters 3. From within root mode, issue this command to display outgoing statistics: show interface pos out-counters 4. From within root mode, issue this command to display outgoing statistics: show out-counters The following incoming statistics are displayed for the SONET, Path, and PPP layer on each POS interface: ■ In Octets — Total number of PPP negotiations octets that have been received on this interface. This does not include octets for data packets. ■ In Unicast Packets — Number of Unicast packets that have been received on this interface. ■ In Multicast Packets — Number of Multicast packets that have been received on this interface. ■ In Broadcast Packets — Number of Broadcast packets that have been received on this interface. ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 125 The following outgoing statistics are displayed for each interface: ■ Out Octets — Total number of PPP negotiations octets that have been transmitted from this interface. This does not include octets for data packets. ■ Out Unicast Packets — Total number of Unicast packets that have been transmitted from this interface. ■ Out Multicast Packets — Total number of Multicast packets that have been transmitted from this interface. ■ Out Broadcast Packets — Total number of Broadcast packets that have been transmitted from this interface. Cuda 12000 IP Access Switch CLI-based Administration Guide 126 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Viewing SONET Line-Layer Information The SONET Line layer serves as the path between multiplexers and is responsible for synchronizing data transmission and multiplexing the STS-n signals generated by the section layer. Performance management statistics are collected at the SONET line layer. To view these Line-layer statistics, perform the following task within root mode: Task Command View SONET Line information. show controllers pos | include Line The show controllers pos command includes a variety of information. The following example displays Line-layer statistics by piping the output to include only Line statistics: cli:172.16.19.10:root# show controllers pos 1/3/1 | include Line Line: AIS 0 Line: RDI 0 Line: FEBE(M1) 0 Line: BIP(B2) 0 cli:172.16.19.10:root# To restart the statistics counters to zero, issue the clear counters command within POS interface configuration mode. Table 7-2 SONET Line Layer Statistics Display Element Description AIS — Path Alarm Indication Signal The number of times a Path Alarm Detections (PAIS) Indication Signal has been detected. A PAIS occurs if all the H1/H2 pointer bytes in the received SONET frame are 01. RDI — Path Remote Defect Indication Detections (PRDI) The number of times a Path Remote Defect Indication has been detected. A PRDI occurs if bits 5,6 and 7 of the G1 byte received with the same value for 5 consecutive frames. FEBE (M1) Far end block errors - Indicates the number of B2 errors that were detected by the remote side in its receive signal. ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 127 Display Element Description BIP (B2) Even Parity is calculated over groups of 3 bytes of each frame, except the first 3 rows of TOH. The value is compared to the B2 values in the received frame. Mismatches are counted. Viewing SONET Path Layer Information The Path layer is responsible for mapping the data to be transported into the synchronous payload envelope (SPE) of the SONET frame. It creates the STS-1 SPE and passes it to the line layer. You can view Path-layer performance information for a selected POS interface. This information includes defects and error statistics to provide an assessment of Path layer operation. To view these Path-layer statistics, perform the following task within root mode: Task Command View SONET Path layer information. show controllers pos | include Path The show controllers pos command includes a variety of information. The following example displays Path-layer statistics by piping the output to include only Path statistics: cli:172.16.19.10:root# show controllers pos 1/3/1 | include Path Path: AIS 0 Path: RDI 0 Path: FEBE(G1) 0 Path: BIP(B3) 0 Path: LOP 0 cli:172.16.19.10:root# To restart the statistics counters to zero, issue the clear counters command within POS interface configuration mode. Cuda 12000 IP Access Switch CLI-based Administration Guide 128 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Table 7-3 describes the SONET Path statistics shown in the display. Table 7-3 SONET Path Layer Statistics Display Element Description AIS — Path Alarm Indication Signal The number of times a Path Alarm Detections (PAIS) Indication Signal has been detected. A PAIS occurs if all the H1/H2 pointer bytes in the received SONET frame are 01. RDI — Path Remote Defect Indication Detections (PRDI) The number of times a Path Remote Defect Indication has been detected. A PRDI occurs if bits 5,6 and 7 of the G1 byte received with the same value for 5 consecutive frames. FEBE (G1) Far end block errors - Indicates the number of B3 errors that were detected by the remote side in its receive signal. BIP (B3) Even Parity is calculated over all bits in the SPE, including POH of each frame. These values are then compared to the B3 values received in the packet. Mismatches are reported. ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 129 Section Layer Administration The primary roles of the section layer include synchronization and timing of the SONET transmission, and passing the electrical STS-n frame format to the photonic layer where it is then converted to an optical signal and transported to the adjacent device. Section layer administration involves viewing the current status of the configuration and modifying the configuration of the section layer parameters for a selected POS interface. You can configure the following POS section layer parameters: Loopback Configuration Loopback configuration on a POS interface allows you to test interface connectivity and connection to a remote device. By default, loopback is not configured. The system supports the following loopback configuration: ■ Line — Configures the POS interface to loop-back data to the originating device. While configured in this mode, the interface loops back and retransmits incoming data without actually receiving it. ■ Internal — Configures the POS interface to loop-back data to itself. While configured in this mode, the interface loops-back outgoing data to the receiver without actually transmitting it. To configure loopback testing on a selected POS interface, perform the following tasks in interface pos mode: Task Command 1. Enable loopback testing. loop {line | internal} 2. Disable loopback testing. no loop Cuda 12000 IP Access Switch CLI-based Administration Guide 130 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Clock Source SONET is a synchronous transport technology. Timing for this synchronous transmission of data is derived from one of the following clock sources: ■ Line — Also referred to as loop timing, this timing option configures the interface to use the recovered receive clock to provide transmit clocking. This is the default clock source. ■ Internal — Configures the interface to generate the transmit clock internally. Keep in mind that the clock source you configure for the POS interface can also be used as the clock source for the primary or secondary backplane clock. If you want to use the clock source for the POS interface as the clock source for the primary or secondary backplane clock, you must configure the Line clock source for the POS interface. Refer to “Configuring Clock Sources” on page 86 for more information on backplane clocks. To configure the clock source for a selected POS interface, perform the following task in interface pos mode: Task Command Configure the clock source for the clock-source {line | internal} current interface. When configuring point to point links, one side of the link should be configured to utilize a line clock source, the other should utilize an internal clock source. Signal Type Configures the type of signal (framing) this POS interface transmits. Currently, the system supports only SONET STS-n framing. To configure the framing type used on a POS interface, perform the following task in interface pos mode: Task Command Configure POS framing. pos framing {sonet | sdh} ADC Telecommunications, Inc. Packet Over SONET (POS) Interface Administration 131 Packet Scrambling Enables scrambling of SONET Synchronous Payload Envelopes (SPEs) on this interface. Note that both end-points of the transmission must use the same scrambling. Scrambling is disabled by default. To configure scrambling on a POS interface, perform the following task in interface pos mode: Task Command Enable scrambling on the POS interface. pos scramble Note the following: ■ Only normal Path Remote Defect Indication is currently supported on POS interfaces. ■ Only SONET signal (framing) is supported on POS interfaces. Configuring and Viewing SONET Alarms Cuda 12000 IP Access Switch CLI-based Administration Guide 132 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Configuring and Viewing SONET Alarms A major advantage of SONET is that it can generate alarm and error messages when problems occur, such as when a signal fails or degrades. A receiving interface is notified of network defects in the form of Alarm Indication Signals (AIS); transmitting interfaces are notified of network defects by the return of Remote Defect Indications (RDI). You can configure the alarms and defects that you want the selected POS interface to report. SONET alarm administration on a POS interface involves the following: ■ Configuring POS Alarm Reporting — You configure the Alarms that you want the POS interface to report on using the pos report command within cable interface configuration mode. ■ Viewing Alarm Information — You can verify the alarms that are enabled and disabled on a selected POS interface, as well as the alarms that have been reported, using the show controller pos command within root mode. ADC Telecommunications, Inc. Configuring and Viewing SONET Alarms 133 Configuring POS Alarm Reporting You can configure reporting of 12 different POS alarms. To do so, perform the following tasks within interface pos mode: Alarm Report Description Line Alarm Indication Signal (LAIS) Disabled by default, configures the interface to report line alarm indication signal errors. Command ■ To enable reporting: pos report lais ■ To disable reporting: no pos report lais Line Remote Defect Indication (LRDI) Disabled by default, configures the interface to report line remote defect indication errors. ■ To enable reporting: pos report lrdi ■ To disable reporting: no pos report lrdi Path Alarm Indication Signal (PAIS) Path Loss of Pointer (PLOP) Path Remote Defect Indication (PRDI) Disabled by default, configures the system to report path alarm indication signal errors. Line terminating equipment (LTE) send packet alarm indication signals to alert downstream path terminating equipment (PTE) of defects on their incoming line signal. Enabled by default, configures the interface to report path loss of pointer errors. A PLOP error may result from an invalid pointer or too many new data flag enabled indications. Disabled by default, configures the interface to report path remote defect indication errors. ■ To enable reporting: pos report pais ■ To disable reporting: no pos report pais ■ To enable reporting: pos report plop ■ To disable reporting: no pos report plop ■ To enable reporting: pos report prdi ■ To disable reporting: no pos report prdi B2 Signal Degrade (SD) Disabled by default, configures the interface to report when the B2 signal degrades enough to meet or cross a specified Bit Error Rate (BER) threshold. The default BER threshold for B2 signal failure is 10-6. ■ To enable reporting: pos report sd-ber ■ To disable reporting: no pos report sd-ber ■ To set the B2 Signal Degrade threshold: pos threshold sd-ber Cuda 12000 IP Access Switch CLI-based Administration Guide 134 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Alarm Report Description B2 Signal Fail (SF) Enabled by default, configures the interface to report a failure when the B2 signal degrades enough to meet or cross a specified Bit Error Rate (BER) threshold. The default BER threshold for B2 signal failure is 10-3. Command ■ To enable reporting: pos report sf-ber ■ To disable reporting: no pos report sf-ber ■ To set the B2 Signal Fail threshold: pos threshold sf-ber Loss of Frame (SLOF) Loss of Signal (SLOS) Enabled by default, configures the interface to report section loss of frame errors. The interface detects SLOF when a severely error framing defect on the incoming SONET signal persists for at least 3 milliseconds. Enabled by default, configures the interface to report loss of signal (SLOS) errors. The POS interface reports a SLOS error under either of the following conditions: ■ When an all-zeros pattern on the incoming SONET signal lasts at least 19(+-3) microseconds. ■ If the signal level drops below the a specified threshold. ■ To enable reporting: pos report slof ■ To disable reporting: no pos report slof ■ To enable reporting: pos report slos ■ To disable reporting: no pos report slos ADC Telecommunications, Inc. Configuring and Viewing SONET Alarms 135 Viewing Alarm Information Using the show controllers pos command within root mode, you can display both the alarms that you have enabled on the POS interface, and whether or not specific alarms have been reported. To view the alarm reporting configuration on a POS interface, perform the following task in root mode: Task Command View whether the reporting of each POS alarm is enabled or disabled. show controllers pos | include alarm The following example views the alarm reporting configuration for POS interface 1/3/1: cli:172.16.19.10:root# show controllers pos 1/3/1 | include alarm Report alarms for B1 enabled Report alarms for B2 enabled Report alarms for B3 enabled Report alarms for LAIS disabled Report alarms for LRDI disabled Report alarms for PAIS disabled Report alarms for PLOP enabled Report alarms for PRDI disabled Report alarms for SD-BER disabled Report alarms for SF-BER enabled Report alarms for SLOF enabled Report alarms for SLOS enabled Local alarm active now None Remote alarm active now None cli:172.16.19.10:root# To view the alarm reporting configuration on a POS interface, perform the following task in root mode: Task Command View whether the reporting of each POS alarm is enabled or disabled. show controllers pos | include alarm Cuda 12000 IP Access Switch CLI-based Administration Guide 136 CHAPTER 7: PACKET OVER SONET ADMINISTRATION The following example indicates whether or not a specific alarm has been reported: cli:172.16.19.10:root# show controllers pos 1/3/1 | include now Local alarm active now None Remote alarm active now None B1 errors occurring now false B2 errors occurring now false B3 errors occurring now false LAIS errors occurring now false LRDI errors occurring now false PAIS errors occurring now false PLOP errors occurring now false PRDI errors occurring now false SD-BER errs occurring now false SF-BER errs occurring now false SLOF errors occurring now false SLOS errors occurring now false cli:172.16.19.10:root# ADC Telecommunications, Inc. Configuring Point-to-Point Protocol (PPP) 137 Configuring Point-to-Point Protocol (PPP) PPP is well-suited for delivery of data over SONET networks, as SONET links are provisioned as point-to-point circuits. The system encapsulates IP datagrams using PPP, then places the PPP frames into the SONET payload before transmission over the SONET circuit. PPP also provides security protocols that support the authentication of peers. PPP administration on a POS interface includes: ■ Configuring PPP Security — POS interfaces support both Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) so that only trusted devices can participate in the creation of a point-to-point circuit. ■ Configuring LCP — As part of establishing the PPP connection, a POS interface uses Link Control Protocol (LCP) packets to configure and test the data link. ■ Enabling NCP — A Network Control Protocol (NCP) is used to configure and enable network layer protocol communication. In this case, the network layer protocol used over the SONET circuit is IP; the NCP used to enable transmission of IP datagrams is the IP Control Protocol (IPCP). PPP encapsulation over SONET is described in RFC 2615. Cuda 12000 IP Access Switch CLI-based Administration Guide 138 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Configuring PPP Security Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) provide authentication mechanisms that serve to identify the peers that want to establish point-to-point connections. Using both CHAP and PAP, the device must provide a known username and password to the POS interface with which it wants to establish a PPP connection. CHAP is more secure than PAP. CHAP clients respond to challenges with an encrypted version of the password; PAP sends unencrypted straight text over the network. In addition, CHAP calls for both endpoints to perform a computation to arrive at a secret string; PAP does not. You can configure the POS interface to attempt authentication using one protocol, and if refused, attempt authorization with the other. SONET connections are provisioned as point-to-point circuits. The connection is initiated by one peer — the caller — into an adjacent peer — the callee. The caller is referred to as the client; and the callee is referred to as the server. Each CHAP and PAP must be enabled at both endpoints of a point-to-point connection and configured to operate in both client and server mode, as described in the following sections. Both CHAP and PAP are specified in RFC 1334. Configuring Client-Side Security Parameters When initiating a point-to-point connection, the POS interface acts as a client and calls into a remote end-point, which functions as a PPP server. If PAP, CHAP, or both forms of authentication are enabled on the server, then the same authentication protocols must be enabled on the POS interface. The POS interface, acting as a client, must provide the remote server with the correct username and password. If the interface fails to provide the correct information, the remote device will not allow it to call in and establish a connection. You can enable CHAP and PAP client-side authentication and configure the security information — username and password — that the POS interface sends to a PPP server when initiating a point-to-point connection. ADC Telecommunications, Inc. Configuring Point-to-Point Protocol (PPP) 139 To configure CHAP authentication, perform the following tasks within interface pos mode: Task Command 1. Enable CHAP authentication. ■ To enable the use of CHAP only: ppp authentication chap The interface will use CHAP authentication only; no negotiation. ■ To enable CHAP then PAP: ppp authentication chap pap The interface will negotiate the authentication protocol to use. It will try to agree on CHAP authentication first, then PAP second. ■ To enable PAP then CHAP: ppp authentication pap chap The interface will negotiate the authentication protocol to use. It will try to agree on PAP authentication first, then CHAP second. 2. Configure the hostname the POS interface will use to respond to CHAP Challenges. ppp chap-hostname 3. Configure the password the POS interface will use to respond to CHAP Challenges. ppp chap-password Cuda 12000 IP Access Switch CLI-based Administration Guide 140 CHAPTER 7: PACKET OVER SONET ADMINISTRATION To configure PAP authentication, perform the following tasks within interface pos mode: Task Command 1. Enable PAP authentication. ■ To enable the use of PAP only: ppp authentication pap The interface will use PAP authentication only; no negotiation. ■ To enable PAP then CHAP: ppp authentication pap chap The interface will negotiate the authentication protocol to use. It will try to agree on PAP authentication first, then CHAP second. ■ To enable CHAP then PAP: ppp authentication chap pap The interface will negotiate the authentication protocol to use. It will try to agree on CHAP authentication first, then PAP second. 2. Configure the username and ppp pap-sent-username password password that the POS interface will use to respond to PAP Challenges. Note that you can disable authentication on a selected POS interface by using the following command within interface pos mode: no ppp authentication ADC Telecommunications, Inc. Configuring Point-to-Point Protocol (PPP) 141 Configuring Server-Side Security Parameters When a remote peer (client) calls into the POS interface and attempts to establish a point-to-point connection, the interface functions as a PPP access server. Enabling server-side authentication configures the POS interface to authenticate all peers that call into it. Configuring server-side authentication involves the following: ■ Specifying which protocol you want the interface to use to authenticate clients. You can configure the interface to request CHAP authentication, PAP authentication, or both in a specified order. ■ Specifying the hostname the POS interface sends to a client when performing CHAP authentication. ■ Adding users to the PPP Server Users Table. User account information includes a username and password. When a remote client responds to a PAP challenge with a username and password, the system examines this table to verify that the client has responded with the correct information. If so, the connection is allowed; otherwise, the connection is closed. Perform the following tasks within interface pos mode to configure PPP CHAP server-side security parameters: Cuda 12000 IP Access Switch CLI-based Administration Guide 142 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Task Command 1. Enable CHAP authentication. ■ To enable the use of CHAP only: ppp authentication chap The interface will use CHAP authentication only; no negotiation. ■ To enable CHAP then PAP: ppp authentication chap pap The interface will negotiate the authentication protocol to use. It will try to agree on CHAP authentication first, then PAP second. ■ To enable PAP then CHAP: ppp authentication pap chap The interface will negotiate the authentication protocol to use. It will try to agree on PAP authentication first, then CHAP second. 2. If you’ve enable CHAP authentication, configure the hostname that the interface sends to a client. ppp chap-hostname 3. If you’ve enabled CHAP, configure the username and password that a requesting client must provide for authentication to allow the connection. ppp username password To configure the interface to authenticate peers using PAP, then you must add user account information for all peers that the interface may authenticate. When PAP is enabled for server mode, the interface requests a username and password from the remote peer. When the peer responds with a username/password combination, the POS interface examines its PPP LCP Server Users Table to verify the information is correct. If the account information is verified correct, the connection is allowed; otherwise it’s closed. ADC Telecommunications, Inc. Configuring Point-to-Point Protocol (PPP) 143 Perform the following tasks within interface pos mode to configure PPP PAP server-side security parameters: Task Command 1. Enable PAP authentication ■ To enable the use of PAP only: ppp authentication pap The interface will use PAP authentication only; no negotiation. ■ To enable PAP then CHAP: ppp authentication pap chap The interface will negotiate the authentication protocol to use. It will try to agree on PAP authentication first, then CHAP second. ■ To enable CHAP then PAP: ppp authentication chap pap The interface will negotiate the authentication protocol to use. It will try to agree on CHAP authentication first, then PAP second. 2. Configure the username and password that a requesting client must provide for authentication to allow the connection. Cuda 12000 IP Access Switch CLI-based Administration Guide ppp username password 144 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Configuring LCP The PPP protocol suite includes a Link Control Protocol (LCP) for establishing, configuring and verifying point-to-point connections. PPP uses LCP to determine encapsulation options, set limits in transmit and receive packet size, detect link configuration errors, and terminate links. LCP is defined in RFCs 1570 and 1661. Configuring LCP Parameters To configure LCP parameters for a selected PPP interface, perform the following tasks within interface pos mode: Initial Maximum Transmit / Receive Unit (MTU) Because IP packets are encapsulated in PPP, the maximum length of an IP packet that can be transmitted over the PPP link is the same length as the PPP information field. If a packet is larger than the PPP information field, it must be fragmented a placed in multiple PPP packets. Perform the following task within interface pos mode to enter the maximum transmit and receive packet size allowed on this interface. NOTE: The only MTU size the Cuda 12000 currently supports is 1500. This value should not be changed. Task Command Configure the maximum transmission unit. mtu 1500 Frame Check Sequence (FCS) Size Perform the following task within interface pos to enter the frame check sequence size: Task Command Configure frame check sequence size. crc {16 | 32} ADC Telecommunications, Inc. Configuring Point-to-Point Protocol (PPP) 145 Max Negotiation Attempts Perform the following task within interface pos mode to configure the maximum number of link negotiation attempts allowed by the current interface: Task Command Configure maximum negotiation attempts. ppp negotiation-count <0...100> Time Between Negotiation Attempts Perform the following task within interface pos mode to configure the number of seconds that the interface waits between LCP negotiations. Task Command Configure the time (seconds) between negotiation attempts. timeout <0 ... 65535> Cuda 12000 IP Access Switch CLI-based Administration Guide 146 CHAPTER 7: PACKET OVER SONET ADMINISTRATION Enabling NCP IP Control Protocol (IPCP) is the Network Control Protocol (NCP) used to configure, enable, and disable IP protocol access on both ends of a SONET point-to-point circuit. In order for IP packets to be transmitted over the point-to-point link, IPCP must reach the open state. This enables IP communication between the two circuit endpoints. By default, the Cuda 12000 is configured to provide its IP address during IPCP negotiations. But when negotiating with a Juniper Networks system, providing the IP address during IPCP negotiation prevents a successful connection. When the interface must connect with a Juniper Networks system, you can disable reporting of an IP address during IPCP negotiation. To enable or disable reporting of the IP address during negotiation, perform the following task within interface pos mode: Task Command 1. Enable the reporting of the IP address during IPCP negotiation. ppp ipcp-report-address 2. Disable the reporting of the IP address during IPCP negotiation. no ppp ipcp-report-address ADC Telecommunications, Inc. 8 TIMING AND ALARM CONTROLLER MANAGEMENT The Cuda 12000 utilizes an external fan tray for cooling and obtains power from an external power source. Fault management features on the Cuda 12000 for the fan tray and power source are: ■ The Timing and Alarms Controller (TAC) that resides on the Management module. TAC provides alarm processing for detection of faults associated with fan tray and power supply auxiliary devices. ■ Software reporting functions that allow you to configure the reporting of fault conditions. Fault reporting alerts you to fault conditions as they arise, so you may take action prior to a loss of operation, or know when the power source and cooling capability is compromised. ■ DB-15 connectors on the rear panel of the Cuda 12000 that allow you to send specific types of alarm signals to notify an auxiliary device that a fault occurred. This chapter provides information and procedures for configuring the monitoring and reporting of power and fan tray fault conditions and includes the following sections: ■ About Timing and Alarm Controller Fault Reporting (page 148) ■ Assertion Levels (page 150) ■ Configuring Fault Reporting (page 153) ■ Configuring Alarms Out (page 157) 148 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT About Timing and Alarm Controller Fault Reporting For a single chassis, you can connect the following units: ■ Fan Tray — The fan tray serves as the system cooling unit. This is a required component and ships with every Cuda 12000. ■ Power Supply A — A single -48 volt DC power source is required for system operation. ■ Power Supply B — Connection to a second power source is optional to provide redundancy. For more information about the Cuda 12000 cooling and power features, see the “Cuda 12000 IP Access Switch Installation Guide.” Two DB-15 connectors — alarms in and alarms out — on the rear of the Cuda 12000 enable communication of alarms from fan trap and power supply units. The following table describes the DB-15 connectors: Table 8-1 DB-15 Connectors Connector Description Alarms In Receives fault signals from the connected units. Alarms Out Transmits fault signals to an external device. For information about connecting the DB-15 connectors to the auxiliary devices, refer to the Cuda 12000 IP Access Switch Installation Guide. You can configure reporting for a number of fault conditions, such as fan rotation and temperature, power alarms and backplane temperature. Reception of a fault signal from the device results in an SNMP trap or syslog message, which is sent to the specified destinations. To view the SNMP trap and syslog message destinations on the system use the show snmp notify command. (Refer to the next chapter, “Simple Network Management Protocol (SNMP)” on page 161 for information about configuring destinations for fault events.) ADC Telecommunications, Inc. About Timing and Alarm Controller Fault Reporting 149 Configuring power and fan tray fault reporting involves performing the following tasks: ■ You must specify whether the auxiliary device utilizes an active-high or active-low assertion level to report fault conditions, as described in “Assertion Levels” on page 150. ■ Configure the faults that you want the system to report, as described in “Configuring Fault Reporting” on page 153. ■ Specify the alarms that you want to send over the alarms out DB-15 connector to an external indication device, as described in “Configuring Alarms Out” on page 157. Cuda 12000 IP Access Switch CLI-based Administration Guide 150 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT Assertion Levels When a fault condition occurs on the fan unit or power supply, a signal is sent to TAC indicating a fault condition. The signal that the fan unit or power supply sends may use one of the following assertion levels: ■ Active-High — Signal indicates the assertion state as a logic ONE state. ■ Active-Low — Signal indicates the assertion state as a logic ZERO state. The power supply and fan unit assertion levels are configured for the following parameters (see Table 8-2). Assertion levels are normally set to active-low, unless otherwise specified by the auxiliary device vendor. The default is set to active-low. Table 8-2 Assertion Level Parameters Parameter Description PS-temp Set to report the temperature of the power supply. DC-monitor Set to report DC current faults of the power supply. AC-monitor Set to report AC current faults of the power supply. Fan-temp Set to report temperature faults of the fan unit. Fan-rotation Set to report rotation faults of the fan unit. ADC Telecommunications, Inc. Assertion Levels 151 Configuring the Power Assertion Level You must verify the assertion level specified by the power supply vendor to indicate fault conditions, and set the assertion levels as specified by the vendor. To configure the assertion level that the power supply utilizes when indicating a fault condition, perform the following tasks: Task Command 1. Enter root mode. root 2. Set the assertion level to report aux-device ac-monitor fault-level {active-high | active-low} AC current faults. 3. Set the assertion level to report aux-device dc-monitor fault-level {active-high | active-low} DC current faults. 4. Set the assertion level to report aux-device ps-temp fault-level {active-high | active-low} power supply temperature faults. To display the assertion levels currently configured for both AC and DC and power supply temperature fault indications, perform the following tasks: Task Command 1. Enter root mode. root 2. Display the assertion level show aux-device ac-monitor currently configured for the reporting of AC current faults. 3. Display the assertion level show aux-device dc-monitor currently configured for the reporting of DC current faults. 4. Display the assertion level currently configured for the reporting of power supply temperature faults. Cuda 12000 IP Access Switch CLI-based Administration Guide show aux-device ps-temp 152 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT Configuring Fan Unit Assertion Levels The fan unit, by default, sends an active-low signal to TAC to report fan temperature and rotation faults. You configure the fan unit to send an active-high signal if so specified by the fan unit vendor. To configure the fan unit assertion level, perform the following tasks: Task Command 1. Enter configuration mode. root 2. Set the assertion level of the signal used to report fan temperature faults to the management module. aux-device fan-temp fault-level {active-high | active-low} 3. Set the assertion level of the signal used to report fan rotation faults to the management module. aux-device fan-rotation fault-level {active-high | active-low} To display the fan unit assertion levels currently configured for both fan temperature and rotation fault indications, perform the following tasks: Task Command 1. Enter configuration mode. root 2. Display the assertion level show aux-device fan-temp currently configured for the reporting of fan temperature faults. 3. Display the assertion level currently configured for the reporting of fan rotation faults. show aux-device fan-rotation Example The following example displays the assertion level currently configured for the fan temperature: cli:192.168.208.3:root# show aux-device fan-temp Assert Fan Temp Fault active-high ADC Telecommunications, Inc. Configuring Fault Reporting 153 Configuring Fault Reporting The system reports faults in the form of SNMP traps and syslog messages. You must configure the faults for which you want to be notified. For each fault that you choose to report, the system sends an SNMP trap or syslog message to all specified destinations if a fault is detected. SNMP traps and syslog messages are also sent when there is a state transition from okay to faulted or a transition from faulted to okay. The Cuda 12000 allows you to report on the following fault conditions. Table 8-3 Fault Conditions Fault Description backplane A payload blade asserted a backplane system fault condition. backplane-power One or more payload blades detected an internal Power Fault. backplane-power-a One or more payload blades detected a Power_A (48V) Fault. backplane-power-b One or more payload blades detected a Power_B (48V) Fault. backplane-temp One or more payload blades detected a Temperature Fault. bits-a The chassis manager associated with the chassis detected a loss of the BITS-A clock. bits-b The chassis manager associated with the chassis detected a loss of the BITS-B clock. blue One or more payload blades has asserted a Blue Alarm. fan-rotation The fan tray associated with the chassis detected one or more non-rotating fans. fan-temp The fan tray associated with the chassis detected an inlet temperature > 50 deg. C. local-pwr-a The chassis manager associated with the chassis detected a loss of Power_A (48V). local-pwr-b The chassis manager associated with the chassis detected a loss of Power_B (48V). processor-temp The chassis manager associated with the chassis detected a processor over-temperature condition. Cuda 12000 IP Access Switch CLI-based Administration Guide 154 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT Fault Description ps-ac The power supply associated with the chassis detected the loss of one or more AC inputs. ps-dc The power supply associated with the chassis detected a DC out-of-range fault. ps-temp The power supply associated with the chassis detected an over-temperature condition. red-alarm One or more payload blades has asserted a Red Alarm. yellow alarm One or more payload blades has asserted a Yellow Alarm. To configure the faults for which you want to be notified, perform the following tasks. By default, the fault reporting status is “disabled” for each fault: Task Command 1. Enter root mode. root 2. Specify the faults that you want reported. chassis-fault {backplane | backplane-power | backplane-power-a | backplane-power-b | backplane-temp | bits-a | bits-b | blue | fan-rotation | fan-temp | local-pwr-a | local-pwr-b | processor-temp | ps-ac | ps-dc | ps-temp | red-alarm | yellow} ADC Telecommunications, Inc. Configuring Fault Reporting 155 Removing a Fault Notification In the event that you no longer wish to be notified of a fault condition, you may remove a specified fault notification by performing the following tasks: Task Command 1. Enter root mode. root 2. Remove the fault condition from the notification report. no chassis-fault {backplane | backplane-power | backplane-power-a | backplane-power-b | backplane-temp | bits-a | bits-b | blue | fan-rotation | fan-temp | local-pwr-a | local-pwr-b | processor-temp | ps-ac | ps-dc | ps-temp | red-alarm | yellow} Cuda 12000 IP Access Switch CLI-based Administration Guide 156 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT Viewing Fault Reporting Status Each fault condition displays one of the following states. ■ disabled — Reporting is not specified for the fault condition. An SNMP Trap or syslog message is not generated when the fault condition occurs. ■ faulted — Fault reporting is specified. An SNMP trap or syslog message is generated when the fault condition occurs. ■ okay — Fault reporting is specified. Use the show chassis-fault status command to display the state of each fault condition. Example The following example displays that faults are to be reported for the backplane power and local power-source-a conditions. In addition, the display indicates that faults have not occurred for the specified conditions. cli:192.168.244.212:root# chassis-fault backplane-power local-pwr-a cli:192.168.244.212:root# show chassis-fault status Chassis Fault Status Bits A Fault Bits B Fault Backplane System Fault Backplane Temp Fault Backplane Power Fault Backplane Power A Fault Backplane Power B Fault Red Alarm Fault Blue Alarm Fault Yellow Alarm Fault Processor Temp Fault Ps Temp Fault Ps AC Fault Ps DC Fault Fan Temp Fault Fan Rotation Fault Local Pwr A Fault Local Pwr B Fault disabled disabled disabled disabled okay disabled disabled disabled disabled disabled disabled disabled disabled disabled disabled disabled okay disabled ADC Telecommunications, Inc. Configuring Alarms Out 157 Configuring Alarms Out A DB-15 connector on the Cuda 12000 chassis rear panel serves as the alarms out port. You can configure the Cuda 12000 to send specific types of alarm signals out this DB-15 connector to an external indication device to notify the external device that a particular type of fault has occurred. (Refer to the Cuda 12000 IP Access Switch Installation Guide for information about cabling the DB-15 connector.) Each fault can generate one or more types of alarm signals. Table 8-4 shows the alarm signals that you can send over the alarms out port and the associated faults that you can use to trigger these signals: Table 8-4 Alarm Signals and Associated Faults You Can Configure This Signal: To Provide Notification of These Faults: Temp Alarm ■ ■ ■ ■ Sys Alarm ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ Red Alarm backplane-temp-fault processor-temp-fault ps-temp-fault fan-temp-fault backplane-system-fault backplane-temp-fault backplane-pwr-fault local-pwr-a-fault local-pwr-b-fault red-alarm-fault ps-temp-fault ps-ac-fault ps-dc-fault fan-temp-fault fan-rotation-fault ■ bits-a-fault bits-b-fault red-alarm-fault Blue Alarm ■ blue-alarm-fault Yellow Alarm ■ yellow-alarm-fault ■ ■ Cuda 12000 IP Access Switch CLI-based Administration Guide 158 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT You Can Configure This Signal: To Provide Notification of These Faults: Power Alarm ■ ■ ■ ■ ■ ■ ■ Temp Fault ■ ■ ■ Power Fault local-pwr-a-fault local-pwr-b-fault backplane-pwr-fault backplane-pwr-a-fault backplane-pwr-b-fault ps-ac-fault ps-dc-fault processor-temp-fault ps-temp-fault fan-temp-fault ■ local-pwr-a-fault local-pwr-b-fault backplane-pwr-a-fault backplane-pwr-b-fault ps-ac-fault ps-dc-fault PowerA Fail ■ local-pwr-a-fault PowerB Fail ■ local-pwr-b-fault Clock ■ ■ ■ ■ ■ ■ ■ ■ bits-a-fault bits-b-fault red-alarm-fault To configure the alarm signals for transmit over the DB-15 connector and the associated signals that can trigger them, perform the following tasks. By default, all faults are configured to not send out their associated alarm signals over the DB-15 connector: ADC Telecommunications, Inc. Configuring Alarms Out Task Command 1. Enter root mode. root 159 2. Specify the types of alarm no aux-device db15 alarm signals that you want to {blue | enable, to set the fault to send clock [bits-a] [bits-b] [red-alarm] | alarm signals out the DB-15 power-alarm [backplane-power] connector. [backplane-pwr-a] [backplane-pwr-b] [local-pwr-a] [local-pwr-b] [ps-ac] [ps-dc] | power-fail-A | power-fail-B | red [bits-a] [bits-b] [red-alarm] | system [backplane] [backplane-power] [backplane-temp] [fan-rotation] [fan-temp] [local-pwr-a] [local-pwr-b] [ps-ac] [ps-dc] [ps-temp] [red-alarm] | temp [backplane-temp] [fan-temp] [processor-temp] [ps-temp] | yellow} 3. Specify the types of alarm aux-device db15 alarm signals that you want to {blue | disable, to prohibit the faults clock [bits-a] [bits-b] [red-alarm] | from being sent out the DB-15 power-alarm [backplane-power] connector. [backplane-pwr-a] [backplane-pwr-b] [local-pwr-a] [local-pwr-b] [ps-ac] [ps-dc] | power-fail-A | power-fail-B | red [bits-a] [bits-b] [red-alarm] | system [backplane] [backplane-power] [backplane-temp] [fan-rotation] [fan-temp] [local-pwr-a] [local-pwr-b] [ps-ac] [ps-dc] [ps-temp] [red-alarm] | temp [backplane-temp] [fan-temp] [processor-temp] [ps-temp] | yellow} Cuda 12000 IP Access Switch CLI-based Administration Guide 160 CHAPTER 8: TIMING AND ALARM CONTROLLER MANAGEMENT Viewing Alarm Signals Out the DB-15 Connector You may display the current configuration of the alarm signals over the DB-15 connector. To do this, perform the following tasks: Task Command 1. Enter root mode. root 2. Display current configuration of the show aux-device db15 alarm signals out the DB-15 connector. Example In the following example: ■ A Temp Alarm, Sys Alarm, Red Alarm, Yellow Alarm and Power Alarm signal have been configured in the past to be sent out the DB-15 connector for all associated faults. ■ The administrator configures a Blue Alarm signal to not be sent out the DB-15 connector for all associated faults. cli:192.168.208.3:root# aux-device db15 alarm blue cli:192.168.208.3:root# show aux-device db15 Temp Alarm backplane-temp-fault processor-temp-fault ps-temp-fault fan-temp-fault Sys Alarm backplane-system-fault backplane-temp-fault backplane-power-fault local-pwr-a-fault local-pwr-b-fault red-alarm-fault ps-temp-fault ps-ac-fault ps-dc-fault fan-temp-fault fan-rotation-fault Red Alarm bits-a-fault bits-b-fault red-alarm-fault Blue Alarm blue-alarm-fault Yellow Alarm yellow-alarm-fault Power Alarm local-pwr-a-fault enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled enabled disabled enabled enabled ADC Telecommunications, Inc. 9 SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Simple Network Management Protocol (SNMP) is a standard for managing networks. This chapter provides an overview of SNMP (refer to “About SNMP” on page 162). This chapter also provides information on performing the following tasks to configure SNMP on the Cuda 12000: ■ Configuring SNMP Access Control (page 164) ■ Configuring System Name, Contact, and Location (page 180) ■ Configuring SNMP Event Notification Types (page 182) ■ Monitoring SNMP (page 196) Sample SNMP configurations are provided at the end of this chapter. These samples illustrate how to set up complete SNMPv1, SNMPv2, and SNMPv3 security schemes. Refer to “Sample SNMP Configurations” on page 198 for more information. 162 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) About SNMP This section provides an overview of SNMP. For further information about the SNMP protocol, refer to the RFCs listed below or other general publications specific to SNMP. SNMP is a network management protocol that provides a standard for network management systems. In the SNMP scheme, a network management system contains two primary components: a manager and agents. The manager is the workstation or console where the network administrator performs network management functions. Agents are entities that interface with the device being managed. The Cuda 12000 runs an SNMP agent. Devices, such as the Cuda 12000, that are managed using SNMP contain managed objects, such as configuration parameters and performance statistics. These objects are defined in a management information base (MIB). SNMP allows managers and agents to communicate for the purpose of accessing MIB objects. SNMP provides access control to MIB objects, which defines who can access MIB objects and their associated access privileges. In SNMPv1 and v2c, access control is managed through associations of agents and managers called communities and security groups. In SNMPv3, access control is managed by the user and context, and an associated security group. Refer to “Configuring SNMP Access Control” on page 164 for more information on access control. SNMP security is defined by Security Models and Security Levels. A combination of a security model and a security level determines which security mechanism is used when handling an SNMP packet. A security model may authenticate messages by providing data integrity, data origin authentication, data confidentiality, message timeliness and limited replay protection. A security model 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. The level of security is determined primarily by the specific SNMP application implementation and by the specific security model implementation. The Cuda 12000 supports DOCSIS 1.1 OSS Interface Specification (SP-OSSIv1.1-I02-000714) and SNMP configuration, as defined by RFCs 1157, 2571, 2572, 2573, 2574, 2575 and 2576. ADC Telecommunications, Inc. About SNMP 163 Configuring and monitoring SNMP on the Cuda 12000 involves the following processes. These processes are explained in the sections that follow: 1. Configuring SNMP access control. 2. Configuring system name, contact, and location information. Refer to “Configuring System Name, Contact, and Location” on page 180. 3. Configuring event notification. Refer to “Configuring SNMP Event Notification Types” on page 182. 4. Monitoring SNMP. Refer to “Monitoring SNMP” on page 196. Cuda 12000 IP Access Switch CLI-based Administration Guide 164 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring SNMP Access Control SNMP Access Control defines how SNMP will controls access to MIB objects. In SNMP versions 1 and 2c, access control is configured by a community-based model. A community associates an SNMP agent and an SNMP management application. You assign a name to the community, and the agent and management application use this name to authenticate SNMP messages exchanged between them. In SNMP version 3, access control is configured by a user-context model. These models are described in the sections that follow. Configuring access control for MIB views and groups is common to all versions. SNMP access control follows a hierarchy and it is recommended that you perform configuration functions in the following order: 1. Configure SNMP Access Views. 2. Configure SNMP Groups. 3. Configure Models, as follows: a Configure SNMPv1, v2c Communities, and/or b Configure SNMPv3 Users and Contexts ADC Telecommunications, Inc. Configuring SNMP Access Control 165 Configuring SNMP Access Views SNMP Access Views control access to a MIB subtree. Configuring SNMP Access Views involves the following: 1. Creating a MIB view. You create a MIB view by specifying a name for the view, by defining the MIB subtree to be viewed, and by specifying whether instances of the MIB subtree are included in the MIB view or excluded from the MIB view. 2. Specifying the storage type for the view. 3. Specifying the status of the view. The following table describes the parameters that you set to configure SNMP Views: Table 9-1 Parameters Associated with SNMP View Configuration Parameter Description View Name The name of the MIB view. Subtree The MIB subtree that defines the family of view subtrees. Type Indicates whether the instances of the MIB subtree are included or excluded from the MIB view. Storage Indicates how the MIB view is stored.The options are: ■ ■ ■ ■ Status volatile: The entry is stored in volatile memory. The information is lost during a system reboot. nonvolatile (default): The entry is stored in non-volatile memory. The information is not lost during a system reboot. permanent: The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. readonly: The entry is stored in non-volatile memory. You cannot delete or modify the information. Indicates whether the MIB view is Active or Not in Service. If status is set to Enable, the MIB view is Active. If status is set to Disable, the MIB view is not in service. Cuda 12000 IP Access Switch CLI-based Administration Guide 166 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Perform the following tasks to configure SNMP Access Views: Tasks Commands 1. Enter configuration mode. root 2. Create a MIB view by performing snmp-server view the following tasks: {included | excluded} ■ ■ ■ Specify the name of the view. Specify the MIB subtree that defines the family of views. You can enter the MIB value as an Object Identifier (OID), and OID with wildcards, or an OID name description. Set the corresponding instances of the MIB subtree to be included or excluded in the MIB view. 3. Specify the storage type for the MIB view. By default, storage type is set to NonVolatile. snmp-server view {included | excluded} [storage {volatile | nonvolatile | permanent | readonly}] 4. Set the status of the MIB view. snmp-server view You enable or disable the status. {included | excluded} Enable sets the status to Active. [status {enable | disable}] Disable sets the status to Not in Service. By default, the status is set to Active. 5. Display an SNMP MIB view. show snmp view [ ] 6. Remove an SNMP MIB view. no snmp-server view ADC Telecommunications, Inc. Configuring SNMP Access Control 167 Example The following example configures and displays an SNMP MIB view using the default storage type and status. cli:192.168.208.3:root# snmp-server view auditorview1 1.3.6.1 included cli:192.168.208.3:root# show snmp view row count: 5 View Name ---------------public private guitraps v1default auditorview1 Subtree --------------------------1.3.6.1 1.3.6.1 1.3.6.1 1.3.6.1 1.3.6.1 Cuda 12000 IP Access Switch CLI-based Administration Guide Type -------Included Included Included Included Included Storage ----------NonVolatile NonVolatile NonVolatile NonVolatile NonVolatile Status ----------Active Active Active Active Active 168 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring SNMP Groups SNMP groups restrict read, write and notify access to certain parts of the MIB. Configuring SNMP groups involves: 1. Creating a group. 2. Assigning the group a security mode and security level to process SNMP messages. 3. Specifying how the group is stored and assigning the group access privileges to an SNMP MIB view. You set the following parameters to configure SNMP Groups: Table 9-2 SNMP Group Configuration Parameters Parameter Description Group The name of the SNMP group for the SNMP entity. Context The name of the context associated with the specific group. Model The SNMP security model used to process SNMP messages and gain access to the group. You can choose V1, V2c or V3. Level The level of security to process SNMP messages. You can choose one of the following three levels: ■ ■ ■ No Authentication (noauth): Provides no authentication and no encryption. This is the lowest level of security. V1 and V2c security models provide only this level of security. Authentication (auth): Provides authentication but no encryption. Only V3 security model provides this level of security. Privacy (priv): Provides authentication and encryption. This is the highest level of security. Only V3 security model provides this level of security. Read View Authorizes the group to have read access to the specific MIB view. Write View Authorizes the group to have write access to the specific MIB view. Notify View Authorizes the group to have notify access to the specific MIB view. ADC Telecommunications, Inc. Configuring SNMP Access Control Parameter Description Storage Specifies how the group entry is stored: ■ ■ ■ ■ 169 volatile: The entry is stored in volatile memory. The information is lost during a system reboot. nonvolatile (default): The entry is stored in non-volatile memory. The information is not lost during a system reboot. permanent: The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. readonly: The entry is stored in non-volatile memory. You cannot delete or modify the information. Perform the following tasks to configure an SNMP group. Refer to the configuration examples below: Read, write or notify privileges are associated to an SNMP MIB view. If an SNMP view already exists, you assign the privileges to that existing view name. If an SNMP view does not already exist, you can create a view name for a new view when you assign the access privileges. Task Command 1. Enter configuration mode. root 2. Create an SNMP group. When an SNMP group is created, by default, the Read View name is assigned as v1default snmp-server group {v1 | v2c | v3 {auth | noauth | priv}} 3. Assign the group’s access to an SNMP view. snmp-server group {v1 | v2c | v3 {auth | noauth | priv}} [read ] [write ] [notify ] If an SNMP view does not already exist, you assign a name for a new view. 4. Associate an existing context to the group. snmp-server group {v1 | v2c | v3 {auth | noauth | priv}} [context ] 5. Specify the storage type for this group. snmp-server group {v1 | v2c | v3 {auth | noauth | priv}} [storage {volatile | nonvolatile | permanent | readonly}] Cuda 12000 IP Access Switch CLI-based Administration Guide 170 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Task Command 6. Display SNMP group information. show snmp group [ ] 7. Remove an SNMP group. no snmp-server group Example 1 The following example creates a new group: root# snmp-server group alemap v3 auth root# show snmp group alemap row count: 18 Group Context Model Level Read View Write View Notify View Storage ---------- ------- ----- ------ ----------- ----------- ----------- ----------alemap V3 Auth v1default NonVolatile The following example assigns the group read privileges to an SNMP MIB view: root# snmp-server group alemaps v1 read adc root# show snmp group Group Context Model Level Read View Write View Notify View Storage ---------- ------- ----- ------ ----------- ----------- ----------- ----------alemaps V1 NoAuth adc NonVolatile cli:192.168.208.3:root# ADC Telecommunications, Inc. Configuring SNMP Access Control 171 The following example associates an existing context to the group: root# snmp-server group alemaps v1 read public context adc root# show snmp group Group Context Model Level Read View Write View Notify View Storage ---------- ------- ----- ------ ----------- ----------- ----------- ----------alemaps adc V1 NoAuth public NonVolatile Example 2 The following example specifies the storage type for a group: root# snmp-server group hms v3 auth storage volatile root# show snmp group Group Context Model Level Read View Write View Notify View Storage ---------- ------- ----- ------ ----------- ----------- ----------- ----------hms V3 Auth v1default Volatile Cuda 12000 IP Access Switch CLI-based Administration Guide 172 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring SNMP Communities SNMP versions 1 and 2c use a community to control access to a MIB object. A community is a pairing relationship between an SNMP agent and an SNMP application. The network administrator assigns the community a name. The community assigns specific rights and privileges to authenticate SNMP messages. The community passes on the messages to an associated group. You set the following parameters to configure SNMP Communities: Table 9-3 Parameters contained in SNMP Community Configuration Parameter Description Name The name assigned to the SNMP community. An SNMP community name may contain up to 32 alphanumeric characters. Security Name The name assigned to security group for the associated SNMP community. A security group name may contain up to 32 alphanumeric characters IP Address The IP address of a host that is a member of the SNMP community. If you do not specify an IP address, all hosts are allowed access using the community string. Mask The mask for the specified IP address. The mask allows you to specify a range of hosts. For example, you can specify an IP address of 220.220.0.0 with a mask of 255.255.0.0. This IP-mask address combination allows any host from 220.220.0.0 through 220.220.255.255 to access MIB objects in the specified SNMP community. Context The name of the SNMP context that is used with the specified community when accessing the security group. The context is one of the parameters that allows access to a group entry, along with group name, security model and security level. NOTE: Refer to the section “Configuring SNMPv3 Contexts” on page 178, for detailed information about SNMP contexts. ADC Telecommunications, Inc. Configuring SNMP Access Control 173 Parameter Description Storage Indicates how the SNMP community’s attributes are stored. The options are: ■ ■ ■ ■ volatile: The entry is stored in volatile memory. The information is lost during a system reboot. nonvolatile (default): The entry is stored in non-volatile memory. The information is not lost during a system reboot. permanent: The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. readonly: The entry is stored in non-volatile memory. You cannot delete or modify the information. Perform the following tasks to configure an SNMPv1 or v2c community. Refer to the configuration example below: Task Command 1. Enter configuration mode. root 2. Create an SNMP community and a corresponding security group. snmp-server community 3. Specify the host that has access snmp-server community address 4. Specify the Mask address for a range of hosts. snmp-server community address mask 5. Name the SNMP context to be used with the SNMP community. snmp-server community [address [mask ]] [context ] 6. Display a specific SNMP community or all SNMP communities. show snmp community [ ] 7. Remove an SNMP community and its security group. no snmp-server community Cuda 12000 IP Access Switch CLI-based Administration Guide 174 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Example The following example creates and displays a specific SNMP community: cli:root# snmp-server community beta build address 192.168.20.12 mask 255.255.255.0 context cuda cli:192.168.208.3:root# show snmp community row count: 5 Name Security Name Context Storage --------------------------------------------------------------bat all NonVolatile beta build cuda NonVolatile guitraps guitraps NonVolatile private adc adc NonVolatile public adc adc NonVolatile ADC Telecommunications, Inc. Configuring SNMP Access Control 175 Configuring SNMPv3 Users The SNMPv3 user is anyone who requires management operations to be authorized by a particular SNMP entity. SNMP entities must have knowledge of a user and the user’s attributes. Configuring an SNMPv3 user involves the following: 1. Specifying a user’s name. 2. Specifying the user’s security attributes for an SNMP entity. 3. Specifying the storage type for the user. 4. Specifying the status of the user. The following table describes the parameters that you set to configure SNMP users: Table 9-4 Parameters Contained in SNMPv3 User Configuration Parameter Description Name The name assigned to the user for the SNMP entity. A user name may contain up to 32 alphanumeric characters. Authentication The security attribute for this user that indicates whether messages sent on behalf of this user can be authenticated. Authentication is defined by two protocols: HMC-MD5-96 and HMAC-SHA-96. Privacy Indicates whether messages sent on behalf of this user will be protected from disclosure. Privacy is defined by the CBC-DES Symmetric Encryption Protocol. Cuda 12000 IP Access Switch CLI-based Administration Guide 176 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Parameter Description Storage Indicates how the user’s attributes are stored. The options are: ■ ■ ■ ■ Status volatile: The entry is stored in volatile memory. The information is lost during a system reboot. nonvolatile (default): The entry is stored in non-volatile memory. The information is not lost during a system reboot. permanent: The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. readonly: The entry is stored in non-volatile memory. You cannot delete or modify the information. Indicates whether the user is active or not in server active. Set to Enable to indicate Active, or set to Disable to indicate Not in Service. Perform the following tasks to configure an SNMP user. An example of an SNMPv3 user configuration is displayed below: Tasks Commands 1. Enter configuration mode. root 2. Create a user for the SNMP entity. snmp-server user 3. Specify the authentication type for this user. snmp-server user [auth {md5 | sha} ] You must specify authentication type in order for messages to be authenticated. By default, authentication type is None. Optionally, specify the priv des56 argument to protect messages from disclosure. By default, messages are not protected from disclosure. snmp-server user [auth {md5 | sha} ] [priv des56 ]] ADC Telecommunications, Inc. Configuring SNMP Access Control 177 Tasks Commands 4. Specify how user attributes are stored. snmp-server user [storage {volatile | nonvolatile | permanent | readonly}] By default, storage type is set to NonVolatile. 5. Specify the user’s status. By default, the Cuda sets status type to Active. snmp-server user [status {enable | disable}] 6. Display SNMP user attributes. show snmp user [ ] 7. Remove an SNMP user. no snmp-server user Example The following example configures an SNMP user with authentication type and privacy attributes: root# snmp-server user mapale auth sha 000111 priv des56 000111 root# show snmp user mapale Name Authentication Privacy Storage Status ------------------------------- -------------- ------- ----------- -----------mapale HMAC-SHA-96 CBC-DES NonVolatile Active cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 178 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring SNMPv3 Contexts SNMPv3 uses contexts to control access to a MIB object. A context is a collection of management information that is accessed by an SNMP entity. A single SNMP entity may be in more than one context. A single SNMP entity may have access to many contexts. Configuring SNMPv3 contexts involves: 1. Creating a context. 2. Setting a storage type for the context. 3. Setting the status for the context. The following table describes the parameters that you set to configure SNMPv3 Contexts: Table 9-5 Parameters Contained in SNMPv3 Context Configuration Parameter Description Context Name The name that identifies a context. A null value indicates a default context. A context name may include up to 32 alphanumeric characters. Storage Indicates how the context entry is stored. Following is a list of the storage types. By default, storage is set to NonVolatile: Non-volatile The entry is stored in non-volatile memory. The information is not lost during a system reboot. Permanent The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. Read-only The entry is stored in non-volatile memory. You cannot delete or modify the information. Volatile The entry is stored in volatile memory. The information is lost during a system reboot. Status Sets the state of the context, as follows: Enable Activates a context. Disable Temporarily sets the context to “Not In Service.” By default, the context is enabled. ADC Telecommunications, Inc. Configuring SNMP Access Control 179 Perform the following tasks to configure SNMPv3 contexts. Refer to the configuration example below: Task Command 1. Enter configuration mode. root 2. Provide the name of the context. snmp-server context Enter a single text or numeric string, up to 32 characters. 3. Set the storage type for the context. snmp-server context [storage {nonvolatile | permanent | readonly | volatile}] By default, storage is set to NonVolatile. 4. Set the status for the context. By default, status is set to enable. snmp-server context [status {enable | disable}] 5. Display all context information for an SNMP entity. show snmp context [ ] 6. Remove the context information. no snmp-server context Example The following example displays the configuration for the context “tech” and displays all contexts for an SNMP entity. root# snmp-server context tech storage permanent status enable root# show snmp context row count: 3 Name -------------------------------adc june tech Storage -----------NonVolatile NonVolatile Permanent cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide Status -----------Active Active Active 180 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring System Name, Contact, and Location For the Cuda 12000, you can configure system name, contact, and location information. This information is stored in the sysName, sysContact, and sysLocation MIB variables. This information is described as follows: Table 9-6 System Name, Contact, and Location Parameters Parameter Description Name The name of the system (sysName MIB object). Contact The type of contact for this network (sysContact MIB object). The contact is typically a network administrator’s name, extension, and/or e-mail address. Location The physical location of the Cuda 12000 (sysLocation MIB object). Perform the following tasks to configure name, contact, and location information for the Cuda 12000: A name, contact, or location text string may contain up to 255 alphanumeric characters. If a text string contains spaces, you may enclose the string in quotes. Task Command 1. Enter configuration mode. root 2. Specify the SNMP contact. snmp-server contact 3. Specify the system’s name. snmp-server name 4. Specify the system’s physical location. snmp-server location 5. Display the contact, name and location information. show snmp 6. Remove the contact, name or location information. no snmp-server {contact | name | location} ADC Telecommunications, Inc. Configuring System Name, Contact, and Location 181 Example The following example creates and displays name, contact, and location information: root# snmp-server name "cuda 111" root# snmp-server contact “John Smith, x334” root# snmp-server location "bldg. 1400" root# show snmp Contact John Smith, x334 Name cuda 111 Location bldg. 1400 SNMP packets received 182168 Bad SNMP version errors 0 Unknown community names 0 Illegal community names 0 Encoding errors 0 Silent drops 0 Unknown security models 0 Invalid messages 0 Unknown PDU handlers 0 Authentication traps disable cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 182 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Configuring SNMP Event Notification Types Notifications indicate that a system event occurred, such as a physical fault that affects the chassis, and system faults that may impact the operation of the management module or any of the application modules. Notifications are sent to an SNMP host. The SNMP host may be the default local host on the management module, or an external host that you configure to receive the notifications. The local host is the default host that is pre-configured and shipped with your chassis.Notifications, for the local host, are sent to IP address 127.0.0.1. If CudaView is installed on the chassis, CudaView uses the local host to display notifications. The local host IP address should not be changed. Defining event notification involves configuring which notifications you want to send to the SNMP host and how to send the notifications to the SNMP host. Notifications may be sent as traps or informs. Traps are notifications that are not acknowledged by the SNMP manager, so they are considered unreliable. In addition, traps are not held in memory. Informs are notifications that are acknowledged by the SNMP manager, so they are considered reliable. If an inform is sent and not acknowledged, it may be sent again. Informs are held in memory, which means they consume more router and network resources. ADC Telecommunications, Inc. Configuring SNMP Event Notification Types 183 The following table lists the system events and their associated Event Classes. For more information about Event Classes, refer to Chapter 10, Managing System Events, on page 203. Table 9-7 List of System Events E System Event Description Cluster events: Cluster events refer to faults that affect the management module. Event Class ■ authentication-failure SNMP receives a bad Community Name. Notice ■ bcm-failover-down Services are going down. This notification type applies to redundant configurations only. Notice ■ bcm-failover-up Services are coming up. This notification type applies to redundant configurations only. Notice ■ bcm-state-change A change in the craft port IP address. Notice ■ bcm-sw-mismatch The secondary will not come up because its software revision does not match the software revision of the primary. Notice ■ trace-log For ADC internal use only. Notice ■ cold-start Generated when module boots from power up. Notice ■ warm-start Generated when module boots from reset. Notice ■ icl-state-change A change in the ICL link. Module events: Notice Module events refer to hardware faults that affect any application module. ■ cable-modem-auth-failure Cable modem failed authorization and did Notice not register. ■ cable-modem-down Cable modem is not operational. Critical ■ cable-modem-up Cable modem is operational. Notice ■ card-down Application module failure. Critical ■ card-up Application module is operational. Notice ■ dhcp-relay-not-configured DHCP configuration error. Warning ■ local-sonet-alarm A transmission problem is detected from the transmitter. Error ■ remote-sonet-alarm A transmission problem is detected from the receiver. Error Cuda 12000 IP Access Switch CLI-based Administration Guide 184 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) System Event Description Event Class ■ Interface-related events: Interface-related events refer to faults that Notice affect the link state of the interface. ■ link up Link to IP network is operational. Notice ■ link down Link to IP network is not operational. Error ■ chassis-fault Auxiliary device-related event that refers to Critical faults associated to the fan tray, power source and clock sources. NOTE: Reference “Timing and Alarm Module Fault Reporting” on page 155, for a list of the chassis-related notification types. ■ chassis-fault-cleared Provisioning events: Indicates the chassis event that caused a fault is fixed. Notice Provisioning events refer to faults that pertain to the FastFlow BPM running on the Cuda 12000. ■ duplicate-addr A duplicate IP address has been detected. Notice ■ isp-addr-high The free IP address count exceeded the upper threshold for the specified ISP. Notice ■ isp-addr-low The free address count fell below the lower threshold for the specified ISP. Notice ■ ldap-failed A directory server access failure occurred. Notice ■ ldap-restored Directory server access is operational after a failure. Notice ■ prov-service A FastFlow BPM service started, stopped, or failed. Notice ■ subnet-addr-high The free IP address count exceeded the high available address threshold for a subnet. Notice ■ subnet-addr-low The free IP address count fell below the low available address threshold for a subnet. Notice DOCSIS events: ■ docs-dyn-rsp-fail DOCSIS events refer to initialization faults on DOCSIS and EuroDOCSIS modules. A dynamic service response failure occurred during the dynamic services process. Warning ADC Telecommunications, Inc. Configuring SNMP Event Notification Types System Event Description Event Class Warning ■ docss-dyn-ack-fail A dynamic service acknowledgement failure occurred during the dynamic services process. ■ docs-dyn-req-fail A dynamic service request failure occurred Warning during the dynamic services process. ■ docs-bpi-init A BPI initialization attempt failure occurred Informational during the registration process. ■ docs-bpkm A baseline privacy key management operation failed. Error ■ docs-dcc-ack-fail A dynamic channel change acknowledgement failed during the dynamic channel change process in the CMTS. Warning ■ docs-dcc-req-fail A dynamic channel change request failed during the dynamic channel change process in the cable modem and was detected by the CMTS. Warning ■ docs-dcc-rsp-fail A dynamic channel change response failed Warning during the dynamic channel change process in the CMTS. ■ docs-dynamic-sa A dynamic security association failed. ■ docs-init-ack-fail A registration acknowledgement failure Warning from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. ■ docs-init-req-fail A registration request failure from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. Warning ■ docs-init-rsp-fail A registration response failure from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. Warning Routing events: Routing events refer to events that indicate a change in the state of OSPF neighbors and OSPF virtual neighbors. Cuda 12000 IP Access Switch CLI-based Administration Guide Warning 185 186 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) System Event Description Event Class ■ ospf-nbr-state Signifies a change in the state of an OSPF neighbor on a physical interface. To send this notification type, note that you also have to enable sending of OSPF neighbor state traps using the report command. Notice ■ ospf-virt-nbr-state Signifies a change in the state of an OSPF neighbor on a virtual interface. To send this notification type, note that you also have to enable sending of OSPF virtual neighbor state traps using the report command. Notice Modem deregistration event: ■ dereg-modems A modem deregistration event refers to the deregistration of cable modems. Signifies that a number or percentage of modems have deregistered over the deregistration time interval. Warning Configuring event notification types involves: 1. Defining an SNMP host to receive trap messages. 2. Specifying the UDP port number on which the SNMP host will receive traps. 3. Specifying the maximum message size (MMS) that the SNMP entity will transmit or receive, and process. 4. Specifying how the definition of the SNMP host that will receive events is stored. 5. Specifying the events for which you want to receive notification, and specifying how to send the notifications. ADC Telecommunications, Inc. Configuring SNMP Event Notification Types 187 The following table describes the parameters that you set to configure notifications: Table 9-8 Parameters Contained in Event Notification Configuration Parameter Description Host:Port The IP address and UDP port number on which the SNMP host is configured to receive traps. The UDP port range is 1 to 65535 and the default is 162. Timeout The amount of time, in seconds, that passes before it is assumed the host did not receive the inform notification message. The range is 0 to 9999 and the default is 15. Retry The number of retries made when a response to a generated inform message is not received. The range is 0 to 255 and the default is 3. Notify or Community Indicates whether the SNMP host receives a trap or an inform notification message, or indicates the name of the community used to access the host ■ ■ Cuda 12000 IP Access Switch CLI-based Administration Guide A trap is any message generated that contains unconfirmed PDUs. You may receive PDU traps for security models v1, v2c, and v3. An inform is any message generated that contains confirmed PDUs. You may receive informs for only v2c and v3 security models. 188 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Parameter Description Storage Specifies how the host entry is stored. The options are: ■ ■ ■ ■ volatile: The entry is stored in volatile memory. The information is lost during a system reboot. nonvolatile (default): The entry is stored in non-volatile memory. The information is not lost during a system reboot. permanent: The entry is stored in non-volatile memory. You cannot delete the information but you can make modifications. readonly: The entry is stored in non-volatile memory. You cannot delete or modify the information. Mask The mask of the IP address on which the SNMP host is configured to receive traps. MMS The maximum message size (in bytes) of an SNMP message that the SNMP engine transmits or receives and processes. Values range from 484 to 65535. The default is 484. Model The SNMP security model used to process SNMP messages and gain access to the group. Your options are V1, V2c or V3. ADC Telecommunications, Inc. Configuring SNMP Event Notification Types 189 Parameter Description Level The level of security to process SNMP messages. You can choose one of the following three levels: ■ ■ ■ No Authentication: Provides no authentication and no encryption. This is the lowest level of security. V1 and V2c security models provide only this level of security. Authentication: Provides authentication but no encryption. Only V3 security model provides this level of security. Privacy: Provides authentication and encryption. This is the highest level of security. Only V3 security model provides this level of security. Group Name The community name associated to the SNMP group for the specific SNMP host. Type Indicates whether the notification is sent as a trap or inform. Notifications Sent The type of event for which you want to be notified. Notifications may be specified for system events occurring for clusters, modules, interfaces and DOCSIS modules. Cluster events: Cluster events refer to faults that affect the management module. ■ authentication-failure SNMP receives a bad Community Name. ■ bcm-failover-down Services are going down. This notification type applies to redundant configurations only. ■ bcm-failover-up Services are coming up. This notification type applies to redundant configurations only. ■ bcm-state-change A change in the craft port IP address. Cuda 12000 IP Access Switch CLI-based Administration Guide 190 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Parameter Description ■ bcm-sw-mismatch The secondary will not come up because its software revision does not match the software revision of the primary. ■ trace-log For ADC internal use only. ■ cold-start Generated when module boots from power up. ■ warm-start Generated when module boots from reset. ■ icl-state-change A change in the ICL link. Module- events: Module events refer to hardware faults that affect any application module. ■ cable-modem-auth-failure Cable modem failed authorization and did not register. ■ cable-modem-down Cable modem is not operational. ■ cable-modem-up Cable modem is operational. ■ card-down Application module failure. ■ card-up Application module is operational. ■ dhcp-relay-not-configured DHCP configuration error. ■ local-sonet-alarm A transmission problem is detected from the transmitter. ■ remote-sonet-alarm A transmission problem is detected from the receiver. ■ Interface-related events: Interface-related events refer to faults that affect the link state of the interface. ■ link-up Link to IP network is operational. ■ link-down Link to IP network is not operational. ■ chassis-fault Auxiliary device-related event that refers to faults associated to the fan tray, power source and clock sources. NOTE: Reference “Timing and Alarm Module Fault Reporting” on page 155, for a list of the chassis-related notification types. ADC Telecommunications, Inc. Configuring SNMP Event Notification Types Parameter ■ chassis-fault-cleared DOCSIS events: 191 Description Indicates the chassis event that caused a fault is fixed. DOCSIS events refer to initialization faults on DOCSIS and EuroDOCSIS modules. ■ docs-dyn-rsp-fail A dynamic service response failure occurred during the dynamic services process. ■ docss-dyn-ack-fail A dynamic service acknowledgement failure occurred during the dynamic services process. ■ docs-dyn-req-fail A dynamic service request failure occurred during the dynamic services process. ■ docs-bpi-init A BPI initialization attempt failure occurred during the registration process. ■ docs-bpkm A baseline privacy key management operation failed. ■ docs-dcc-ack-fail A dynamic channel change acknowledgement failed during the dynamic channel change process in the CMTS. ■ docs-dcc-req-fail A dynamic channel change request failed during the dynamic channel change process in the cable modem and was detected by the CMTS. ■ docs-dcc-rsp-fail A dynamic channel change response failed during the dynamic channel change process in the CMTS. ■ docs-dynamic-sa A dynamic security association failed. ■ docs-init-ack-fail A registration acknowledgement failure from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. ■ docs-init-req-fail A registration request failure from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. Cuda 12000 IP Access Switch CLI-based Administration Guide 192 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Parameter Description docs-init-rsp-fail A registration response failure from the cable modem occurred during the cable modem initialization process and was detected on the CMTS side. Provisioning events: Provisioning events refer to faults that pertain to the FastFlow BPM running on the Cuda 12000. ■ ■ duplicate-addr A duplicate IP address has been detected. ■ isp-addr-high The free IP address count exceeded the upper threshold for the specified ISP. ■ isp-addr-low The free address count fell below the lower threshold for the specified ISP. ■ ldap-failed A directory server access failure occurred. ■ ldap-restored Directory server access is operational after a failure. ■ prov-service A FastFlow BPM service started, stopped, or failed. ■ subnet-addr-high The free IP address count exceeded the high available address threshold for a subnet. ■ subnet-addr-low The free IP address count fell below the low available address threshold for a subnet. Routing events: ■ ospf-nbr-state Routing events refer to events that indicate a change in the state of OSPF neighbors and OSPF virtual neighbors. Signifies a change in the state of an OSPF neighbor on a physical interface. To send this notification type, note that you also have to enable sending of OSPF neighbor state traps using the report command. ADC Telecommunications, Inc. Configuring SNMP Event Notification Types Parameter ■ ospf-virt-nbr-state Modem deregistration event: ■ dereg-modems 193 Description Signifies a change in the state of an OSPF neighbor on a virtual interface. To send this notification type, note that you also have to enable sending of OSPF virtual neighbor state traps using the report command. A modem deregistration event refers to the deregistration of cable modems. Signifies that a number or percentage of modems have deregistered over the deregistration time interval. Perform the following tasks to configure event notifications. Refer to the configuration examples, below: Tasks Commands 1. Enter configuration mode. root 2. Create an SNMP host to receive trap messages. snmp-server host {traps | informs [timeout ] [retries ]} [version {1 | 2c | 3 {auth | noauth | priv}] 3. Specify the UDP port number on which the SNMP host will receive traps. snmp-server host {traps | informs [timeout ] [retries ]} [version {1 | 2c | 3 {auth | noauth | priv}] udp-port 4. Specify the maximum message size (MMS), in bytes, of an SNMP message that the SNMP engine will transmit or receive and process. snmp-server host {traps | informs [timeout ] [retries ]} [version {1 | 2c | 3 {auth | noauth | priv}] [mms] Cuda 12000 IP Access Switch CLI-based Administration Guide 194 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Tasks Commands 5. Specify the storage type for this host. snmp-server host {traps | informs [timeout ] [retries ]} [version {1 | 2c | 3 {auth | noauth | priv}] [storage {volatile | nonvolatile | permanent | readonly}] By default, storage type is set to NonVolatile. 6. Specify the type of events for which you want to be notified. snmp-server host {traps | informs [timeout ] [retries ]} [version {1 | 2c | 3 {auth | noauth | priv}] [notification-type ...] 7. Display SNMP host information. show snmp host [parameters] 8. Display all SNMP hosts and associated notification type(s). show snmp notify [ ] 9. Remove an SNMP host entity from the trap recipient list, or remove a parameter in the host entry. no snmp-server host {traps | informs} [mask] [notification-type ...] Example 1 The following example creates and displays an SNMP host with default parameter values: root# snmp-server host 133.10.1.1 june informs retries 2 root# show snmp host version 2c noauth Host:Port Time Retry Notify or Storage Mask MMS -out Community ------------------- ---- ----- -------------- ----------- --------------- ----133.10.1.1:162 15 2 inform NonVolatile 484 cli:192.168.208.3:root# show snmp host parameters Notify:Host:Port Model Level Group Name Storage ---------------------------- ----- ------ ------------------------- ----------inform:133.10.1.1:162 V2c NoAuth june NonVolatile cli:192.168.208.3:root# ADC Telecommunications, Inc. Configuring SNMP Event Notification Types 195 Example 2 The following example displays all SNMP hosts notification destinations and associated notification types. root# show snmp notify row count: 2 Host:Port -------------------136.4.6.6:164 127.0.0.1:54321 Storage ----------NonVolatile NonVolatile Notifications Sent --------------------------------------trace-log cold-start link-up prov-service ldap-failed ldap-restored subnet-addr-low subnet-addr-high isp-addr-low isp-addr-high duplicate-addr bcm-failover-down bcm-failover-up bcm-sw-mismatch card-down card-up trace-log cable-modem-up cable-modem-down bcm-state-change icl-state-change cable-modem-auth-failure dhcp-relay-not-configured local-sonet-alarm remote-sonet-alarm chassis-fault chassis-fault-cleared cold-start warm-start link-down link-up authentication-failure Cuda 12000 IP Access Switch CLI-based Administration Guide Type -----inform V2 196 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Monitoring SNMP The show snmp command allows you to monitor SNMP activity on the Cuda 12000. To use this command, perform the following tasks: Tasks Commands 1. Enter root mode. root 2. Monitor SNMP activity. show snmp The command displays the following information: Table 9-9 SNMP Parameters and Statistics Parameter Description Contact The type of contact for this network. The contact is typically a network administrator’s name, extension, and/or e-mail address. Name The name of the system (sysName MIB object). Location The physical location of the device (sysLocation MIB object). SNMP Packets Received Total number of messages that the transport service delivers to the SNMP entity. Bad SNMP Version Errors Total number of SNMP messages that the SNMP entity receives using an unsupported version of SNMP. Unknown Community Total number of SNMP messages that the SNMP entity Names receives using an SNMP community name not known to the entity. Illegal Community Names Total number of SNMP messages that the SNMP entity receives that represent an SNMP operation that is now allowed by the SNMP community named in the message. Encoding Errors Total number of ASN.1 or BER errors that the SNMP entity encounters when decoding SNMP messages. Silent Drops Total number of GetRequest-PDUs, GetNextRequest-PDUs, GetBulkRequest-PDUs, SetRequest-PDUs, and InformRequest-PDU packets that the SNMP entity receives and drops. Unknown Security Models Total number of packets that the SNMP engine receives and drops because the security model was not known or supported by the SNMP engine. ADC Telecommunications, Inc. Monitoring SNMP 197 Parameter Description Invalid Messages Total number of packets that the SNMP engine receives and drops because there were invalid or inconsistent components in the SNMP message. Unknown PDU Handlers Total number of packets that the SNMP engine receives and drops because the PDU contained in the packets could not be passed to an application responsible for the PDU type. Authentication Traps Indicates whether the SNMP entity is able to generate failure traps. Example In the following example, the user issues the show snmp command to monitor SNMP activity. root# show snmp Contact Name Location SNMP packets received Bad SNMP version errors Unknown community names Illegal community names Encoding errors Silent drops Unknown security models Invalid messages Unknown PDU handlers Authentication traps cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide router cuda 111 bldg. 1400 182168 0 0 0 0 0 0 0 0 disable 198 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) Sample SNMP Configurations This section provides sample configurations for SNMPv1/v2c community access control, SNMPv3 access control, and notification. Sample SNMPv1/v2c Community Access Control To configure SNMPv1/v2c community access control, you must: 1. Configure SNMP Access Views. 2. Configure SNMP Groups. 3. Configure SNMPv1, v2c Communities. In this sample configuration, the administrator creates three communities (and associated views and groups): ■ A community called “monitor” that allows any host read-only access to the entire MIB, except for sensitive SNMP configuration information. No write access is allowed. ■ A community called “admincon” that allows read-write access to the entire MIB, but only from management hosts in a particular address range (such as a management network operations center). In this case, the address range is 100.100.0.0 through 100.100.255.255. ■ A community called “justme” that allows the same access as the “admincon” community, but from two individual hosts only. To configure the “monitor” community, the administrator first issues the following commands to configure two read-only views, each named “nosnmpconfig:” cli:192.168.208.3:root# snmp-server view nosnmpconfig 1.3.6.1 included cli:192.168.208.3:root# snmp-server view nosnmpconfig snmpModules excluded The administrator then creates two groups named “monitorgroup” that associate the read-only view (nosnmpconfig) and the community “monitor,” which is created afterward. cli:192.168.208.3:root# snmp-server group monitorgroup v1 read nosnmpconfig cli:192.168.208.3:root# snmp-server group monitorgroup v2 read nosnmpconfig The administrator then creates the community “monitor,” which includes an association to the group named “monitorgroup.” cli:192.168.208.3:root# snmp-server community monitor monitorgroup ADC Telecommunications, Inc. Sample SNMP Configurations 199 To configure the “admincon” community, the administrator issues the following commands: cli:192.168.208.3:root# snmp-server cli:192.168.208.3:root# snmp-server allaccess cli:192.168.208.3:root# snmp-server allaccess cli:192.168.208.3:root# snmp-server 100.100.0.0 mask 255.255.0.0 view allaccess 1.3.6.1 included group admingroup v1 read allaccess write group admingroup v2 read allaccess write community admincon admingroup address To configure the “justme” community, the administrator issues the following commands: cli:192.168.208.3:root# snmp-server community justme admingroup address 100.100.10.5 cli:192.168.208.3:root# snmp-server community justme admingroup address 100.100.10.8 Notice that the administrator does not have to specify a view or a group. The administrator uses the view and group created during configuration of the “admincon” community. Sample SNMPv3 Access Control To configure SNMPv3 community access control, you must: 1. Configure SNMP Access Views. 2. Configure SNMP Groups. 3. Configure SNMPv3 Users and Contexts. First, the administrator creates: ■ A view that includes access to most of the MIB and a view that excludes access from sensitive configuration information. ■ A group that configures the user for the default security model “noauth.” ■ An SNMPv3 user called “mgr.” ■ A context called “monitor” that allows the user read-only access to the entire MIB, except for sensitive SNMP configuration information. Cuda 12000 IP Access Switch CLI-based Administration Guide 200 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) To configure these access control elements, the administrator issues the following commands: cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# monitor cli:192.168.208.3:root# cli:192.168.208.3:root# snmp-server view nosnmpconfig 1.3.6.1 included snmp-server view nosnmpconfig snmpModules excluded snmp-server group mgr v3 noauth read nosnmpconfig context snmp-server context monitor snmp-server user mgr The administrator then decides that a user with read and write access to the entire MIB is needed. To create this user and assign the user the necessary access privileges, the administrator issues the following commands: cli:192.168.208.3:root# cli:192.168.208.3:root# allaccess context admin cli:192.168.208.3:root# cli:192.168.208.3:root# a0b0c0d0e0f0 snmp-server view allaccess 1.3.6.1 included snmp-server group superman v3 priv read allaccess write snmp-server context admin snmp-server user superman auth md5 ab03045f6e priv des56 The group entry allows the context “admin” to have read and write access to the entire MIB. Only management hosts that use the user “superman” and the context “admin” can access the view “allaccess.” ADC Telecommunications, Inc. Sample SNMP Configurations 201 Sample Notification Configuration The following sample commands configure the Cuda 12000 to send SNMPv1 traps to a host (201.1.1.20): cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# cli:192.168.208.3:root# snmp-server snmp-server snmp-server snmp-server snmp-server view allaccess 1.3.6.1 included group trapcommunity v1 notify allaccess group trapcommunity v2 notify allaccess community trapcommunity trapcommunity host 201.1.1.20 trapcommunity traps version 1 In this example, the SNMP agent on the Cuda 12000 sends SNMPv1 traps (on the default UDP port of 162) to a host with an IP address of 201.1.1.20. Because the administrator does not specify any notification types, all types are sent. The administrator creates two group entries for community-based SNMPv1/v2c access. Each group entry is assigned a notify view of “allaccess” that allows notifications access to the entire MIB (this community has no read or write access). The community inserted into outgoing traps will be “trapcommunity.” To send SNMPv2 traps instead of SNMPv1 traps, the administrator would issue the same commands except for a slightly different version of the snmp-server host command: cli:192.168.208.3:root# snmp-server host 201.1.1.20 trapcommunity traps version 2c To send inform messages instead of traps, another form of the snmp-server host command would be used: cli:192.168.208.3:root# snmp-server host 201.1.1.20 trapcommunity informs version 2c This command sends inform messages with the default timeout and retries values set. To change the defaults to 20 (for timeout) and 5 (for retries), the administrator would issue the following command: cli:192.168.208.3:root# snmp-server host 201.1.1.20 trapcommunity informs timeout 20 retries 5 version 2c Cuda 12000 IP Access Switch CLI-based Administration Guide 202 CHAPTER 9: SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP) ADC Telecommunications, Inc. 10 MANAGING SYSTEM EVENTS This chapter describes how to manage event transmission and includes the following sections: ■ About System Events (page 204) ■ Configuring the Syslog Server (page 205) ■ Configuring SNMP Trap Recipients (page 206) ■ Configuring Event Transmission (page 208) ■ Event Reporting (page 210) ■ Event Classes and SNMP System Events (page 214) ■ Clearing the Event Log (page 216) ■ Displaying Event Transmission, Reporting, and Syslog Parameters (page 216) ■ Displaying the Event Log (page 218) 204 CHAPTER 10: MANAGING SYSTEM EVENTS About System Events An event is a problem, a configuration change or some other noteworthy incident that occurs on the Cuda 12000 or in the network. Events create the generation of: ■ System log (syslog) messages ■ SNMP traps, which the Cuda 12000 sends to network management stations ■ Internal log messages ADC Telecommunications, Inc. Configuring the Syslog Server 205 Configuring the Syslog Server Before you manage event transmission or reporting using the syslog server, you set the IP address of the syslog server to which your Cuda 12000 writes system log messages, as required by DOCSIS 1.1 standards. You may specify the IP address of the local Syslog server on your Cuda 12000 or a remote syslog server on another Cuda 12000. To configure the IP address of the Syslog server, perform the following tasks: Task Command 1. Enter root mode. root 2. Specify the IP address of the syslog event-config syslog server. 3. Display the syslog server IP address. If a Syslog server IP address does not currently exist, the default is 0.0.0.0. show event-config syslog Example cli:192.168.208.3:root# show event-config syslog Syslog Server 0.0.0.0 cli:192.168.208.3:root# To remove the Syslog server entry, perform the following tasks: Task Command 1. Enter root mode. root 2. Remove the syslog server entry. event-config syslog 0.0.0.0 Cuda 12000 IP Access Switch CLI-based Administration Guide 206 CHAPTER 10: MANAGING SYSTEM EVENTS Configuring SNMP Trap Recipients You must define a list of IP addresses of SNMP management stations that receive traps or syslog messages from your Cuda 12000. Use this procedure to specify each trap recipient: Task Command 1. Enter root mode. root 2. Specify the trap recipient. snmp-server host [traps | informs [timeout ][retries ]] [version {1 | 2c | 3} {auth | noauth | priv}] [udp-port ] [mms ] [storage {volatile | nonvolatile | permanent | readonly}] [notification-type ...] For information on command arguments, refer to Chapter 9, Simple Network Management Protocol (SNMP), on page page 161, or see snmp-server host command in the Cuda 12000 IP Access Switch CLI Reference Guide. 3. Display the trap recipient. show snmp host Example root# snmp-server host 136.4.6.6 informs timeout 500 retries 200 version 2c noauth private udp-port 164 mms 5000 notification-type cold-start link-up cli:192.168.220.230:root# ADC Telecommunications, Inc. Configuring SNMP Trap Recipients 207 Removing SNMP Trap Recipients Perform this task to remove an SNMP trap recipient: Task Command Remove the trap recipient. no snmp-server host Example root# no snmp-server host 136.4.6.6 Cuda 12000 IP Access Switch CLI-based Administration Guide 208 CHAPTER 10: MANAGING SYSTEM EVENTS Configuring Event Transmission A Cuda 12000 can generate a significant volume of events in a short period of time. The Cuda 12000 manages event transmission in compliance with DOCSIS 1.1 standards. To avoid flooding the syslog server and network management stations with events, you can control the pace of event transmission by configuring these parameters: Table 10-1 Event Transmission Parameters Parameter Description Event Threshold Number of events that the Cuda 12000 may generate per event interval before throttling occurs. Throttling is the process of eliminating excessive events. Note that an event causing both a trap and a syslog message is still treated as a single event. Values range from 0 to 4294967295. The default is 0. Event Interval The interval, in seconds, over which the event threshold applies. For example, if you configure an event threshold of 20 and an event interval of 40 seconds, then the Cuda 12000 may generate 20 events over 40 seconds before throttling occurs. Values range from 0 seconds to 2147483647 seconds. The default is 1. Event Administrative Status Controls the transmission of traps and syslog messages with respect to the event threshold. Specify one of these administrative status values: ■ ■ ■ ■ unconstrained (default) — The Cuda 12000 transmits traps and syslog messages without regard to the event threshold and interval settings. maintainBelowThreshold — The Cuda 12000 suppresses traps and syslog messages if the number of events exceeds the threshold. The Cuda 12000 resumes transmitting traps and syslog messages when the number of events drops below the threshold. stopAtThreshold — The Cuda 12000 stops trap and syslog message transmissions at the threshold. To resume trap and syslog message transmission, you must reset the threshold. inhibited – The Cuda 12000 suppresses all trap transmissions and syslog messages. ADC Telecommunications, Inc. Configuring Event Transmission 209 Parameter Description Throttle Inhibited Displays the throttle inhibited status. This field displays True if one of the following conditions is met: ■ ■ Event Administrative Status is set to inhibited. Event Administrative Status is set to stopAtThreshold and the threshold has been reached. Otherwise, this field displays False. To configure event transmission, perform the following tasks: Task Command 1. Enter root mode. root 2. Specify the event threshold. event-config throttle threshold 3. Specify the event threshold interval. event-config throttle interval 4. Specify the event administrative status. event-config throttle admin {unconstrained | maintainBelowThreshold | stopAtThreshold | inhibited} 5. Display the event threshold. show event-config throttle Example The following is an example of an event threshold configuration, using the default settings: cli:192.168.208.3:root# show event-config throttle Event Throttle Parameters ------------------------Threshold 0 Interval 1 Admin Status unconstrained Throttle Inhibited False cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 210 CHAPTER 10: MANAGING SYSTEM EVENTS Event Reporting Each Cuda 12000 event belongs to one of eight event classes. An event class defines the severity of the event. You can configure each event class to be sent through a subset of reporting mechanisms (trap, syslog, or local event log). To do this, you specify: ■ An event class ■ How you want events in that class to be reported Event Classes Event classes are ordered from most critical (emergency) to least critical (debug). The following table lists the event classes, in priority order: Table 10-2 Event Classes Event Class Description Emergency Indicates hardware- or software-related problems with DOCSIS or EuroDOCSIS modules. Prevents CMTS operation. Alert Indicates a serious failure that causes the Cuda 12000 to reboot. Critical Indicates a serious failure that requires attention and prevents the device from transmitting data. Failure may be resolved without a system reboot. Error Indicates a failure occurred that could interrupt the normal data flow. Warning Indicates a failure occurred that could interrupt the normal data flow. (This failure is not as severe as reported for Error events.) Notice Indicates an event that requires attention, but is not a failure. Information Indicates an event that may be helpful for tracing normal operation. Informational events do not report failures. Debug An event used for only debugging purposes. ADC Telecommunications, Inc. Event Reporting 211 Reporting Actions Each event class is associated with a reporting action. The following table lists the reporting actions: Table 10-3 Reporting Actions Reporting Action Description local Write a message to the internal log. local|traps Write a message to the internal log and send a trap. local|syslog Write a message to the internal log and send a syslog message. local|traps|syslog Write a message to the internal log, send a trap, and send a syslog message. none Do not report events in this class. Configuring Event Reporting By default, the Cuda 12000 reports events as follows: Table 10-4 Default Event Class Reporting Actions Event Class Default Reporting Action Emergency local Alert local Critical local|traps|syslog Error local|traps|syslog Warning local|traps|syslog Notice local|traps|syslog Information none Debug none Cuda 12000 IP Access Switch CLI-based Administration Guide 212 CHAPTER 10: MANAGING SYSTEM EVENTS To configure event classes and associated reporting actions, perform the following tasks: Task Command 1. Enter root mode. root 2. Assign the Default event class and event-config reporting default reporting action. 3. Assign the Emergency event class and associated reporting action. event-config reporting emergency local 4. Assign the Alert event class and associated reporting action. event-config reporting alert local 5. Assign the Critical event class and associated reporting action. Note: The pipe ( | ) must be included in the command string. event-config reporting critical {local|traps|syslog} {local|traps} {local|syslog} 6. Assign the Error event class and associated reporting action. Note: The pipe ( | ) must be included in the command string. event-config reporting error {local|traps|syslog} {local|traps} {local|syslog} 7. Assign the Warning event class and associated reporting action. Note: The pipe ( | ) must be included in the command string. event-config reporting warning {local|traps|syslog} {local|traps} {local|syslog} 8. Assign the Notice event class and associated reporting action. Note: The pipe ( | ) must be included in the command string. event-config reporting notice {local|traps|syslog} {local|traps} {local|syslog} 9. Assign the Information event class event-config reporting info and associated reporting action. 10.Assign the Debug event class and associated reporting action. event-config reporting debug Refer to the next section for information on viewing the event reporting configuration. ADC Telecommunications, Inc. Event Reporting 213 Viewing Event Reporting Configuration You may view the event reporting configuration. The output includes event reporting configuration for all current event classes. To view the current event reporting configuration, perform the following tasks: Task Command 1. Enter root mode. root 2. Display current event reporting configuration show event-config reporting Example The following example displays the current event reporting configuration. cli:192.168.208.3:root# show event-config reporting Event Reporting Priorities -------------------------row count: 8 Priority ----------emergency alert critical error warning notice information debug Action -----------------local local local|syslog local|traps local|traps|syslog local|traps|syslog none none cli:192.168.208.3:root# Cuda 12000 IP Access Switch CLI-based Administration Guide 214 CHAPTER 10: MANAGING SYSTEM EVENTS Event Classes and SNMP System Events Event classes are associated with SNMP system events, as shown in Table 10-5. For additional information about SNMP System Events refer to Chapter 9, Simple Network Management Protocol (SNMP), on page 161. Table 10-5 List of System Events and Their Event Classes E SNMP System Event Event Class Cluster events: ■ authentication-failure Notice ■ bcm-failover-down Notice ■ bcm-failover-up Notice ■ bcm-state-change Notice ■ bcm-sw-mismatch Notice ■ trace-log Notice ■ cold-start Notice ■ warm-start Notice ■ icl-state-change Notice Module events: ■ cable-modem-auth-failure Notice ■ cable-modem-down Critical ■ cable-modem-up Notice ■ card-down Critical ■ card-up Notice ■ dhcp-relay-not-configured Warning ■ local-sonet-alarm Error ■ remote-sonet-alarm Error ■ Interface-related events: Notice ■ link up Notice ■ link down Error ■ chassis-fault Critical ■ chassis-fault-cleared Notice ADC Telecommunications, Inc. Event Classes and SNMP System Events SNMP System Event Event Class Provisioning events: ■ duplicate-addr Notice ■ isp-addr-high Notice ■ isp-addr-low Notice ■ ldap-failed Notice ■ ldap-restored Notice ■ prov-service Notice ■ subnet-addr-high Notice ■ subnet-addr-low Notice DOCSIS events: ■ docs-dyn-rsp-fail Warning ■ docss-dyn-ack-fail Warning ■ docs-dyn-req-fail Warning ■ docs-bpi-init Informational ■ docs-bpkm Error ■ docs-dcc-ack-fail Warning ■ docs-dcc-req-fail Warning ■ docs-dcc-rsp-fail Warning ■ docs-dynamic-sa Warning ■ docs-init-ack-fail Warning ■ docs-init-req-fail Warning ■ docs-init-rsp-fail Warning Routing events: ■ ospf-nbr-state Notice ■ ospf-virt-nbr-state Notice Modem deregistration event: ■ dereg-modems Cuda 12000 IP Access Switch CLI-based Administration Guide Warning 215 216 CHAPTER 10: MANAGING SYSTEM EVENTS Clearing the Event Log To prevent your internal event log from consuming too much disk space, you may want to clear the log periodically. Use this procedure to clear the event log: Task Command 1. Enter root mode. root 2. Clear the event log. event-log clear Displaying Event Transmission, Reporting, and Syslog Parameters Use this procedure to display the event transmission, reporting, and syslog parameters: Task Command 1. Enter root mode. root 2. Display event transmission, reporting, and syslog parameters. show event-config {throttle | reporting | syslog} ADC Telecommunications, Inc. Displaying Event Transmission, Reporting, and Syslog Parameters Example root# show event-config Event Throttle Parameters ------------------------Threshold Interval Admin Status Throttle Inhibited 0 1 unconstrained True Event Reporting Priorities -------------------------row count: 8 Priority ----------emergency alert critical error warning notice information debug Action -----------------local local local|traps|syslog local|traps|syslog traps|syslog traps|syslog none none Syslog Server 133.132.1.1 cli:192.168.208.3:root# show event-config throttle Event Throttle Parameters ------------------------Threshold 0 Interval 1 Admin Status unconstrained Throttle Inhibited True cli:192.168.208.3:root# show event-config reporting Event Reporting Priorities -------------------------row count: 8 Priority ----------emergency alert critical error Action -----------------local local local|traps|syslog local|traps|syslog Cuda 12000 IP Access Switch CLI-based Administration Guide 217 218 CHAPTER 10: MANAGING SYSTEM EVENTS warning notice information debug traps|syslog traps|syslog none none cli:192.168.208.3:root# show event-config syslog Syslog Server 133.132.1.1 cli:192.168.208.3:root# Displaying the Event Log Use this procedure to display the log of events that the Cuda has generated: Task Command 1. Enter root mode. root 2. Display the contents of the event log. show event-log The show event-log command output displays these fields of information about each event: Table 10-6 Event Log Fields Field Description Index The number of the event in the log. This number is used to order the events in the log. First Time The time that the log entry was created. Last Time The time that the last event associated with the log entry occurred. In some cases, multiple events can be associated with a single log entry. This tends to happen when duplicate events are reported. However, when only one event is reported, then one event is associated with an entry, which means that the First Time and Last Time values are the same. Counts The number of consecutive event instances that this event entry reports. The count starts at 1 when the entry is created and increments by one for each subsequent duplicate event. Level The event’s class (emergency, alert, critical, error, warning, notice, info, debug). ADC Telecommunications, Inc. Displaying the Event Log Field Description ID An internal event identifier. The Text field describes the event associated with this identifier. Text Brief description of the event. Example root# show event-log row count: 133 Index First Time ------ ---------1 2000-12-31 ,21:1:40.0 ,455:0 2 2000-12-31 ,21:31:40. 0,455:0 3 2001-1-1,1 :20:0.0,45 5:0 219 Last Time Counts Level ID ---------- ---------- ---------- ---------2000-12-31 1 critical 2147483652 ,21:1:40.0 ,455:0 2000-12-31 ,21:31:40. 0,455:0 2001-3-6,1 :26:40.0,4 55:0 1 1264 4 2000-12-31 2000-12-31 ,19:28:20. ,19:28:20. 0,455:0 0,455:0 2 5 2000-12-31 2000-12-31 ,19:36:40. ,23:46:40. 0,455:0 0,455:0 --More-- 5 Text ---------CMTS/CM Down ifIndex = 8781825 critical 2147483649 Card Down - 1/1/1 critical 2147483652 CMTS/CM Down ifIndex = 8781825 critical 2147483652 CMTS/CM Down ifIndex = 8781825 critical 2147483652 CMTS/CM Down ifIndex = Cuda 12000 IP Access Switch CLI-based Administration Guide 220 CHAPTER 10: MANAGING SYSTEM EVENTS ADC Telecommunications, Inc. III IP ROUTING Chapter 11 Creating Route Filters Chapter 12 Configuring DHCP Relay Chapter 13 Configuring DHCP Authority Chapter 14 Configuring IP Chapter 15 IP Packet Filtering Chapter 16 Network-Layer Bridging Chapter 17 Managing IP Multicast 11 CREATING ROUTE FILTERS This chapter provides information and procedures on how to create route filters to control the flow of routes on your network. You create these route filters in the form of route-maps and map-lists. Route-maps contain the fundamental gating action (permit or deny) based on selected route-match criteria with optional override actions. Map-lists are sequential groupings of these route-maps. This chapter includes the following sections: ■ About RIP and OSPF Route Maps (page 224) ■ Creating Route Maps (page 225) ■ Creating Map Lists (page 239) ■ Route Filter Configuration Example (page 241) 224 CHAPTER 11: CREATING ROUTE FILTERS About RIP and OSPF Route Maps The system uses route filtering functions to control the flow of routes to and from other RIP and OSPF routers. Two filtering functions are supported for control of RIP and OSPF routes: ■ Import — Controls how routes are added to the system’s routing table. ■ Export — Controls which routes are advertised to other routers. Route filtering is used to customize connectivity, increase security, conserve routing table space, or adjust route cost. In order to understand route filtering, you must be familiar with the following functions: ■ Route-Map — The route map defines the match criteria and the action that you want the system to take when a match is found. You use the route-map command to create a route-map and enter configuration mode for the route-map. When you define a route-map, you specify a permit or deny action. You then define the match criteria of a route map using the match command. In addition, you can choose to define override actions using the override command. ■ Map-List — A sequential grouping of route-maps. Routes are sequentially compared against all route-maps that comprise the map-list. When a match is found, the action defined by the route-map is invoked, and further exploration of the route-map is ended. If the system does not find a match, then no action is taken. Defining RIP and OSPF route filtering is a two-step process: ■ First, you create route maps to define match criteria and the action that you want the system to take when it finds a match. You can choose to permit or deny a route, as well as override route cost, tag, or preference. ■ Second, you arrange those route-maps into map-lists. When defining route maps and map lists, remember the following: ■ Map lists are made up of one or more route maps. ■ The same route map may be shared among multiple map lists. ■ Route maps within each map list must be sorted in order of the specific-to-general match criteria and action needs of the map list. ADC Telecommunications, Inc. Creating Route Maps 225 Creating Route Maps You can use route maps to control and modify routing information and to define the conditions by which routes are redistributed. When you run the route-map command within router:rip:import or export mode, or router:ospf:export mode the following syntax applies: route-map {permit | deny} The map-tag is a number that identifies the route map. The permit keyword configures the router to accept matching routes; the deny keyword configures the router to reject matching routes. When you run the route-map command within router-ospf import mode, the following syntax applies: route-map All route maps must permit incoming OSPF routes; deny is not an option. Once you issue the route-map command, you enter configuration mode for the specified route-map. For example: cli:172.16.19.10:root# router ospf export mode: router:ospf:export cli:172.16.19.10:router:ospf:export# route-map 80 permit cli:172.16.19.10:router:ospf:export:route-map(80)# While within this mode, you then use the following commands: ■ match — Use this command to specify the routes to match. ■ override — Use this command to alter the attributes of redistributed routes. Cuda 12000 IP Access Switch CLI-based Administration Guide 226 CHAPTER 11: CREATING ROUTE FILTERS While within any route-map mode, you can display a summary of all route maps configured within that mode using the show route-map command as follows: cli:172.16.19.10:router:rip:export:route-map(3)# show route-map row count: 3 ID Description Route Address Route Mask --- ----------- --------------- --------------1 172.16.0.0 255.255.0.0 2 10.255.0.0 255.255.0.0 3 10.0.0.0 255.0.0.0 Interface Address Owner ----------------- ----0.0.0.0 NONE 0.0.0.0 NONE 0.0.0.0 NONE cli:172.16.19.10:router:rip:export:route-map(3)# ADC Telecommunications, Inc. Creating Route Maps 227 Using the Match Command Use the match command within route-map configuration mode to define the match criteria for the route map. Refer to the following sections for more information on using this command: ■ “Creating OSPF Import Route Maps” on page 229 ■ “Creating OSPF Export Route Maps” on page 231 ■ “Creating RIP Import Route Maps” on page 234 ■ “Creating RIP Export Route Maps” on page 236 The following example sets match attributes for route-map 80, then verifies the new route-map configuration using the show route-map command: cli:172.16.19.10:router:ospf:export:route-map(80)# match ip-address 172.16.19.0 255.255.255.0 cli:172.16.19.10:router:ospf:export:route-map(80)# match route-type rip cli:172.16.19.10:router:ospf:export:route-map(80)# show route-map 80 ID 80 Description Route Address 172.16.19.0 Route Mask 255.255.255.0 Type RIP Specific1 0.0.0.0 Specific2 0.0.0.0 Tag 0 Key Bits 5 Metric 0 Flags 1 Action Tag 0 cli:172.16.19.10:router:ospf:export:route-map(80)# Cuda 12000 IP Access Switch CLI-based Administration Guide 228 CHAPTER 11: CREATING ROUTE FILTERS Using the Override Command Use the override command within route-map configuration mode to specify override actions to take for all matching routes. Refer to the following sections for more information on using this command: ■ “Creating OSPF Import Route Maps” on page 229 ■ “Creating OSPF Export Route Maps” on page 231 ■ “Creating RIP Import Route Maps” on page 234 ■ “Creating RIP Export Route Maps” on page 236 The following example configures route-map 80 to redistribute matching routes with a cost metric of 10. cli:172.16.19.10:router:ospf:export:route-map(80)# override metric 10 cli:172.16.19.10:router:ospf:export:route-map(80)# show route-map 80 ID 80 Description Route Address 172.16.19.0 Route Mask 255.255.255.0 Type RIP Specific1 0.0.0.0 Specific2 0.0.0.0 Tag 0 Key Bits 5 Metric 10 Flags 17 Action Tag 0 cli:172.16.19.10:router:ospf:export:route-map(80)# ADC Telecommunications, Inc. Creating Route Maps 229 Creating OSPF Import Route Maps You can use OSPF import route-maps to override the preference of incoming OSPF routes. Preference is the local ranking of the route. OSPF import route maps are created within router-ospf import mode using the route-map command. To create an OSPF import route map, use this procedure: Permit and deny options do not apply to OSPF import routes as all OSPF routes are always learned. Task Command 1. Enter router-ospf mode. router ospf 2. Enter import mode. import 3. Specify the route map or create a new one if it does not already exist. route-map 4. Define that match criteria for this route map. match {ip-address | neighbor | tag {exact | exclude}} 5. Define the override criteria that you want the system to apply to any routes that match. override preference 6. Optional: You can then verify the route map with the show route-map command. show route-map Cuda 12000 IP Access Switch CLI-based Administration Guide 230 CHAPTER 11: CREATING ROUTE FILTERS The following example creates an OSPF import route map that assigns a preference of 100 to all incoming routes from the 172.16.0.0 network: cli:172.16.19.10:root# router ospf mode: router:ospf cli:172.16.19.10:router:ospf# import mode: router:ospf:import cli:172.16.19.10:router:ospf:import# route-map 1 cli:172.16.19.10:router:ospf:import:route-map(1)# match ip-address 172.16.0.0 255.255.0.0 cli:172.16.19.10:router:ospf:import:route-map(1)# override preference 100 cli:172.16.19.10:router:ospf:import:route-map(1)# show route-map 1 ID 1 Description Route Address 172.16.0.0 Route Mask 255.255.0.0 Peer Address 0.0.0.0 Peer Mask 0.0.0.0 Tag 0 Key Bits 1 Preference 100 Flags 2049 cli:172.16.19.10:router:ospf:import:route-map(1)# ADC Telecommunications, Inc. Creating Route Maps 231 Creating OSPF Export Route Maps You can use OSPF route maps to permit or deny advertisement of routes learned from a non-OSPF protocol. For example, you can choose to advertise select routes onto your OSPF network if they were originally learned through the RIP protocol, or if they were manually added as a static route. You can also override the cost metric of incoming routes originating for a non-OSPF protocol. When there are multiple routes to the same destination, the route with the lowest cost is preferred. OSPF export route maps are created within router-ospf export mode using the route-map command. To create an OSPF export route map, use this procedure: Task Command 1. Enter router-ospf mode. router ospf 2. Enter export mode. export 3. Specify the route map that you want to configure, or create a new one if it does not already exist. route-map {permit | deny} Cuda 12000 IP Access Switch CLI-based Administration Guide 232 CHAPTER 11: CREATING ROUTE FILTERS Task Command 4. Define the match criteria for this route map. match {ip-address | tag {exact | exclude} | specific1 | specific2 | route-type {none | connected | static | special | rip | bgp-ext | bgp-int | } Note that a “connected” route is a local route (a route to a directly connected network). 5. Define the override criteria that you want the system to apply to any routes that match. override {metric | tag } 6. Optional: You can then verify the route map with the show route-map command. show route-map ADC Telecommunications, Inc. Creating Route Maps 233 The following example creates an export route map that prevents the 176.16.0.0 RIP network from being advertised. cli:172.16.19.10:router:ospf:import:route-map(1)# router rip mode: router:rip cli:172.16.19.10:router:rip# export mode: router:rip:export cli:172.16.19.10:router:rip:export# route-map 1 deny cli:172.16.19.10:router:rip:export:route-map(1)# match ip-address 172.16.0.0 255.255.0.0 cli:172.16.19.10:router:rip:export:route-map(1)# show route-map 1 ID 1 Description Route Address 172.16.0.0 Route Mask 255.255.0.0 Interface Address 0.0.0.0 Owner NONE Specific 0.0.0.0 Peer Mask 0.0.0.0 Tag 0 Key Bits 1 Metric 16 Flags 0 Action Tag 0 cli:172.16.19.10:router:rip:export:route-map(1)# Cuda 12000 IP Access Switch CLI-based Administration Guide 234 CHAPTER 11: CREATING ROUTE FILTERS Creating RIP Import Route Maps You can use RIP import route maps to alter the preference of incoming RIP routes. When there are multiple routes to the same destination, the route with the numerically highest preference is preferred. RIP import route maps are created within router-rip import mode using the route-map command. To create a RIP import route map, use this procedure: Task Command 1. Enter router-rip mode. router rip 2. Enter import mode. import 3. Specify the route map or create a new one if it does not already exist. route-map 4. Define that match criteria for this route map. match {ip-address | tag {exact | exclude} | peer-address } 5. Define the override criteria that you want the system to apply to any routes that match. override {metric | tag | preference } 6. Optional: You can then verify the route map with the show route-map command. show route-map ADC Telecommunications, Inc. Creating Route Maps 235 The following example creates a RIP import route-map that prevents the 176.16.0.0 network learned through a non-RIP protocol from being advertised via the RIP protocol. cli:172.16.19.10:root# router rip mode: router:rip cli:172.16.19.10:router:rip# import mode: router:rip:import cli:172.16.19.10:router:rip:import# route-map 1 deny cli:172.16.19.10:router:rip:import:route-map(1)# match ip-address 172.16.0.0 255.255.0.0 cli:172.16.19.10:router:rip:import:route-map(1)# show route-map 1 ID 1 Description Route Address 172.16.0.0 Route Mask 255.255.0.0 Peer Address 0.0.0.0 Peer Mask 0.0.0.0 Tag 0 Key Bits 1 Preference 0 Metric 0 Flags 0 Action Tag 0 cli:172.16.19.10:router:rip:import:route-map(1)# Cuda 12000 IP Access Switch CLI-based Administration Guide 236 CHAPTER 11: CREATING ROUTE FILTERS Creating RIP Export Route Maps You can use RIP export route maps to permit or deny advertisement of routes learned from non-RIP protocols. For example, you can choose not to advertise select routes via RIP if they were manually added as static routes. You can also choose to override the cost metric of advertised routes originating for a non-RIP protocol. When there are multiple routes to the same destination, the route with the lowest cost metric is preferred. OSPF export route maps are created within router-rip export mode using the route-map command. To create a RIP export route map, use this procedure: Task Command 1. Enter router-rip mode. router rip 2. Enter export mode. export 3. Specify the route map or create a new one if it does not already exist. route-map {permit | deny} ADC Telecommunications, Inc. Creating Route Maps 237 Task Command 4. Define that match criteria for this route map. match {ip-address | tag {exact | exclude} | interface-address | peer-mask | specific | route-owner {none | connected | ospf | ospf-ext | static | special | bgp-ext | bgp-int | } Note that a “connected” route is a local route (a route to a directly connected network). 5. Define the override criteria that you want the system to apply to any routes that match. override {metric | tag } 6. Optional: You can then verify the route map with the show route-map command. show route-map Cuda 12000 IP Access Switch CLI-based Administration Guide 238 CHAPTER 11: CREATING ROUTE FILTERS The following example creates a RIP export route map that allows the 176.16.0.0 network that was learned through a non-RIP protocol to be advertised via RIP with a cost of 16. cli:172.16.19.10:root# router rip mode: router:rip cli:172.16.19.10:router:rip# export mode: router:rip:export cli:172.16.19.10:router:rip:export# route-map 1 permit cli:172.16.19.10:router:rip:export:route-map(1)# match ip-address 172.16.0.0 255.255.0.0 cli:172.16.19.10:router:rip:export:route-map(1)# override metric 16 cli:172.16.19.10:router:rip:export:route-map(1)# show route-map 1 ID 1 Description Route Address 172.16.0.0 Route Mask 255.255.0.0 Interface Address 0.0.0.0 Owner NONE Specific 0.0.0.0 Peer Mask 0.0.0.0 Tag 0 Key Bits 1 Metric 16 Flags 17 Action Tag 0 cli:172.16.19.10:router:rip:export:route-map(1)# ADC Telecommunications, Inc. Creating Map Lists 239 Creating Map Lists A map-list is a sequential grouping of route maps. These route-maps serve as the filter criteria within the map-list. A route is sequentially compared against all route maps that comprise the active route list. Upon finding a match, the system takes the action defined by the route map and exists the list. You create a map-list by adding a route map to it using the map-list command. You can create multiple map-lists, but only one list can be configured as the active list for each of the following areas: ■ RIP Imports ■ RIP Exports ■ OSPF Imports ■ OSPF Exports Use the set active option to define a map-list as active. This means, if you create 3 map lists to define RIP import policies, only a single map list can be designated as the active map list against which incoming RIP routes are applied. You add one or more route-maps to a specified map-list using the map-list command import or export modes. The following syntax applies: map-list route-map For example, the following command adds route-map 10 to map-list 1: cli# map-list 1 route-map 10 For example, the following example creates map-list 1 then configures it as as the active map-list to which incoming RIP routes are applied: cli:172.16.19.10:root# router rip import mode: router:rip:import cli:172.16.19.10:router:rip:import# map-list 1 route-map 1 cli:172.16.19.10:router:rip:import# map-list 1 set active cli:172.16.19.10:router:rip:import# Cuda 12000 IP Access Switch CLI-based Administration Guide 240 CHAPTER 11: CREATING ROUTE FILTERS Route-maps are appended to the specified map-list. The order in which you add the route-maps to the map-list determine the sequence in which the system examines the route maps; the first route-map that you added to the list is examined first, the final route-map that you appended to the list is examined last. You cannot modify the sequence of route-maps in an existing map-list. To re-define the order of route-maps, you must create a new map-list. To create a map list, use this procedure: Task Command 1. If you haven’t already done so, define the route maps that you want to use to filter routes. For more information about the route-map command and defining route maps, see “Creating Route Maps” on page 225. 2. Do one of the following: ■ If you are creating RIP route maps, enter router-rip mode. ■ or or If you are creating OSPF route maps, enter router-ospf mode. router rip ■ router ospf ■ import 3. Do one of the following: ■ If you are creating an import filter, enter import mode. or or ■ If you creating an export filter, enter export mode. 4. Add a route map to the map list then set the list to active or inactive. Repeat this command for all route maps that you want to add to the map-list. ■ export map-list route-map set {active | inactive} ADC Telecommunications, Inc. Route Filter Configuration Example 241 The following example creates a RIP import filter by adding route maps 1, 2, and 3 to the a map list number 20 and designates it as the active list to use for RIP imports. cli:172.16.19.10:root# router rip mode: router:rip cli:172.16.19.10:router:rip# import mode: router:rip:import cli:172.16.19.10:router:rip:import# map-list 2 route-map 1 cli:172.16.19.10:router:rip:import# map-list 2 route-map 2 cli:172.16.19.10:router:rip:import# map-list 2 route-map 3 set active cli:172.16.19.10:router:rip:import# Route Filter Configuration Example The following example creates two RIP import route-maps and adds them to map-list 1: cli:172.16.19.10:root# router rip mode: router:rip cli:172.16.19.10:router:rip# import mode: router:rip:import cli:172.16.19.10:router:rip:import# route-map 10 permit cli:172.16.19.10:router:rip:import:route-map(10)# match ip-address 172.16.19.0 255.255.255.0 cli:172.16.19.10:router:rip:import:route-map(10)# override metric 10 cli:172.16.19.10:router:rip:import:route-map(10)# route-map 11 deny cli:172.16.19.10:router:rip:import:route-map(11)# match ip-address 172.16.19.23 255.255.255.255 cli:172.16.19.10:router:rip:import:route-map(11)# map-list 1 route-map 11 cli:172.16.19.10:router:rip:import:route-map(11)# map-list 1 route-map 10 cli:172.16.19.10:router:rip:import:route-map(11)# map-list 1 set active cli:172.16.19.10:router:rip:import:route-map(11)# show map-list 1 row count: 3 Template Template Order -------- -------1 1 10 3 11 2 Row Status -------------Active Active Active cli:172.16.19.10:router:rip:import:route-map(11)# Cuda 12000 IP Access Switch CLI-based Administration Guide 242 CHAPTER 11: CREATING ROUTE FILTERS ADC Telecommunications, Inc. 12 CONFIGURING DHCP RELAY This chapter provides information and procedures on how to configure DHCP relay on a cable interface and includes the following sections: ■ About DHCP Relay (page 244) ■ Displaying DHCP Relay Configuration (page 245) ■ Configuring DHCP Relay Options (page 247) ■ Specifying DHCP Servers (page 249) ■ DHCP and BOOTP Policies (page 251) 244 CHAPTER 12: CONFIGURING DHCP RELAY About DHCP Relay DHCP is used within a DOCSIS- or EuroDOCSIS-compliant network to allocate IP addresses and to configure cable modems with other IP parameters. DHCP Relay support on DOCSIS or EuroDOCSIS modules enables a cable interface (CMTS) to forward DHCP Requests from cable modems, CPE devices, MTA devices, and other IP hosts to a DHCP server. The DHCP server may reside: ■ Externally, on a system other than the Cuda 12000 that has the cable interface you are configuring. ■ Internally, on the same Cuda 12000 that has the cable interface that you are configuring. Note: You may configure the CMTS to forward DHCP Requests to up to 32 servers using DHCP Policies. For more information, see “Configuring DHCP and BOOTP Policies” on page 253. Gateway addresses are used by the DHCP Relay to request a specific subnet for the host and cable modem. Configuration is accomplished within interface cable mode using the dhcp-relay command. Using this command, you can configure the following functions: ■ Enable or disable DHCP Relay ■ Configure the following gateway addresses: ■ ■ CPE/IP Host Gateway Address — The Host Gateway address that the DHCP Relay requests on behalf of the host. This is the same address as the Gateway Address configured on the interface. When a DHCP request is received and it is from the host, then the Host Gateway Address is used by the DHCP Relay. Cable Modem (CM) Gateway Address — The CM Gateway address that the DHCP Relay requests on behalf of the cable modem. This is the same address as the Gateway Address configured on the interface. When a DHCP Request is received and it is from the cable modem, then the CM Gateway Address is used by the DHCP Relay. ADC Telecommunications, Inc. Displaying DHCP Relay Configuration ■ ■ 245 MTA Gateway Address — The MTA Gateway address that the DHCP Relay requests on behalf of the MTA device. This is the same address as the Gateway Address configured on the interface.When a DHCP Request is received and it is from the MTA device, then the MTA Gateway Address is used by the DHCP Relay. Enable or disable agent options. Displaying DHCP Relay Configuration You can display the current DHCP relay configuration using the show dhcp-relay command from within interface cable mode, as shown in the following example: cli:192.168.208.3:interface:cable:csi(1/1/1)# show dhcp-relay dhcp-relay enable Add Agent Options enable Drop Mismatch disable Max. Pkt. Len. 576 Relay Mode replace Server Address ---------------giAddresses: CM CPE MTA 201.1.1.1 201.1.2.1 0.0.0.0 cli:192.168.208.3:interface:cable:csi(1/1/1)# Cuda 12000 IP Access Switch CLI-based Administration Guide 246 CHAPTER 12: CONFIGURING DHCP RELAY Table 12-1 describes the fields shown in the display. Table 12-1 DHCP-Relay Display Fields Field Description dhcp-relay: [enabled or disabled] Indicates whether or not the DHCP Relay is enabled on this cable interface. Add Agent Options Indicates whether Agent Options are enabled on this cable interface. Drop Mismatch Indicates whether the Drop Mismatch options is enable or disabled. Max Pkt Len Maximum packet length allowed to be relayed. Relay Mode DHCP Relay mode configured on this interface. giAddresses Indicates the IP gateway that is used by: ■ ■ ■ Cable modems (CM) CPE devices attached to this cable interface MTA devices To configure which DHCP servers the CMTS forwards requests to, use the dhcp-policy command. Using DHCP Policies, you can configure the DHCP Relay agent to forward requests to a list of up to 32 DHCP servers. For more information, see “Configuring DHCP and BOOTP Policies” on page 253. ADC Telecommunications, Inc. Configuring DHCP Relay Options 247 Configuring DHCP Relay Options The Cuda 12000 allows you to enable and configure DHCP Relay functionality on each IP interface so that the interface can forward DHCP requests to a central DHCP server. You must enable DHCP Relay on a select CMTS interface to dynamically allocate network addresses to the attached cable modems. You must also enable DHCP agent options for that interface if you plan to place cable modems, attached CPE hosts and MTA devices on different networks. Use the following procedure to configure DHCP Relay on a cable interface. Task Command 1. Enter configuration mode for the the interface on which you want to DHCP Relay. interface 2. Enable DHCP Relay on the current dhcp-relay {enable | disable} interface. Disabling DHCP Relay prevents the DHCP server from assigning IP addresses to hosts on the interface. 3. Show the available IP interfaces on show ip-address the selected physical interface. You must choose one of these interfaces as a gateway for cable modems and CPE hosts (next). If you have not yet done so, you must add the IP address of the gateway (that you want the devices on this interface to use) to the interface using the ip address command. 4. If you plan to specify different gateways for cable modem, CPE devices and MTA devices to use, you must enable DHCP agent options. dhcp-relay add-agent-options enable 5. Configure the gateway that you want the CPE/IP hosts on this interface to use. Select one of the IP interfaces defined on the current physical interface. dhcp-relay cpe-gateway Cuda 12000 IP Access Switch CLI-based Administration Guide Note that this option must be enabled when using the FastFlow Broadband Provisioning Manager. 248 CHAPTER 12: CONFIGURING DHCP RELAY Task Command 6. If you are configuring a cable interface, then configure the gateway that you want cable modems on this interface to use. dhcp-relay cm-gateway 7. If you are configuring an MTA interface, then configure the gateway that you want MTA devices on this interface to use. dhcp-relay mta-gateway 8. Verify the current dhcp-relay parameters for the current interface. show dhcp-relay Example cli:192.168.208.3:interface:cable:csi(1/1/1)# dhcp-relay enable cli:192.168.208.3:interface:cable:csi(1/1/1)# dhcp-relay add-agent-options enable cli:192.168.208.3:interface:cable:csi(1/1/1)# show ip address Chassis/Slot/Interface 1/1/1 row count: 2 IP Address ---------------201.1.1.1 201.1.2.1 Net Mask Interface Priority ---------------- ---------- ---------255.255.255.0 8781825 Other 255.255.255.0 8781825 Primary cli:192.168.208.3:interface:cable:csi(1/1/1)# cli:192.168.208.3:interface:cable:csi(1/1/1)# cli:192.168.208.3:interface:cable:csi(1/1/1)# cli:192.168.208.3:interface:cable:csi(1/1/1)# dhcp-relay enable Add Agent Options enable Drop Mismatch disable Max. Pkt. Len. 576 Relay Mode replace Server Address ---------------giAddresses: CM CPE MTA dhcp-relay cm-gateway 201.1.2.1 dhcp-relay cpe-gateway 201.1.2.1 dhcp-relay mta-gateway 201.1.2.1 show dhcp-relay 201.1.2.1 201.1.2.1 201.1.2.1 ADC Telecommunications, Inc. Specifying DHCP Servers 249 Specifying DHCP Servers You must specify the DHCP server to which you want the cable interface to forward DHCP Requests. The DHCP server is configured on a per interface basis. You may add up to 32 DHCP servers. If a DHCP server is not configured, then the DHCP server drops all DHCP requests as it does not know where to forward them. DHCP servers fall into two categories: ■ External — DHCP servers that reside on systems other than the Cuda 12000 that has the cable interface that you are configuring. DHCP messages are forwarded over the network to a remote, external DHCP server. ■ Internal — A FastFlow Broadband Provisioning Manager DHCP server that resides on the same Cuda 12000 that has the cable interface you are configuring (that is, the local Cuda 12000). DHCP requests are forwarded internally to the DHCP server. Specifying External DHCP Servers To specify an external DHCP server, you configure the DHCP Relay Agent on the cable interface to point to the IP address of a remote DHCP server. To do so, perform the following tasks. Task Command 1. Enter cable interface mode. interface cable 2. Specify an external DHCP server. dhcp-policy default permit Example The following example configures cable interface 1/1/1 to forward DHCP messages to the DHCP server at address 201.1.13.1: cli:172.16.19.10:root# interface 1/1/1 mode: interface:cable:csi(1/1/1) cli:172.16.19.10:interface:cable:csi(1/1/1)# dhcp-policy default permit 201.1.13.1 Cuda 12000 IP Access Switch CLI-based Administration Guide 250 CHAPTER 12: CONFIGURING DHCP RELAY Specifying the Internal DHCP Server To specify the internal FastFlow BPM DHCP server, perform the following tasks: Task Command 1. Enter cable interface mode. interface cable 2. Specify the internal DHCP server. dhcp-policy default permit forward-internal Example The following example configures cable interface 1/1/1 to forward DHCP messages to the internal FastFlow BPM DHCP server: cli:172.16.19.10:root# interface 1/1/1 mode: interface:cable:csi(1/1/1) cli:172.16.19.10:interface:cable:csi(1/1/1)# dhcp-policy default permit forward-internal ADC Telecommunications, Inc. DHCP and BOOTP Policies 251 DHCP and BOOTP Policies You can use Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) policies to control which devices obtain IP addresses and which DHCP and BOOTP servers allocate those addresses. This section provides information and procedures about configuring DHCP and BOOTP policies on the Cuda 12000 and includes the following sections: ■ About DHCP Policies ■ About BOOTP Policies ■ Configuring DHCP and BOOTP Policies ■ Configuring Default Policies About DHCP Policies A DOCSIS- or EuroDOCSIS-compliant network uses DHCP for dynamic assignment of IP addresses. A DHCP server allocates addresses and other IP operational parameters to requesting cable modems, CPE devices and MTA devices. DOCSIS and EuroDOCSIS modules serve as cable modem termination systems and, as such, also function as DHCP relay agents. As relay agents, these cable interfaces relay DHCP requests and responses between the DHCP server and cable modems, CPE devices and MTA devices. DHCP policies allow you to control and restrict the forwarding of DHCP requests. Specifically, DHCP policies allow matching on several parameters in the DHCP packet. It then uses the result of this matching to determine which list of servers to forward the packet to; or it can reject (drop) the packet to deny the requesting client an address. DHCP policies allow you to do the following: ■ Prevent select modems, CPE devices and MTA devices from obtaining IP addresses. ■ Direct DHCP requests to particular DHCP servers based on whether the request originated from a modem, CPE device or MTA device. ■ Direct DHCP requests to particular DHCP servers based on the cable modem’s, CPE’s or MTA’s MAC address. ■ Direct DHCP requests to particular servers based on which interface it was received. Cuda 12000 IP Access Switch CLI-based Administration Guide 252 CHAPTER 12: CONFIGURING DHCP RELAY For example, you can configure the system to match on the DHCP packet to determine whether the request originated from a cable modem, a CPE, a MTA device, a specific interface, or a specific MAC address; wildcards can be used to match portions of a MAC address. In the event of a match, you can configure the DHCP relay agent to forward the request to a list of up to 32 DHCP servers, or configure the agent to drop the request. If there are no policies defined, or a DHCP packet does not match any existing policy, the default policy is used to determine if the packet is dropped or forwarded to a list of up to 32 DHCP servers. The Cuda 12000 ships with a default policy to deny (drop) DHCP requests that do not match any other policy. Note that while other DHCP policies are interface-specific, the default DHCP policy is module-wide—it provides default behavior for all interfaces on the module. This default policy can be modified but not deleted. About BOOTP Policies BOOTP is a protocol that allows diskless workstations to boot off of a network server, called a BOOTP server. You can configure the cable interface to deny (drop) a matching BOOTP request or permit it to be forwarded to a list of BOOTP servers. ADC Telecommunications, Inc. DHCP and BOOTP Policies 253 Configuring DHCP and BOOTP Policies DHCP Policies determine the DHCP servers to which a CMTS interface forwards DHCP requests from attached cable modems, CPE devices and MTA devices. BOOTP Policies determine the BOOTP servers to which a CMTS interface forwards BOOTP requests from attached cable modems and diskless workstations. You configure DHCP policies using the dhcp-policy command. You configure the BOOTP policies using the bootp-policy command. Defining Policies for a Cable Interface Using the dhcp-policy or bootp-policy command, you can configure the cable interface to forward DHCP or BOOTP requests. The following table describes the parameters that you set to configure DHCP policies: Table 12-2 DHCP Policy Parameters Parameter Description Index Number Determines the sequence in which a DHCP request is compared to each policy. You assign this number when defining the policy. The request is applied to the policy with the lowest index first, then precedes incrementally. Upon finding a match, the action defined for the policy is taken, and no further policies are applied. Policy Server List A list of IP addresses to which you want the current cable interface to forward DHCP packets. Cuda 12000 IP Access Switch CLI-based Administration Guide 254 CHAPTER 12: CONFIGURING DHCP RELAY Parameter Description Match Criteria DHCP Policies allow matching on several parameters in the DHCP packet, including: ■ ■ ■ ■ Policy Action Cable Modem MAC Address – Allows you to match on the cable modem MAC address contained in the request. Interface – Enables you to match on the specific interface on which the DHCP offer was received. MAC Address – Allows you to match on the source MAC address of the cable modem. You can also wildcard any or all octets of the MAC address. Specifies the action that you want the system to take upon finding a matching DHCP request. You can configure the interface to do the following: ■ ■ Forward-Internal Agent-Options – Determines whether the DHCP request is from a cable modem, CPE device, or MTA device. Permit the packet to be forwarded to up to 32 DHCP servers Deny (drop) the packet without forwarding it Specifies that the current cable interface forwards DHCP requests internally (meaning, to a DHCP server on the local Cuda 12000). Optionally, you can specify the disable keyword to disable internal forwarding. ADC Telecommunications, Inc. DHCP and BOOTP Policies 255 The following table describes the parameters that you set to configure BOOTP policies: Table 12-3 BOOTP Policy Parameters Parameter Description Index Number Determines the sequence in which a BOOTP request is compared to each policy. You assign this number when defining the policy. The request is applied to the policy with the lowest index first, then precedes incrementally. Upon finding a match, the action defined for the policy is taken, and no further policies are applied. Policy Server List A list of IP addresses to which you want the current cable interface to forward BOOTP messages. Match Criteria Matching MAC addresses of BOOTP clients. These devices are either permitted to send BOOTP messages to specified BOOTP servers or denied permission to send BOOTP messages. Using masks, you can specify a range of MAC addresses. Policy Action The action that you want the system to take upon finding a matching BOOTP request. You can configure the interface to do the following: ■ ■ Cuda 12000 IP Access Switch CLI-based Administration Guide Permit the BOOTP message to be forwarded to BOOTP servers. Deny (drop) the BOOTP message from being forwarded to BOOTP servers. 256 CHAPTER 12: CONFIGURING DHCP RELAY To configure a DHCP Policy and a BOOTP policy, perform the following tasks: Task Command 1. Enter cable interface mode. interface cable 2. Create a DHCP Policy. dhcp-policy { | default} {deny | permit} { ... | forward-internal [disable] } [agent-option {cm | cpe} | cmmac | interface | mac [mask ]] [vendor-class-id {cm | mta}] [description ] 3. Create a BOOTP policy. bootp-policy { | default} {deny mac [mask ] ... | permit ... mac [mask ] ...} [description ] To display the DHCP or BOOTP policies currently configured on a cable interface, perform the following tasks: Task Command 1. Enter cable interface mode. interface cable 2. Display all DHCP policies. show dhcp-policy 3. Display all BOOTP policies. show bootp-policy 4. Display a specified DHCP policy. show dhcp-policy 5. Display a specified BOOTP policy. show bootp-policy 6. Display the default DHCP policy. show dhcp-policy default 7. Display the default BOOTP policy. show bootp-policy default ADC Telecommunications, Inc. DHCP and BOOTP Policies 257 To remove DHCP or BOOTP policies from the current cable interface, perform the following tasks within interface cable mode: Task Command 1. Remove all DHCP policies from the current cable interface. no dhcp-policy all 2. Remove all BOOTP policies from the current cable interface. no bootp-policy all 3. Remove a specified DHCP policy from the current cable interface. no dhcp-policy 4. Remove a specified BOOTP policy from the current cable interface. no bootp-policy Cuda 12000 IP Access Switch CLI-based Administration Guide 258 CHAPTER 12: CONFIGURING DHCP RELAY Configuring Default Policies To modify the default DHCP or BOOTP policy used on all interfaces of a specific DOCSIS module, enter interface cable mode for one of the interfaces on the selected DOCSIS module and perform the following task: Task Command 1. Modify the default DHCP policy. dhcp-policy default {permit