Lucent Technologies Stinger Administration Manual

Download

Stinger®

Administration Guide

Part Number: 7820-0712-008

For software version 9.7.0

August, 2004

This material is protected by the copyright laws of the United States and other countries. It may not be reproduced, distributed, or altered in any fashion by any entity (either internal or external to Lucent Technologies), except in accordance with applicable agreements, contracts, or licensing, without the express written consent of Lucent Technologies. For permission to reproduce or distribute, please email your request to techcomm@lucent.com.

Notice

Every effort was made to ensure that the information in this document was complete and accurate at the time of printing, but information is subject to change.

For latest information, refer to online product documentation at www.lucent.com/support.

European Community (EC) RTTE compliance

Hereby, Lucent Technologies, declares that the equipment documented in this publication is in compliance with the essential requirements and other relevant provisions of the Radio and Telecommunications Technical Equipment (RTTE) Directive 1999/5/EC.

To view the official Declaration of Conformity certificate for this equipment, according to EN 45014, access the Lucent INS online documentation library at http://www.lucentdocs.com/ins.

Safety, compliance, and warranty Information

Before handling any Lucent Access Networks hardware product, read the Edge Access and Broadband Access Safety and Compliance Guide included in your product package. See that guide also to determine how products comply with the electromagnetic interference (EMI) and network compatibility requirements of your country. See the warranty card included in your product package for the limited warranty that Lucent Technologies provides for its products.

Security statement

In rare instances, unauthorized individuals make connections to the telecommunications network through the use of access features.

Trademarks

Lucent, the Lucent logo, and all Lucent brand and product names are trademarks or registered trademarks of Lucent Technologies Inc. Other brand and product names are trademarks of their respective holders.

Ordering Information

You can order the most up-to-date product information and computer-based training online at http://www.lucentdocs.com/bookstore.

How to comment

To comment on this information product, go to the Online Comment Form (http://www.lucent-info.com/comments/enus/) or email your comments to the Comments Hotline (comments@lucent.com).

Lucent Technologies

Customer Service

Product and service information, and software upgrades, are available 24 hours a day. Technical assistance options accommodate varying levels of urgency.

Finding information and software

To obtain software upgrades, release notes, and addenda for this product, log in to Lucent OnLine Customer Support at http://www.lucent.com/support.

Lucent OnLine Customer Support also provides technical information, product information, and descriptions of available services. The center is open 24 hours a day, seven days a week. Log in and select a service.

Obtaining technical assistance

Lucent OnLine Customer Support at http://www.lucent.com/support provides easy access to technical support. You can obtain technical assistance through email or the Internet, or by telephone. If you need assistance, make sure that you have the following information available:

Customer Service



Active service or maintenance contract number, entitlement ID, or site ID



Product name, model, and serial number



Software version or release number



Software and hardware options



If supplied by your carrier, service profile identifiers (SPIDs) associated with your line



Whether you are routing or bridging with your Lucent product



Type of computer you are using



Description of the problem

Obtaining assistance through email or the Internet

If your services agreement allows, you can communicate directly with a technical

engineer through Email Technical Support or a Live Chat. Select one of these sites when you log in to http://www.lucent.com/support.

Calling the technical assistance center (TAC)

If you cannot find an answer through the tools and information of Customer Support OnLine Customer Support for a list of telephone numbers inside and outside the United States.

or if you have a very urgent need, contact TAC. Access

http://www.lucent.com/support

Lucent OnLine

and click

Lucent

Alternatively, call 1-866-LUCENT8 (1-866-582-3688) from any location in North America for a menu of Lucent services. Or call +1 510-747-2000 for an operator. If you do not have an active services agreement or contract, you will be charged for time and materials.

Stinger® Administration Guide iii

Contents

Customer Service ........................................................................................................iii

About This Guide ..............................................................................xix

What is in this guide .................................................................................................xix

What you should know.............................................................................................xix

Documentation conventions ......................................................................................xx

Stinger documentation set ........................................................................................xxi

Chapter 1 Administering a Stinger System ......................................................1-1

About standalone and hosted Stinger systems ......................................................... 1-1

Logging into a Stinger unit....................................................................................... 1-2

Enabling basic security measures ............................................................................. 1-2

Changing the default Admin password ............................................................... 1-3

Securing the serial port of each control module................................................ 1-3

Specifying a management-only Ethernet interface ........................................... 1-4

Securing Telnet access ....................................................................................... 1-5

Managing administrative access to the unit ............................................................. 1-5

Logging into the Stinger unit ............................................................................. 1-6

Creating a new administrative profile ............................................................... 1-6

Enabling two level authentication ..................................................................... 1-7

Specifying the maximum number of login attempts ....................................... 1-11

Authentication from a remote shelf to a host Stinger unit.............................. 1-11

User account and user password expiration .................................................... 1-12

What happens when a user account or user password expires ................ 1-12

RADIUS support for account and password expiration ............................ 1-12

Setting expiration dates for user accounts and passwords ........................ 1-13

Enforcing a password check ...................................................................... 1-14

Changing a user password......................................................................... 1-14

Creating Telnet access control lists .................................................................. 1-15

Assigning permissions ...................................................................................... 1-16

Understanding command permissions ...................................................... 1-17

Specifying group permissions for commands and profile access ............... 1-19

Specifying a time-out for user logins ............................................................... 1-24

Setting the command-line prompt .................................................................. 1-24

Setting log levels for each login ....................................................................... 1-24

Logging in as a different user ........................................................................... 1-25

Displaying the current user ............................................................................. 1-25

Basic system settings .............................................................................................. 1-25

Setting the system name.................................................................................. 1-25

Setting the system time and date..................................................................... 1-26

Stinger® Administration Guide v

Contents

Viewing the system time and date ............................................................ 1-26

Changing the system time ......................................................................... 1-26

Changing the system date ......................................................................... 1-26

Configuring system clocking ............................................................................ 1-27

Displaying the current clock-source.......................................................... 1-27

Configuring trunk ports as clock sources .................................................. 1-27

Displaying basic system information ...................................................................... 1-28

Displaying system hardware information and software version ..................... 1-28

System and module uptime ............................................................................. 1-29

Using the status window.................................................................................. 1-30

Displaying the status window ................................................................... 1-30

Understanding the status window ............................................................ 1-31

Connection status information.................................................................. 1-31

General status information........................................................................ 1-32

Line and channel status ................................................................................... 1-32

Log message information .......................................................................... 1-33

Customizing the status window display .................................................... 1-34

Changing current status window sizes...................................................... 1-34

Viewing the factory configuration and software licenses ................................ 1-35

Managing administrative connections ................................................................... 1-35

Displaying administrative session information with the userstat command ... 1-35

Customizing the output of the userstat command.................................. 1-36

Displaying information related to a known IP address ............................. 1-36

Displaying information related to a known username.............................. 1-37

Using the view left session command ......................................................... 1-37

Displaying administrative users ....................................................................... 1-38

Terminating a user connection ........................................................................ 1-38

Disconnecting an idle connection .................................................................... 1-38

Resetting a Stinger system...................................................................................... 1-39

Chapter 2 Working with Stinger Shelves and Modules ..................................2-1

Understanding physical addressing on Stinger units................................................ 2-1

Viewing system components .................................................................................... 2-3

Using the show command................................................................................... 2-3

Field description from the output of the show command ............................ 2-4

Displaying the status of LPMs, PSMs, and CLT modules............................. 2-4

Monitoring the status of remote shelves ........................................................... 2-5

Using the remote-shelf-stat profile .......................................................... 2-5

Displaying information about enabled remote shelves ............................... 2-7

Displaying hosted MRT system topology and statistics ............................... 2-7

Displaying a picture of the topology............................................................ 2-8

Sending an init packet to a remote shelf................................................... 2-11

Viewing information about a particular module ............................................. 2-11

Using the show command with the shelf and slot numbers ...................... 2-11

Using the slot-info profile....................................................................... 2-12

Opening a session with a module .......................................................................... 2-12

Sample open commands................................................................................... 2-13

Opening a session ...................................................................................... 2-13

Ending a session ........................................................................................ 2-13

Module-level commands ................................................................................. 2-13

Changing a module’s state ..................................................................................... 2-14

vi Stinger® Administration Guide

Contents

Using the slot command................................................................................. 2-14

Using slot-admin profiles ................................................................................ 2-14

Changing the state of a module’s interface ............................................................ 2-15

Using the device command ............................................................................. 2-15

Using the device-state profile........................................................................ 2-16

Removing a module and its configuration ............................................................. 2-17

Removing LIMs that use system-generated ATM addresses............................ 2-17

Replacing a LIM and retaining the existing ATM addresses on the slot .......... 2-17

Moving a LIM that uses system-generated ATM addresses ............................. 2-18

Recovering from a failed module installation ........................................................ 2-18

Using the nvram command ............................................................................... 2-18

Removing the module ..................................................................................... 2-19

Chapter 3 Configuring logging, Syslog, and call logging services .................3-1

Configuring system logging and Syslog services ...................................................... 3-1

Overview of log profile parameters ................................................................... 3-1

Configuring system logging ............................................................................... 3-4

Enabling command logging ............................................................................... 3-4

Viewing command logs ............................................................................... 3-5

Viewing the cmd-log profile ........................................................................ 3-6

Saving command logs.................................................................................. 3-7

Storing log messages across system resets ................................................... 3-7

Configuring the Stinger unit Syslog facility .................................................... 3-10

Enabling the Syslog facility on the Stinger unit ........................................ 3-11

Specifying a session ID base ...................................................................... 3-12

Configuring the Syslog daemon ................................................................ 3-12

Configuring call logging ......................................................................................... 3-12

Overview of call logging .................................................................................. 3-12

Enabling call logging ........................................................................................ 3-13

Chapter 4 Monitoring System and Network Processor operations................4-1

Maintaining ASIC Integrity ...................................................................................... 4-1

Checking the defaults for control module self-tests .......................................... 4-1

Enabling centralized integrity checks ................................................................ 4-4

Optimizing system performance .............................................................................. 4-4

Optimizing performance with filters and flow classification ............................. 4-5

Overview of system profile settings............................................................. 4-5

Configuration recommendations ................................................................ 4-6

Adjusting network processor FPP memory compaction .................................... 4-6

Configuring queue size from controller to LIM ................................................. 4-7

Monitoring network processor operations ............................................................... 4-7

Monitoring network processor operations on the IP2000 module.................... 4-7

Enabling and disabling statistics collection.................................................. 4-8

Monitoring IP QoS ...................................................................................... 4-8

Monitoring statistics for a connection ....................................................... 4-11

Monitoring FPP statistics ........................................................................... 4-12

Global RSP statistics................................................................................... 4-13

Monitoring logical port traffic ................................................................... 4-13

Scheduler traffic and error statistics .......................................................... 4-15

Displaying APP driver statistics ................................................................. 4-15

Monitoring network operations on the the Fast Ethernet Trunk module ...... 4-15

Stinger® Administration Guide vii

Contents

Enabling, disabling, and clearing statistics collection ................................ 4-16

Displaying Ethernet traffic and error statistics and traffic rates ................ 4-17

Displaying ATM statistics—Fast Ethernet Trunk module.......................... 4-19

Obtaining AAL5 statistics .......................................................................... 4-20

Chapter 5 Monitoring Interfaces on LIMs and Trunk Modules.......................5-1

Where to find related information ........................................................................... 5-1

Summary of profiles and commands for monitoring interfaces............................... 5-2

Using profiles to monitor LIM and trunk interfaces................................................. 5-3

Monitoring trunk module interfaces ................................................................. 5-3

Monitoring LIM interfaces ................................................................................. 5-4

Displaying interface information.............................................................................. 5-6

Displaying trunk port status .............................................................................. 5-7

Resetting trunk statistics .................................................................................... 5-8

Displaying LIM interfaces .................................................................................. 5-8

Displaying ADSL LIM interfaces.................................................................. 5-8

Displaying T1 and E1 interfaces ................................................................ 5-10

Displaying IMAgroups ..................................................................................... 5-10

Testing IMA connectivity ................................................................................. 5-10

Displaying DSL performance settings..................................................................... 5-10

Displaying the current time ............................................................................. 5-11

Displaying ADSL physical entries .................................................................... 5-11

Displaying channel entries............................................................................... 5-11

Displaying interval statistics for disruption of service events .......................... 5-12

Displaying interval totals for ADSL block counts ............................................ 5-12

Displaying disruption of service statistics......................................................... 5-12

Displaying ADSL block counts ......................................................................... 5-13

Displaying performance data interval.............................................................. 5-14

Displaying channel performance intervals ...................................................... 5-15

Displaying monitor parameters ....................................................................... 5-16

Displaying time and interval information........................................................ 5-16

Displaying initialization failure statistics.......................................................... 5-16

Monitoring LIM and LIM port redundancy ........................................................... 5-17

Overview of port redundancy parameters ....................................................... 5-17

Verifying port redundancy status .................................................................... 5-18

Verifying slot configuration redundancy status ............................................... 5-18

Displaying redundancy or ignore-lineup settings for LIM ports...................... 5-19

Monitoring redundant trunk groups...................................................................... 5-20

Chapter 6 Managing System Configuration and Memory..............................6-1

Saving system configuration .................................................................................... 6-1

Saving the configuration to a local file .............................................................. 6-2

Saving the configuration to a network host ...................................................... 6-2

Saving the configuration in GZIP compressed format ....................................... 6-2

Displaying NVRAM usage statistics .......................................................................... 6-2

Clearing system configuration.................................................................................. 6-3

Retaining configuration information after clearing NVRAM ................................... 6-3

How it works ..................................................................................................... 6-3

Loading a default.cfg file from the TFTP server .............................................. 6-4

Verifying that the default.cfg is saved to the desired directories .................... 6-4

Issuing the nvram command on a system with a default.cfg file..................... 6-5

viii Stinger® Administration Guide

Contents

Restoring or updating system configuration ............................................................ 6-6

Restoring from a local file .................................................................................. 6-6

Restoring from a network host .......................................................................... 6-6

Updating the configuration................................................................................ 6-6

Transferring code images between control modules ................................................ 6-7

Using FTP to transfer files......................................................................................... 6-9

FTP client command-line interface .................................................................... 6-9

Typical command-line FTP file transfer ............................................................. 6-9

FTP client URL interface .................................................................................. 6-10

Username and password details ................................................................ 6-11

URL path details ........................................................................................ 6-11

Typical FTP URLs ............................................................................................. 6-11

Sample FTP URL with complete syntax .................................................... 6-11

Sample FTP URL with no URL path or local directory .............................. 6-12

Sample FTP URL with no username or password ..................................... 6-12

Sample FTP URL by specifying a source IP Address .................................. 6-12

Using extended profiling ........................................................................................ 6-13

Requirements and limitations.......................................................................... 6-13

Enabling extended profiling............................................................................. 6-13

Restoring an earlier configuration after enabling extended profiling.............. 6-13

Using a script to configure a Stinger unit ............................................................... 6-14

Timing the saving of profiles .................................................................................. 6-15

Reloading profiles from RADIUS............................................................................ 6-15

Loading specific module images ............................................................................. 6-15

Using the load-select profile.......................................................................... 6-16

Loading images for unknown modules ........................................................... 6-16

Loading an extracted code image .................................................................... 6-17

Using the load configuration command with an ATM VCC ......................... 6-17

Managing PCMCIA flash cards ............................................................................... 6-17

Formatting a flash card .................................................................................... 6-18

Displaying the contents of flash ....................................................................... 6-18

Compressing and uncompressing files on a flash card..................................... 6-18

Checking the file system .................................................................................. 6-19

Chapter 7 Administering the SNMP Agent.......................................................7-1

Overview of Stinger SNMP support ......................................................................... 7-1

Stinger unit as an SNMP agent .......................................................................... 7-1

Requirement for a soft IP address ...................................................................... 7-2

Overview of the snmp profile .................................................................................... 7-2

Activating the SNMP agent ...................................................................................... 7-3

Securing the SNMP agent ........................................................................................ 7-4

Enabling read-write access and setting community strings ............................... 7-4

Configuring host address security...................................................................... 7-4

Enabling host address security .................................................................... 7-4

Configuring the snmp-manager profile ......................................................... 7-5

Example of configuring host address security ............................................. 7-6

Configuring SNMPv3 USM privacy ................................................................... 7-6

Verifying the SNMPv3 license is enabled .................................................... 7-6

SNMPv3 USM features ................................................................................ 7-6

Enabling SNMPv3 USM privacy .................................................................. 7-7

Using the snmpv3-usm-user profile.............................................................. 7-7

Stinger® Administration Guide ix

Contents

Generating authentication keys .................................................................. 7-9

Generating privacy keys .............................................................................. 7-9

Example of SNMPv3 USM configuration .................................................. 7-10

Restricting the agent to SNMPv3 .............................................................. 7-10

SNMPv3 notifications ................................................................................ 7-11

Configuring view-based access control ............................................................ 7-13

Enabling VACM......................................................................................... 7-14

Mapping a security name and security model to a security group............ 7-14

Specifying view names for different types of access .................................. 7-15

Defining views........................................................................................... 7-16

Managing SNMP interfaces .................................................................................... 7-17

Verifying SNMP state ....................................................................................... 7-18

Using the admin-state-perm-if profile..................................................... 7-18

Using the admin-state-phys-if profile..................................................... 7-19

Viewing SNMP interface numbers ................................................................... 7-21

Initiating interface state changes ..................................................................... 7-21

Resetting the SNMP interface table sequentially ............................................. 7-22

Naming convention for SNMP-configured profiles ................................................ 7-22

Default naming convention ............................................................................. 7-22

Configurable naming convention .................................................................... 7-23

Selecting the naming convention for connection profiles............................... 7-23

Chapter 8 Watchdogs, Alarms, and Traps ........................................................8-1

Configuring SNMP watchdogs ................................................................................. 8-1

Settings in a watchdog-config profile ................................................................ 8-3

Enabling a watchdog to monitor fan failure...................................................... 8-3

Watchdog routines for input relays ................................................................... 8-4

Watchdog routines for a remote shelves ........................................................... 8-4

Defining alarms ........................................................................................................ 8-4

Overview of alarm profile settings ..................................................................... 8-5

Sample alarm profile configuration .................................................................. 8-7

Working with alarms ......................................................................................... 8-7

Listing alarms using the alarm command.................................................... 8-7

Using the alarm-stat profile ....................................................................... 8-8

Acknowledging alarms ................................................................................ 8-9

Clearing alarms ........................................................................................... 8-9

Turning off an alarm status light ................................................................. 8-9

Closing a relay ............................................................................................. 8-9

Setting alarms for events on remote shelves ..................................................... 8-9

Monitoring environmental conditions ............................................................ 8-12

Configuring alarm settings for the alarm MIB................................................. 8-12

Setting the maximum number of alarms in alarmClearTable ..........8-13

Clearing alarms from alarmActiveTable and alarmClearedTable ......8-13

Deleting an alarm model table .................................................................. 8-13

Configuring SNMP traps......................................................................................... 8-13

Creating a trap profile ...................................................................................... 8-13

Configuring the trap profile ............................................................................ 8-14

Trap classes ...................................................................................................... 8-15

Alarm class traps ....................................................................................... 8-15

Security class traps .................................................................................... 8-18

Port class trap ............................................................................................ 8-19

x Stinger® Administration Guide

Contents

Slot class trap............................................................................................. 8-19

OSPF class traps......................................................................................... 8-20

Typical uses of traps and trap classes......................................................... 8-22

Traps not belonging to any class ............................................................... 8-23

Monitoring ADSL threshold values ................................................................. 8-23

Specifying the dsl-threshold profile ........................................................ 8-24

Overview of the dsl-threshold profile settings ........................................ 8-24

Lucent-specific ADSL threshold traps ....................................................... 8-25

Enabling the system to generate ADSL threshold traps ............................ 8-26

How the system generates link-state traps for trunk ports .............................. 8-26

Configuring trap sequencing and heartbeat traps............................................ 8-28

Trap sequencing and the heartbeat trap.................................................... 8-28

Configuring trap sequencing and the sending of heartbeat traps ............. 8-29

Enabling traps for events on remote shelves ................................................... 8-30

Stinger trap optimization ................................................................................. 8-31

Optimizing the number of traps generated by the system ........................ 8-31

Trap optimization ...................................................................................... 8-32

Displaying information about notification logs ............................................... 8-32

Chapter 9 Working with IP Traffic ....................................................................9-1

Testing IP connectivity ............................................................................................. 9-1

Displaying the IP interface table............................................................................... 9-2

Displaying and modifying IP routes ......................................................................... 9-4

Using the netstat command to display the IP routing table ............................. 9-4

Modifying the IP routing table........................................................................... 9-5

Adding a static IP route to the routing table ............................................... 9-5

Deleting a static IP route from the routing table ......................................... 9-5

Tracing IP routes ...................................................................................................... 9-6

Displaying IP protocol statistics ................................................................................ 9-6

Displaying IP route cache information..................................................................... 9-9

Verifying name service settings ................................................................................ 9-9

Displaying the ARP cache....................................................................................... 9-10

Displaying the DNS host table ................................................................................ 9-11

Displaying the Ethernet information ..................................................................... 9-11

Displaying the contents of Ethernet packets.................................................... 9-12

Displaying Ethernet statistics and error counters ............................................ 9-12

Displaying information about IGMP ...................................................................... 9-13

Displaying WAN IP interface information.............................................................. 9-15

Displaying packets on WAN IP interfaces ........................................................ 9-15

Displaying WAN data for a particular user ...................................................... 9-16

Displaying WAN data during connection establishment for users .................. 9-16

Chapter 10 Monitoring OSPF routing ...............................................................10-1

Overview of the OSPF command ........................................................................... 10-1

Displaying general information about OSPF routing ............................................. 10-2

Displaying the OSPF database ................................................................................ 10-4

Displaying OSPF external advertisements ....................................................... 10-6

Displaying OSPF internal advertisements ........................................................ 10-7

Displaying the OSPF link-state database ................................................................ 10-7

Displaying OSPF LSAs ............................................................................................ 10-9

Displaying the OSPF routing table ....................................................................... 10-10

Stinger® Administration Guide xi

Contents

Displaying information about OSPF areas............................................................ 10-11

Displaying information about OSPF routers ........................................................ 10-11

Displaying OSPF interfaces................................................................................... 10-12

Displaying summarized information.............................................................. 10-12

Displaying information about a specific interface.......................................... 10-13

Displaying OSPF neighbors .................................................................................. 10-14

Chapter 11 Monitoring ATM and PNNI.............................................................11-1

Monitoring ATM networks .................................................................................... 11-1

Using the ATM status window......................................................................... 11-2

Determining ATM line status........................................................................... 11-3

Displaying the status of ATM internal lines..................................................... 11-4

Changing ATM debug levels ............................................................................ 11-4

Displaying the status of ATM trunk modules and their connections .............. 11-5

Checking the status of a VCC interface........................................................... 11-5

Checking the status of a terminating PVC ....................................................... 11-6

Displaying ATM VCC information and packet statistics .................................. 11-6

Displaying ATM virtual link information ........................................................ 11-7

Displaying ATM virtual link cross-connect information................................ 11-10

Displaying SPVC information ........................................................................ 11-11

Displaying SPVC target ATM addresses ......................................................... 11-13

Monitoring failing SPVCs............................................................................... 11-14

Displaying signal statistics .............................................................................. 11-14

Displaying CAC bandwidth allocation statistics............................................. 11-15

Displaying ATM connection failures .............................................................. 11-17

Displaying QoS statistics ................................................................................ 11-18

Monitoring PNNI nodes ....................................................................................... 11-18

Verifying the PNNI link.................................................................................. 11-19

Displaying general PNNI information ............................................................ 11-20

Displaying PNNI interface information......................................................... 11-21

Displaying information about PNNI logical links........................................... 11-22

Displaying information about the PNNI hierarchy ........................................ 11-24

Displaying details about neighbor nodes ....................................................... 11-27

Displaying local node information................................................................. 11-28

Displaying information about other nodes .................................................... 11-30

Displaying the PNNI topology database ......................................................... 11-32

Displaying the PNNI routing table ................................................................. 11-33

Chapter 12 Diagnostic Testing ..........................................................................12-1

OAM testing ........................................................................................................... 12-1

Overview of F4 and F5 OAM tests................................................................... 12-1

Using the oam command and atm-oam profile to run OAM tests...................... 12-2

Overview of the oam command ................................................................. 12-3

Overview of the atm-oam profile................................................................ 12-4

Enabling F4 OAM on a LIM ...................................................................... 12-7

Continuity check and monitoring ................................................................... 12-9

Continuity check implementation ............................................................ 12-9

Deactivating a continuity check test ....................................................... 12-10

Running F4 and F5 continuity tests using the oam command................. 12-11

Running F5 continuity tests using the atm-oam profile ........................... 12-12

OAM loopback tests ....................................................................................... 12-12

xii Stinger® Administration Guide

Contents

Running F4 and F5 loopback tests using the oam command ................... 12-12

Running F4 and F5 loopback tests using the atm-oam profile ................. 12-14

Specifying that a trap is sent ................................................................... 12-15

Using the oamloop command................................................................... 12-16

Configuring loopback on OC3, E3, and DS3 interfaces........................... 12-16

Displaying OAM entries................................................................................. 12-17

Fault reporting and alarms ............................................................................ 12-21

Traps for AIS/RDI and continuity check alarms ............................................ 12-22

Internal and external diagnostic tests .................................................................. 12-22

Running an internal diagnostic test (IDT) ..................................................... 12-22

Running an external diagnostic test (EDT) feature ....................................... 12-24

Digital loopback....................................................................................... 12-24

Analog loopback...................................................................................... 12-25

Running built-in self tests (BISTs) on DSL ports ........................................... 12-25

Supported LIMs ....................................................................................... 12-25

Enabling the built-in self test using the command-line interface ........... 12-25

Relay alarm testing............................................................................................... 12-26

Overview of the inputrelaytest command.................................................. 12-26

Examples using the inputrelaytest command............................................. 12-27

Displaying the status of input relays.............................................................. 12-29

Configuring a bit-error rate test (BERT) .............................................................. 12-29

Testing DSL copper loops ..................................................................................... 12-30

Using the line-tests profile ......................................................................... 12-30

Galvanic isolation test .................................................................................... 12-31

Using the line-tests profile ................................................................... 12-31

Using the isolate command................................................................... 12-32

Multiport tone generation test....................................................................... 12-33

Using the line-tests profile ................................................................... 12-33

Using the gen-tone command................................................................. 12-33

Appendix A Using Debug Commands .................................................................A-1

Enabling debug permissions .....................................................................................A-1

Enabling debug output .............................................................................................A-2

Setting debug levels..................................................................................................A-2

Getting online help for debug commands ................................................................A-2

Summary of common debug commands .................................................................A-3

System and devices debugging.................................................................................A-3

Displaying IP2000 module network processor information ........................A-4

Displaying network processor connection information ..............................A-5

Obtaining information about routes on the network processor .................A-6

Obtaining detailed information for a DID ...................................................A-7

Displaying ARP entries ................................................................................A-8

Displaying SED parameters for a DID .........................................................A-8

Displaying multicast group information......................................................A-8

Displaying IP QoS details.............................................................................A-8

Displaying bridge group information ..........................................................A-9

Displaying scheduler IDs associated with a logical port ............................A-10

Displaying information for a specific queue..............................................A-11

Displaying details for a specific scheduler .................................................A-11

Displaying Fast Ethernet trunk protocol and connection information............A-11

Displaying connection information ...........................................................A-12

Displaying ATM information.....................................................................A-13

Stinger® Administration Guide xiii

Contents

Displaying AAL5 channel information......................................................A-14

Displaying Ethernet device information....................................................A-14

Displaying Stinger port information ................................................................A-16

Resetting TCP port 23 ......................................................................................A-16

Displaying the serial numbers..........................................................................A-17

Modifying Stinger unit functionality ...............................................................A-17

RADIUS debugging.................................................................................................A-17

Using the acct-failsafe debug command......................................................A-18

Verifying settings in the external-auth profile ...............................................A-18

Displaying RADIUS accounting session status .................................................A-19

Displaying RADIUS authentication and accounting statistics..........................A-20

Interface debugging ................................................................................................A-21

Displaying network interface mappings ..........................................................A-21

Using the EOC command on ADSL interfaces .................................................A-22

Control module debugging.....................................................................................A-23

Displaying the status of redundant control modules .......................................A-23

Displaying interface management information ...............................................A-24

Appendix B Stinger Log Messages...................................................................... B-1

Fatal and warning error messages............................................................................B-1

Reviewing the fatal error log ............................................................................. B-1

Clearing the fatal error log................................................................................. B-2

Definitions of fatal errors .........................................................................................B-2

Definitions of warning messages .............................................................................. B-4

Fatal crash information on the console.................................................................... B-7

Syslog messages........................................................................................................B-7

PCMCIA flash card error messages........................................................................... B-8

load command messages ................................................................................... B-9

format command messages.............................................................................. B-10

dircode command messages............................................................................B-10

Index .......................................................................................... Index-1

xiv Stinger® Administration Guide

Figures

Figure Sample contents of a status window 1-31 Figure Front panel of a Stinger FS unit 2-2 Figure Status window for ATM VCCs 11-3 Figure Data passing through a modem’s digital circuitry 12-25 Figure Data passing through a modem’s digital and analog circuitry 12-25

Stinger® Administration Guide xv

Tables

Table 1-1 Permissions and associated commands ........................................... 1-18

Table 1-2 .Message levels ................................................................................ 1-25

Table 2-1 How TAOS organizes Stinger module functions ............................... 2-2

Table 2-2 Description of Reqd, Oper, and Slot Type fields................................ 2-4

Table 2-3 Statistics displayed for a remote shelf ............................................... 2-9

Table 2-4 Statistics displayed for the host shelf............................................... 2-10

Table 2-5 Statistics displayed in an open session on the remote shelf ............ 2-10

Table 4-1 Sample call performance statistics with different values of

np-update-time............................................. 4-6

Table 5-1 Where to find additional information ............................................... 5-1

Table 5-2 Summary of profiles and commands for monitoring interfaces........ 5-2

Table 5-3 Field descriptions for status commands............................................. 5-6

Table 7-1 SNMP parameters and associated tasks............................................. 7-2

Table 8-1 Hosted MRT alarm events ............................................................... 8-10

Table 8-2 Compact Remote alarm events ....................................................... 8-10

Table 8-3 Parameters that enable or disable traps in the alarm class.............. 8-15

Table 8-4 Parameters that enable or disable traps in the security class .......... 8-18

Table 8-5 Parameter that enables or disables traps in the port-state class ...... 8-19

Table 8-6 Parameter that enables or disables traps in the slot class ................ 8-20

Table 8-7 Parameters that enable or disable traps in the OSPF class .............. 8-20

Table 8-8 Lucent-specific ADSL threshold traps ............................................. 8-25

Table 8-9 ADSL threshold traps and required settings in the trap profile...... 8-26

Table 8-10 Description of fields for the output of the nlmstat command ........ 8-33

Table 8-11 Additional fields reported by the nlmstat Ipaddress command .... 8-34

Table 11-1 Profiles and commands for monitoring ATM networks .................. 11-1

Table 11-2 Commands and profiles for monitoring PNNI operations............. 11-19

Table 12-1 Direction specified by the remote peer and the results ................. 12-10

Table A-1 Commonly used debug commands ................................................... A-3

Table B-1 Load command error messages (loading a tar file) ........................... B-9

Table B-2 Load command error messages (uploading to PCMCIA flash cards) B-9

Table B-3 Format command error messages ................................................... B-10

Table B-4 Dircode command error messages .................................................. B-10

Stinger® Administration Guide xvii

About This Guide

This guide explains how to administer a Stinger unit and manage its operations. To use this guide, you must have set up the Stinger system as described in the Getting Started Guide for your Stinger unit and configured it for network connectivity as described in the Stinger ATM Configuration Guide.

What is in this guide

Each chapter in this guide focuses on a particular aspect of Stinger unit administration and operations. The chapters describe tools for system management, network management, and SNMP agent management.

To perform many of the tasks in this manual, you must have administrative permission on the Stinger unit. For instructions on logging into the Stinger unit with administrative permissions, see “Logging into a Stinger unit” on page 1-2.

Note This manual describes the set of features for Stinger units running software

version TAOS 9.7.0. Some features might not be available with earlier versions or specialty loads of the software.

Warning Before installing or operating your Stinger unit, be sure to read the safety

instructions in the Edge Access and Broadband Access Safety and Compliance Guide. For information specific to your unit, see the “Safety-Related Electrical, Physical, and Environmental Information” appendix in your unit’s Getting Started Guides.

What you should know

This guide attempts to provide enough information to enable an administrator who is not an expert in a particular network technology to operate and troubleshoot a Stinger unit. However, this guide does not provide a complete explanation of any network management topic. For best results, when working with the following capabilities on a Stinger unit, make sure that you have some applicable general knowledge:



Line configuration and testing



Connection negotiation and authentication



Connection cost management and accounting



IP routing



Network security

Stinger® Administration Guide xix

About This Guide

Documentation conventions

Following are all the special characters and typographical conventions used in this manual:

Convention Meaning

Monospace text Represents text that appears on your computer’s screen, or that

could appear on your computer’s screen.

Boldface monospace text

Italics Represent variable information. Do not enter the words

[ ] Square brackets indicate an optional argument you might add

| Separates command choices that are mutually exclusive.

> Points to the next level in the path to a parameter or menu

Key1+Key2 Represents a combination keystroke. To enter a combination

Press Enter Means press the Enter or Return key or its equivalent on your

Represents characters that you enter exactly as shown (unless the characters are also in italics—see Italics, below). If you could enter the characters but are not specifically instructed to, they do not appear in boldface.

themselves in the command. Enter the information they represent. In ordinary text, italics are used for titles of publications, for some terms that would otherwise be in quotation marks, and to show emphasis.

to a command. To include such an argument, type only the information inside the brackets. Do not type the brackets unless they appear in boldface.

item. The item that follows the angle bracket is one of the options that appear when you select the item that precedes the angle bracket.

keystroke, press the first key and hold it down while you press one or more other keys. Release all the keys at the same time. (For example, Ctrl+H means hold down the Ctrl key and press the H key.)

computer.

Introduces important additional information.

Note

Warns that a failure to follow the recommended procedure

Caution

Warning

xx Stinger® Administration Guide

could result in loss of data or damage to equipment.

Warns that a failure to take appropriate safety precautions could result in physical injury.

Warns of danger of electric shock.

Stinger documentation set

The Stinger documentation set consists of the following manuals, which can be found at http://www.lucent.com/support and http://www.lucentdocs.com/ins.



Read me first:

– Edge Access and Broadband Access Safety and Compliance Guide. Contains

important safety instructions and country-specific information that you must

read before installing a Stinger unit.

– TAOS Command-Line Interface Guide. Introduces the TAOS command-line

environment and shows you how to use the command-line interface

effectively. This guide describes keyboard shortcuts and introduces

commands, security levels, profile structure, and parameter types.



Installation and basic configuration:

– Getting Started Guide for your Stinger platform. Shows how to install your

Stinger chassis and hardware. This guide also shows you how to use the

command-line interface to configure and verify IP access and basic access

security on the unit, and how to configure Stinger control module

redundancy on units that support it.

About This Guide

Stinger documentation set

– Module guides. For each Stinger line interface module (LIM), trunk module,

or other type of module, an individual guide describes the module's features

and provides instructions for configuring the module and verifying its status.



Configuration:

– Stinger Compact Remote Installation and Configuration Guide. Provides an

overview of the Stinger Compact Remote and provides instructions for the

installation and replacement of its components. This guide also describes how

to configure and manage the Compact Remote as a hosted unit

– Stinger ATM Configuration Guide. Describes how to integrate the Stinger into

the ATM and Digital Subscriber Line (DSL) access infrastructure. The guide

explains how to configure PVCs, and shows how to use standard ATM

features such as quality of service (QoS), connection admission control

(CAC), and subtending.

– Stinger IP2000 Configuration Guide. For Stinger systems with the IP2000

control module, this guide describes how to integrate the system into the IP

infrastructure. Topics include IP-routed switch-through ATM PVCs and RFC

1483 PVCs that terminate on the IP2000, IEEE 802.1Q VLAN, and

forwarding multicast video transmissions on DSL interfaces.

– Stinger Private Network-to-Network Interface (PNNI) Supplement. For the optional

PNNI software, this guide provides quick-start instructions for configuring

PNNI and soft PVCs (SPVCs), and describes the related profiles and

commands.

– Stinger SNMP Management of the ATM Stack Supplement. Describes SNMP

management of ATM ports, interfaces, and connections on a Stinger unit to

provide guidelines for configuring and managing ATM circuits through any

SNMP management utility.

– Stinger T1000 Module Routing and Tunneling Supplement. For the optional T1000

module, this guide describes how to configure the Layer 3 routing and virtual

private network (VPN) capabilities.

Stinger® Administration Guide xxi

About This Guide

Stinger documentation set



RADIUS: TAOS RADIUS Guide and Reference. Describes how to set up a unit to use the Remote Authentication Dial-In User Service (RADIUS) server and contains a complete reference to RADIUS attributes.



Administration and troubleshooting: Stinger Administration Guide (this guide). Describes how to administer the Stinger unit and manage its operations. Each chapter focuses on a particular aspect of Stinger administration and operations. The chapters describe tools for system management, network management, and Simple Network Management Protocol (SNMP) management.



Reference:

– Stinger Reference. An alphabetic reference to Stinger profiles, parameters, and

– TAOS Glossary. Defines terms used in documentation for Stinger units.

commands.

xxii Stinger® Administration Guide

Administering a Stinger System

About standalone and hosted Stinger systems . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

Logging into a Stinger unit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Enabling basic security measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

Managing administrative access to the unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

Basic system settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-25

Displaying basic system information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-28

Managing administrative connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-35

Resetting a Stinger system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-39

This chapter describes the system administration tasks that you might perform on the Stinger unit, such as enabling basic security, configuring and managing administrative access to a system, configuring and displaying basic system settings, and managing user connections.

To use this chapter, you must have performed the tasks described in the Getting Started Guide for your unit and the Stinger ATM Configuration Guide. You can obtain

Stinger manuals at http://www.lucent.com/support.

Note On a Stinger MRT device, control module and line interface module (LIM)

functions are incorporated into the unit’s chassis. The terms control module and LIM in this guide refer to the control module and the LIM port functions on a Stinger MRT and not to physical modules.

About standalone and hosted Stinger systems

In this document, a Stinger FS, Stinger FS+, Stinger LS, Stinger RT, Stinger MS+ or Stinger MRT unit that does not provide host functions to other Stinger units is referred to as a standalone unit.

You can provision and manage up to five cascaded Stinger MRT units as a single hosted system, with a single management interface. Only one of the Stinger MRT units supports ATM trunk interfaces, and that unit must be the controlling unit (the host) for the hosted system. The other cascaded units (remote shelves) are included in the hosted system topology by enabling the remote shelf through a profile for that shelf ID. For more information about the hosted operations of Stinger MRT units, see the Stinger MRT Getting Started Guide for your unit.

Stinger® Administration Guide 1-1

Administering a Stinger System

Logging into a Stinger unit

Stinger FS+, Stinger LS, and Stinger RT units with revision 2.0, revision 2.1, and IP2000 control modules can also support host functions to Stinger Compact Remote units. The Stinger Compact Remote unit is a small temperature-hardened unit that extends the reach of host Stinger units located in the central office. For more information about the hosted operations of a Compact Remote unit, see the Stinger Compact Remote Getting Started Guide.

On hosted systems, provisioning and management of the remote shelves is performed on the host. The look and feel of the host management interface is very similar to that of a standalone system, except that some commands require that you specify a shelf ID in the physical address of a slot or port, and the shelf ID is also displayed in the output of commands that previously showed only slot and port information. For more information about shelf, slot, and port addressing on Stinger systems, see “Understanding physical addressing on Stinger units” on page 2-1.

Logging into a Stinger unit

When you log into a Stinger unit, you actually connect to its control module. If the Stinger unit contains two control modules, you can connect to either control module.

Note On units with redundant control modules, only one control module is active at

a time. The secondary control module becomes the primary (active) control module if the primary control module can no longer support the Stinger unit. The unit transfers any configuration changes that you make on the primary control module to the secondary control module, except for changes to IP addresses. Each control module must have a unique IP address.

To administer the system, you can log in from a PC connected to the control module’s serial port, or from a workstation that has Telnet access to the system. When you log in, you are prompted for a username:

User:

To log in with administrative privileges, enter the default password (Ascend) assigned to the Stinger admin login at the factory:

User: admin Password: Ascend

The name specified in the name parameter of the admin user profile appears as your system prompt. For example:

admin>

If you are already connected to the Stinger unit as a different user, use the auth command to log in as the administrator:

admin> auth user Password:

For additional information about user profiles, see “Managing administrative access to the unit” on page 1-5.

Enabling basic security measures

The Stinger unit is shipped with certain default parameters set to allow easy access for the initial configuration. After you have initially logged in as administrator, ensure that the following three basic security tasks have been completed:

1-2 Stinger® Administration Guide



Change the default admin password.



Secure the serial port on both control modules.



Specify one of the Ethernet ports as a management-only port.

You can also manage administrative access to the Stinger unit by specifying the types of tasks administrative users can perform on the Stinger unit. See “Managing administrative access to the unit” on page 1-5.

If the Stinger unit will be configured for SNMP, see also “Securing the SNMP agent” on page 7-4.

Changing the default Admin password

Because the admin login has superuser privileges, you must change the default password immediately. Be sure to write down the password you assign and store it in a safe place.

To change the password for the admin login, proceed as follows:

admin> read user admin USER/admin read

admin> set password = top-secret

admin> write USER/admin written

Administering a Stinger System

Enabling basic security measures

All subsequent administrator logins are required to supply the new password. (For more information about configuring user profiles, see “Managing administrative access to the unit” on page 1-5.)

Securing the serial port of each control module

The default settings for the control module allow anyone connecting to the serial port to access the system as the admin user, without logging in or being authenticated. Therefore, you must configure each control module to request a username and password and to automatically log the user out when the terminal session is terminated.

To secure the serial port on a single or primary control module, proceed as follows:

1 Read the serial profile of the primary (or single) control module:

admin> read serial {1 8 2}

The serial profile index refers to a physical port on the control module. The serial port is always designated as the second physical port of the control module.

2 Set the user-profile parameter to null:

admin> set user-profile =

3 Set the auto-logout parameter to yes:

admin> set auto-logout = yes

With this setting, the system automatically logs off the current user profile if the Data Terminal Ready (DTR) signal is lost on the serial port.

4 Write the profile:

admin> write

Stinger® Administration Guide 1-3

Administering a Stinger System

Enabling basic security measures

If your Stinger unit is operating with two control modules, both are working in parallel. As a result, the primary control module does not copy over this configuration to the secondary control module. You must secure both serial ports manually.

The following sample commands show how to secure the serial port on a secondary control module:

admin> read serial {1 9 2}

admin> set user-profile =

admin> set auto-logout = yes

admin> write

Now users connecting to a control module must supply a valid username and password for access to the Stinger unit.

Specifying a management-only Ethernet interface

You can specify that a control module’s Ethernet interface is for management only. Following is the relevant parameter, which is shown with its default setting:

[in IP-INTERFACE/{ { any-shelf any-slot 0 } 0 }] management-only-interface = no

Setting the management-only-interface parameter to yes means that incoming traffic on the interface terminates in the system itself and is not forwarded on any other interface. In addition, only traffic generated by the system is forwarded onto the management-only interface. Traffic generated externally is dropped by the interface.

To configure a management interface for each of the control modules, proceed as in the following example:

admin> read ip-int {{ 1 8 1 } 0} IP-INTERFACE/{ { shelf-1 slot-8 1 } 0 } read

admin> set management-only = yes

admin> write IP-INTERFACE/{ { shelf-1 slot-8 1 } 0 } written

admin> read ip-int {{ 1 9 1 } 0} IP-INTERFACE/{ { shelf-1 slot-9 1 } 0 } read

admin> set management-only = yes

admin> write IP-INTERFACE/{ { shelf-1 slot-9 1 } 0 } written

Verifying the Ethernet port status

You can view the Ethernet’s port status using the ifmgr command. For the system to respond to this command, your user profile must be enabled with debug privileges. For information on enabling debug privileges see “Enabling debug permissions” on page A-1.

To verify that an Ethernet interface has been set for management only, display the output of the ifmgr -d command, as shown in the following example:

admin> ifmgr -d bif slot sif u m p ifname host-name remote-addr local-addr

1-4 Stinger® Administration Guide

--------------------------------------------------------------------------000 1:09 000 * ie0 - 0.0.0.0/32 134.112.26.201/32 001 1:09 001 * ie1 - 0.0.0.0/32 0.0.0.0/32 002 1:09 002 * lo0 - 0.0.0.0/32 127.0.0.1/32 003 0:00 000 * rj0 - 0.0.0.0/32 127.0.0.2/32 004 0:00 000 * bh0 - 0.0.0.0/32 127.0.0.3/32 005 1:09 000 * wanabe - 0.0.0.0/32 127.0.0.3/32 006 0:00 000 * local - 0.0.0.0/32 127.0.0.1/32 007 0:00 000 * mcast - 0.0.0.0/32 224.0.0.0/32 008 0:00 000 - tunnel0 - 0.0.0.0/32 134.112.26.201/32 009 0:00 000 * vr0_main - 0.0.0.0/32 134.112.26.201/32 010 0:00 000 - sip0 - 0.0.0.0/32 0.0.0.0/32 011 1:05 006 * p wan11 bir-2-2 222.222.222.222/32 222.222.222.1/32

The u column displays an asterisk (*) to indicate that the interface is operational or a hyphen (-) to indicate that it is disabled.

Securing Telnet access

If the telnet-password parameter in the ip-global profile (without specifying a user-profile name), you can configure a Stinger system to support mild

authentication for telnet access. When a user attempts to access the system via telnet, the user must provide a password when prompted. After telnet authentication, the user goes through the terminal session authentication similar to authentication for console access.

Administering a Stinger System

Managing administrative access to the unit

User authentication can be internal or external based on system configuration. If the user-profile parameter in the ip-global profile is set with the name of a user profile, then the terminal session's user authentication is bypassed. To ensure that the user is authenticated for telnet access, the user-profile parameter should not be set to any user profile. See also, “Creating Telnet access control lists” on page 1-15 for more information about managing Telnet access to the system.

Managing administrative access to the unit

You create and define administrative access to the Stinger unit using user profiles. Do not confuse them with connection profiles. You configure user profiles to provide access to the Stinger command-line interface to monitor or configure the unit. In contrast, connection profiles contain authentication and configuration information for a remote device or user and allow the remote user to connect to the Stinger unit for WAN or LAN access.

You can create any number of user profiles and fine-tune the privileges they allow. In addition to authentication and permission information, user profiles also contain parameters that affect how the user’s environment appears at login.

A Stinger unit is shipped with the predefined user profiles admin and default. An admin user profile provides full read-write permissions, while the default user profile authorizes minimal use of commands.

Many sites choose to create some administrative accounts with read-only permissions, to allow certain users to check status windows, read log buffers, and enter diagnostic commands. You need at least one administrative account with readwrite permissions, but you might choose to create several read-only accounts.

Stinger® Administration Guide 1-5

Administering a Stinger System

Managing administrative access to the unit

For information about managing administrative sessions, see “Managing administrative connections” on page 1-35.

Logging into the Stinger unit

To log into the Stinger unit for administrative tasks, use a profile that has write permissions, as in the following example:

% telnet myStinger User: admin Password: mypassword

admin>

If you are already logged into the Stinger unit, make sure you are at the highest level by entering the list .. command (possibly more than once), as in the following example:

admin> list .. name = ““ physical-address* = { shelf-1 slot-1 1 } line-interface = { yes esf b8zs eligible middle-priority inband wink-start digi+

admin> list .. error: at highest level

Creating a new administrative profile

You use the new user command to create a new administrative profile. You must then activate and authenticate the new profile.

To creat e a new user profile based on the user profile admin, append admin to the new user command. The following example shows how to create a new user profile named test, with full administrative privileges:

admin> new user admin USER/admin read

admin> set name = test

admin> set password = test-pw

admin> write USER/admin written

To create a new user profile based on the user profile default, use the new user command with no additional arguments. The following example shows how to create a new user profile named test2, with default administrative privileges:

admin> new user USER/default read

admin> set name = test2

admin> set password = my-password

admin> write USER/test2 written

1-6 Stinger® Administration Guide

To activate a user profile, proceed as follows:

admin> read user test USER/test read

admin> set active-enabled = yes

admin> write USER/test2 written

If you are connected to the Stinger unit as a different user, use the auth command to log in as the administrator:

admin> auth user Password:

Enabling two level authentication

You can configure the system to require a second level of authentication for the following types of access to a Stinger unit or for any combination of the following:





Telnet access using system IP address



system console access

Administering a Stinger System

Managing administrative access to the unit



modem access



opening a session from a remote shelf to a host Stinger unit

By default, the system uses only single-level authentication.

If two-level authentication is enabled, at login, the system prompts the user to log in twice, each time with a different username and password.

Note After an NVRAM operation, the system defaults to a single level of

authentication.

To enable two-level authentication, you must perform the following tasks, in the following recommended order:

1 Create a second-level user profile and link it to a first level user profile.

2 Specify the type of access for which two-level authentication is required,

systemwide.

Note Before enabling two-level authentication for a system, make sure that you

have configured first-level and second-level user profiles for your system. If you configure the system to require two-level authentication without defining first-level and second-level user profiles, you might be unable to log into the system.

Settings in the user profile and comparable RADIUS attributes

To configure second-level authentication for a system, configure first and second level user profiles that define the user name and password for each login level. Then, specify a first-level profile for the second-level user profile.

You use the following parameters in the user profile to designate the login level for a user profile and to associate a first-level user profile with a second-level user profile. The comparable RADIUS attributes are also shown below.

Stinger® Administration Guide 1-7

Administering a Stinger System

Managing administrative access to the unit

Command-line interface parameter

RADIUS attribute Specifies

first-level-user Ascend-First-

Level-User

Ascend-User-LoginLevel

A user cannot use a first-level user profile name and password to login for the second level of authentication or use a second-level user profile name and password to login at the first level of authentication.

If you are configuring the system for RADIUS support, keep the following in mind:



If the rad-serv-enable and rad-auth-client parameters are enabled in the external-auth by selecting the appropriate setting for the cli-user-auth parameter in the external-auth profile. If the system is set for single-level authentication, the

system uses the RADIUS server for single level authentication. If the system is configured for two-level authentication, RADIUS authentication also requires two levels of authentication.



For all telnet user accounts, first and second level, the attribute Ascend-TelnetProfile must be set to a valid Stinger user profile.



For a second level user, the attribute Ascend-First-Level-User must specify a first-level user account.



The attributes Ascend-User-Login-Level and Ascend-First-Level-User must be set as part of the check list items in the telnet user account.

Name of a first-level user profile. The default setting is null. If possible, do not assign a first-level user profile to more than one second-level user profile.



first-level (the default)—This user profile is to be used for first level authentication.



second-level—This user profile is to be used for second level authentication. If the login-level parameter is set to second-level, you must specify the name of a valid first-level user profile for the first-level-user parameter.

profile, external authentication is supported by a RADIUS server

1-8 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

Settings in the system profile

To configure second-level authentication for a Stinger system, in the system profile, set the user-second-level-authentication parameter. The definition of the user- second-level-authentication parameter is as follows:

Parameter Specifies

user-secondlevelauthentication

Enables/disables two-level user authentication for the different types of administrative access to a Stinger system.

Specify one of the following the values:





none (the default)—Second level authentication is disabled for the system.



console-only—Second level authentication is enabled only for console access.



telnet-only—Second level authentication is enabled only for console access.



modem-only—Second level authentication is enabled only for modem access.



control-bus-only: Second level authentication is required only for control-bus access (from a remote shelf to a host Stinger system).



console-modem-only—Second level authentication is enabled for console and modem access.



console-telnet-only—Second level authentication is enabled for console and telnet access.



telnet-modem-only—Second level authentication is enabled only for telnet and modem access.



console-control-bus-only—Second level authentication is required for console and control-bus access.



telnet-control-bus-only—Second level authentication is required for telnet and control-bus access.



modem-control-bus-only—Second level authentication is required for telnet and control-bus access.



console-telnet-modem-only—Second level authentication is enabled for console,telnet, and modem access.



console-telnet-ctrl-bus-only—Second level authentication is enabled for console, telnet and controlbus access.



console-modem-ctrl-bus-only—Second level authentication is enabled for console, modem and controlbus access.



modem-telnet-ctrl-bus-only—Second level authentication is enabled for modem, telnet, and controlbus access.



system-level—Second level authentication is enabled system access.

Stinger® Administration Guide 1-9

Administering a Stinger System

Managing administrative access to the unit

Sample configuration

Suppose you have an existing user profile called admin. To require two levels of authentication for the user admin, create a new user john and configure it as a firstlevel login. Then, configure the user profile admin as a second level login and specify the user profile john as its first level login profile.

The following sample commands create the first level user profile john:

admin> new user john USER/john read

admin> set login-level = first-level

admin> write USER/john written

The following commands configure the user profile admin as a second-level login profile and assigns the profile john as its first-level login profile:

admin> read user admin USER/admin read

admin> set login-level = second-level

admin> set first-level-user = john

admin> write USER/admin read

Following are examples of RADIUS user files for telnet user accounts with settings for first-level and second-level authentication.

raduser1 Password = "system123", Ascend-User-Login-Level = First-Level User-Service = Shell-User, Ascend-Telnet-Profile = "admin", Ascend-User-Acct-Expiration = "Jan 6, 2006"

raduser2 Password = "system234", Ascend-User-Login-Level = Second-Level, Ascend-First-Level-User = "raduser1"

User-Service = Shell-User, Ascend-Telnet-Profile = "admin", Ascend-User-Acct-Expiration = "Dec 01 2003"

The following sample commands configure the system to require second-level authentication for telnet access:

admin> read system SYSTEM read

admin> set user-second-level-authentication = telnet-only

admin> write SYSTEM written

The system generates a log message whenever a user has successfully logged in. For example:

LOG info, Shelf 1, Controller-1, Time: 12:57:14-login success : user 'admin', source '135.17.134.39'on first level access

1-10 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

Specifying the maximum number of login attempts

To specify the maximum number of login attempts that a user can make, set the maximum-login-attempts parameter in the system profile. Specify a number between 1 through 6. The default value is 3.

The system generates a log message whenever a login attempt fails. The log message indicates whether the level of authentication failure is at the first level or second level. For example:

LOG critical, Shelf 1, Controller, Time: 16:46:32-login failure: user 'john', source '135.17.134.39' on first level access

LOG critical, Shelf 1, Controller, Time: 16:47:17-login failure: user 'mitch', source '135.17.134.39' on second level access

If a user fails to login after making the number of attempts specified by the maximumlogin-attempts parameter, the system generates the maxTelnetAttempts trap.

Authentication from a remote shelf to a host Stinger unit

When a user opens a session from a remote shelf (Stinger MRT or Compact Remote) to a host Stinger unit using the open shelf slot command, the systems creates a terminal session using the control bus.

The host Stinger unit authenticates a user by prompting the user for a user name and password. The user name and password must be defined in a user profile in the host Stinger system. The host grants access to the user only after successful authentication, and the host Stinger unit logs a message for every successful login and for every login failure.

If the host unit is configured for two-level authentication or control bus access, the host requires the user to log in twice.

No authentication is required when a user opens a session from the host Stinger unit to any of its own slots or to a remote controller or remote LIM.

The following sample session shows a user logging in from a remote shelf to a host unit. Two-level authentication is not configured on the host.

admin> show

Shelf 2 ( slave ): Reqd Oper Slot Type { shelf-2 slot-1 0 } N/A UP mrt-36-adsl-card { shelf-2 trunk-module-1 0 } UP UP oc3-atm-trunk-daughter-card

admin> open 1 8 Usage: open - start session with master controller

User: admin

Password:

shelf-router-1/8>

The following sample session shows a user logging in from a remote shelf to a host unit. Two-level authentication is configured on the host Stinger unit.

admin> open 1 8

Usage: open - start session with master controller

Stinger® Administration Guide 1-11

Administering a Stinger System

Managing administrative access to the unit

User: admin

Password:

User: user1

II Level Password:

shelf-router-1/8>

When a user has successfully logged in, the host generates the following sample log messages:

LOG info, Shelf 1, Controller, Time: 19:57:03-login success : user 'admin', source 'control bus'on first level access

LOG info, Shelf 1, Controller, Time: 19:57:08-login success : user 'user1', source 'control bus'on second level access

User account and user password expiration

You can configure Stinger systems to monitor for expired user accounts and user passwords. To enable the system to audit user profiles for expired passwords or user accounts, set the audit-user-profiles in system profile to yes. By default, the system does not audit user profiles.

If the audit-user-profiles parameter is set to yes, by default, a user account expires after three years and a password expires after 60 days. Users with Admin privileges can modify user account and password expiration dates.

What happens when a user account or user password expires

If enabled, the system monitors user profiles for expired accounts and passwords. If a user account is expired, the system disables that account and terminates any active user sessions. A user with an expired account is denied access to the system. Note that the system-generated user profile admin and its password do not expire.

Note After an NVRAM operation, the system reverts to the default settings for this

feature. That is, the system does not audit user profiles for expired accounts or passwords.

When the system terminates a user session because the user account is expired, it generates the following sample log message:

LOG critical, Shelf 1, Controller, Time: 00:51:55-Account expired for User: user1 from 135.17.134.39, disconnected by system

If the user’s account is still active, the user can change the expired password from the terminal session.

RADIUS support for account and password expiration

RADIUS supports user account expiration, but a user cannot change an expired password. All password administration must be performed by the RADIUS server system administrator. After successful authentication, the RADIUS server returns the name of the Stinger user profile that is linked to the external user account. The system authenticates users as defined in the user profile for user terminal session.

1-12 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

Setting expiration dates for user accounts and passwords

The following parameters in the user profile enable you to view the last login date for a user account and specify an expiration date for a user account and user password. Only user account expiration is supported by RADIUS.

Parameter RADIUS attribute Specifies

last-login-date n/a Date when this user profile was used to log in.

user-acctexpiration-date

user-passwdexpiration-date

Ascend-User-Acct-

Expiration date for this user account. Complex field.

Expiration

Not supported User password expiration date. Complex field.

Note Stinger systems do not audit RADIUS server user accounts. If a Stinger system

is configured for external authentication and the audit-user-profiles parameter in the system profile is enabled, for the users to be authenticated, the RADIUS server administrator must ensure that for all system telnet user accounts, the attribute Ascend-User-Acct-Expiration is set to the correct date.

The following sample commands specify the expiration date for the user account remote and the expiration date for its password. Note that you cannot set the parameter weekday.

admin> read user remote USER/test read

admin> list user-acct-expiration-date [in USER/remote:user-acct-expiration-date] weekday = Monday month = January year = 1990 day = 1

admin> set month = December

admin> set year =2005

admin> set day = 31

admin> list user-passwd-expiration-date [in USER/remote:user-passwd-expiration-date]

weekday = Monday month = January year = 1990 day = 1

admin> set month = dec

admin> set year = 2003

admin> set day = 31

admin> write -f USER/remote written

Stinger® Administration Guide 1-13

Administering a Stinger System

Managing administrative access to the unit

Enforcing a password check

To configure the system to validate that any new password created is unique and that it is at least 8 characters in length, with at least two numbers and four alphabetical characters, set the enforce-password-check parameter in user profileto yes. By default, this feature is disabled.

If this feature is enabled, the system administrator must provide a new user with a password for the user’s initial login. After a user has logged in and has been authenticated by the system, the user can use the changepasswd command to set a new password.

Changing a user password

If a user with an expired password attempts to log in and the user account is still valid, the system prompts the user to set a new password.

The changepasswd command enables a user to change password from the terminal session. When a user enters the changepasswd command, the system first authenticates the old password and then accepts the new password. If the system is configured for two-level authentication, the user can change the first and second level passwords. If password validation is enabled for the user’s account (the enforce-password-check parameter in the user profile is set to yes), the new password must be at least 8 characters long, containing at least two numbers and four alphabetical characters.

Following is a sample session showing a user changing a password using the

changepasswd command:

bash-2.05$ telnet 135.17.134.28 Trying 135.17.134.28... Connected to 135.17.134.28. Escape character is '^]'.

User: user1 Password:

SECOND LEVEL ACCESS User: user2 II Level Password:

user2> user2> user2> changePasswd Old SYSTEM Password: New SYSTEM Password: ReEnter New Password: Old II Level Password: New II Level Password: ReEnter New Password: user2> user2> quit Connection closed by foreign host. bash-2.05$

1-14 Stinger® Administration Guide

The following sample session shows a user changing an expired password:

bash-2.05$ telnet 135.17.134.28 Trying 135.17.134.28... Connected to 135.17.134.28. Escape character is '^]'.

User: user1 Old Password: New Password: ReEnter New Password:

SECOND LEVEL ACCESS User: user2 Old II Level Password: New II Level Password: ReEnter New Password:

user2>

Creating Telnet access control lists

Administering a Stinger System

Managing administrative access to the unit

You can restrict telnet access to the Stinger system by configuring a tacl (telnet access control list) profile. You must have system authorization to create, read, or modify the profile.

You can configure up to 20 entries in the tacl profile, each of which specifies a source IP address that is explicitly allowed telnet access to the system. Specifying a subnet address allows access from any of the addresses within the subnet range.

The tacl profile contains the following parameters, shown with default values:

[in TACL] enable-permit = no

[in TACL:permit-list[1]] valid-entry = no source-address = 0.0.0.0/0 source-address-mask = 0.0.0.0

Parameter Setting

enable-permit Enables or disables control over telnet access to the

system on the basis of the permit-list settings in the tacl profile. If set to no (the default), the permit-list settings have no effect. If set to yes, only the IP addresses specified in the permit-list subprofiles are allowed telnet access. Setting enable-permit to yes has no effect if none of the permit-list subprofiles have been configured.

valid-entry Enables or disables the permit-list entry.

Stinger® Administration Guide 1-15

Administering a Stinger System

Managing administrative access to the unit

Parameter Setting

source-address Source IP address of a host or subnet to be allowed

source-address-mask The subnet mask to be applied to the source-address

For example, the following commands create a tacl profile that enables telnet access from 30 host addresses from 10.27.34.1 to 10.27.34.31:

admin> new tacl

admin> set enable-permit = yes

admin> set permit-list 1 valid-entry = yes

admin> set permit-list 1 source-address = 10.27.34.1/27

telnet access to the system. If you specify the subnet mask as part of the source-address value, the sourceaddress-mask value is set automatically to the

corresponding dotted decimal value.

value. You can set the value directly in dotted decimal format or by including a subnet as part of the source-

address value.

admin> write -f

With this tacl configuration, only telnet attempts from the specified subnet will be allowed access. For example, the following sequence shows a successful telnet session established to a Stinger system at 210.210.210.99 from a valid IP address:

(sys10-27-34-1) telnet 210.210.210.99 Trying 210.210.210.99... Connected to 210.210.210.99. Escape character is '^]'. User: admin Password:

An attempt to telnet to the Stinger system from an IP address that is not on the specified subnet will fail. For example, the following sequence is displayed:

(sys10-27-45-45) telnet 210.210.210.99 Trying 210.210.210.99... Connected to 210.210.210.99. Escape character is '^]'. Connection closed by foreign host.

Assigning permissions

If you have administrative privileges, you can create any number of user profiles that grant other administrators various degrees of access to the system.

1-16 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

You can set the following permission parameters in any combination:

Parameter Setting

allow-code Enable/disable permission to upload code to the Stinger

unit and use the following code-level commands:



format—Prepares a flash card for use



fsck—Checks the file system on a flash card

allow-diagnostic Enable/disable administrative access to diagnostic profiles.

allow-password Enable/disable administrative access to the password

command.

allow-system Enable/disable administrative access to system profiles.

allow-termserv Does not apply to the Stinger unit. Enable/disable

administrative access to the terminal-server commands.

allow-update Enable/disable administrative access to update profiles.

allow-debug Enable/disable administrative access to debug commands.

This parameter is not visible on the interface. See “Enabling debug permissions” on page A-1.

Understanding command permissions

Permissions control the actions that a user who logs in with a particular profile can perform on a Stinger unit. Each permission enables the use of a particular command class. When you use the help command to display available commands, the left column shows command names, and the right column shows the command class. For example:

admin> ?

? ( user ) acct-failsafe ( debug ) agsh ( debug ) alarm ( system ) aliasTable ( debug ) annexType ( debug ) apsMgr ( debug ) arptable ( system ) atmcacstat ( debug ) atmCacToggle ( debug ) atmCktState ( debug ) atmConnectionFailures ( system ) atmControlState ( debug ) atmDelGet ( debug ) atmds3trunkdev ( debug ) atme3trunkdev ( debug ) atmems ( debug ) AtmEmsDebug ( debug ) atmFlexVpiVci ( debug ) atmGet ( debug ) atmInternalLines ( system )

Stinger® Administration Guide 1-17

Administering a Stinger System

Managing administrative access to the unit

atmnbase ( debug ) [More? <ret>=next entry, <sp>=next page, <^C>=abort]

Typically, read-write accounts enable the System command class. They might also enable the Update and Code command classes. Read-only accounts might be limited to the Diagnostic command class. Table 1-1 shows command class and the associated permission.

Table 1-1. Permissions and associated commands

Permission Command class

N/A

User

(always enabled)

Allow-System System

Allow-Update Update

Allow-Code Code

Allow-

Diagnostic

Allow-Termserv Termserv (Does not apply to the Stinger unit.)

Allow-Password N/A. The Allow-Password permission enables a user to view

passwords. If the permission is set to no, the user sees a row of asterisks instead of the actual configured password. If the administrator who backs up system configurations does not have the allow-password permission set to yes, passwords are not saved as part of the configuration.

Typical permission configurations

The following commands create a read-write administrative login named Marco, which is based on the admin user profile, but has access only to System, Diagnostic, and Update command classes:

admin> new user admin USER/admin read

admin> set name = marco

admin> set password = my-password

admin> set allow-password = yes

admin> set allow-code = no

admin> write USER/marco written

The following commands create a user profile named test based on the user profile admin, but restricts some permissions and assigns a different password:

1-18 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

admin> new user admin USER/admin read

admin> set name = test

admin> set password = test-pw

admin> set allow-update = no

admin> set allow-code = no

admin> write USER/admin written

The following commands create a profile that enables the user to use the update commands, but not to perform any other actions:

admin> new user USER/default read

admin> set name = techpubs

admin> set password = january

admin> set allow-update= yes

admin> set prompt = *

admin> set log-display-level = none

admin> write USER/techpubs written

Specifying group permissions for commands and profile access

You can create a centralized definition of the TAOS commands that a group of users can perform, and associate individual users with a command user group. You use the user-group profile to define command access for a group of users you specify. Then, assign a user group to a user by specifying a valid user-group profile for the user- group parameter in the user profile.

Creating a user group

To define a command user group, set the following parameters in the user-group profile. You can specify access settings and a list of up to 512 commands that users in the user group have permission to use.

Parameter Setting

name Name of a command user group. Specify up to

23 characters. The default is null.

use-group-permissions Enable/disable the user’s access to all the allow-xxx

settings in the user-group profile specified by the user- group parameter. With the default no setting, the user does not have access to the commands permitted by the allow-xxx settings in the user-group profile and only the commands permitted by the allow-xxx settings in the user profile apply. Specify yes for the user to have access to all commands permitted by the allow-xxx setting in the user-group profile and for the allow-xxx settings in the user profile to be ignored.

Stinger® Administration Guide 1-19

Administering a Stinger System

Managing administrative access to the unit

Parameter Setting

allow-termserv Enable/disable permission for the users in the group to

allow-system Enable/disable permission for the users in the group to

allow-diagnostic Enable/disable permission for the users in the group to

allow-update Enable/disable permission for the users in the group to

allow-password Enable/disable permission for the users in the group to

allow-code Enable/disable permission for the users in the group to

exclude-listed-commands Enable/disable permission for the users in the group to

command [n] Commands to allow or exclude.

profile Array that contains a listing of system profiles to which

use terminal-server commands. With the default no setting, users do not have terminal-server permission. Specify yes to enable users to have terminal-server permission.

use system-level commands. With the default no setting, users do not have system-level permission. Specify yes to give users system-level permission.

use diagnostic-level commands. With the default no setting, users do not have diagnostic-level permission. Specify yes to give users diagnostic-level permission.

use update-level commands. With the default no setting, users do not have update-level permission. Specify yes to give users update-level permission.

view passwords. With the default no setting, users cannot view passwords. Specify yes to enable users to view passwords.

use code-level commands. With the default no setting, users do not have code-level permission. Specify yes to give users code-level permission.

use the commands designated by the command parameter. With the default no setting, users have permission to use the designated commands. Specify yes to disable permission to use the designated commands.

users in this user group are denied access. You can specify up to 400 profiles. The default setting for this array is null.

1-20 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

Specifying a command user group for a user

You assign a command user group to a user by specifying a valid user-group profile name for the user-group parameter in the user profile. Following is the definition for the user-group parameter:

Parameter Setting

user-group Name of a user-group profile. The default is null. If the

user-group parameter refers to a valid user-group

profile, the access settings of the user-group profile are applied to the user session, overriding those in the user profile. If the user-group profile cannot be found, the user cannot log on or perform any commands. If no user-group profile is specified in the user profile, the access settings in the user profile apply.

In this example, the existing user bill is given permission to use the six commands that he needs to provision new users. The existing user ted can use all the Stinger commands except reset, slot, and read:

admin> read user bill USER/bill read

admin> set user-group = provisioning

admin> write -f USER/bill written

admin> new user-group provisioning USER-GROUP/provisioning read

admin> set command 1 = new

admin> set command 2 = list

admin> set command 3 = delete

admin> set command 4 = write

admin> set command 5 = get

admin> set command 6 = auth

admin> write -f USER-GROUP/provisioning written

admin> read user ted USER/ted read

admin> set allow-update = yes

admin> set allow-system = yes

admin> set allow-termserv = yes

admin> set allow-diagnostic = yes

admin> set allow-password = yes

admin> set allow-code = yes

admin> set user-group = maintenance

admin> write -f USER/ted read

Stinger® Administration Guide 1-21

Administering a Stinger System

Managing administrative access to the unit

admin> new user-group maintenance USER-GROUP/maintenance read

admin> set use-group-permissions = yes

admin> set exclude-listed-commands = yes

admin> set command 1 = reset

admin> set command 2 = slot

admin> set command 3 = read

admin> write -f USER-GROUP/maintenance written

When you change the user-group settings, the permissions of the associated users are automatically adjusted. If a user-group profile is deleted, the sessions of all the associated users are terminated.

Restricting access to profiles

You can maintain a list of system profiles that are critical to system security, for which access is denied. You define the restricted profiles in the array called profile in the user-group profile. Users that belong to this user group cannot perform read, write, get, new, delete, or save commands on restricted profiles. If a user attempts to access a restricted profile, the system prompts the user with an access denial message.

In the following sample user-group profile called remote, users that belong to this user group cannot perform read, write, get, new, delete, or save commands on the

user, ip-interface, and user-group profiles.

[in USER-GROUP/remote (changed)] name* = remote use-group-permissions = no allow-termserv = yes allow-system = yes allow-diagnostic = yes allow-update = yes allow-password = no allow-code = no allow-debug = no exclude-listed-commands = no command = [ "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "+ profile = [ user ip-int user-group "" "" "" "" "" "" "" "" "" "" "" "" "" ""

Verifying user group settings

The system does not prohibit you from entering a command user group or a user that does not exist, nor from entering an invalid list of commands. Use the usergroupcheck command to verify that your specifications are valid. For syntax information, see the Stinger Reference.

To verify that all the user-group profiles specify valid lists of commands and that all user-group profiles specified by user profiles are valid, use the usergroupcheck command with the -a option. For example:

admin> usergroupcheck -a All groups and users verified

1-22 Stinger® Administration Guide

Administering a Stinger System

Managing administrative access to the unit

To verif y t hat the user-group profile specified in the user profile enter the usergroupcheck command with the -u option. For example:

admin> usergroupcheck -u bill Group provisioning: Commands all valid. Commands available to this user are: ? ( user ) auth ( user ) clear ( user ) date ( user ) delete ( update ) dtunnel ( user ) filtcache ( user ) get ( system ) gre ( user ) grep ( user ) help ( user ) l2tp ( user ) l2tpcards ( user ) l2tpsessions 9.6.0 ( user ) l2tptunnels ( user ) list ( system ) netware ( user ) new ( system ) prtcache ( user ) quit ( user ) whoami ( user ) write ( update )

To verif y t he user-group profile specified by the user-group parameter in the user profile called user, and display the commands to which user has access, use the -g group option. For example, the following example verifies that the newyork command user group contains a valid list of commands:

admin> usergroupcheck -g newyork Group provisioning commands all valid

Extra levels of security for some commands

Certain command options have extra levels of security restricting access beyond that of standard commands, and these security levels cannot be bypassed by means of the user-group profile. For example, the standard arptable command displays the contents of the ARP cache, and is protected by the system level in both the user and user-group profiles. In addition, the option to add entries to the table is protected by the diagnostic or update level. As a result, allowing a command user group access to the arptable command by designating it with the command parameter does not allow members of the group to add entries to the ARP cache, unless the group or any of its users is granted access to system, diagnostic, and update commands.

Following are other commands and options that have additional levels of security:



arptable -a—Protected by update or diagnostic permission.



arptable -d—Protected by update or diagnostic permission.



arptable -f—Protected by update or diagnostic permission.



loadmate—Protected by debug and code permissions.

Stinger® Administration Guide 1-23

Administering a Stinger System

Managing administrative access to the unit



filtcache -f—Protected by update or diagnostic permission.



prtcache -f—Protected by update or diagnostic permission.



resrcmgr -t—Protected by diagnostic permission.

When used to restore configurations, the load command also requires the use of the new, set, and write commands, because the device runs these commands in the process of loading the configuration.

Specifying a time-out for user logins

You can specify a time-out period after which idle sessions on the Stinger unit disconnect. The default is 60 seconds. To configure an idle time-out, proceed as in the following example:

admin> read user test

admin> set idle-logout = 120

admin> write User test written

Setting the command-line prompt

The command-line prompt is configured with the prompt parameter. The following sample commands show how to configure a command-line prompt of hello:

admin> read user test

admin> set prompt = hello

admin> write User test written

The default command-line prompt is an asterisk followed by a right angle bracket (*>). An asterisk in this setting causes the Stinger system to substitute the value of the profile’s name parameter after a successful login. For example, for the admin profile, the following prompt appears:

admin>

Setting log levels for each login

You can configure the user profile to display one or more levels of log messages immediately in the interface. The display level you set causes messages at that level and above to be displayed in the interface, interrupting whatever work might be going on at the prompt. For example, the following commands cause messages at the critical, alert, and emergency levels to be displayed:

admin> read user test USER/test read

admin> set log-display-level = critical

admin> write USER/test written

Table 1-2 lists the message levels in order from highest to lowest severity.

1-24 Stinger® Administration Guide

Table 1-2. .Message levels

Administering a Stinger System

Basic system settings

Message level

emergency Error condition in the Stinger unit. The unit is probably not

alert Error condition in the unit. However, the unit is still operating

critical Inoperative interface or a security error.

error Error event.

warning Unusual event (a user entering an incorrect password, for example).

notice Event of interest in normal operation (for example, the

info State or status change that is not of general interest.

debug Helpful debug information.

none No messages are displayed.

Indicates

operating normally.

normally.

However, the unit is otherwise operating normally.

establishment of a link).

Logging in as a different user

To log in with a different user profile, use the auth command, as in the following example:

admin> auth test Password:@3wPZHd2

You must supply the password configured in the specified profile to be logged in as the user. Logging in as a different user can be helpful for verifying that the user profile permissions are correct.

Displaying the current user

To display the user profile that you are currently using, enter the whoami or who am i command. For example:

admin> whoami User Name : admin User Profile : admin

Basic system settings

The following sections describe how to set the system name, time, date and system clock source.

Setting the system name

The Stinger system name is used only during Point-to-Point Protocol (PPP) negotiations. The name is not used in Domain Name System (DNS) lookups.

Stinger® Administration Guide 1-25

Administering a Stinger System

Basic system settings

The system name is specified in the system profile. For example, to set the Stinger unit’s system name to Stinger01, proceed as follows:

admin> read system SYSTEM read

admin> set name = Stinger01

admin> write SYSTEM written

Setting the system time and date

The Stinger unit maintains the time and date. For proper operation, set the time and date at initial configuration using the timedate profile.

Viewing the system time and date

To view the current time and date, enter the date command with no argument. For example:

admin> date Tue Nov 6 14:52:25 2001

You can also access the timedate profile to view the information:

admin> get timedate [in TIMEDATE] time = { 14 53 10 } date = { Tuesday November 2001 6 }

Changing the system time

If the time is incorrect, you can change it by entering the current time in the timedate profile. The following example shows how to change the system time to 12:30:08 a.m.:

admin> read timedate TIMEDATE read

admin> set time = { 12 30 08 }

admin> write TIMEDATE written

Changing the system date

If the date is incorrect, you can change it by entering the current time in the timedate profile. Because the date subprofile includes a read-only field (day of week), you must set the date parameters independently. The following example shows how to change the system date to January 6, 2002.

admin> read timedate TIMEDATE read

admin> set date month = 01

admin> set date day = 06

admin> set date year = 2002

admin> write TIMEDATE written

1-26 Stinger® Administration Guide

Configuring system clocking

The Stinger unit requires a clock source for its timing subsystem. By default, the system uses the a built-in 8kHz clock on the single or primary control module as its timing source. The system-8k-clock parameter in the system profile specifies the clock source for the Stinger system. You can configure the system to take its clock source from a line interface module (LIM), trunk port, or from an external building integrated timing supply (BITS) clock connected to the unit’s alarm relay. By default, the system-8k-clock parameter is set to controller.

Displaying the current clock-source

You can view the current clock source by using the get command to display the setting for the system-8k-clock parameter. For example:

admin> get system system-8k-clock [in SYSTEM:system-8k-clock] system-8k-clock = controller

The clock-source command also displays the current clock-source along with available clock sources.

admin> clock-source Master: slot-1/1 line 3 Source List:

Source: slot-1/1 Available priority: 1

Administering a Stinger System

Basic system settings

A line specified as the clock source can be used as the source of timing information for synchronous connections, so both the sending device and the receiving device can determine where one block of data ends and the next begins. If multiple lines specify that they are the clock-source (the default configuration), you can assign clocksource priority among multiple lines.

The following commands cause the system to first attempt to use a trunk port as its clock source, and to use the built-in clock only if it finds no ports that are eligible clock sources:

admin> read system SYSTEM read

admin> set system-8k-clock = lim-or-trunk-module

admin> write SYSTEM written

Configuring trunk ports as clock sources

You can specify whether a trunk port can be used to source the ATM network clock and feed it to the primary control module as the master clock for the unit. To specify whether a trunk port as eligible or ineligible for this use, set the clock-source parameter in the trunk profile for that port (ds3-atm, oc3-atm, or e3-atm profile). You can assign a high, middle, or low priority for being elected as the clock source by setting the clock-priority parameter in the trunk profile for that port.

If more than one line is eligible to be the clock source, the system chooses the one with the highest priority, as specified by the clock-priority setting. If multiple sources of equal priority are present, the system selects the first valid clock source. (A clock source is valid if the clock-source parameter is set to eligible and the OC12, DS3, OC3, or E3 interface is synchronized.)

Stinger® Administration Guide 1-27

Administering a Stinger System

Displaying basic system information

Once it has selected a clock source, the system uses that source until the source becomes unavailable or a higher-priority source becomes available. If no eligible external sources exist, the system uses an internal clock generated by the primary control module.

The following sample commands configure both ports of the first DS3-ATM module as eligible clock sources, with the first port assigned a higher priority for this use:

admin> read ds3-atm { 1 trunk-module-1 1 } DS3-ATM/{ shelf-1 trunk-module-1 1 } read

admin> set line-config clock-source = eligible

admin> set line-config clock-priority = high

admin> write DS3-ATM/{ shelf-1 trunk-module-1 1 } written

admin> read ds3-atm { 1 trunk-module-1 2 } DS3-ATM/{ shelf-1 trunk-module-1 2 } read

admin> set line-config clock-source = eligible

admin> set line-config clock-priority = low

admin> write DS3-ATM/{ shelf-1 trunk-module-1 2 } written

The following commands configure only the first port of the second OC3-ATM trunk module as an eligible clock source. If this port becomes unavailable and is not backed up, the unit begins using the built-in clock on the primary control module.

admin> read oc3-atm { 1 trunk-module-1 1 } OC3-ATM/{ shelf-1 trunk-module-1 1 } read

admin> set line-config clock-source = eligible

admin> set line-config clock-priority = high

admin> write OC3-ATM/{ shelf-1 trunk-module-1 1 } written

The Getting Started Guide for your unit provides additional information about configuring the system clock source.

Displaying basic system information

The following sections describe how to display hardware platform, system name, serial number, software version, boot firmware version, control module role, control module revision and model number, system and module uptime.

For information about see displaying system components, see “Working with Stinger Shelves and Modules” on page 2-1

Displaying system hardware information and software version

The system-level command info displays information about the Stinger system, including hardware platform, system name, serial number, software version, boot firmware version, installed memory and control module role.

During system reboot, if you are connected to the control module console port, the system displays the platform type and the TAOS version running on the system.

1-28 Stinger® Administration Guide

Administering a Stinger System

Displaying basic system information

admin> info Platform : Lucent Stinger CRT COP System Name : (not configured) Serial Number : 58737 Software Version : TAOS 9.6.0 (crtcm) * * * rtr/crtcm <ss120> June 06 2004 18:16 * * * Boot Version : TAOS 9.7.0 Installed Memory : 64MB Hardware revision: 1.0

The fields displayed by the info command are defined as follows:

Field Definition

Platform Hardware platform type. This field reports one of the following

values:



Lucent Stinger MRT - 23"



Lucent Stinger MRT - 19"



Lucent Stinger LS/RT - 23"



Lucent Stinger LS/RT - 19"



Lucent Stinger FS



Lucent Stinger FS+



Lucent Stinger CRT COP

On a redundant system, if you enter the info command from the secondary control module, this field shows Lucent Stinger.

System name Name of the system as configured in the system profile. If the

system profile has not been configured, the command displays (not configured).

Serial number Serial number of the control module on which you entered the

command.

Software version Current version of TAOS.

Boot version Version of boot loader on the system.

Controller role Current role of the control module, either primary or

secondary.

Installed Memory Installed memory on the system.

Hardware revision Revision number of the control module on which you entered

the command.

System and module uptime

The uptime command reports how long the system and its individual modules have been operating. Without an argument, the command displays system uptime. For example:

admin> uptime 12:53:37 { shelf-1 first-control-module } cm-v2 0 days 18:58:57 (PRIMARY)

Stinger® Administration Guide 1-29

Administering a Stinger System

Displaying basic system information

If you specify a slot and shelf number, the uptime command displays the current time; identifies the module installed in the slot, and the length of time that the module installed in the slot has been operating. The following example shows that an SDSL LIM in slot 3 has been operating for 48 minutes and 38 seconds:

admin> uptime 1 3 16:15:06 { shelf-1 slot-3 } sdsl-atm-card 0 days 00:48:38 9.6.0

If you use the -a option, the command displays the uptime only for modules in the UP state. For example:

admin> uptime -a Current system time: 16:49:30 { shelf-1 slot-5 } ima-8-e1-card 9 days 06:17:16 9.6.0 { shelf-1 first-control-module } cm-v2 9 days 06:18:37 ( PRIMARY ) { shelf-1 slot-12 } glite-atm-48-card 9 days 06:16:54 9.6.0 { shelf-1 slot-15 } sdsl-atm-v2-card 9 days 06:17:00 9.6.0 { shelf-1 slot-16 } ima-8-t1-card 9 days 06:17:16 9.6.0

Using the status window

You can use a status window to display the continuous stream of statistics that the Stinger unit generates about its activities. For example, one status window displays up to 100 of the most recent system events that have occurred since the Stinger unit was started up, and another displays statistics about the currently active session. A VT100 window that can accommodate an image of at least 80 columns by 24 rows is required for displaying the status screens.

Displaying the status window

You can open the status window using the status, connection, line, view, or log command. For details about using these commands, see the Stinger Reference.

To open the system status window, enter the status command. Figure 1-1 shows the sample contents for each area of the status window.

1-30 Stinger® Administration Guide

Figure 1-1. Sample contents of a status window

Left: Connections

Top : G e neral

Administering a Stinger System

Displaying basic system information

12 Connections 0008 c9 ATM 04/09/ 0 7616K 0007 c7 ATM 04/07/ 0 7616K 0006 c11 ATM 04/11/ 0 7616K 0005 c10 ATM 04/10/ 0 7616K 0004 c8 ATM 04/08/ 0 7616K 0003 c6 ATM 04/06/ 0 7616K 0002 c5 ATM 04/05/ 0 7616K 0001 c4 ATM 04/04/ 0 7616K

The system prompt moves to just below the status window. If the system prompt is not visible below the status window, press Escape to display it.

To close the status window, enter the status command again:

admin> status

Understanding the status window

Figure 1-1 shows the main areas of the status window. In its default configuration, these areas contain the following information:



Left—Connection information is displayed on the left side of the window.



Top—General information, such as serial number, software version, and uptime are displayed in the upper right side of the window.



Bottom—Log information is displayed in the lower right side of the window.

ScootersStngr Status

Serial number: 123456 Version: 9.5.206

Rx Pkt: 998004 Tx Pkt: 266585

Col: 34

07/03/2003 12:47:16 Up:42days, 15:15:36

M: 242 L: notice Src: shelf-1/slot-6 Line 48 00S

Issued: 09:37:03, 07/23/2003

Bottom: Log

Connection status information

With the default settings in a user profile, the left area of the status window initially displays connection information, as shown in Figure 1-1. Each line represents an active connection; its username or station name; the type of connection (A for ATM, P for PPP, or M for MPP); the shelf ID, line, and channel (separated by slashes) on which the call was placed or received; and the bandwidth or baud rate of the connection.

Stinger® Administration Guide 1-31

Administering a Stinger System

Displaying basic system information

If the status window is not already visible, the connection command opens it with the connection-status information displayed:

admin> connection 2 Connections | Status 0003 test1 A 02/01/01/ 0 8000 | Serial number: 11XYZ90A7 Version: 9.7 0002 test2 A 01/17/01/ 1 155M |

===========================================================================

This command puts the window in connection-status mode, with the following message displayed below the status window:

[Next/Last Conn: <dn/up arw>, Next/Last Page: <pg dn/up>, Exit: <esc>]

This message indicates the keystroke sequences you can use for displaying additional information in the connection-status area. The Down Arrow and Up Arrow keys display the next and previous connections, respectively, in the list of active connections. The Page Down and Page Up keys display the list, one screen at a time.

When the connection-status-mode message is displayed, the system prompt does not appear at the bottom of the window. Press the Escape key to exit this mode and return to the system prompt.

General status information

With the default settings in a user profile, the top area of the status window initially displays general status information about the Stinger unit, including its serial number, the version of system software that the unit is running, and the number of packets transmitted and received. This area also shows the current system date and time and how long the system has been operational.

If the top of the status window is displaying another kind of information, you can redisplay the general status information with the view command:

admin> view top general

Line and channel status

To display information about WAN lines and channels, use the line command. Because space is limited for this graphical display of status information about lines and channels, the line-status window uses identifiers and codes. For example, the line’s link status uses a two-character code such as LA (link active), RA (Red Alarm), YA (Yellow Alarm), and so forth. For complete information on line-status codes, see the Stinger Reference.

If the status window is not already displayed, the following line command opens it with line-status information displayed in the bottom (lower right) of the window:

1-32 Stinger® Administration Guide

Administering a Stinger System

Displaying basic system information

admin> line

Or, you can use the following command to specify that the line-status information appears in the top of the window, replacing the general status information:

admin> line top

You can display information about all lines installed in the system if you wish, but the default is to show information only about enabled lines. To display the status of all lines, enter the following command:

admin> line all

When you enter the line command, the system puts the window in line-status mode and displays the following message, which indicates the key sequences for displaying additional information in the line-status area:

[Next/Last Line: <dn/up arw>, Next/Last Page: <pg dn/up>, Exit: <esc>]

The Down Arrow and Up Arrow keys display the next and previous lines, respectively, in the list. The Page Down and Page Up keys display the list a screen at a time.

Line status information includes the following identifiers and codes:



Line identifier in the format shelf slot line



Two-character code indicating the line’s link status



Single-character code indicating channel status



Single-character code indicating channel type

For additional information about identifiers and codes, see the Stinger Reference.

When the line-status-mode message is displayed, the system prompt does not appear at the bottom of the window. Press the Escape key to exit this mode and return to the system prompt.

Log message information

With the default settings in a user profile, the bottom area of the status window initially displays the most recent message from the Stinger log buffer. The number of system event messages stored in the log is set by the save-number parameter in the log profile.

The first line of the event log window shows the log entry number (M: 00 through M: N, where N is set in the save-number parameter of the log profile), the level of message, and the device on which the event occurred. The last line shows the date and time when the event occurred.

The middle of the window displays the text of the most recent message.

If the status window is not already displayed or if you want to scroll through the log, use the log command:

admin> log

If the Status window is not displayed, the log command opens it and displays the logmode message below the Status window. (If the Status window is already open, the

log command just displays the message.)

[Next/Last Conn:<dn/up arw>, Next/Last Page:<pg dn/up>,Exit: <esc>]

Stinger® Administration Guide 1-33

Administering a Stinger System

Displaying basic system information

This message indicates the key sequences you can use for displaying additional information in the Log area:



The Down Arrow and Up Arrow keys display the next and previous messages in the buffer, respectively.



The Page Up and Page Down keys display the first and last messages in the buffer, respectively.

When the log-mode message is displayed, the system prompt does not appear at the bottom of the window. Press the Escape key to exit this mode and return to the system prompt.

Customizing the status window display

You use the user profile to specify whether these statistics are always displayed when a user logs in using that profile, the areas of the window that are displayed by default, and the size of the status windows.

The following parameters in a user profile, shown with their default values, specify the contents of the status window:

left-status = connection-list top-status = general-info bottom-status = log-window

The following parameters in a user profile, shown with their default values, specify the size of the status window. The status-length parameter must be at least 6 lines smaller than screen-length.

screen-length = 24 status-length = 18

See the Stinger Reference for details about these parameters.

The following commands configure the user profile to display the status window after login, and to show line information in the bottom area of the window. This set of commands also configures a larger terminal emulator window and status screens.

admin> set default-status = yes

admin> set bottom-status = line-status

admin> set screen-length = 36

admin> set status-length = 30

Changing current status window sizes

The screen command enables you to change the size of the terminal emulator and status windows for the current session. For syntax information, see the Stinger Reference.

The following example changes the current display size to 55 lines long and 100 characters wide:

admin> screen 55 -w 100

If the Status window is open when you enter the screen command, the command resizes it dynamically. If it is not open, the Status window is resized when you next open it.

1-34 Stinger® Administration Guide

Administering a Stinger System

Managing administrative connections

Viewing the factory configuration and software licenses

The read-only base profile displays software version, enabled features (software licenses), network interfaces, and other system information that is not modified across resets. These values are read from the system ROM, security program array logic (PAL), and the hardware assembly itself. For information about the parameters in the base profile, see the Stinger Reference.

To view t h e base profile, use the get command. For example:

admin> get base [in BASE] shelf-number = 1 software-version = 9 software-revision = 7 software-level = "" ...

...

nm-prov-core = yes ras-enabled = yes h248 = no

Managing administrative connections

You can use the userstat, view left session, or who command to display connection information for users.

Displaying administrative session information with the userstat command

To display the most complete information about active sessions, use userstat with the -l option, as in the following example:

admin> userstat -l SessionID Line/Chan Slot:Item Tx/Rx Rate Svc Address Username ConnTime IdleTime Dialed# 383578461 1.17.02/002 1:17:02/002 155M/ 155M ATM 0.0.0.0 sig-17-2-0-5 32:21:18 unknown 383578460 1.17.03/002 1:17:03/002 44M/ 44M ATM 0.0.0.0 rcc-17-3-0-18 32:21:18 unknown 383578459 1.17.03/001 1:17:03/001 44M/ 44M ATM 0.0.0.0 sig-17-3-0-5 32:21:19 unknown 383578458 1.17.02/001 1:17:02/001 155M/ 155M ATM 0.0.0.0 rcc-17-2-0-18 32:21:27 unknown <end user list> 4 active user(s)

Stinger® Administration Guide 1-35

Administering a Stinger System

Managing administrative connections

Following are the userstat output fields with descriptions:

Field Description

Sessionid Unique ID assigned to the session.

Line/Chan Physical address (shelf.slot.line/channel) of the

Slot:Item Shelf:slot:item/logical-item of the host port to which

Tx/Rx Rate Transmit and receive rate.

Svc Type of service in use for the session. Following are

network port on which the connection was established.

the call was routed.

the possible values:



--- The service is being negotiated.)



TLN Telnet



BTN Binary Telnet



ATM Asynchronous Transfer Mode

Address IP address of the user.

Username Name of the user.

ConnTime The amount of time (in hours:minutes:seconds

format) since the session was established. This field appears only with the -l option.

IdleTime The amount of time (in hours:minutes:seconds

format) since data was last transmitted across the connection. This field appears only with the -l option.

Dialed# The number dialed to initiate this session.

Customizing the output of the userstat command

The -o option with one or more format specifiers can limit the commands’s output to those fields of interest. For example, if you use the -o option and indicate the codes for session ID and line or channel information, the command shows only the following details:

admin> userstat -o %i %l

SessionID Line/Chan 288532030 1.01.01/012 <end user list> 1 active user(s)

For definitions of the available specifiers, see the Stinger Reference.

Displaying information related to a known IP address

Use the userstat -a command to display information related to a known IP address. The userstat -a command requires an IP address argument on the command line. For example:

admin> userstat -a 1.1.1.238

1-36 Stinger® Administration Guide

SessionID Line/Chan Slot:Item Tx/Rx Rate Svc Address Username 288532030 1.01.01/012 1:03:01/002 56000/56000 PPP 1.1.1.238 net1 <end user list> 1 active user(s)

To display only the relevant username, include the -o option as follows:

admin> userstat -a 1.1.1.238 -o %u Username net1 <end user list> 1 active user(s)

Displaying information related to a known username

Use the userstat -u command to display information related to a known username. You must enter a username argument on the command line. For example:

admin> userstat -u net1 SessionID Line/Chan Slot:Item Tx/Rx Rate Svc Address Username 288532030 1.01.01/012 1:03:01/002 56000/56000 PPP 1.1.1.238 net1 <end user list> 1 active user(s)

To display only the user’s IP address, include the -o option as follows:

admin> userstat -u net1 -o %a Address

1.1.1.238 <end user list> 1 active user(s)

Administering a Stinger System

Managing administrative connections

Using the view left session command

To display information about administrative users, including user name and source IP address, use the view left session command. For example:

admin> view left session

essions x Status dmin console x Serial number: 11038184 Version: 9.6.0 dmin 192.11.156.32 x dmin 192.11.156.149 x Rx Pkt: 230059 dmin 192.11.157.123 x Tx Pkt: 1186 x Col: 3 x x01/10/2004 16:33:21 Up: 9 days, 06:22:31 xqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq xM: 181 L: notice Src: shelf-1/slot-3 x x Line 48 up x x x x x Issued: 10:14:29, 01/01/2004 qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq

The Sessions section shows the user name and source IP address of administrative users from Telnet sessions. An asterisk (*) denotes the current session.

Stinger® Administration Guide 1-37

Administering a Stinger System

Managing administrative connections

Displaying administrative users

The who command displays names of administrative users, user profiles, and IP addresses of administrative users from Telnet sessions. An asterisk (*) denotes the current session. For example:

admin> who user profile from super console * admin admin 135.254.196.37 pratul admin 135.254.196.37

Terminating a user connection

To terminate a user connection, use the userstat -k command. For example:

admin> userstat SessionID Line/Chan Slot:Item Rate Svc Address Username 332429649 1.13.01/000 1:13:01/000 3360/3360 ATM 1.1.1.1 11-0-13 <end user list> 1 active user(s)

admin> userstat -k 332429649 Session 246986325 cleared

The userstat command can terminate Telnet, Telnet binary, Raw TCP, or terminal server user sessions.

You can also terminate an administrative session using the who -k command. The who -k command requires System privileges. For example, the following command disconnects the user pratul logged in from IP address 135.254.96.37:

admin> who -k pratul 135.254.196.37 LOG critical, Shelf 1, Controller-1, Time: 05:24:17--user admin from 135.254.196.37 disconnected user pratul from 135.254.196.37 1 administrative user killed.

The who -k command disconnects all sessions with the user name pratul logged in from IP address 135.254.96.7.

You cannot use the who -k command to disconnect the current session or a session from the console if for its serial port the user-profile parameter in the serial profile is set to a value other than null.

Disconnecting an idle connection

You can configure a Stinger unit to disconnect a modem connection after a specified period of inactivity. To configure a timeout value, set the inactivity-time parameter in the modem profile with a value from 0 through 255 seconds. With the default setting of 0, the timer is disabled and an inactive modem connection is not disconnected after any period of inactivity.

The following sample commands configure the Stinger unit to disconnect a modem connection after it has been inactive for 120 seconds.

admin> read modem { shelf-1 first-control-module 3 } MODEM/{ shelf-1 first-control-module 3 } read

admin> list [in MODEM/{ shelf-1 first-control-module 3 }]

admin> set inactivity-time = 120

1-38 Stinger® Administration Guide

admin> write MODEM/{ shelf-1 first-control-module 3 } written

Resetting a Stinger system

When you reset the Stinger system, it restarts and terminates all active connections. All users are logged out, and the default security level is reactivated. In addition, a system reset can cause a WAN line to temporarily shut down due to momentary loss of signaling or framing information. After a reset, the system runs power-on self tests (POSTs).

When you enter the reset command without any arguments, the system resets each control module. In hosted systems, this command resets each controller on the remote shelves. To reset the Stinger with confirmation, proceed as follows:

admin> reset Reboot the entire system, dropping all connections? [y/n]

In a redundant system, to reset the secondary control module only with no confirmation. For example:

admin> reset -f -r secondary_controller Please standby. System reset in progress.

Administering a Stinger System

Resetting a Stinger system

On a hosted system, to reset only the master controller (the controller in the host system), use the -m option. For example:

HOST> reset –m

To reset a specific remote shelf, use the -s option and specify the shelf’s ID. For example, the following command resets shelf 3:

HOST> reset –s 3

In an open session to a remote shelf, the -m and -s options are not supported. Executing a reset on a remote shelf resets only that shelf.

For additional command options, see the Stinger Reference.

Stinger® Administration Guide 1-39

Working with Stinger Shelves and Modules

Understanding physical addressing on Stinger units . . . . . . . . . . . . . . . . . . . . . . 2-1

Viewing system components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

Opening a session with a module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-12

Changing a module’s state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14

Changing the state of a module’s interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-15

Removing a module and its configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

Recovering from a failed module installation . . . . . . . . . . . . . . . . . . . . . . . . . . 2-18

For information about how to configure a particular module, see the module guide for your device at http://www.lucentdocs.com/ins. For information about managing the Stinger system, see Chapter 1, “Administering a Stinger System.”

Understanding physical addressing on Stinger units

On modular Stinger units, the True Access™ Operating System (TAOS) software uses the physical address to provide configuration and administration access to a shelf or module’s functions. Because TAOS associates module functions with the same slot numbers on all Stinger units, the functions are grouped into virtual slots on the Stinger MRT chassis. In this document, Stinger MRT refers to both the Stinger MRT 23 and Stinger MRT 19 chassis.

The chassis of Stinger FS, Stinger FS+, Stinger LS, Stinger RT, or Compact Remote units have slots that accept plug-in modules with different functions. The smaller Stinger MRT units integrate the functions of the control module, line interface modules (LIMs), and line protection modules (LPMs) into the chassis, and have a single trunk module slot. Each module has a physical address composed of its shelf number, slot number, and item number in the format {shelf-

On hosted Stinger MRT systems, the value of shelf is defined by the SHELF ID switch on that shelf. On hosted Compact Remote systems, the value for shelf is assigned.

Figure 2-1 shows the modules on the front panel of a Stinger FS or Stinger FS+ unit. The slots are numbered from left to right, with the middle slots reserved for the control modules. On a Stinger LS or Stinger RT unit, which has fewer slots, the control modules are on the right.

N slot-N item-N }.

Stinger® Administration Guide 2-1

Working with Stinger Shelves and Modules

Understanding physical addressing on Stinger units

Figure 2-1. Front panel of a Stinger FS unit

Note On a Stinger MRT, because control module and LIM functions are

incorporated into the unit’s chassis, the terms control module and LIM in this guide refer to the control module and LIM functions on the Stinger MRT, and not to physical modules.

Table 2-1 shows how TAOS relates slot numbers to modules and module functions on all Stinger units, for configuration and administration. (LPMs are not configured.)

Table 2-1. How TAOS organizes Stinger module functions

Module type LIM Control module(s) Trunk module (s)

Module Function: Connecting the unit to

subscriber lines

General control and configuration of the

Connecting the unit to ATM links

unit

Slot numbers on Stinger FS, Stinger FS+, Stinger LS, and Stinger RT units

Stinger MRT units

Slots 1 through 7



Slots 10 through 16 (Stinger FS and Stinger FS+ only)

Virtual slot 1 Virtual slot 8

Slots 8 and 9 Slots 17 and 18



Virtual slot 17



(built-in STS-3 interface)



Virtual slot 18 (trunk module)

Stinger MS+ units

Slots 1 through 4 Virtual slot 8 Virtual slot 17

2-2 Stinger® Administration Guide

Viewing system components

You can use the show command and slot-info profile to display information about the modules installed or configured in Stinger systems and the status of each module.

Using the show command

The show command lists the address of all modules installed in a Stinger system including those installed in remote shelves, their required operating states and current operating states, and the type of module installed.

Following is a sample output from a standalone Stinger FS, Stinger FS+, Stinger LS, or Stinger RT,

admin> show Controller { first-control-module } ( PRIMARY ): Reqd Oper Slot Type { shelf-1 slot-2 0 } UP NONE stngr-48a-adsl-card { shelf-1 slot-3 0 } UP UP al-dmtadsl-atm-card { shelf-1 slot-5 0 } UP NONE dadsl-atm-24-card { shelf-1 slot-6 0 } UP NONE dadsl-atm-24-card { shelf-1 slot-7 0 } DOWN RESET glite-atm-48-card { shelf-1 slot-11 0 } UP NONE stngr-48a-adsl-card { shelf-1 slot-14 0 } DOWN RESET stngr-48b-adsl-card { shelf-1 trunk-module-1 0 } UP UP ds3-atm-trunk-daughter-card

Working with Stinger Shelves and Modules

Viewing system components

On an ADSL 36-port Stinger MRT, the show command displays the following output:

admin> show Shelf 1 ( standalone ):

Reqd Oper Slot Type { second-control-module } UP UP ( SECONDARY ) { shelf-1 slot-1 0 } UP UP mrt-36-adsl-card { shelf-1 trunk-module-1 0 } UP UP oc3-atm-trunk-daughter-card { shelf-1 trunk-module-2 0 } UP UP oc3-atm-trunk-daughter-card

On a unit with dual control modules, the show command identifies which control module is primary. The command also lists the addresses of each slot with an installed module.

On a hosted system, the show command displays information about all shelves with an active control link to the host. For example, on a hosted Stinger MRT system, the following command output shows that in addition to the host shelf (shelf ID 1), shelves 3, 4, 5, and 6 have an active link to the host. For more information about physical addressing on Stinger systems, see “Understanding physical addressing on Stinger units” on page 2-1.

HOST> show Shelf 1 ( master ): Reqd Oper Slot Type { shelf-1 slot-1 0 } UP UP mrt-36-adsl-card { shelf-1 trunk-module-1 0 } UP UP oc3-atm-trunk-daughter-card { shelf-1 trunk-module-2 0 } UP UP ds3-atm-trunk-daughter-card { shelf-3 slot-1 0 } UP UP mrt-36-adsl-card { shelf-3 first-control-mod+ UP UP mrt-cm { shelf-4 slot-1 0 } UP UP mrt-36-shdsl-card { shelf-4 first-control-mod+ UP UP mrt-cm

Stinger® Administration Guide 2-3

Working with Stinger Shelves and Modules

Viewing system components

{ shelf-5 slot-1 0 } UP UP mrt-36-adsl-card { shelf-5 first-control-mod+ UP UP mrt-cm { shelf-6 slot-1 0 } UP UP mrt-36-adsl-card { shelf-6 first-control-mod+ UP UP mrt-cm

Note All configuration profiles reside on and are accessible only on the host system.

Field description from the output of the show command

Table 2-2 describes the values displayed for the Reqd, Oper, and Slot-Type fields.

Table 2-2. Description of Reqd, Oper, and Slot Type fields

Field Indicates

Reqd Required operational state of the module, which can be up, down, or

maint. This field reports the setting of the reqd-state parameter in

the slot-state profile. See “Using slot-admin profiles” on page 2-14.

Oper Current operational state of the slot, which can be one of the

following values:



UP—Normal operational mode.



DOWN—Not in an operational mode.



POST—Module is running power-on self tests (POSTs).



BOOT—Control module has recognized the module and has begun to run the code in its boot ROM. Typically, the LOAD state quickly follows the BOOT state.



LOAD—Module is loading code as part of booting up.



RESET—Module is resetting.



NONE—Module has been removed, but its configuration remains in NVRAM.



DIAG—The slot is being controlled by a remote debugger or is trying to perform a core dump as the result of a fatal error.

Slot Type Type of device installed in a slot, or the function defined by a virtual

slot. For a list of all the devices, see the definition of the slot-type parameter in the Stinger Reference.

The system considers a module to be present if a slot-type profile exists for that type of module. If you remove a module, the system does not delete the slot-type profile for that module until you use the slot -r command or clear NVRAM. For more information, see “Removing a module and its configuration” on page 2-17.

Displaying the status of LPMs, PSMs, and CLT modules

The rearslotshow command shows the status of all slots used for LPMs, path selector modules (PSMs), and copper loop test (CLT) modules. It also reports on the status of the midplane sparing bus. For details, see “Verifying port redundancy status” on page 5-18.

2-4 Stinger® Administration Guide

Monitoring the status of remote shelves

The remote-shelf-stat profile resides on the host for monitoring remote shelves. The remoteshelf command displays information about enabled remote shelves in the hosted system.

You can set alarms and traps to notify an SNMP management station when certain conditions occur on a remote shelf. See “Enabling traps for events on remote shelves” on page 8-30 for more information.

Using the remote-shelf-stat profile

When the host detects an enabled remote shelf, the system creates a remote-shelfstat profile for the shelf. For example:

HOST> dir remote-shelf-stat 0 08/27/2003 16:11:22 shelf-2 0 08/27/2003 16:17:39 shelf-3 0 08/27/2003 16:13:33 shelf-4

The remote-shelf-stat profile is read-only, and maintains dynamic state information regarding the remote shelf. It is accessible by SNMP managers.

The contents of the remote-shelf-stat profile are listed in the following table. The differences in the fields of the remote-shelf-stat profile for a hosted Compact Remote system and a hosted MRT system are noted where applicable.

Working with Stinger Shelves and Modules

Viewing system components

Parameter Setting

remote-shelf-id Shelf ID of the remote shelf represented in this profile.

remote-shelf-oper-state Operational state of the remote shelf. Values can

indicate that the remote shelf is up or down, if the link between the host and remote shelf failed to come up, or that the host-to-shelf autodiscovery process is currently in progress or has established the link to the operational remote shelf.

internal-fan-unit-failed An alarm was received from the remote shelf fan to

indicate a failure of the internal fan unit (yes or no).

Not meaningful for Stinger MRT units.

external-fan-unit-failed An alarm was received from the remote shelf fan to

indicate a failure of the external fan unit (yes or no).

Not meaningful for Stinger MRT units.

door-open An alarm was received from the remote shelf fan to

indicate that the door is open (yes or no).

Not meaningful for Stinger MRT units.

over-temperature Whether the cabinet temperature exceeds the

threshold (yes or no).

Stinger® Administration Guide 2-5

Working with Stinger Shelves and Modules

Viewing system components

Parameter Setting

contact-closure[n] An array of indexed parameters that indicate the

contact closure state (yes if contact closure is detected) on the corresponding remote shelf. Only the first two

contact closure values are meaningful for Stinger MRT units.

host-port:physicaladdress

Physical address of the remote shelf. The address specifies a shelf ID, followed by a slot number, followed by the item number of an addressable entity within the context of shelf and slot.

Not meaningful for Stinger CR units.

host-port:logical-item Number that specifies an addressable logical entity

within the context of a physical address.

Not meaningful for Stinger CR units.

topology:port-towardshost-shelf

Port on the remote shelf used for the link to the host.

Not meaningful for Stinger CR units.

topology:port-1-shelf Shelf ID of the remote shelf directly connected to the

first cascade port on the host.

Not meaningful for Stinger CR units.

topology:port-2-shelf Shelf ID of the remote shelf directly connected to the

second cascade port on the host.

Not meaningful for Stinger CR units.

validation-status:idvalid

Indicates whether the validation-id setting in the remote-shelf-config profile matches the validation ID

specified by the remote shelf’s DIP-switch setting. The disabled value indicates that no validation was performed. A true setting indicates that validation was done, and the software validation ID setting matched the DIP switch setting. A false setting indicates that validation was done, and the software validation ID setting did not match the DIP switch setting.

Not meaningful for Stinger MRT units.

validation-status: validation-id-setting

Physical validation ID set by DIP switches on the remote shelf (from 0 to 255). This value is read from the remote shelf.

Not meaningful for Stinger MRT units.

validation-status:

validation-id

The validation ID specified in the remote-shelf-config profile. This value is compared against the validation- id- setting from the remote shelf to determine the validation result, which is shown in the id-valid field.

Not meaningful for Stinger MRT units.

2-6 Stinger® Administration Guide

Working with Stinger Shelves and Modules

Displaying information about enabled remote shelves

The remoteshelf command displays information about enabled remote shelves. It uses the following syntax on a hosted system:

HOST> help remoteshelf usage: remoteShelf -[s|o] <param> remoteShelf with no options, show all configured remote shelves remoteShelf -s <shelf> show detailed information for a single remote shelf

For example, the following command shows details about remote shelf 3:

HOST> remoteshelf -s 3 Shelf: 3 Shelf Name: MyShelfName Shelf Location: MyShelfLocation Shelf Type: Stinger MRT Host Port: { { 1 17 1 } 0 } Shelf Enabled: Yes Oper State: OPER_UP Up Count: 2 Last Up Time: Wed Sep 17 15:45:25 2003 Last down Time: Wed Sep 17 15:45:21 2003

Viewing system components

Without any options, the command displays all configured remote shelves:

HOST> remoteshelf Shelf Name AdminState OperState host-port up-count 2 MyShelfName Enabled OPER_Down {{ 0 0 0} 0} 0

Displaying hosted MRT system topology and statistics

To display the topology of a hosted system, use the topology command. For syntax information, see the Stinger Reference.

You can also execute the topology command in an open session on a remote shelf. In that case, the command displays the details of that shelf.

Displaying the entire topology

With no options, the topology command displays details about each shelf in the hosted system. In the following example, remote shelf 3 is connected to EXP1, and no remote shelves are connected after it. On EXP2 remote shelf 2 is connected, followed by remote shelf 5.

HOST> topol Slaves connected to EXP1 of Master ================================== ShelfId : 3 Operational State : UP Admin State : UP Position : 1 MrtType : STINGER_MRT_23INCH_PLATFORM MRT Connected to Exp1 : 1 MRT Connected to Exp2 : 16 Port connected to - On Master : 0 Port connected to - On Slave : 0

Stinger® Administration Guide 2-7

Working with Stinger Shelves and Modules

Viewing system components

Slaves connected to EXP2 of Master ================================== ShelfId : 2 Operational State : UP Admin State : UP Position : 1 MrtType : STINGER_MRT_23INCH_PLATFORM MRT Connected to Exp1 : 1 MRT Connected to Exp2 : 5 Port connected to - On Master : 1 Port connected to - On Slave : 0

ShelfId : 5 Operational State : UP Admin State : UP Position : 2 MrtType : STINGER_MRT_23INCH_PLATFORM MRT Connected to Exp1 : 2 MRT Connected to Exp2 : 16 Port connected to - On Master : 1 Port connected to - On Slave : 0

For an explanation about the output of the toplogy command, see the Stinger MRT Getting Started Guide for your unit or the Stinger Reference.

Displaying a picture of the topology

For a picture of the topology, use the topology -p command. For example:

HOST> topol -p

-------EXP1------- -------EXP1------ | Slave : 5 | | Slave : 4 |

-------EXP2------- -------EXP2------ | | | |

-------EXP1------- -------EXP1------ | Slave : 3 | | Slave : 6 |

-------EXP2------- -------EXP2-------

Displaying the details for a specific shelf

To display the details about a particular shelf by using the topology -d command and specifying the remote shelf ID. For example:

HOST> topol -d 5 ShelfId : 5 Operational State : UP Admin State : UP Position : 2

2-8 Stinger® Administration Guide

Working with Stinger Shelves and Modules

Viewing system components

MrtType : STINGER_MRT_23INCH_PLATFORM MRT Connected to Exp1 : 2 MRT Connected to Exp2 : 16 Port connected to - On Master : 1 Port connected to - On Slave : 0

Displaying statistics for a specific shelf

To display statistics about the types of packets received and sent to a particular shelf, use the topology -s command with the remote shelf ID. For example:

HOST> topol -s 3 Statistics of Shelf: 3 discovery restart : 0 Number of requests received Valid : 1 Duplicate ShelfId : 0 Admin State not UP: 0 Invalid : 0 Discarded : 0 Number of Ack Sent : 1 Number of Nack Sent : 0 Number of Reset Sent : 0 Number of Init Sent : 0

Table 2-3 shows details displayed by this command:

Table 2-3. Statistics displayed for a remote shelf

Output field Description of value

discovery restart Number of times autodiscovery has been restarted.

Number of requests received

Valid Count of valid requests received.

Duplicate ShelfId

Another MRT sent requests with this shelf ID.

Admin State not UPRequest was received when

administrative state for this shelf was down or unknown.

Invalid An invalid request was received.

A request is invalid is it contains a protocol Id or version mismatch, or is sent from invalid intermediate shelf.

Discarded Request discarded, which might

indicate that the intermediate shelf is down.

Number of Ack Sent Number of Acks sent to the shelf.

Stinger® Administration Guide 2-9

Working with Stinger Shelves and Modules

Viewing system components

Table 2-3. Statistics displayed for a remote shelf (Continued)

Output field Description of value

Number of Nack Sent Number of Nacks sent to the shelf.

Number of Reset Sent Number of Resets sent to the shelf.

Number of Init Sent Number of Inits sent to the shelf.

When you specify shelf ID 1, indicating the host, the topology -s command displays the number of erroneous packets received. For example:

HOST> topol -s 1 Discarded packets : 0 Request Rcvd with Invalid ShelfID : 0

Table 2-4 shows details displayed by this command:

Table 2-4. Statistics displayed for the host shelf

Output field Description of value

Discarded packets Packets discarded due to header errors, intermediate

shelves being down. No action had been taken on these packets, they were silently discarded.

Request Rcvd with Invalid ShelfID

Autodiscovery received from with invalid shelf ID (a shelf ID outside the range from 2 to 7).

If you execute this command on the remote shelf, statistics are displayed for that shelf only. For example:

HOST> open 3 8

SLAVE3/8>> topol -s Statistics of Shelf: 3 Discarded packets : 0 Discovery restart : 0 Number of Req Sent : 126 Number of Ack Rcvd : 0 Number of Nack Rcvd : 0 Number of PassThruReq : 0 Number of PassThruRep : 0 Number of Init Rcvd : 0 Number of Reset Rcvd : 0

Table 2-5 shows details displayed by this command:

Table 2-5. Statistics displayed in an open session on the remote shelf

Output field Description of value

Discarded packets Packet discarded due to header errors.

2-10 Stinger® Administration Guide

Table 2-5. Statistics displayed in an open session on the remote shelf

Output field Description of value

Discovery restart Number of times Auto Discovery has been restarted.

Number of Req Sent Number of Auto Discovery Request sent.

Number of Ack Rcvd Number of Acks received from the host.

Number of Nack Rcvd Number of Nacks received from the host.

Number of PassThruReq Number of pass through request forwarded.

Number of PassThruRep Number of pass through replies forwarded.

Number of Init Rcvd Number of Inits received from the host.

Number of Reset Rcvd Number of Resets received from the host.

Sending an init packet to a remote shelf

Working with Stinger Shelves and Modules

Viewing system components

Usually, the host sends an init packet to a remote shelf only if its administrative state is UP and its operational state is DOWN. To restart autodiscovery between the host and a remote shelf without resetting the shelf, use the topology -r command and specify the shelf’s ID. For example:

HOST> topol -r 2

Viewing information about a particular module

You can obtain information about a particular module by entering the show command with the shelf-number and slot-number arguments or by displaying the slot-info profile.

Using the show command with the shelf and slot numbers

To use th e show command for information about a particular module, add the shelf and slot numbers as arguments. For example:

admin> show 1 3 Controller { first-control-module } ( PRIMARY ): Reqd Oper Slot Type { shelf-1 slot-3 0 } UP UP al-dmtadsl-atm-card: { shelf-1 slot-3 1 } DOWN xdsl-12-line1 { shelf-1 slot-3 2 } DOWN xdsl-12-line-2 { shelf-1 slot-3 3 } DOWN xdsl-12-line-3 { shelf-1 slot-3 4 } DOWN xdsl-12-line-4 { shelf-1 slot-3 5 } DOWN xdsl-12-line-5 { shelf-1 slot-3 6 } DOWN xdsl-12-line-6 { shelf-1 slot-3 7 } DOWN xdsl-12-line-7 { shelf-1 slot-3 8 } DOWN xdsl-12-line-8 { shelf-1 slot-3 9 } DOWN xdsl-12-line-9 { shelf-1 slot-3 10 } DOWN xdsl-12-line-10 { shelf-1 slot-3 11 } DOWN xdsl-12-line-11

Stinger® Administration Guide 2-11

Working with Stinger Shelves and Modules

Opening a session with a module

{ shelf-1 slot-3 12 } DOWN xdsl-12-line-12

The following sample command displays information about the trunk module installed in a Stinger MRT, which is identified as virtual slot 18 :

admin> show 1 18

Shelf 1 ( standalone ):

{ shelf-1 trunk-module-2 0 } UP UP oc3-atm-trunk-daughter-card: { shelf-1 trunk-module-2 1 } UP atm-oc3-trunk-1 { shelf-1 trunk-module-2 2 } DOWN atm-oc3-trunk-2

Using the slot-info profile

The read-only slot-info profile stores information about each module that has successfully booted. This profile is not stored in NVRAM, so it does not persist across system resets or power cycles. The system creates a slot-info profile when you boot the module and deletes the profile when your remove or reboot the module. SNMP managers can read the slot-info profile.

The following sample commands display the contents of the slot-info profile for the module installed in slot 13:

admin> read slot-info {1 13 0} SLOT-INFO/{ shelf-1 slot-13 0 } read

admin> list [in SLOT-INFO/{ shelf-1 slot-13 0 }] slot-address* = { shelf-1 slot-13 0 } serial-number = 1018540161 software-version = 9.4-185.2 software-revision = 0 software-level = "" hardware-level = 0 software-release = e0

Reqd Oper Slot Type

For information about the parameters in the slot-info profiles, see the Stinger Reference.

Opening a session with a module

Each installed and operating LIM or T1 or E1 module on a Stinger FS, Stinger FS+, Stinger LS, or Stinger RT unit has its own processor and is running its own operating system. You can use the open command to connect to a module directly and run commands. On a Stinger MRT, you can open a session with virtual slot 1. (See “Understanding physical addressing on Stinger units” on page 2-1 for additional information.)

This type of connection is useful for performing debug operations, because when you issue a debug command from a module, the command operates only from the context of that module.

The syntax of the open command is as follows:

open shelf-number slot-number

To open a session with a remote shelf, specify a shelf-number.

2-12 Stinger® Administration Guide

Sample open commands

The open command creates an internal Telnet-like session with the module and displays a modified prompt indicating the slot and module you are managing.

Opening a session

The following command opens a session to the secondary control module in slot 9:

admin> open 1 9 shelf-router-1/9>

The following command opens a session to the LIM located in shelf 1, slot 4 of a Stinger FS, Stinger LS, or Stinger RT unit:

admin> open 1 4 dmtadsl-atm-1/4>

The following command opens a session with virtual slot 1 on a Stinger MRT:

admin> open 1 1 mrtdmt-1/1>

Ending a session

Working with Stinger Shelves and Modules

Opening a session with a module

To exit the session with the module, enter quit, as in the following example:

dmtadsl-atm-1/4> quit Terminated from far-end

Module-level commands

When you are connected to a module, only a subset of the Stinger commands are available. To list the commands available on the module, enter a question mark (?) or

help, as in the following example:

dmtadsl-atm-1/4> ? ? ( user ) @fatalTest ( debug ) addrpool ( debug ) alErrs ( debug ) alPorts ( debug ) alRestart ( debug ) apctog ( debug ) arptable ( system ) atm1483State ( debug ) atmAdd ( debug ) atmApc ( debug ) atmARam ( debug ) atmAtab ( debug ) atmcacstat ( debug ) atmCacToggle ( debug ) atmcallif ( debug ) atmCktState ( debug ) atmCT ( debug ) atmDebug0 ( debug ) atmDebug1 ( debug ) atmDel ( debug )

Stinger® Administration Guide 2-13

Working with Stinger Shelves and Modules

Changing a module’s state

atmDpRam ( debug ) [More? <ret>=next entry, <sp>=next page, <^C>=abort]

For information about module-level commands, see the Stinger Reference.

Changing a module’s state

You can temporarily start or stop the operation of a module, put it in maintenance mode, or reset it by using the slot command or by setting the reqd-state parameter in the slot-admin profile. This feature is particularly useful while performing maintenance operations, when you might want to replace a failed module without deleting its configuration.

Using the slot command

The slot command allows you to control the state of an installed module. For the syntax of the slot command, see the Stinger Reference.

To temporarily stop the operation of a module, use the slot command with the -d option, and specify the module’s shelf and slot number. For example:

admin> slot -d 1 3 slot 1/3 state change forced

When you stop a module’s operation with the slot command, it remains disabled only until the next reboot, and retains its configuration.

To start the operation of a module, use the slot command with the -u option, and specify the module’s shelf and slot number. For example:

admin> slot -u 1 3 slot 1/3 state change forced

Note You cannot change the state of a secondary control module by using the slot

-u or slot -d commands.

To put a module in maintenance state, use the -m option. For example:

admin> slot -m 1 3 Slot 1/1, state change forced warning: new state will remain until next explicit management action.

To reset a module, use the slot command with the -b option, and specify the shelf and slot number of the module you want to reset (bounce). For example:

admin> slot -b 1 3 slot 1/3 state change forced

Using slot-admin profiles

You can also change the state of a slot and its module using the reqd-state parameter in the slot-admin profile.

The following commands display the contents of the slot-admin profile for the module in slot 1. The parameter descriptions follow the profile listing.

admin> read slot-admin {1 1 0} SLOT-STATE/{ shelf-1 slot-1 0 } read

2-14 Stinger® Administration Guide

admin> list [in SLOT-ADMIN/{ shelf-1 slot-1 0 }] slot-address* = { shelf-1 slot-1 0 } reqd-state = reqd-state-up

Parameter Setting

slot-address Address of the slot.

reqd-state

Required operational state of the slot. If you change the value of this parameter to nonoperational, you temporarily disable a slot and its module. The change in status is complete when the setting of current-state parameter has changed to match the setting of the reqd-state parameter. The unit retains this setting only until you reset the system or remove power to the unit.

At system startup, the system reinitializes the required state to match the actual state of the module. Specify one of the following values:



reqd-state-down—Requires the device to be in an inactive, nonoperational state.



reqd-state-up—Requires the device to be in a normal operating state.



reqd-state-maint—Requires the device be in a nonoperational maintenance state.

Working with Stinger Shelves and Modules

Changing the state of a module’s interface

The following sample commands disable a slot:

admin> read slot-admin {1 3 0} SLOT-STATE/{ shelf-1 slot-3 0 } read

admin> set reqd-state = reqd-state-down

admin> write SLOT-STATE/{shelf-1 slot-3 0} written

The following commands return a slot to normal operating mode:

admin> set reqd-state = reqd-state-up

admin> write SLOT-STATE/{ shelf-1 slot-3 0} written

Changing the state of a module’s interface

You can change the state of an interface on a module by entering the device command or by setting the reqd-state parameter in the device-state profile. An interface is specified by its interface address, which consists of the shelf number (always 1), slot number, item number, and logical item number (if necessary) of the interface.

Using the device command

The device command initiates a state change to a specified interface on a module. You typically use this command to administratively disable or enable an interface.

Stinger® Administration Guide 2-15

Working with Stinger Shelves and Modules

Changing the state of a module’s interface

For example, to administratively disable port 24 on a module in slot 3, use the device command with the -d option as follows:

admin> device -d {{1 3 24} 0} device { { 1 3 24 } 0 } state change forced

To reenable the port, use the device command with the -u option as follows:

admin> device -u {{1 3 24} 0} device { { 1 3 24 } 0 } state change forced

Using the device-state profile

Every host interface or network interface on a Stinger unit has a device-state profile, which stores the current state of an interface and allows you to change it.

The following commands display the device profile for port 24 in slot 3. The description of the parameters follow the profile listing.

admin> read device-state {{1 3 24} 0} DEVICE-STATE/{ { shelf-1 slot-3 24 } 0 } read

admin> list device-address* = { { shelf-1 slot-3 24 } 0 } device-state = down-dev-state up-status = idle-up-status reqd-state = up-reqd-state

Parameter Setting

device-address Address of the device whose state is stored in this profile,

defined by the address {{shelf slot item}} logical item}.

device-state Current operational state of the interface, which can be down-

dev-state, up-dev-state, or none. A status of none indicates

that the interface does not exist on the unit.

up-status

Status of an operational interface. This parameter is valid only if the device-state parameter is set to up-dev-state. An operational interface displays one of the the following values:



idle—Interface is not in use.



reserved—Interface is not used until all idle interfaces of the same type are in use.



assigned—Interface is in use.

reqd-state Required operational state of the interface, which can be up-

reqd-state or down-reqd-state. Changing this value initiates a

state change for the interface. The change is complete when device-state parameter changes to match the reqd-state parameter. A Stinger system retains this setting only until you reset or remove power to the unit. At system startup, the system reinitializes the required state to match the actual state of the interface.

2-16 Stinger® Administration Guide

Working with Stinger Shelves and Modules

Removing a module and its configuration

The following commands disable port 24 on the device installed in slot 3:

admin> read device-state {{1 3 24} 0} DEVICE-STATE/{ { shelf-1 slot-3 24 } 0 } read

admin> set reqd-state = down-reqd-state

admin> write DEVICE-STATE/{ { shelf-1 slot-3 24 } 0 } written

Removing a module and its configuration

Stinger FS, Stinger FS+, Stinger LS, Stinger RT and Compact Remote modules are hot-swappable. When you remove a module, the system retains its configuration. You can reinstall a module or install another of the same type in the same slot without reconfiguring the system or uploading a backup configuration. Keep in mind that when you remove a module, the NVRAM used to store configuration information is not cleared until you explicitly clear the configuration.

When you remove a module from a Stinger system, the show command reports a value of NONE for the empty slot. For example:

admin> show 1 4 Controller { first-control-module } ( PRIMARY ):

Reqd Oper Slot Type { second-control-module } UP UP ( SECONDARY ) { shelf-1 slot-4 0 } UP NONE stngr-32-idsl-card:

The status NONE indicates that the module was removed, but its profiles have been saved. The Stinger system saves the profile of modules that you have removed until you install a module of a different type in the same slot, or until you enter the slot -

r command, as in the following example:

admin> slot -r 4 slot 1/4 removed

In either case, the system deletes all the old profiles associated with the slot. If you insert a different type of module, the system creates the appropriate new profiles.

Removing LIMs that use system-generated ATM addresses

In a Stinger unit enabled for Private Network-to-Network Interface (PNNI) protocol, the system generates a unique ATM address for each ATM interface via the AtmInterfaceSoftPvcAddressTable. These ATM addresses are used as the target address (atmSoftPvccTargetAddress) during the creation of a soft permanent virtual circuit (SPVC). The system generates the ATM addresses based on the LIM serial number, using the following formula:

SPVC address = pnni-node-prefix + LIM-serial-number + port-number

For details, see the Stinger Private Network-to-Network Interface (PNNI) Supplement.

Replacing a LIM and retaining the existing ATM addresses on the slot

If you replace a LIM and wish to retain the existing ATM addresses for the slot (whether the addresses were generated by the system or assigned explicitly), do not use the the slot. The system recognizes the existing ATM addresses and does not generate

slot -r command. Simply remove the old LIM and insert the new LIM into

Stinger® Administration Guide 2-17

Working with Stinger Shelves and Modules

Recovering from a failed module installation

new ones. An SPVC initiator switch can reestablish subscriber SPVCs, because the SPVC addresses have not changed.

Moving a LIM that uses system-generated ATM addresses

If you move a LIM to a slot that does not already have assigned ATM addresses, you must remove the configuration from the previous slot by using the Otherwise, when you insert the LIM into the new slot, the system generates new ATM addresses using the same formula based on the serial number of this LIM, which results in duplicate ATM addresses for the interfaces in two slots. If duplicate ATM addresses occur on multiple LIM interfaces, calls can be established only on one of the interfaces.

For example, suppose slot 4 contains a LIM that will be moved to slot N, and the LIM interfaces have system-generated ATM addresses based on the serial number of the LIM. Slot N has no addresses configured (for example, it has never been used or its configuration has been removed via procedure:

1 Remove the LIM from slot 4.

2 Delete the configuration by using the slot -r command. For example:

slot -r). To move the LIM, you must follow this

slot -r command.

admin> slot -r 4

3 Insert the LIM into its new slot.

4 Save the new configuration using the save command.

After the move, slot 4 has no addresses configured. In slot system-generated ATM addresses based on the serial number of the LIM. Saving the new configuration is recommended, to avoid the possibility of restoring old ATM address assignments.

Note If existing subscriber loops are connected to the LIM and you remove the

configuration by using the

slot -r command, when you insert a new LIM in that slot,

the interfaces will have new ATM addresses. In that case, you must inform the SPVC initiator switch of the new ATM addresses associated with the LIM to enable the switch to reestablish the subscriber SPVCs.

Recovering from a failed module installation

If you installed a new module in a Stinger FS, Stinger FS+, Stinger LS, or Stinger RT unit before upgrading the system software, and the module does not begin operating properly, you can attempt to recover using one of the following methods:



Use the nvram command.



Remove the module.

N, the LIM interfaces have

Using the nvram command

Caution Using the nvram command resets the entire system. You cannot perform

this task remotely because the nvram command clears the Stinger unit configuration, including its IP address. Before performing this procedure, make sure that you have access to the Stinger unit’s serial port.

2-18 Stinger® Administration Guide

Working with Stinger Shelves and Modules

Recovering from a failed module installation

To recover from a failed module installation using the nvram command, proceed as follows:

1 Save the current system configuration. For example:

admin> save network bonzo 971001

This command saves the configuration to a file named 971001 in the TFTP home directory on a host named bonzo.

2 Clear the system configuration and restart the Stinger unit by entering the nvram

command:

admin> nvram

3 Restore the saved system configuration.

You can restore the configuration through the serial port, or you can reassign an IP address and default gateway through the serial port, then use the load command to load the rest of the configuration, as in the following example:

admin> load config network bonzo 971001

This command restores the configuration from a file named 971001 in the TFTP home directory on a host named bonzo.

For a complete description of saving and restoring configurations, see Chapter 1, “Administering a Stinger System”

Removing the module

To recover from a failed module installation by removing the module:

1 Save the current configuration of any profiles on the module. For example:

admin> save network bonzo 971001 ds3-atm

This command saves the configuration of all DS3-ATM profiles for this trunk module to a file named 971001 in the TFTP home directory on a host named bonzo.

2 Stop the module’s operation, as in the following example:

admin> slot -d 1 1

This command disables the module in shelf 1, slot 1.

3 Remove the module profile:

admin> slot -r 1 1

4 Reenable the module:

admin> slot -u 1 1

5 Restore the configuration of any profiles on the module. For the DS3-ATM trunk

module in this example, you enter the following command:

admin> load config network bonzo 971001

This command restores the configuration from a file named 971001 in the TFTP home directory on a host named bonzo.

Stinger® Administration Guide 2-19

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

Configuring call logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-12

The Stinger unit monitors itself continuously and generates error and event messages related to its operations. It also monitors itself for alarm events, such as failures and state changes. For information about remote monitoring using SNMP, see “Administering the SNMP Agent” on page 7-1.

Configuring system logging and Syslog services

The Stinger unit generates error and event messages related to its operations. You can use the log profile to perform the following tasks:



Configure how the system handles log messages that are displayed on a status window. (See also, “Setting log levels for each login” on page 1-24.)



Enable and configure the system to save log messages to the Syslog server.

Overview of log profile parameters

The following commands display the contents of the log profile and auxiliarysyslog subprofile, shown with default settings. Parameter descriptions follow the

profile listing.

[in LOG] save-level = info save-number = 100 software-debug = no call-info = none syslog-enabled = no host = 0.0.0.0 port = 514 facility = local0 syslog-format = tnt log-call-progress = no log-software-version = no syslog-level = info auxiliary-syslog = [ { no info 0.0.0.0 514 local0 } { no info 0.0.0.0 514 local

Stinger® Administration Guide 3-1

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

admin> list auxiliary-syslog [in LOG:auxiliary-syslog] auxiliary-syslog[1] = { no info 0.0.0.0 514 local0 } auxiliary-syslog[2] = { no info 0.0.0.0 514 local0 }

admin> list 1 [in LOG:auxiliary-syslog[1]] syslog-enabled = no syslog-level = info host = 0.0.0.0 port = 514 facility = local0

Parameter Setting

save-number Maximum number of log messages that the Stinger unit saves

for display in the status windows.

save-level Lowest level of log messages that the Stinger unit displays in

the log status window. The unit logs all messages that are at the specified level or higher. For example, if alert is specified, all messages at the alert and emergency levels are logged. Specify one of the following settings:



none (the default)—Displays no log messages.



emergency—Announces error conditions that are likely to prevent normal operation.



alert—Announces error conditions that do not prevent normal operation.



critical—Announces interface failures and security errors.



error—Announces error events.



warning—Displays unusual events that do not affect normal operation.



notice—Displays operational events of interest.



info—Displays state and status changes.



debug—Displays helpful debug information.

The save-level parameter does not control the level of syslog records sent to a syslog server.

call-info

Does not apply to the Stinger unit.

syslog-enabled Enable/disable the forwarding of log messages to a syslog

server.

host Domain Name System (DNS) hostname or address of a syslog

host for the first data stream.

In the auxiliary-syslog [1] subprofile, the host value specifies the host to which the unit sends syslog messages for the second data stream. In the auxiliary-syslog [1] subprofile, the host value specifies the host to which the unit sends syslog messages for the third data stream.

3-2 Stinger® Administration Guide

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

Parameter Setting

port Destination port of the syslog host that receives the first data

stream.

In the auxiliary-syslog [1] subprofile, the port value specifies the destination port of the syslog host that receives the second data stream. In the auxiliary-syslog [1] subprofile, the port value specifies the destination port of the

syslog host that receives the third data stream.

facility Syslog daemon facility code for messages logged from the

Stinger unit. For detailed information, see the syslog.conf manual page entry on the UNIX syslog server. Specify one of the following settings:



local0 (the default)



local1



local2



local3



local4



local5



local6



local7

In the auxiliary-syslog [1] subprofile, the facility value applies to the second data stream.

In the auxiliary-syslog [2] subprofile, the facility value applies to the third data stream.

The settings in each auxiliary-syslog subprofile affect an individual syslog stream, and override the setting in the log profile.

log-callprogress

Enable/disable the unit to log incoming call-progress messages. Specify one of the following values:



yes—The unit logs incoming call-progress messages.s



no (the default)—The unit discards incoming call-progress messages.

log-softwareversion

Enable/disable the hourly log message reporting of the current software version to the syslog host. Specify yes to enable hourly log messages reporting the current software version or no (the default) to disable it. If debug permission is enabled, the messages are displayed on the screen (as well as sent to the syslog host).

Stinger® Administration Guide 3-3

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

Parameter Setting

syslog-level Lowest level of log messages that the Stinger unit sends to the

syslog server. All levels above the level you indicate are

included in your syslog messages. For example, if alert is specified, messages at the emergency and alert levels are included. Values are the same as those for save-level on page 3-2.

By default, syslog records with a level of debug are filtered out, and records with a level of info or above are transmitted to the syslog server.

The syslog-level value in the log profile affects all data streams. The syslog-level value in each auxiliary syslog subprofile affects the individual data stream directed to the device specified by the host value, and overrides the value in the log profile.

auxiliarysyslog [1]

auxiliarysyslog [2]

Configuring system logging

The Stinger unit records system events in its status window event log. (For additional information, see “Log message information” on page 1-33.)

The save-level parameter specifies the lowest level of message to be saved for status display. The lowest possible level is none (the default). The highest level is debug. For a list of the log message levels, see the description of save-level on page 3-2.

The save-number parameter specifies the number of messages to be saved in the status display. The default is 100.

The following commands configure the Stinger unit to save 200 messages in the event log and to display emergency type messages on the status display:

admin> read log LOG read

admin> set save-level = emergency

admin> set save-number = 200

admin> write LOG written

Subprofile that specifies the settings for the syslog server for the second data stream.

Subprofile that specifies the settings for the syslog server for the third data stream.

Enabling command logging

You can configure a Stinger system to log command-line interface (CLI) commands issued by system users. You can use these command logs to determine if certain system failures are caused by user configuration errors.

The history-size parameter in the log profile enables or disables command logging for a system. To enable command logging, specify the number of commands entered by users that the system logs. Valid values are from 0 through 1000. With the default

3-4 Stinger® Administration Guide

setting of zero (0), command logging is disabled for a Stinger system (the system logs no user commands). To enable command logging, set this parameter to a value greater than zero. For example, the following commands configure the system to save up to 100 commands:

admin> read log LOG read admin> set history-size = 100

admin> write -f LOG written

If the history-size parameter is set to a value other than 0, consider saving the existing command logs before changing its value. The system deletes all existing command logs when a users resets the value of the history-size parameter. See “Saving command logs” on page 3-7 for more information. If the new setting is 0, the system deletes all existing command logs, but logs no new commands. If the new setting is a value other than 0, the system deletes all existing command logs and starts logging commands for the new history size.

Viewing command logs

To view command logs, use the history command or display the cmd-log profiles. For security reasons, consider limiting user access to the history command and the cmd- log profiles to users with System privileges. You can use a user-group profile to restrict access to the history commands and the cmd-log profiles. For more information about configuring group privileges to commands and profiles using the user-group profile, see“Specifying a command user group for a user” on page 1-21 and “Restricting access to profiles” on page 1-22.

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

Using the history command

The history command displays command logs to the terminal session.

Following is a sample output of the history command, followed by a description of the fields in the output:

admin> history Date Time Source User Id Card Command 11/13/2003 16:31:00 console admin 01 {01 08} history 11/13/2003 16:30:52 135.17.134.39 user2 03 {01 08} quit 11/13/2003 16:30:49 135.17.134.39 user2 03 {01 08} save c log 11/13/2003 16:30:41 135.17.134.39 user2 03 {01 08} dir cmd-log 11/13/2003 16:30:32 135.17.134.39 user2 03 {01 08} help 11/13/2003 16:30:29 135.17.134.39 user2 03 {01 08} atmcacstat 11/13/2003 16:30:25 135.17.134.39 user2 03 {01 08} show 11/13/2003 16:30:16 135.17.134.39 user1 02 {01 08} quit 11/13/2003 16:30:07 135.17.134.39 user1 02 {01 08} history 11/13/2003 16:29:58 135.17.134.39 user1 02 {01 08} dir

Field Indicates

Date

Time

Date the command was entered.

Time the command was entered

Stinger® Administration Guide 3-5

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

Field Indicates

Source

How the user initiated the session, for example, via telnet or by connecting to the serial port.

User

The user profile associated with the user who entered the command.

Card

Command

User session ID number.

Shelf and slot number from which the command was entered.

Command entered by the user.

Viewing the cmd-log profile

If command logging is enabled, the system creates a cmd-log profile for every command entered by a user. The cmd-log profile contains read-only parameters that provide details about a logged command entry.

Following is a listing of a sample cmd-log profile with an index number of 92. The description of the parameters follow the profile listing.

admin> read cmd-log 92 CMD-LOG/92 read

admin> list [in CMD-LOG/92] user = admin session-id = 2 login-source = console log-date = { Friday November 2003 7 } log-time = { 6 58 12 } information = "dir cmd-log" index* = 92 shelf = 1 slot = 9

Parameter Specifies

user The user profile associated with the administrator who entered

the command.

session-id ID number of the user session.

telnet or the serial port, and so forth.

log-date Date the command log was generated, in the format { Weekday

Month Year Date }.

log-time Time the command was entered, in the format { Hour Minute

Second }.

information Command-line interface command entered by the user.

shelf Shelf number on which the command issued.

slot Slot number on which the CLI command issued.

index Index number of the command log.

3-6 Stinger® Administration Guide

Saving command logs

You can save command log profiles to a file in the flash card or to a remote system using the save command. For example:

admin> save -a 1/current/cmd.log cmd-log

Note You cannot save cmd-log profiles with other system profiles.

For more information about using the save command, see the Stinger Reference.

Storing log messages across system resets

You can store log messages across system resets by saving log messages as profiles. System logs are saved in volatile memory and are erased during system resets. You can optionally save each log message as profile, which is saved in system NVRAM. These message profiles are then retained across system resets. This feature can help determine the cause of an unexpected system reset.

This feature is available only in the debug environment. That is, in the user profile, allow-debug must be set to yes.

Note Limit the use of this feature for debugging purposes only. Enabling this feature

causes the system to constantly access NVRAM while creating log messages. It should not be provisioned on regular systems.

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

How it works

The system classifies each log message for storage purpose as one of the following types:



boot message—log message that is generated before a device (controller card or slot module) reaches the Operational UP state.



runtime message—log message that is generated after a device is in the Operational Up state.

Boot message logging includes all messages from system power up until slot POST test is completed. After the slots are up, if a slot reverts to slot down, slot POST test, slot none or slot diagnostic states, the system collects boot log messages again until slot POST test is completed.

After system initialization, to indicate the start of runtime message logging, the system generates an INFO log message, Post done & start runtime log.

If enabled, a Stinger system saves log messages generated from control modules (controllers), line interface modules (LIMs), Compact Remote units, MRT controllers and remote LIMs as profile log-entry.

Stinger® Administration Guide 3-7

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

Enabling the system to save log messages as profiles

The following parameters in the log profile enable the saving of a log message as a profile. These parameters are visible only if in the user profile, allow-debug is set to yes.

Parameter Specifies

boot-level Lowest level of boot log message to be saved. Valid

values (shown from highest to lowest level) are:



run-time-level Lowest level of runtime log message to be saved.

Valid values (shown from highest to lowest level) are:



emergency—Critical event has occured; normal operation is doubtful.

alert—Undesired event has occurred, but normal operation can probably continue.

critical—An interface is disabled or a security error has occured.

error—Unexpected event has occured.

none (the default)—No log messages are saved

or displayed.

emergency—Critical event has occured; normal operation is doubtful.

alert—Undesired event has occurred, but normal operation can probably continue.

critical—An interface is disabled or a security error has occured.

error—Unexpected event has occured.

none (the default)—No log messages are saved

or displayed

By default, the system does not save log messages as profiles. For the system to save boot and runtime messages as profiles, set the boot-level and run-time-level parameters, respectively, to values other than none. For example:

admin> set boot-level = critical

admin> set run-time-level = critical

The system can store up to 1000 each of boot and runtime log-entry profiles. These profiles are stored in circular queue. When the system has saved save 100 boot messages, it discards the oldest boot log profile for every new boot log message saved.

To disable the saving of log messages, set the parameters to none. Saved log messages are not erased when you disable this feature.

The system automatically disables the saving of log messages 24 hours from the time you set the boot-level or run-time-level parameter to a value other than none.

3-8 Stinger® Administration Guide

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

If the system undergoes a reset for any reason while logging is enabled, the system disables logging during reinitialization. Note that saved logs are retained during initialization.

If you restore an saved configuration in which log saving enabled, the system will ignore the restored setting and will continue to use the existing setting.

Viewing log-entry profiles

You can save log-entry profiles to a file in the system flash card or to another device on the network. The log command displays log message profiles to the system user screen or saving them to a file in flash card or to a remote system.

The system does not save log-entry profiles to the system config file when you save system configuration. However, you can save log-entry profiles to a file using the specific profile option. For example:

admin> save -a 1/current/system.log log-entry

Using the log command

To display log-entry profile contents to a user terminal or to save it to a file in flash or to remote system, use the log command with the -d option. The command syntax is follows:

log -s [-b|-r] <target> dump log

Replace target with the console, flash, or network options. You can opt to display boot messages only (-b option) or runtime messages only (-r option). For example:

admin> log -s -b c Date Time Source Level Description 06/04/2004 03:23:39 shelf-3/first-contro alert Saving of system logs as profile is disabled

For more information about the log command, see the Stinger Reference.

Overview of the log-entry profile

The contents of the log-entry profile have read-only access. Following is a sample listing of log-entry profile, followed by parameter descriptions:

[in LOG-ENTRY/{ boot 11 }] log-entry-index* = { boot 11 } date = { Sunday February 2004 8 } time = { 8 22 17 } level = info shelf = shelf-1 slot = first-control-module message = "Initialization complete, starting normal operation"

[in LOG-ENTRY/{ boot 11 }:log-entry-index] log-type = boot

Stinger® Administration Guide 3-9

Configuring logging, Syslog, and call logging services

Configuring system logging and Syslog services

index = 11

Parameter Specifies

log-type Type of log message saved—boot for boot log messages or run-

time for runtime log messages.

index Instance of a particular type of log entry (boot or runtime). This

value is incremented by 1 every time an instance of the type of log occurs.

date

Date when the log was saved.

time Time when the log was saved.

level Level of the log message. Reported values can be one of the

following:



none—No log messages are saved or displayed.



emergency—Critical event has occurred; normal operation is doubtful.



alert—Undesired event has occurred; normal operation can probably continue.



critical—An interface is disabled or a security error has occured.



error—Unexpected event has occured.

shelf

Shelf number on which the message was logged. Reported values can be one of the following:



any-shelf—Special value used to specify any shelf.



shelf-n—Shelf number from 1 through 25.

slot

Slot number on which the message was logged. Reported values are:



any-slot—Any slot.



slot-x—Slot number from 1 through 7 or 10 through 16.



first-control-module—The control module in slot 8.



second-control-module—The control module in slot 9.



trunk-module-1—Trunk Module 1 pseudo slot.



trunk-module-2—Trunk Module 2 pseudo slot.



control-module—The control module pseudo-slot. -STNGR only

message

Log information. Text field, 255 characters

Configuring the Stinger unit Syslog facility

By configuring the Stinger unit to report events to a syslog host on the local IP network, you can maintain a permanent log of events and send Call Detail Reporting (CDR) reports to a host that can record and process them.

The host running a syslog daemon is typically a UNIX host, but it can also be a Microsoft Windows system. If the log host is not on the same subnet as the Stinger

3-10 Stinger® Administration Guide

Configuring logging, Syslog, and call logging services

unit, the unit must have a route to that host, either via RIP or a static route. (For information about syslog messages, see “Syslog messages” on page B-7.)

Note Do not configure the Stinger to send reports to a syslog host that can be

reached only by a dial-up connection. Doing so causes the Stinger unit to dial the log host for every logged action, including hangups.

Enabling the Syslog facility on the Stinger unit

The following sample commands enable syslog reporting

admin> read log LOG read

admin> set syslog-enabled = yes

Configuring Syslog streams

The stream of records sent by the Stinger unit to a syslog server is called a syslog stream. The Stinger unit supports up to three syslog servers and define an

independent syslog stream for each server.

For example, you can define a syslog stream to transfer all records, another stream to transfer records with a severity level of warning or above, and a third stream to transfer records with a severity level of emergency.

Configuring system logging and Syslog services

The syslog-format parameter controls the format of all syslog streams. The parameters in the log profile and two auxiliary syslog subprofiles configure the syslog streams as follows:



The syslog-level, host, port, and facility settings in the log profile affect the first data stream.



The syslog-level, host, port, and facility settings in the auxiliary-syslog [1] subprofile affect the second data stream and override the settings in the log

profile.



The syslog-level, host, port, and facility settings in the auxiliary-syslog [2] subprofile affect the the third data stream and override the settings in the log

profile.

The following sample commands define the first data stream and direct the Stinger unit to send end-of-call syslog messages to the host 10.2.3.4 on port 588:

admin> read log LOG read

admin> set host = 10.2.3.4

admin> set port = 588

admin> set facility = local0

admin> write LOG written

Note After setting a log facility number, configure the syslog daemon to write all

messages containing that facility number to a particular log file. This file is the Stinger log file.

Stinger® Administration Guide 3-11

Configuring logging, Syslog, and call logging services

Configuring call logging

Specifying a session ID base

The sessionid-base parameter in the system profile specifies the base number to use for generating a unique ID for each session. The system uses this value to identify the session to SNMP, RADIUS, or other external entities. If this parameter is set to zero, the Stinger unit sets the initial base for session IDs to the absolute clock. For details about this parameter, see the Stinger Reference.

Configuring the Syslog daemon

To configure the syslog daemon to interact with a Stinger system, you must modify the file /etc/syslog.conf on the host. This file specifies the action that the daemon performs when it receives messages from a particular log facility number (which represents the Stinger).

For example, if you set the log parameter facility to local5 in the Stinger unit, and want to log its messages in /var/log/Stinger01, add the following line to

/etc/syslog.conf:

local5.info<tab>/var/log/Stinger01

Note The syslog daemon must reread /etc/syslog.conf after it has been changed.

Configuring call logging

The call-logging protocol supports real-time surveillance of Stinger units using the Navis™ family of network management products. If configured, it allows NavisAccess™ 5.1 and later releases to monitor, report, and send alarms on various performance and failure information for the Stinger unit. For additional information, go to http://www.lucent.com/products/ and search on NavisAccess.

Overview of call logging

The main purpose of Stinger call logging is to provide details about physical-layer line statistics to a management station for all active DSL OC3, DS3, and E3 trunk lines in a Stinger unit.

The Stinger unit uses a method called streaming to periodically collect call-logging data and send it to call-logging servers in an evenly distributed manner.

Once you have configured call logging, the Stinger unit sends Start Session, Stop Session, and Streaming packets to a call-logging server. A call-logging server is a local host that is configured to communicate with the Stinger, such as a host running NavisAccess™ software.

DSL statistics are generated on the DSL drivers of Stinger LIMs and trunk modules. These statistics are propagated to the management station by means of the calllogging protocol. The call-logging packets on the Stinger unit deliver ADSL, SDSL, HDSL, SHDSL, IDSL, OC3, E3, or DS3 statistics about the physical layer.

Note Call logging for the Stinger unit is supported by NavisAccess™ 5.1 or later

releases.

3-12 Stinger® Administration Guide

Enabling call logging

To enable Stinger call logging to a call-logging server on the local network, proceed as in the following example:

1 Read in the call-logging profile:

admin> read call-logging CALL-LOGGING read

2 Enable call logging:

admin> set call-log-enable = yes

3 Specify the IP address of a call-logging host:

admin> set call-log-host-1 = 10.2.3.4

4 Specify the number of seconds that the Stinger unit waits for a response to a call-

logging request:

admin> set call-log-timeout = 10

5 Specify that the unit can send a stop packet without a username:

admin> set call-log-stop-only = yes

6 Specify a retry limit in seconds for call-logging requests to the host:

admin> set call-log-limit-retry = 3

7 Write the profile to save the changes:

admin> write CALL-LOGGING written

Configuring logging, Syslog, and call logging services

Configuring call logging

Stinger® Administration Guide 3-13

Monitoring System and Network Processor operations

Maintaining ASIC Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

Optimizing system performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-4

Monitoring network processor operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-7

Maintaining ASIC Integrity

A Stinger unit includes mechanisms for maintaining the integrity of ATM cellprocessing application-specific integrated circuits (ASICs) for control modules and line-interface modules (LIMs).

Because the ATM cell-processing application-specific integrated circuits (ASICs) are so central to the unit’s performance, error detection and correction mechanisms are supported for both the control module and LIM ASICs.

The default system-integrity profile configuration for control modules enables continuous background testing of the control module ASIC. Lucent Technologies recommends that you do not disable this default.

The default system-integrity configuration for LIM testing is a periodic integrity test for those LIMs that support it, and a periodic reset for earlier LIMs that are not equipped for integrity testing (STGR-LIM-AD-12 and STGR-LIM-SH-48). You can configure the control module to perform LIM integrity testing centrally, as described in “Enabling centralized integrity checks” on page 4-4.

Checking the defaults for control module self-tests

If a problem occurs in the control module’s ATM ASIC, the unit might stop switching data traffic. To prevent this possibility, by default, the system performs background integrity tests of the control module ASIC at a specified interval of 100 milliseconds. The system keeps track of the past 20 integrity tests, and verifies after each test how many failures have occurred in the previous 20 tests. If this failure rate is higher than the configured correction factor, the control module performs a correction by resetting its ASIC.

Following are the integrity-config subprofile settings, shown with default values for a control module in slot 8. With the default configuration, continuous checking is enabled, and Lucent Technologies recommends that you keep this default.

[in SYSTEM-INTEGRITY:integrity-config[8]] enable-continuous-detection = yes detection-interval = 100

Stinger® Administration Guide 4-1

Monitoring System and Network Processor operations

Maintaining ASIC Integrity

only-one-correction = yes correction-factor = 5 auto-correction-enable = yes interval-auto-correction = 600000

Parameter Setting

enable-continuousdetection

detection-interval

only-one-correction Enable/disable multiple corrections in a row. The

correction-factor Number of problems that must be detected in the

auto-correctionenable

interval-autocorrection

Enable/disable detection and correction in continuous mode. The default of yes is recommended for the control modules.

Detection interval in milliseconds. When continuous detection is enabled, the control module performs integrity tests at defined intervals. Valid values are from 0 to 65535.

Note The default value of 100ms is recommended for

control modules.

default yes value causes the system to apply the ASIC correction only once. Only one correction is recommended.

previous 20 integrity tests to cause a correction. With the default value of 5, a correction results if the system detects five problems in its history of 20 previous tests. Valid values are from 1 to 20.

Does not apply to control modules.

LIM automatic correction settings

By default, detection and correction of the LIM ASICs are performed every few hours or at a specified interval. For earlier LIMs that are not equipped for integrity testing (STGR-LIM-AD-12 and STGR-LIM-SH-48), the ASIC is simply reset automatically. For recent LIMs that can perform integrity testing, instead of an automatic correction, an integrity test is performed every few hours and the ASIC is corrected only if a problem is detected.

Following are the integrity-config settings for LIM ASIC integrity testing, shown with default values for a LIM in slot 1:

[in SYSTEM-INTEGRITY:integrity-config[1]] enable-continuous-detection = no detection-interval = 100 only-one-correction = yes correction-factor = 5

4-2 Stinger® Administration Guide

Monitoring System and Network Processor operations

auto-correction-enable = yes interval-auto-correction = 600000

Parameter Setting

Maintaining ASIC Integrity

enable-continuousdetection

Enable/disable detection and correction in continuous mode. The default value is no for LIM slots, which allows sufficient correction for most LIMs while conserving system resources.

detection-interval

Detection interval in milliseconds. The default value is 100ms. Valid values are from 0 to 65535. When continuous detection is enabled, the LIM performs integrity tests at the defined interval.

only-one-correction Enable/disable multiple corrections in a row. If the unit

is configured to perform only one correction, after resetting the ASIC, the control module erases the previous 20 tests and begins again. This mechanism prevents multiple resets if the past few tests have failed continuously, and is the recommended setting.

correction-factor Number of problems that must be detected in the

previous 20 integrity tests to cause a correction. Valid values are from 1 to 20. The default is 5.

auto-correctionenable

Enable/disable automatic correction for the LIM. With the default yes value, the LIM performs an integrity test (for LIMs equipped for integrity testing) or performs a correction at the interval specified by the interval-auto-corection parameter. If this parameter is set to no, the LIM performs these actions every 2 to 3 hours.

interval-autocorrection

Number of milliseconds between LIM automatic correction actions. The default is 600000ms (10 minutes). Valid values are from 0 to 2147483647.

For example, the following commands verify that a 12-port SDSL LIM resides in slot 14 and change the automatic correction interval for that LIM to 1 hour:

admin> show Controller { first-control-module } ( PRIMARY ): Reqd Oper Slot Type { shelf-1 slot-3 0 } UP UP dadsl-atm-24-card { shelf-1 slot-14 0 } UP UP sdsl-atm-card { shelf-1 trunk-module-1 0 } UP UP ds3-atm-trunk-daughter-card { shelf-1 trunk-module-2 0 } UP UP oc3-atm-trunk-daughter-card

admin> read system-integrity SYSTEM-INTEGRITY read

admin> set integrity-config 14 interval-auto-correction = 3600000

admin> write SYSTEM-INTEGRITY written

Stinger® Administration Guide 4-3

Monitoring System and Network Processor operations

Optimizing system performance

Enabling centralized integrity checks

In addition to the periodic automatic correction performed by the LIMs, you can enable centralized detection, which causes the control module to perform integrity tests on every LIM in the unit that is equipped for ASIC testing. If a LIM requires correction, the control module sends a message causing the LIM to reset its ASIC. If the LIM problem is not corrected within 5 minutes, the control module resets the LIM ASIC again and also resets its own ASIC. Resetting both the control module and LIM ASICs at the same time clears most problems.

Note By default, all LIMs are corrected every few hours, which is typically sufficient

for most LIMs.

Following are the relevant parameters, shown with default values:

[in SYSTEM-INTEGRITY] enable-centralized-detection = no ratio-centralized-detection = 5

Parameter Setting

enable-centralizeddetection

ratio-centralizeddetection

For example, the following commands enable centralized detection and specify a ratio of 100. Because the control module self-tests are performed every 100ms by default, this ratio causes the control module to perform LIM testing every 10 seconds.

admin> read system-integrity SYSTEM-INTEGRITY read

admin> set enable-centralized-detection = yes

admin> set ratio-centralized-detection = 100

admin> write SYSTEM-INTEGRITY written

Enable/disable centralized error detection. This option is disabled by default. If the parameter is set to yes, the control module is required to perform LIM testing using its own failure ratio and correction setting. If a LIM requires a reset of the ASIC, the control module sends a message to the LIM to initiate the reset. If the reset does not correct the detected problem within 5 minutes, the control module initiates a second LIM reset and simultaneously resets its own ASIC.

If centralized detection is enabled, this parameter specifies the ratio of problem detection between the control module and all other modules. For example, if the ratio is 5, the control module performs five selftests before triggering centralized LIM tests. Values can be from 0 to 65535. The default is 5.

Optimizing system performance

The following sections describe recommendations for optimizing performance on systems installed with an IP2000 module.

4-4 Stinger® Administration Guide

Lucent Technologies Stinger Administration Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Customer Service

Finding information and software

Obtaining technical assistance

Obtaining assistance through email or the Internet

Calling the technical assistance center (TAC)

About This Guide

What is in this guide

What you should know

Documentation conventions

Stinger documentation set

Administering a Stinger System

About standalone and hosted Stinger systems

Logging into a Stinger unit

Enabling basic security measures

Changing the default Admin password

Securing the serial port of each control module

Specifying a management-only Ethernet interface

Verifying the Ethernet port status

Securing Telnet access

Managing administrative access to the unit

Logging into the Stinger unit

Creating a new administrative profile

Enabling two level authentication

Specifying the maximum number of login attempts

Authentication from a remote shelf to a host Stinger unit

User account and user password expiration

What happens when a user account or user password expires

RADIUS support for account and password expiration

Setting expiration dates for user accounts and passwords

Enforcing a password check

Changing a user password

Creating Telnet access control lists

Assigning permissions

Understanding command permissions

Specifying group permissions for commands and profile access

Specifying a time-out for user logins

Setting the command-line prompt

Setting log levels for each login

Basic system settings

Logging in as a different user

Displaying the current user

Setting the system name

Setting the system time and date

Viewing the system time and date

Changing the system time

Changing the system date

Configuring system clocking

Displaying the current clock-source

Configuring trunk ports as clock sources

Displaying basic system information

Displaying system hardware information and software version

System and module uptime

Using the status window

Displaying the status window

Understanding the status window

Connection status information

General status information

Line and channel status

Log message information

Customizing the status window display

Changing current status window sizes

Managing administrative connections

Viewing the factory configuration and software licenses

Displaying administrative session information with the userstat command

Customizing the output of the userstat command

Displaying information related to a known IP address

Displaying information related to a known username

Using the view left session command

Displaying administrative users

Terminating a user connection

Disconnecting an idle connection

Resetting a Stinger system

Working with Stinger Shelves and Modules

Understanding physical addressing on Stinger units

Viewing system components

Using the show command