This preface describes who should read the Cisco Service Control Engine (SCE) Software Configuration Guide, how it is organized, and its document conventions.

Document Revision History

Cisco Service Center Release	Part Number	Publication Date
Release 3.0.5	OL-7827-05	November, 2006

Description of Changes

Added the following new feature:

Managing the SCMP

The following sections were added or updated to explain various CLI commands that had not previously appeared in this guide:

Monitoring the Operational Status of the SCE Platform
Monitoring the Connection Mode
Link Failure Reflection in Linecard-Aware Mode (SCE 2000 only)
Removing Subscribers with Tunnel Mappings
Traffic Rules

Cisco Service Center Release	Part Number	Publication Date
Release 3.0.3	OL-7827-04	May, 2006

Description of Changes

Added the following new features:

MPLS/VPN Support (including MPLS/VPN-related changes in Managing Subscribers and Configuring Tunneling Protocols).
Configuring VLAN Translation
VAS over 10G

The Proprietary MIB Reference was reorganized to reflect reorganization of the pcube Enterprise MIB.

Cisco Service Center Release	Part Number	Publication Date
Release 3.0	OL-7827-03	December, 2005

Description of Changes

Added the following new features:

Value Added Services (VAS) Traffic Forwarding
Monitoring SCE Platform Utilization
Configuring the Management Ports for Redundancy
Management Interface Security
TACACS+ Authentication, Authorization and Accounting
Dynamic Mapping of RDRs to Categories

Cisco Service Center Release	Part Number	Publication Date
Release 2.5.7	OL-7827-02	May, 2005

Description of Changes

Complete reorganization and revision of product documentation.

Audience

This guide is for experienced network administrators who are responsible for configuring and maintaining the SCE platform.

Organization

The major sections of this guide are as follows:

Chapter	Title	Description
Chapter 1	Overview	Overview of SCE platform management.
Chapter 2	Command Line Interface	Detailed explanation of how to use the Cisco SCE Command-line Interface.
Chapter 3	Operations	Explanation of how to manage configurations, install applications and upgrade the system software.
Chapter 4	Utilities	Explanation of the setup wizard and the user log, as well as of file operations.
Chapter 5	Configuring the Management Interface and Security	Explanation of how to configure the various management options: Telnet, SSH, and SNMP. Also how to configure the system time,Domain Name Settings, management IP address, and passwords.
Chapter 6	Configuring the Line Interface	Explanation of how to configure tunneling, TOS marking, and traffic rules.
Chapter 7	Configuring the Connection	Explanation of how to configure the connection mode, link mode, and failure behaviors.
Chapter 8	Configuring the RDR Formatter	Explanation of how to configure the RDR Formatter so that RDRs are sent to the proper destinations.
Chapter 9	Managing Subscribers	Explanation of how to import and export subscriber information and how to monitor subscribers.
Chapter 10	Redundancy and Fail-Over	Explanation of how to configure and manage a redundant system. This chapter applies only to the SCE 2000 platform.
Chapter 11	Identifying And Preventing Distributed-Denial-Of-Service Attacks	Explanation of how to configure attack filtering.
Chapter 12	Value Added Services (VAS) Traffic Forwarding	Explanation of Value Added Services (VAS) and how to configure VAS traffic forwarding.
Chapter 13	MPLS/VPN Support	Explanation of MPLS/VPN support, and how to configure and monitor MPLS/VPN subscribers and support.
Chapter 14	Managing the SCMP	Explanation of Service Control Management Protocol (SCMP), which is a protocol that integrates the SCE platform and the ISG (Intelligent Service Gateway) functionality of the Cisco routers. It also explains how to configure and manage SCMP, SCMP peer devices and the RADIUS client.
Appendix A	Monitoring SCE Platform Utilization	Explanation of how to monitor SCE platforms that are installed in real traffic.
Appendix B	Proprietary MIB Reference	Definition of the proprietary Service Control Enterprise MIB.

Related Publications

Your SCE platform and the software running on it contain extensive features and functionality, which are documented in the following resources:

For further information regarding the Service Control CLI and a complete listing of all CLI commands, refer to the Cisco Service Control Engine (SCE) CLI Command Reference
For complete installation information, including initial configuration, refer to the relevant installation guide:
- Cisco SCE 2000 4xGBE Installation and Configuration Guide
- Cisco SCE 2000 4/8xFE Installation and Configuration Guide
- Cisco SCE 1000 2xGBE Installation and Configuration Guide

Note

You can access Cisco software configuration and hardware installation and maintenance documentation on the World Wide Web at Cisco Website URL. Translated documentation is available at the following URL: International Cisco Website

For initial installation and startup information, refer to the relevant quick start guide:
- Cisco SCE 2000 4xGBE Quick Start Guide
- Cisco SCE 2000 4/8xFE Quick Start Guide
- Cisco SCE 1000 2xGBE Quick Start Guide
For international agency compliance, safety, and statutory information for wide-area network (WAN) interfaces for the SCE platform, refer to the regulatory and safety information document:
- Regulatory Compliance and Safety Information for the Cisco Service Control Engine (SCE)
For installation and configuration of the other components of the Service Control Management Suite refer to:
- Cisco Service Control Management Suite Subscriber Manager User Guide
- Cisco Service Control Management Suite Collection Manager User Guide
- Cisco Service Control Application for Broadband User Guide
- Cisco Service Control Application Reporter User Guide
To view Cisco documentation or obtain general information about the documentation, refer to the following sources:
- Obtaining Documentation
- The Cisco Information Packet that shipped with your SCE platform.

Conventions

This document uses the following conventions:

Convention	Description
boldface font	Commands and keywords are in boldface.
italic font	Arguments for which you supply values are in italics.
[ ]	Elements in square brackets are optional.
{x \| y \| z}	Alternative keywords are grouped in braces and separated by vertical bars.
[x \| y \| z]	Optional alternative keywords are grouped in brackets and separated by vertical bars.
string	A nonquoted set of characters. Do not use quotation marks around the string, or the string will include the quotation marks.
`screen` font	Terminal sessions and information that the system displays are in `screen` font.
`boldface screen` font	Information you must enter is in `boldface screen` font.
`italic screen` font	Arguments for which you supply values are in `italic screen` font.
< >	Nonprinting characters, such as passwords, are in angle brackets.
[ ]	Default responses to system prompts are in square brackets.
!, #	An exclamation point (!) or a pound sign (#) at the beginning of a line of code indicates a comment line.

Note

Means reader take note. Notes contain helpful suggestions or references to materials not covered in this manual.

Caution

Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.

Warning

Means reader be warned. In this situation, you might do something that could result in bodily injury.

Obtaining Documentation

The following sections provide sources for obtaining documentation from Cisco Systems.

World Wide Web

You can access the most current Cisco documentation on the World Wide Web at the following sites:

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package that ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.

Ordering Documentation

Cisco documentation is available in the following ways:

Registered Cisco Direct Customers can order Cisco Product documentation from the networking Products MarketPlace:

http://www.cisco.com/public/ordsum.html
Registered Cisco.com users can order the Documentation CD-ROM through the online Subscription Store:

http://www.cisco.com/pcgi-bin/marketplace/welcome.pl
Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco corporate headquarters (California, USA) at 408 526-7208 or, in North America, by calling 800 553-NETS(6387).

Documentation Feedback

If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and selectDocumentation. After you complete the form, click Submit to send it to Cisco.

You can e-mail your comments to bug-doc@cisco.com.

To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:

Attn Document Resource Connection Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.

Cisco.com

Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at any time, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.

Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.

Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.

To access Cisco.com, go to http://www.cisco.com.

Technical Assistance Center

The Cisco Technical Assistance Center (TAC) website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.

Contacting TAC by Using the Cisco TAC Website

If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website http://www.cisco.com/tac.

P3 and P4 level problems are defined as follows:

P3—Your network is degraded. Network functionality is noticeably impaired, but most business operations continue.
P4—You need information or assistance on Cisco product capabilities, product installation, or basic product configuration.

In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.

To register for Cisco.com, go to http://tools.cisco.com/RPF/register/register.do.

If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at http://www.cisco.com/tac/caseopen.

Contacting TAC by Telephone

If you have a priority level 1 (P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml.

P1 and P2 level problems are defined as follows:

P1—Your production network is down, causing a critical impact to business operations if service is not restored quickly. No workaround is available.
P2—Your production network is severely degraded, affecting significant aspects of your business operations. No workaround is available.

Chapter 1. General Overview

This chapter provides a general overview of the Cisco Service Control solution. It introduces the Cisco Service Control concept and the Service Control capabilities. It also briefly describes the hardware capabilities of the Service Control Engine (SCE) platform and the Cisco specific applications that together compose the total Cisco Service Control solution.

The Cisco Service Control Concept

The Cisco Service Control solution is delivered through a combination of purpose-built hardware and specific software solutions that address various service control challenges faced by service providers. The SCE platform is designed to support classification, analysis, and control of Internet/IP traffic.

Service Control enables service providers to create profitable new revenue streams while capitalizing on their existing infrastructure. With the power of Service Control, service providers have the ability to analyze, charge for, and control IP network traffic at multigigabit wire line speeds. The Cisco Service Control solution also gives service providers the tools they need to identify and target high-margin content-based services and to enable their delivery.

As the downturn in the telecommunications industry has shown, IP service providers’ business models need to be reworked to make them profitable. Having spent billions of dollars to build ever larger data links, providers have incurred massive debts and faced rising costs. At the same time, access and bandwidth have become commodities where prices continually fall and profits disappear. Service providers have realized that they must offer value-added services to derive more revenue from the traffic and services running on their networks. However, capturing real profits from IP services requires more than simply running those services over data links; it requires detailed monitoring and precise, real-time control and awareness of services as they are delivered. Cisco provides Service Control solutions that allow the service provider to bridge this gap.

Service Control for Broadband Service Providers

Service providers of any access technology (DSL, cable, mobile, and so on) targeting residential and business consumers must find new ways to get maximum leverage from their existing infrastructure, while differentiating their offerings with enhanced IP services.

The Cisco Service Control Application for Broadband adds a new layer of service intelligence and control to existing networks that can:

Report and analyze network traffic at subscriber and aggregate level for capacity planning
Provide customer-intuitive tiered application services and guarantee application SLAs
Implement different service levels for different types of customers, content, or applications
Identify network abusers who are violating the Acceptable Use Policy
Identify and manage peer-to-peer, NNTP (news) traffic, and spam abusers
Enforce the Acceptable Use Policy (AUP)
Integrate Service Control solutions easily with existing network elements and BSS/OSS systems

Cisco Service Control Capabilities

The core of the Cisco Service Control solution is the purpose-built network hardware device: the Service Control Engine (SCE). The core capabilities of the SCE platform, which support a wide range of applications for delivering Service Control solutions, include:

Subscriber and application awareness—Application-level drilling into IP traffic for real-time understanding and controlling of usage and content at the granularity of a specific subscriber.
- Subscriber awareness—The ability to map between IP flows and a specific subscriber in order to maintain the state of each subscriber transmitting traffic through the SCE platform and to enforce the appropriate policy on this subscriber’s traffic.
  
  Subscriber awareness is achieved either through dedicated integrations with subscriber management repositories, such as a DHCP or a Radius server, or via sniffing of Radius or DHCP traffic.
- Application awareness—The ability to understand and analyze traffic up to the application protocol layer (Layer 7).
  
  For application protocols implemented using bundled flows (such as FTP, which is implemented using Control and Data flows), the SCE platform understands the bundling connection between the flows and treats them accordingly.
Application-layer, stateful, real-time traffic control—The ability to perform advanced control functions, including granular BW metering and shaping, quota management, and redirection, using application-layer stateful real-time traffic transaction processing. This requires highly adaptive protocol and application-level intelligence.
Programmability—The ability to quickly add new protocols and easily adapt to new services and applications in the ever-changing service provider environment. Programmability is achieved using the Cisco Service Modeling Language (SML).

Programmability allows new services to be deployed quickly and provides an easy upgrade path for network, application, or service growth.
Robust and flexible back-office integration—The ability to integrate with existing third-party systems at the Service Provider, including provisioning systems, subscriber repositories, billing systems, and OSS systems. The SCE provides a set of open and well-documented APIs that allows a quick and robust integration process.
Scalable high-performance service engines—The ability to perform all these operations at wire speed.

The SCE Platform

The SCE family of programmable network devices is capable of performing application-layer stateful-flow inspection of IP traffic, and controlling that traffic based on configurable rules. The SCE platform is a purpose-built network device that uses ASIC components and RISC processors to go beyond packet counting and delve deeper into the contents of network traffic. Providing programmable, stateful inspection of bidirectional traffic flows and mapping these flows with user ownership, the SCE platforms provide real-time classification of network usage. This information provides the basis of the SCE platform advanced traffic-control and bandwidth-shaping functionality. Where most bandwidth shaper functionality ends, the SCE platform provides more control and shaping options, including:

Layer 7 stateful wire-speed packet inspection and classification
Robust support for over 600 protocols and applications, including:
- General—HTTP, HTTPS, FTP, TELNET, NNTP, SMTP, POP3, IMAP, WAP, and others
- P2P file sharing—FastTrack-KazaA, Gnutella, BitTorrent, Winny, Hotline, eDonkey, DirectConnect, Piolet, and others
- P2P VoIP—Skype, Skinny, DingoTel, and others
- Streaming and Multimedia—RTSP, SIP, HTTP streaming, RTP/RTCP, and others
Programmable system core for flexible reporting and bandwidth control
Transparent network and BSS/OSS integration into existing networks
Subscriber awareness that relates traffic and usage to specific customers

The following diagram illustrates a common deployment of an SCE platform in a network.

Figure 1.1. SCE Platform in the Network

Management and Collection

The Cisco Service Control solution includes a complete management infrastructure that provides the following management components to manage all aspects of the solution:

Network management
Subscriber management
Service Control management

These management interfaces are designed to comply with common management standards and to integrate easily with existing OSS infrastructure.

Figure 1.2. Service Control Management Infrastructure

Network Management

Cisco provides complete network FCAPS (Fault, Configuration, Accounting, Performance, Security) Management.

Two interfaces are provided for network management:

Command-line interface (CLI)—Accessible through the Console port or through a Telnet connection, the CLI is used for configuration and security functions.
SNMP—Provides fault management (via SNMP traps) and performance monitoring functionality.

Service Configuration Management

Service configuration management is the ability to configure the general service definitions of a service control application. A service configuration file containing settings for traffic classification, accounting and reporting, and control is created and applied to an SCE platform. The SCA BB application provides tools to automate the distribution of these configuration files to SCE platforms. This simple, standards-based approach makes it easy to manage multiple devices in a large network.

Service Control provides an easy-to-use GUI to edit and create these files and a complete set of APIs to automate their creation.

Subscriber Management

Where the Cisco Service Control Application for Broadband (SCA BB) enforces different policies on different subscribers and tracks usage on an individual subscriber basis, the Cisco Service Control Management Suite (SCMS) Subscriber Manager (SM) may be used as middleware software for bridging between the OSS and the SCE platforms. Subscriber information is stored in the SM database and can be distributed between multiple platforms according to actual subscriber placement.

The SM provides subscriber awareness by mapping network IDs to subscriber IDs. It can obtain subscriber information using dedicated integration modules that integrate with AAA devices, such as Radius or DHCP servers.

Subscriber information may be obtained in one of two ways:

Push Mode—The SM pushes subscriber information to the SCE platform automatically upon logon of a subscriber.
Pull Mode—The SM sends subscriber information to the SCE platform in response to a query from the SCE platform.

Data Collection

The Cisco Service Control solution generates usage data and statistics from the SCE platform and forwards them as Raw Data Records (RDRs), using a simple TCP-based protocol (RDR-Protocol). The Cisco Service Control Management Suite (SCMS) Collection Manager (CM) software implements the collection system, listening in on RDRs from one or more SCE platforms and processing them on the local machine. The data is then stored for analysis and reporting functions, and for the collection and presentation of data to additional OSS systems such as billing.

Chapter 2. Command-Line Interface

This chapter describes how to use the SCE platform Command-Line Interface (CLI), its hierarchical structure, authorization levels and its help features. The Command-Line Interface is one of the SCE platform management interfaces.

Getting Help

To obtain a list of commands that are available for each command mode, enter a question mark (?) at the system prompt. You also can obtain a list of keywords and arguments associated with any command using the context-sensitive help feature.

The following table lists commands you can enter to get help that is specific to a command mode, a command, a keyword, or an argument.

Table 2.1. Getting Help

Command	Purpose
abbreviated-command-entry?	Obtain a list of commands that begin with a particular character string. (Do not leave a space between the command and question mark.)
abbreviated-command-entry<Tab>	Complete a partial command name.
?	List all commands available for a particular command mode.
command ?	List the keywords associated with the specified command. Leave a space between the command and question mark.
command keyword ?	List the arguments associated with the specified keyword. Leave a space between the keyword and question mark.

Authorization and Command Levels (Hierarchy)

When using the CLI there are two important concepts that you must understand in order to navigate:

Authorization Level — Indicates the level of commands you can execute. A user with a simple authorization level can only view some information in the system, while a higher level administrator can actually make changes to configuration.

This manual documents commands at the User, Viewer, and Admin authorization level. See CLI Command Hierarchy.
Command Hierarchy Level — Provides you with a context for initiating commands. Commands are broken down into categories and you can only execute each command within the context of its category. For example, in order to configure parameters related to the Line Card, you need to be within the LineCard Interface Configuration Mode. See CLI Command Hierarchy.

The following sections describe the available Authorization and Command Hierarchy Levels and how to maneuver within them.

The on-screen prompt indicates both your authorization level and your command hierarchy level, as well as the assigned host name. See Prompt Indications.

Note

Throughout the manual, SCE is used as the sample host name.

CLI Command Hierarchy

The set of all CLI commands is grouped in hierarchical order, according to the type of the commands. The first three levels in the hierarchy are the User Exec, Viewer, and Privileged Exec modes. These are non-configuration modes in which the set of available commands enables the monitoring of the SCE platform, file system operations, and other operations that cannot alter the configuration of the SCE platform.

The next levels in the hierarchy are the Global and Interface configuration modes, which hold a set of commands that control the global configuration of the SCE platform and its interfaces. Any of the parameters set by the commands in these modes should be saved in the startup configuration, such that in the case of a reboot, the SCE platform restores the saved configuration.

The following tableshows the available CLI modes.

Table 2.2. CLI Modes

Mode	Description	Level	Prompt indication
User Exec	Initial mode with very limited functionality.	User	SCE>
Viewer	Monitoring (show commands).	Viewer	SCE>
Privileged Exec	General administration; file system manipulations and control of basic parameters that do not change the configuration of the SCE platform.	Admin	SCE#
Global Configuration	Configuration of general system parameters, such as DNS, host name, and time zone.	Admin	SCE`(config)#`
Management Interface Configuration	Configuration of management interface parameters, such as the Ethernet interface properties and selection of the active port.	Admin	SCE`(config if)#`
Interface Configuration	Configuration of specific system interface parameters, such as the Line Card, and the Ethernet interfaces.	Admin	SCE`(config if)#`
Line Configuration	Configuration of Telnet lines, such as an access-list.	Admin	SCE`(config-line)#`

When you login to the system, you have the User authorization level and enter User Exec mode. Changing the authorization level to Viewer automatically moves you to Viewer mode. In order to move to any of the configuration modes, you must enter commands specific to that mode.

The list of available commands in each mode can be viewed using the question mark ‘?’ at the end of the prompt.

The figure below, illustrates the hierarchical structure of the CLI modes, and the CLI commands used to enter and exit a mode.

Figure 2.1. CLI Command Hierarchy

The following commands are used to enter the different configure interface modes and the Line Configuration Mode:

E1 interface LineCard 0
E2 interface Mng 0/1 or 0/2(management port, all platforms)
E3 interface GigabitEthernet 0/1 or 0/2 (line ports, SCE 1000 platform)
E3 interface GigabitEthernet 0/1,0/2, 0/3, or 0/4 (line ports, SCE 2000 4xGBE platform)
E3 interface FastEthernet 0/1,0/2, 0/3, or 0/4 (line ports, SCE 2000 4/8xFE platform)
E4 line vty 0

Note

Although the system supports up to five concurrent Telnet connections, you cannot configure them separately. This means that any number you enter in the line vty command (0, 1, 2,3 or 4) will act as a 0 and configure all five connections together.

Note

In order for the auto-completion feature to work, when you move from one interface configuration mode to another, you must first exit the current interface configuration mode (as illustrated in the above figure).

Example:

This example illustrates moving into and out of configuration modes as follows:

Enter global configuration mode
Configure the SCE platform time zone
Enter Mng Interface configuration mode for Mng port 1
Configure the speed of the management interface
Exit the Mng Interface configuration mode to the global configuration mode
Enter the LineCard Interface configuration
Define the link mode.
Exit LineCard Interface configuration mode to the global configuration mode
Exit global configuration mode

SCE#configure
SCE(config)#clock timezone PST -10
SCE(config)#interface Mng 0/1
SCE(config if)#speed 100
SCE(config if)#exit
SCE(config)#interface LineCard 0
SCE(config if)#link-mode all-links forwarding
SCE(config if)#exit
SCE(config)#exit
SCE#

CLI Authorization Levels

The SCE platform has four authorization levels, which represent the user access permissions. When you initially connect to the SCE platform, you automatically have the most basic authorization level, that is User, which allows minimum functionality.

In order to monitor the system, you must have Viewer authorization, while in order to perform administrative functions on the SCE platform, you must have Admin or Root authorization. A higher level of authorization is accessed by logging in with appropriate password, as described in the procedures below.

In each authorization level, all the commands of the lower authorization layers are available in addition to commands that are authorized only to the current level.

Note

This manual covers the functions that can be performed by the Admin level user, unless otherwise noted.

The following CLI commands are related to authorization levels:

enable
disable

Each authorization level has a value (number) corresponding to it. When using the CLI commands, use the values, not the name of the level, as shown in the following table.



Table 2.3. Authorization Levels

Level	Description	Value	Prompt
User	Password required. This level enables basic operational functionality.	0	>
Viewer	Password required. This level enables monitoring functionality. All show commands are available to the Viewer authorization level, with the exception of those that display password information.	5	>
Admin	Password required. For use by general administrators, the Admin authorization level enables configuration and management of the SCE platform.	10	#
Root	Password required. For use by technical field engineers, the Root authorization level enables configuration of all advanced settings, such as debug and disaster recovery. The Root level is used by technical engineers only and is not documented in this manual.	15	#>

To change from User to Viewer level authorization:

From the SCE> prompt, type enable 5 and press Enter.

The system prompts for a password by showing the prompt Password:
Type in the password for the Viewer level and press Enter.

Note that the password is an access-level authorization setting, not an individual user password.

The system prompt SCE> does not change when you move from User to Viewer level.

A telnet session begins with a request for password, and will not continue until the proper user password is supplied. This enhances the security of the system by not revealing its identity to unauthorized people.

To log in with Admin level authorization:

Initiate a telnet connection.
A Password: prompt appears. Type in the user level password and press Enter.

The SCE> prompt appears.

You now have user level authorization.
From the SCE> prompt, type enable 10 and press Enter.

The system prompts for a password by showing the prompt Password:
Type in the password for the Admin level and press Enter.

Note that the password is an access-level authorization setting, not an individual user password.

The system prompt changes to SCE# to show you are now in Admin level.

Example:

The following example illustrates how to change the authorization level from User to Admin, and then revert back to Viewer. No password is required for moving to a lower authorization level.

SCE>enable 10
Password:  cisco
SCE#disable
SCE>

Prompt Indications

The on-screen prompt indicates your authorization level, your command hierarchy level, and the assigned host name. The structure of the prompt is: <hostname(mode-indication)level-indication>

Authorization levels are indicated as follows:

This prompt...	Indicates this...
>	indicates User and Viewer levels
#	indicates Admin level
#>	indicates Root level

Command hierarchy levels are indicated as follows:

This command hierarchy...	Is indicated as...
User Exec	`SCE>`
Privileged Exec	`SCE#`
Global Configuration	`SCE(config)#`
Interface Configuration	`SCE(config if)#`
Line Configuration	`SCE(config-line)#`

Example:

The prompt MySCE(config if)# indicates:

The name of the SCE platform is MySCE
The current CLI mode is Interface configuration mode
The user has Admin authorization level

Exiting Modes

This section describes how to revert to a previous mode.

To exit from one authorization level to the previous one, use the disable command.
To exit from one mode to another with the Admin authorization level (these are the various configuration modes), use the exit command.

To exit from the Privileged Exec mode and revert to the Viewer mode:

At the SCE# prompt, type disable, and press Enter.

The SCE> prompt for the Viewer and User Exec mode appears.

To exit from the Global Configuration Mode:

At the SCE(config)# prompt, type exit, and press Enter.

The appropriate prompt for the previous level appears.

Example:

The following example shows the system response when you exit the Interface Configuration mode.

SCE(config if)#exit
SCE(config)#

Navigating Between Configuration Modes

Entering and Exiting Global Configuration Mode

To enter the Global Configuration Mode:

At the SCE# prompt, type configure, and press Enter.

The SCE(config)# prompt appears.

To exit the Global Configuration Mode:

At the SCE(config)# prompt, type exit and press Enter.

The SCE# prompt appears.

Interface Configuration Modes

The components that are configured by the Interface Configuration Modes are:

Card
- LineCard — Interface LineCard 0
  
  The LineCard interface configures the main functionality of viewing and handling traffic on the line.
Ports
- See Configuring the Physical Ports
Telnet
- Line Configuration Mode — Line vty 0
  
  The Line Configuration Mode enables you to configure Telnet parameters.

Configuring the Physical Ports

The SCE platform contains the following physical port interfaces:

Management:

Interface Mng 0/1 or 0/2

The Management Interface mode configures the settings for the interface to a remote management console. The two management ports support management interface redundancy.

The following commands are used to configure the management port:
- ip address
- duplex
- speed
- active-port (SCE 2000 platform only)
- fail-over
Fast Ethernet (SCE 2000 4/8xFE):

Interface FastEthernet 0/1, 0/2, 0/3, or 0/4

The FastEthernet Interface mode configures the settings for the FastEthernet interface to the Internet traffic on the wire. Each of the four ports can be set individually.

The following commands are used to configure the Fast Ethernet line ports:
- bandwidth
- duplex
- queue
- speed
Gigabit Ethernet (SCE 1000 platform):

Interface GigabitEthernet 0/1, or 0/2

The GigabitEthernet Interface mode configures the settings for the GigabitEthernet interface to the Internet traffic on the wire. Each of the two ports can be set individually.
Gigabit Ethernet (SCE 2000 4xGBE platform):

Interface GigabitEthernet 0/1, 0/2, 0/3, or 0/4

The GigabitEthernet Interface mode configures the settings for the GigabitEthernet interface to the Internet traffic on the wire. Each of the four ports can be set individually.

The following commands are used to configure the Gigabit Ethernet line ports:
- auto-negotiate (GigabitEthernet only)
- bandwidth
- queue

Note

You must specify the slot number/interface number when referencing any interface. The slot number is always 0, and the interfaces are numbered as follows: Management Interface: 1,2 Ethernet Line Interfaces: SCE 1000 platform: 1,2 SCE 2000 platform: 1,2,3,4

Entering Management Interface Configuration Mode

Before you can configure the parameters for the management interface, you must be in the Mng Interface Configuration Mode.

To enter Mng Interface Configuration Mode, complete the following steps:

To enter Global Configuration Mode, type configure and pressEnter.

The SCE(config)# prompt appears.
Type interface Mng [0/1|0/2] and press Enter.

The SCE(config if)# prompt appears.

The system prompt changes to reflect the higher level mode.

To return to the Global Configuration mode, use the following command:

Type exit.

Entering LineCard Interface Configuration Mode

The following procedure is for entering Line Card Interface Configuration mode. The procedures for entering the other interfaces are the same except for the interface command as described above and in CLI Command Reference.

To enter LineCard Interface Configuration mode:

To enter Global Configuration Mode, at the SCE# prompt, type configure, and press Enter.

The SCE(config)# prompt appears.
Type interface LineCard 0, and press Enter.

The SCE(config if)# prompt appears.
To return to Global Configuration Mode, type exit and press Enter.

The SCE(config)# prompt appears.
To exit Global Configuration Mode, type exit and press Enter.

The SCE# prompt appears.

Entering Ethernet Line Interface Configuration Mode

Entering the Fast Ethernet Line Interface Configuration Mode

To enter the FastEthernet Interface Configuration Mode:

To enter Global Configuration Mode, type configure and press Enter.

The SCE(config)# prompt appears.
For the SCE 2000, type interface FastEthernet [0/1|0/2|0/3|0/4] and pressEnter.

The SCE(config if)# prompt appears.

Example:

The following example shows how to enter Configuration Mode for the FastEthernet Interface number 3.

SCE(config)#interface FastEthernet 0/3
SCE(config if)#

Entering the Gigabit Ethernet Line Interface Configuration Mode

To enter the GigabitEthernet Interface Configuration Mode:

To enter Global Configuration Mode, type configure and press Enter.

The SCE(config)# prompt appears.
For the SCE 1000, type interface GigabitEthernet [0/1|0/2] and press Enter.
For the SCE 2000, type interface GigabitEthernet [0/1|0/2|0/3|0/4] and press Enter.

The SCE(config if)# prompt appears.

Example:

The following example shows how to enter Configuration Mode for the GigabitEthernet Interface number 2.

SCE(config)#interface GigabitEthernet 0/2
SCE(config if)#

Navigating between the Interface Configuration Modes

To navigate from one Interface Configuration Mode to another:

Type exit.

You are returned to the Global Configuration Mode.
Type the appropriate command to enter a different Interface Configuration Mode.

The "do" Command: Executing Commands Without Exiting

There are four configuration command modes:

Global configuration mode
Management interface configuration mode
Interface configuration mode
Line configuration mode

When you are in one of these configuration modes, it is possible to execute an EXEC mode command (such as a show command) or a privileged EXEC (such as show running-config) without exiting to the relevant command mode. Use the 'do' command for this purpose.

To execute an exec mode command from a configuration command mode, use the following command:

At the SCEconfig# (or SCEconfig if#) prompt, type do <command>.

The specified command executes without exiting to the appropriate exec command mode.

Example

The following example shows how to display the running configuration while in interface configuration mode.

SCEconfig if# do show running-config

CLI Help Features

CLI provides context sensitive help. Two types of context sensitive help are supported:

Partial help
Argument help

Partial Help

To obtain a list of commands that begin with a particular character string, enter the abbreviated command entry immediately followed by a question mark (?). This form of help is called partial help, because it lists only the keywords or arguments that begin with the abbreviation you entered.

Example:

The following example illustrates howtyping c? displays all available arguments that start with the letter c.

SCE(config)#snmp-server c?
Community		contact
SCE(config)#snmp-server c

Argument Help

To obtain a list of command’s associated keywords or parameters, type a question mark (?) in place of a keyword or parameter on the command line.

Note that if <Enter> is acceptable input, the symbol <cr> represents the Enter key.

Example:

The following example illustrates how to get a list of all arguments or keywords expected after the command snmp-server.

SCE(config)#snmp-server ?
Community   Define community string
Contact     Set system contact
Enable      Enable the SNMP agent
Host        Set traps destination
Location        Set system location
SCE(config)# snmp-server

When asking for help on particular parameter, the system informs you of the type of data that is an accepted legal value. The types of parameters supported are:

STRING	When a String is expected, you can enter any set of characters or digits. If the string has a space as one of its characters, use double-quote (“) marks to enclose the string.
DECIMAL	Any decimal number. Positive number is assumed, for negative numbers use the “–” symbol.
HEX	A hexadecimal number; must start with either 0x or 0X.

Example:

The following example illustrates the use of ? to get help on commands syntax. In this example, you can enter either the word running-config, or any name of a file, after the word copy.

SCE#copy ?
    running-config      Copy running configuration file
    STRING          Source file name
SCE#copy

The [no] Prefix

Many CLI commands offer the option of adding the word no before the command to disable the feature controlled by the command or revert it to its default configuration. This notation is shown in the CLI Command Reference as [no] to denote it is optional.

For example, no service telnetd disables the telnet server. Enabling the telnet server is done by typing service telnetd.

Navigational and Shortcut Features

Command History

CLI maintains a history buffer of the most recent commands you used in the current CLI session for quick retrieval. Using the keyboard, you can navigate through your last commands, one by one, or all commands that start with a given prefix. By default, the system saves the last 30 commands you typed. You can change the number of commands remembered using the history size command.

To use the history functions, use the keys shown in the following table.

Table 2.4. Keyboard Shortcuts for History Functions

Arrow	Shortcut	Description
Up arrow	Ctrl-P	Moves cursor to the previous command with the same prefix.
Down arrow	Ctrl-N	Moves cursor to the next command with the same prefix as original.
	Ctrl-L Ctrl-R	Re-display the current command line.

Keyboard Shortcuts

The SCE platform has a number of keyboard shortcuts that make it easier to navigate and use the system. The following table shows the keyboard shortcuts available.

You can get a display the keyboard shortcuts at any time by typing help bindings.

Table 2.5. Keyboard Shortcuts

Description	Shortcut Key
Navigational shortcuts
Move cursor one character to the right.	CTRL-F /->
Move cursor one character to the left.	CTRL-B /<-
Move cursor one word to the right (forward).	ESC-F
Move cursor one word to the left (backward.	ESC-B
Move cursor to the start of the line.	CTRL-A
Move cursor to the end of the line.	CTRL-E
Editing shortcuts
Delete the character where the cursor is located.	CTRL-D
Delete from the cursor position to the end of the word.	ESC-d
Delete the character before the current location of the cursor.	Backspace
Delete the character before the current location of the cursor.	CTRL-H
Deletes from the cursor position to the end of the line	CTRL-K
Deletes all characters from the cursor to the beginning of the line	CTRL-U
Deletes all characters from the cursor to the beginning of the line. (Same functionality as CTRL-U.)	CTRL-X
Delete the word to the left of the cursor.	CTRL-W
Recall the last item deleted.	CTRL-Y
Completes the word when there is only one possible completion.	<Tab>
Completes the word when there is only one possible completion. (Same functionality as <Tab>.)	CTRL-I

Tab Completion

The CLI interface features tab completion. When you type in the first letters of a command and type <Tab>, the system automatically fills in the rest of the command or keyword. This feature works only when there is one possible command that could be possible using the starting letters.

Example:

The letters snm followed by <Tab> will be completed to the command snmp-server.

SCE(config)#snm<Tab>
SCE(config)#snmp-server

If you type <Enter> instead of <Tab>, and there is no ambiguity, the system actually carries out the command which would be filled in by the rest of the word.

Example:



The following example displays how the system completes a partial (unique) command for the enable command. Because enable does not require any parameters, the system simply carries out the enable command when the user presses Enter.

SCE>en<Enter>
Password:   
SCE#

FTP User Name and Password

CLI enables saving ftp user name and password to be used in FTP operations—download and upload, per session.

These settings are effective during the current CLI session.

Example:

The following example illustrates how to set FTP password and user name and the use in these settings for getting a file named config.tmp from a remote station using FTP protocol.

SCE#ip ftp password vk
SCE#ip ftp username vk
SCE#copy ftp://@10.1.1.253/h:/config.tmp myconf.txt
connecting 10.1.1.253 (user name vk password vk) to retrieve config.tmp 
SCE#

Managing Command Output

Some commands, such as many show commands, may have many lines of output. There are several ways of managing the command output:

Scrolling options — When the command output is too large to be displayed all at once, you can control whether the display scrolls line by line or refreshes the entire screen.
Filtering options — You can filter the output so that output lines are displayed only if they include or exclude a specified expression.
Redirecting to a file — You can send the output to a specified file

Scrolling the Screen Display

The output of some show and dir commands is quite lengthy and cannot all be displayed on the screen at one time. Commands with many lines of output are displayed in chunks of 24 lines. You can choose to scroll the display line by line or refresh the entire screen. At the prompt after any line, you can type one of the following keys for the desired action:

<Enter>– show one more line
<Space> – show 24 more lines (a new chunk)
<g> – Stop prompting for more
<?> – Display a help string showing possible options
Any other key – quit showing the file

Filtering Command Output

You can filter the output of certain commands, such as show, more, and dir, so that output lines are displayed only if they include or exclude a specified expression. The filtering options are as follows:

include — Shows all lines that include the specified text.
exclude — Does not show any lines that include the specified text.
begin — Finds the first line that includes the specified text, and shows all lines starting from that line. All previous lines are excluded.

The syntax of filtered commands is as follows:

<command> | include <expression>
<command> | exclude <expression>
<command> | begin <expression>

The <expression> in these commands is case sensitive.

Example



Following is an example of how to filter the show version command to display only the last part of the output, beginning with the version information.

SCE#  show version begin revision

Redirecting Command Output to a File

You can redirect the output of commands, such as show, more, and dir, to a file. When writing the output of these commands to a file, you can specify either of the following options:

redirect — The new output of the command will overwrite the existing contents of the file.
append — The new output of the command will be appended to the existing contents of the file.

The syntax of redirection commands is as follows:

<command> | redirect <file-name>
<command> | append <file-name>

Example



Following is an example of how to do the following:



Filter the more command to display from a csv subscriber file only the gold package subscribers.



Redirect that output to a file named current_gold_subscribers. The output should not overwrite existing entries in the file, but should be appended to the end of the file.

SCE# more subscribers_10.10.2004 include gold append current_gold_subscribers

CLI Scripts

The CLI scripts feature allows you to record several CLI commands together as a script and play it back. This is useful for saving repeatable sequence of commands , such as software upgrade. For example, if you are configuring a group of SCE platforms and you want to run the same configuration commands on each platform, you could create a script on one platform and run it on all the other SCE platforms.

The available script commands are:

script capture
script stop
script print
script run



To create a script:



At the SCE# prompt, type script capture sample1.scr where sample1.scr is the name of the script.



Perform the actions you want to be included in the script.



Type script stop.

The system saves the script.

Example:

The following is an example of recording a script for upgrading software.

SCE#script capture upgrade.scr
SCE#configure
SCE(config)#boot system new.pkg
Verifying package file...
Package file verified OK.
SCE(config)#exit
SCE#copy running-config startup-config
Writing general configuration file to temporary location...
Extracting files from ‘/tffs0/images/new.pkg’...
Verifying package file...
Package file verified OK.
Device ‘/tffs0/’ has 81154048 bytes free, 21447973 bytes are needed for extraction, all is well.
Extracting files to temp locations...
Renaming temp files...
Extracted OK.
Backing-up general configuration file...
Copy temporary file to final location...
SCE#script stop
SCE#

To run the script recorded above, type:

SCE#script run upgrade.scr

Chapter 3. Operations

Managing Configurations



The SCE platform uses two configuration files:



Startup configuration — This file contains the non-default configuration as saved by the user. The startup-config file is loaded each time the SCE platform reboots.



Running configuration — This file contains results of configuration commands entered by the user. The running-config file is saved in the SCE volatile memory and is effective only as long as the SCE platform is up and running.

Use the following commands to view and save the configuration files.

You can also recover a previous configuration from a saved configuration file, as well as completely remove all current user configuration.

Viewing Configuration



When you enter configuration commands, it immediately effects the SCE platform operation and configuration. This configuration, referred to as the running-config, is saved in the SCE platform volatile memory and is effective while the SCE platform is up. After reboot, the SCE platform loads the startup-config, which includes the non-default configuration as saved by the user, into the running-config.

The SCE platform provides commands for:



Viewing the running configuration



Viewing the startup configuration

After configuring the SCE platform, you may query for the running configuration using the command show running-config. This command displays the non-default running configuration. To view all SCE platform running configuration, whether it is the default or not, you may use the option all-data in the show running-config command.



To view the running configuration, use the following command:



At the SCE# prompt, type show running-config.

The system shows the running configuration.

SCE#show running-config
#This is a general configuration file (running-config).
#Created on 15:50:56  CET  MON  December  11  2005
#cli-type 1
#version 1

clock timezone CET 1
snmp-server community “public” ro
snmp-server host 10.1.1.253 traps version 1 “public”
interface LineCard 0
connection-mode active
no silent
no shutdown
flow-aging default-timeout UDP 60
interface FastEthernet 0/0
ip address 10.1.5.109 255.255.0.0
interface FastEthernet 0/1
interface FastEthernet 0/2
exit
line vty 0 4
no timeout
exit
SCE#

Removing the Configuration



You can completely remove all current configuration by removing all configuration files. The following data is deleted by this command:



General configuration files



Application configuration files



Static party DB files



Management agent installed MBeans

Note



After using this command, the SCE platform should be reloaded immediately to ensure that it returns to the 'factory default' state.



To remove the configuration files, use the following command:



At the SCE(config)# prompt, type erase startup-config-all.

All configuration files are removed, including configuration files not explicitly managed by the user, as listed above.

Saving the Configuration Settings



When you make changes to the current running configuration and you want those changes to continue to be valid when the system restarts, you must save the changes before leaving the management session, that is, you must save the running configuration to the startup configuration file.

The SCE platform provides multiple interfaces for the purpose of configuration and management. All interfaces supply an API to the same database of the SCE platform and any configuration made through one interface is reflected through all interfaces. Furthermore, when saving the running configuration to the startup configuration from any management interface, all configuration settings are saved regardless of the management interface used to set the configuration.



To save configuration changes, complete the following steps:



At the SCE# prompt, type show running-config to view the running configuration.

The running configuration is displayed.



Check the displayed configuration to make sure that it is set the way you want. If not, make the changes you want before saving.



Type copy running-config startup-config.

The system saves all running configuration information to the configuration file, which is used when the system reboots.

The configuration file holds all information that is different from the system default in a file called config.txt located in the directory: tffs0:system.

Example:



The following example shows the running configuration file.

SCE#show running-config
#This is a general configuration file (running-config).
#Created on 15:50:56  CET  MON  February  11  2006
#cli-type 1
#version 1

clock timezone CET 1
snmp-server community “public” ro
snmp-server host 10.1.1.253 traps version 1 “public”
interface LineCard 0
connection-mode active
no silent
no shutdown
flow-aging default-timeout UDP 60
interface FastEthernet 0/0
ip address 10.1.5.109 255.255.0.0
interface FastEthernet 0/1

interface FastEthernet 0/2

exit
line vty 0 4
no timeout
exit
SCE#     
SCE#copy running-config startup-config
Writing general configuration file to temporary location...
Backing-up general configuration file...
Copy temporary file to final location...
SCE#

For backup purposes, the old startup-config file is saved under the directory: tffs0:system/prevconf. Refer to Recovering a Previous Configuration for an explanation on how to recover previous configuration.
To remove a configuration command from the running-config, use the no form of the command.

Example:



The following example illustrates how to remove all DNS settings from the running configuration.

SCE(config)#no ip name-server
SCE(config)#

Recovering a Previous Configuration



When you save a new configuration, the system automatically backs up the old configuration in the directory tffs0:system/prevconf/. Up to nine versions of the startup configuration file are saved, namely config.tx1-config.tx9, where config.tx1 is the most recently saved file.

You can view the old startup configuration files using the CLI command more.

Restoring a previous startup configuration means renaming the file so it overwrites the startup configuration (config.txt) file.



To restore a previous startup configuration, complete the following steps:



At the SCE# prompt, type more tffs0:system/prevconf/config.txt to view the configuration file.

The system displays the configuration information stored in the file.



Read the configuration information to make sure it is the configuration you want to restore.

Note that you cannot undo the configuration restore command.



Type 
copy tffs0:system/prevconf/config.tx1 tffs0:system/config.txt.

The system sets the startup configuration to the configuration from config.tx1.

Example:



The following example displays a saved configuration file and then restores the file to overwrite the current configuration.

SCE#more tffs0:system/prevconf/config.tx1
#This is a general configuration file (running-config).
#Created on 19:36:07 UTC THU February 14 2006

#cli-type 1
#version 1

interface LineCard 0
no silent
no shutdown

interface FastEthernet 0/0
ip address 10.1.5.109 255.255.0.0

interface FastEthernet 0/1

interface FastEthernet 0/2

exit

line vty 0 4
exit
SCE#copy tffs0:system/prevconf/config.tx1 tffs0:system/config.txt
SCE#

Creating a Backup Configuration File



Although a backup of the configuration file is created automatically under certain circumstances, it is useful to be able to explicitly create a backup configuration file.

For example, it can be used in a cascaded solution to copy the configuration from one SCE platform to the other, as follows:



To create a backup configuration file, execute this command on the first SCE platform, specifying an FTP backup file:

copy startup-config backup-file



To upload the backup configuration file to the cascaded SCE platform, execute this command on that SCE platform, specifying the previously created backup file:

copy backup-file startup-config 

The following option is available:



backup-file — The name of the backup configuration file to be created. The file name should be in 8.3 format, that is, there are a maximum of 8 characters before the period and three characters following it.

The backup file may be created via FTP or it may be a local file, as shown in the following examples:



via FTP: ftp://user:pass@host/drive:/dir/bckupcfg.txt



local: /tffs0/bckupcfg.txt



To create a backup configuration file, use the following command:



At the SCE# prompt, type copy startup-config backup-file.



To upload a backup configuration file, use the following command:



At the SCE# prompt, type copy backup-file startup-config .

Example:



The following example shows how to copy the configuration from one SCE platform to another.

On the first SCE platform, enter the following command:

SCE1#copy startup-config ftp://adminuser:mypassword@10.10.10.10/c:/config/bckupcfg.txt
SCE1#

On the second SCE platform, enter the following command:

SCE2#copy ftp://adminuser:mypassword@10.10.10.10/c:/config/bckupcfg.txt startup-config
SCE2#

Upgrading SCE Platform Firmware



Cisco distributes upgrades to the software and firmware on the SCE platform. Cisco distributes upgrade software as a file with the extension .pkg that is installed directly from the ftp site without being copied to the disk. This procedure walks you through installation and rebooting of the SCE platform with the new firmware.



To upgrade your SCE platform software, complete the following steps:



Type configure to enter Global Configuration mode.

The SCE prompt changes to SCE(config)#.



Type boot system ftp://<user:password@host/drive:dir/seNum.pkg>, where <seNum.pkg> is the file name on the ftp site.

The boot command verifies that the package is a legal, appropriate update for the SCE platform and that the file was not corrupted. It does not perform an upgrade, but does keep in the system memory that a pkg file is available.



Type exit to leave the Global Configuration mode.

The SCE prompt changes to SCE#.



Type copy running-config startup-config.

This command re-verifies that the package is valid, and extracts the upgrade to the Flash file system.

The system notifies you that it is performing the extraction as follows:

Backing–up configuration file…
Writing configuration file…
Extracting new system image…
Extracted OK.
SCE#



Type reload to reboot the system.

The SCE prompts you for confirmation by asking Are you sure?



Type Y and press Enter.

The system sends the following message and reboots.

the system is about to reboot, this will end your CLI session

Example:



The following example shows the full procedure for performing a software update.

SCE#configure 
SCE(config)# boot system ftp://vk:vk@10.1.1.230/downloads/SENum.pkg
SCE(config)#exit 
SCE#copy running-config startup-config
Backing–up configuration file…
Writing configuration file…
Extracting new system image…
Extracted OK.
SCE#>reload
Are you sure? y
the system is about to reboot, this will end your CLI session

Configuring Applications



The SCE platform can be configured to run with different Service Control applications by installing the appropriate file. All SCE platform application files are pqi files, that is, the filename must end with the pqi extension.

Once a specific Service Control application is installed it can be configured by applying a configuration file. The configuration file is application-specific, and is produced by application-specific means, not covered in this documentation. Configuration files have no specific extension.

Note



These configuration changes are automatically saved to the start-up configuration after execution, and therefore do not appear when the running configuration is displayed (more running-config command).
These configurations cannot be manipulated by changing the system/config.txt file

Installing an Application



Use the following commands to install, uninstall, and upgrade an application. You can use the show pqi file info command before installing or upgrading an application to display the options that are available when installing the pqi file. These options can then be specified in the install orupgrade command as needed.

The documentation of the application will tell the user whether the application is stand-alone (in which case install should be used), or an upgrade to an existing application that is assumed to be installed already (in this case upgrade should be used). Currently all Cisco Service Control applications are stand-alone.

You should always run the pqi uninstall command before installing a new pqi file. This prevents old files from accumulating on the disk.

The following commands are relevant for installing and uninstalling an application:

pqi install file (interface LineCard configuration mode)
pqi uninstall file (interface LineCard configuration mode)
pqi upgrade file (interface LineCard configuration mode)
pqi rollback file  (interface LineCard configuration mode)
show pqi file info (viewer mode)
show pqi last-installed (viewer mode)



To display information about an application file, use the following command:



From the SCE# prompt, type show pqi file filename info and press Enter.



To install an application, use the following command:



From the SCE(config if)# prompt, type pqi install file filename  [options] and press Enter.

The specified pqi file is installed using the installation options specified (if any).

Note that this may take up to 5 minutes.

Note



Always run the pqi uninstall command before installing a new pqi file.



To uninstall an application, use the following command:



From the SCE(config if)# prompt, type pqi uninstall file filename and press Enter.

You must specify the same pqi file that was installed.

Note that this may take up to 5 minutes.



To upgrade an application, use the following command:



From the SCE(config if)# prompt, type pqi upgrade file filename [options] and press Enter.

You must specify the pqi file that was last used for upgrade.

Note that this may take up to 5 minutes.



To undo an upgrade of an application, use the following command:



From the SCE(config if)# prompt, type pqi rollback file filename and press Enter.

The upgrade of the specified pqi file is undone. Note that this may take up to 5 minutes.



To display the last pqi file that was installed, use the following command:



From the SCE# prompt, type show pqi last-installedand press Enter.

Monitoring the Operational Status of the SCE Platform



The following table lists the operational states of the SCE platform. You can monitor the operational status of the SCE platform via:



The Status LED on the SCE front panel



The show system operation-status CLI command



Table 3.1. SCE platform Operational States

SCE platform Operational Status	Description	Status LED State
Booting	Initial state after reset	Orange
Operational	SCE platform becomes operational after completing the following process: Boot is completed Power self-tests are completed without failure Platform configuration is applied	Flashing green
Warning	SCE platform is fully operational (as above) but one of the following occurred: Link on one of the line ports is down Management port link is down Temperature raised above threshold Voltage not in required range Fans problem Power supply problem Insufficient space on the disk Note: If the condition that caused the SCE platform to be in Warning state is resolved (for example, link is up) the SCE platform reverts to Operational state.	Flashing orange
Failure	System is in Failure state after Boot due to one of the following conditions: Power on test failure Three abnormal reboots in less than 20 minutes Platform configured to enter Failure mode consequent to failure-induced reboot (this is configurable using CLI command) Note: Depending on the cause of failure, the management interface and the platform configuration may or may not be active/available.	Red



To display the current operational status of the SCE platform, use the following command:



From the SCE> prompt, type show system operation-status and press Enter.

Example:



The following example shows how to display the current operational status of the SCE platform.

SCE>show system operation-status
System Operation status is Operational
Port status is:
Link on port #1 is down
Link on port #2 is down

Displaying the SCE Platform Version Information



Use this command to display global static information on the SCE platform, such as software and hardware version, image build time, system uptime, last open packages names and information on the SLI application assigned.



To show the version information for the SCE platform software and hardware, use the following command:



At the SCE# prompt, type show version and press Enter.

Example:



The following example shows how to display the SCE platform version information.

SCE#show version
System version: Version 3.0.0 Build 240
Build time: Jan 11 2006, 07:34:47
Software version is: Version 2.5.2 Build 240
Hardware information is: 
rx            : 0x0075
dp            : 0x1808
tx            : 0x1708
ff            : 0x0077
cls           : 0x1721
cpld          : 0x0025
Lic           : 0x0176
rev           : G001
Bootrom       : 2.1.0
L2 cache      : Samsung 0.5
lic type      : MFE
optic mode    : MM
Product S/N   : CAT093604K3
Product ID    : SCE2020-4XGBE-MM
Version ID    : V01
Deviation     :
Part number   : 800-26601-01
Revision      : B0
Software revision : G001
LineCard S/N      : CAT09370L1Q
Power Supply type : AC

SML Application information is:
Application file: /tffs0/temp.sli
Application name:
Application help:
Original source file: H:\work\Emb\jrt\V2.5\sml\actions\drop\drop_basic_anyflow.san
Compilation date: Wed, November 12 2006 at 21:25:21
Compiler version: SANc v2.50 Build 32 gcc_codelets=true built on: Tue September 23 2006 09:51:57 AM.;SME plugin v1.1
Default capacity option used.


Logger status: Enabled


Platform: SCE 2000 - 4xGBE
Management agent interface version: SCE Agent 3.0.5 Build 18
Software package file: ftp://vk:vk@10.1.8.22/P:/EMB/LatestVersion/3.0.5/se1000.pkg

SCE 2000 uptime is 21 minutes, 37 seconds
SCE#

Displaying the SCE Platform Inventory



Unique Device Identification (UDI) is a Cisco baseline feature that is supported by all Cisco platforms. This feature allows network administrators to remotely manage the assets in their network by tracing specific devices through either CLI or SNMP. The user can display inventory information for a remote device via either:



Entity MIB (see ENTITY-MIB)



CLI show inventory command

The show inventory CLI command displays the following information:



Device name



Description



Product identifier



Version identifier



Serial number



To display the SCE platform UDI, use the following command:



From the SCE> prompt, type show inventory and press Enter.

Example:



The following example shows how to display the inventory (UDI) of the SCE platform.

SCE>show inventory
NAME: "Chassis",
DESCR: "Cisco SCE 2020 Service Control Engine, Multi Mode, 4-port GE"
PID: SCE2020-4XGBE-MM  , VID: V01, SN: CAT093604K3
SCE>

Displaying the System Uptime



Use this command to see how long the system has been running since the last reboot.



To show the system uptime for the SCE platform, use the following command:



At the SCE# prompt, type show system-uptime and press Enter.

The system shows how long the system has been running since the last reboot.

Example:



The following example shows how to display the system uptime of the SCE platform.

SCE#show system-uptime
SCE uptime is 21 minutes, 37 seconds
SCE#

Rebooting and Shutting Down the SCE Platform

Rebooting the SCE Platform



Rebooting the SCE platform is required after installing a new firmware, in order for that firmware to take effect. There might be other occasions where rebooting the SCE platform is necessary.

Note



When the SCE restarts, it loads the startup configuration, so all changes made in the running configuration will be lost. You are advised to save the running configuration before performing reload, as described in Saving the Configuration Settings.



To reboot your SCE platform, complete the following steps:



At the SCE# prompt, type reload and press Enter.

A confirmation message appears.



Type Y to confirm the reboot request and press Enter.

Example:



The following example shows the commands for system reboot.

SCE# reload
Are you sure? y
the system is about to reboot, this will end your CLI session

Shutting Down the SCE Platform



Shutting down the SCE platform is required before turning the power off. This helps to ensure that non-volatile memory devices in the SCE platform are properly flushed in an orderly manner.

Note



When the SCE platform restarts, it loads the startup configuration, so all changes made in the running configuration will be lost. You are advised to save the running configuration before performing reload, as described in Saving the Configuration Settings.



To shut down your SCE platform, complete the following steps:



Connect to the serial console port (The CON connector on the SCE platform front panel, 9600 baud).

The SCE# prompt appears.



Type reload shutdown.

A confirmation message appears.



Type Y to confirm the shutdown request and press Enter.

Example:



The following example shows the commands for system shutdown.

SCE#reload shutdown
You are about to shut down the system.
The only way to resume system operation after this
is to cycle the power off, and then back on.
Continue? 
y

IT IS NOW SAFE TO TURN THE POWER OFF.

Note



Since the SCE platform can recover from the power-down state only by being physically turned off (or cycling the power), this command can only be executed from the serial CLI console. This limitation helps prevent situations in which a user issues this command from a Telnet session, and then realizes he/she has no physical access to the SCE platform.

Chapter 4. Utilities

Setup Utility



The setup utility is an interactive wizard that guides the user through the basic configuration process. This utility runs automatically upon initial connection to the local terminal. It may also be invoked explicitly via Telnet or via the local terminal to make changes to the system configuration.

The following table lists all the command parameters for the setup utility.



Table 4.1. Setup Command Parameters

Parameter	Definition
IP address	IP address of the SCE Platform.
subnet mask	Subnet mask of the SCE Platform.
default gateway	Default gateway.
hostname	Character string used to identify the SCE Platform. Maximum length is 20 characters.
admin password	Admin level password. Character string from 4-100 characters beginning with an alpha character.
root password	Root level password. Character string from 4-100 characters beginning with an alpha character.
password encryption status	Enable or disable password encryption?
Time Settings
time zone name and offset	Standard time zone abbreviation and minutes offset from UTC.
local time and date	Current local time and date. Use the format: 00:00:00 1 January 2002
SNTP Configuration
broadcast client status	Set the status of the SNTP broadcast client. If enabled, the SCE will synchronize its local time with updates received from SNTP broadcast servers.
unicast query interval	Interval in seconds between unicast requests for update (64 – 1024)
unicast server IP address	IP address of the SNTP unicast server.
DNS Configuration
DNS lookup status	Enable or disable IP DNS-based hostname translation.
default domain name	Default domain name to be used for completing unqualified host names
IP address	IP address of domain name server. ( maximum of 3 servers)
RDR Formatter Destination Configuration
IP address	IP address of the RDR-formatter destination
TCP port number	TCP port number of the RDR-formatter destination
Access Control Lists
Access Control List number	How many ACLs will be necessary? What IP addresses will be permitted/denied access for each management interface? You may want ACLs for the following: Any IP access Telnet access SNMP GET access SNMP SET access
list entries (maximum 20 per list)	IP address, and whether permitted or denied access.
IP access ACL	ID number of the ACL controlling IP access.
telnet ACL	ID number of the ACL controlling telnet access.
SNMP Configuration
SNMP agent status	Enable or disable SNMP management.
GET community names	Community strings to allow GET access and associated ACLs (maximum 20).
SET community names	Community strings to allow SET access and associated ACLs (maximum 20).
trap managers (maximum 20)	Trap manager IP address, community string, and SNMP version.
Authentication Failure trap status	Sets the status of the Authentication Failure traps.
enterprise traps status	Sets the status of the enterprise traps.
system administrator	Name of the system administrator.
Topology Configuration (Both Platforms)
connection mode	Is the SCE Platform installed in bump-in-the-wire topology (inline) or out of line using splitter or switch (receive-only)?
Admin status of the SCE Platform after abnormal boot	After a reboot due to a failure, should the SCE Platform remain in a Failure status or move to operational status provided no other problem was detected?
Topology Configuration (SCE 1000)
link bypass mode on operational status	When the SCE 1000 is operational, should it bypass traffic or not?
redundant SCE 1000 platform?	Is there a redundant SCE 1000 installed as a backup?
link bypass mode on non-operational status	When the SCE 1000 is not operational, should it bypass traffic or cut it off?
Topology Configuration (SCE 2000)
type of deployment	Is this a cascade topology, with two SCE Platforms connected via the cascade ports? Or is this a single platform topology?
physically connected link (cascade topology only)	In a cascade deployment this parameter sets the index for the link that this SCE 2000 is deployed on. The options for the SCE 2000 are link-0 or link-1. In a single-SCE 2000 Platform deployment this parameter is not relevant since one SCE 2000 is deployed on both links. In this case the link connected to port1-port2 is by default link-0 and the link connected to port3-port4 is by default link-1.
priority (cascade topology only)	If this is a cascaded topology, is this SCE 2000 the primary or secondary SCE 2000?
on-failure behavior (inline connection mode only)	If this SCE 2000 is deployed inline, should the failure behavior be bypass or cutoff of the link?







Information regarding these parameters can be found in the appropriate sections throughout this guide.

For more information regarding SCE platform topology, and for a step-by-step description of the setup utility, see the Cisco SCE 2000/SCE 1000 Installation and Configuration Guides.

Entering the Setup Utility



To enter the setup utility



From the SCE# prompt, type setup and press Enter.

The following dialog appears:

                --- System Configuration Dialog ---

At any point you may enter a question mark ‘?’ followed by ‘Enter’ for help.
Use ctrl-C to abort configuration dialog at any prompt.
Use ctrl-Z to jump to the end of the configuration dialog at any prompt.
Default settings are in square brackets ‘[]’.

Would you like to continue with the System Configuration Dialog? [yes/no]: y
system configuration dialog begins.

Multiple entry parameters (Lists)



When explicitly invoked, the setup utility offers the option of multiple entries (lists) for certain parameters.

Several parameters, such as the Access Control Lists, are actually lists containing a number of entries. If these lists are empty (initial configuration) or contain only one entry, they act the same as any scalar parameter, except that you are giving the option of adding additional entries to the list.

If these lists already contain more than one entry, the entire list is displayed, and you are then presented with several options. Following is an excerpt from the SNMP trap manager menu, illustrating how to configure list entries.



To configure a list parameter when more than one entry already exists in the list, complete the following steps:



The entries in the list are displayed.

There are 2 SNMP trap managers in the current configuration as follows:
IP address: 10.10.10.10     Community: private  Version: 1
IP address: 10.11.10.1  Community: pcube    Version: 2c

Note
Note: If only one entry exists in the table, it is displayed as the default [ ] to be either accepted or changed. The three list options are not displayed.



Three options are presented.

Please choose one of the following options:
1. Leave the running configuration unchanged.
2. Clear the existing lists and configure new ones.
3. Add new entries.

Enter your choice:



You are prompted to continue the setup, depending on the choice you entered:



1. Leave the running configuration unchanged:

The dialog proceeds to the next question. The list remains unchanged.



2. Clear the existing entries and configure new ones:

The dialog prompts you for a new entry in the list.

After completing the first entry, you are asked whether you would like to add another new entry.

Would you like to add another SNMP trap manager? [no]:y

Since the list was empty, you may enter the maximum number of entries.



3. Add new entries:

The dialog prompts you for a new entry in the list.

After the completing one entry, you are asked whether you would like add another new entry.

Would you like to add another SNMP trap manager? [no]:y

You may enter only enough additional entries to reach the maximum number.

File-system Operations



The CLI commands include a complete range of file management commands. These commands allow you to create, delete, copy, and display both files and directories.

Note



Regarding disk capacity: While performing disk operations, the user should take care that the addition of new files that are stored on the SCE disk do not cause the disk to exceed 70%.

Working with Directories



The following file-system operations commands are relevant to directories:

cd
delete
dir
mkdir
pwd
rmdir

Creating a Directory



To create a directory, use the following command::



From the SCE# prompt, type mkdir directory-name and press Enter.

Deleting a Directory



There are two different commands for deleting a directory, depending on whether the directory is empty or not.



To delete a directory and all its files and sub-directories, use the following command::



From the SCE# prompt, type delete directory-name /recursiveand press Enter.



To delete an empty directory, use the following command::



From the SCE# prompt, type rmdir directory-name and press Enter.

Changing Directories



To change the path of the current working directory, use the following command::



From the SCE# prompt, type cd new path and press Enter.

Displaying Working Directory



To display the current working directory, use the following command::



From the SCE# prompt, type pwd and press Enter.

Listing Files in Current Directory



You can display a listing of all files in the current working directory. This list may be filtered to include only application files. The listing may also be expanded to include all files in any sub-directories.



To list all the files in the current directory, use the following command::



From the SCE# prompt, type dir and press Enter.



To list all the applications in the current directory, use the following command::



From the SCE# prompt, type dir applications and press Enter.



To include files in all sub-directories in the listing of the current directory, use the following command::



From the SCE# prompt, type dir -r and press Enter.

Working with Files



The following file-system operations commands are relevant to files:

copy
copy-passive
delete
more
rename
unzip

Renaming a File



To rename a file, use the following command:



From the SCE# prompt, type rename current-file-name new-file-name and press Enter.

Deleting a File



To delete a file, use the following command:



From the SCE# prompt, type delete file-name and press Enter.

Copying a File



You can copy a file from the current directory to a different directory.

You can also copy a file (upload/download) to or from an FTP site. In this case, either the source or destination filename must begin with ftp://. To copy a file using passive FTP, use the copy-passive command.



To copy a file, use the following command:



From the SCE# prompt, type copy source-file-name destination-file-name and press Enter.

Example:



The following example copies the local analysis.sli file located in the root directory to the applications directory.

SCE#copy analysis.sli applications/analysis.sli
SCE#



To download a file from an FTP site:



From the SCE#
        prompt, type copy ftp://source destination-file-name and press
        Enter.



To upload a file to an FTP site using Passive FTP, use the following command:



From the SCE# prompt, type copy-passive source-file-name ftp://destination and press Enter.

Example:



The following example uploads the analysis.sli file located on the local flash file system to the host 10.1.1.105, specifying Passive FTP.

SCE#copy-passive /appli/analysis.sli ftp://myname:mypw@10.1.1.105/p:/appli/analysis.sli
SCE#

Displaying File Contents



To display the contents of a file, use the following command:



From the SCE# prompt, type more file-name and press Enter.

Unzipping a File



Use this command to unzip a file. The specified file must be a zip file.

Files are extracted to the current directory.



To unzip a file, use the following command:



From the SCE# prompt, type unzip file-name and press Enter.

The User Log



The user log is an ASCII file that can be viewed in any editor. It contains a record of system events, including startup, shutdown and errors. You can use the Logger to view the user log to determine whether or not the system is functioning properly, as well as for technical support purposes.

The Logging System



Events are logged to one of two log files. After a file reaches maximum capacity, the events logged in that file are then temporarily archived. New events are then automatically logged to the alternate log file. When the second log file reaches maximum capacity, the system then reverts to logging events to the first log file, thus overwriting the temporarily archived information stored in that file.

Basic operations include:



Copying the User Log to an external source



Viewing the User Log



Clearing the User Log



Viewing/clearing the User Log counters

Copying the User Log



You can view the log file by copying it to an external source or to disk. This command copies both log files to the local SCE platform disk or any external host running a FTP server.



To copy the user log to an external source, use the following command:



From the SCE# prompt, type logger get user-log file-name ftp://username:password@ipaddress/path and press Enter.



To copy the user log to an internal location, use the following command:



From the SCE# prompt, type logger get user-log file-name target-filenameand press Enter.

Enabling and Disabling the User Log



By default, the user log is enabled. You can disable the user log by configuring the status of the logger.



To disable the user log, complete the following steps:



From the SCE# prompt, type configure and press Enter.



Type logger device User-File-Log disabled and press Enter.



To enable the user file log, complete the following steps:



From the SCE# prompt, type configure and press Enter.



Type logger device User-File-Log enabled and press Enter.

Viewing the User Log Counters



There are two types of log counters:



User log counters — count the number of system events logged from the SCE platform last reboot.



Non-volatile counters — are not cleared during boot time



To view the user log counters for the current session, use the following command:



From the SCE# prompt, type show logger device user-file-log counters and pressEnter.



To view the non-volatile logger counters for both the User log file and the debug log file, use the following command:



From the SCE# prompt, type show logger nv-counters and press Enter.



To view the non-volatile counter for the user-file-log only, use the following command:



From the SCE# prompt, type show logger device user-file-log nv-counters and press Enter.

Viewing the User Log

Note



This command is not recommended when the user log is large. Copy a large log to a file to view it (see Copying the User Log)



To view the user log, use the following command:



From the SCE# prompt, type more user-log and press Enter.

Clearing the User Log



You can clear the contents of the user log at any time. The user log contains important information regarding the functioning of the system. It is recommended that a copy be made before the log is cleared.



To clear the user log, complete the following steps:



From the SCE# prompt, type clear logger device user-file-log and press Enter.



The system asks Are you sure?



Type Y and press Enter.

The SCE# prompt appears.

Generating a File for Technical Support



In order for technical support to be most effective, the user should provide them with the information contained in the system logs. Use the logger get support-file command to generate a support file for the use of Cisco technical support staff.



To generate a log file for technical support, use the following command:



From the SCE# prompt, type logger get support-file filename and pressEnter.

The support information file is created using the specified filename. This operation may take some time.

Chapter 5. Configuring the Management Interface and Security



The SCE platform is equipped with two RJ-45 management (MNG)ports. These ports provide access from a remote management console to the SCE platform via a LAN.

The two management ports support management interface redundancy, providing the possibility for a backup management link.

In addition to the Layer 1 security of a backup management link, the Service Control platform provides a further management interface security feature; an IP filter that monitors for various types of TCP/IP attacks. This filter can be configured with thresholds rates both for defining an attack and defining the end of an attack.

Note



The addition of the second management port is reflected in all objects related to it in the SNMP interface.

Perform the following tasks to configure the management interface and management interface security:



Configure the management port:



Physical parameters



Specify active port (if not redundant installation)



Redundancy (if redundant installation)



Configure management interface security



Enable IP fragment filtering



Configure the permitted and not-permitted IP address monitor

Configuring the Management Ports



Perform the following tasks to configure the management ports:



Configure the IP address and subnet mask (only one IP address for the management interface, not one IP address per port).



Configure physical parameters:



Duplex



Speed



Configure redundant management interface behavior (optional):



Fail-over mode



If fail-over mode is disabled, specify the active port (optional).



To configure the management interface, complete the following steps:



Cable the desired management port, connecting it to the remote management console via the LAN.



Disable the automatic fail-over mode. (See Configuring the Fail-Over Mode.)



Configure the management port physical parameters. (See Configuring the Management Port Physical Parameters.)

To configure the system with management interface redundancy, see Configuring the Management Ports for Redundancy.

Entering Management Interface Configuration Mode



When entering Management Interface Configuration Mode, you must indicate the number of the management port to be configured:



0/1 — Mng port 1



0/2 — Mng port 2

The following Management Interface commands are applied only to the port specified when entering Management Interface Configuration Mode. Therefore, each port must be configured separately:



speed



duplex

The following Management Interface commands are applied to both management ports, regardless of which port had been specified when entering Management Interface Configuration Mode. Therefore, both ports are configured with one command:



ip address



auto-fail-over



To enter Global Configuration Mode, type configure and pressEnter.

The SCE(config)# prompt appears.



Type interface Mng {0/1|0/2} and press Enter.

The SCE(config if)# prompt appears.

Configuring the Management Port Physical Parameters



This interface has a transmission rate of 10 or 100 Mbps and is used for management operations and for transmitting RDRs, which are the output of traffic analysis and management operations.

The procedures for configuring this interface are explained in the following sections:



Setting the IP Address and Subnet Mask of the Management Interface.



Configuring the Speed of the Management Interface



Configuring the Duplex Operation of the Management Interface.



Specifying the Active Management Port: only if both of the following conditions are present:



Fail-over mode is disabled (no automatic switch to the backup port).



Active port = Mng Port 2 (Mng port 1 is the default and therefore does not need to be explicitly specified).

Setting the IP Address and Subnet Mask of the Management Interface



The user must define the IP address of the management interface.

When both management ports are connected, providing a redundant management port, this IP address always acts as a virtual IP address for the currently active management port, regardless of which port is the active port.

The following options are available:



IP address — The IP address of the management interface.

If both management ports are connected, so that a backup management link is available, this IP address will be act as a virtual IP address for the currently active management port, regardless of which physical port is currently active.



subnet mask — subnet mask of the management interface.

Warning



Changing the IP address of the management interface via telnet will result in loss of the telnet connection and inability to reconnect with the interface.



To set the IP address and subnet mask of the Management Interface, use the following command:



From the SCE(config if)# prompt, type ipaddress ip-address subnet-mask and press Enter.

The command might fail if there is a routing table entry that is not part of the new subnet, defined by the new IP address and subnet mask.

Example:



The following example shows how to set the IP address of the SCE platform to 10.1.1.1 and the subnet mask to 255.255.0.0.

SCE(config if)#ip address 10.1.1.1 255.255.0.0

Configuring the Management Interface Speed and Duplex Parameters



This section presents sample procedures that describe how to configure the speed and the duplex of the Management Interface.

Both these parameters must be configured separately for each port.

Configuring the Speed of the Management Interface



The following options are available:



speed — speed in Mbps of the currently selected management port (0/1 or 0/2):



auto (default) — auto-negotiation (do not force speed on the link)

If the duplex parameter is configured to auto, changing the speed parameter has no effect (see Interface State Relationship to Speed and Duplex).



To configure the speed of the specified management port, use the following command:



From the SCE(config if)# prompt, type speed 10|100|auto and pressEnter.

Example:



The following example shows how to use this command to configure the Management port to 100 Mbps speed.

SCE(config if)#speed 100

Configuring the Duplex Operation of the Management Interface



The following options are available:



duplex — duplex operation of the currently selected management port (0/1 or 0/2):



full



half



auto (default) — auto-negotiation (do not force duplex on the link)

If the speed parameter is configured to auto, changing the duplex parameter has no effect (see Interface State Relationship to Speed and Duplex).



To configure the duplex operation of the specified management port, use the following command:



From the SCE(config if)# prompt, type duplex auto|full|half and press Enter.

Configures the duplex operation of the currently selected management interface to either auto, half duplex, or full duplex.

Example:



The following example shows how to use this command to configure a management port to half duplex mode.

SCE(config if)#duplex half



Table 5.1. Interface State Relationship to Speed and Duplex

Speed	Duplex	Actual FEI state
Auto	Auto	Auto negotiation
Auto	Full	Auto negotiation
Auto	Half	Auto negotiation
10	Auto	Auto-negotiation (duplex only)
10	Full	10 Mbps and Full duplex
10	Half	10 Mbps and half duplex
100	Auto	Auto-negotiation (speed only)
100	Full	100 Mbps and full duplex
100	Half	100 Mbps and half duplex

Specifying the Active Management Port



This command explicitly specifies which management port is currently active. Its use varies slightly, depending on whether the management interface is configured as a redundant interface (auto fail-over enabled) or not (auto fail-over disabled)



auto fail-over enabled (automatic mode) — the specified port becomes the currently active port, in effect forcing a fail-over action even if a failure has not occurred.



auto fail-over disabled (manual mode) — the specified port should correspond to the cabled Mng port, which is the only functional port and therefore must be and remain the active management port

Note



This command is a Privileged Exec command, unlike the other commands in this section, which are Mng Interface Configuration commands. If in Mng interface configuration mode, you must exit to the privileged exec mode and see the SCE# prompt displayed



The following options are available:



slot-number/interface-number — The interface number (0/1 or 0/2) of the management port that is specified as the active port.



To specify the active management port, use the following command:



From the SCE# prompt, type Interface Mng {0/1 | 0/2} active-port and press Enter.

Example:



The following example shows how to use this command to configure Mng port 2 as the currently active management port.

SCE# Interface Mng 0/2 active-port

Configuring the Management Ports for Redundancy



The SCE platform contains two RJ-45 management ports. The two management ports provide the possibility for a redundant management interface, thus ensuring management access to the SCE platform even if there is a failure in one of the management links. If a failure is detected in the active management link, the standby port automatically becomes the new active management port.

Note that both ports must be connected to the management console via a switch. In this way, the IP address of the MNG port is always the same, regardless of which physical port is currently active.

Important information:



Only one port is active at any time.



The same virtual IP address and MAC address are assigned to both ports.



Default —



Port 1 = active



Port 2 = standby



The standby port sends no packets to the network and packets from the network are discarded.



When a problem in the active port is encountered, the standby port automatically becomes the new active port.



Link problem, with switch to standby MNG port, is declared after the link is down for 300 msec.



Service does not revert to the default active port if/when that link recovers. The currently active MNG port remains active until link failure causes a switch to the other MNG port.



To configure the system with management interface redundancy, complete the following steps:



Cable both management ports (Mng 1 and Mng 2), connecting them both to the remote management console via the LAN and via a switch.



Configure the automatic fail-over mode. (See Configuring the Fail-Over Mode.)



Configure the IP address for the management interface. The same IP address will always be assigned to the active management port, regardless of which physical port is currently active. (See Setting the IP Address and Subnet Mask of the Management Interface.)



Configure the speed and duplex for both management ports. (See Configuring Management Interface Speed and Duplex Parameters.)

Configuring the Fail-Over Mode



Use the following command to enable automatic fail-over. The automatic mode must be enabled to support management interface redundancy. This mode automatically switches to the backup management link when a failure is detected in the currently active management link.

This parameter can be configured when in management interface configuration mode for either management port, and is applied to both ports with one command.

The following options are available:



auto/ no auto — Enable or disable automatic fail-over switching mode



Default — auto (automatic mode)



To enable automatic fail-over mode, use the following command:



From the SCE(config if)# prompt, type auto-fail-over and press Enter.

When the automatic fail-over mode is disabled, by default Mng port 1 is the active port. If Mng port 2 will be the active port, it must be explicitly configured as such (see Specifying the Active Management Port.)



To disable automatic fail-over mode:



From the SCE(config if)# prompt, type no auto-fail-over and pressEnter.

Management Interface Security



Management security is defined as the capability of the SCE platform to cope with malicious management conditions that might lead to global service failure. Resiliency to attacks on the management port includes the following features:



The SCE platform remains stable during flooding attack.



The number of TCP/IP stack control protocol vulnerabilities is minimized.



The availability of reporting capabilities on attacks on the management port.

There are two parallel security mechanisms:



Automatic security mechanism — monitors the TCP/IP stack rate at 200 msec intervals and throttles the rate from the device if necessary.

This mechanism always functions and is not user-configurable



User-configurable security mechanism — accomplished via two IP filters at user-configurable intervals:



IP fragment filter — Drops all IP fragment packets



IP filter monitor — Measures the rate of accepted and dropped packets for both permitted and not-permitted IP addresses.

Configuring Management Port Security



The procedure for configuring management port security is explained in the following sections:



Enabling the IP Fragment Filter



Configuring the Permitted and Not-permitted IP Address Filter

Enabling the IP Fragment Filter



Use this command to enable the filtering out of IP fragments.

The following options are available:



enable/disable — Enable or disable IP fragment filtering



Default — disable



To enable IP fragment filtering, use the following command:



From the SCE(config)# prompt, type ip filter fragment enable and press Enter.



To disable IP fragment filtering, use the following command:



From the SCE(config)# prompt, type ip filter fragment disable and press Enter.

Configuring the Permitted and Not-permitted IP Address Monitor



Use this command to configure the limits for permitted and not-permitted IP address transmission rates.

The following options are available:



ip permitted/ip not-permitted — Specifies whether the configured limits apply to permitted or not-permitted IP addresses.

If neither keyword is used, it is assumed that the configured limits apply to both permitted and not-permitted IP addresses.



low rate — lower threshold; the rate in Mbps that indicates the attack is no longer present



Default — 20



high rate — upper threshold; the rate in Mbps that indicates the presence of an attack



Default — 20



burst size — duration of the interval in seconds that the high and low rates must be detected in order for the threshold rate to be considered to have been reached



Default — 10



To configure the permitted and not-permitted IP address monitor limits, use the following command:



From the SCE(config)# prompt, type ip filter monitor {ip_permited | ip_not_permited} low_rate low_rate high_rate high_rate burst burst size and press Enter.

Monitoring Management Interface IP Filtering



Use this command to display the following information for management interface IP filtering.



IP fragment filter enabled or disabled



configured attack threshold (permitted and not-permitted IP addresses)



configured end of attack threshold (permitted and not-permitted IP addresses)



burst size in seconds  (permitted and not-permitted IP addresses)



To display information relating to the management interface, use the following command:



From the SCE# prompt, type show ip filter and press Enter.

Configuring the Available Interfaces



The system allows you to configure the Telnet and SNMP interfaces according to the manner in which you are planning to manage the SCE platform and the external components of the system.

TACACS+ Authentication, Authorization, and Accounting



TACACS+ is a security application that provides centralized authentication of users attempting to gain access to a network element. The implementation of TACACS+ protocol allows customers to configure one or more authentication servers for the SCE platform, providing a secure means of managing the SCE platform, as the authentication server will authenticate each user. This then centralizes the authentication database, making it easier for the customers to manage the SCE platform.

TACACS+ services are maintained in a database on a TACACS+ server running, typically, on a UNIX or Windows NT workstation. You must have access to and must configure a TACACS+ server before the configured TACACS+ features on your network element are available.

The TACACS+ protocol provides authentication between the network element and the TACACS+ ACS, and it can also ensure confidentiality, if a key is configured, by encrypting all protocol exchanges between a network element and a TACACS+ server.

The following is a summary of the procedure for configuring TACACS+. All steps are explained in detail in the remainder of this section.



To configure TACACS+ authentication, authorization, and accounting, complete the following steps:



Configure the remote TACACS+ servers.

Configure the remote servers for the protocols, Keep in mind the following guidelines:



Configure the encryption key that the server and client will use



The maximal user privilege level and enable password (password used when executing the enable command) should be provided.



The configuration should always include the root user, giving it the privilege level of 15.



Viewer (privilege level 5) and superuser (privilege level 10) user IDs should be established at this time also.

For complete details on server configuration, refer to the appropriate configuration guide for the particular TACACS+ server that you will be using.



Configure the SCE client to work with TACACS+ server:



hostname of the server



port number



shared encryption key (the configured encryption key must match the encryption key configured on the server in order for the client and server to communicate.)



(Optional) Configure the local database, if used.



add new users

If the local database and TACACS+ are both configured, it is recommended to configure the same user names in both TACACS+ and the local database. This will allow the users to access the SCE platform in case of TACACS+ server failure.

Note

Note

If TACACS+ is used as the login method, the TACACS+ username is used automatically in the enable command. Therefore, it is important to configure the same usernames in both TACACS+ and the local database so that the enablecommand can recognize this username.



specify the password



define the privilege level



Configure the authentication methods on the SCE platform.



login authentication methods



privilege level authorization methods



Review the configuration.

Use the "show running-config" command to view the configuration.

The TACACS+ protocol provides the following three features:



Login authentication



Privilege level authorization



Accounting

Login Authentication



The SCE platform uses the TACACS+ ASCII authentication message for CLI, Telnet and SSH access.

TACACS+ allows an arbitrary conversation to be held between the server and the user until the server receives enough information to authenticate the user. This is usually done by prompting for a username and password combination.

The login and password prompts may be provided by the TACACS+ server, or if the TACACS+ server does not provide the prompts, then the local prompts will be used.

The user log on information (user name and password) is transmitted to the TACACS+ server for authentication. If the TACACS+ server indicates that the user is not authenticated, the user will be re-prompted for the user name and password. The user is re-prompted a user-configurable number of times, after which the failed login attempt is recorded in the SCE platform user log and the telnet session is terminated (unless the user is connected to the console port.)

The SCE platform will eventually receive one of the following responses from the TACACS+ server:



ACCEPT – The user is authenticated and service may begin.



REJECT – The user has failed to authenticate. The user may be denied further access, or will be prompted to retry the login sequence depending on the TACACS+ server.



ERROR – An error occurred at some time during authentication. This can be either at the server or in the network connection between the server and the SCE platform. If an ERROR response is received, the SCE platform will try to use an alternative method\server for authenticating the user.



CONTINUE – The user is prompted for additional authentication information.

If the server is unavailable, the next authentication method is attempted, as explained in General AAA Fallback and Recovery Mechanism.

Accounting



The TACACS+ accounting supports the following functionality:



Each executed command (the command must be a valid one) will be logged using the TACACS+ accounting mechanism (including login and exit commands).



The command is logged both before and after it is successfully executed.



Each accounting message contains the following:



User name



Current time



Action performed



Command privilege level

TACACS+ accounting is in addition to normal local accounting using the SCE platform dbg log.

Privilege Level Authorization



After a successful login the user is granted a default privilege level of 0, giving the user the ability to execute a limited number of commands. Changing privilege level is done by executing the "enable" command. This command initiates the privilege level authorization mechanism.

Privilege level authorization in the SCE platform is accomplished by the use of an "enable" command authentication request. When a user requests an authorization for a specified privilege level, by using the "enable" command, the SCE platform sends an authentication request to the TACACS+ server specifying the requested privilege level. The SCE platform grants the requested privilege level only after the TACACS+ server does the following:



Authenticates the "enable" command password



Verifies that the user has sufficient privileges to enter the requested privilege level.

Once the user privilege level has been determined, the user is granted access to a specified set of commands according to the level granted.

As with login authentication, if the server is unavailable, the next authentication method is attempted, as explained in General AAA Fallback and Recovery Mechanism.

General AAA Fallback and Recovery Mechanism



The SCE platform uses a fall-back mechanism in order to maintain service availability in case of an error.

The AAA mechanism in the SCE platform contains several AAA methods that are used to back each other up. The customer may choose the AAA methods that are used and the order in which they are used.

The AAA methods available are:



TACACS+ – AAA is performed by the use of a TACACS+ server, allows authentication, authorization and accounting.



Local – AAA is performed by the use of a local database, allows authentication and authorization.



Enable – AAA is performed by the use of user configured passwords, allows authentication and authorization.



None – no authentication\authorization\accounting is performed.

In the current implementation the order of the methods used isn't configurable but the customer can choose which of the methods are used. The current order is



TACACS+



Local



Enable



None

Note



Important: If the server goes to AAA fault, the SCE platform will not be accessible until one of the AAA methods is restored. In order to prevent this, it is advisable to use the "none" method as the last AAA method.

If the SCE platform becomes un-accessible, the shell function "AAA_MethodsReset" will allow the user to delete the current AAA method settings and set the AAA method used to "Enable".

Configuring the SCE Platform TACACS+ Client



The user must configure the remote servers for the TACACS+ protocol. Then the SCE platform TACACS+ client must be configured to work with the TACACS+ servers. The following information must be configured:



TACACS+ server hosts definition — a maximum of three servers is supported.

For each sever host, the following information can be configured:



hostname (required)



port



encryption key



timeout interval



Default encryption key (optional) — A global default encryption key may be defined. This key is defined as the key for any server host for which a key is not explicitly configured when the server host is defined.

If the default encryption key is not configured, a default of no key is assigned to any server for which a key is not explicitly configured.



Default timeout interval (optional) — A global default timeout interval may be defined. This timeout interval is defined as the timeout interval for any server host for which a timeout interval is not explicitly configured when the server host is defined.

If the default timeout interval is not configured, a default of five seconds is assigned to any server for which a timeout interval is not explicitly configured.

The procedures for configuring the SCE platform TACACS+ client are explained in the following sections:



Adding a new TACACS+ Server Host



Removing a TACACS+ Server Host



Configuring the Global Default Key



Configuring the Global Default Timeout

Adding a new TACACS+ Server Host



Use this command to define a new TACACS+ server host that is available to the SCE platform TACACS+ client.

The Service Control solution supports a maximum of three TACACS+ server hosts.

The following options are available:



host-name — name of the server



port # — TACACS+ port number



Default = 49



timeout interval — time in seconds that the server waits for a reply from the server host before timing out



Default = 5 seconds or user-configured global default timeout interval (see Configuring the Global Default Timeout.)



key-string — encryption key that the server and client will use when communicating with each other. Make sure that the specified key is actually configured on the TACACS+ server host.



Default = no key or user-configured global default key (see Configuring the Global Default Key)



To add a new TACACS+ server host, use the following command:



From the SCE(config)# prompt, type tacacs-server host host-name [port port#] [timeout timeout-interval] [key key-string] and press Enter.

Removing a TACACS+ Server Host



Use this command to delete a TACACS+ server host from the system.

The following options are available:



host-name — name of the server to be deleted



To delete a TACACS+ server host, use the following command:



From the SCE(config)# prompt, type no tacacs-server host host-nameand press Enter.

Configuring the Global Default Key



Use this command to define the global default key for the TACACS+ server hosts. This default key can be overridden for a specific TACACS+ server host by explicitly configuring a different key for that TACACS+ server host.

The following options are available:



key-string — default encryption key that all TACACS servers and clients will use when communicating with each other. Make sure that the specified key is actually configured on the TACACS+ server hosts.



Default = no encryption



To define the global default key, use the following command:



From the SCE(config)# prompt, type tacacs-server key key-stringand press Enter.



To clear the global default key, use the following command:



From the SCE(config)# prompt, type no tacacs-server key and press Enter.

No global default key is defined. Each TACACS+ server host may still have a specific key defined. However, any server host that does not have a key explicitly defined (uses the global default key) is now configured to use no key.

Configuring the Global Default Timeout



Use this command to define the global default timeout interval for the TACACS+ server hosts. This default timeout interval can be overridden for a specific TACACS+ server host by explicitly configuring a different timeout interval for that TACACS+ server host.

The following options are available:



timeout interval — default time in seconds that the server waits for a reply from the server host before timing out.



Default = 5 seconds



To define the global default timeout interval, use the following command:



From the SCE(config)# prompt, type tacacs-server timeout timeout-interval and press Enter.



To clear the global default timeout interval, use the following command:



From the SCE(config)# prompt, type no tacacs-server timeout and pressEnter.

No global default timeout interval is defined. Each TACACS+ server host may still have a specific timeout interval defined. However, any server host that does not have a timeout interval explicitly defined (uses the global default timeout interval) is now configured to a five second timeout interval.

Managing the User Database



TACACS+ maintains a local user database. Up to 100 users can be configured in this local database, which includes the following information for all users:



Username



Password — may configured as encrypted or unencrypted



Privilege level

The procedures for managing the local user database are explained in the following sections:



Adding a User



Deleting a User



Defining the User Privilege Level

Adding a User



Use these commands to add a new user to the local database. Up to 100 users may be defined.

The password is defined with the username. There are several password options:



No password — use the nopassword keyword.



Password — Password is saved in clear text format in the local list.

Use the password parameter.



Encrypted password — Password is saved in encrypted (MD5) form in the local list. Use the secret keyword.

Password may be defined by either of the following methods:



Specify a clear text password, which is saved in MD5 encrypted form



Specify an MD5 encryption string, which is saved as the user MD5-encrypted secret password

The following options are available:



name — name of the user to be added



password — a clear text password. May be saved in the local list in either of two formats:



as clear text



in MD5 encrypted form if the secret keyword is used



encrypted-secret — an MD5 encryption string password

The following keywords are available:



nopassword — There is no password associated with this user



secret — the password is saved in MD5 encrypted form. Use with either of the following keywords to indicate the format of the password as entered in the command:



0 — use with the password option to specify a clear text password that will be saved in MD5 encrypted form



5 = use with the encrypted-secret option to specify an MD5 encryption string that will be saved as the user MD5-encrypted secret password



To add a new user to the local database with a clear text password, use the following command:



From the SCE(config)# prompt, type username name password password and press Enter.



To add a new user to the local database with no password, use the following command:



From the SCE(config)# prompt, type username name nopassword and pressEnter.



To add a new user to the local database with an MD5 encrypted password entered in clear text, use the following command:



From the SCE(config)# prompt, type username name secret 0 password and press Enter.



To add a new user to the local database with an MD5 encrypted password entered as an MD5 encryption string, use the following command:



From the SCE(config)# prompt, type username name secret 5 encrypted-secret and press Enter.

Defining the User Privilege Level



Privilege level authorization in the SCE platform is accomplished by the use of an "enable" command authentication request. When a user requests an authorization for a specified privilege level, by using the "enable" command, the SCE platform sends an authentication request to the TACACS+ server specifying the requested privilege level. The SCE platform grants the requested privilege level only after the TACACS+ server authenticates the"enable" command password and verifies that the user has sufficient privileges the enter the requested privilege level.

Use this command to set the privilege level of the specified user.

The following options are available:



name — name of the user whose privilege level is set



level — the privilege level permitted to the specified user. These levels correspond to the CLI authorization levels, which are entered via the enable command:



0 — User



10 — Admin



15 (default) — Root



To set the privilege level for the specified user, use the following command:



From the SCE(config)# prompt, type username name privilege level and press Enter.

Adding a User with Privilege Level and Password



Use these commands to define a new user, including password and privilege level, in a single command.

Note



In the config files (running config and startup config), this command will appear as two separate commands..



The following options are available:



name — name of the user to be added



password — a clear text password. May be saved in the local list in either of two formats:



as clear text



in MD5 encrypted form if the secret keyword is used



encrypted-secret — an MD5 encryption string password



level — the privilege level permitted to the specified user. These levels correspond to the CLI authorization levels, which are entered via the enable command:



0 — User



10 — Admin



15 (default) — Root

The following keywords are available:



secret — the password is saved in MD5 encrypted form. Use with either of the following keywords to indicate the format of the password as entered in the command:



0 — use with the password option to specify a clear text password that will be saved in MD5 encrypted form



5 = use with the encrypted-secret option to specify an MD5 encryption string that will be saved as the user MD5-encrypted secret password



To add a new user to the local database, specifying the privilege level and a clear text password, use the following command:



From the SCE(config)# prompt, type username name privilege level password password and press Enter.



To add a new user to the local database, specifying the privilege level and an MD5 encrypted password entered in clear text, use the following command:



From the SCE(config)# prompt, type username name privilege level secret 0 password and press Enter.



To add a new user to the local database, specifying the privilege level and an MD5 encrypted password entered as an MD5 encryption string, use the following command:



From the SCE(config)# prompt, type username name privilege level secret 5 encrypted-secret and press Enter.

Deleting a User



Use these commands to delete a specified user from the local database.

The following options are available:



name — name of the user to be deleted



To delete a user from the local database, use the following command:



From the SCE(config)# prompt, type no username name and press Enter.

Configuring AAA Login Authentication



There are two features to be configured for login authentication:



Maximum number of permitted Telnet login attempts



The authentication methods used at login (see General AAA Fallback and Recovery Mechanism.)

The procedures for configuring login authentication are explained in the following sections:



Configuring Maximum Login Attempts



Configuring the Login Authentication Methods

Configuring Maximum Login Attempts



Use this command to set the maximum number of login attempts that will be permitted before the session is terminated. This is relevant only for Telnet sessions. From the local console, the number of re-tries is unlimited.

The following options are available:



number-of-attempts — The maximum number of login attempts that will be permitted before the telnet session is terminated



Default = three



To configure the maximum number of permitted login attempts, use the following command:



From the SCE(config)# prompt, type aaa authentication attempts login number-of-attempts and press Enter.

Configuring the Login Authentication Methods



You can configure "backup" login authentication methods to be used in the event of failure of the primary login authentication method (see General AAA Fallback and Recovery Mechanism).

Use this command to specify which login authentication methods are to be used, and in what order of preference.

The following options are available:



method — the login authentication methods to be used. You may specify up to four different methods, in the order in which they are to be used.



group tacacs+ — Use TACACS+ authentication.



local — Use the local username database for authentication.



enable (default) — Use the "enable" password for authentication



none — Use no authentication.



To configure login authentication methods, use the following command:



From the SCE(config)# prompt, type aaa authentication login default method1 [method2...] and press Enter.

You may list a maximum of four methods; all four methods explained above. List them in the order of priority.



To delete the login authentication methods list, use the following command:



From the SCE(config)# prompt, type no aaa authentication login default and press Enter.

If the login authentication methods list is deleted, the default login authentication method only (enable password) will be used. TACACS+ authentication will not be used.

Configuring AAA Privilege Level Authorization Methods



As with login authentication, you can configure "backup" privilege level authorization methods to be used in the event of failure of the primary privilege level authorization method (see General AAA Fallback and Recovery Mechanism).

Use this command to specify which privilege level authorization methods are to be used, and in what order of preference.,

The following options are available:



method — the privilege level authorization methods to be used. You may specify up to four different methods, in the order in which they are to be used.



group tacacs+ — Use TACACS+ authentication.



local — Use the local username database for authentication.



enable (default) — Use the "enable" password for authentication



none — Use no authentication.



To configure privilege level authorization methods, use the following command:



From the SCE(config)# prompt, type aaa authentication enable default method1 [method2...] and press Enter.

You may list a maximum of four methods; all four methods explained above. List them in the order of priority.



To delete the privilege level authorization methods list, use the following command:



From the SCE(config)# prompt, type no aaa authentication enable default and press Enter.

If the privilege level authorization methods list is deleted, the default login authentication method only (enable password) will be used. TACACS+ authentication will not be used.

Enabling AAA Accounting



If TACACS+ accounting is enabled, the SCE platform sends an accounting message to the TACACS+ server after every command execution. The accounting message is logged in the TACACS+ server for the use of the network administrator.

Use this command to enable or disable TACACS+ accounting.

By default, TACACS+ accounting is disabled.

The following options are available:



level — The privilege level for which to enable the TACACS+ accounting



To enable TACACS+ accounting for a specified privilege level, use the following command:



From the SCE(config)# prompt, type aaa authentication accounting commands level default stop-start group tacacs+ and press Enter.

The start-stop keyword (required) indicates that the accounting message is sent at the beginning and the end (if the command was successfully executed) of the execution of a CLI command.



To disable TACACS+ accounting for a specified privilege level, use the following command:



From the SCE(config)# prompt, type no aaa authentication accounting commands level default and press Enter.

Monitoring TACACS+ Servers



Use these commands to display statistics for the TACACS+ servers.

Note that, although most show commands are accessible to viewer level users, the 'all' option is available only at the admin level. Use the command 'enable 10' to access the admin level.



To display statistics for all TACACS+ servers, use the following command:



From the SCE# prompt, type show tacacs and press Enter.



To display statistics, including keys and timeouts, for all TACACS+ servers, use the following command:



From the SCE# prompt, type show tacacs all and press Enter.

Monitoring TACACS+ Users



Use this command to display the users in the local database, including passwords.

Note that, although most show commands are accessible to viewer level users, this command is available only at the admin level. Use the command 'enable 10' to access the admin level.



To display the users in the local database, use the following command:



From the SCE# prompt, type show users and press Enter.

Configuring Access Control Lists (ACLs)



The SCE platform can be configured with Access Control Lists (ACLs), which are used to permit or deny incoming connections on any of the management interfaces. An access list is an ordered list of entries, each consisting of an IP address and an optional wildcard “mask” defining an IP address range, and a permit/deny field.

The order of the entries in the list is important. The default action of the first entry that matches the connection is used. If no entry in the Access List matches the connection, or if the Access List is empty, the default action is deny.



Configuration of system access is done in two stages:



Creating an access list. (See Adding Entries to an Access List).



Associating the access list with a management interface. (See Defining the Global Access List and Associating an Access List to Telnet Interface.)

Creating an access list is done entry by entry, from the first to the last.

When the system checks for an IP address on an access list, the system checks each line in the access list for the IP address, starting at the first entry and moving towards the last entry. The first match that is detected (that is, the IP address being checked is found within the IP address range defined by the entry) determines the result, according to the permit/deny flag in the matched entry. If no matching entry is found in the access list, access is denied.

You can create up to 99 access lists. Access lists can be associated with system access on the following levels:



Global (IP) level. If a global list is defined using the ip access-class command, when a request comes in, the SCE platform first checks if there is permission for access from that IP address. If not, the SCE does not respond to the request. Configuring the SCE platform to deny a certain IP address would preclude the option of communicating with that address using any IP-based protocol including Telnet, FTP, ICMP and SNMP. The basic IP interface is low-level, blocking the IP packets before they reach the interfaces.



Interface level. Access to each management interface (Telnet, SNMP, etc.) can be restricted to an access list. Interface-level lists are, by definition, a subset of the Global list defined. If access is denied at the global level, the IP will not be allowed to access using one of the interfaces. Once an access list is associated with a specific management interface, that interface checks the access list to find out if there is permission for a specific external IP address trying to access the management interface.

It is possible to configure several management interfaces to the same access list, if this is the desired behavior of the SCE platform.

If no ACL is associated to a management interface or to the global IP level, access is permitted from all IP addresses.

Note



The SCE Platform will respond to ping commands only from IP addresses that are allowed access. Ping from a non-authorized address will not receive a response from the SCE  unit, as ping uses ICMP protocol

The following commands are relevant to access lists:

access-list
access-class number in
ip access-class
no access-list
no ip access-class
show ip access-class

Adding Entries to an Access List



To add an address to an access list allowing access to a particular address, complete the following steps:



To enter the Global Configuration Mode, type configure and press Enter.



The SCE(config)# prompt appears.



To configure one IP address type:

access-list number permit x.x.x.x and press Enter where x.x.x.x is the IP address.



To configure more than one IP address type:

access-list number permit x.x.x.x y.y.y.y and press Enter.

This command configures a range of addresses in the format x.x.x.x y.y.y.y where x.x.x.x specifies the prefix bits common to all IP addresses in the range, and y.y.y.y is a wildcard-bits mask specifying the bits that are ignored. In this notation, ‘0’ means bits to ignore.

Example:



The following example adds an entry to the access list number 1, that permits access only to IP addresses in the range of 10.1.1.0–10.1.1.255.

SCE(config)#access-list 1 permit 10.1.1.0 0.0.0.255

You can also add addresses from which you deny service, by using the deny rather than the permit switch. You can create up to 99 different address lists, which can be associated with access to the interfaces.
When you add a new entry to an ACL, it is always added to the end of the Access-List.

Removing an Access List



To remove an Access List (with all its entries), use the following command:



From the SCE(config)# prompt, type no access-list number permit/deny, and press Enter.

The Access List and all of its entries are removed.

Defining the Global Access List



To define an Access List as the global list for permitting or denying all traffic to the SCE platform, use the following command:



From the SCE(config)# prompt, type ip access-class number, and press Enter.

Telnet Interface



This section discusses the Telnet interface of the SCE platform. A Telnet session is the most common way to connect to the SCE CLI interface.

You can set the following parameters for the Telnet interface:



Enable/disable the interface



Associate an access list to permit or deny incoming connections. (Access lists)



Timeout for Telnet sessions, that is, if there is no activity on the session, how long the SCE platform waits before automatically cutting off the Telnet connection.

The following commands are relevant to Telnet interface:

access-class number in
line vty
[no] access list
[no] service telnetd
[no] timeout
show line vty access-class in
show line vty timeout

Preventing Telnet Access



You can disable access by Telnet altogether.



To disable Telnet access, use the following command:



From the SCE(config)# prompt, type no service telnetd.

Telnet service is no longer allowed on the SCE platform. Current Telnet sessions are not disconnected, but no new Telnet sessions are allowed.

Associating an Access List to Telnet Interface



To restrict the SCE platform management via Telnet to a specific access list, complete the following steps:



From the SCE(config)# prompt, enter the Line Configuration mode by typing line vty 0.



Type access-class access-list-number in (where access-list-number is an index of an existing access list).

The following example associates the access list  number 1 to the Telnet interface.

SCE#configure
SCE (config)#line vty 0
SCE(config-line)#access-class 1 in



Type exit and press Enter.

This returns you to Global Configuration Mode.

Telnet Timeout



The SCE platform supports timeout of inactive Telnet sessions. The default timeout is 30 minutes.



To configure the timeout for a telnet session when the line is idle, use the following command:



From the SCE(config-line)# prompt, type timeout time, where time is the time in minutes.

SSH Server



A shortcoming of the standard telnet protocol is that it transfers password and data over the net unencrypted, thus compromising security. Where security is a concern, using a Secure Shell (SSH) server rather than telnet is recommended.

An SSH server is similar to a telnet server, but it uses cryptographic techniques that allow it to communicate with any SSH client over an insecure network in a manner which ensures the privacy of the communication. CLI commands are executed over SSH in exactly the same manner as over telnet.

The SSH server supports both the SSH-1 and SSH-2 protocols.

An Access Control List (ACL) can be configured for SSH as for any other management protocol, limiting SSH access to a specific set of IP addresses (see Configuring Access Control Lists).

Key Management



Each SSH server should define a set of keys (DSA2, RSA2 and RSA1) to be used when communicating with various clients. The key sets are pairs of public and private keys. The server publishes the public key while keeping the private key in non-volatile memory, never transmitting it to SSH clients. Note that the keys are kept on the tffs0 file system, which means that a person with knowledge of the ‘enable’ password can access both the private and public keys. The SSH server implementation provides protection against eavesdroppers who can monitor the management communication channels of the SCE platform, but it does not provide protection against a user with knowledge of the ‘enable’ password.

Key management is performed by the user via a special CLI command. A set of keys must be generated at least once before enabling the SSH server.

Size of the encryption key is always 2048 bits.

Managing the SSH Server



Use these commands to manage the SSH server. These commands do the following:



Generate an SSH key set



Enable/disable the SSH server



Assign/remove an ACL to the SSH server



Delete existing SSH keys

Remember that you must generate a set of SSH keys before you enable the SSH server.



To generate a set of SSH keys, use the following command:



From the SCE(config)# prompt, type ip ssh key generate and press Enter.

A new SSH key set is generated and immediately saved to non-volatile memory. (Key set is not part of the configuration file). Key size is always 2048 bits.



To enable the SSH server, use the following command:



From the SCE(config)# prompt, type ip ssh and press Enter.



To disable the SSH server, use the following command:



From the SCE(config)# prompt, type no ip ssh and press Enter.



To assign an ACL to the SSH server, use the following command:



From the SCE(config)# prompt, type ip ssh access-class access-list number and press Enter.

The specified ACL is assigned to the SSH server, so that access the SSH server is limited to the IP addresses defined in the ACL.



To remove the ACL assignment from the SSH server, use the following command:



From the SCE(config)# prompt, type no ip ssh access-class and press Enter.

The ACL assignment is removed from the SSH server, so that any IP address may now access the SSH server.



To delete the existing SSH keys, use the following command:



From the SCE(config)# prompt, type ip ssh key remove and press Enter.

The existing SSH key set is removed from non-volatile memory.

If the SSH server is currently enabled, it will continue to run, since it only reads the keys from non-volatile memory when it is started. However, if the startup-configuration specifies that the SSH server is enabled, the SCE platform will not be able to start the SSH server on startup if the keys have been deleted. To avoid this situation, after executing this command, always do one of the following before the SCE platform is restarted (using reload):



Generate a new set of keys.



Disable the SSH server and save the configuration.

Monitoring the Status of the SSH Server



Use this command to monitor the status of the SSH sever, including current SSH sessions.

This command is a Privileged Exec command. Make sure that you are in Privileged Exec command mode by exiting any other modes, and that the SCE# prompt appears in the command line.



To display the SSH server status, use the following command:



From the SCE# prompt, type show ip ssh and press Enter.

SNMP Interface



To enable the SNMP interface, use the snmp-server command. You can also configure any of the SNMP parameters (hosts, communities, contact, location, and trap destination host). When you enable the SNMP agent, these four parameters are filled in with their most recent values before the agent was disabled. To disable the SNMP interface, use the no snmp-server command.

This section guides you through enabling and disabling the SNMP interface. Complete information on SNMP is found in SNMP Configuration and Management.

The following commands are relevant to enabling and disabling the SNMP interface:

[no] snmp-server
[no] snmp-server community
[no] snmp-server contact
[no] snmp-server host
[no] snmp-server location

Enabling SNMP



To enable SNMP by setting a community string, complete the following commands:



To enter the Global Configuration Mode, at the SCE# prompt, type configure and press Enter.

The SCE(config)# prompt appears.



Type snmp-server community community-string, where the community string is a security string that identifies a community of managers that are able to access the SNMP server.

You must define at least one community string in order to allow SNMP access. For complete information on community strings see Configuring SNMP Community Strings.

Disabling SNMP



To disable SNMP access, use the following command:



From the SCE(config)# prompt, type no snmp-server.

SNMP Configuration and Management



The SCE platform operating system includes a Simple Network Management Protocol (SNMP) agent that supports the following:



RFC 1213 standard (MIB-II)



RFC 2737 standard (ENTITY-MIB version 2)



pcube enterprise MIBs

This section explains how to configure the SNMP agent parameters. It also provides a brief overview of SNMP notifications and the supported MIBs, and explains the order in which the MIB must be loaded.

Note



Throughout this manual, the terms SNMP server and SNMP agent are used interchangeably, as equivalents.

SNMP Protocol



SNMP (Simple Network Management Protocol) is a set of protocols for managing complex networks. SNMP works by sending messages, called protocol data units (PDUs), to different parts of a network. SNMP-compliant devices, called agents, store data about themselves in Management Information Bases (MIBs) and return this data to the SNMP requesters.

SCE platform supports the original SNMP protocol (also known as SNMPv1), and a newer version called Community-based SNMPv2 (also known as SNMPv2C).



SNMPv1 — is the first version of the Simple Network Management Protocol, as defined in RFCs 1155 and 1157, and is a full Internet standard. SNMPv1 uses a community-based form of security.



SNMPv2c — is the revised protocol, which includes improvements to SNMPv1 in the areas of protocol packet types, transport mappings, and MIB structure elements but using the existing SNMPv1 administration structure. It is defined in RFC 1901, RFC 1905, and RFC 1906.

SCE platform implementation of SNMP supports all MIB II variables, as described in RFC 1213, and defines the SNMP traps using the guidelines described in RFC 1215.

The SNMPv1 and SNMPv2C specifications define the following basic operations that are supported by SCE platform:



Table 5.2. Request Types

Request Type	Description	Remarks
Set Request	Writes new data to one or more of the objects managed by an agent.	Set operations immediately affect the SCE platform running-config but do not affect the startup config.
Get Request	Requests the value of one or more of the objects managed by an agent.
Get Next Request	Requests the Object Identifier(s) and value(s) of the next object(s) managed by an agent.
Get Response	Contains the data returned by an agent.
Trap	Sends an unsolicited notification from an agent to a manager, indicating that an event or error has occurred on the agent system	SCE platform may be configured to send either SNMPv1 or SNMPv2 style traps.
Get Bulk Request	Retrieves large amounts of object information in a single Request / response transaction. GetBulk behaves as if many iterations of GetNext request/responses were issued, except that they are all performed in a single request/response.	This is newly defined SNMPv2c message.

Configuration via SNMP



SCE platform supports a limited set of variables that may be configured via SNMP (read-write variables). Setting a variable via SNMP (as via the CLI) takes effect immediately and affects only the running-configuration. To make this configuration stored for next reboots (startup-configuration) the user must specify it explicitly via CLI or via SNMP using the Cisco enterprise MIB objects (see the figure in Cisco Enterprise MIB).

It should be noted also that the SCE platform takes the approach of a single configuration database with multiple interfaces that may change this database. Therefore, activating the copy running-config startup-config command via CLI or SNMP makes permanent all the changes made by either SNMP or CLI.

Security Considerations



By default, the SNMP agent is disabled for both read and write operations. When enabled, SNMP is supported over the management port only (in-band management is not supported).

In addition, the SCE platform supports the option to configure community of managers for read-write accessibility or for read-only accessibility. Furthermore, an ACL (Access List) may be associated with a community to allow SNMP management to a restricted set of managers IP addresses.

SNMP Community Strings



An SNMP community string is a text string that acts like a password to permit access to the agent on the SCE platform. The community string is used to authenticate messages that are sent between the management station (the SNMP manager) and the device (the SNMP agent). The community string is included in every message transmitted between the SNMP manager and the SNMP agent.

Configuring SNMP Community Strings



In order to enable SNMP management, you must configure SNMP community strings to define the relationship between the SNMP manager and the agent.

After receiving an SNMP request, the SNMP agent compares the community string in the request to the community strings that are configured for the agent. The requests are valid under the following circumstances:



SNMP Get, Get-next, and Get-bulk requests are valid if the community string in the request matches the read-only community.



SNMP Get, Get-next, Get-bulk and Set requests are valid if the community string in the request matches the agent’s read-write community.

You may specify the following characteristics associated with the community string:



An access list of IP addresses of the SNMP managers permitted to use the community string to gain access to the agent



Read-write or read-only accessibility for the community.

Note



If no access list is configured, all IP addresses can access the agent using the defined community string. For more information about Access Lists, see Configuring Access Control Lists (ACLs)

Note



When defining a community if it is not specified explicitly, the default accessibility is read-only.

The following describes how to configure a community string, as well as how to remove a community string.



To configure a community string:



At the SCE(config)# prompt, type snmp-server community community-string [ro|rw] [acl-number], and press Enter.

The SCE(config)# prompt appears.



If needed, repeat steps 1 to configure additional community strings.

Example:



The following example shows how to configure a community string called “mycommunity” with read-only rights and access list number “1”.

SCE(config)#snmp-server community mycommunity 1

Note



ACL-number is an index to an access list. For further information about access lists, see Configuring Access Control Lists (ACLs)



To remove a community string, use the following command:



At the SCE(config)# prompt, type no snmp-server community community-string, and press Enter.

The community string is removed.

Example:



The following example displays how to remove a community string called “mycommunity”.

SCE(config)#no snmp-server community mycommunity



To display the configured communities, use the following command:



At the SCE# prompt, type show snmp community and press Enter.

The configured SNMP communities appear.

Example:



The following example shows the SNMP communities.

SCE#show snmp community
Community: public, Access Authorization: RO, Access List Index: 1

Notifications



Notifications are unsolicited messages that are generated by the SNMP agent that resides inside the SCE platform when an event occurs. When the Network Management System receives the notification message, it can take suitable actions, such as logging the occurrence or ignoring the signal.

Configuring Notifications



By default, the SCE platform is not configured to send any SNMP notifications. You must define the Network Management System to which the SCE platform should send notifications. (See the table below, Configurable Notifications, for a list of configurable notifications). Whenever one of the events that trigger notifications occurs in the SCE platform, an SNMP notification is sent from the SCE platform to the list of IP addresses that you define.

SCE platform supports two general categories of notifications:



Standard SNMP notifications — As defined in RFC1157 and using the conventions defined in RFC1215.



Proprietary SCE enterprise notifications — As defined in the SCE proprietary MIB (see Notification Types).

After a host or hosts are configured to receive notifications, by default, the SCE platform sends to the host or hosts all the notifications supported by the SCE platform except for the AuthenticationFailure notification. The SCE platform provides the option to enable or disable the sending of this notification, as well as some of the SCE enterprise notifications, explicitly.

SCE platform can be configured to generate either SNMPv1 style or SNMPv2c style notifications. By default, the SCE platforms sends SNMPv1 notifications.

Following are some sample procedures illustrating how to do the following:



Configure hosts (NMS) to which the SNMP agent should send notifications



Enable the SNMP agent to send authentication-failure notifications



Reset all notifications to the default setting



Remove/disable a host (NMS) from receiving notifications



To configure the SCE platform to send notifications to a host (NMS), use the following command:



At the SCE(config)# prompt, type snmp-server host IP-address community-string, and press Enter.

Example:



The following example shows how to configure the SCE platform to send SNMPv1 notifications to several hosts.

SCE(config)#snmp-server host 10.10.10.10 mycommunity
SCE(config)#snmp-server host 20.20.20.20 mycommunity
SCE(config)#snmp-server host 30.30.30.30 mycommunity
SCE(config)#snmp-server host 40.40.40.40 mycommunity



To enable the SNMP server to send Authentication Failure notifications, use the following command:



At the SCE(config)# prompt, type snmp-server enable traps snmp authentication, and press Enter.

The SNMP server is enabled to send authentication failure notifications.

Example:



The following example shows how to configure the SNMP server to send the Authentication failure notification.

SCE(config)#snmp-server enable traps snmp authentication

You may enable or disable a specific enterprise notification or all enterprise notifications.



To enable the SNMP server to send all Enterprise notifications, use the following command:



At the SCE(config)# prompt, type snmp-server enable traps enterprise, and press Enter.

The SNMP server is enabled to send all enterprise notifications.

Example:



The following example shows how to configure the SNMP server to send all enterprise notifications.

SCE(config)#snmp-server enable traps enterprise



To enable the SNMP server to send a specific Enterprise notification, use the following command:



At the SCE(config)# prompt, type snmp-server enable traps  enterprise [chassis|link-bypass|logger|operational-status|
RDR-formatter|sntp|system-reset|telnet] and press Enter.

The SNMP server is enabled to send the specified enterprise notification(s).

Example:



The following example shows how to configure the SNMP server to send the logger enterprise notification only.

SCE(config)#snmp-server enable traps enterprise logger



To restore all notifications to the default status, use the following command:



At the SCE(config)# prompt, type default snmp-server enable traps, and press Enter.

All notifications supported by the SCE platform are reset to their default status.

Example:



The following example shows how to restore all SNMP notifications to their default status.

SCE(config)#default snmp-server enable traps



To configure the SCE to stop sending notifications to an NMS, use the following command:



At the SCE(config)# prompt, type no snmp-server host IP-address, and press Enter.

The SCE(config)# prompt appears.

Example:



The following example shows how to remove the host with the IP Address: “192.168.0.83”.

SCE(config)#no snmp-server host 192.168.0.83

CLI



The SCE platform supports the CLI commands that control the operation of the SNMP agent. All the SNMP commands are available in Admin authorization level. The SNMP agent is disabled by default and any SNMP configuration command enables the SNMP agent (except where there is an explicit disable command).

Privileged Exec Mode Commands



The following SNMP commands are available in Exec mode when the SNMP agent is enabled:

show snmp (also available when SNMP agent is disabled)
show snmp community
show snmp contact
show snmp enabled
show snmp host
show snmp location
show snmp mib
show snmp traps

Global Configuration Mode Commands



The following SNMP commands are available in Global Configuration Mode:

snmp-server enable
no snmp-server
snmp-server community
no snmp-server community all
[no | default] snmp-server enable traps
[no] snmp-server host
no snmp-server host all
[no] snmp-server contact
[no] snmp-server location

MIBs



MIBs (Management Information Bases) are databases of objects that can be monitored by a network management system (NMS). SNMP uses standardized MIB formats that allow any SNMP tools to monitor any device defined by a MIB.

The SCE platform supports the following MIBs:



Standard MIBs:



MIB-II (as defined in RFC 1213, Management Information Base for Network Management of TCP/IP-based Internets) and some of its extensions.



ENTITY-MIB version 2 (as defined in RFC 2737)



Proprietary MIBs – MIBs defined by Pcube, for Pcube products (see Proprietary MIB Reference.).

Pcube enterprise MIB (pcube) can be divided into different kinds of MIBs:



Proprietary SCOS MIBs – These MIBs contain platform specific information. They also contain the generic definitions of the pcube subtree.

The SCE MIB and the Dispatcher MIB are two examples of OS MIBs.



Proprietary Application MIB(s) – These MIBs contain application specific information.

Currently, there is one application MIB – Engage MIB.



Proprietary Common MIB(s) – These MIBs contain functionality that is common across more than a single Cisco platform.

Currently there is one common MIB – configuration copy MIB.

Since the acquisition of P-cube, Inc by Cisco Systems, Inc, the existing proprietary MIBs have undergone a process of updating to make them conform to Cisco standards. Note that all PcubeMIBs since SCOS version 3.0.3 are compiled using SMICNG and are in conformation with Cisco standards and styling.

Note



While the designations "Pcube" and "SC” have been retained in the MIB for the sake of consistency, they refer to the corresponding Cisco SCE products.

The data objects that make up the MIB may be identified in two ways:



OID (Object Identifier) — The unique string that describes a specific data object in the agent database.

OIDs are written in dotted format such as: 1.3.6.1.4.1.5655.4.1.10.1



MIB descriptor — A name defined in the MIB file for the OID. It is often used instead of the explicit OID.

For instance: “ifTable” stands for the OID of the MIB-II interface table.

MIB-II



SCE platform fully supports MIB-II (RFC1213), including the following groups:



System



Interface (for both the management and line ports)



AT (management port)



IP (management port)



ICMP (management port)



TCP (management port)



UDP (management port)



SNMP (management port)

IF-MIB



The MIB-II standard has been extended by a number of different MIBs. The SCOS supports the IF-MIB, defined in RFC-2233.

The IF-MIB defines the following four tables:

iftable	An update to the MIB-II ifTable
ifxtable	An addition to the ifTable, intended for high capacity interfaces
ifStackTable	A table containing information about sublayers of interfaces
ifRcvAddressTable	A table meant for interfaces that support more than one receive address





These are the details of specific objects in this MIB:

ifindex	The numbering of the interfaces is such that the port(s) come first.
ifdescr	The same as the CLI name of the interface.
ifPhysAddress	For Management interfaces, this is the MAC address. For traffic interfaces, this is an all zeros address.
IfAdminStatus	Write operation to this object is not supported. This OK according to Ethernet MIB RFC2665 section 3.2.7
IfOutQLen	Always returns 0.
Under ifXTable: ifname	The same as ifDescr.
ifpromiscuousmode	Management interface – “false”. Traffic interfaces – “true”.
ifRcvAddressTable	Not implemented
iftesttable	Was deprecated by RFC-2233, and is therefore not implemented

ENTITY-MIB



The Entity-MIB contains five groups of MIB objects:



entityPhysical group



entityLogical group



entityMapping group



entityGeneral group



entityNotifications group

The SCOS implements only the physical and the general groups of the Entity-MIB, since the other groups are not relevant to the SCE platform.

entityPhysical group



The entityPhysical group describes the physical entities managed by a single agent. It contains a single table, the entPhysicalTable, that identifies physical system components.

These are the details of specific objects in the entPhysicalTable, as implemented in SCOS:

entPhysicalIndex (1)	1 (SCE main board)
entPhysicalDescr (2)	The description corresponding to the Product ID, as it appears in the product catalog.
entPhysicalVendorType (3)	cevChassisSCE2000 = {cevChassis 511} (1.3.6.1.4.1.9.12.3.1.3.511) cevChassisSCE1000 = {cevChassis 512} (1.3.6.1.4.1.9.12.3.1.3.512)
entPhysicalContainedIn (4)	0 (not contained)
entPhysicalClass (5)	3 (chassis)
entPhysicalParentRelPos (6)	1
entPhysicalName (7	"Chassis"
entPhysicalHardwareRev (8)	Version ID, as identified in EPROM
entPhysicalFirmwareRev (9)	empty string
entPhysicalSoftwareRev (10)	Software version, as seen in "show version"
entPhysicalSerialNum (11)	Serial number, as identified in EPROM
entPhysicalMfgName (12)	"Cisco Systems, inc."
entPhysicalModelName (13)	Product ID, as identified in EPROM
entPhysicalAlias (14)	empty string
entPhysicalAssetID (15)	empty string
entPhysicalIsFRU (16)	2 (false)

entityGeneral group



The entityGeneral group contains general information relating to the other object groups. The entGeneral group contains a single scalar object.

These are the details of specific object in the entityGeneral group,as implemented in SCOS:

entLastChangeTime

sysUpTime. This reflects the fact that the entries in the Entity-MIB do not change in the SCE platform after their creation at boot time.

pcube Enterprise MIB



The SCE proprietary pcube MIB enables external management systems to retrieve general information regarding the SCE platform operating status and resources utilization, extract real time measurements of bandwidth utilization and network statistics, and receive notifications of critical events and alarms.

Note



The following object identifier represents the pcube Enterprise MIB:

1.3.6.1.4.1.5655, or iso.org.dod.internet.private.enterprise.pcube

The pcube Enterprise MIB splits into four main groups:



Products



Modules



Management



Workgroup

The pcube enterprise tree structure is defined in a MIB file named pcube.mib.

Refer to the Proprietary MIB Reference for a complete description of the pcube enterprise MIB.

The figure below illustrates the pcube Enterprise MIB structure.

Conventions used in the diagram:



Dotted arrows surrounding a unit or units indicate that the component is described in the MIB file specified below the line.



A shadowed box indicates that the component is described in its own MIB file.



Figure 5.1. Cisco Service Control MIB Structure



pcubeProducts subtree — contains the OIDs of Cisco Service Control products.



pcubeModules subtree — provides a root object identifier under which MIB modules can be defined.



pcubeMgmt subtree — the root for pcube MIBs that are relevant to multiple products.



pcubeConfigCopy MIB — a subset of the Cisco Config-Copy-MIB that supports local copying of running config to startup config.



pcubeWorkgroups subtree — contains the actual MIBs for Cisco Service Control devices and sub-devices.



pcubeSeMIB — comprises two branches:



pcubeSeEvents — Contains the OIDs used for sending enterprise-specific notifications.



pcubeSEObjs  — Contains the OIDs that belong to the SCE platform, divided into groups according to functionality.

Loading the MIB Files



The Service Control proprietary MIB uses definitions that are defined in other MIBs, such as pcube MIB (pcube.mib), and the SNMPv2.mib. Therefore, the order in which the MIBs are loaded is important. To avoid errors, the MIBs must be loaded in the proper order.

Note



Information and proprietary MIB files supported by the SCOS can be downloaded from:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
under the Cisco Service Routing Products section.



To load the MIBs, complete the following steps:



Load the SNMPv2.my



Load the SNMP-FRAMEWORK-MIB.my



Load PCUBE-SMI.my.



Load PCUBE-SE-MIB.my.

Passwords



Cisco CLI passwords are an access-level authorization setting, not individual user passwords. All Admin users, for example, log in with the same password. This means that the system does not identify you as an individual, but as a user with certain privileges.

Passwords are needed for all authorization levels in order to prevent unauthorized users from accessing the SCE platform. It is highly recommended that you change the default password upon initial installation, and that you change the passwords periodically to secure the system.

Note



The default password for all levels is either "pcube" or “cisco”.

When a telnet user logs on, he sees only a Password: prompt, no logo is displayed. This provides extra security by not revealing the system identity to users that do not know the password.

Password guidelines:



Password length must be between 4 and 100 characters long.



Passwords can contain any visible keyboard character.



Passwords must begin with a letter.



Passwords cannot contain spaces.



Passwords are case-sensitive.

Users with Admin or higher authorization level can view the configured passwords using the show running-config or the show startup-config commands. Therefore, if you want passwords to remain completely confidential, you must activate the encryption feature, described in Encryption

Changing Passwords



Use the enable password command to change the password. Note that if the password has been changed, the default password will no longer be accepted.



To change the password for a specified level, complete the following steps:



At the SCE> prompt, to access the Admin authorization level, type enable and press Enter.

The Password: prompt appears.



Type cisco (the default password for the Admin level) and press Enter.

The SCE# prompt appears.



To enter the Global Configuration Mode, type configure and press Enter.

The SCE(config)# prompt appears.



Type enable password level <level> <password>, and press Enter.

Use the appropriate value for the level parameter as follows:



0: user



10: admin



15: root

Your new password for the specified level is entered into the system.

The SCE(config)# prompt appears.



Type exit to exit the Global Configuration Mode and press Enter.

The SCE# prompt appears.



At this point, the Network Administrator should record passwords in a secure location.



To verify that you configured your passwords correctly, complete the following steps:



Initiate a new telnet connection, while maintaining the one you used to set the password.

This is needed so that if the verification fails, you would still have admin level authorization in order to re-enter the password.



At the SCE# prompt, do one of the following, according to the password level you are checking:



Type enable.

OR



Type enable 15. (Root level)



Press Enter.



Type your new password and press Enter.

If your new password has been entered successfully, then the SCE Admin or Root prompt appears.

If you enter an incorrect password , the following error message appears: “Error—The supplied password is simply not right.”



Repeat steps 1 to 3 to check additional passwords.

The encryption feature will encrypt the passwords in the platform configuration files.

Encryption



Once the encryption feature is activated, passwords entered into the system are encrypted to the startup configuration file the next time the configuration is saved. When encryption feature is turned off, passwords previously encrypted to the startup configuration file are not deciphered.

By default, the password encryption feature is turned off.



To enable password encryption, use the following command:



From the SCE(config)# prompt, type service password encryption.

Password encryption is enabled.



To disable password encryption, use the following command:



From the SCE(config)# prompt, type no service password encryption.

This does not remove the encryption from the configuration file. You must save to the startup configuration file if you want the password to be stored un-encrypted on the startup configuration file.

Note



Once the system is secured, you cannot recover a lost or forgotten password. Contact your Cisco customer support center if the password is lost.

Password Recovery



Use the following procedures if it becomes necessary to recover the enable passwords for the SCE platform.

Be sure to use the appropriate procedure depending on the version of SCOS you are using:



Version prior to 2.5.5



Version 2.5.5 or later

Recovering the Passwords: SCOS versions prior to 2.5.5



For SCE platforms running a SCOS version prior to 2.5.5, you can recover the passwords by simply removing the config.txt file and then rebooting.

Note



This procedure resets the configuration of the SCE platform to factory defaults. Therefore, this procedure should be performed only after making sure that no traffic can be affected by the behavior of the SCE platform.

Note



This procedure resets the configuration of the SCE platform to factory defaults. Therefore, all current user configuration is lost. To recover the passwords without losing the user configuration, use the procedure described in Recovering the Passwords: Saving the Current Configuration



Connect a serial terminal to the ‘aux’ port at 9600 baud.



Press Enter.

When the prompt appears, connectivity is verified.



Delete the configuration file, which contains the unknown passwords.

Type rm "/tffs0/system/config.txt" and press Enter.



Reboot the system to restore the default configuration, including default passwords.

Type reboot and press Enter.

In order to block unauthorized users from connecting to the SCE platform using the default password, a new password should be configured immediately for all levels for which such a password is required. The configuration should be saved (use the CLI command copy running-config startup-config) to make the new passwords permanent.

Recovering the Passwords: Saving the Current Configuration



The previous procedure, while quick and easy to use, resets the configuration of the SCE platform to factory defaults, replacing all current user configuration. Use this procedure, which saves the configuration file, to recover the passwords without losing the current configuration.

Note



Although this procedure does save the current configuration, the process involves a temporary reset of the configuration of the SCE platform to factory defaults. Therefore, this procedure should be performed only after making sure that no traffic can be affected by the behavior of the SCE platform.



Connect a serial terminal to the ‘aux’ port at 9600 baud.



Press Enter.

When the prompt appears, connectivity is verified.



Rename the configuration file so that it will not be lost when the system is rebooted. Use the following commands:

cd "system"
rename “config.txt”,”config2.txt”



Reboot the system to reset passwords. This will provide access to the system.

Type reboot and press Enter.

The SCE platform reboots and the default configuration is restored, in which all passwords are pcube. (Only the IP address configuration should remain as it was last configured.)



Establish a Telnet session to the SCE platform and copy the file /system/config2.txt to your PC using the SCE platform FTP client.

The format of the command is:

copy /system/config2.txt ftp://user:password@192.168.0.13/d:/temp/config2.txt



On your PC, view the file. Look for the lines that start with enable password.



If passwords are not encrypted: you will be able to see the passwords, and can simply take note of them.



If passwords are encrypted (see Encryption): edit the file by removing the lines that begin with enable password,  save the file, and then copy the file from your PC back to the SCE platform disk space using the SCE platform FTP client.

The format of the command is:

copy ftp://user:password@192.168.0.13/d:/temp/config2.txt /system/config2.txt



Rename the configuration file on the SCE platform back to the original name “config.txt”:

Type rename /system/config2.txt /system/config.txt and press Enter.



Reload the SCE platform to restore the saved user configuration.

Type reboot and press Enter.

The SCE platform reboots and the saved user configuration is restored.



If passwords were not encrypted: the user-configured passwords that you viewed in the copied file are restored, since the configuration file was not changed.



If passwords were encrypted: the default password pcube remains, since the encrypted lines were removed from the configuration file before it was copied back to the SCE platform.

In order to block unauthorized users from connecting to the SCE platform using the default password, a new password should be configured immediately for all levels for which such a password is required. The configuration should be saved (use the CLI command copy running-config startup-config) to make the new passwords permanent.

Recovering the Passwords: SCOS versions 2.5.5 or later



In SCOS versions 2.5.5 or later, a specific command is available to restore the default passwords. However, it is important to note that this default password configuration is only temporary. New passwords should be configured and saved immediately both for security and also so that the unknown passwords will not be restored in case of system reboot.

Note



This procedure does not affect configuration parameters other then login passwords. It is, therefore, safe to execute during traffic control.



Connect a serial terminal to the ‘aux’ port at 9600 baud.



Press Enter.

When the prompt appears, connectivity is verified.



Reset the passwords.

Type PSWD_ResetAll and press Enter.

The following message will appear:

All 'enable' passwords have been reset.

The SCOS is now using the default passwords for all levels. Note that this is a temporary state that is not preserved after a reboot. Rebooting the SCE platform without changing and saving the passwords will restore the unknown passwords.

In order to block unauthorized users from connecting to the SCE platform using the default password, a new password should be configured immediately for all levels for which such a password is required. The configuration should be saved (use the CLI command copy running-config startup-config) to make the new passwords permanent.

IP Configuration

IP Routing Table



For handling IP packets on the out of band FE port, the SCE platform maintains a static routing table. When a packet is sent, the system checks the routing table for proper routing, and forwards the packet accordingly. In cases where the SCE platform cannot determine where to route a packet, it sends the packet to the default gateway.

SCE platform supports the configuration of the default gateway as the default next hop router, as well as the configuration of the routing table to provide different next hop routers for different subnets (for maximum configuration of 10 subnets).

The following sections illustrate how to use CLI commands to configure various parameters.

The following commands are relevant to IP Routing tables:

ip route prefix mask next-hop
no ip route all
no ip route prefix mask
show ip route
show ip route prefix
show ip route prefix mask

Default Gateway



To configure the default gateway, use the following command:



From the SCE(config)# prompt, type ip default-gateway <address>, and press Enter.

Example:



The following example shows how to set the default gateway IP of the SCE platform to 10.1.1.1.

SCE(config)#ip default-gateway 10.1.1.1

Adding IP Routing Entry to Routing Table



To add an IP routing entry to the routing table, use the following command:



From the SCE(config)# prompt, use the ip route <prefix> <mask> <next-hop> command, and press Enter.

The IP routing entry is added to the routing table. (All addresses must be in dotted notation. The next-hop must be within the Fast-Ethernet interface subnet.)

Example:



The following example shows how to set the router 10.1.1.250 as the next hop to subnet 10.2.0.0.

SCE(config)#ip route 10.2.0.0 255.255.0.0 10.1.1.250

Show IP Route



To use show ip route command to display the entire routing table, use the following command:



From the SCE# prompt, type show ip route and press Enter.

The entire routing table and the destination of last resort (default-gateway) appear.

Example:

SCE#show ip route
gateway of last resort is        10.1.1.1

|    prefix        |    mask         |    next hop     |
|------------------|-----------------|-----------------|
|        10.2.0.0  |    255.255.0.0  |      10.1.1.250 |
|        10.3.0.0  |    255.255.0.0  |      10.1.1.253 |
|        198.0.0.0 |       255.0.0.0 |      10.1.1.251 |
|        10.1.60.0 |   255.255.255.0 |      10.1.1.5   |



To use show ip route prefix command to display routing entries from the subnet specified by the prefix and mask pair, use the following command:



From the SCE# prompt, type show ip route prefix mask and press Enter.

Routing entries with this prefix and mask pair appear.

Example:

SCE#show ip route 10.1.60.0 255.255.255.0
|    prefix       |     mask        |    next hop     |
|-----------------|-----------------|-----------------|
|       10.1.60.0 |   255.255.255.0 |        10.1.1.5 |
SCE#

IP Advertising



IP advertising is the act of periodically sending Ping requests to a configured address at configured intervals. This maintains the SCE platform IP/MAC addresses in the memory of adaptive network elements, such as switches, even during a long period of inactivity.

The following commands are relevant to IP advertising:

[no] ip advertising
ip advertising destination
ip advertising interval
default ip advertising destination
default ip advertising interval
show ip advertising
show ip advertising destination
show ip advertising interval

Configuring IP Advertising



In order to configure IP advertising, you must first enable IP advertising. You may then specify a destination address to which the ping request is to be sent and/or the frequency of the ping requests (interval). If no destination or interval is explicitly configured, the default values are assumed.



To enable IP advertising, use the following command:



From the SCE(config)# prompt, type ip advertising, and press Enter.



To configure the IP advertising destination, use the following command:



From the SCE(config)# prompt, type ip advertising destination <destination>, and press Enter.

The specified IP address is the destination for the ping requests.



To configure the IP advertising interval in seconds, use the following command:



From the SCE(config)# prompt, type ip advertising interval <interval>, and press Enter.

The ping requests are sent at the specified intervals.

Example:



The following example shows how to configure IP advertising, specifying 10.1.1.1 as the destination and an interval of 240 seconds.

SCE(config)#ip advertising destination 10.1.1.1 interval 240

Show IP Advertising



To display the current IP advertising configuration, use the following command:



From the SCE# prompt, type show ip advertising and press Enter.

The status of IP advertising (enabled or disabled), the configured destination, and the configured interval are displayed.

Setting the IP Address and Subnet Mask of the Management Interface



The user must define the IP address of the management interface.

When both management ports are connected, providing a redundant management port, this IP address always acts as a virtual IP address for the currently active management port, regardless of which port is the active port.

The following options are available:



IP address — The IP address of the management interface.

If both management ports are connected, so that a backup management link is available, this IP address will be act as a virtual IP address for the currently active management port, regardless of which physical port is currently active.



subnet mask — subnet mask of the management interface.

Warning



Changing the IP address of the management interface via telnet will result in loss of the telnet connection and inability to reconnect with the interface.



To set the IP address and subnet mask of the Management Interface, use the following command:



From the SCE(config if)# prompt, type ipaddress ip-address subnet-mask and press Enter.

The command might fail if there is a routing table entry that is not part of the new subnet, defined by the new IP address and subnet mask.

Example:



The following example shows how to set the IP address of the SCE platform to 10.1.1.1 and the subnet mask to 255.255.0.0.

SCE(config if)#ip address 10.1.1.1 255.255.0.0

Time Clocks and Time Zone



The SCE platform has three types of time settings, which can be configured: the clock, the calendar, and the time zone. It is important to synchronize the clock and calendar to the local time, and to set the time zone properly. The SCE platform does not track Daylight Saving Time automatically, so you must update the time zone when the time changes bi-annually.

The SCE platform has the following two time sources:



A real-time clock, called the calendar, that continuously keeps track of the time, even when the SCE platform is not powered up. When the SCE platform reboots, the calendar time is used to set the system clock. The calendar is not used for time tracking during system operation.



A system clock, which creates all the time stamps during normal operation. This clock clears if the system shuts down. During a system boot, the clock is initialized to show the time indicated by the calendar.

It does not matter which clock you set first, as long as you use the clock and calendar read commands to ensure they are synchronized.

The time zone settings are important because they allow the system to communicate properly with other systems in other time zones. The system is configured based on Greenwich Mean Time (GMT), which is standard in the industry for coordination with other manufacturers’ hardware and software. For example, Pacific Standard Time would be written as PST-10, meaning that the name of the time zone is PST, which is 10 hours behind Greenwich Mean Time.

When setting and showing the time, the time is always typed or displayed according to the local time zone configured.

Showing System Time



To display the current time of the system clock, use the following command:



From the SCE(config)# prompt, type show clock and press Enter.

Example:



The following example shows the current system clock.

SCE#show clock
12:50:03  UTC  MON  November 13 2001

Setting the Clock



To set the clock, use the following command:



From the SCE# prompt, type clock set <hh:mm:ss day month year>, where <hh:mm:ss day month year> is the time and date you want to set, and press Enter.

Example:



The following example shows how to set the clock to 20 minutes past 10 AM, October 13, 2001, updates the calendar and then displays the time.

SCE#clock set 10:20:00 13 oct 2001
SCE#clock update-calendar
SCE#show clock
10:21:10  UTC  THU  October  13  2001

Setting the Calendar



To set the calendar, complete the following steps:



From the SCE# prompt, type calendar set <hh:mm:ss day month year>, where <hh:mm:ss day month year> is the time and date you want to set.

This sets the system calendar, displaying the time and date.



Synchronize the clock with the calendar time you just set by typing clock read-calendar.

The time specified in this command is relative to the configured time zone.

Example:



The following example shows that the calendar is set to 20 minutes past 10 AM, October 13, 2001.

SCE#calendar set 10:20:00 13 oct 2001
SCE#clock read-calendar
SCE#show calendar
10:20:00  UTC  THU  October  13  2001

Showing Calendar Time



To display the current time and date of the system calendar, use the following command:



From the SCE# prompt, type show calendar and press Enter.

Example:



The following example shows the current system calendar.

SCE#show calendar
12:50:03  UTC  MON  November 13 2001

Setting the Time Zone



To set the current time zone, use the following command:



From the SCE(config)# prompt, type clock timezone <zone> <hours>, where <zone> is the name of the time zone and <hours> is the offset from GMT.

Example:



The following example shows how to set the time zone to Pacific Standard Time with an offset of 10 hours behind GMT.

SCE(config)#clock timezone PST –10
SCE(config)#

Note



You can configure time zones that do not differ from GMT by a multiple of one hour. Consult the CLI Command Reference regarding the clock timezone global configuration command.

Removing Current Time Zone Setting



To remove the current time zone setting, use the following command:



From the SCE(config)# prompt, type no clock timezone and press Enter.

The default time zone is UTC (GMT).

Example:



The following example shows how to remove the time zone setting.

SCE(config)#no clock timezone

Configuring Daylight Saving Time



The SCE platform can be configured to automatically switch to daylight savings time on a specified date, and also to switch back to standard time. In addition, the three-letter time zone code can be configured to vary with daylight savings time if required. (For instance, in the eastern United States, standard time is designated EST, and daylight savings time is designated EDT).

The transition times into and out of daylight savings time may be configured in one of two ways, depending on how the dates for the beginning and end of daylight savings time are determined for the particular location:



recurring — If daylight savings time always begins and ends on the same day every year, (as in the United States), the clock summer-time recurring command is used. The beginning and ending days for daylight savings time can be configured once, and the system will automatically perform the switch every year.



not recurring — If the start and end of daylight savings time is different every year, (as in Israel), the clock summer-time command is used. In this case, the transitions must be configured every year for that particular year. (Note that "year" is not necessarily a calendar year. If the transition days are determined in the fall, the transitions for that fall and the next spring may be configured.)

The day on which the transition takes place may be defined in several ways:



Specific date — For example, March 29, 2004. A specific date, including the year, is defined for a not recurring configuration.



First/last occurrence of a day of the week in a specified month — For example, the last Sunday in March. This is used for a recurring configuration.



Day of the week in a specific week in a specified month — For example, Sunday of the fourth week of March. (This would be different from the last Sunday of the month whenever there were five Sundays in the month). This is used for a recurring configuration.

General guidelines for configuring daylight savings time transitions:



Specify the three letter time zone code for daylight savings time.



recurring — specify a day of the month (week#|first|last/day of the week/month).



not recurring — specify a date (month/day of the month/year).



Define two days:



Day1 = beginning of daylight savings time.



Day2 = end of daylight savings time.

In the Southern hemisphere, month2 must be before month1, as daylight savings time begins in the fall and ends in the spring.



Specify the exact time that the transition should occur (24 hour clock).



Time of transition into daylight savings time — according to local standard time.



Time of transition out of clock summer-time recurring  — according to local daylight savings time.



Offset — specify the difference in minutes between standard time and daylight savings time.

Default = 60 minutes



For the clock summer-time recurring command, the default values are the United States transition rules:



Daylight savings time begins — 2:00 (AM) on the first Sunday of April.



Daylight savings time ends — 2:00 (AM) on the last Sunday of October.



To define recurring daylight savings time transitions, use the following command:



From the SCE(config)# prompt, type clock summer-time <zone> recurring [<week1> <day1> <month1> <time1> <week2> <day2> <month2> <time2> [<offset>]] and press Enter.

Example:



The following example shows how to configure recurring daylight savings time for a time zone designated "DST" as follows:



Daylight savings time begins — 0:00 on the last Sunday of March.



Daylight savings time ends — 23:59 (AM) on the Saturday of fourth week of November.



Offset = 1 hour (default)

SCE(config)# clock summer-time DST recurring last Sunday March 00:00   4 Saturday November 23:59



To define non-recurring daylight savings time transitions, use the following command:



From the SCE(config)# prompt, type clock summer-time <zone> [<date1> <month1> <year1> <time1> <date2> <month2> <year2> <time2> [<offset>]] and press Enter.

Example:



The following example shows how to configure non-recurring daylight savings time for a time zone designated "DST" as follows:



Daylight savings time begins — 0:00 on April 16, 2004.



Daylight savings time ends — 23:59 October 23, 2004.



Offset = 1 hour (default)

SCE(config)# clock summer-time DST April 16 2004 00:00 October 23 2004 23:59



To cancel the daylight savings time transitions configuration, use the following command:



From the SCE(config)# prompt, type no clock summer-time and press Enter.



To display the current daylight savings time configuration, use the following command:



From the SCE(config)# prompt, type show timezone and press Enter.

The current time zone and daylight saving time configuration is displayed.

SNTP



The Simple Network Timing Protocol (SNTP) is a simple solution to the problem of synchronizing the clocks in the various elements of the network. SNTP provides access to a time source via the network. The system clock and calendar are then set in accordance with this external source.

There are two options for the SNTP client. These functions are independent, and the system employ either one or both.



Multicast SNTP client — Listens to SNTP broadcasts and updates the system clock accordingly.



Unicast SNTP client — Sends a periodic request to a configured SNTP server, and updates the system clock according to the server response.

Note



It is recommended that an IP access control list be configured in order to prevent access from unauthorized SNTP or NTP multicast servers.

The following commands are relevant to SNTP configuration:

[no] sntp broadcast client
[no] sntp server address
no sntp server all
sntp update-interval interval in seconds
show sntp

Enabling SNTP multicast client



To enable the SNTP multicast client, use the following command:



From the SCE(config)# prompt, type sntp broadcast client, and press Enter.

The SNTP multicast is enabled, and will accept time updates from any broadcast server.

Disabling SNTP multicast client



To disable the SNTP multicast client, use the following command:



From the SCE(config)# prompt, type no sntp broadcast client, and press Enter.

The SNTP multicast client is disabled, and will not accept any broadcast time updates.

Enabling SNTP unicast client



To define the SNTP unicast server to be queried, use the following command:



From the SCE(config)# prompt, type sntp server <address>, and press Enter, where <address> is the IP address of the SNTP server.

The SNTP unicast server is defined, and SNTP client is enabled to query that server.

Example:



The following example shows how to enable an SNTP server at IP address 128.182.58.100.

SCE(config)# sntp server 128.182.58.100

Disabling SNTP unicast client



To disable the SNTP unicast client and remove all servers from the client list, use the following command:



From the SCE(config)# prompt, type no sntp server all, and press Enter.

All SNTP unicast servers are removed, preventing unicast SNTP query.



To remove one SNTP servers from the client list, use the following command:



From the SCE(config)# prompt, type no sntp server <address>, and press Enter, where <address> is the IP address of the SNTP server.

The specified SNTP unicast server is removed.

Defining the SNTP unicast update interval



To define the interval for SNTP update queries, use the following command:



From the SCE(config)# prompt, type sntp update-interval <interval>, where <interval> is the time in seconds between updates (64 through 1024), and press Enter.

The SNTP unicast client will query the server at the defined intervals.

Example:



The following example shows how to set the SNTP update interval for 100 seconds.

SCE(config)# sntp update-interval 100

Display SNTP information



To get information about SNTP servers and updates, use the following command:



From the SCE(config)# prompt, type show sntp, and press Enter.

The configuration of both the SNTP unicast client and the SNTP multicast client is displayed.

Example:

SNTP broadcast client: disabled
last update time: not available

SNTP unicast client: enabled
SNTP unicast server: 128.182.58.100
last update time: Feb 10 2002, 14:06:41
update interval: 100 seconds

Domain Name (DNS) Settings



When a name of a host is given as a parameter to a CLI command that expects a host name or an IP address, the system translates the name to an IP address according to the following:

If the name is in a dotted decimal notation (that is, in the format x.x.x.x), it is directly translated to an IP address it represents.

If the name does not contain the dot character (.), the system looks it up in the IP Host table. If the name is found on the table, it is mapped to the corresponding IP address. The IP host table can be configured using the command ip host.

If the name does not contain the dot (.) character, and the domain name function is enabled (See the ip domain-lookup command), and a default domain name is specified (See the ip domain-name command), the default domain name is appended to the given name to form a fully qualified host name. This, in turn, is used to perform a DNS query translating the name to an IP address.

Otherwise, if the domain name function is enabled, the name is considered to be fully qualified, and is used to perform a DNS query translating the name to an IP address.

The following commands are relevant to DNS settings:

ip name-server
ip domain-name
no ip domain-name
ip domain-lookup
show hosts



To enable DNS lookup, use the following command:



From the SCE(config)# prompt, type ip domain-lookup.



To disable DNS lookup, use the following command:



From the SCE(config)# prompt, type no ip domain-lookup.

Name Servers



To specify the address of one or more name servers to use for name and address resolution, use the following command:



From the SCE(config)# prompt, type ip name-server <server-address1> [<server-address2> [<server-address3>]], and press Enter.

Example:



The following example shows how to configure the two name server (DNS) IP addresses.

SCE(config)#ip name-server 10.1.1.60 10.1.1.61



To remove the name server address, use the following command:



From the SCE(config)# prompt, type no ip name-server <server-address1> [<server-address2> [<server-address3>]], and press Enter.

Example:



The following example shows how to remove the name server (DNS) IP address.

SCE(config)#no ip name-server 10.1.1.60 10.1.1.61



To clear the name server table all addresses, use the following command:



From the SCE(config)# prompt, type no ip name-server, and press Enter.

Domain Name



To define a default domain name:, use the following command



From the SCE(config)# prompt, type ip domain-name domain-name, and press Enter.

The default domain name is defined. The default domain name is used to complete unqualified host names. Do not include the initial period that separates an unqualified name from the domain name.

Example:



The following example shows how to configure the domain name.

Now, if the hostname “Cisco” is entered, the default domain name “com” is appended, to produce “Cisco.com”.

SCE(config)#ip domain-name com

Example:



The following example shows how to remove the configured domain name.

SCE(config)#no ip domain-name

Host Table



To add a hostname and address to the host table, use the following command:



From the SCE(config)# prompt, type ip host hostname ip-address, and press Enter.

Example 1:



The following example shows how to add a host to the host table.

SCE(config)#ip host PC85 10.1.1.61

Example 2:



The following example shows how to remove a hostname together with all of its IP mappings.

SCE(config)#no ip host PC85

show hosts



To display current DNS settings, use the following command:



From the SCE# prompt, type show hosts.

Example:



The following example shows how to display current DNS information.

SCE#show hosts
Default domain is Cisco.com
Name/address lookup uses domain service
Name servers are 10.1.1.60, 10.1.1.61
Host                 Address
----                 -------
PC85                 10.1.1.61
SCE#

Configuring the Management Port Physical Parameters



This interface has a transmission rate of 10 or 100 Mbps and is used for management operations and for transmitting RDRs, which are the output of traffic analysis and management operations.

The procedures for configuring this interface are explained in the following sections:



Setting the IP Address and Subnet Mask of the Management Interface.



Configuring the Speed of the Management Interface



Configuring the Duplex Operation of the Management Interface.



Specifying the Active Management Port: only if both of the following conditions are present:



Fail-over mode is disabled (no automatic switch to the backup port).



Active port = Mng Port 2 (Mng port 1 is the default and therefore does not need to be explicitly specified).

Configuring the Management Interface Speed and Duplex Parameters



This section presents sample procedures that describe how to configure the speed and the duplex of the Management Interface.

Both these parameters must be configured separately for each port.

Configuring the Duplex Operation of the Management Interface



The following options are available:



duplex — duplex operation of the currently selected management port (0/1 or 0/2):



full



half



auto (default) — auto-negotiation (do not force duplex on the link)

If the speed parameter is configured to auto, changing the duplex parameter has no effect (see Interface State Relationship to Speed and Duplex).



To configure the duplex operation of the specified management port, use the following command:



From the SCE(config if)# prompt, type duplex auto|full|half and press Enter.

Configures the duplex operation of the currently selected management interface to either auto, half duplex, or full duplex.

Example:



The following example shows how to use this command to configure a management port to half duplex mode.

SCE(config if)#duplex half

Configuring the Speed of the Management Interface



The following options are available:



speed — speed in Mbps of the currently selected management port (0/1 or 0/2):



auto (default) — auto-negotiation (do not force speed on the link)

If the duplex parameter is configured to auto, changing the speed parameter has no effect (see Interface State Relationship to Speed and Duplex).



To configure the speed of the specified management port, use the following command:



From the SCE(config if)# prompt, type speed 10|100|auto and pressEnter.

Example:



The following example shows how to use this command to configure the Management port to 100 Mbps speed.

SCE(config if)#speed 100

Monitoring the Management Interface



Use this command to display the following information for the specified management interface. Speed and duplex parameters are specific to the selected interface (port), while other parameters apply to both ports and are displayed by a command to either interface.



speed



duplex



IP address



active port



To display information relating to the management interface, use the following command:



From the SCE# prompt, type show interface Mng {01 | 0/2} ip address and press Enter.

Chapter 6. Configuring the Line Interface

Line Interfaces



The Line Interfaces (Subscriber and Network) are used to connect the SCE platform to the network. See the description of network topologies in the Topology section of the Cisco SCE 2000/SCE 1000 Installation and Configuration Guides.

The SCE 1000 2xGBE and the SCE 2000 4xGBE have Gigabit Ethernet line interfaces. You should configure autonegotiation for these interfaces.

The SCE 2000 4/8x FE has Fast Ethernet line interfaces. You should configure the speed and duplex for these interfaces.

Configuring the Gigabit Ethernet Line Interfaces

Note



The maximum packet size supported by the SCE platform is 1600 bytes



To configure GBE auto-negotiation for a specified GBE line interface, complete the following steps:



To enter the Global Configuration Mode, at the SCE# prompt, type configure, and press Enter.

The SCE(config)# prompt appears.



To enter the desired GBE port interface, type interface GigabitEthernet 0/portnumber, and press Enter, where portnumber is the number of the selected port (1-4).

The SCE(config if)# prompt appears.



Type auto-negotiate and press Enter.

The SCE(config if)# prompt appears.



To return to Global Configuration Mode, type exit and pressEnter.

The SCE(config)# prompt appears.

Repeat this procedure to configure auto-negotiation for the other GBE port interfaces as needed.

Configuring the Fast Ethernet Line Interfaces



Note that both sides of the FE link (both the SCE 2000 4/8xFE and the remote device) should have the same configuration. Use either of the following two configuration options:



Autonegotiation = ON



Autonegotiation = ON, speed = 100



To configure the speed and duplex for a specified FE line interface, complete the following steps:



To enter the desired FE interface, type interface FastEthernet 0/portnumber, and press Enter, where portnumber is the number of the selected port (1-4).

The SCE(config if)# prompt appears.



Type duplex auto|full|half and press Enter.



Type speed 100|auto and pressEnter.



To return to Global Configuration Mode, type exit and pressEnter.

The SCE(config)# prompt appears.

Repeat this procedure to configure auto-negotiation for the other FE port interfaces as needed.

Configuring Tunneling Protocols



Tunneling technology is used across various telecommunications segments in order to solve a wide variety of networking problems. The SCE platform is designed to recognize and process various tunneling protocols in a number of ways. The SCE platform is able to either ignore the tunneling protocols ("skip" the header) or treat the tunneling information as subscriber information ("classify"). A special case of classification by tunneling information is MPLS/VPN with private IP support (see MPLS/VPN Support).

The following table shows the support for the various tunneling protocols (the default behavior for each protocol is in bold):



Table 6.1. Tunneling Protocol Summary

Protocol	Supported handling	Mode name
L2TP	Ignore tunnel	IP-tunnel L2TP skip
L2TP	Don't ignore tunnel – classify by external IP	No IP-Tunnel
VLAN	Ignore tunnel	VLAN symmetric skip
	Ignore tunnel – asymmetric	VLAN a-symmetric skip
	VLAN tag as subscriber	VLAN symmetric classify
MPLS	Ignore tunnel (inject unlabeled)	MPLS Traffic-engineering skip
	Ignore tunneled (inject labeled)	MPLS VPN skip
	MPLS L3 VPN as subscriber	MPLS VPN auto-learn







When the tunneling information is ignored, the subscriber identification is the subscriber IP of the IP packet carried inside the tunnel.

L2TP is an IP-based tunneling protocol, therefore the system must be specifically configured to recognize the L2TP flows, given the UDP port used for L2TP. The SCE platform can then skip the external IP, UDP, and L2TP headers, reaching the internal IP, which is the actual subscriber traffic. If L2TP is not configured, the system treats the external IP header as the subscriber traffic, thus all the flows in the tunnel are seen as a single flow.

A single VLAN tag is supported per packet (no QinQ support). MPLS labels are supported up to a maximum of 15 labels per packet.

Subscriber classification by VLAN tag is supported only in symmetric VLAN environments – i.e. where the upstream and downstream tags are identical.

Note



All subscribers with tunnel mappings must be cleared in order to change the tunneling mode. If the connection with the SM is down, use the no subscriber all with-tunnel-mappings CLI command (see Removing Subscribers with Tunnel Mappings).

Selecting the Tunneling Mode



Use these commands to configure tunneling:

ip tunnel
vlan
mpls 
L2TP identify-by

Configuring IP Tunnels



By default, IP tunnel recognition is disabled. Use this command to configure recognition of L2TP tunnels and skipping into the internal IP packet.

An IP tunnel is mutually exclusive with tunnel-based classification.



To configure IP tunnels, use the following command:



From the SCE(config if)# prompt, type:

ip tunnel L2TP skip and press Enter.



To disable identification of IP tunnels, use the following command:



From the SCE(config if)# prompt, type:

no ip tunnel and press Enter.

Configuring the VLAN Environment



Use this command to configure the VLAN environment. There are three options:



symmetric classify



symmetric skip (default)



a-symmetric skip

Symmetric environment refers to an environment in which the same VLAN tags are used for carrying a transaction in the upstream and downstream directions.

Setting the mode to classify means that subscriber and flow classification will use the VLAN tag. Using VLAN classification is mutually exclusive with other tunnel-based classification or IP tunnels.

An a-symmetric environment is an environment in which the VLAN tags might not be the same in the upstream and downstream directions.

The SCE platform is configured by default to work in symmetric environments. A specific command should be used in order to allow correct operation of the SCE platform in asymmetric environments and instruct it to take into consideration that the upstream and downstream of each flow has potentially different VLAN tags.

Note that using The a-symmetric skip value incurs a performance penalty.



To configure the VLAN environment, use the following command:



From the SCE(config if)# prompt, type:

vlan [symmetric {classify|skip}]|[a-symmetric skip]and press Enter.

Example:



The following example selects symmetric skip VLAN tunnel environment.

SCE(config if)#vlan symmetric skip

Configuring the MPLS Environment



Use this command to set the MPLS environment. Use the VPN keyword when the labels are mandatory in the traffic, otherwise use Traffic-Engineering (default).

Note that using the VPN value incurs a performance penalty.



From the SCE(config if)# prompt, type:

mpls [vpn|Traffic-Engineering] skip and press Enter.

Example:



The following example selects the VPN MPLS tunnel environment.

SCE(config if)#mpls vpn skip

Configuring the L2TP Environment



Use this command to set the port number that the LNS and LAC use for L2TP tunnels. The default port number is 1701.



From the SCE(config if)# prompt, type:

L2TP identify-by port-number <number> and press Enter.

Note that if external fragmentation exists in the L2TP environment, it is required to configure a Traffic Rule (see Configuring Traffic Rules and Counters) that bypasses all IP traffic targeted to either the LNS or LAC IP address. This will make sure that any packets not having the L2TP port indication (i.e. non-first fragments) will not require handling by the traffic processors.

Displaying Tunneling Configuration



You can display the tunnel configuration.



To display the tunneling configuration, use the following command:



From the SCE# prompt, type:

show interface lineCard 0 [MPLS|VLAN|L2TP|IP-tunnel] and press Enter.

Configuring VLAN Translation



Some topologies require the SCE platform to be able to translate between different VLAN tags.

The following drawing illustrates an example of such a system, in which one router acts as a dispatcher, forwarding traffic and performing load balancing between two SCE 2000 platforms.



Figure 6.1. VLAN Translation





In this example, traffic enters the router via the access ports; it is forwarded to an EtherChannel, which is configured as a trunk, and enters the SCE 2000 platforms.

As can be seen from this drawing, the subscriber side VLAN tags must be different from those on the network side, or the router will simply forward the traffic to the opposite port. This can be supported very simply by having the SCE platform replace the VLAN tags according to a preset configuration.

VLAN Translation Features and Limitations

Features



Configuration of an increment or decrement constant.



Configuration of the constant is global for the line card.



The configured operation (either increment or decrement) is applied to the network side.



The subscriber side automatically performs the opposite operation. That is, if the VLAN is incremented by X on the network side, it is decremented by X on the subscriber side.



VLAN tagged packets are changed (incremented or decremented) before transmission.



Non-tagged packet are not changed.



This feature allows seamless processing with non-VLAN traffic.

Limitations



LIC Bypass not supported – Translation is done in the transmission. Therefore, in LIC bypass, where there is no transmission, there is also no translation.

This means that in general, installations using the VLAN translation feature should rely on cutoff on failure and at upgrade (use redundant SCE platform).



STP hazard – VLAN translation may interfere with Spanning Tree Protocol. This should be taken in consideration when deploying the solution.



The maximum offset that can be configured is 2047. Note that there is no protection for wraparound.

Setting the VLAN Translation Constant



Use this command to define the VLAN translation constant. Make sure that the same VLAN translation constant is configured for all SCE platforms in the system.

The following option is available:



value — Integer value by which the VLAN is to incremented or decremented.

The configured translation is applied to the network port side. The reverse operation is performed at the subscriber side.

For example, if "increment 5" is defined, at the network port the VLAN is incremented by 5, and at the subscriber port the VLAN is decremented by 5.

In this case, the network side VLAN tags might be 105, 205, 305, and the subscriber side the VLAN tags would then be 100, 200, 300.

Default = 0

Maximum = 2047 (Note that there is no protection for wraparound of the VLAN value.)



To define the VLAN translation constant, use the following command:



From the SCE(config if)# prompt, type vlan translation increment|decrement value value and press Enter.

Example:



The following example sets the translation constant to 10, decremented at the network side.

SCE(config if)#vlan translation decrement value 10

Disabling VLAN Translation



To disable vlan translation configuration (translation constant = 0), use this command:



From the SCE# prompt, type no vlan translation and press Enter.

Monitoring VLAN Translation



To display the vlan translation configuration per port, use this command:



From the SCE# prompt, type show interface LineCard 0 vlan translation and press Enter.

Configuring Traffic Rules and Counters



Traffic rules and counters may be configured by the user. This functionality enables the user to define specific operations on the traffic flowing through the SCE Platform, such as blocking or ignoring certain flows or counting certain packets. The configuration of traffic rules and counters is independent of the application loaded by the SCE platform, and thus is preserved when the application being run by the SCE platform is changed.

Possible uses for traffic rules and counters include:



Enabling the user to count packets according to various criteria. Since the traffic counters are readable via the SCE SNMP MIB, these might be used to monitor up to 32 types of packets, according to the requirements of the installation.



Ignoring certain types of flows. When a traffic rules specifies an “ignore” action, packets matching the rule criteria will not open a new flow, but will pass through the SCE platform without being processed. This is useful when a particular type of traffic should be ignored by the SCE platform.

Possible examples include ignoring traffic from a certain IP range known to require no service, or traffic from a certain protocol.



Blocking certain types of flows. When a traffic rules specifies a “block” action, packets matching the rule criteria (and not belonging to an existing flow) will be dropped and not passed to the other interface. This is useful when a particular type of traffic should be blocked by the SCE platform.

Possible examples include performing ingress source address filtering (dropping packets originating from a subscriber port whose IP address does not belong to any defined subscriber-side subnet), or blocking specific ports.

It should be noted that using traffic rules and counters does not affect performance. It is possible to define the maximum number of both traffic rules and counters without causing any degradation in the SCE platform performance.

Traffic Rules



A traffic rule specifies that a defined action should be taken on packets processed by the SCE Platform that meet certain criteria. The maximum number of rules is 128, which includes not only traffic rules configured via the SCE platform CLI, but also any additional rules configured by external management systems, such as SCA BB. Each rule is given a name when it is defined, which is then used when referring to the rule.

Packets are selected according to user-defined criteria, which may be any combination of the following:



IP address — A single address or a subnet range can be specified for each of the line ports (Subscriber / Network).



Protocol — TCP/UCP/ICMP/IGRP/EIGRP/IS-IS/OSPF/Other



TCP/UDP Ports — A single port or a port range can be specified for each of the line ports (Subscriber / Network). Valid for the TCP/UDP protocols only.



TCP flags (TCP only).



Direction (Upstream/Downstream).

The possible actions are:



Count the packet by a specific traffic counter



Block the packet (do not pass it to the other side)



Ignore the packet (do not provide service for this packet — No bandwidth metering, transaction reporting etc. is done)



Quick-forward the packet with service — forward delay-sensitive packets through the fast path while maintaining serviceability for these packets



Quick-forward the packet with no service — forward delay-sensitive packets through the fast path with no service provided for these packets

Block and Ignore actions affect only packets that are not part of an existing flow.

Note that Block and Ignore are mutually exclusive. However, blocked or ignored packets can also be counted.

It is possible for a single packet to match more that one rule (The simplest way to cause this is to configure two identical rules with different names). When this happens, the system operates as follows:



Any counter counts a specific packet only once. This means that:



If two rules specify that the packet should be counted by the same counter, it is counted only once.



If two rules specify that the packet should be counted by different counters, it is counted twice, once by each counter.



Block takes precedence over Ignore — If one rule specifies Block, and another rule specifies Ignore, the packet is blocked.

Traffic counters



Traffic counters count the traffic as specified by the traffic rules. The maximum number of counters is 32. Each counter is given a name when it is defined, which is then used when referring to the counter.

A traffic counter can be configured in one of two ways:



Count packets — the counter is incremented by 1 for each packet it counts.



Count bytes — the counter is incremented by the number of bytes in the packet for each packet it counts.

Configuring Traffic Counters



A traffic counter must be created before it can be referenced in a traffic rule. Use the following commands to create and delete traffic counters.



To create a traffic counter, use the following command:



From the SCE(config if)# prompt, type traffic-counter name <name> (count-bytes|count-packets)



To delete a traffic counter, use the following command:



From the SCE(config if)# prompt, type no traffic-counter name <name>

Note that a traffic counter cannot be deleted if it is used by any existing traffic rule.



To delete all existing traffic counters, use the following command:



From the SCE(config if)# prompt, type no traffic-counter all

Configuring Traffic Rules



Use the following commands to create and delete traffic rules.



To create a traffic rule, use the following command:



From the SCE(config if)# prompt, type traffic-rule name <name> IP-addresses (all|(subscriber-side <IP specification> network-side <IP specification>)) protocol <protocol> [tunnel-id tunnel-id specification] direction <direction> traffic-counter <traffic-counter> [action <action>]

Where the command options are defined as follows:

IP specification:

all|([all-but] (<ip-address>|<ip-range>))



<ip-address> is a single IP address in dotted-decimal notation, such as 10.1.2.3



<ip-range> is an IP subnet range, in the dotted-decimal notation followed by the number of significant bits, such as 10.1.2.0/24.



Use the all-but keyword to exclude the specified IP address or range of IP addresses

protocol:

Any one of the following protocols:

TCP/UCP/ICMP/IGRP/EIGRP/IS-IS/OSPF/Other

tunnel id specification:

all|([all-but] tunnel id)



tunnel id is an 8-bit Hex value range, in the format '(HEX)Tunnel-id' or '(HEX)MinTunnelId:(HEX)MaxTunnelId', which reflects the lower eight bits of the VLAN tag.



Tunnel ID based rules can only be used in "VLAN symmetric classify" mode, and only when tunnel id mode is enabled. Use the traffic-rule tunnel-id-mode command.

Note that the VLAN tag itself is a 12-bit value, and therefore aliasing of the lower 8 bits can occur, depending on the VLAN tags used

direction:

Any of the following:

upstream/downstream/both

traffic-counter:

Either of the following:



name <name of an existing traffic counter> — Packets meeting the criteria of the rule are to be counted in the specified counter. If a counter name is defined, the “count” action is also defined implicitly. The keyword name must appear as well as the actual name of the counter.



none — If none is specified, then an action must be explicitly defined via the action option.

action: (not required if the action is count only)

One of the following:



block — Block the specified traffic



ignore — Bypass the specified traffic; traffic receives no service



quick-forwarding — Forward delay-sensitive packets through the fast path while maintaining serviceability for these packets



quick-forwarding-ignore — Forward delay-sensitive packets through the fast path with no service provided for these packets

Example 1



This example creates the following traffic rule:

Name = rule1

IP addresses: subscriber side = all IP addresses, network side = 10.10.10.10 only

Protocol = other

Direction = both

Traffic counter = counter1

The only action performed will be counting

SCE (config if)# traffic-rule rule1 IP-addresses subscriber-side all network-side 10.10.10.10 protocol other direction both traffic-counter name counter1

Example 2



This example creates the following traffic rule:

Name = rule2

IP addresses: subscriber  side = all IP addresses, network side = all IP addresses EXCEPT the subnet 10.10.10.0/24

Protocol = TCP

Tunnel id = all

Direction = downstream

Traffic counter = counter2

Action = Block

The actions performed will be counting and blocking

SCE (config if)#traffic-rule tunnel-id-mode (enables tunnel id mode)

SCE (config if)# traffic-rule rule2 IP-addresses subscriber-side all network-side all-but 10.10.10.0/24 protocol tcp tunnel-id all direction downstream traffic-counter name counter2 action block

Example 3



This example creates the following traffic rule:

Name = rule3

IP addresses: all

Protocol = IS-IS

Direction = upstream

Traffic counter = none

Action = ignore (required since traffic-counter = none)

The only action performed will be Ignore.

SCE (config if)# traffic-rule rule3 IP-addresses all protocol IS-IS direction upstream traffic-counter none action ignore



To delete a traffic rule, use the following command:



From the SCE(config if)# prompt, type no traffic-rule name <name>

Note that a traffic counter cannot be deleted if it is used by any existing traffic rule.



To delete all existing traffic rules, use the following command:



From the SCE(config if)# prompt, type no traffic-rule all

Managing Traffic Rules and Counters



Use these commands to display existing traffic rule configuration, as well as traffic counter configuration (packets/bytes and the name of the rule using the counter) and traffic counter value. You can also reset a specific counter or all counters.



To view a specified traffic rule, use the following command:



From the SCE# prompt, type show interface linecard 0 traffic-rule name <rule-name>



To view all existing traffic rules, use the following command:



From the <product># prompt, type show interface linecard 0 traffic-rule all



To view a specified traffic counter, use the following command:



From the SCE# prompt, type show interface linecard 0 traffic-counter name <counter-name>

Example



The following example displays information for the traffic counter “cnt”.

SCE# show interface linecard 0 traffic-counter name cnt
Counter 'cnt' value: 0 packets. Rules using it: None.



To view all existing traffic counters, use the following command:



From the <product># prompt, type show interface linecard 0 traffic-counter all

Example



The following example displays information for all existing traffic counters.

SCE#show interface linecard 0 traffic-counter all

Counter 'cnt' value: 0 packets. Rules using it: None.
1 counters listed out of 32 available.



To reset a specified traffic counter, use the following command:



From the SCE# prompt, type clear interface linecard 0 traffic-counter name <counter-name>



To reset all existing traffic counters, use the following command:



From the SCE# prompt, type clear interface linecard 0 traffic-counter all

Configuring TOS Marking



The SCE platform TOS marking feature enables marking the TOS field in the IP header of each packet according to two applicative attributes of the packet: its Class (class of service) and its Color (reflects the packet’s level of compliance to its relevant bandwidth limitations, where applicable). The actual TOS value set in the IP header is determined according to the configurable TOS table, based on the Class and Color. The default values in the TOS table are based on the Diffserv standard.

Note



The first few TCP packets (connection establishment) are associated and marked with a default AF4 class that is mapped to the AF-4 queue and are marked accordingly. This occurs because the SCE platform transmits the first few packets before classifying the flow and identifying the application or service.

The following commands are relevant to TOS marking:

no tos-marking diffserv
tos-marking mode
tos-marking set-table-entry class
tos-marking reset-table
show interface LineCard tos-marking mode
show interface LineCard tos-marking table

Enabling and Disabling TOS Marking



To enable TOS marking, use the following command:



From the SCE platform(config if)# prompt, type tos-marking mode diffserv and press Enter.



To disable TOS marking, use the following command:



From the SCE(config if)# prompt, type no tos-marking diffserv and press Enter.

Modifying the TOS Table



To modify the TOS table, use the following command:



From the SCE(config if)# prompt, type tos-marking set-table-entry classclass color color value value andpress Enter.

class is the applicative class of the packet (BE, AF1, AF2, AF3, AF4, EF),, color is the applicative color (green, red or any) and value is the value to be assigned to the packet (value set to the IP TOS field). The value parameter must be in hexadecimal format in the range 0x0 to 0x3f.

Example:



The following example sets a TOS marking table entry.

SCE (config if)#tos-marking set-table-entry class AF3 color green value 0x24

Counting Dropped Packets



By default, the SCE platform hardware drops red packets (packets that are marked to be dropped due to BW control criteria). However, this presents a problem for the user who needs to know the number of dropped packets per service. In order to be able to count dropped packets per service, the traffic processor must see all dropped packets for all flows. However, if the hardware is dropping red packets, the traffic processor will not be able to count all dropped packets and the user will not get proper values on the relevant MIB counters

The user can disable the drop-red-packets-by-hardware mode. This allows the application to access existing per-flow counters. The application can then retrieve the number of dropped packets for every flow and provide the user with better visibility into the exact number of dropped packets and their distribution.

Note that counting all dropped packets has a considerable effect on system performance, and therefore, by default, the drop-red-packets-by-hardware mode is enabled.

Disabling the Hardware Packet Drop



Use this command to disable the drop-red-packets-by-hardware mode, enabling the software to count all dropped packets.

By default hardware packet drop is enabled.

Note



Disabling this feature may have both delay and performance implications.



To disable hardware packet drop, use the following command:



From the SCE(config if)# prompt, type no accelerate-packet-drops and press Enter.



To enable hardware packet drop, use the following command:



From the SCE(config if)# prompt, type accelerate-packet-drops and press Enter.

Chapter 7. Configuring the Connection

Editing the Connection Mode



The connection mode command allows you to configure the topology of the system in one command. The connection mode is determined by the physical installation of the SCE platform.

There are four topology-related parameters included in the connection mode command:



Connection mode — Can be any one of the following, depending on the physical installation of the SCE platform:



Inline — single SCE platform inline



Receive-only — single SCE platform receive-only



Inline-cascade — two cascaded SCE platforms inline



Receive-only-cascade — two cascaded SCE platforms receive-only

Default — inline



Physically-connected-links — In cascaded topologies, defines which link is connected to this SCE platform. Possible values are ‘link-0’ and ‘link-1’.

Not applicable to single SCE platform topologies.



Priority — This parameter defines which is the primary SCE platform. It is applicable only in a two SCE platform topology. Possible values are ‘primary’ and ‘secondary’

Not applicable to single SCE platform topologies.



On-failure — This parameter determines whether the system cuts the traffic or bypasses it when the SCE platform either has failed or is booting.

Default — bypass

Not applicable to receive-only topologies.

Note



Do not change the connection mode unless the physical installation has been changed.



To define the system topology, use the following command:



From the SCE (config if)# prompt, type connection-mode inline|receive-only|inline-cascade|receive-only-cascade physically-connected-links [link 0|link 1] priority [primary|secondary] on-failure [bypass|cutoff]  and press Enter.

Example 1:



The following example defines the primary device in a two-SCE platform redundant, inline topology. Link 0 is connected to this device, and the link mode on failure is bypass

SCE (config if)# connection-mode inline-cascade physically-connected-links link-0  priority primary on-failure bypass

Example 2:



The following example defines a single-SCE platform, dual link, receive-only topology. Neither link mode on failure, nor physically-connected-links, nor priority is applicable.

SCE (config if)# connection-mode receive-only

Monitoring the Connection Mode



To display the current configuration of the SCE platform link connection, use the following command:



From the SCE> prompt, type show interface linecard 0 connection-mode.

Example:



The following example shows how to display the current configuration of the connection mode.

SCE>show interface LineCard 0 connection-mode
Connection mode is inline
slot failure mode is bypass
Redundancy status is standalone
SCE>

Link Mode



The SCE platform has an internal hardware card used to maintain the links even when the SCE platform fails. This hardware card has four possible modes of operation:



bypass



forwarding



cutoff



sniffing

Normally, the link mode is selected by the SCE platform software according to the configured connection-mode. However, the link-mode command can be used to enforce a specific desired mode. This may be useful when debugging the network, or in cases where we would like the SCE platform just to forward the traffic. (Note that this is only relevant to inline topologies even though the configuration is available also when in receive-only mode.)

The following link mode options are available:



Forwarding — forwards traffic on the specified link to the SCE platform for processing.



Bypass — stops all forwarding of traffic on the specified link to the SCE platform. Traffic still flows on the link, but is not processed in any way by the SCE platform.

This does not affect the redundancy states.



Sniffing — allows the SCE platform to forward traffic on the specified link through the bypass mechanism while still analyzing the traffic passively.

Sniffing is permitted to be configured for all links, only (use the all-links option).



Cutoff — completely cuts off flow of traffic through the specified link.

Note the following recommendations and restrictions:



Since the SCE 1000 platform has only one link, the link is not specified.



Since the SCE 2000 platforms have more than one link, it is required to specify the link. The link designations are different for the GBE and FE platforms, as follows:



SCE 2000 4xGBE — GBE1-GBE2/GBE3-GBE4



SCE 2000 4/8xFE — LINK1/LINK2



Use the 'all-links' option to configure the link mode for all links (SCE 2000 platforms only).



It is recommended that both links be configured together. Use the all-links option.



Link mode is relevant only to inline topologies.



It is recommended that in cascaded topologies, both SCE platforms be configured for the same link mode, otherwise the service will be unpredictable.



Sniffing can only be configured for all links, therefore, to configure sniffing, the all-links option is required, not just recommended.



The default link mode is forwarding. When other link modes are selected, active service control is not available and any service control configuration will not be applicable.



To set the link mode, use the following command:



From the SCE (config if)# prompt, type link-mode [<link>|all-links] [forwarding|bypass|sniffing|cutoff] and press Enter.

Forced Failure



Use the following commands to force a virtual failure condition, and to exit from the failure condition when performing an application upgrade. (See Application Upgrade.)



To force a virtual failure condition, use the following command:



From the SCE(config if)# prompt, type force failure-condition and press Enter.



To exit the virtual failure condition, use the following command:



From the SCE(config if)# prompt, type no force failure-condition and press Enter.

Failure Recovery Mode



The failure-recovery operation-mode command defines the behavior of the system after boot resulting from failure. The system may return to operational mode, or remain not operational.

The default value is operational.



To edit the failure recovery operational mode, use the following command:



From the SCE(config)# prompt, type failure-recovery operation-mode operational|non-operational and press Enter.

Enter either the value operational or non-operational.

Example 1:



The following example sets the system to boot as non-operational after a failure

SCE(config)#failure-recovery operation-mode non-operational
SCE(config)#

Example 2:



The following example sets the system to the default failure recovery mode.

SCE(config)# default failure-recovery operation-mode
SCE(config)#

SCE Platform/SM Connection



The user can configure the behavior of the SCE platform in case of failure of the Subscriber Manager (SM):



If SM functionality is critical to the operation of the system — configure the desired behavior of the SCE platform in the event of any loss of connection with the SM (may be due either to failure of the SM or failure of the connection itself).



If SM functionality is not critical to the operation of the system — no action needs to be configured.

The following options are available :



force-failure ¾&#61472;Force failure of SCE platform. The SCE platform then acts according to the behavior configured for the failure state.



remove-mappings ¾&#61472;Remove all current subscriber mappings.



shut ¾&#61472;The SCE platform shuts down and quits providing service.



none (default) ¾&#61472;Take no action.



To configure the behavior of the SCE platform in case of failure of the SM, use the following command:



From the SCE(config if)# prompt, type subscriber sm-connection-failure action [force-failure|none|remove-mappings|shut] and press Enter.

You can also configure the timeout interval; the length of time that the SM-SCE platform connection is disrupted before a failed connection is recognized and the configured behavior is applied.



To configure the SM-SCE platform connection timeout, use the following command:



From the SCE(config if)# prompt, type subscriber sm-connection-failure action timeout interval-in-seconds and press Enter.

Enabling and Disabling Link Failure Reflection



In some topologies, link failure on one port must be reflected to the related port in order to allow the higher layer redundancy protocol in the network to detect the failure and function correctly. The link failure-reflection command determines the behavior of the system when there is a link problem.

The link failure-reflection command enables reflection of a link failure. Use the [no] form of this command to disable failure reflection on the link.

The default value is disabled.



To enable reflection of link failure, use the following command:



From the SCE(config if)# prompt, type link failure-reflection and press Enter.



To disable reflection of link failure, use the following command:



From the SCE(config if)# prompt, type no link failure-reflection and press Enter.

Enabling and Disabling Link Failure Reflection on All Ports



The Link reflection on all ports feature extends the link failure reflection feature. It allows the user to determine whether all ports should be taken down if a single port link fails.

In certain topologies, when a failure state occurs on one link, the link state must be reflected to all ports in order to signal any element using this SCE platform that the device is in a failure state, and therefore cannot be used.

Note



The Link reflection on all ports feature cannot be used in a cascade mode, because in this mode one of the links is used to provide redundancy.

In link reflection on all ports mode, all ports of the SCE platform are forced down and the link state of the first port is reflected on all the ports.

When recovering from the failure state, the forced down ports (the other link) are brought up only after the first failed port (link) has recovered. In addition, the reflection algorithm will not try to reflect failure for this link again for the next 15 seconds, to avoid link stability problems on auto-negotiation.

The on-all-ports keyword enables reflection of a link failure to all ports. Use the [no] form of this command to disable failure reflection to all ports (the on-all-ports keyword is not used in the [no] form of the command).

The default value is disabled.



To enable reflection of link failure to all ports, use the following command:



From the SCE(config if)# prompt, type link failure-reflection on-all-ports  and press Enter.

Failure reflection to all ports is enabled.



To disable reflection of link failure, use the following command:



From the SCE(config if)# prompt, type no link failure-reflection and press Enter.

Link Failure Reflection in Linecard-Aware Mode (SCE 2000 only)



The linecard-aware-mode option is an additional extension of the link failure reflection feature for use in MGSCP topologies. Use this option when the subscriber-side interface and the corresponding network-side interface of the same link of the SCE 2000 platform are connected to the same linecard in the router.

This mode reflects a failure of one port to the other three ports of the SCE 2000 differently, depending on different failure conditions, as follows:



One interface of the SCE 2000 is down: Link failure is reflected to the all other SCE platform ports.



Two reciprocal ports of the SCE 2000 are down simultaneously, indicating a possible problem in the linecard of the router to which the SCE platform is connected: In this case the failure is not reflected to any of the other interfaces. This allows the second link in the SCE platform to continue functioning without interruption.

Use the [no] form of this command with the linecard-aware-mode keyword to disable the linecard aware mode without disabling link failure reflection itself.



To enable linecard aware mode, use the following command:



From the SCE(config if)# prompt, type link failure-reflection on-all-ports linecard-aware-mode and press Enter.



To disable the linecard-aware-mode, use the following command:



From the SCE(config if)# prompt, type no link failure-reflection linecard-aware-mode and press Enter.

Note that this command does not disable link failure reflection on all ports.

Chapter 8. Configuring the RDR Formatter

The RDR Formatter



The RDR formatter is used to gather the streams of events passed from the application, format the data into Raw Data Records (RDRs), and send these RDRs to the appropriate destination(s).

There can be a maximum of eight destinations for the RDRs. The system decides which destination to send the RDRs to on the basis of three factors:



Categories — RDRs may be divided into four categories, with each category being assigned to a maximum of three of the defined destinations. A destination may be assigned to more than one category.



Priority — The priority value assigned to the destination for a specific category



Forwarding mode — the pattern in which the RDR traffic is divided between the various destinations

RDR Formatter Destinations



The SCE platform can be configured with a maximum of eight RDR destinations, three destinations per category. Each destination is defined by its IP address and TCP port number, and is assigned a priority for each category to which it is assigned.

The following figure illustrates the simplest RDR formatter topology, with only one category and one destination.



Figure 8.1. Simple RDR Formatter Topology





The following figure illustrates a complex topology using both categories and four destinations. Each category can send RDRs to three of the four destinations.



Figure 8.2. RDR Formatter Topology with Multiple Destinations

RDR Formatter Topology with Multiple Destinations

Priority



The priority value is used to indicate whether the destination should be a destination for a given category. A high priority indicates that RDRs from a category should be sent to a particular destination. A low priority indicates that RDRs from a category should not be sent to a particular destination.

Priority is related to the redundant forwarding mode, in that it indicates which is the primary active connection. Priority values have no effect in multicast forwarding mode.

Each destination is assigned a priority value for each category. The first destination that is configured is automatically assigned a priority of 100 (highest priority) for all categories, unless explicitly defined otherwise.

Following are some important points to keep in mind regarding priority values:



Two destinations may not have the same priority for one category. The priority values for destinations within a category must be unique in order to have any meaning.



If only one priority value is assigned to the destination, that priority is automatically assigned to all categories for that destination.



If only one category is assigned a priority value for a destination, no RDRs from the other categories will be sent to the specified destination.



Assign a high priority if RDRs from the specified category should be sent to this destination. Assign a low priority if RDRs from the specified category should less likely to be sent to this destination.



Redundant forwarding mode — Assign a high priority to the primary destination for the system/category. Assign a lower priority to the secondary destination for the system/category.

Forwarding Modes



When more than one RDR destination is defined for a category, the system must decide which of these destinations is to receive the RDRs. This is determined by the forwarding mode. There are two forwarding modes:



Redundancy — All RDRs are sent only to the primary (active) connection. If the primary connection fails, the RDRs will be sent to the connected destination with the next highest priority.



Multicast — All RDRs are sent to all destinations. This feature may negatively affect performance in an installation with a high rate of RDRs.

Configuring the RDR Formatter



The following commands are relevant to the RDR-formatter:

RDR-formatter forwarding-mode
service RDR-formatter
no service RDR-formatter
RDR-formatter destinations:



RDR-formatter destination



no RDR-formatter destination



no RDR-formatter destination all

RDR-formatter categories:



RDR-formatter category-number



no RDR-formatter category-number

Note



Note the following configuration restrictions:

•  The protocol version must be RDRv1 (default value)
•  The simple-load-balancing forwarding mode is not currently supported
•  The size of the history buffer must be zero bytes (the default value). Other values may cause duplication of RDRs.
•  The connection timeout parameter is not currently supported.



To configure the RDR Formatter forwarding mode, use the following command:



From the SCE(config)# prompt, type RDR-Formatter forwarding-mode <redundancy>|<multicast>, and press Enter.

The specified RDR Formatter forwarding mode is defined.

Example:



The following example shows how to set the RDR Formatter forwarding-mode to multicast

SCE(config)# RDR-Formatter forwarding-mode multicast

Configuring the RDR Formatter Destinations



In order for the RDRs from the SCE platform to arrive at the correct location, the IP address of the destination and its TCP port number must be configured.

A priority value must be assigned. Priority is important in the redundancy forwarding mode, but not crucial in simple-load-balancing mode or multicast mode. Remember that in load-balancing and multicast modes, the existence of any priority value causes the destination to receive RDRs.

The relationship between priorities and categories is addressed in the next section.



To configure an RDR Formatter destination (all categories), use the following command:



From the SCE(config)# prompt, type RDR-Formatter destination <IP address> port <port-number> [priority <priority(1-100)>], and press Enter.

The RDR Formatter destination is defined. When no category is specified, as in the above example, the specified priority is assigned to all categories.

Example:



The following example shows how to configure two RDR Formatter destinations in a system without using the categories.

The first destination will automatically be assigned a priority of 100, and therefore the priority does not need to be explicitly defined. For the second destination, the priority must be explicitly defined.

The same priority will automatically be assigned to both categories for each destination, but since the categories will be ignored, this is irrelevant.

SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 
SCE(config)# RDR-Formatter destination 10.1.1.206 port 33000 priority 80

Configuring the RDR Formatter Categories



There are two steps in defining the RDR formatter destination categories:

Define the category names (optional).

Assign the destinations to both categories.

Configuring the destinations with the proper priorities for each category, as well as configuring all the other RDR formatter parameters, may be approached in several different ways, and may take some planning. Refer to the examples below for illustrations of some of the issues involved in configuring categories.



To configure an RDR Formatter category name, use the following command:



From the SCE(config)# prompt, type RDR-Formatter category-number 1-4 name <category-name>, and press Enter.

The name for the specified category number is defined. This category name can then be used in any RDR-formatter command instead of the category number.



To configure a RDR Formatter destination and assign it to a category, use the following command:



From the SCE(config)# prompt, type RDR-Formatter destination <IP address> port <port-number> category [name <category-name> |number [1-4]] [priority <priority(1-100)>] [category [name <category-name> |number [1-4]] [priority <priority(1-100)>]], and press Enter.

The RDR Formatter destination is defined. A different priority may be assigned to each category. (This can be done in one command for a maximum of two categories.) If RDRs from the specified category should be sent to this destination, the priority for the category should be high. If the RDRs from the specified category should not be sent to this destination, the priority should be low.

Note that within each category the priorities must be unique for each destination.

Example 1:



The following example defines a name for one category, and then configures two RDR Formatter destinations, assigning each to a different category (see diagram).

The RDRs of category 1 are to go to the first destination, so a high priority was assigned to that category in the first destination, and no priority in the second.

Since all RDRs in category 2 (prepaid) are to go to the second destination, the priority assigned to category 2 is assigned only to the second destination and not to the first.



Note that if there is a loss of connection to either destination, transmission of RDRs of the relevant category is interrupted until the connection is re-established. There is no redundant connection defined for either category.

SCE(config)# RDR-Formatter category-number 2 name prepaid
SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 category number 1 priority 90
SCE(config)# RDR-Formatter destination 10.1.1.206 port 33000 category name prepaid priority 80

Example 2:



This example is similar to the above, but a low priority is assigned to the second category for each destination, rather than no priority. This allows each destination to function as a backup for the other in case of a problem with one of the connections (redundancy forwarding mode).

SCE(config)# RDR-Formatter category-number 2 name prepaid
SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 category name prepaid priority 90 category number 1 priority 25
SCE(config)# RDR-Formatter destination 10.1.1.206 port 33000 category number 1 priority 80 category name prepaid priority 20

Example 3:



This example demonstrates two methods for assigning one category to the first destination only, while the other category uses the second destination as the primary destination, and the first destination as a secondary destination.

SCE(config)# RDR-Formatter category-number 2 name prepaid
SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 category name prepaid priority 90 category number 1 priority 10
SCE(config)# RDR-Formatter destination 10.1.1.206 port 33000 category number 1 priority 95

In the following example, all priority values seem quite high. However, it is the relative values of priorities for a category that determine which destination is the primary destination.

SCE(config)# RDR-Formatter category-number 2 name prepaid
SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 priority 90
SCE(config)# RDR-Formatter destination 10.1.1.206 port 33000 priority 95
SCE(config)# no RDR-Formatter destination 10.1.1.206 port 33000 category name prepaid

Example 4:



Finally, the following illustrates a more complex configuration with one category (prepaid) assigned to one destination and the other (billing) being sent to both destinations, in multi-cast mode.



The forwarding mode is defined for the entire RDR formatter, not just one category. Since the category “prepaid” goes to only one destination, the forwarding mode is irrelevant. It is relevant, however to the “billing” category, since it goes to two different destinations.

SCE(config)# RDR-Formatter forwarding-mode multi-cast
SCE(config)# RDR-Formatter category-number 1 name billing
SCE(config)# RDR-Formatter category-number 2 name prepaid
SCE(config)# RDR-Formatter destination 10.1.1.205 port 33000 priority 40
SCE(config)# no RDR-Formatter destination 10.1.1.205 port 33000 category name prepaid
SCE(config)# RDR-Formatter destination 10.10.10.96 port 33000 category name billing priority 90
SCE(config)# RDR-Formatter destination 10.1.96.0 port 33000 category name prepaid priority 80

Dynamic Mapping of RDRs to Categories



Dynamic configuration of RDRs to multiple categories is supported.

Each RDR tag has a list of categories. The default category is the one that was assigned when application was loaded.

The configuration of categories to RDR tags is done by adding and removing mappings. A user can add a mapping of RDR tag to a category and remove a mapping, including the default mapping. If only one category is left configured for a certain tag, it cannot be removed.

The user must provide the RDR tag ID and the category number to add or remove. The configuration is saved as part of the application configuration.

Configuring Mappings



Use these command to add or remove a mapping.

The following options are available:



tag-ID — The complete 32 bit value given as an hexadecimal number. The RDR tag must be already configured in the Formatter by the application.



category-number — Number of the category (1-4) to which to map the RDR tag.



To add a mapping to a category, use the following command:



From the SCE(config)# prompt, type RDR-formatter rdr-mapping (tag-ID <tag number> category-number <category number>) and press Enter.

If the table already contains a mapping with the same tag and category number, an error is issued and nothing is done.



To remove a mapping from a category, use the following command:



From the SCE(config)# prompt, type no RDR-formatter rdr-mapping (tag-ID <tag number> category-number <category number>) and press Enter.



To restore the default mapping for a specified RDR tag, use the following command:



From the SCE(config)# prompt, type default RDR-formatter rdr-mapping tag-ID <tag number> and press Enter.

Displaying RDR Formatter Configuration and Statistics



The system can display the complete RDR formatter configuration, or just specific parameters.

The following commands can be used to display the RDR formatter configuration and statistics:

show RDR-formatter
show RDR-formatter connection-status
show RDR-formatter counters
show RDR-formatter destination
show RDR-formatter enabled
show RDR-formatter forwarding-mode
Show RDR-formatter rdr-mapping
show RDR-formatter statistics



To display the current RDR formatter configuration, use the following command:



From the SCE> prompt, type show RDR formatter.

Example:



The following example shows how to display the current RDR formatter configuration.

SCE#show RDR-formatter
Status: enabled
Connection is: up
Forwarding mode: redundancy
Connection table:
-------------------------------------------------------------------------|
Collector   | Port|Status|           Priority per Category:              |
IP Addres / |     |      |-----------------------------------------------|
Host-Name   |     |      |Category1  |Category2  |Category3  |Category4  |
-------------------------------------------------------------------------|
10.1.1.205  |33000|Up    |100 primary|100 primary|100 primary|100 primary|
10.1.1.206  |33000|Down  |60         |60         |60         |60         |
10.12.12.12 |33000|Up    |40         |40         |40         |40         |
-------------------------------------------------------------------------|

RDR:    queued:         0 ,sent:         0, thrown:         0
UM:     queued:         0 ,sent:         0, thrown:         0
Logger: queued:         0 ,sent:         0, thrown:         0
Errors: thrown:         0
Last time these counters were cleared: 14:05:57 UTC SUN February 23 2003
SCE#

Refer to CLI Command Reference for a complete description of the other show RDR-formatter commands.

Disabling the LineCard from Sending RDRs



The silent command disables the LineCard from issuing Raw Data Records (RDR). Use the [no] form of this command if you want the LineCard to send reports.



To disable the LineCard from sending Raw Data Records (RDRs), complete the following steps:



From the SCE(config)# prompt, type interface Linecard 0, and press Enter.

The SCE(config if)# prompt appears.



Type silent, and press Enter.

The LineCard stops producing RDRs and the SCE(config if)# prompt appears.



To enable the Line Card to produce RDRs, use the following command:



From the SCE(config if)#

Hierarchical Navigation

Cisco Service Control Operating System Software

Cisco Service Control Engine (SCE) Software Configuration Guide, Rel 3.0.5 (HTML)

SCE Software Configuration Guide

Preface

Document Revision History

Description of Changes

Description of Changes

Description of Changes

Description of Changes

Audience

Organization

Related Publications

Note

Conventions

Note

Caution

Warning

Obtaining Documentation

World Wide Web

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Contacting TAC by Using the Cisco TAC Website

Contacting TAC by Telephone

Chapter 1. General Overview

The Cisco Service Control Concept

Service Control for Broadband Service Providers

Cisco Service Control Capabilities

The SCE Platform

Management and Collection

Network Management

Service Configuration Management

Subscriber Management

Data Collection

Chapter 2. Command-Line Interface

Getting Help

Authorization and Command Levels (Hierarchy)

Note

CLI Command Hierarchy

Note

Note

Example:

CLI Authorization Levels

Note

Example:

Prompt Indications

Example:

Exiting Modes

Example:

Navigating Between Configuration Modes

Entering and Exiting Global Configuration Mode

Interface Configuration Modes

Configuring the Physical Ports

Note

Entering Management Interface Configuration Mode

Entering LineCard Interface Configuration Mode

Entering Ethernet Line Interface Configuration Mode

Entering the Fast Ethernet Line Interface Configuration Mode

Example:

Entering the Gigabit Ethernet Line Interface Configuration Mode

Example:

Navigating between the Interface Configuration Modes

The "do" Command: Executing Commands Without Exiting

Example

CLI Help Features

Partial Help

Example:

Argument Help

Example:

Example:

The [no] Prefix

Navigational and Shortcut Features

Command History

Keyboard Shortcuts

Tab Completion

Example: