SCE2000 4xGBE Installation and Configuration Guide

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:

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

Two interfaces are provided for network 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:

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. SCA BB 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.

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.

*Titles and quantities of documents will vary. You must order the type and quantity of documentation sets when you order the hardware.

The SCE 2000 can serve one of two general functions:

The SCE 2000 can be deployed in a single GBE link or in two GBE links. The two-link topology may implement load-sharing and the SCE 2000 in this case is able to process both directions of a bi-directional flow even if they split to both links.

When a high degree of reliability is desired, a second SCE 2000 Platform should be installed to provide backup operation capabilities. The combination of two SCE 2000s guarantees uninterrupted functioning in case of a failure of one of the platforms. The two SCE 2000s are cascaded, so that, although all processing is performed only in the active SCE 2000, the standby SCE 2000 is constantly updated with all the necessary information so that it can instantly take over processing the traffic on the data links should the active SCE 2000 fail.

If only preservation of the network links is required, and uninterrupted functionality of the SCE 2000 is not required, a single SCE 2000 is sufficient.

The bypass mechanism of the SCE 2000 allows traffic to continue to flow, if desired, even if the device itself is not functioning.

Note that when the SCE 2000 is connected to the network through an optical splitter, a failure of the SCE 2000 does not affect the traffic flow, as the traffic continues to flow through the optical splitter.

A single SCE 2000 supports both single GBE link and dual GBE link topologies.

Single Link: Inline Topology

Typically, the SCE 2000 is connected in a full duplex GBE link between two devices (Router, BRAS, etc.). When the SCE 2000 is installed as an inline installation, it physically resides on the data link between the subscribers and the network.

Figure 3.1. Single SCE Platform Single Link: In-line Topology

When configuring the SCE 2000, an inline installation is referred to as “inline” connection mode.

Dual link: Inline Installation

In this topology, one SCE 2000 is connected inline in two full duplex, GBE links.

In case the two links are load-shared, asymmetrical routing might occur, and some of the flows may be split, i.e. the upstream packets of the flow go on one link, and the downstream packets go on the other link.

When installed in this topology, the SCE 2000 completely overcomes this phenomenon, and provides its normal functionality as if asymmetrical routing were not occurring in the two links.

Figure 3.2. Single SCE Platform Dual Link Inline Topology

This topology supports both monitoring and control functionality, and is referred to as “inline” connection mode.

Single Link: Receive-only Topology

In this topology, an optical splitter resides physically on the GBE link between the subscribers and the network. The traffic passes through the optical splitter, which splits traffic to the SCE 2000. The SCE 2000, therefore, only receives traffic and does not transmit.

Figure 3.3. Single SCE Platform Single Link: Receive-Only Topology

When configuring the SCE 2000, an optical splitter topology is referred to as “receive-only” connection mode.

Note that in an optical splitter topology, the SCE 2000 only enables traffic monitoring functionality.

Note

When implementing receive-only topologies with a switch, the switch must support SPAN functionality that includes separation between ingress and egress traffic and multiple SPAN-ports destinations.

Dual Link: Receive-Only Topology

In this topology, one SCE 2000 is connected in receive-only mode to two full duplex, GBE links using optical splitters. If the two links are load-shared, asymmetrical routing might occur, and some of the flows may be split, i.e. the upstream packets of the flow go on one link, and the downstream packets go on the other link.

When installed in this topology, the SCE 2000 completely overcomes this phenomenon, and provides its normal monitoring functionality as if asymmetrical routing were not occurring in the two links.

This installation supports monitoring functionality only, and is configured as “receive-only” connection mode.

Figure 3.4. Single SCE Platform Dual Link Receive-Only Topology

Note

When implementing receive-only topologies with a switch, the switch must support SPAN functionality that includes separation between ingress and egress traffic and multiple SPAN-ports destinations.

In this topology, two cascaded SCE 2000s are used. This allows a fail-over solution, where in case of a failure of one SCE 2000, the functionality that the SCE 2000 provides is preserved by the redundant platform.

Two Cascaded SCE 2000s: Inline Topology

This topology allows both control and monitoring functionality where redundancy is required and “inline” connection is used. The two SCE 2000s are cascaded, so the primary SCE 2000 processes the traffic of the two links, while the secondary SCE 2000 only bypasses the traffic of its links to the primary SCE 2000 for processing, and then bypasses the processed traffic back to the link. The two SCE 2000s also exchange keep-alive messages and subscriber state information.

In case the primary SCE 2000 fails, the two SCE 2000s switch their roles, and this way fail-over is provided.

Figure 3.5. Two SCE Platforms: Dual Link Inline Topology

This fail-over solution preserves the SCE 2000 functionality and the network link:

• The two SCE 2000s are simultaneously aware of the subscriber contexts, and subscriber states are constantly exchanged between them, such that if the primary SCE 2000 fails, the secondary can take over with minimum state loss.

• When one SCE 2000 fails (depending on the type of failure) its link traffic is still bypassed to the functioning SCE 2000 and processed there, so the traffic processing continues for both the links.

• The bypass of the traffic through the failed SCE 2000 is configurable, and the user may choose to always cutoff the line that goes through the failed SCE 2000. In this case network redundancy protocols like HSRP are responsible for identifying the line cutoff and switching all the traffic to go through the functioning SCE 2000.

Refer to the following sections to determine the correct values for all topology-related parameters before beginning run the initial setup of the SCE 2000.

The SCE 2000 chassis is fully assembled at the factory, including the application and software packages. No assembly is required. However, you need the following tools and equipment to install the SCE 2000 chassis and the rack-mount kit (if installing the SCE 2000 platform in a rack), fan modules, and power supplies:

The environmental monitoring functionality in the SCE 2000 protects the system and components from potential damage from over-voltage and over-temperature conditions. To ensure normal operation and to avoid unnecessary maintenance, plan your site configuration and prepare your site before installation. After installation, make sure the site maintains an ambient temperature of 41°F to 104°F (5°C to 40°C) with short term temperatures ranging from 23°F to 131°F (–5°C to 55°C), and keep the area around the SCE 2000 chassis free from dust.

Planning a proper location for the SCE 2000 and the layout of your equipment rack or wiring closet is essential for successful system operation. Equipment placed too close together or inadequately ventilated can cause system over-heating. In addition, chassis panels made inaccessible by poor equipment placement can make system maintenance difficult.

Airflow

Figure 4.2. Airflow Through the SCE Platform

When you plan the location and layout of your equipment rack or wiring closet you need to consider how air flows though your system. The SCE 2000 draws cooling air in through the intake vents on the left side of the chassis, moves the air across the internal components, and out through the right side and rear panel of the chassis. The above figure illustrates the airflow through the SCE 2000.

Note

Remember to leave a two inch (5 cm) clearance on both sides of the SCE 2000 and five inches (12.7 cm) at the rear for adequate airflow for the inlet and exhaust vents.

The router should already be in the area where you will install it, and your installation location should already be determined. If not, see Site Requirement Guidelines and the Site Preparation and Safety Guide.

When installing the SCE 2000, please observe the following conditions:

You can install the SCE 2000 platform on any flat surface as long as the surface is large enough for the SCE 2000 (see the table in SCE 2000 Dimensions), and allows for adequate airflow/ventilation around the sides of the SCE 2000, as described in the Installation Precautions. When installing the SCE 2000 on a workbench or tabletop or in a rack, ensure that the surface is clean and in a safe location.

Figure 4.3. Installing the System on a Flat Surface

This completes the general workbench or tabletop installation.

Proceed to section, Attaching a Chassis Ground Connection to continue the installation.

You can mount the SCE 2000 platform to a 19” rack. There are two standard types of equipment racks, and the appropriate brackets for each are provided in the enclosed kit.

The SCE 2000 mounts to the two front rack posts with brackets that attach to the front of the SCE 2000 The inside width between the two posts or mounting strips (left and right) must be at least 17.3 inches (44 cm).

Because the inlet and exhaust ports (vents) for cooling air are located at both sides of the chassis, respectively, multiple SCE 2000s can be stacked in a rack with no vertical clearance.

Before you connect the power or turn on the power to the SCE 2000 platform, it is required that you provide an adequate chassis ground (protective earth) connection for the SCE 2000 chassis. A grounding kit is provided with each SCE 2000.

Use the grounding kit to properly ground the SCE 2000 chassis (see SCE 2000 Component List for details).

This completes the procedure for installing the SCE 2000 chassis. Proceed to the next section, Connecting to the Power Supply, to continue the installation.

The following LEDs are used to monitor the functioning of the power supply units:

On both the AC-input and DC-input power supplies, the IN LED iis used to monitor the voltages received by the platform from the power source. If the input voltages are within normal operating ranges, the green IN LED is illuminated. If the input voltages are above or below normal ranges, the IN LED is not illuminated.

On both the AC-input and DC-input power supplies, the OK LED is used to monitor the power supply DC output voltages used to power the platform. The normal operating ranges for the 12 VDC output voltage is between 11.9V and 12.1V. If the output voltages are within normal operating ranges, the green OK LED is illuminated. If the 12 VDC output voltages are above (more than 12.1V) or below (less than 11.9V) normal ranges, the OK LED is not illuminated.

The Power A and Power B LEDs on the front panel indicate whether the corresponding power supply unit is functioning normally.

Refer to the following tables for LED status information

The following table lists the AC-input and DC-input power supply specifications for the SCE 2000 platform:

The following sections describe how to remove power from an AC-input power supply and a DC-input power supply:

This completes the procedure for removing the power supply from a SCE 2000 platform.

This completes the procedures for replacing a power supply in a SCE 2000 platform.

The following sections describe how to reconnect the AC or DC power:

The following sections explain how to remove and replace a fan module in a SCE 2000 platform:

This section provides instructions for setting up your local terminal at your workstation, to enable you to perform the initial system configuration of the SCE 2000 system using the setup utility.

Figure 5.1. Connecting to the Local Console

Make sure that the terminal configuration is as follows:

The above SCE 2000 port parameters are fixed and are not configurable.

Following are some general instructions regarding the setup dialog:

Example:

Verify the following initial settings for the SCE 2000:

All values are Internet addresses of the form ‘X.X.X.X’, where each letter corresponds to a decimal number between 0 and 255.

Example:

The following example displays a typical configuration of the IP address (10.1.5.109), subnet mask (255.255.0.0), and default gateway (10.1.1.3).

Since the IP address and the subnet mask are related, when the IP address is changed, there is no longer a default value of the subnet mask, and it must be entered explicitly.

Enter IP address [10.1.1.201]:10.1.5.109
Enter IP subnet mask:255.255.0.0
Enter IP address of default gateway [10.1.1.3]:

The hostname is used to identify the SCE 2000. It appears as part of the CLI prompt and is also returned as the value of the MIB-II object sysName.

The maximum length is 20 characters.

The default hostname is SCE 2000.

Configure the passwords as follows:

Passwords must meet the following criteria:

Example:

Following is an example of changing all passwords. Password encryption is not enabled (default).

Enter a User password [cisco]: userin
Enter an Admin password [cisco]: mng123
Enter a Root password [cisco]: cistech
Enable passwords encryption? [no]:

The time settings menu configures all time and date related parameters in the system. The time settings menu includes the following:

You must enter the time setting menu in order to configure SNTP settings. You may choose to skip the time settings menu if you wish to accept all default values.

Example:

Following is a sample time setting dialog. In addition to setting the time zone, time and date are changed, and SNTP unicast updates are configured.

The DNS configuration menu defines the IP address of the domain name server, which is used for DNS lookup, as well as the default domain name, which is used to complete unqualified host names.

You may choose to skip the DNS configuration menu if you wish to accept all default values.

Example:

Following is a sample DNS configuration dialog. The default domain name is pcube.com, and the IP address of the Domain Name Server is 10.1.1.230.

Would you like to enter the DNS configuration menu? [no]: y
Enable IP DNS-based hostname translation? [yes]:
Enter default domain name []: pcube.com
Enter Primary DNS IP address: 10.1.1.230
Would you like to add another Name Server? [no]:

The SCE 2000 passes Raw Data Records (RDRs) to an external collection system via the RDR-Formatter. In order for the data to reach the correct location, the IP address of the external collection system and its port number must be configured.

Example:

Following is a sample RDR-formatter configuration dialog, assigning the IP address and TCP port number.

Would you like to enter the RDR-formatter configuration menu? [no]: y
Enter RDR-formatter destination’s IP address: 10.1.1.230
Enter RDR-formatter destination’s TCP port number: 33000

The SCE 2000 can be configured with Access Control Lists (ACLs), which are used to permit or deny incoming connections on any of the management interfaces.

Would you like to enter the Access lists configuration menu? [no]: y
Would you like to create new Access lists or modify existing lists? [no]: y
Enter ACL number: 1
Does this entry permit access? [yes]:
Enter IP address or the word ‘any’ to denote any IP address: any
This entry matches every IP address, no use in adding more entries to this list.
Would you like to configure another list? [no]: y
Enter ACL number: 2
Does this entry permit access? [yes]:
Enter IP address or the word ‘any’ to denote any IP address: 10.1.1.0
Enter wildcard bits: 0.0.0.0
Would you like to add another entry to this list? [no]:y
Does this entry permit access? [yes]:
Enter IP address or the word ‘any’ to denote any IP address: 10.10.10.1
Enter wildcard bits: 0.0.0.0
Would you like to add another entry to this list? [no]:y
Does this entry permit access? [yes]:n
Enter IP address or the word ‘any’ to denote any IP address: any
This entry matches every IP address, no use in adding more entries to this list.
Would you like to configure another list? [no]: 
Enter IP access-class [0]: 1
Enter Telnet access-class [0]: 2
Example 2:
This example skips the first section of the dialog (creating/modifying), and proceeds directly to assign existing ACLs.
Would you like to enter the Access lists configuration menu? [no]: y
Would you like to create new Access lists or modify existing lists? [no]:
Enter IP access-class [0]: 10
Enter Telnet access-class [0]: 22

Managing the SCE 2000 is possible also via a Network Management System (NMS) that supports SNMP. By default, SNMP is disabled on the SCE 2000.

To enable SNMP management you must configure the following basic SNMP parameters:

Example:

Following is a sample SNMP configuration, configuring one trap manager, one GET community, and one SET community, and enabling the authentication failure trap, as well as all enterprise traps.

Would you like to enter the SNMP configuration menu? [no]: y
Enable SNMP management? [no]: y
Enter SNMP GET community name[]: public
Enter Access list number allowing access with this community string, use ‘0’ to allow all: 0
Would you like to add another SNMP GET community? [no]:
Enter SNMP SET community name[]: private
Enter Access list number allowing access with this community string, use ‘0’ to allow all: 2
Would you like to add another SNMP SET community? [no]:
Would you like to configure SNMP trap managers? [no]: y
Enter SNMP trap manager IP address: 10.1.1.253
Enter SNMP trap manager community string: public
Enter trap manager SNMP version: 2c
Would you like to add another SNMP trap manager? [no]:
Enable the ‘Authentication Failure’ trap [no]: y
Enable SCE enterprise traps []: y
Enter system administrator contact name []: John Smith

The topology configuration menu is a series of guided questions relating to the deployment of the SCE 2000 in the network and its mode of operation. Values for the parameters are configured based on the user answers.

The correct value for each parameter must be ascertained before configuring the system to make sure that the system will function in the desired manner. (See Topology for a comprehensive discussion of topology and the related parameters.)

There are six topology-related parameters:

The procedure described below is a presentation of all the questions in the topology configuration. In actual practice, all questions may not be presented for a particular configuration, depending on the topology deployed.

Study the examples that follow to understand the procedure for various topologies.

The following examples present the procedure for configuring the topology-related parameters for various topologies.

Example 1:

Following is a sample topology configuration for a non-redundant topology using an optical splitter, that is, a single SCE 2000 connected in receive-only connection mode, to one or two GBE links

All other parameter values are automatically assigned by the system.

Example 2:

Following is a sample topology configuration for a non-redundant inline topology. In this topology, a single SCE 2000 is connected to one or two GBE links.

When the inline connection mode is specified, the user must specify the on-failure link behavior.

Example 3:

Following is a sample topology configuration for a secondary SCE 2000 in a redundant inline topology. In this topology there are two SCE 2000s that are cascaded via the cascade GBE ports (ports 3 and 4). Each SCE 2000 is connected inline to both sides (subscribers/network) of one GBE link.

In this case, the user must specify the physically-connected-link index (link-0 in our example), the priority of the SCE 2000, and the on-failure link behavior.

When you have completed the entire configuration, the system checks for errors. If errors are found, a warning message appears. When the configuration is error-free, you may apply and save it.

This completes the procedures for initial configuration of the SCE 2000 platform.

Example 1:

Following is an example of a configuration that the user aborted due to errors detected in the configuration.

Note that no confirmation is requested for the decision to abort the setup. Had there been no errors, confirmation would have been requested before aborting.

Example 2:

Following is an example of a configuration that was applied and saved to the startup configuration as well as to an FTP site.

Although not demonstrated in this example, it is recommended that you always view the configuration before applying it.

Example 3:

Following is an example of a configuration that was aborted, although no errors were detected.

The SCE 2000 has two management ports, labeled Mng1 and Mng 2.

If the SCE 2000 platform has been powered up, test now to verify that connectivity has been established between the SCE 2000 and the remote management host. If the SCE 2000 platform is not powered up, perform this step after starting the SCE 2000 platform.

This completes the procedures for connecting the management interfaces and for initial configuration of the SCE 2000 platform. Proceed to the next chapter for a description of the procedures for cabling the Gigabit Ethernet ports and for configuring Gigabit Ethernet (GBE) interface parameters.

Example:

The following example displays a typical ping response where the target IP address is 10.1.1.201.

Before beginning, find the appropriate cabling diagram for the topology in your installation:

Single Link: Inline Topology

In the inline topology, the SCE 2000 resides physically on the GBE (Gigabit Ethernet) link between the subscribers, which are usually connected through either a BRAS (in DSL access), a PDSN (in wireless access), a CMTS (in the Cable access), or a switch or router aggregator (in other topologies), and the network, where the SCE 2000 usually connects to a router or layer 3 switch network element.

Figure 6.1. Cabling Diagram for Single Link Inline Topology

In the single link inline topology, either the first GBE link (first two ports) of the SCE 2000 or the second GBE link (third and fourth ports) can be used, as illustrated in the diagram above. The remaining pair of ports is unused.

Either port 1 or port 3 is used for connecting to the network element that is deployed on the subscriber side of the SCE 2000 while port 2 or port 4 is used for connecting to the network element that is deployed on the network side of the SCE 2000.

Inline topology requires both Receive and Transmit fibers

Single Link: Receive-only Topology

In this topology, an optical splitter resides physically on the GBE link that the SCE 2000 should monitor. The optical splitter is connected to the SCE 2000 via Rx links only.

In this topology, the traffic passes through the optical splitter, which splits traffic to the SCE 2000.

Note

Receive-only topologies can also be implemented using a switch. Such a switch must support SPAN functionality that includes separation between ingress and egress traffic and multiple SPAN-ports destinations.

Figure 6.2. Cabling Diagram for Single SCE Platform Single Link Receive-only Topology

The single link receive-only topology cabling is similar to that for single link inline, in that either the first GBE link (first two ports) or the second GBE link (third and fourth ports) can be used, as illustrated in the diagram above. The remaining pair of ports is unused.

Either port 1 or port 3 is used for connecting to the network element that is deployed on the subscriber side of the SCE 2000 while port 2 or port 4 is used for connecting to the network element that is deployed on the network side of the SCE 2000.

Dual Link: Single SCE 2000 Topologies

In this topology, one SCE 2000 is connected to two full duplex, GBE links. The SCE 2000 may be either inline, to support both monitoring and traffic control functionality, or receive-only for traffic monitoring functionality only.

When one SCE 2000 supports two links, the first two ports are connected to one link, while ports 3 and 4 are connected to the second link as follows;

• Port 1: Link 1, Subscriber side

• Port 2: Link 1, Network side

• Port 3: Link 2, Subscriber side

• Port 4: Link 2, Network side

As with the single link cabling, inline topologies require both Receive and Transmit fibers, while Receive-only systems use only Receive fibers.

Note

Receive-only topologies can be implemented using either an optical splitter or a switch. If a switch is used, it must support SPAN functionality that includes separation between ingress and egress traffic and multiple SPAN-ports destinations.

The following two diagrams illustrate the connections for dual links, with a single SCE 2000 deployed for both inline and receive-only topologies.

Figure 6.3. Cabling Diagram: Dual Link One SCE Platform Inline

Figure 6.4. Cabling Diagram: Dual Link One SCE Platform Receive-only

Dual Link: Two SCE 2000s Topology

In this topology, two SCE 2000s are connected to two full duplex, GBE links, providing full redundancy through cascading the two SCE 2000s. The SCE 2000s may be either inline, to support both monitoring and traffic control functionality, or receive-only for traffic monitoring functionality only.

Note

When installing a cascaded system, it is extremely important to follow the sequence of procedures outlined in the section Installing a Cascaded System.

Note

Receive-only topologies can be implemented using either an optical splitter or a switch. If a switch is used, it must support SPAN functionality that includes separation between ingress and egress traffic and multiple SPAN-ports destinations.

When two SCE 2000s are used, the first two ports in each SCE 2000 are connected to the links, while ports 3 and 4 are the cascade ports that are used for communicating between the two SCE 2000s as follows:

SCE 2000 #1

• Port 1: Link 1, Subscribers side

• Port 2: Link 1, Network side

• Port 3: Cascade, connect to Port 4 in SCE 2000 #2

• Port 4: Cascade, connect to Port 3 in SCE 2000 #2

SCE 2000 #2

• Port 1: Link 2, Subscribers side

• Port 2: Link 2, Network side

• Port 3: Cascade, connect to Port 4 in SCE 2000 #1

• Port 4: Cascade, connect to Port 3 in SCE 2000 #1

Note

Cascade ports must be connected directly in Layer 1 (dark fibers).

Inline topologies require connecting both Receive and Transmit fibers to the SCE 2000. Cascade ports always require both Receive and Transmit fibers to be connected.

The following diagram illustrates the connections for a dual link, two SCE 2000 inline topology

Figure 6.5. Cabling Diagram: Dual Link Inline Topology Two Cascaded SCE Platforms

By default, the SCE 2000 GBE line interface ports are configured with auto-negotiation disabled. The procedure for enabling auto-negotiation for the GBE line interface ports is explained in the following section.

The following sections present the general procedure for cabling the GBE interface ports. Refer to Cabling Diagrams to find the appropriate cabling diagram for the topology of your system for the specific connections required.

If the SCE 2000 platform has been powered up, test now to verify that connectivity has been established on all links. If the SCE 2000 platform is not powered up, perform this step after starting the SCE 2000 platform.

This section presents CLI commands relevant to the configuration and monitoring of a redundant system.

Use the following commands to configure and monitor a redundant system:

SCE 2000(config if)# connection-mode inline-cascade physically-connected-links link-0 priority secondary on-failure bypass

Check the following conditions before you start your SCE 2000 platform:

You are now ready to start your SCE 2000 platform. Proceed to the section Starting the System and Observing Initial Conditions.

If the system does not complete each of the steps in the startup procedure, proceed to Troubleshooting for troubleshooting recommendations and procedures.

The procedures for performing the final tests to verify that the SCE 2000 is functioning properly are explained in the following sections:

SCE 2000#show system operation-status
System Operation status is Operational

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:

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.

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.

Example:

The following example shows the running configuration file.

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.

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.

Example:

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

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.

Example:

The following example shows the commands for system reboot.

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.

Example:

The following example shows the commands for system shutdown.

Use the following commands to provide information to help you troubleshoot installation of your SCE 2000 platform. Refer to Cisco Service Control Engine (SCE) Software Configuration Guide or the Cisco Service Control Engine (SCE) CLI Command Reference for more information.

Refer to The User Log for an explanation of commands related to 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 front panel LEDS are the most immediate problem-detection mechanism of the platform. Refer to the following sections for information on SCE 2000 platform LEDS:

Startup problems are commonly due to the source power or to a poor cable connection.

When you start up the SCE 2000 platform for the first time, you should observe the startup sequence described in the Starting the SCE 2000 Platform. This section contains a more detailed description of the normal startup sequence and describes the steps to take if the system does not perform that sequence as expected. LEDs indicate all system states in the startup sequence. By checking the state of the LEDs, you can determine when and where the system failed in the startup sequence. Use the following descriptions to isolate the problem to a subsystem, and then proceed to the appropriate sections to try to resolve the problem.

When you start up the system by turning on the power supply switch, the following should occur:

Check the following to help isolate a problem in the power subsystem. In the normally configured SCE 2000 platform with redundant power supply units, it is unlikely that the device will not start at all. However, at startup it should be verified that both power supply units are operational, and therefore the following steps should be followed if one of the Power LEDs on the front panel remains unlit when the SCE 2000 platform is powered up.

Check the following to help isolate a problem in the installation of the firmware package.

Problems related to the installation of the firmware package could be any of the following:

Check the following to help isolate a problem in the management subsystem.

Problems in the management subsystem could be any of the following:

Check the following to help isolate a problem in the link interface subsystem.

In general, the case where no traffic is coming out of the SCE 2000 is often caused by link problems or GBE interface configuration. Note that in some cases, the problem which seems as a transmit problem could be in the Rx (no traffic is being received by the SCE 2000 or there is actually no traffic on the line, which could be a normal situation).

Problems in the link interface subsystem could be any of the following: