Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide

Configuring the 4-Port Serial Interface SPA

To configure the 4-Port Serial Interface SPA, complete these steps:

Note Each port should first be connected with the appropriate cable before attempting full configuration. Some commands are enabled only based upon the cable type connected to the port.

Note The bandwidth of each interface is 2 MB by default; setting the clock rate does not change the interface bandwidth. Cisco recommends that you configure the bandwidth value with the clock rate command at the DCE and DTE side.

Note A clock rate of 2016 does not appear in the configuration because it is the default value.

Specifying the Interface Address on a SPA

SPA interface ports begin numbering with “0” from left to right. Single-port SPAs use only the port number 0. To configure or monitor SPA interfaces, you need to specify the physical location of the SIP, SPA, and interface in the CLI (command-line-interface). The interface address format is slot / subslot / port, where:

• slot —Specifies the chassis slot number in the Cisco 7600 series router where the SIP is installed.
• subslot —Specifies the secondary slot of the SIP where the SPA is installed.
• port —Specifies the number of the individual interface port on a SPA.

The following example shows how to specify the first interface (0) on a SPA installed in the first subslot of a SIP (0) installed in chassis slot 3:

For more information about identifying slots and subslots, see the “Identifying Slots and Subslots for SIPs, SSCs, and SPAs” section.

Verifying the Configuration

After configuring the new interface, use the show commands to display the status of the new interface or all interfaces, and use the ping and loopback commands to check connectivity. This section includes the following subsections:

• Show Commands
• Using the ping Command to Verify Network Connectivity
• Using loopback Commands

Show Commands

The table below shows the show commands you can use to verify the operation of the 4-Port Serial Interface SPA. Sample displays of the output of selected show commands appear in the section that follows. For complete command descriptions and examples, refer to the publications listed in the “$paratext>” section.

Note The outputs that appear in this document may not match the output you receive when running these commands. The outputs in this document are examples only.

Verification Examples

The following is an example of a show version command with the 4-Port Serial Interface SPA:

The following is an example of a show hardware command with the 4-Port Serial Interface SPA:

The following is an example of a show controllers serial command with the 4-Port Serial Interface SPA:

Note The acronyms are defined as follows: RTS (Request to Send); CTS (Clear To Send); DTR (Data Transmit Ready); DCD (Data Carrier Detect); DSR (Data Set Ready).

The following is an example of a show diagbus command with the 4-Port Serial Interface SPA:

The following is an example of a show interfaces serial command with the 4-Port Serial Interface SPA:

The following are examples of the show protocol command with the 4-Port Serial Interface SPA:

The following is an example of a show startup-config command with the 4-Port Serial Interface SPA:

Using the ping Command to Verify Network Connectivity

Using the ping command, you can verify that an interface port is functioning properly. This section provides a brief description of this command. Refer to the publications listed in the “$paratext>” section for detailed command descriptions and examples.

The ping command sends echo request packets out to a remote device at an IP address that you specify. After sending an echo request, the system waits a specified time for the remote device to reply. Each echo reply is displayed as an exclamation point (!) on the console terminal; each request that is not returned before the specified timeout is displayed as a period (.). A series of exclamation points (!!!!!) indicates a good connection; a series of periods (.....) or the messages [timed out] or [failed] indicate a bad connection.

Following is an example of a successful ping command to a remote server with the address 10.0.0.10:

If the connection fails, verify that you have the correct IP address for the destination and that the device is active (powered on), and repeat the ping command.

Proceed to the next section, “Using loopback Commands,” to finish checking network connectivity.

Using loopback Commands

With the loopback test, you can detect and isolate equipment malfunctions by testing the connection between the 4-Port Serial Interface SPA and a remote device such as a modem or a channel service unit (CSU) or a data service unit (DSU). The loopback command places an interface in loopback mode, which enables test packets that are generated from the ping command to loop through a remote device or compact serial cable. If the packets complete the loop, the connection is good. If not, you can isolate a fault to the remote device or compact serial cable in the path of the loopback test.

Note You must configure a clock rate on the port before performing a loopback test. However, if no cable is attached to the port, the port is administratively up, and the port is in loopback mode; you do not have to configure a clock rate on the port before performing a loopback test.

Depending on the mode of the port, issuing the loopback command checks the following path:

• When no compact serial cable is attached to the 4-Port Serial Interface SPA port, or if a data circuit-terminating equipment (DCE) cable is attached to a port that is configured as line protocol up, the loopback command tests the path between the network processing engine and the interface port only (without leaving the network processing engine and port adapter).
• When a data terminal equipment (DTE) cable is attached to the port, the loopback command tests the path between the network processing engine and the near (network processing engine) side of the DSU or modem to test the 4-Port Serial Interface SPA and compact serial cable. (The X.21 DTE interface cable does not support this loopback test; see the following Note.)

Note The X.21 interface definition does not include a loopback definition. On the 4-Port Serial Interface SPA port adapter, the X.21 DTE interface does not support the loopback function. Because of the internal clock signal present on the 4-Port Serial Interface SPAs, loopback will function on an X.21 DCE interface.

This completes the configuration procedure for the new 4-Port Serial Interface SPA port adapter serial interfaces.

Optional Configurations

The following optional configurations may be necessary to complete the configuration of your serial SPA.

• Configuring Timing Signals
• Inverting the Clock Signal
• Configuring NRZI Format
• Configuring Cyclic Redundancy Checks
• Configuring Encapsulation
• Configuring Distributed Multilink PPP
• Configuring MLFR
• Configuring Multipoint Bridging
• Configuring Bridging Control Protocol Support
• Configuring BCP on MLPPP
• FRF.12 Guidelines
• LFI Guidelines
• FRF.12 LFI Guidelines

Configuring Timing Signals

All interfaces support both DTE and DCE mode, depending on the mode of the compact serial cable attached to the port. To use a port as a DTE interface, you need only connect a DTE compact serial cable to the port. When the system detects the DTE mode cable, it automatically uses the external timing signal. To use a port in DCE mode, you must connect a DCE compact serial cable and set the clock speed with the clock rate configuration command. You must also set the clock rate to perform a loopback test. This section describes how to set the clock rate on a DCE port and, if necessary, how to invert the clock to correct a phase shift between the data and clock signals.

Use the following commands when configuring timing signals:

Note Clock rates supported for EIA/TIA-232: 1.2K, 2.4K, 4.8K, 9.6K, 14.4K, 19.2K, 28.8K, 32K, 38.4K, 56K, 64K, 128K.

Note Clock rates supported for EIA-530, EIA-530A, EIA-449, V.35(bps): 1.2K, 2.4K, 4.8K, 9.6K, 14.4K, 19.2K, 28.8K, 32K, 38.4K, 56K, 64K, 72K, 115.2K, 128k, 230.4k, 252K, 504k, 1.008M, 2.016M, 4.032M, 8.064M. The other ones are unconfigurable.

Note Clock rates supported for X.21: 1.2K, 2.4K, 4.8K, 9.6K, 14.4K, 19.2K, 28.8K, 32K, 38.4K, 56K, 64K, 72K, 115.2K, 128k, 230.4k, 252K, 504k, 2.016M, 4.032M, 8.064M.

Inverting the Clock Signal

Systems that use long cables or cables that are not transmitting the TxC (clock) signal might experience high error rates when operating at higher transmission speeds. If a SPA-4XT DCE port is reporting a high number of error packets, a phase shift might be the problem: inverting the clock might correct this phase shift.

When the EIA/TIA-232 interface is a DTE, the invert-transmit-clock command inverts the TxC signal the DTE receives from the remote DCE. When the EIA/TIA-232 interface is a DCE, the invert-txclock command inverts the clock signal to the remote DTE port. Use the no invert-txclock command to change the clock signal back to its original phase.

Use the following commands when inverting the clock signal:

Configuring NRZI Format

All EIA/TIA-232 interfaces on the SPA-4XT support non-return-to-zero (NRZ) and non-return-to-zero inverted (NRZI) formats. Both formats use two different voltage levels for transmission. NRZ signals maintain constant voltage levels with no signal transitions—no return to a zero voltage level—during a bit interval and are decoded using absolute values: 0 and 1. NRZI uses the same constant signal levels but interprets the absence of data—a space—at the beginning of a bit interval as a signal transition and the presence of data—a mark—as no signal transition. NRZI uses relational encoding to interpret signals rather than determining absolute values.

Configuring Cyclic Redundancy Checks

Cyclic redundancy checking (CRC) is an error-checking technique that uses a calculated numeric value to detect errors in transmitted data. All interfaces use a 16-bit CRC (CRC-CITT) by default but also support a 32-bit CRC. The sender of a data frame calculates the frame check sequence (FCS). Before it sends a frame, the sender appends the FCS value to the message. The receiver recalculates the FCS and compares its calculation to the FCS from the sender. If there is a difference between the two calculations, the receiver assumes that a transmission error occurred and sends a request to the sender to resend the frame.

In the example that follows, the first serial port on a 4-Port Serial Interface SPA, installed on a versatile interface processor (VIP) in interface processor slot 3, is configured for 32-bit CRC:

The preceding command example applies to all systems in which the 4-Port Serial Interface SPA is supported.
Use the no crc 32 command to disable CRC-32 and return the interface to the default CRC-16 (CRC-CITT) setting.

Configuring Encapsulation

When traffic crosses a WAN link, the connection needs a Layer 2 protocol to encapsulate traffic. To set the encapsulation method, use the following commands:

Verifying Encapsulation

Use the show interface serial command to display the encapsulation method:

Configuring Distributed Multilink PPP

The Distributed Multilink Point-to-Point Protocol (dMLPPP) feature allows you to combine serial lines into a bundle that has the combined bandwidth of the multiple lines. This is done by using a dMLPPP link. You choose the number of bundles and the number of serial lines in each bundle. This allows you to increase the bandwidth of your network links beyond that of a single serial line without having to purchase a bigger line.

This section includes the following topics:

• dMLPPP Configuration Guidelines
• dMLPPP Configuration Tasks
• Verifying dMLPPP

dMLPPP Configuration Guidelines

dMLPPP is supported under the following conditions:

• All links are on the same Cisco 7600 SIP-200.
• Member links in a bundle are recommended to have the same bandwidth and clock rate.
• Quality of Service (QoS) is implemented on the Cisco 7600 SIP-200 for dMLPPP.
• Bundle links are configurable across the multilinkSPA.

Note Because the bundles are done in software, performance is dependent on the line card CPU.

• To enable fragmentation for software-based dMLPPP, you must configure the ppp multilink interleave command.
• You must use the ppp chap hostname command when you have more than one bundle between two routers.

When configuring dMLPPP on the Cisco 7600 SIP-200, consider the following restrictions:

• Data compression is supported for RTP traffic only (dCRTP).
• Encryption is not supported.
• The maximum differential delay is 100 ms when supported in software.

dMLPPP Configuration Tasks

The following sections describe how to configure dMLPPP:

• Creating a dMLPPP Bundle (required)
• Assigning an Interface to a dMLPPP Bundle (required)
• Configuring LFI over dMLPPP (optional)

Creating a dMLPPP Bundle

To configure a dMLPPP bundle, use the following commands beginning in global configuration mode:

Assigning an Interface to a dMLPPP Bundle

To configure an interface PPP link and associate it as a member of a multilink bundle, use the following commands beginning in global configuration mode. Repeat these steps to assign multiple links to the dMLPPP bundle.

The following example uses the ppp chap hostname command.

Configuring LFI over dMLPPP

LFI over dMLPPP is supported in software on the Cisco 7600 SIP-200. This support is determined by your link configuration.

Guidelines

When configuring LFI over dMLPPP, consider the following guidelines for software-based LFI:

• LFI over dMLPPP will be configured in software if there is more than one link assigned to the dMLPPP bundle.
• LFI is disabled by default in software-based LFI. To enable LFI on the multilink interface, use the ppp multilink interleave command.
• Fragmentation size is calculated from the delay configured and the member link bandwidth.
• You must configure a policy map with a priority class under the multilink interface.
• Compressed Real-Time Protocol (CRTP) should not be configured on a multilink interface when LFI is enabled on the multilink interface when the multilink bundle has more than one member link, or a QoS policy with a priority feature is enabled on the multilink interface.
• Using the using the shut and no shut commands in interface configuration mode is required when configuring interleave on the multilink interface.

Verifying dMLPPP

To verify dMLPPP configuration, use the show ppp multilink command, as shown in the following example:

Configuring MLFR

Multilink Frame Relay (MLFR) allows you to combine lines into a bundle that has the combined bandwidth of the multiple lines. You choose the number of bundles and the number of lines in each bundle. This allows you to increase the bandwidth of your network links beyond that of a single line.

Note MLFR is not supported with 4-port serial SPA on Cisco 7600 SIP-400.

MLFR Configuration Guidelines

MLFR will function in hardware if all of the following conditions are met:

• All links in the bundle are member links.
• All links are on the same SPA.

Creating a Multilink Bundle

To create a multilink bundle, use the following commands:

Assigning an Interface to a Multilink Bundle

To assign an interface to a multilink bundle, use the following commands:

Verifying Multilink Frame Relay

Use the show frame-relay multilink detailed command to verify the Frame Relay multilinks:

Configuring Multipoint Bridging

Multipoint bridging (MPB) enables the connection of multiple ATM permanent virtual circuist( PVCs), Frame Relay PVCs, Bridge Control Protocol (BCP) ports, and WAN Gigabit Ethernet subinterfaces into a single broadcast domain (virtual LAN), together with the LAN ports on that VLAN. This enables service providers to add support for Ethernet-based Layer 2 services to the proven technology of their existing ATM and Frame Relay legacy networks. Customers can then use their current VLAN-based networks over the ATM or Frame Relay cloud. This also allows service providers to gradually update their core networks to the latest Gigabit Ethernet optical technologies, while still supporting their existing customer base.

For MPB configuration guidelines and restrictions and feature compatibility tables, see the “Configuring Multipoint Bridging” section of Chapter5, “Configuring the SIPs and SSC”

Configuring Bridging Control Protocol Support

The Bridging Control Protocol (BCP) enables forwarding of Ethernet frames over SONET networks and provides a high-speed extension of enterprise LAN backbone traffic through a metropolitan area. The implementation of BCP on the SPAs includes support for IEEE 802.1D, IEEE 802.1Q Virtual LAN (VLAN), and high-speed switched LANs.

For BCP configuration guidelines and restrictions and feature compatibility tables, see the “BCP Feature Compatibility” section of Chapter5, “Configuring the SIPs and SSC”

Configuring BCP on MLPPP

BCP on MLPPP Configuration Guidelines

• Only Distributed MLPPP is supported.
• Only channelized interfaces are allowed, and member links must be from the same controller card.
• Only trunk port BCP is supported on MLPPP.
• Bridging can be configured only on the bundle interface.

Note BCP on MLPPP operates only in trunk mode.

Note BCP on MLPPP is not supported with 4-port serial SPA on Cisco 7600 SIP-400.

Configuring BCP on MLPPP Trunk Mode

To configure BCP on MLPPP trunk mode, perform these steps:

Verifying BCP on MLPPP Trunk Mode

To display information about Multilink PPP, use the show ppp multilink command in EXEC mode.

The following shows an example of show ppp multilink command :

FRF.12 Guidelines

For FRF.12, note the following:

• The fragmentation is configured at the main interface.
• Any fragmentation size is available.

For information on configuring FRF.12 on the Cisco SIP-200, see:

• http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/76sipspa/sipspasw/76sipssc/76cfgsip.htm#wp1135593
• http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/vvfvofr.htm.

Note FRF.12 is not supported with 4-Port Serial Interface SPA on Cisco 7600 SIP-400.

LFI Guidelines

LFI can function intwo ways—using FRF.12 or MLPPP.

FRF.12 LFI Guidelines

For LFI using FRF.12, note the following:

• The fragmentation is configured at the main interface.
• Any fragmentation size is available.

Note FRF.12 LFI is not supported with 4-Port Serial Interface SPA on Cisco 7600 SIP-400.

Saving the Configuration

To save your running configuration to nonvolatile random-access memory (NVRAM), use the following command in privileged EXEC configuration mode:

For more information about managing configuration files, refer to the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.2 and Cisco IOS Configuration Fundamentals Command Reference, Release 12.2 publications.

Verifying the Interface Configuration

Besides using the show running-configuration command to display your Cisco 7600 series router configuration settings, you can use the show interfaces serial and the show controllers serial commands to get detailed information on a per-port basis for your 2-Port and 4-Port Channelized T3 SPA.

Verifying Per-Port Interface Status

To find detailed interface information on a per-port basis for the 2-Port and 4-Port Channelized T3 SPA, use the show interfaces serial command to display port-specific information.

The following example provides sample output for the serial interface:

To find detailed status and statistical information on a per-port basis for the 4-Port Serial Interface SPA, use the show controller serial command.

The following example provides sample controller statistics:

Inverting the Clock Signal Configuration Example

NRZI Format Configuration Example

Cyclic Redundancy Checks Configuration Example

Encapsulation Configuration Example

Distributed Multilink PPP Configuration Example

MLFR Configuration Example

Bridging Control Protocol Support Configuration Example

BCP on MLPPP Configuration Example