Table Of Contents
Configuring Interfaces
Interface Configuration Task List
Understand Interface Configuration
Configure an Asynchronous Serial Interface
Asynchronous Serial Task List
Specify an Asynchronous Serial Interface
Configure Asynchronous Serial Encapsulation
Configure Dedicated or Interactive Mode
Enable Routing on the Asynchronous Interface
Configure Group and Member Asynchronous Interfaces
Create the Group Interface and the Member Interfaces
Define Member Asynchronous Interface Characteristics
Configure an ATM Interface
Configure Channelized E1
Channelized E1 Task List
Configure the E1 Controller
Define the Line Code
Define the Framing Characteristics
Define the E1 Channel Groups
Configure the Channelized E1 Channel Groups
Configure Channelized T1
Channelized T1 Task List
Configure the T1 Controller
Define the Line Code
Define the Framing Characteristics
Define the Clock Source
Define the T1 Channel Groups
Configure the Channelized T1 Channel Groups
Troubleshooting Channelized E1 and Channelized T1
Troubleshooting Channelized T1/E1 Channel Groups
Channelized T1/E1 Channel Group Loopbacks
Configure Channelized T1 on the Cisco AS5200
Configure the T1 Controllers to Make and Receive Calls
Configure the ISDN D-Channel Serial Interfaces
Configure CSU/DSU Service Modules (Cisco 2524 and Cisco 2525)
Configure Fractional T1/T1 CSU/DSU Service Modules
Specify the Clock Source
Enable Data Inversion Before Transmission
Specify the Frame Type of a FT/T1 Line
Specify the CSU Line Build Out
Specify FT1/T1 Line-Code Type
Enable Remote Alarms
Enable Loopcodes that Initiate Remote Loopbacks
Specify Timeslots
Configure 2-Wire and 4-Wire 56/64-kbps CSU/DSU Service Modules
Set the Clock Source
Set the Network Line Speed
Enable Scrambled Data Coding
Change between Digital Data Service and Switched Dial-Up Modes
Enable Acceptance of a Remote Loopback Request
Select a Service Provider
Configure a Dialer Interface
Configure an Ethernet or Fast Ethernet Interface
Ethernet Interface Task List
Specify an Ethernet or Fast Ethernet Interface
Specify Ethernet Encapsulation Method
Specify the Media and Connector Type (Cisco 4000)
Extend the 10BaseT Capability (Cisco 4000 and Cisco 4500 only)
Configure a Fiber Distributed Data Interface (FDDI)
Using Connection Management (CMT) Information
FDDI Task List
Specify an FDDI
Enable FDDI Bridging Encapsulation
Set the Token Rotation Time
Set the Transmission Valid Timer
Control the Transmission Timer
Modify the C-Min Timer
Modify the TB-Min Timer
Modify the FDDI Timeout Timer
Control SMT Frame Processing
Enable Duplicate Address Checking
Set the Bit Control
Control the CMT Microcode
Start and Stop FDDI
Control the FDDI SMT Message Queue Size
Preallocate Buffers for Bursty FDDI Traffic
Configure a High-Speed Serial Interface (HSSI)
HSSI Task List
Specify an HSSI
Specify HSSI Encapsulation
Invoke ATM on an HSSI Line
Convert HSSI to Clock Master
Configure a Hub Interface
Enable a Hub Port
Disable or Enable Automatic Receiver Polarity Reversal
Disable or Enable the Link Test Function
Enable Source Address Control
Enable SNMP Illegal Address Trap (for Cisco 2505, Cisco 2507, and Cisco 2516)
Configure an ISDN BRI, MBRI, or PRI Interface
Configure a LAN Extender Interface
LAN Extender Interface Configuration Task List
Configure and Create a LAN Extender Interface
Define Packet Filters
Filter by MAC Address and Vendor Code
Filter by Protocol Type
Control Priority Queuing
Control the Sending of Commands to the LAN Extender
Shut Down and Restart the LAN Extender's Ethernet Interface
Restart the LAN Extender
Download a Software Image to the LAN Extender
Troubleshoot the LAN Extender
Configure a Loopback Interface
Configure Low-Speed Serial Interfaces (Cisco 2520 to Cisco 2523)
Understand Half-Duplex DTE and DCE State Machines
Half-Duplex DTE State Machines
Half-Duplex DCE State Machines
Change between Controlled-Carrier and Constant-Carrier Modes
Place a Low-Speed Serial Interface in Controlled-Carrier Mode
Place a Low-Speed Serial Interface in Constant-Carrier Mode
Tune Half-Duplex Timers
Change between Synchronous and Asynchronous Modes
Return a Low-Speed Serial Interface to Synchronous Mode
Configure a Null Interface
Configure a Packet OC-3 Interface
Packet OC-3 Interface Configuration Task List
Select a Packet OC-3 Interface
Set the MTU Size
Configure Framing
Configure an Interface for Internal Loopback
Configure an Interface for Line Loopback
Set the Source of the Transmit Clock
Enable the Packet OC-3 Interface
Assign a Network Protocol Address
Save the Configuration
Configure a Synchronous Serial Interface
Synchronous Serial Task List
Specify a Synchronous Serial Interface
Specify Synchronous Serial Encapsulation
Configure PPP
Configure Compression of LAPB Data
Configure Compression of HDLC Data
Invoke ATM over a Serial Line
Configure the CRC
Use the NRZI Line-Coding Format
Enable the Internal Clock
Invert the Transmit Clock Signal
Set Transmit Delay
Configure DTR Signal Pulsing
Ignore DCD and Monitor DSR as Line Up/Down Indicator
Specify the Serial Network Interface Module Timing
Specify G.703 Interface Options
Enable Framed Mode
Enable CRC4 Generation
Use Time Slot 16 for Data
Specify a Clock Source
Configure a Token Ring Interface
Token Ring Task List
Specify a Token Ring Interface
Enable Early Token Release
Configure PCbus Token Ring Interface Management
Configure a Tunnel Interface
Advantages of Tunneling
Special Considerations
IP Tunneling Task List
Specify the Tunnel Interface
Configure the Tunnel Source
Configure the Tunnel Destination
Configure the Tunnel Mode
Configure End-to-End Checksumming
Configure a Tunnel Identification Key
Configure a Tunnel Interface to Drop Out-of-Order Datagrams
Configure Asynchronous Host Mobility
Understand Subinterfaces
Configure Features Available on Any Interface
Add a Description for an Interface
Configure MOP
Control Interface Hold-Queue Limits
Set Bandwidth
Set Interface Delay
Adjust Timers
Limit Transmit Queue Size
Adjust Maximum Packet Size or MTU Size
Understand Online Insertion and Removal (OIR)
Understand Fast, Autonomous, and SSE Switching Support
Monitor and Maintain the Interface
Monitor Interface and Controller Status
Monitor the T1 or E1 Controller
Monitor and Maintain CSU/DSU Service Modules
Reset the CSU/DSU
Perform a Self-Test
Display a Performance Report
Perform Loopback Tests
Monitor the LAN Extender Interface
Monitor and Maintain a Hub
Shut Down the Hub Port
Reset the Hub or Clear the Hub Counters
Monitor the Hub
Monitor IP Tunnels
Clear and Reset the Interface
Shut Down and Restart the Interface
Configure Loopback Detection
Run Interface Loopback Diagnostics
Enable Loopback Testing on the HSSI
Configure the Ethernet Loopback Server
Enable Loopback on Token Ring Cards
Troubleshooting Channelized E1 and Channelized T1
Troubleshooting Channelized T1 and E1 Channel Groups
Enable Loopback Testing of Fractional T1/T1
Interface Configuration Examples
Enabling Interface Configuration Examples
Dedicated Asynchronous Interface Example
Restricting Access on the Asynchronous Interface Example
Asynchronous Routing and Dynamic Addressing Example
Address Pooling on Asynchronous Interfaces Examples
DHCP Pooling Examples
Local Pooling Example
Configure Specific IP Addresses for an Interface Example
Group and Member Asynchronous Interfaces Examples
Channelized E1 Controller Example
Channelized T1 Controller and Interface Examples
CSU/DSU Service Module (Cisco 2524 and 2525) Examples
FT1/T1 Examples
2- and 4-Wire 56/64-kpbs Service Module Examples
Enabling Ethernet Encapsulation Example
Hub Configuration Examples
Hub Port Startup Examples
Source Address for an Ethernet Hub Port Configuration Examples
Hub Port Shutdown Examples
Enable SNMP Illegal Address Trap for Hub Port Example
Enabling a LAN Extender Interface Example
LAN Extender Interface Access List Examples
Filtering by MAC Address Example
Filtering by Ethernet Type Code Example
Low-Speed Serial Interface Examples
Set Synchronous or Asynchronous Mode Example
Change between Controlled-Carrier and Constant-Carrier Modes Example
Tune Half-Duplex Timers Example
Packet OC-3 Interface Configuration Examples
Packet OC-3 Configuration with Default Values Accepted
Two Routers Connected Back to Back
IP Tunneling Examples
Routing Two AppleTalk Networks across an IP-Only Backbone Example
Routing a Private IP Network and a Novell Net across a Public Service Provider Example
Interface Description Examples
Interface Shutdown Examples
Backup Interface Examples
Dial Backup Service When the Primary Line Goes Down Example
Dial Backup Service When the Primary Line Reaches Threshold Examples
Dial Backup Service When the Primary Line Exceeds Threshold Examples
Configuring Interfaces
Use the information in this chapter to understand the types of interfaces supported on Cisco routers and access servers. Two types of interfaces are supported: physical and virtual interfaces. The types of physical interfaces on a device depend on its interface processors or port adapters. The virtual interfaces that Cisco routers and access servers support include subinterfaces and IP tunnels.
Cisco routers and access servers support the following types of interfaces:
•
Asynchronous serial
•
Asynchronous Transfer Mode (ATM)
•
Channelized E1
•
Channelized T1
•
Dialer
•
Ethernet
•
Fast Ethernet
•
Fiber Distributed Data Interface (FDDI)
•
Fractional T1/T1
•
High-Speed Serial Interface (HSSI)
•
ISDN Basic Rate Interface (BRI)
•
ISDN Multiple Basic Rate Interface (MBRI)
•
ISDN Primary Rate Interface (PRI)
•
LAN Extender
•
Loopback
•
Low-Speed Serial
•
Null
•
Packet OC-3
•
Synchronous serial
•
Token Ring
•
Tunnel
In addition, the Cisco IOS software support subinterfaces. See the Wide-Area Networking Configuration Guide and the protocol chapters in the Cisco IOS software configuration guides for specific information on how to configure a subinterface for a particular protocol.
Note
One or more of the commands that previously appeared in this chapter have been replaced by new commands. See the Configuration Fundamentals Command Reference for command information. The old commands continue to perform their normal function in the current release, but support for them will cease in a future release.
For hardware technical descriptions and information about installing interfaces, refer to the hardware installation and maintenance publication for your product. For command descriptions and usage information, refer to the "Interface Commands" chapter of the Configuration Fundamentals Command Reference.
Interface Configuration Task List
You can perform the tasks in the following sections to configure and maintain the interfaces:
•
Understand Interface Configuration
•
Configure an Asynchronous Serial Interface
•
Configure an ATM Interface
•
Configure Channelized E1
•
Configure Channelized T1
•
Configure Channelized T1 on the Cisco AS5200
•
Configure CSU/DSU Service Modules (Cisco 2524 and Cisco 2525)
•
Configure a Dialer Interface
•
Configure an Ethernet or Fast Ethernet Interface
•
Configure a Fiber Distributed Data Interface (FDDI)
•
Configure a High-Speed Serial Interface (HSSI)
•
Configure a Hub Interface
•
Configure an ISDN BRI, MBRI, or PRI Interface
•
Configure a LAN Extender Interface
•
Configure a Loopback Interface
•
Configure Low-Speed Serial Interfaces (Cisco 2520 to Cisco 2523)
•
Configure a Null Interface
•
Configure a Packet OC-3 Interface
•
Configure a Synchronous Serial Interface
•
Configure a Token Ring Interface
•
Configure a Tunnel Interface
•
Understand Subinterfaces
•
Configure Features Available on Any Interface
•
Understand Online Insertion and Removal (OIR)
•
Understand Fast, Autonomous, and SSE Switching Support
•
Monitor and Maintain the Interface
Note
For information about the Channel Interface Processor (CIP), see the chapter entitled "Configuring IBM Channel Attach" in the Bridging and IBM Networking Configuration Guide. The CIP is described in a separate chapter because of the relationships between host system configuration values and configuration values.
See the end of this chapter for "Interface Configuration Examples."
Understand Interface Configuration
Begin interface configuration in global configuration mode. To configure an interface, follow these steps:
Step 1
Enter the configure EXEC command at the privileged EXEC prompt to enter global configuration mode.
Step 2
Once in the global configuration mode, start configuring the interface by entering the interface command. Identify the interface type followed by the number of the connector or interface card. These numbers are assigned at the factory at the time of installation or when cards are added to a system and can be displayed with the show interfaces EXEC command. A report is provided for each interface that the device supports, as seen in the following partial sample display:
Serial 0 is administratively down, line protocol is down
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Use the show hardware EXEC command to see a list of the system software and hardware.
To begin configuring serial interface 0, you add the following line to the configuration file:
Note
It is not necessary to add a space between the interface type and interface number. For example, in the preceding line you can specify either serial 0 or serial0.
Step 3
Follow each interface command with the interface configuration commands your particular interface requires. These command define the protocols and applications that will run on this interface. The commands are collected and applied to the interface command until you enter another interface command, a command that is not an interface configuration command, or you type the Ctrl-Z sequence to get out of configuration mode and return to privileged EXEC mode.
Step 4
Once an interface is configured, you can check its status by entering the EXEC show commands described after the task tables that follow.
Note
When you configure channelized T1or channelized E1, you must first define the channels and the time slots that comprise the channels by using the controller t1 and the channel-group controller configuration commands. Then configure the virtual serial interfaces using the interface serial global configuration commands. See the section "Configure Channelized T1" later in this chapter for T1 configuration tasks, and see the section "Configure Channelized E1" also later in this chapter for E1 configuration tasks.
The following sections show how to configure each interface type. Follow the interface command with the routing or bridging interface configuration commands for your particular protocol or application, as described in this chapter and subsequent chapters.
See the section "Enabling Interface Configuration Examples" at the end of this chapter.
Configure an Asynchronous Serial Interface
To configure an asynchronous serial interface on a routing device, you must set up the interface to send SLIP or PPP packets. PPP and SLIP define methods of sending Internet packets over a standard EIA-232 asynchronous serial line. PPP also defines methods for sending IPX and ARA packets during PPP sessions.
Asynchronous Serial Task List
To configure an asynchronous interface so you can connect to an asynchronous device on the network, complete the tasks in the following sections:
•
Specify an Asynchronous Serial Interface
•
Configure Asynchronous Serial Encapsulation
•
Configure Dedicated or Interactive Mode
•
Enable Routing on the Asynchronous Interface
•
Configure Group and Member Asynchronous Interfaces
Note
You can also configure support for SLIP and PPP using extended BOOTP requests. See the chapter entitled "Loading System Images, Microcode Images, and Configuration Files" in this publication.
Specify an Asynchronous Serial Interface
On an access server, you can configure any of the available asynchronous interfaces (1 through 8 on the Cisco 2509 and 2510, 1 through 16 on the Cisco 2511 and 2512, or 1 through 48 on the AS5100). The auxiliary (labeled AUX on the back of the product) port can also be configured as an asynchronous serial interface, although performance on the AUX port is much slower than on standard asynchronous interfaces and does not support some features. illustrates why asynchronous interfaces permit substantially better performance than AUX ports configured as asynchronous interfaces.
Table 1 Differences between Auxiliary (AUX) Port and Asynchronous Port
Feature
|
Asynchronous Interface
|
Auxiliary Port
|
Maximum speed
|
115200 kbps
|
38400 kbps
|
Supported Platforms
|
Cisco 2509, 10, 11, 12, AS5100, Cisco 1001
|
All Cisco routers
|
Supports DMA buffering1
|
Yes
|
No
|
PPP framing on chip2
|
Yes
|
No
|
IP fast switching3
|
Yes
|
No
|
On routers without built-in asynchronous interfaces, only the AUX port can be configured as an asynchronous serial interface. To configure the AUX port as an asynchronous interface, you must also configure it as an auxiliary line with the line aux 1 command as described in the chapter "Configuring Terminal Lines and Modem Support" in the Access Services Configuration Guide. Access servers do not have this restriction.
Use the line command with the appropriate line configuration commands for modem control, such as speed. Perform the following task in global configuration mode to specify a port as an asynchronous interface:
Task
|
Command
|
Specify an asynchronous serial interface.
|
interface async port-number
|
Configure Asynchronous Serial Encapsulation
There are two asynchronous serial encapsulation methods:
•
Serial Line Internet Protocol (SLIP)
•
Point-to-Point Protocol (PPP)
Only IP packets can be sent across lines configured for SLIP. PPP supports transmission of IP, IPX, and ARA packets on an asynchronous serial interface.
For information about configuring SLIP and PPP, refer to the chapter "Configuring SLIP and PPP" in the Access Services Configuration Guide.
Configure Dedicated or Interactive Mode
You can configure the asynchronous interface to be in dedicated network or interactive mode.
In dedicated mode, there is no user prompt or EXEC level, so no end-user commands are required to place the line into interface mode. When the interface is configured for dedicated mode, the user cannot change the encapsulation method, address, or other parameters.
To configure an asynchronous interface to be in dedicated network mode, perform the following task in interface configuration mode:
Task
|
Command
|
Place the asynchronous line into dedicated network mode.
|
async mode dedicated
|
For an example of placing an asynchronous interface into dedicated network mode, see the section "Dedicated Asynchronous Interface Example" at the end of this chapter.
Alternatively, you can configure an asynchronous line for interactive mode. In interactive mode, the line can be used to make any type of connection, depending on the EXEC command entered by the user. For example, depending on its configuration, the line could be used for Telnet connections, or SLIP or PPP encapsulation. Perform the following task in interface configuration mode to configure an asynchronous line for interactive mode:
Task
|
Command
|
Place the asynchronous line in interactive mode.
|
async mode interactive
|
Enable Routing on the Asynchronous Interface
To enable dynamic routing protocols on asynchronous interfaces, perform the following task in interface configuration mode:
Task
|
Command
|
Configure an asynchronous interface for routing.
|
async dynamic routing
|
Configure Group and Member Asynchronous Interfaces
You can create an asynchronous interface to be used as a group interface, which can be associated with other, member asynchronous interfaces.
This association allows you to configure the group interface and all of its member interfaces with a single command entered at the asynchronous group interface command line. You can have more than one group interface on a device; however, a member interface can be associated with only one group.
See the "Group and Member Asynchronous Interfaces Examples" section at the end of this chapter for an example of group and member interfaces.
illustrates the group-member interface concept.
Figure 1 Group-Member Association on Asynchronous Interfaces
Create the Group Interface and the Member Interfaces
To create an asynchronous group interface and associate member interfaces to this group interface, perform the following commands starting in global configuration mode:
Task
|
Command
|
Create an asynchronous group interface.
|
interface group-async unit-number
|
Associate one or more asynchronous interfaces (members) to the group interface so that all associated interfaces can be configured through the group interface.
|
group-range low-end-of-range high-end-of-range
|
Refer to the "Group and Member Asynchronous Interfaces Examples" section in this chapter for an example configuration.
Define Member Asynchronous Interface Characteristics
Member interfaces can have certain interface configurations that differ from their group. The following are valid interface configuration commands:
•
async default ip address
•
description
To configure a member with two or more interface configurations that are different from its group, enter the following command in interface configuration mode, where interface-command is one of the commands listed in the preceding list:
Task
|
Command
|
Configure a member to have specific differences from its group.
|
member interface-number interface-command
|
Configure an ATM Interface
See the "Configuring ATM" chapter in the Wide-Area Networking Configuration Guide for information on how to configure an Asynchronous Transfer Mode (ATM) interface.
See also the section "Invoke ATM over a Serial Line" in the section "Configure a Synchronous Serial Interface" in this chapter.
Configure Channelized E1
Support for channelized E1 is provided on the following platforms:
•
Cisco 7000 series—by means of a MultiChannel Interface Processor (MIP) and a channelized E1 adapter. The MIP, which can be installed in any Cisco 7000 family router, can support one or two channelized E1 adapters.
•
Cisco 4000 series—by means of up to three channelized E1 controllers, each providing one physical interface (adapter) to the network when running as a channelized interface card. (When used to run ISDN PRI, only one Network Processor Module (NPM) can be used in the Cisco 4000 and two NPMs can be used in the Cisco 4500 or Cisco 4700.)
Each E1 adapter can support a maximum of 30 channel groups. The Cisco 7000 family MIP can support one or two adapters, providing a maximum of 60 channel groups per MIP. The Cisco 4000 series can support one adapter, providing a maximum of 30 channel groups. Each channel group is presented to the system as a serial interface that can be configured individually. In effect, up to 30 E1 circuits are multiplexed to each hardware adapter.
Use the show controllers e1 EXEC command to display current E1 status. This command provides a report for each physical interface configured to support channelized E1.
Channelized E1 supports the following WAN protocols:
•
X.25
•
LAPB
•
Frame Relay
•
PPP
•
HDLC
•
SMDS
•
ATM-DXI
When a channelized E1 adapter is used for ISDN PRI, it can support DDR; when it is not used for ISDN PRI, it does not support DDR. Refer to the "Configuring ISDN" chapter in the Wide-Area Networking Configuration Guide for more information.
Channelized E1 Task List
Using channelized E1 controller and serial interface configuration commands, you can perform the tasks in the following sections to configure channelized E1:
•
Configure the E1 Controller
•
Define the Line Code
•
Define the Framing Characteristics
•
Define the E1 Channel Groups
•
Configure the Channelized E1 Channel Groups
See the end of this chapter for "Interface Configuration Examples."
Configure the E1 Controller
To configure the E1 physical characteristics, you first define the location of the controller in the router. A Cisco 7000 router can have up to four MIPs, and a Cisco 7010 router can have up to three MIPs. Each MIP provides one or two E1 ports. The Cisco 4000 series routers can support up to three network processor module (NPM) cards, each with one interface when running it as a channelized interface card. However, when the card is used to run ISDN PRI, only one NPM can be used in the Cisco 4000 and two NPMs can be used in the Cisco 4500.
Note
You can define ISDN PRI groups and channel groups on the same controller. However, you cannot overlap time slots or use the ISDN D channel time slot in a channel group.
Perform the following task in global configuration mode to define the E1 controller and to enter controller configuration mode:
Task
|
Command
|
Define the controller location in the Cisco 7000 series by slot and port number.
or
Define the controller location in the Cisco 4000 series by unit number, ranging from 0 through 2.
|
controller e1 slot/port
controller e1 number
|
Define the Line Code
Perform the following task in controller configuration mode to define the line code as either alternate mark inversion (AMI) or HDB3:
Task
|
Command
|
Define the line code as either AMI or HDB3; HDB3 is the default.
|
linecode {ami | hdb3}
|
Contact your local telephone service provider to determine the line-code requirements of the physical E1 line. The E1 controller values must match the service provided by the telephone company.
Define the Framing Characteristics
Perform the following task in controller configuration mode to define the framing characteristics as either CRC4 or no-CRC4, or as the version of E1 framing used in Australia only:
Task
|
Command
|
Define the framing characteristics as either CRC4 or no-CRC4.
|
framing {crc4 | no-crc4} [australia]
|
Contact your local telephone service provider to determine the framing requirements of the physical E1 line. The E1 controller values must match the service provided by the telephone company.
Define the E1 Channel Groups
You can define up to 30 DS0 channel groups for each E1 adapter. You must define the time slots that belong with each channel group. Channel groups are numbered 0 to 30, and time slots are numbered 1 to 31. Perform the following task in controller configuration mode to define the channel groups and time slots:
Task
|
Command
|
Define the channel group number and, if needed, circuit speed.
|
channel-group number timeslots range [speed {48 | 56 | 64}]
|
Working with your local service provider, you can create channel-groups with from one to 31 timeslots. These timeslots can be in any order, contiguous or noncontiguous. Channel-group speeds can be 48 kbps, 56 kbps, or 64 kbps; the default is 64 kbps if the speed is not specified. The speed you choose must match the speed specified by your service provider.
Defining a channel group creates a serial interface; defining multiple channel groups creates an equal number of serial interfaces that you can configure independently. The channel group numbers for each E1 controller can be arbitrarily assigned.
Configure the Channelized E1 Channel Groups
After you define the E1 channel groups, you can configure each channel group as a serial interface. In other words, you can think of each channel group as a virtual serial interface. Subinterface configuration on the created interface is also supported. To enter interface configuration mode and configure the serial interface that corresponds to a channel group, perform the following task either in global configuration mode or controller configuration mode:
Task
|
Command
|
Define the serial interface for an E1 channel group.
|
interface serial slot/port:channel-group (Cisco 7000 series)
interface serial number:channel-group (Cisco 4000 series)
|
E1 channel groups support local loopback. You can enable local loopback for specified individual channel groups with the loopback local command. Local loopback loops the entire specified channel group both toward the line and toward the router.
E1 channel groups do not respond to any remote loopback codes. That is, you cannot remotely loop an E1 channel group.
Configure Channelized T1
Support for channelized T1 is provided on the following platforms:
•
Cisco 7000 family by means of a MultiChannel Interface Processor (MIP) and a channelized T1 adapter. The Cisco 7000 family MIP can support one or two channelized T1 adapters.
•
Cisco AS5200 access server
•
Cisco 4000 series by means of a single channelized T1 adapter.
Each T1 adapter can support a maximum of 24 DS0 channel groups. Each channel group is presented to the system as a serial interface that can be configured individually. The Cisco 7000 MIP can support one or two channelized T1 adapters, providing a maximum of 48 channel groups per MIP. The Cisco 4000 supports a one adapter, providing a maximum of 24 channel groups. In effect, up to 24 DS0 circuits are multiplexed to a single hardware adapter.
Use the show controllers t1 EXEC command to display current T1 status. This command provides a report for each physical interface configured to support channelized T1.
Channelized T1 supports the following WAN protocols:
•
X.25
•
LAPB
•
Frame Relay
•
PPP
•
HDLC
•
SMDS
•
ATM-DXI
When a channelized T1 adapter is used for ISDN PRI, it can support DDR; when it is not used for ISDN PRI, it does not support DDR. Refer to the "Configuring ISDN" chapter in the Wide-Area Networking Configuration Guide for more information.
The Cisco channelized T1 controllers require the use of a CSU when connected to a public network. This device should take a T1 signal from the public network and provide a T1 signal to the channelized T1 controller.
Channelized T1 Task List
Using channelized T1 controller and serial interface configuration commands, you can perform the tasks in the following sections to configure channelized T1:
•
Configure the T1 Controller
•
Define the Line Code
•
Define the Framing Characteristics
•
Define the Clock Source
•
Define the T1 Channel Groups
•
Configure the Channelized T1 Channel Groups
See the end of this chapter for "Interface Configuration Examples."
Configure the T1 Controller
To configure the T1 physical characteristics, you first define the physical location of the MIP and E1 port in the Cisco 7000 family router. The Cisco 7000 family of routers provide various numbers of slots for MIPs. Each MIP provides one or two T1 ports. The Cisco 4000 series routers can support up to three network processor module (NPM) cards, each with one interface when running it as a channelized interface card. However, when the card is used to run ISDN PRI, only one NPM can be used in the Cisco 4000 and two NPMs can be used in the Cisco 4500 series.
Note
You can define ISDN PRI groups and channel groups on the same controller. However, you cannot overlap timeslots or use the ISDN D-channel timeslot in a channel group.
Perform the following task in global configuration mode to define the T1 controller and to enter controller configuration mode:
Task
|
Command
|
Define the MIP and CxCT1 locations in the Cisco 7000 series by slot and port number.
or
Define the controller location in the Cisco 4000 series by unit number, ranging from 0 through 2.
|
controller t1 slot/port
or
controller t1 number
|
Define the Line Code
Perform the following task in controller configuration mode to define the line code as either alternate mark inversion (AMI) or bipolar 8 zero substitution (B8ZS):
Task
|
Command
|
Define the line code as either AMI or B8ZS; AMI is the default.
|
linecode {ami | b8zs}
|
Contact your local telephone service provider to determine the line-code requirements of the physical T1 line. The T1 controller values must match the service provided by the telephone company.
Define the Framing Characteristics
Perform the following task in controller configuration mode to define the framing characteristics as either Super Frame (SF) or Extended Super Frame (ESF):
Task
|
Command
|
Define the framing characteristics as either SF or ESF; SF is the default.
|
framing {sf | esf}
|
Contact your local telephone service provider to determine the framing requirements of the physical T1 line. The T1 controller values must match the service provided by the telephone company.
Define the Clock Source
Under normal usage, skip this step. You must define the clock source only when connecting two devices back-to-back for testing purposes. The clock source normally comes from the T1 line rather than from the router interface, but when you connect two routers back-to-back for testing purposes, one device supplies an internal clock source. To define the clock source, perform the following task in controller configuration mode:
Task
|
Command
|
Define the clock source if you are connecting two cards back-to-back for testing purposes; the default source is the line.
|
clock source {line | internal}
|
Define the T1 Channel Groups
You can define up to 24 channel groups for each T1 adapter.You must define the timeslots that belong with each channel group. Channel groups are numbered 0 to 23, and timeslots are numbered 1 to 24. Perform the following task in controller configuration mode to define the channel groups and timeslots:
Task
|
Command
|
Define the channel group number and, if needed, circuit speed.
|
channel-group number timeslots range [speed {48 | 56 | 64}]
|
Working with your local service provider, you can create channel-groups with from one to 24 timeslots. These timeslots can be in any order, contiguous or noncontiguous. In the United States, channel-group speeds can be either 56 kbps or 64 kbps; the default is 56 kbps. If 64 kbps is used, it is recommended to be used with framing type of ESF and a linecode of B8ZS. The speed you select must match the speed provided by the telephone company.
Defining a channel group creates a serial interface; defining multiple channel groups creates an equal number of serial interfaces that you can configure independently. The channel group numbers for each T1 controller can be arbitrarily assigned.
Configure the Channelized T1 Channel Groups
After you define the T1 channel groups, you can configure each channel group as a serial interface. In other words, you can think of each channel group as a virtual serial interface. Subinterface configuration is also supported on the created serial interface. Perform the following task either in global configuration mode or controller configuration mode to enter interface configuration mode and configure the serial interface that corresponds to a channel group:
Task
|
Command
|
Define the serial interface for a T1 channel group.
|
interface serial slot/port:channel-group (Cisco 7000 series)
interface serial number:channel-group (Cisco 4000 series)
|
Troubleshooting Channelized E1 and Channelized T1
When troubleshooting channelized T1 or E1, you must first decide if the problem is with a particular channel group, or with the T1 or E1 line.
If the problem is with a single channel group, you have an potential interface problem.
If the problem is with the T1 or E1 line, or with all channel groups, you have a potential controller problem.
Troubleshooting Channelized T1/E1 Controllers
When you troubleshoot E1 or T1 controllers, first check that the configuration is correct. The framing type and line code should match to what the service provider has specified. Then check channel group and PRI-group configurations, especially to verify that the timeslots and speeds are what the service provider has specified.
At this point, the show controller t1 or show controller e1 commands should be used to check for T1 or E1 errors. Use the command several times to determine if error counters are increasing, or if the line status is continually changing. If this is occurring, you need to work with the service provider.
Note
Cisco routers do not have CSU capability and do not react to any remote loopback codes at the T1 or E1 level.
Channelized T1 Controller Loopbacks
For the T1 controller, two loopbacks are available for testing:
•
Local loopback
•
Remote loopback
Local Loopback: The local loopback loops the controller both toward the router, and toward the line. Since the loopback is done internally to the router, the controller should transition to the UP state within approximately 10 seconds, and no further T1 errors should be detected.
All channel groups will be looped back; if the encapsulation on that channel group supports loopbacks (for example, HDLC and PPP), you can test that channel group by pinging the interface address. For example, if you have assigned an IP address to the serial interface defined for a channel group, you can ping that IP address.
To place the controller into local loopback, perform the following task in controller configuration mode.
Task
|
Command
|
Loop the T1 controller toward the router and toward the line.
|
loopback local (controller)
|
To test a channel group, perform the following task in EXEC mode:
Ping the interface address.
|
ping protocol protocol-address
|
Check errors by performing the following task in EXEC mode:
Check errors.
|
show controller t1
|
If any errors occur, or the controller fails to change to the UP state, please contact the Cisco TAC.
Since the controller local loopback is bidirectional, the service provider can test the line integrity using a T1 BERT test set.
Remote Loopback: The second T1 controller loopback is a remote loopback. This loopback can be used only if the entire T1 goes to a remote CSU. This is not the case with 99.9% of channelized T1. When the loopback remote controller command is executed, an inband CSU loop-up code will be sent over the entire T1, which will attempt to loop up the remote CSU. To place the controller in remote loopback, perform the following task in controller configuration mode:
Task
|
Command
|
Place the T1 controller in remote loopback.
|
loopback remote (controller)
|
Note
If controller loopbacks are used, they will disrupt service for all channel groups on that interface.
Channelized E1 Controller Loopback
For the E1 controller, only the local loopback is available. Local loopback operates the same as the local loopback on the T1 controller, forming a bidirectional loopback, both toward the router, and toward the line.To place the E1 controller in local loopback, perform the following task in controller configuration mode:
Task
|
Command
|
Place the E1 controller in local loopback toward the router and toward the line.
|
loopback (controller)
|
All channel groups will be looped back; if the encapsulation on that channel group supports loopbacks (for example, HDLC and PPP), you can test that channel group by pinging the interface address. For example, if you have assigned an IP address to the serial interface defined for a channel group, you can ping that IP address.
To place the controller into local loopback, perform the following task in controller configuration mode.
Task
|
Command
|
Loop the T1 controller toward the router and toward the line.
|
loopback local (controller)
|
To test a channel group, perform the following task in EXEC mode:
Ping the interface address.
|
ping protocol protocol-address
|
Check errors if any. by performing the following task in EXEC mode:
Check errors.
|
show controller t1
|
If any errors occur, it is most likely a hardware problem; please contact the Cisco TAC. At the same time, the service provider can test the line by using a T1 BERT test set.
Troubleshooting Channelized T1/E1 Channel Groups
Each channelized T1 or channelized E1 channel group is treated as a separate serial interface. To troubleshoot channel groups, first verify configurations and check everything that is normally checked for serial interfaces. You can verify that the timeslots and speed are correct for the channel group by checking for CRC errors and aborts on the incoming line.
Channelized T1/E1 Channel Group Loopbacks
Note
None of the Cisco channelized interfaces will react to any loop codes. To loop a channelized interface requires that the configuration command be entered manually.
Two loopbacks are available for channel groups:
•
Interface local loopback
•
Interface remote loopback
Interface Local Loopback: Interface local loopback is a bidirectional loopback, which will loopback toward the router and toward the line. The entire set of timeslots for the channel group are looped back. The service provider can use a BERT test set to test the link from the central office to your local router, or the remote router can test using pings to their local interface (which will go from the remote site, looped back at your local site, and return to the interface on the remote site).
To place the serial interface (channel group) into local loopback, perform the following task in interface configuration mode:
Task
|
Command
|
Place the serial interface (channel group) in local loopback.
|
loopback local
|
Interface Remote Loopback: Remote loopback is the ability to put the remote DDS CSU/DSU in loopback. It will work only with channel groups that have a single DS0 (1 timeslot), and with equipment that works with a latched CSU loopback as specified in AT&T specification TR-TSY-000476, "OTGR Network Maintenance Access and Testing." To place the serial interface (channel group) in remote loopback, perform the following task in interface configuration mode:
Task
|
Command
|
Place the serial interface (channel group) in remote loopback.
|
loopback remote (interface)
|
Using the loopback remote interface command sends a latched CSU loopback command to the remote CSU/DSU. The router must detect the response code, at which time the remote loopback is verified.
Configure Channelized T1 on the Cisco AS5200
The Cisco AS5200 Universal Access Server is an ISDN-capable access server that can make and receive ISDN and analog calls from remote clients needing access to network resources. The Cisco AS5200 has two T1 controllers, which can be configured individually.
On a Cisco AS5200, you can allocate the 24 available channels for channelized T1 in the following four ways:
1
All 24 channels can be configured to support ISDN PRI.
2
If you are not running PRI ISDN, all channels can be configured to support channel-associated signaling (also known as robbed-bit signaling), which enables an AS5200 modem to receive and make analog calls.
3
All 24 channels can be configured in a single channel group.
4
Mix and match channels supporting PRI ISDN, robbed bit signalling, and channel grouping across the same T1 line.
For example, on the same channelized T1 you can configure the pri-group timeslots 1-10 command, channel-group 11 timeslots 11-16 command, and cas-group 17 timeslots 17-23 command. This is a rare configuration requires you to align the correct range of timeslots on both ends of the connection.
To configure the T1 controllers in the Cisco AS5200, perform the tasks in the following sections:
•
Configure the T1 Controllers to Make and Receive Calls
•
Configure the ISDN D-Channel Serial Interfaces
Configure the T1 Controllers to Make and Receive Calls
Set parameters for a T1 controller to make and receive calls. To do so, perform the following steps beginning in global configuration mode:
Task
|
Command
|
Step 1 Enable the T1 0 controller, and enter controller configuration mode.
|
controller t1 0
|
Step 2 If the channelized T1 line connects to a smart jack instead of a CSU, set pulse equalization (use parameter values specified by your telco).
|
cablelength long dbgain-value dbloss-value
|
Step 3 Set the framing to match your telco's offering, which in most cases is esf.
|
framing esf
|
Step 4 Set the line code type to match your telco's offering, which in most cases is b8zs.
|
linecode b8zs
|
Step 5 Configure one T1 line to serve as the primary or most stable clock source line.
|
clock source line primary 1
|
Step 6 Configure channels on this T1 controller for ISDN PRI. or If you are not running ISDN, configure channels to accept voice calls. or If you are not running ISDN, configure channels for synchronous serial communications.
This step creates interfaces that you can configure.
|
pri-group timeslots 1-24
cas-group 1 timeslots 1-24
channel-group 1 timeslots 1-24
|
Step 7 Set the facilities data link exchange standard for the CSU, as specified by your service provider.
|
fdl {att | ansi}
|
Repeat Steps 1 through 7 to configure T1 controller 1, making sure in Step 5 to select T1 controller 1's line as the secondary clock source. You do not have to configure the timeslots in the same way on the two T1 controllers. You can configure the timeslots on this second controller as needed, no matter how you configured the timeslots in T1 controller 0.
Configure the ISDN D-Channel Serial Interfaces
Once you create the interfaces, two corresponding D channel serial interfaces are automatically created. Serial interface 0:23 is the D channel for T1 controller 0, and serial interface 1:23 is the D channel for T1 controller 1. You must configure each serial interface to receive and make calls.
To configure an ISDN D-Channel serial interface, perform the following steps beginning in global configuration mode:
Task
|
Command
|
Step 1 Specify the D channel of the first PRI line.
|
interface serial 0:23
|
Step 2 Configure all incoming voice calls to go to the Cisco AS5200's integrated modems.
|
isdn incoming-voice modem 1 , 2
|
Step 3 Assign this interface to a dialer interface. The dialer interface's protocol characteristics apply to each interface assigned to it.
|
dialer rotary-group number 3
|
Repeat Steps 1 through 3 for serial interface 1:23, which is the D channel on the second T1 controller.
Configure CSU/DSU Service Modules (Cisco 2524 and Cisco 2525)
This section describes how to configure CSU/DSU service modules on Cisco 2524 and Cisco 2525 routers. It describes these tasks in the following sections:
•
Configure Fractional T1/T1 CSU/DSU Service Modules
•
Configure 2-Wire and 4-Wire 56/64-kbps CSU/DSU Service Modules
See the "CSU/DSU Service Module (Cisco 2524 and 2525) Examples" section and its subsections for service module examples.
See the "Monitor and Maintain CSU/DSU Service Modules" section for monitoring, maintenance, and loopback test information.
Configure Fractional T1/T1 CSU/DSU Service Modules
This section describes how to configure fractional T1 and T1 (FT1/T1) service modules installed on Cisco 2524 and Cisco 2525 routers. This section describes the following tasks:
•
Specify the Clock Source
•
Enable Data Inversion Before Transmission
•
Specify the Frame Type of a FT/T1 Line
•
Specify the CSU Line Build Out
•
Specify FT1/T1 Line-Code Type
•
Enable Remote Alarms
•
Enable Loopcodes that Initiate Remote Loopbacks
•
Specify Timeslots
Specify the Clock Source
To specify the clock source for the FT1/T1 CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Specify the clock source, for the CSU/DSU internal clock or the line clock.
|
service-module t1 clock source {internal | line}
|
Enable Data Inversion Before Transmission
Data inversion is used to guarantee the ones density requirement on an AMI line when using bit-oriented protocols such as High-Level Data Link Control (HDLC), Point-to-Point Protocol (PPP), X.25, and Frame Relay.
To guarantee the ones density requirement on an AMI line using the FT1/T1 CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Invert bit codes by changing all 1 bits to 0 bits and all 0 bits to 1 bits.
|
service-module t1 data-coding inverted
|
If the timeslot speed is set to 56 kbps, this command is rejected because line density is guaranteed when transmitting at 56 kbps. Use this command with the 64 kbps line speed. If you transmit inverted bit codes, both CSU/DSUs must have this command configured for successful communication.
To enable normal data transmission on a FT1/T1 network, perform the following task in interface configuration mode:
Task
|
Command
|
Enable normal data transmission on a T1 network.
|
service-module tx1 data-coding normal
or
no service-module t1 data-coding inverted
|
Specify the Frame Type of a FT/T1 Line
To specify the frame type for a line using the FT1/T1 CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Specify a FT1/T1 frame type. Choose either D4 Super Frame (sf) or Extended Super Frame (esf).
|
service-module t1 framing {sf | esf}
|
In most cases, the service provider determines which framing type, either esf or sf, is required for your circuit.
Specify the CSU Line Build Out
To decrease the outgoing signal strength to an optimum value for the telecommunication carrier network, perform the following task on the FT1/T1 CSU/DSU module in interface configuration mode:
Task
|
Command
|
Decrease the outgoing signal strength in decibels.
|
service-module t1 lbo {-15 db | -7.5 db}
|
To transmit packets without decreasing outgoing signal strength, perform the following task in interface configuration mode:
Task
|
Command
|
Transmits packets without decreasing outgoing signal strength.
|
service-module t1 lbo none
|
The ideal signal strength should be between -15 dB and -22 dB, which is calculated by adding the phone company loss + cable length loss + line build out.
You may use this command in back-to-back configurations, but it is not needed on most actual T1 lines.
Specify FT1/T1 Line-Code Type
To configure the line code for the FT1/T1 CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Specify a line-code type. Choose alternate mark inversion (AMI) or binary 8 zero substitution (B8ZS).
|
service-module t1 linecode {ami | b8zs}
|
Configuring B8ZS is a method of ensuring the ones density requirement on a T1 line by substituting intentional bipolar violations in bit positions four and seven for a sequence of eight zero bits. When the CSU/DSU is configured for AMI, you must guarantee the ones density requirement in your router configuration using the service-module t1 data-coding inverted command or the service-module t1 timeslots speed 56 command.
In most cases, your T1 service provider determines which line-code type, either ami or b8zs, is required for your T1 circuit.
Enable Remote Alarms
To generate remote alarms (yellow alarms) at the local CSU/DSU or detect remote alarms sent from the remote CSU/DSU, perform the following task in interface configuration mode:
Task
|
Command
|
Enable remote alarms.
|
service-module t1 remote-alarm-enable
|
Remote alarms are transmitted by the CSU/DSU when it detects an alarm condition, such as a red alarm (loss of signal) or blue alarm (unframed 1's). The receiving CSU/DSU then knows there is an error condition on the line.
With D4 super frame configured, a remote alarm condition is transmitted by setting the bit 2 of each time slot to zero. For received user data that has the bit 2 of each time slot set to zero, the CSU/DSU will interpret the data as a remote alarm and interrupt data transmission, which explains why remote alarms are disabled by default. With Extended Super Frame configured, the remote alarm condition is signalled out of band in the facility data link.
You can see if the FT1/T1 CSU/DSU is receiving a remote alarm (yellow alarm) by issuing the show service-module command.
To disable remote alarms, perform the following task in interface configuration mode:
Task
|
Command
|
Disable remote alarms.
|
no service-module t1 remote-alarm-enable
|
Enable Loopcodes that Initiate Remote Loopbacks
To specify if the fractional T1/T1 CSU/DSU module goes into loopback when it receives a loopback code on the line, perform the following task in interface configuration mode:
Task
|
Command
|
Configures the remote loopback code used to transmit or accept CSU loopback requests.
|
service-module t1 remote-loopback full
|
Configures the loopback code used by the local CSU/DSU to generate or detect payload-loopback commands.
|
service-module t1 remote-loopback payload [alternate | v54]
|
Note
By entering the service-module t1 remote-loopback command without specifying any keywords, you enable the standard-loopup codes, which use a 1-in-5 pattern for loopup and a 1-in-3 pattern for loopdown.
You can simultaneously configure the full and payload loopback points. However, only one loopback payload code can be configured at a time. For example, if you configure the service-module t1 remote-loopback payload alternate command, a payload v.54 request, which is the industry standard and default, cannot be transmitted or accepted. Full and payload loopbacks with standard-loopup codes are enabled by default.
The no form of this command disables loopback requests. For example, the no service-module t1 remote-loopback full command ignores all full-bandwidth loopback transmissions and requests. Configuring the no form of the command may not prevent telco line providers from looping your router in esf mode, because fractional T1/T1 telcos use facilities data-link messages to initiate loopbacks.
If you enable the service-module t1 remote-loopback command, the loopback remote commands on the FT1/T1 CSU/DSU module will not be successful.
Specify Timeslots
To define timeslots for FT1/T1 module, perform the following task in interface configuration mode:
Task
|
Command
|
Specify timeslots.
|
service-module t1 timeslots {range | all} [speed {56 | 64}]
|
This command specifies which timeslots are used in fractional T1 operation and determines the amount of bandwidth available to the router in each timeslot.
The range specifies the DS0 timeslots that constitute the FT1/T1 channel. The range is from 1 to 24, where the first timeslot is numbered 1 and the last timeslot is numbered 24. Specify this field by using a series of subranges separated by commas. The timeslot range must match the timeslots assigned to the channel group. In most cases, the service provider defines the timeslots that comprise a channel group. Use the no form of this command to select all FT1/T1 timeslots transmitting at 64 kbps, which is the default.
To use the entire T1 line, enable the service-module T1 timeslots all command.
Configure 2-Wire and 4-Wire 56/64-kbps CSU/DSU Service Modules
This section describes how to configure 2- and 4-wire 56/64 kbps service modules. The following tasks are described:
•
Set the Clock Source
•
Set the Network Line Speed
•
Enable Scrambled Data Coding
•
Change between Digital Data Service and Switched Dial-Up Modes
•
Enable Acceptance of a Remote Loopback Request
•
Select a Service Provider
Set the Clock Source
In most applications, the CSU/DSU should be configured with the service-module 56k clock source line command. For back-to-back configurations, use the internal keyword to configure one CSU/DSU and use the line keyword to configure the other CSU/DSU.
To configure the clock source for a 4-wire 56/64-kbps CSU/DSU module, perform the following task:
Task
|
Command
|
Configure the clock source.
|
service-module 56k clock source {line | internal}
|
Use the no form of this command to revert to the default clock source, which is the line clock.
Set the Network Line Speed
To configure the network line speed for a 4-wire 56/64-kbps CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Set the network line speed.
|
service-module 56k clock rate line-speed
|
You can use the following line speed settings: 2.4, 4.8, 9.6, 19.2, 38.4, 56, 64 kpbs, and an auto setting.
The 64-kbps line speed cannot be used with back-to-back digital data service (DDS) lines. The subrate line speeds are determined by the service provider.
Only the 56-kbps line speed is available in switched mode. Switched mode is the default on the 2-wire CSU/DSU and is enabled by the service-module 56k network-type interface configuration command on the 4-wire CSU/DSU.
The auto linespeed setting enables the CSU/DSU to decipher current line speed from the sealing current running on the network. Because back-to-back DDS lines do not have sealing current, use the auto setting only when transmitting over telco DDS lines and using the line clock as the clock source.
Use the no form of this command to enable a network line speed of 56 kbps, which is the default.
Enable Scrambled Data Coding
To prevent application data from replicating loopback codes when operating at 64-kbps on a 4-wire CSU/DSU, perform the following task in interface configuration mode:
Task
|
Command
|
Scramble bit codes before transmission.
|
service-module 56k data-coding scrambled
|
Enable the scrambled configuration only in 64-kbps digital data service (DDS) mode. If the network type is set to switched, the configuration is refused.
If you transmit scrambled bit codes, both CSU/DSUs must have this command configured for successful communication.
To enable normal data transmission for the 4-wire 56/64-kbps module, perform the following task, which is the default, in interface configuration mode:
Task
|
Command
|
Specify normal data transmission.
|
service-module 56k data-coding normal
or
no service-module 56k data-coding
|
Change between Digital Data Service and Switched Dial-Up Modes
To transmit packets in Digital Data Service (DDS) mode or switched dial-up mode using the 4-wire 56/64-kbps CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Transmit packets in switched dial-up mode or DDS mode.
|
service-module 56k network-type dds
or
service-module 56k network-type switched
|
Use the no form of these commands to transmit from a dedicated leased line in DDS mode. DDS is enabled by default for the 4-wire CSU/DSU. Switched is enabled by default for the 2-wire CSU/DSU.
In switched mode, you need additional dialer configuration commands to configure dial-out numbers. Before you enable the service-module 56k network-type switched command, both CSU/DSU's must use a clock source coming from the line and the clock rate configured to auto or 56k kbps. If the clock rate is not set correctly, this command will not be accepted.
The 2-wire and 4-wire 56/64-kbps CSU/DSU modules use V.25 bis dial commands to interface with the router. Therefore, the interface must be configured using the dialer in-band command. DTR dial is not supported.
Note
Any loopbacks in progress are terminated when switching between modes.
Enable Acceptance of a Remote Loopback Request
To enable the acceptance of a remote loopback request on a 2- or 4-wire 56/64-kbps CSU/DSU module, perform the following task in interface configuration mode:
Task
|
Command
|
Enable a remote loopback request.
|
service-module 56k remote-loopback
|
The no service-module 56k remote-loopback command prevents the local CSU/DSU from being placed into loopback by remote devices on the line. Unlike the T1 module, the 2- or 4-wire 56/64-kbps CSU/DSU module can still initiate remote loopbacks with the no form of this command configured.
Select a Service Provider
To select a service provider to use with a 2- or 4-wire 56/64 kbps dial-up line, perform the following task in interface configuration mode:
Task
|
Command
|
Select a service provider for a 2 or 4 wire switched 56/64 kbps dialup line.
|
service-module 56k switched-carrier {att | other | sprint}
|
The att keyword specifies AT&T or another digital network service provider as the line carrier, which is the default for the 4-wire 56/64-kbps CSU/DSU module. The sprint keyword specifies Sprint or another service provider whose network carries mixed voice and data as the line carrier, which is the default for the 2-wire switched 56-kbps CSU/DSU module.
In a Sprint network, echo-canceler tones are sent during call setup to prevent echo cancelers from damaging digital data. The transmission of these cancelers may increase call setup times by 8 seconds on the 4-wire module. Having echo cancellation enabled does not affect data traffic.
This configuration command is ignored if the network type is DDS.
Use the no form of this command to enable the default service provider. AT&T is enabled by default on the 4-wire 56/64 module. Sprint is enabled by default on the 2-wire switched 56 module.
Configure a Dialer Interface
See the chapter "Configuring DDR" in the Wide-Area Networking Configuration Guide for information about how to configure a dialer interface.
Configure an Ethernet or Fast Ethernet Interface
Cisco Supports both 10 Mbps Ethernet and 100 Mbps Fast Ethernet.
Support for the 10 Mbps Ethernet interface is supplied on one of the following Ethernet network interface cards or systems:
•
The Multiport Communications Interface (MCI) card in the modular routers, which provides one Ethernet connector compatible with Ethernet Versions 1 and 2 and the IEEE 802.3 protocol.
•
An integrated Ethernet controller on the Cisco 2500 series and Cisco 3000 models.
•
An integrated Ethernet controller on the Cisco 1003 model.
•
On the Cisco 4000 series, a 1-port, 2-port, or 6-port Ethernet network processor module (NPM).
•
On the Cisco 7000 and 7500 series, the Ethernet interface processor (EIP) for two, four, or six ports. The EIP ports are in compliance with Ethernet versions 1 and 2 and the IEEE 802.3 specifications.
•
On the Cisco 7200 series, the 4- or 8-port 10BASE-T Ethernet adapter and the 5-port 10BASE-FL Ethernet adapter.
Support for the 100 Mbps Fast Ethernet interface is supplied on the following cards and systems:
•
On Cisco 4500 (Cisco 4500, Cisco 4500-M, Cisco 4700, and Cisco 4700-M) routers, a Fast Ethernet network processor module (NPM)
•
On the Cisco 7000, Cisco RSP/7000, and Cisco 7500, the Fast Ethernet Interface Processor (FEIP)
•
On the Cisco 7000 and 7200 series routers with a Versatile Interface Processor (VIP), the 100Base-TX Ethernet port adapter
•
On the Cisco 7200 series routers with a second-generation Versatile Interface Processor (VIP2), a 1-port 100BASE-TX Fast Ethernet port adapter and a 1-port 100BASE-FX Fast Ethernet port adapter
Use the show interfaces, show controllers mci, and show controllers cbus EXEC commands to display the Ethernet port numbers. These commands provide a report for each interface supported by the router or access server.
Use the show interface fastethernet command to display interface statistics, and use the show controller fastethernet to display the information about the fastethernet controller chip. The output shows the information about initialization block information, transmit ring, receive ring and errors.
Ethernet Interface Task List
Perform the tasks in the following sections to configure features on an Ethernet interface. The first task is required; the remaining tasks are optional.
•
Specify an Ethernet or Fast Ethernet Interface
•
Specify Ethernet Encapsulation Method
•
Specify the Media and Connector Type (Cisco 4000)
•
Extend the 10BaseT Capability (Cisco 4000 and Cisco 4500 only) (Does not apply to the FastEthernet interface)
Specify an Ethernet or Fast Ethernet Interface
To specify an Ethernet interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface ethernet number
|
Begin interface configuration for the Cisco 7000 and 7200 series.
|
interface ethernet slot/port
|
Begin interface configuration for Cisco 7500 series.
|
interface ethernet slot/port-adapter/port
|
Begin interface configuration for the Cisco 4000 series with a Fast Ethernet NIM installed.
|
interface fastethernet number
|
Specify a Fast Ethernet interface and enter interface configuration mode on the Cisco 7000 series or the Cisco 7200 series.
|
interface fastethernet slot/port
|
Specify a Fast Ethernet interface and enter interface configuration mode on the Cisco 7500.
|
interface fastethernet slot/port-adapter/port
|
Use the show interfaces fastethernet command to display the Fast Ethernet slots and ports. The Fast Ethernet NIM and the FEIP default to half-duplex mode.
Specify Ethernet Encapsulation Method
Currently, there are three common Ethernet encapsulation methods:
•
The standard ARPA Ethernet Version 2.0 encapsulation, which uses a 16-bit protocol type code (the default encapsulation method)
•
SAP IEEE 802.3 encapsulation, in which the type code becomes the frame length for the IEEE 802.2 LLC encapsulation (destination and source Service Access Points, and a control byte)
•
The SNAP method, as specified in RFC 1042, which allows Ethernet protocols to run on IEEE 802.2 media
The encapsulation method you use depends upon the type of Ethernet media connected to the router or access server and the routing or bridging application you configure. Establish Ethernet encapsulation by performing one of the following tasks in interface configuration mode:
Task
|
Command
|
Select ARPA Ethernet encapsulation.
|
encapsulation arpa
|
Select SAP Ethernet encapsulation.
|
encapsulation sap
|
Select SNAP Ethernet encapsulation.
|
encapsulation snap
|
For an example of selecting Ethernet encapsulation, see the section "Enabling Ethernet Encapsulation Example" at the end of this chapter. See also the chapters describing specific protocols or applications.
Specify the Media and Connector Type (Cisco 4000)
You can specify that the Ethernet network interface module (NIM) on the Cisco 4000 uses either an AUI and a 15-pin connector, or 10BaseT and an RJ45 connector. To do so, perform one of the following tasks in interface configuration mode:
Task
|
Command
|
Select a 15-pin Ethernet connector.
|
media-type aui
|
Select an RJ45 Ethernet connector.
|
media-type 10baset
|
Extend the 10BaseT Capability (Cisco 4000 and Cisco 4500 only)
On a Cisco 4000 or Cisco 4500, you can extend the twisted-pair 10BaseT capability beyond the standard 100 meters by reducing the squelch (signal cutoff time). This feature applies only to the LANCE controller 10BaseT interfaces. LANCE is the AMD controller chip for the Cisco 4000 and Cisco 4500 Ethernet interface.
To reduce squelch, perform the first task that follows in interface configuration mode. You can later restore the squelch by performing the second task.
Task
|
Command
|
Reduce the squelch.
|
squelch reduced
|
Return squelch to normal.
|
squelch normal
|
Configure a Fiber Distributed Data Interface (FDDI)
The Fiber Distributed Data Interface (FDDI) is an ANSI-defined standard for timed 100-Mbps token passing over fiber-optic cable. FDDI is not supported on access servers.
An FDDI network consists of two counter token-passing fiber-optic rings. On most networks, the primary ring is used for data communication and the secondary ring is used as a hot standby. The FDDI standard sets a total fiber length of 200 kilometers. (The maximum circumference of the FDDI network is only half the specified kilometers because of the wrapping or looping back of the signal that occurs during fault isolation.)
The FDDI standard allows a maximum of 500 stations with a maximum distance between active stations of two kilometers when interconnecting them with multimode fiber or ten kilometers when interconnected via single mode fiber, both of which are supported by our FDDI interface controllers. The FDDI frame can contain a minimum of 17 bytes and a maximum of 4500 bytes. Our implementation of FDDI supports Station Management (SMT) Version 7.3 of the X3T9.5 FDDI specification, offering a single MAC dual-attach interface that supports the fault-recovery methods of the dual attachment stations (DASs). The mid-range platforms also support single attachment stations (SASs).
Support for FDDI is supplied on one of our FDDI interface cards, as follows:
•
On the Cisco 4000 series, the high-speed multimode-to-multimode, single mode-to-single mode, multimode-to-single mode, or single mode-to-multimode FDDI DAS Network Interface Module (NIM), and also the multimode FDDI SAS NIM
•
On the FDDI Interface Processor (FIP) in the Cisco 7000 series, high-speed multimode-to-multimode, single mode-to-single mode, multimode-to-single mode, or single mode-to-multimode
•
On the second-generation Versatile Interface Processor (VIP2) in the Cisco 7000 family, FDDI port adapters that support half-duplex multimode-to-multimode, half-duplex single mode-to-multimode, full duplex single mode-to-multimode, and full duplex multimode-to-multimode
We also provide support for some of the FDDI MIB variables as described in RFC 1285, "FDDI Management Information Base," published in January 1992 by Jeffrey D. Case of the University of Tennessee and SNMP Research, Inc. One such variable that we support is snmpFddiSMTCFState.
FDDI interface configuration is not required for dual homing. The FDDI interface recognizes that it is attached to two M ports on the concentrators and automatically supports dual homing.
Using Connection Management (CMT) Information
Connection Management (CMT) is an FDDI process that handles the transition of the ring through its various states (off, on, active, connect, and so on) as defined by the X3T9.5 specification. The FIP provides CMT functions in microcode.
A partial sample output of the show interfaces fddi command follows, along with an explanation of how to interpret the CMT information in the output.
Phy-A state is active, neighbor is B, cmt signal bits 08/20C, status ALS
Phy-B state is active, neighbor is A, cmt signal bits 20C/08, status ILS
CFM is thru A, token rotation 5000 usec, ring operational 0:01:42
Upstream neighbor 0800.2008.C52E, downstream neighbor 0800.2008.C52E
The show interfaces fddi example shows that Physical A (Phy-A) completed CMT with its neighbor. The state is active and the display indicates a Physical B-type neighbor.
The sample output indicates cmt signal bits 08/20C for Phy-A. The transmit signal bits are 08. Looking at the PCM state machine, 08 indicates that the port type is A, the port compatibility is set, and the LCT duration requested is short. The receive signal bits are 20C, which indicate the neighbor type is B, port compatibility is set, there is a MAC on the port output, and so on.
The neighbor is determined from the received signal bits, as follows:
Bit Positions
|
9 8 7 6 5 4 3 2 1 0
|
Value Received
|
1 0 0 0 0 0 1 1 0 0
|
Interpreting the bits in the diagram above, the received value equals 0x20C. Bit positions 1 and 2 (0 1) indicate a Physical B-type connection.
The transition states displayed indicate that the CMT process is running and actively trying to establish a connection to the remote physical connection. The CMT process requires state transition with different signals being transmitted and received before moving on to the state ahead as indicated in the PCM state machine. The ten bits of CMT information are transmitted and received in the Signal State. The NEXT state is used to separate the signaling performed in the Signal State. Therefore, in the preceding sample output, the NEXT state was entered 11 times.
Note
The display line showing transition states is not generated if the FDDI interface has been shut down, or if the cmt disconnect command has been issued, or if the fddi if-cmt command has been issued. (The fddi if-cmt command applies to the Cisco 7000 only.)
The CFM state is thru A in the sample output, which means this interface's Phy-A has successfully completed CMT with the Phy-B of the neighbor and Phy-B of this interface has successfully completed CMT with the Phy-A of the neighbor.
The display (or nondisplay) of the upstream and downstream neighbor does not affect the ability to route data. Since the upstream neighbor is also its downstream neighbor in the sample, there are only two stations in the ring: the network server and the router at address 0800.2008.C52E.
FDDI Task List
Perform the tasks in the following sections to configure an FDDI interface. The first task is required; the remaining tasks are optional.
•
Specify an FDDI
•
Enable FDDI Bridging Encapsulation
•
Set the Token Rotation Time
•
Set the Transmission Valid Timer
•
Control the Transmission Timer
•
Modify the C-Min Timer
•
Modify the TB-Min Timer
•
Modify the FDDI Timeout Timer
•
Control SMT Frame Processing
•
Enable Duplicate Address Checking
•
Set the Bit Control
•
Control the CMT Microcode
•
Start and Stop FDDI
•
Control the FDDI SMT Message Queue Size
•
Preallocate Buffers for Bursty FDDI Traffic
Specify an FDDI
To specify an FDDI interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration
|
interface fddi number
|
Begin interface configuration for the Cisco 7000, Cisco 7200, or Cisco 7500 series.
|
interface fddi slot/port
|
Enable FDDI Bridging Encapsulation
Cisco FDDI by default uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface when using the FIP.
FIP fully supports transparent and translational bridging for the following configurations:
•
FDDI to FDDI
•
FDDI to Ethernet
•
FDDI to Token Ring
Enabling FDDI bridging encapsulation places the FIP into encapsulation mode when doing bridging. In transparent mode, the FIP interoperates with earlier versions of encapsulating interfaces when performing bridging functions on the same ring. When using the FIP, you can specify the encapsulation method by performing the following task in interface configuration mode:
Task
|
Command
|
Specify the encapsulation method for the FIP.
|
fddi encapsulate
|
When you are doing translational bridging, you have to route routable protocols and use translational bridging for the rest (such as LAT).
Note
Bridging between dissimilar media presents several problems that can prevent communications. These problems include bit-order translation (using MAC addresses as data), maximum transfer unit (MTU) differences, frame status differences, and multicast address usage. Some or all of these problems might be present in a multimedia-bridged LAN and might prevent communication. These problems are most prevalent in networks that bridge between Token Rings and Ethernets or between Token Rings and FDDI because of the different ways Token Ring is implemented by the end nodes.
We are currently aware of problems with the following protocols when bridged between Token Ring and other media: AppleTalk, DECnet, IP, Novell IPX, Phase IV, VINES, and XNS. Further, the following protocols might have problems when bridged between FDDI and other media: Novell IPX and XNS. We recommend that these protocols be routed whenever possible.
Set the Token Rotation Time
You can set the FDDI token rotation time to control ring scheduling during normal operation and to detect and recover from serious ring error situations. To do so, perform the following task in interface configuration mode:
Task
|
Command
|
Set the FDDI token rotation time.
|
fddi token-rotation-time microseconds
|
The FDDI standard restricts the allowed time to be greater than 4000 microseconds and less than 165,000 microseconds. As defined in the X3T9.5 specification, the value remaining in the token rotation timer (TRT) is loaded into the token holding timer (THT). Combining the values of these two timers provides the means to determine the amount of bandwidth available for subsequent transmissions.
Set the Transmission Valid Timer
You can set the transmission timer to recover from a transient ring error by performing the following task in interface configuration mode:
Task
|
Command
|
Set the FDDI valid transmission timer.
|
fddi valid-transmission-time microseconds
|
Control the Transmission Timer
You can set the FDDI control transmission timer to control the FDDI TL-Min time, which is the minimum time to transmit a Physical Sublayer or PHY line state before advancing to the next Physical Connection Management or PCM state as defined by the X3T9.5 specification. To do so, perform the following task in interface configuration mode:
Task
|
Command
|
Set the FDDI control transmission timer.
|
fddi tl-min-time microseconds
|
Modify the C-Min Timer
You can modify the C-Min timer on the PCM from its default value of 1600 microseconds by performing the following task in interface configuration mode:
Task
|
Command
|
Set the C-Min timer on the PCM.
|
fddi c-min microseconds
|
Modify the TB-Min Timer
You can change the TB-Min timer in the PCM from its default value of 100 milliseconds. To do so, perform the following task in interface configuration mode:
Task
|
Command
|
Set TB-Min timer in the PCM.
|
fddi tb-min milliseconds
|
Modify the FDDI Timeout Timer
You can change the FDDI timeout timer in the PCM from its default value of 100 milliseconds. To do so, perform the following task in interface configuration mode:
Task
|
Command
|
Set the timeout timer in the PCM.
|
fddi t-out milliseconds
|
Control SMT Frame Processing
You can disable and reenable SMT frame processing for diagnostic purposes. To do so, perform one of the following tasks in interface configuration mode:
Task
|
Command
|
Disable SMT frame processing.
|
no fddi smt-frames
|
Enable SMT frame processing.
|
fddi smt-frames
|
Enable Duplicate Address Checking
You can enable the duplicate address detection capability on the FDDI. If the FDDI finds a duplicate address, it displays an error message and shuts down the interface. To enable duplicate address checking, perform the following task in interface configuration mode:
Task
|
Command
|
Enable duplicate address checking capability.
|
fddi duplicate-address-check
|
Set the Bit Control
You can set the FDDI bit control to control the information transmitted during the Connection Management (CMT) signaling phase. To do so, perform the following task in interface configuration mode:
Task
|
Command
|
Set the FDDI bit control.
|
fddi cmt-signal-bits signal-bits [phy-a | phy-b]
|
Control the CMT Microcode
You can control whether the CMT onboard functions are on or off. The FIP provides CMT functions in microcode. These functions are separate from those provided on the processor card and are accessed through EXEC commands.
The default is for the FIP CMT functions to be on. A typical reason to disable is when you work with new FDDI equipment and have problems bringing up the ring. If you disable the CMT microcode, the following actions occur:
•
The FIP CMT microcode is disabled.
•
The main system code performs the CMT function while debugging output is generated.
To disable the CMT microcode, perform the following task in interface configuration mode:
Task
|
Command
|
Disable the FCIT CMT functions.
|
no fddi if-cmt
|
Start and Stop FDDI
In normal operation, the FDDI interface is operational once the interface is connected and configured. You can start and stop the processes that perform the CMT function and allow the ring on one fiber to be stopped. To do so, perform either of the following tasks in EXEC mode:
Task
|
Command
|
Start CMT processes on FDDI ring.
|
cmt connect [interface-name [phy-a | phy-b]]
|
Stop CMT processes on FDDI ring.
|
cmt disconnect [interface-name [phy-a | phy-b]]
|
Do not do either of the preceding tasks during normal operation of FDDI; they are performed during interoperability tests.
Control the FDDI SMT Message Queue Size
You can set the maximum number of unprocessed FDDI Station Management (SMT) frames that will be held for processing. Setting this number is useful if the router you are configuring gets bursts of messages arriving faster than the router can process them. To set the number of frames, perform the following task in global configuration mode:
Task
|
Command
|
Set SMT message queue size.
|
smt-queue-threshold number
|
Preallocate Buffers for Bursty FDDI Traffic
The FCI card preallocates three buffers to handle bursty FDDI traffic (for example, NFS bursty traffic). You can change the number of preallocated buffers by performing the following task in interface configuration mode:
Task
|
Command
|
Preallocate buffers to handle bursty FDDI traffic.
|
fddi burst-count
|
Configure a High-Speed Serial Interface (HSSI)
On the Cisco 7000 series and the Cisco 7500 series, the HSSI Interface Processor (HIP) provides a single HSSI network interface. The network interface resides on a modular interface processor that provides a direct connection between the high-speed CiscoBus and an external network.
HSSI Task List
Perform the tasks in the following sections to configure an HSSI interface. The first task is required; the remaining tasks are optional.
•
Specify an HSSI
•
Specify HSSI Encapsulation
•
Invoke ATM on an HSSI Line
•
Convert HSSI to Clock Master
Specify an HSSI
To specify an HSSI and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface hssi number
|
Begin interface configuration for the Cisco 7000 series.
|
interface hssi slot/port
|
Specify HSSI Encapsulation
The HSSI supports the serial encapsulation methods, except for X.25-based encapsulations. The default method is HDLC. You can define the encapsulation method by performing the following task in interface configuration mode:
Task
|
Command
|
Configure HSSI encapsulation.
|
encapsulation {atm-dxi | hdlc | frame-relay | ppp | sdlc-primary | sdlc-secondary | smds | stun}
|
For information about PPP, see the "Configure SLIP and PPP" chapter of the Access Services Configuration Guide and the "Configure PPP for Wide-Area Networking" chapter of the Wide-Area Networking Configuration Guide.
Invoke ATM on an HSSI Line
If you have an ATM DSU, you can invoke ATM over a HSSI line. You do so by mapping an ATM virtual path identifier (VPI) and virtual channel identifier (VCI) to a DXI frame address. ATM-DXI encapsulation defines a data exchange interface that allows a DTE (such as a router) and a DCE (such as an ATM DSU) to cooperate to provide a User-Network Interface (UNI) for ATM networks.
To invoke ATM over a serial line, perform the following tasks in interface configuration mode:
Task
|
Command
|
Step 1 Specify the encapsulation method.
|
encapsulation atm-dxi
|
Step 2 Map a given VPI and VCI to a DXI frame address.
|
dxi map protocol address vpi vci [broadcast]1
|
You can also configure the dxi map command on a serial interface.
To configure an ATM interface using an AIP card, see the "Configuring ATM" chapter in the Wide-Area Networking Configuration Guide.
Convert HSSI to Clock Master
You can convert the HSSI interface into a 45-MHz clock master by performing the following task in interface configuration mode:
Task
|
Command
|
Convert the HSSI interface into a 45-MHz clock master.
|
hssi internal-clock
|
Configure a Hub Interface
The Cisco 2500 series includes routers that have hub functionality for an Ethernet interface. The hub is a multiport repeater. The advantage of an Ethernet interface over a hub is that the hub provides a star-wiring physical network configuration while the Ethernet interface provides 10BaseT physical network configuration. The router models with hub ports and their configurations are as follows:
•
Cisco 2505—1 Ethernet (8 ports) and 2 serial
•
Cisco 2507—1 Ethernet (16 ports) and 2 serial
•
Cisco 2516—1 Ethernet (14 ports), 2 serial, and 1 ISDN BRI
We provide SNMP management of the Ethernet hub as specified in RFC 1516.
To configure hub functionality on an Ethernet interface, perform the tasks in the following sections. The first task is required; the remaining are optional.
•
Enable a Hub Port
•
Disable or Enable Automatic Receiver Polarity Reversal
•
Disable or Enable the Link Test Function
•
Enable Source Address Control
•
Enable SNMP Illegal Address Trap (for Cisco 2505, Cisco 2507, and Cisco 2516)
See the "Hub Configuration Examples" section the end of this chapter.
Enable a Hub Port
To enable a hub port, perform the following tasks in global configuration mode:
Task
|
Command
|
Step 1 Specify the hub number and the hub port (or range of hub ports) and enter hub configuration mode.
|
hub ethernet number port [end-port]
|
Step 2 Enable the hub ports.
|
no shutdown
|
Disable or Enable Automatic Receiver Polarity Reversal
On Ethernet hub ports only, the hub ports can invert, or correct, the polarity of the received data if the port detects that the received data packet waveform polarity is reversed due to a wiring error. This receive circuitry polarity correction allows the hub to repeat subsequent packets with correct polarity. When enabled, this function is executed once after reset of a link fail state.
Automatic receiver polarity reversal is enabled by default. To disable this feature on a per-port basis, perform the following task in hub configuration mode:
Task
|
Command
|
Disable automatic receiver polarity reversal.
|
no auto-polarity
|
To reenable automatic receiver polarity reversal on a per-port basis, perform the following task in hub configuration mode:
Task
|
Command
|
reenable automatic receiver polarity reversal.
|
auto-polarity
|
Disable or Enable the Link Test Function
The link test function applies to Ethernet hub ports only. The Ethernet ports implement the link test function as specified in the 802.3 10BaseT standard. The hub ports will transmit link test pulses to any attached twisted pair device if the port has been inactive for more than 8 to 17 milliseconds.
If a hub port does not receive any data packets or link test pulses for more than 65 to 132 milliseconds and the link test function is enabled for that port, that port will enter link fail state and be disabled from transmit and receive functions. The hub port will be reenabled when it receives four consecutive link test pulses or a data packet.
The link test function is enabled by default. To allow the hub to interoperate with 10BaseT twisted-pair networks that do not implement the link test function, the hub's link test receive function can be disabled on a per-port basis. To do so, perform the following task in hub configuration mode:
Task
|
Command
|
Disable the link test function.
|
no link-test
|
To reenable the link test function on a hub port connected to an Ethernet interface, perform the following task in hub configuration mode:
Task
|
Command
|
Enable the link test function.
|
link-test
|
Enable Source Address Control
On an Ethernet hub port only, you can configure a security measure such that the port accepts packets only from a specific MAC address. For example, suppose your workstation is connected to port 3 on a hub, and source address control is enabled on port 3. Your workstation has access to the network because the hub accepts any packet from port 3 with your workstation's MAC address. Any packets arriving with a different MAC address cause the port to be disabled. The port is reenabled after 1 minute and the MAC address of incoming packets is checked again.
To enable source address control on a per-port basis, perform the following task in hub configuration mode:
Task
|
Command
|
Enable source address control.
|
source-address [mac-address]
|
If you omit the optional MAC address, the hub remembers the first MAC address it receives on the selected port, and allows only packets from the learned MAC address.
See the examples of establishing source address control at the end of this chapter in "Hub Configuration Examples."
Enable SNMP Illegal Address Trap (for Cisco 2505, Cisco 2507, and Cisco 2516)
To enable the router to issue an SNMP trap when an illegal MAC address is detected on an Ethernet hub port, perform the following tasks in hub configuration mode:
Task
|
Command
|
Step 1 Specify the hub number and the hub port (or range of hub ports) and enter hub configuration mode.
|
hub ethernet number port [end-port]
|
Step 2 Enable the router to issue an SNMP trap when an illegal MAC address is detected on the hub port.
|
snmp trap illegal-address
|
You may need to set up a host receiver for this trap type (snmp-server host) for a nms to receive this trap type. The default is no trap. For an example of configuring a SNMP trap for an Ethernet hub port, see the section "Hub Configuration Examples" at the end of this chapter.
Configure an ISDN BRI, MBRI, or PRI Interface
ISDN Primary Rate Interface (PRI) is supported on the Cisco 4000, the Cisco 4500, and the Cisco 7000 series routers using T1 or E1 versions of the Multichannel Interface Processor (MIP) card in conjunction with PRI signaling software. Channelized T1 ISDN PRI offers 23 B-channels and 1 D-channel. Channelized E1 ISDN PRI offers 30 B-channels and 1 D-channel.
The Integrated Services Digital Network (ISDN) Basic Rate Interface (BRI) is supported on the Cisco 1003 model, Cisco 2500 series, Cisco 3000 series, and Cisco 4000 series routers. ISDN Multiport BRI (MBRI) is supported on the Cisco 4000 and Cisco 4500 only, which have a multichannel NIM. The multichannel card supports one or two BRI port adapters, providing either 4 or 8 ports, respectively.
For information on how to configure ISDN, see the chapter entitled "Configuring ISDN" in the Wide-Area Networking Configuration Guide. For command information, refer to the chapter entitled "ISDN Commands" in the Wide-Area Networking Command Reference.
Note
Any router configured for ISDN support must be connected to the same switch type on all its ISDN interfaces.
Configure a LAN Extender Interface
The Cisco 1001 and Cisco 1002 LAN Extenders are two-port chassis that connects a remote Ethernet LAN to a core router at a central site (see ). The LAN Extender is intended for small networks at remote sites.
The remote site can have one Ethernet network. The core router can be a Cisco 2500 series, Cisco 4000 series, Cisco 4500 series, Cisco 4700 series, Cisco 7000 series, or AGS+ router running Cisco IOS Release 10.2(2) or later, which support the LAN Extender host software. The connection between the LAN Extender and the core router is made via a short leased serial line, typically a 56-kbps or 64-kbps line. However, the connection can also be via T1 or E1 lines.
Figure 2 Cisco 1000 Series LAN Extender Connection to a Core Router
is an expanded view of that shows all the components of the LAN Extender connection to a core router. On the left is the core router, which is connected to the LAN Extender as well as to other networks. In the core router, you configure a LAN Extender interface, which is a logical interface that connects the core router to the LAN Extender chassis. In the core router, you also configure a serial interface, which is the physical interface that connects the core router to the LAN Extender. You then bind, or associate, the LAN Extender interface to the physical serial interface.
shows the actual physical connection between the core router and the LAN Extender. The serial interface on the core router is connected by a leased serial line to a serial port on the LAN Extender. This creates a virtual Ethernet connection, which is analogous to having inserted an Ethernet interface processor into the core router.
Figure 3 Expanded View of Cisco 1000 Series LAN Extender Connection
Although there is a physical connection between the core router and the LAN Extender, what you actually manage is a remote Ethernet LAN. shows the connection you are managing, which is a LAN Extender interface connected to an Ethernet network. The virtual Ethernet connection (the serial interface and LAN Extender) has been removed from the figure, and points A and B, which in were separated by the virtual Ethernet connection, are now adjacent. All LAN Extender interface configuration tasks described in this chapter apply to the interface configuration shown in .
Figure 4 LAN Extender Interface Connected to an Ethernet Network
To install a LAN Extender at a remote site, refer to the Cisco 1000 Series Hardware Installation publication.
After the LAN Extender has been installed at the remote site, you need to obtain its MAC address. Each LAN Extender is preconfigured with a permanent (burned-in) MAC address. The address is assigned at the factory; you cannot change it. The MAC address is printed on the LAN Extender's packing box. (If necessary, you can also display the MAC address with the debug ppp negotiation command.) The first three octets of the MAC address (the vendor code) are always the hexadecimal digits 00.00.0C.
You can upgrade software for the LAN Extender on the host router with a TFTP server that is local to the host router.
The LAN Extender and core router communicate using the Point-to-Point Protocol (PPP). Before you can configure the LAN Extender from the core router, you must first enable PPP encapsulation on the serial interface to which the LAN Extender is connected.
You then configure the LAN Extender from the core router—either a Cisco 4000 series or
Cisco 7000 series router—as if it were simply a network interface board. The LAN Extender cannot be managed or configured from the remote Ethernet LAN or via a Telnet session.
To configure the LAN Extender, you configure a logical LAN Extender interface on the core router and assign the MAC address from your LAN Extender to that interface. Subsequently, during the PPP negotiation on the serial line, the LAN Extender sends its preconfigured MAC address to the core router. The core router then searches for an available (preconfigured) LAN Extender interface, seeking one to which you have already assigned that MAC address. If the core router finds a match, it binds, or associates, that LAN Extender interface to the serial line on which that MAC address was negotiated. At this point, the LAN Extender interface is created and is operational. If the MAC address does not match one that is configured, the connection request is rejected. illustrates this binding process.
Figure 5 Binding a Serial Line to a LAN Extender Interface
LAN Extender Interface Configuration Task List
To configure a LAN Extender interface, perform the tasks described in the following sections. The first task is required; the remainder are optional.
•
Configure and Create a LAN Extender Interface
•
Define Packet Filters
•
Control Priority Queuing
•
Control the Sending of Commands to the LAN Extender
•
Shut Down and Restart the LAN Extender's Ethernet Interface
•
Restart the LAN Extender
•
Download a Software Image to the LAN Extender
•
Troubleshoot the LAN Extender
To monitor the LAN Extender interface, see the section "Monitor and Maintain the Interface" later in this chapter. For configuration examples, see the "Enabling a LAN Extender Interface Example" and the "LAN Extender Interface Access List Examples" sections at the end of this chapter.
Configure and Create a LAN Extender Interface
To configure and create a LAN Extender interface, you configure the LAN Extender interface itself and the serial interface to which the LAN Extender is physically connected. The order in which you configure these two interface interfaces does not matter. However, you must first configure both interfaces in order for the LAN Extender interface to bind (associate) to the serial interface.
To create and configure a LAN Extender interface, perform the following tasks:
Task
|
Command
|
Step 1 Configure a LAN Extender interface in global configuration mode and enter interface configuration mode. or Configure a LAN Extender on a Cisco 7000.
|
interface lex number
interface lex slot/port
|
Step 2 Assign the burned-in MAC address from your LAN Extender to the LAN Extender interface.
|
lex burned-in-address ieee-address
|
Step 3 Assign a protocol address to the LAN Extender interface.
|
ip address ip-address mask1
|
Step 4 Return to global configuration mode.
|
exit2
|
Step 5 Configure a serial interface in global configuration mode and enter interface configuration mode.
|
interface serial number
|
Step 6 Enable PPP encapsulation on the serial interface in interface configuration mode.
|
encapsulation ppp
|
Step 7 Exit interface configuration mode.
|
Ctrl-Z
|
Step 8 Save the configuration to memory.
|
copy running-config startup-config3
|
Note that there is no correlation between the number of the serial interface and the number of the LAN Extender interface. These interfaces can have the same or different numbers.
Note
Do not configure the MTU to a value other than the default value when you are configuring a LAN Extender interface.
Define Packet Filters
You can configure specific administrative filters that filter frames based on their source MAC address. The LAN Extender forwards packets between a remote LAN and a core router. It examines frames and transmits them through the internetwork according to the destination address, and it does not forward a frame back to its originating network segment.
You define filters on the LAN Extender interface in order to control which packets from the remote Ethernet LAN are permitted to pass to the core router. (See .) These filters are applied only on traffic passing from the remote LAN to the core router. Filtering on the LAN Extender interface is actually performed in the LAN Extender, not on the core router. This means that the filtering is done using the LAN Extender CPU, thus off-loading the function from the core router. This process also saves bandwidth on the WAN, because only the desired packets are forwarded from the LAN Extender to the core router. Whenever possible, you should perform packet filtering on the LAN Extender.
Figure 6 Packet Filtering on the LAN Extender
You can also define filters on the core router to control which packets from the LAN Extender interface are permitted to pass to other interfaces on the core router. (See .) You do this using the standard filters available on the router. This means that all packets are sent across the WAN before being filtered and that the filtering is done using the core router's CPU.
Figure 7 Packet Filtering on the Core Router
The major reason to create access lists on a LAN Extender interface is to prevent traffic that is local to the remote Ethernet LAN from traversing the WAN and reaching the core router. You can filter packets by MAC address, including vendor code, and by Ethernet type code. To define filters on the LAN Extender interface, perform the tasks described in one or both of the following sections:
•
Filter by MAC Address and Vendor Code
•
Filter by Protocol Type
Note
When setting up administrative filtering, remember that there is virtually no performance penalty when filtering by vendor code, but there can be a performance penalty when filtering by protocol type.
When defining access lists, keep the following points in mind:
•
You can assign only one vendor code access list and only one protocol type access list to an interface.
•
The conditions in the access list are applied to all outgoing packets from the LAN Extender.
•
The entries in an access list are scanned in the order you enter them. The first entry that matches the outgoing packet is used.
•
An implicit "deny everything" entry is automatically defined at the end of an access list unless you include an explicit "permit everything" entry at the end of the list. This means that unless you have an entry at the end of an access list that explicitly permits all packets that do no match any of the other conditions in the access list, these packets will not be forwarded out the interface.
•
All new entries to an existing list are placed at the end of the list. You cannot add an entry to the middle of a list.
•
If you do not define any access lists on an interface, it is as if you had defined an access lists with only a "permit all" entry. All traffic passes across the interface.
Filter by MAC Address and Vendor Code
You can create access lists to administratively filter MAC addresses. These access lists can filter groups of MAC addresses, including those with particular vendor codes. There is no noticeable performance loss in using these access lists, and the lists can be of indefinite length. You can filter groups of MAC addresses with particular vendor codes by performing the tasks that follow:
Step 1
Create a vendor code access list.
Step 2
Apply an access list to an interface.
To create a vendor code access list, perform the following task in global configuration mode:
Task
|
Command
|
Create an access list to filter frames by canonical (Ethernet-ordered) MAC address.
|
access-list access-list-number {permit | deny} address mask
|
Note
Token Ring and FDDI networks swap their MAC address bit ordering, but Ethernet networks do not. Therefore, an access list that works for one medium might not work for others.
Once you have defined an access list to filter by a particular vendor code, you can assign this list to a particular LAN Extender interface so that the interface will then filter based on the MAC source addresses of packets received on that LAN Extender interface. To apply the access list to an interface, perform the following task in interface configuration mode:
Task
|
Command
|
Assign an access list to an interface for filtering by MAC source addresses.
|
lex input-address-list access-list-number
|
For an example of creating an access list and applying it to a LAN Extender interface, see the section "LAN Extender Interface Access List Examples" in the section "Interface Configuration Examples" at the end of this chapter.
Filter by Protocol Type
You can filter by creating a type-code access list and applying it to a LAN Extender interface.
The LAN Extender interface can filter only on bytes 13 and 14 of the Ethernet frame. In Ethernet packets, these two bytes are the type field. For a list of Ethernet type codes, refer to the "Ethernet Type Codes" appendix in the Bridging and IBM Networking Command Reference. In 802.3 packets, these two bytes are the length field.
To filter by protocol type, perform the following tasks:
Step 1
Create a protocol-type access list.
Step 2
Apply the access list to an interface.
Note
Type-code access lists can have an impact on system performance; therefore, keep the lists as short as possible and use wildcard bit masks whenever possible.
To create a protocol-type access list, perform the following task in global configuration mode:
Task
|
Command
|
Create an access list to filter frames by protocol type.
|
access-list access-list-number {permit | deny} type-code wild-mask
|
To apply an access list to an interface, perform the following task in interface configuration mode:
Task
|
Command
|
Add a filter for Ethernet- and SNAP-encapsulated packets on input.
|
lex input-type-list access-list-number
|
For an example of creating an access list and applying it to a LAN Extender interface, see the section "LAN Extender Interface Access List Examples" in the section "Interface Configuration Examples" at the end of this chapter.
Control Priority Queuing
Priority output queuing is an optimization mechanism that allows you to set priorities on the type of traffic passing through the network. Packets are classified according to various criteria, including protocol and subprotocol type. Packets are then queued on one of four output queues. For more information about priority queuing, refer to the "Managing the System" chapter.
To control priority queuing on a LAN Extender interface, perform the following tasks:
•
Set the priority by protocol type.
•
Assign a priority group to an interface.
To establish queuing priorities based on the protocol type, perform the following task in global configuration mode:
Task
|
Command
|
Establish queuing priorities based on the protocol type.
|
priority-list list protocol protocol {high | medium | normal | low} 1 or priority-list list protocol bridge {high | medium | normal | low} list list-number
|
You then assign a priority list to an interface. You can assign only one list per interface. To assign a priority list to a LAN Extender interface, perform the following task in interface configuration mode:
Task
|
Command
|
Assign a priority list to a LAN Extender interface, thus activating priority output queuing on the LAN Extender.
|
lex priority-group group
|
Control the Sending of Commands to the LAN Extender
Each time the core router sends a command to the LAN Extender, the LAN Extender responds with an acknowledgment. The core router waits for the acknowledgment for a predetermined amount of time. If it does not receive an acknowledgment in this time period, the core router resends the command.
By default, the core router waits 2 seconds for an acknowledgment from the LAN Extender. You might want to change this interval if your connection to the LAN Extender requires a different amount time. To determine whether commands to the LAN Extender are timing out, use the debug lex rcmd privileged EXEC command. To change this interval, perform the following task in interface configuration mode:
Task
|
Command
|
Set the amount of time that the core router waits to receive an acknowledgment from the LAN Extender.
|
lex timeout milliseconds
|
By default, the core router sends each command ten times before giving up. The core router displays an error message when it gives up sending commands to the LAN Extender. To change this default, perform the following task in interface configuration mode:
Task
|
Command
|
Set the number of times the core router sends a command to the LAN Extender before giving up.
|
lex retry-count number
|
Shut Down and Restart the LAN Extender's Ethernet Interface
From the core router, you can shut down the LAN Extender's Ethernet interface. This stops traffic on the remote Ethernet LAN from reaching the core router, but leaves the LAN Extender interface that you created intact.
Note that logically it makes no sense to shut down the serial interface on the LAN Extender. There are no commands that might allow you to do this.
To shut down the LAN Extender's Ethernet interface, perform the following task in interface configuration mode:
Task
|
Command
|
Shut down the LAN Extender's Ethernet interface.
|
shutdown
|
To restart the LAN Extender's Ethernet interface, perform the following task in interface configuration mode:
Task
|
Command
|
Restart the LAN Extender's Ethernet interface.
|
no shutdown
|
Restart the LAN Extender
To reboot the LAN Extender and reload the software, perform the following task in privileged EXEC mode:
Task
|
Command
|
Halt operation of the LAN Extender and have it perform a cold restart.
|
clear controller lex number [prom]
|
Halt operation of the LAN Extender on a Cisco 7000.
|
clear controller lex slot/port [prom]
|
Download a Software Image to the LAN Extender
When the LAN Extender is powered on, it runs the software image that is shipped with the unit. You can download a new software image from a TFTP server or from Flash memory on the core router to the LAN Extender.
To download a software image to the LAN Extender, perform one of the following tasks in privileged EXEC mode:
Task
|
Command
|
Download a software image from a TFTP server.
|
copy tftp lex number
|
Download a software image from Flash memory.
|
copy flash lex number
|
Troubleshoot the LAN Extender
The primary means of troubleshooting the LAN Extender is by using the light emitting diodes (LEDs) that are present on the chassis. This section will help you assist the remote user at the LAN Extender site who can observe the LEDs.
The key to problem solving is to try to isolate the problem to a specific subsystem. By comparing what the system is doing to what it should be doing, the task of isolating a problem is greatly simplified.
The Cisco 1000 series LAN Extender uses multiple LEDs to indicate its current operating condition. By observing the LEDs, any fault conditions that the unit is encountering can be observed. The system LEDs are located on the front panel of your LAN Extender (see ).
Figure 8 LAN Extender LEDs
When there is a problem with the LAN Extender, a user at the remote site should contact you and report the condition of the LEDs located on the front panel of the LAN Extender. You can then use this information to diagnose or verify the operation of the system. explains the LEDs.
Table 2 LED Trouble Indicators
LED
|
Condition
|
Meaning
|
POWER
|
On Steady
|
The POWER LED indicates that 12 Volts DC is being supplied to the LAN Extender.
|
| |
Off
|
If the POWER LED is off, power is not reaching the unit.
Verify that the power supply is plugged into the wall receptacle, and that the cable from the power supply to the unit is connected.
|
SYSTEM OK
|
On Steady
|
The SYSTEM OK LED is lit when the unit passes the power on diagnostics. This indicates proper operation.
|
| |
Blinking
|
The system will blink while running its startup diagnostics and then will go to a steady on position.
Blinking after the start-up diagnostics indicates that a system error has been encountered. Contact your system administrator who will have you disconnect and then reconnect the power to recycle your LAN Extender. If the blinking continues, check your WAN connection and the RX and TX LEDs.
|
| |
Off
|
An error condition has occurred. Contact your system administrator who will ask you to disconnect the power cord and then reconnect it to re-establish power to your LAN Extender.
|
SERIAL TX and SERIAL RX
|
Flicker
|
The serial line is transmitting and receiving packets normally.
|
| |
Blinking
|
A line fault has been detected. The LEDs will go on for several seconds and then they will blink a certain number of times to indicate a particular error. The LEDs will blink at a rate of one to two blinks per second. The following are the errors that can be encountered:
1 blink = The serial line is down.
2 blinks = No clock signal was received.
3 blinks = An excessive number of cyclic redundancy check (CRC) errors has been received.
4 blinks = The line is noisy.
5 blinks = A loopback condition has occurred.
6 blinks = The PPP link has failed.
Contact your system administrator.
|
LAN TX and LAN RX
|
Flicker
|
The Ethernet LAN connection is transmitting and receiving data normally.
|
COLLISION
|
|
Data collisions are being detected.
|
LINK OK
|
Steady
|
This indicates the serial link is up and functioning.
|
For more complete network troubleshooting information, refer to the Troubleshooting Internetworking Systems publication.
Configure a Loopback Interface
You can specify a software-only interface called a loopback interface to emulate an interface. It is supported on all platforms. A loopback interface is a virtual interface that is always up and allows BGP and RSRB sessions to stay up even if the outbound interface is down.
You can use the loopback interface as the termination address for BGP sessions, for RSRB connections, or to establish a Telnet session from the device's console to its auxiliary port when all other interfaces are down. You can also use a loopback interface to configure IPX-PPP on asynchronous interfaces. To do so, you must associate an asynchronous interface with a loopback interface configured to run IPX. In applications where other routers or access servers attempt to reach this loopback interface, you should configure a routing protocol to distribute the subnet assigned to the loopback address.
Packets routed to the loopback interface are rerouted back to the router or access server and processed locally. IP packets routed out the loopback interface but not destined to the loopback interface are dropped. This means that the loopback interface serves as the Null 0 interface also.
Note
Loopback does not work on an X.21 DTE because the X.21 interface definition does not include a loopback definition.
To specify a loopback interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface loopback number
|
Begin interface configuration for the Cisco 7000 series or the Cisco 7200 series.
|
interface loopback slot/port
|
Begin interface configuration for the Cisco 7500 series.
|
interface loopback slot/port-adapter/port
|
See the section "Run Interface Loopback Diagnostics" later in this chapter.
Configure Low-Speed Serial Interfaces (Cisco 2520 to Cisco 2523)
This section describes how to configure low-speed serial interfaces on Cisco 2520 through Cisco 2523 routers. To configure low-speed serial interfaces, perform the tasks described in the following sections:
•
Understand Half-Duplex DTE and DCE State Machines
•
Change between Controlled-Carrier and Constant-Carrier Modes Example
•
Tune Half-Duplex Timers
•
Change between Synchronous and Asynchronous Modes
See the "Low-Speed Serial Interface Examples" section at the end of this chapter for configuration examples.
Understand Half-Duplex DTE and DCE State Machines
The following section describes the communication between half-duplex DTE transmit and receive state machines and half-duplex DCE transmit and receive state machines.
Half-Duplex DTE State Machines
As shown in , the half-duplex DTE transmit state machine for low-speed interfaces remains in the ready state when it is quiescent. When a frame is available for transmission, the state machine transitions to the transmit delay state and waits for a time period, which is defined by the half-duplex timer transmit-delay command. The default is 0 ms. Transmission delays are used for debugging half-duplex links and assisting lower speed receivers that cannot process back-to-back frames.
Figure 9 Half-Duplex DTE Transmit State Machine
After idling for a defined number of ms, the state machine asserts request to send (RTS) and transitions to the wait clear to send (CTS) state for the data communications equipment (DCE) to assert CTS. A timeout timer with a value set by the half-duplex timer rts-timeout command starts. This default is 3 ms. If the timeout timer expires before CTS is asserted, the state machine returns to the ready state and de-asserts RTS. If CTS is asserted prior to the timer's expiration, the state machine transitions to the transmit state and sends the frames.
Once there are no more frames to transmit, the state machine transitions to the wait transmit finish state. The machine waits for the transmit first in first out (FIFO) in the serial controller to empty, starts a delay timer with a value defined by the half-duplex timer rts-drop-delay interface command, and transitions to the wait RTS drop delay state.
When the timer in the wait RTS drop delay state expires, the state machine de-asserts RTS and transitions to the wait CTS drop state. A timeout timer with a value set by the half-duplex timer cts-drop-timeout interface command starts, and the state machine waits for the CTS to de-assert. The default is 250 ms. Once the CTS signal is de-asserted or the timeout timer expires, the state machine transitions back to the ready state. If the timer expires before CTS is de-asserted, an error counter is incremented, which can be displayed by issuing the show controllers command for the serial interface in question.
As shown in , a half-duplex DTE receive state machine for low-speed interfaces idles and receives frames in the ready state. A giant frame is any frame whose size exceeds the maximum transmission unit (MTU). If the beginning of a giant frame is received, the state machine transitions to the in giant state and discards frame fragments until it receives the end of the giant frame. At this point, the state machine transitions back to the ready state and waits for the next frame to arrive.
Figure 10 Half-Duplex DTE Receive State Machine
An error counter is incremented upon receipt of the giant frames. To view the error counter, enter the show interface command for the serial interface in question.
Half-Duplex DCE State Machines
As shown in , for a low-speed serial interface in DCE mode, the half-duplex DCE transmit state machine idles in the ready state when it is quiescent. When a frame is available for transmission on the serial interface, such as when the output queues are no longer empty, the state machine starts a timer (based on the value of the transmit-delay command, in milliseconds) and transitions to the transmit delay state. Similar to the DTE transmit state machine, the transmit delay state gives you the option of setting a delay between the transmission of frames; for example, this feature lets you compensate for a slow receiver that loses data when multiple frames are received in quick succession. The default transmit-delay value is 0 ms; use the half-duplex timer transmit-delay interface configuration command to specify a delay value not equal to 0.
Figure 11 Half-Duplex DCE Transmit State Machine
After the transmit delay state, the next state depends on whether the interface is in constant-carrier mode (the default) or controlled-carrier mode.
If the interface is in constant-carrier mode, it passes through the following states:
1
The state machine passes to the transmit state when the transmit-delay timer expires. The state machine stays in the transmit state until there are no more frames to transmit.
2
When there are no more frames to transmit, the state machine passes to the wait transmit finish state, where it waits for the transmit FIFO to empty.
3
Once the FIFO empties, the DCE passes back to the ready state and waits for the next frame to appear in the output queue.
If the interface is in controlled-carrier mode, the interface performs a handshake using the data carrier detect (DCD) signal. In this mode, DCD is de-asserted when the interface is idle and has nothing to transmit. The transmit state machine transitions through the states as follows:
1
After the transmit-delay timer expires, the DCE asserts DCD and transitions to the DCD-txstart delay state to ensure a time delay between the assertion of DCD and the start of transmission. A timer with the value dcd-txstart-delay is started. (This timer has a default value of 100 ms; use the half-duplex timer dcd-txstart-delay interface configuration command to specify a delay value.)
2
When this delay timer expires, the state machine transitions to the transmit state and transmits frames until there are no more frames to transmit.
3
After the DCE transmits the last frame, it transitions to the wait transmit finish state, where it waits for transmit FIFO to empty and the last frame to transmit to the wire. Then DCE starts a delay timer with the value dcd-drop-delay. (This timer has the default value of 100 ms; use the half-duplex timer dcd-drop-delay interface configuration command to specify a delay value.)
4
The DCE transitions to the wait DCD drop delay state. This state causes a time delay between the transmission of the last frame and the de-assertion of DCD in the controlled-carrier mode for DCE transmits.
5
When the timer expires, the DCE de-asserts DCD and transitions back to the ready state and stays there until there is a frame to transmit on that interface.
As shown in , the half-duplex DCE receive state machine idles in the ready state when it is quiescent. It transitions out of this state when the DTE asserts RTS. In response, the DCE starts a timer with the value cts-delay. This timer delays the assertion of CTS because some DTE interfaces expect this delay. (The default value of this timer is 0 ms; use the half-duplex timer cts-delay interface configuration command to specify a delay value.)
Figure 12 Half-Duplex DCE Receive State Machine
When the timer expires, the DCE state machine asserts CTS and transitions to the receive state. It stays in the receive state until there is a frame to receive. If the beginning of a giant frame is received, it transitions to the in giant state and keeps discarding all the fragments of the giant frame and transitions back to the receive state.
Transitions back to the ready state occur when RTS is de-asserted by the DTE. The response of the DCE to the de-assertion of RTS is to de-assert CTS and go back to the ready state.
Change between Controlled-Carrier and Constant-Carrier Modes
The half-duplex controlled-carrier command enables you to change between controlled-carrier and constant-carrier modes for low-speed serial DCE interfaces in half-duplex mode. Configure a serial interface for half-duplex mode by using the half-duplex command. Full-duplex mode is the default for serial interfaces. This interface configuration is available on Cisco 2520 through Cisco 2523 routers.
Controlled-carrier operation means that the DCE interface will have DCD de-asserted in the quiescent state. When the interface has something to transmit, it will assert DCD, wait a user-configured amount of time, then start the transmission. When it has finished transmitting, it will again wait a user-configured amount of time, then de-assert DCD.
Place a Low-Speed Serial Interface in Controlled-Carrier Mode
To place a low-speed serial interface in controlled-carrier mode, perform the following task in interface configuration mode:
Task
|
Command
|
Place a low-speed serial interface in controlled-carrier mode.
|
half-duplex controlled-carrier
|
Place a Low-Speed Serial Interface in Constant-Carrier Mode
To return a low-speed serial interface to constant-carrier mode from controlled-carrier mode, perform the following task in interface configuration mode:
Task
|
Command
|
Place a low-speed serial interface in constant-carrier mode.
|
no half-duplex controlled-carrier
|
Tune Half-Duplex Timers
To tune half-duplex timers, perform the following task in interface configuration mode:
Task
|
Command
|
Tune half-duplex timers.
|
half-duplex timer {cts-delay value | cts-drop-timeout value | dcd-drop-delay value | dcd-txstart-delay value | rts-drop-delay value | rts-timeout value | transmit-delay value}
|
The timer tuning commands permit you to adjust the timing of the half-duplex state machines to suit the particular needs of their half-duplex installation.
Note that the half-duplex timer command and its options deprecates the following two timer tuning commands that are available only on high-speed serial interfaces:
•
sdlc cts-delay
•
sdlc rts-timeout
Change between Synchronous and Asynchronous Modes
To specify the mode of a low-speed serial interface as either synchronous or asynchronous, perform the following task in interface configuration mode:
Task
|
Command
|
Specify the mode of a low-speed interface as either synchronous or asynchronous.
|
physical-layer {sync | async}
|
This command applies only to low-speed serial interfaces available on Cisco 2520 through Cisco 2523 routers.
In synchronous mode, low-speed serial interfaces support all interface configuration commands available for high-speed serial interfaces, except the following two commands:
•
sdlc cts-delay
•
sdlc rts-timeout
When placed in asynchronous mode, low-speed serial interfaces support all commands available for standard asynchronous interfaces. The default is synchronous mode.
Note that when you enter this command, it does not appear in the output of show running config and show startup config command, because the command is a physical-layer command.
Return a Low-Speed Serial Interface to Synchronous Mode
To return to the default mode (synchronous) of a low-speed serial interface on a Cisco 2520 through Cisco 2523 router, perform the following task in interface configuration mode:
Task
|
Command
|
Return the interface to its default mode, which is synchronous.
|
no physical-layer
|
Configure a Null Interface
The Cisco IOS software supports a "null" interface. This pseudo-interface functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic; encapsulation always fails. The only interface configuration command that you can specify for the null interface is no ip unreachables.
The null interface provides an alternative method of filtering traffic. You can avoid the overhead involved with using access lists by directing undesired network traffic to the null interface.
To specify the null interface, perform the following task in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface null 0
|
Specify null 0 (or null0) as the interface type and number. The null interface can be used in any command that has an interface type as an argument. The following example configures a null interface for IP route 127.0.0.0:
ip route 127.0.0.0 255.0.0.0 null 0
Configure a Packet OC-3 Interface
The Cisco Packet over SONET Interface Processor (POSIP) for Cisco 7500 and Cisco RSP/7000 routers provides a single 155.520-Mbps, OC-3 physical layer interface for packet-based traffic. This OC-3 interface is fully compatible with SONET and Synchronous Digital Hierarchy (SDH) network facilities and is compliant with RFC 1619, "PPP over SONET/SDH," and RFC 1662, "PPP in HDLC-like Framing."
describes the default values set in the initial configuration of a Packet OC-3 interface.
Table 3 Packet OC-3 Interface Default Configuration
Attribute
|
Default Value
|
Maximum transmission unit (MTU)
|
4470 bytes
|
Framing
|
SONET STS-3c framing
|
Loopback internal
|
No internal loopback
|
Loopback line
|
No line loopback
|
Transmit clocking
|
Recovered receive clock
|
Enabling
|
Shut down
|
Because the Packet OC-3 interface is partially configured, you might not need to change its configuration before enabling it. However, when the router is powered up, a new Packet OC-3 interface is shut down. To enable the Packet OC-3 interface, you must enter the no shutdown command in the global configuration mode.
Packet OC-3 Interface Configuration Task List
The values of all Packet OC-3 configuration parameters can be changed to match your network environment. Perform the optional tasks in the following sections if you need to customize the POSIP configuration:
•
Select a Packet OC-3 Interface
•
Set the MTU Size
•
Configure Framing
•
Configure an Interface for Internal Loopback
•
Configure an Interface for Line Loopback
•
Set the Source of the Transmit Clock
•
Enable the Packet OC-3 Interface
•
Assign a Network Protocol Address
•
Save the Configuration
For Packet OC-3 interface configuration examples, see the "Packet OC-3 Interface Configuration Examples" section, later in this chapter.
Select a Packet OC-3 Interface
The Packet OC-3 interface is referred to as posi in the configuration commands. An interface is created for each POSIP found in the system at reset time.
If you need to change any of the default configuration attributes or otherwise reconfigure the Packet OC-3 interface, first complete the following task in global configuration mode:
Task
|
Command
|
Select the Packet OC-3 interface and enter interface configuration mode.
|
interface posi slot/port
|
Set the MTU Size
To set the maximum transmission unit (MTU) size for the interface, complete the following task in interface configuration mode:
Task
|
Command
|
Set the MTU size.
|
mtu bytes
|
The value of the bytes argument is in the range 64 to 4470 bytes; the default is 4470 bytes. (4470 bytes exactly matches FDDI and HSSI interfaces for autonomous switching.) The no form of the command restores the default.
Configure Framing
To configure framing on the Packet OC-3 interface, complete one of the following tasks in interface configuration mode:
Task
|
Command
|
Select SDH STM-1 framing.
|
posi framing-sdh
|
Revert to the default SONET STS-3c framing.
|
no posi framing-sdh
|
Configure an Interface for Internal Loopback
With the loopback internal command, packets from the router are looped back in the framer. Outgoing data gets looped back to the receiver without actually being transmitted. With the loopback line command, the receive (RX) fiber is logically connected to the transmit fiber (TX) so that packets from the remote router are looped back to it. Incoming data gets looped around and retransmitted without actually being received.
To enable or disable internal loopback on the interface, complete one of the following tasks in interface configuration mode:
Task
|
Command
|
Enable internal loopback.
|
loop internal
|
Disable internal loopback.
|
no loop internal
|
Local loopback is useful for checking that the POSIP is working. Packets from the router are looped back in the framer.
Configure an Interface for Line Loopback
Line loopback is used primarily for debugging purposes.
To enable or disable an interface for line loopback, complete one of the following tasks in interface configuration mode:
Task
|
Command
|
Enable line loopback.
|
loop line
|
Disable line loopback.
|
no loop line
|
The receive fiber (RX) is logically connected to the transmit fiber (TX) so that packets from the remote router are looped back to it.
Set the Source of the Transmit Clock
By default, the Packet OC-3 interface uses the recovered receive clock to provide transmit clocking. To change the transmit clock source, complete one of the following tasks in interface configuration mode:
Task
|
Command
|
Set the internal clock as the transmit clock source.
|
posi internal-clock
|
Set the recovered receive clock to provide transmit clocking.
|
no posi internal-clock
|
Enable the Packet OC-3 Interface
To enable the Packet OC-3 interface when it is first installed or after it has been disabled, complete the following task in interface configuration mode:
Task
|
Command
|
Enable the interface.
|
no shutdown
|
Assign a Network Protocol Address
You can now enter one or more network protocol addresses and otherwise configure the interface for LAN or WAN uses. For example, if IP routing is enabled on the system, perform the following task in interface configuration mode:
Task
|
Command
|
Assign an IP address and subnet mask to the interface.
|
ip address ip-address mask
|
For more information about LAN network protocol configuration, see the relevant volume and chapter of the Network Protocols Configuration Guide. For information about WAN configuration, see the Wide-Area Networking Configuration Guide.
Save the Configuration
To save the new configuration to memory, complete the following task in privileged EXEC mode.
Task
|
Command
|
Write the new configuration to memory.
|
copy running-config startup-config
|
Configure a Synchronous Serial Interface
Synchronous serial interfaces are supported on the following serial network interface cards or systems:
•
The high-speed synchronous serial interface on the Cisco 2500 series and Cisco 3000 series
•
The two-port or four-port serial NPM on the Cisco 4000 series
•
The Fast Serial Interface Processor (FSIP) on the Cisco 7000 series and Cisco 7500 series with four or eight channel-independent, synchronous serial ports that support full-duplex operation at DS-1 (1.544 Mbps) and E-1 (2.048 Mbps) speeds
Each port supports any of the available interface types (EIA/TIA-232, EIA/TIA-449, V.35, X.21, EIA-530, and G.703), and each can be configured individually to operate with either internal or external timing signals (except the EIA-530 interfacce, which is DTE only).
Synchronous Serial Task List
Perform the tasks in the following sections to configure a synchronous serial interface. The first task is required; the remaining tasks are optional.
•
Specify a Synchronous Serial Interface
•
Specify Synchronous Serial Encapsulation
•
Configure PPP
•
Configure Compression of LAPB Data
•
Configure Compression of HDLC Data
•
Invoke ATM over a Serial Line
•
Configure the CRC
•
Use the NRZI Line-Coding Format
•
Enable the Internal Clock
•
Invert the Transmit Clock Signal
•
Set Transmit Delay
•
Configure DTR Signal Pulsing
•
Ignore DCD and Monitor DSR as Line Up/Down Indicator
•
Specify the Serial Network Interface Module Timing
•
Specify G.703 Interface Options
Specify a Synchronous Serial Interface
To specify a synchronous serial interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface serial number
|
Begin interface configuration for the Cisco 7000 or Cisco 7200 series.
|
interface serial slot/port
|
Begin interface configuration for the Cisco 7500 series.
|
interface serial slot/port-adapter/port
|
Begin interface configuration for a channelized T1 or E1 interface.
|
interface serial slot/port:channel-group (Cisco 7000 series) interface serial number:channel-group (Cisco 4000 series)
|
Specify Synchronous Serial Encapsulation
By default, synchronous serial lines use the High-Level Data Link Control (HDLC) serial encapsulation method, which provides the synchronous framing and error detection functions of HDLC without windowing or retransmission. The synchronous serial interfaces support the following serial encapsulation methods:
•
Asynchronous Transfer Mode-Data Exchange Interface (ATM-DXI)
•
High-Level Data Link Control (HDLC)
•
Frame Relay
•
Point-to-Point Protocol (PPP)
•
Synchronous Data Link Control (SDLC)
•
Switched Multimegabit Data Services (SMDS)
•
Cisco Serial Tunnel (STUN)
•
X.25-based encapsulations
You can define the encapsulation method by performing the following task in interface configuration mode:
Task
|
Command
|
Configure synchronous serial encapsulation.
|
encapsulation {atm-dxi | hdlc | frame-relay | ppp | sdlc-primary | sdlc-secondary | smds | stun | x25}
|
Encapsulation methods are set according to the type of protocol or application you configure in the Cisco IOS software. ATM-DXI is described in this chapter in the section "Invoke ATM over a Serial Line." PPP is described in the "Configure PPP for Wide-Area Networking" chapter. The remaining encapsulation methods are defined in their respective books and chapters describing the protocols or applications. Serial encapsulation methods are also discussed in the Configuration Fundamentals Command Reference in the chapter "Interface Commands" under the encapsulation command.
By default, synchronous interfaces operate in full-duplex mode. To configure an SDLC interface for half-duplex mode, perform the following task in interface configuration mode:
Task
|
Command
|
Configure an SDLC interface for half-duplex mode.
|
half-duplex
|
BSC is a half-duplex protocol. Each block of transmission is acknowledged explicitly. To avoid the problem associated with simultaneous transmission, there is an implicit role of primary and secondary station. The primary resends the last block if there is no response from the secondary within the period of block receive timeout.
To configure the serial interface for full-duplex mode, perform the following task in interface configuration mode:
Task
|
Command
|
Specify that the interface can run BSC using switched RTS signals.
|
full-duplex
|
Configure PPP
To configure PPP, see the "Configuring PPP for Wide-Area Networking" chapter of the Wide-Area Networking Configuration Guide.
Configure Compression of LAPB Data
You can configure point-to-point software compression on serial interfaces that use Link Access Procedure, Balanced (LAPB) or multi-LAPB encapsulation. Compression reduces the size of a LAPB or multi-LAPB frame via lossless data compression. The compression algorithm used is a predictor algorithm (the RAND algorithm), which uses a compression dictionary to predict the next character in the frame.
Compression is performed in software and might significantly affect system performance. Cisco recommends that you disable compression if the router CPU load exceeds 65 percent. To display the CPU load, use the show process cpu EXEC command.
Predictor compression is recommended when the bottleneck is caused by the load on the router or access server; Stacker compression is recommended when the bottleneck is the result of line bandwidth. Compression is not recommended if the majority of your traffic is already compressed files. Compression is also not recommended for line speeds greater than T1; the added processing time slows performance on fast lines.
If the majority of your traffic is already compressed files, do not use compression.
To configure compression over LAPB, perform the following tasks in interface configuration mode:
Task
|
Command
|
Step 1 Enable encapsulation of a single protocol on the serial line.
|
encapsulation lapb
|
Step 2 Enable compression.
|
compress [predictor | stac]
|
To configure compression over multi-LAPB, perform the following tasks in interface configuration mode:
Task
|
Command
|
Step 1 Enable encapsulation of multiple protocols on the serial line.
|
encapsulation lapb multi
|
Step 2 Enable compression.
|
compress [predictor | stac]
|
When you are using compression, adjust the MTU for the serial interface and the LAPB N1 parameter as in the following example, to avoid informational diagnostics regarding excessive MTU or N1 sizes:
For information about configuring X.25 TCP/IP header compression and X.25 payload compression, see the "Configuring X.25 and LAPB" chapter in the Wide-Area Networking Configuration Guide.
Configure Compression of HDLC Data
You can configure point-to-point software compression on serial interfaces that use HDLC encapsulation. Compression reduces the size of a HDLC frame via lossless data compression. The compression algorithm used is a Stacker (LZS) algorithm.
Compression is performed in software and might significantly affect system performance. We recommend that you disable compression if CPU load exceeds 65 percent. To display the CPU load, use the show process cpu EXEC command.
If the majority of your traffic is already compressed files, you should not use compression.
To configure compression over HDLC, perform the following tasks in interface configuration mode:
Task
|
Command
|
Step 1 Enable encapsulation of a single protocol on the serial line.
|
encapsulation hdlc
|
Step 2 Enable compression.
|
compress stac
|
Invoke ATM over a Serial Line
If you have an ATM DSU, you can invoke ATM over a serial line. You do so by mapping an ATM virtual path identifier (VPI) and virtual channel identifier (VCI) to a DXI frame address. ATM-DXI encapsulation defines a data exchange interface that allows a DTE (such as a router) and a DCE (such as an ATM DSU) to cooperate to provide a User-Network Interface (UNI) for ATM networks.
To invoke ATM over a serial line, perform the following tasks in interface configuration mode:
Task
|
Command
|
Step 1 Specify the encapsulation method.
|
encapsulation atm-dxi
|
Step 2 Map a given VPI and VCI to a DXI frame address.
|
dxi map protocol address vpi vci [broadcast] 1
|
You can also configure the dxi map command on a HSSI interface.
To configure an ATM interface using an AIP card, see the "Configuring ATM" chapter in the Wide-Area Networking Configuration Guide.
Configure the CRC
The cyclic redundancy check (CRC) on a serial interface defaults to a length of 16 bits. To change the length of the CRC to 32 bits on an FSIP or HIP of the Cisco 7000 series only, complete the following task in interface configuration mode:
Task
|
Command
|
Set the length of the CRC.
|
crc size
|
Use the NRZI Line-Coding Format
All FSIP interface types on the Cisco 7000 support nonreturn-to-zero (NRZ) and nonreturn-to-zero inverted (NRZI) format. This is a line-coding format that is required for serial connections in some environments. NRZ encoding is most common. NRZI encoding is used primarily with RS-232 connections in IBM environments.
The default configuration for all serial interfaces is NRZ format. The default is no nrzi-encoding. To enable NRZI format, complete the following task in interface configuration mode:
Task
|
Command
|
Enable NRZI encoding format.
|
nrzi-encoding
|
Enable the Internal Clock
When a DTE does not return a transmit clock, use the following interface configuration command on the Cisco 7000 series to enable the internally generated clock on a serial interface:
Task
|
Command
|
Enable the internally generated clock on a serial interface.
|
transmit-clock-internal
|
Invert the Transmit Clock Signal
Delays between the SCTE clock and data transmission indicate that the transmit clock signal might not be appropriate for the interface rate and length of cable being used. Different ends of the wire may have variances that differ slightly. Invert the clock signal to compensate for these factors by completing the following task in interface configuration mode on a Cisco 7000 series, Cisco 7200 series, and Cisco 7500 series router:
Task
|
Command
|
Invert the clock signal on an interface.
|
invert-transmit-clock
|
Set Transmit Delay
It is possible to send back-to-back data packets over serial interfaces faster than some hosts can receive them. You can specify a minimum dead time after transmitting a packet to alleviate this condition. This setting is available for serial interfaces on the MCI and SCI interface cards and for the HSSI or MIP. Perform one of the following tasks, as appropriate for your system, in interface configuration mode:
Task
|
Command
|
Set the transmit delay on the MCI and SCI synchronous serial interfaces.
|
transmitter-delay microseconds
|
Set the transmit delay on the HSSI or MIP.
|
transmitter-delay hdlc-flags
|
Configure DTR Signal Pulsing
You can configure pulsing DTR signals on all serial interfaces. When the serial line protocol goes down (for example, because of loss of synchronization) the interface hardware is reset and the DTR signal is held inactive for at least the specified interval. This function is useful for handling encrypting or other similar devices that use the toggling of the DTR signal to resynchronize. To configure DTR signal pulsing, perform the following task in interface configuration mode:
Task
|
Command
|
Configure DTR signal pulsing.
|
pulse-time seconds
|
Ignore DCD and Monitor DSR as Line Up/Down Indicator
This task applies to Quad Serial NIM interfaces on the Cisco 4000 series and Hitachi-based serial interfaces on the Cisco 2500 series and Cisco 3000 series.
By default, when the serial interface is operating in DTE mode, it monitors the Data Carrier Detect (DCD) signal as the line up/down indicator. By default, the attached DCE device sends the DCD signal. When the DTE interface detects the DCD signal, it changes the state of the interface to up.
In some configurations, such as an SDLC multidrop environment, the DCE device sends the Data Set Ready (DSR) signal instead of the DCD signal, which prevents the interface from coming up. To tell the interface to monitor the DSR signal instead of the DCD signal as the line up/down indicator, perform the following task in interface configuration mode:
Task
|
Command
|
Configure the serial interface to monitor the DSR signal as the line up/down indicator.
|
ignore-dcd
|
Specify the Serial Network Interface Module Timing
On Cisco 4000 series routers, you can specify the serial Network Interface Module timing signal configuration. When the board is operating as a DCE and the DTE provides terminal timing (SCTE or TT), you can configure the DCE to use SCTE from the DTE. When running the line at high speeds and long distances, this strategy prevents phase shifting of the data with respect to the clock.
To configure the DCE to use SCTE from the DTE, perform the following task in interface configuration mode:
Task
|
Command
|
Configure the DCE to use SCTE from the DTE.
|
dce-terminal-timing enable
|
When the board is operating as a DTE, you can invert the TXC clock signal it gets from the DCE that the DTE uses to transmit data. Invert the clock signal if the DCE cannot receive SCTE from the DTE, the data is running at high speeds, and the transmission line is long. Again, this prevents phase shifting of the data with respect to the clock.
To configure the interface so that the router inverts the TXC clock signal, perform the following task in interface configuration mode:
Task
|
Command
|
Specify timing configuration to invert TXC clock signal.
|
dte-invert-txc
|
Specify G.703 Interface Options
This section describes the optional tasks for configuring a G.703 serial interface (a serial interface that meets the G.703 electrical and mechanical specifications and operates at E1 data rates). G.703 interfaces are available on port adapters for the Fast Serial Interface Processor (FSIP) on a Cisco 4000 series or Cisco 7000 series router.
•
Enable Framed Mode
•
Enable CRC4 Generation
•
Use Time Slot 16 for Data
•
Specify a Clock Source
Enable Framed Mode
G.703 interfaces have two modes of operation: framed and unframed. By default, G.703 serial interfaces are configured for unframed mode. To enable framed mode, perform the following task in interface configuration mode:
Task
|
Command
|
Enable framed mode.
|
timeslot start-slot - stop-slot
|
To restore the default, use the no form of this command or set the starting time slot to 0.
Enable CRC4 Generation
By default, the G.703 CRC4, which is useful for checking data integrity while operating in framed mode, is not generated. To enable generation of the G.703 CRC4, perform the following task in interface configuration mode:
Task
|
Command
|
Enable CRC4 generation.
|
crc4
|
Use Time Slot 16 for Data
By default, time slot 16 is used for signaling. It can also be used for data. To specify the use of time slot 16 for data, perform the following task in interface configuration mode:
Task
|
Command
|
Specify that time slot 16 is used for data.
|
ts16
|
Specify a Clock Source
A G.703 interface can clock its transmitted data from either its internal clock or from a clock recovered from the line's receive data stream. By default, the interface uses the line's receive data stream. To control which clock is used, perform the following task in interface configuration mode:
Task
|
Command
|
Specify the clock used for transmitted data.
|
clock source {line | internal}
|
Configure a Token Ring Interface
Cisco supports Token Ring interfaces as follows:
•
On the Cisco 2500 series fixed-configuration routers, one or two Token Ring interfaces.
•
On the Cisco 4000 series routers, the 1-port or 2-port 4/16-Mbps Token Ring cards, which interconnect network servers to IEEE 802.5 and IBM-compatible Token Ring media at speeds of 4 or 16 Mbps. The Token Ring cards are NP-1RV2, and NP-2R (dual port).
•
On the Cisco 7000 series and Cisco 7500 series, the high-speed Token Ring Interface Processor (TRIP) that has two or four DB-9 ports and interconnects network servers to IEEE 802.5 and IBM-compatible Token Ring media.
•
On the Cisco 7000 series, Cisco 7200 series, and Cisco 7500 series with the Versatile Interface Processor (VIP) or second-generation Versatile Interface Processor (VIP2), multiport Token Ring port adapters that plug into the VIP or VIP2 board. The port adapters support both 4-Mbps and 16-Mbps Token Ring operations at wire speed (25 Kpps at 16 Mbps).
The Token Ring interface supports both routing (Layer 3 switching) and source-route bridging (Layer 2 switching). Routing and bridging function on a per-protocol basis. For example, IP traffic could be routed while SNA traffic is bridged. Routing features enhance source-route bridges.
The Token Ring MIB variables support the specification in RFC 1231, "IEEE 802.5 Token Ring MIB," by K. McCloghrie, R. Fox, and E. Decker, May 1991. The mandatory Interface Table and Statistics Table are implemented, but the optional Timer Table of the Token Ring MIB is not. The Token Ring MIB has been implemented for the TRIP.
Use the show interfaces, show controllers token, and show controllers cbus EXEC commands to display the Token Ring numbers. These commands provide a report for each ring that Cisco IOS software supports.
Note
If the system receives an indication of a cabling problem from a Token Ring interface, it puts that interface into a reset state and does not attempt to restart it. It functions this way because periodic attempts to restart the Token Ring interface drastically affect the stability of routing tables. Once you have again plugged the cable into the MAU, restart the interface by entering the clear interface tokenring command, where the number argument is the interface number.
By default, the Token Ring interface uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface.
Token Ring Task List
Perform the tasks in the following sections to configure a Token Ring interface. The first task is required; the remaining tasks are optional.
•
Specify a Token Ring Interface
•
Enable Early Token Release
•
Configure PCbus Token Ring Interface Management
Specify a Token Ring Interface
To specify a Token Ring interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface tokenring number
|
Begin interface configuration for the Cisco 7000 or Cisco 7200 series.
|
interface tokenring slot/port
|
Begin interface configuration for the Cisco 7500 series.
|
interface tokenring slot/port-adapter/port
|
Enable Early Token Release
Cisco Token Ring interfaces support early token release, a method whereby the interface releases the token back onto the ring immediately after transmitting rather than waiting for the frame to return. This feature can help to increase the total bandwidth of the Token Ring. To configure the interface for early token release, perform the following task in interface configuration mode:
Task
|
Command
|
Enable early token release.
|
early-token-release
|
Configure PCbus Token Ring Interface Management
The Token Ring interface on the AccessPro PC card can be managed by a remote LAN manager over the PCbus interface. Currently, the LanOptics Hub Networking Management software running on an IBM-compatible PC is supported.
To enable LanOptics Hub Networking Management of a PCbus Token Ring interface, perform the following task in interface configuration mode:
Task
|
Command
|
Enable PCbus LAN management.
|
local-lnm
|
Configure a Tunnel Interface
Tunneling provides a way to encapsulate arbitrary packets inside of a transport protocol. This feature is implemented as a virtual interface to provide a simple interface for configuration. The tunnel interface is not tied to specific "passenger" or "transport" protocols, but rather, it is an architecture that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme. Because tunnels are point-to-point links, you must configure a separate tunnel for each link.
Tunneling has three primary components:
•
Passenger protocol, which is the protocol you are encapsulating (AppleTalk, Banyan VINES, CLNP, DECnet, IP, or IPX)
•
Carrier protocol, which is one of the following encapsulation protocols:
•
Generic route encapsulation (GRE), Cisco's multiprotocol carrier protocol
•
Cayman, a proprietary protocol for AppleTalk over IP
•
EON, a standard for carrying CLNP over IP networks
•
NOS, IP over IP compatible with the popular KA9Q program
•
Transport protocol, which is the protocol used to carry the encapsulated protocol (IP only)
illustrates IP tunneling terminology and concepts.
Figure 13 IP Tunneling Terminology and Concepts
To understand the process of tunneling, consider connecting two AppleTalk networks with a non-AppleTalk backbone, such as IP. The relatively high bandwidth consumed by the broadcasting of Routing Table Maintenance Protocol (RTMP) data packets can severely hamper the backbone's network performance. This problem can be solved by tunneling AppleTalk through a foreign protocol, such as IP. Tunneling encapsulates an AppleTalk packet inside the foreign protocol packet, which is then sent across the backbone to a destination router. The destination router then de-encapsulates the AppleTalk packet and, if necessary, routes the packet to a normal AppleTalk network. Because the encapsulated AppleTalk packet is sent in a directed manner to a remote IP address, bandwidth usage is greatly reduced. Furthermore, the encapsulated packet benefits from any features normally enjoyed by IP packets, including default routes and load balancing.
Advantages of Tunneling
There are several situations where encapsulating traffic in another protocol is useful:
•
To provide multiprotocol local networks over a single-protocol backbone
•
To provide workarounds for networks containing protocols that have limited hop counts; for example, AppleTalk (see )
•
To connect discontinuous subnetworks
•
To allow virtual private networks across wide-area networks (WANs)
Figure 14 Providing Workarounds for Networks with Limited Hop Counts
Special Considerations
The following are considerations and precautions to observe when you configure tunneling:
•
Encapsulation and decapsulation at the tunnel end points are slow operations; in general, only processor switching is supported. However, fast switching of GRE tunnels was introduced in version 11.1 for the Cisco 2500 series and the Cisco 4000 series of routers.
•
Consider security and topology issues. Be careful not to violate access control lists. You can configure a tunnel with a source and destination that are not restricted by firewall routers.
•
Tunneling might create problems with transport protocols with limited timers (for example, DECnet) due to increased latency.
•
Be aware of the environments across which you create tunnels. You might be tunneling across fast FDDI rings or through slow 9600-bps phone lines; some passenger protocols behave poorly in mixed media networks.
•
Multiple point-to-point tunnels can saturate the physical link with routing information.
•
Routing protocols that make their decisions based solely on hop count will often prefer a tunnel over a multipoint real link. A tunnel might appear to be a one-hop, point-to-point link and have the lowest-cost path, but may actually cost more. For example, in the topology shown in
, packets from Host 1 will travel across networks w, q, and z to get to Host 2 instead of taking the path w, x, y, z because it "appears" shorter.
Figure 15 Tunnel Precautions: Hop Counts
•
An even worse problem will occur if routing information from the tunneled network mixes with the transport networks' information. In this case, the best path to the "tunnel destination" is via the tunnel itself. This is called a recursive route and will cause the tunnel interface to temporarily shut down. To avoid recursive routing problems, keep passenger and transport network routing information disjointed:
•
Use a different AS number or tag.
•
Use a different routing protocol.
•
Use static routes to override the first hop (but watch for routing loops).
•
If you see line protocol down, as in the following example, it might be because of a recursive route:
%TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routing
IP Tunneling Task List
If you want to configure IP tunneling, you must perform the tasks in the following sections.
•
Specify the Tunnel Interface
•
Configure the Tunnel Source
•
Configure the Tunnel Destination
The tasks in the following tunnel configuration sections are optional.
•
Configure the Tunnel Mode
•
Configure End-to-End Checksumming
•
Configure a Tunnel Identification Key
•
Configure a Tunnel Interface to Drop Out-of-Order Datagrams
•
Configure Asynchronous Host Mobility
For commands that monitor IP tunnels, see the section "Monitor and Maintain the Interface" later in this chapter. For examples of configuring tunnels, see the section "IP Tunneling Examples" at the end of this chapter.
Specify the Tunnel Interface
To specify a tunnel interface and enter interface configuration mode, perform one of the following tasks in global configuration mode:
Task
|
Command
|
Begin interface configuration.
|
interface tunnel number
|
Begin interface configuration for the Cisco 7000 series.
|
interface tunnel slot/port
|
Configure the Tunnel Source
You must specify the tunnel interface's source address by performing the following task in interface configuration mode:
Task
|
Command
|
Configure the tunnel source.
|
tunnel source {ip-address | type number}
|
Note
You cannot have two tunnels using the same encapsulation mode with exactly the same source and destination address. The workaround is to create a loopback interface and source packets off of the loopback interface.
Configure the Tunnel Destination
You must specify the tunnel interface's destination by performing the following task in interface configuration mode:
Task
|
Command
|
Configure the tunnel destination.
|
tunnel destination {hostname | ip-address}
|
Configure the Tunnel Mode
The encapsulation mode for the tunnel interface defaults to generic route encapsulation (GRE), so this task is considered optional. However, if you want a mode other than GRE, you must configure it by performing the following task in interface configuration mode:
Task
|
Command
|
Configure the tunnel mode.
|
tunnel mode {aurp | cayman | dvmrp | eon | gre ip | nos}
|
If you are tunneling AppleTalk, you must use either the AppleTalk Update Routing Protocol (AURP), Cayman or GRE tunneling mode. Cayman tunneling is designed by Cayman Systems and enables routers and access servers to interoperate with Cayman GatorBoxes. You can have Cisco devices at either end of the tunnel, or you can have a GatorBox at one end and Cisco router or access server at the other end. Use Distance Vector Multicast Routing Protocol (DVMRP) mode when a router or access server connects to a mrouted router to run DVMRP over a tunnel. It is required to configure Protocol-Independent Multicast (PIM) and an IP address on a DVMRP tunnel.
Caution 
Do not configure a Cayman tunnel with an AppleTalk network address.
If you use GRE, you must have only Cisco routers or access servers at both ends of the tunnel connection. When you use GRE to tunnel AppleTalk, you must configure an AppleTalk network address and a zone. Perform the following tasks to tunnel AppleTalk using GRE:
Task
|
Command
|
Step 1 Enable tunneling on the interface.
|
interface tunnel number
|
Step 2 Assign a cable range to an interface.
|
appletalk cable-range start-end [network.node]1
|
Step 3 Set a zone name for the connected AppleTalk network.
|
appletalk zone zone-name2
|
Step 4 Specify the interface out which the encapsulated packets will be sent, or specify the router's IP address.
|
tunnel source {ip-address | type}
|
Step 5 Specify the IP address of the router at the far end of the tunnel.
|
tunnel destination {ip-address | hostname}
|
Step 6 Enable GRE tunneling.
|
tunnel mode gre ip
|
Configure End-to-End Checksumming
Some passenger protocols rely on media checksums to provide data integrity. By default, the tunnel does not guarantee packet integrity. By enabling end-to-end checksums, the Cisco IOS software drops corrupted packets. To enable such checksums on a tunnel interface, perform the following task in interface configuration mode:
Task
|
Command
|
Configure end-to-end checksumming.
|
tunnel checksum
|
Configure a Tunnel Identification Key
You can optionally enable an ID key for a tunnel interface. This key must be set to the same value on the tunnel endpoints. Tunnel ID keys can be used as a form of weak security to prevent misconfiguration or injection of packets from a foreign source.
The tunnel ID key is available with GRE only.
Note
When using GRE, the ID key is carried in each packet. We do not recommend relying on this key for security purposes.
To configure a tunnel ID key, perform the following task in interface configuration mode:
Task
|
Command
|
Configure a tunnel identification key.
|
tunnel key key-number
|
Configure a Tunnel Interface to Drop Out-of-Order Datagrams
You can optionally configure a tunnel interface to drop datagrams that arrive out of order. This is useful when carrying passenger protocols that behave poorly when they receive packets out of order (for example, LLC2-based protocols). This option is available with GRE only.
To use this option, perform the following task in interface configuration mode:
Task
|
Command
|
Configure a tunnel interface to drop out-of-order datagrams.
|
tunnel sequence-datagrams
|
Configure Asynchronous Host Mobility
Increasingly, remote users are accessing networks through dial-up telephone connections. In contrast to local users who can connect directly into the network, remote users must first dial into an access server.
The access server supports a packet tunneling strategy that extends the internetwork—in effect creating a virtual private link for the mobile user. When a user activates asynchronous host mobility, the access server on which the remote user dials into becomes a remote point-of-presence (POP) for the user's home network. Once logged in, users experience a server environment identical to the one that they experience when they connect directly to the "home" access server.
Once the network layer connection is made, data packets are tunneled at the physical and/or data link layer instead of at the protocol layer. In this way, raw data bytes from dial-in users are transported directly to the "home" access server, which processes the protocols.
illustrates the implementation of asynchronous host mobility on an extended internetwork. A mobile user connects to an access server on the internetwork and, by activating asynchronous host mobility, is connected to a "home" access server configured with the appropriate username. The user sees an authentication dialog or prompt from the "home" system and can proceed as if he or she were connected directly to that device.
Figure 16 Asynchronous Host Mobility
The remote user implements asynchronous host mobility by executing the tunnel command in the User EXEC mode. The tunnel command sets up a network layer connection to the specified destination. The access server accepts the connection, attaches it to a virtual terminal (VTY), and runs a command parser capable of running the normal dial-in services. After the connection is established, data is transferred between the modem and network connection with a minimum of interpretations. When communications are complete, the network connection can be closed and terminated from either end.
Refer to the Cisco Access Connection Guide for information about setting up the network layer connection with the tunnel command.
Understand Subinterfaces
Configuring multiple virtual interfaces, or subinterfaces, on a single physical interface allows greater flexibility and connectivity on the network. A subinterface is a mechanism that allows a single physical interface to support multiple logical interfaces or networks. That is, several logical interfaces or networks can be associated with a single hardware interface. Subinterfaces are implemented in various WAN and LAN protocols, including ATM, Frame Relay, SMDS, X.25, and Novell IPX. For more information about using subinterfaces, refer to the appropriate protocol chapter.
Note
The Cisco IOS software can support a maximum of 255 interfaces and subinterfaces.
Configure Features Available on Any Interface
The following sections describe optional tasks that you can perform on any type of interface:
•
Add a Description for an Interface
•
Configure MOP
•
Control Interface Hold-Queue Limits
•
Set Bandwidth
•
Set Interface Delay
•
Adjust Timers
•
Limit Transmit Queue Size
•
Adjust Maximum Packet Size or MTU Size
Add a Description for an Interface
You can add a description about an interface to help you remember what is attached to it. This description is meant solely as a comment to help identify what the interface is being used for. The description will appear in the output of the following commands: show configuration, show running-config, and show interfaces. When you add a description for a T1 controller interface, it will appear in the output of the show controllers t1 and show running-config commands.
To add a description for any interface but a T1 or E1 controller interface, perform the following task in interface configuration mode. To add a description for a T1 or E1 controller in a Cisco 4500 series, or Cisco 7000 series, or Cisco 7200 series router, perform the following task in controller configuration mode:
Task
|
Command
|
Add a description for an interface.
|
description string
|
For examples of adding interface descriptions, see the section "Interface Description Examples" at the end of this chapter.
Configure MOP
You can enable MOP on an interface by performing the following task in interface configuration mode:
Task
|
Command
|
Enable MOP.
|
mop enabled
|
You can enable an interface to send out periodic MOP system identification messages on an interface by performing the following task in interface configuration mode:
Task
|
Command
|
Enable MOP message support.
|
mop sysid
|
Control Interface Hold-Queue Limits
Each interface has a hold-queue limit. This limit is the number of data packets that the interface can store in its hold queue before rejecting new packets. When the interface empties one or more packets from the hold queue, it can accept new packets again. You can specify the hold-queue limit of an interface in interface configuration mode as follows:
Task
|
Command
|
Specify the maximum number of packets allowed in the hold queue.
|
hold-queue length {in | out}
|
Set Bandwidth
Higher-level protocols use bandwidth information to make operating decisions. For example, IGRP uses the minimum path bandwidth to determine a routing metric. TCP adjusts initial retransmission parameters based on the apparent bandwidth of the outgoing interface. Perform the following task in interface configuration mode to set a bandwidth value for an interface:
Task
|
Command
|
Set a bandwidth value.
|
bandwidth kilobits
|
The bandwidth setting is a routing parameter only; it does not affect the physical interface.
Set Interface Delay
Higher-level protocols might use delay information to make operating decisions. For example, IGRP can use delay information to differentiate between a satellite link and a land link. To set a delay value for an interface, perform the following task in interface configuration mode:
Task
|
Command
|
Set a delay value for an interface.
|
delay tens-of-microseconds
|
Setting the delay value sets an informational parameter only; you cannot adjust the actual delay of an interface with this configuration command.
Adjust Timers
To adjust the frequency of update messages, perform the following task in interface configuration mode:
Task
|
Command
|
Adjust the frequency with which the Cisco IOS software sends messages to itself (Ethernet and Token Ring) or to the other end (HDLC-serial and PPP-serial links) to ensure that a network interface is alive for a specified interface.
|
keepalive [seconds]
|
You also can configure the keepalive interval, the frequency at which the Cisco IOS software sends messages to itself (Ethernet and Token Ring) or to the other end (HDLC-serial, PPP-serial), to ensure that a network interface is alive. The interval in some previous software versions was 10 seconds; it is now adjustable in one-second increments down to one second. An interface is declared down after three update intervals have passed without receiving a keepalive packet.
When adjusting the keepalive timer for a very low bandwidth serial interface, large packets can delay the smaller keepalive packets long enough to cause the line protocol to go down. You might need to experiment to determine the best value.
Limit Transmit Queue Size
You can control the size of the transmit queue available to a specified interface on the MCI and SCI cards. To limit the size, perform the following task in interface configuration mode:
Task
|
Command
|
Limit the size of the transmit queue.
|
tx-queue-limit number
|
Adjust Maximum Packet Size or MTU Size
Each interface has a default maximum packet size or maximum transmission unit (MTU) size. This number generally defaults to 1500 bytes. On serial interfaces, the MTU size varies, but cannot be set smaller than 64 bytes. To adjust the maximum packet size, perform the following task in interface configuration mode:
Task
|
Command
|
Adjust the maximum packet size or MTU size.
|
mtu bytes
|
Caution 
Changing an MTU size on a Cisco 7500 router will result in recarving of buffers and resetting of all interfaces. The following message is displayed:
%RSP-3-Restart:cbus complex
Understand Online Insertion and Removal (OIR)
The online insertion and removal (OIR) feature—supported on the Cisco 7000 series, the Cisco 7200 series, and the Cisco 7500 series routers only—allows you to remove and replace interface processors while the system is on line. You can shut down the interface processor before removal and restart it after insertion without causing other software or interfaces to shut down.
Note
Do not remove or install more that one interface processor at one time. After a removal or installation, observe the LEDs before continuing.
You do not need to notify the software that you are going to remove or install an interface processor. When the route processor is notified by the system that an interface processor has been removed or installed, it stops routing and scans the system for a configuration change. All interface processors are initialized, and each interface type is verified against the system configuration; then the system runs diagnostics on the new interface. There is no disruption to normal operation during interface processor insertion or removal.
Only an interface of a type that has been configured previously will be brought on line; others require configuration. If a newly installed interface processor does not match the system configuration, the interface is left in an administratively down state until the system operator configures the system with the new interfaces.
Hardware (MAC-level) addresses for all interfaces on the Cisco 7000 routers are stored on an electronically erasable programmable read-only memory (EEPROM) component in the Route Processor (RP) instead of on the individual interface boards. On the Cisco 7000, an address allocator in the EEPROM contains a sequential block of 40 addresses (5 interface slots times a maximum of 8 possible ports per slot; each address is assigned to a specific slot and port address in the chassis, regardless of how the interfaces are configured. On the Cisco 7200 series, hardware addresses are stored in a midplane EEPROM that supports 1024 addresses per box.
Storage of hardware addresses in EEPROM allows interfaces to be replaced online without requiring the system to update routing tables and data structures. Regardless of the types of interfaces installed, the hardware addresses do not change unless you replace the system RP. If you do replace the RP, the hardware addresses of all ports change to those specified in the address allocator on the new RP.
Understand Fast, Autonomous, and SSE Switching Support
Switching is the process by which packets are forwarded. The Cisco IOS software supports four kinds of switching: process switching, fast switching, autonomous switching, and silicon switching.
Monitor and Maintain the Interface
You can perform the tasks in the following sections to monitor and maintain the interfaces:
•
Monitor Interface and Controller Status
•
Monitor the T1 or E1 Controller
•
Monitor and Maintain CSU/DSU Service Modules
•
Monitor the LAN Extender Interface
•
Monitor and Maintain a Hub
•
Monitor IP Tunnels
•
Clear and Reset the Interface
•
Shut Down and Restart the Interface
•
Configure Loopback Detection
•
Run Interface Loopback Diagnostics
Monitor Interface and Controller Status
The software contains commands that you can enter at the EXEC prompt to display information about the interface including the version of the software and the hardware, the controller status, and statistics about the interfaces. The following table lists some of the interface monitoring tasks. (You can display the full list of show commands by entering the show ? command at the EXEC prompt.) These commands are fully described in the Configuration Fundamentals Command Reference.
Perform the following commands in EXEC mode:
Task
|
Command
|
Display the status of the asynchronous interface.
|
show async status show interfaces async
|
Display compression statistics on a serial interface.
|
show compress
|
Display current internal status information for the interface controller cards.
|
show controllers {bri | cbus | fddi | lance | mci | serial | token}
|
Display information about the Switch Processor (SP) controller on the Cisco 7000 series and Cisco 7500 series.
|
show controllers cbus
|
Display current internal status information for the interface controller cards on the Cisco 4000 series.
|
show controllers {e1 | ethernet | fastethernet | fddi | serial | t1 | token}
|
Display current internal status information for the interface controller cards on the Cisco 7000 series.
|
show controllers {e1 | ethernet | fastethernet | fddi | serial | t1 | token}
|
Display current internal status information for the interface controller cards on the Cisco 7200 series and Cisco 7500 series routers,
|
show controllers {ethernet | fastethernet | fddi | serial | token}
|
Display diagnostic information about the controller, interface processor, and port adapters associated with a specified slot of a Cisco 7000 series, Cisco 7200 series, or Cisco 7500 series router.
|
show diagbus [slot]
|
Display the number of packets of each protocol type that have been sent through the interface.
For the Cisco 7000 series, Cisco 7200 series, and for the Cisco RSP/7000 and Cisco 7500 series with a Packet over SONET Interface Processor.
For the Cisco 7000 and Cisco 7500 series with VIP or VIP2 cards.
|
show interfaces [type number] [first] [last] [accounting]
show interfaces [type slot/port] [accounting]
show interfaces [type slot/port-adapter/port] [accounting]
|
Display information about the Cisco 7500 or Cisco RSP/7000 with a Packet over SONET Interface Processor.
|
show interfaces posi [slot/port]
|
Display the number of packets of each protocol type that have been sent through the asynchronous serial line.
|
show interfaces async [number] [accounting]
|
Display the currently running configuration in RAM.
|
show running-config
|
Display the current contents of the routing information field (RIF) cache.
|
show rif
|
Display the global (system-wide) and interface-specific status of any configured Level 3 protocol.
|
show protocols
|
Display the hardware configuration, software version, the names and sources of configuration files, and the boot images.
|
show version1
|
Monitor the T1 or E1 Controller
This section applies to the Cisco 4000 series, the Cisco 7000 series, and the Cisco 7500 series only. Because the T1 or E1 link itself is viewed as the controller, perform the following task in EXEC mode to display information about activity on the T1 or E1 line.
Task
|
Command
|
Display information about the T1 link.
|
show controller t1
|
Display information about the E1 link.
|
show controller e1
|
Alarms, line conditions, and other errors are displayed. The data is updated every 10 seconds. Every 15 minutes, the cumulative data is stored and retained for 24 hours. This means at any one time, up to 96 15-minute accumulations are counted in the data display.
Monitor and Maintain CSU/DSU Service Modules
This section describes how to monitor and maintain service modules on Cisco 2524 and Cisco 2525 routers. It describes the following tasks:
•
Reset the CSU/DSU
•
Perform a Self-Test
•
Display a Performance Report
•
Perform Loopback Tests
Reset the CSU/DSU
To reset the CSU/DSU, perform the following task in privileged EXEC mode:
Task
|
Command
|
Reset the CSU/DSU. Specify the interface type and number.
|
clear service-module interface
|
Use this command only in severe circumstances (for example, when the router is not responding to a CSU/DSU configuration command).
This command terminates all DTE and line loopbacks that are locally or remotely configured. It also interrupts data transmission through the router for up to 15 seconds. The software performs an automatic software reset in case of two consecutive configuration failures.
The CSU/DSU module is not reset with the clear interface command.
Caution 
If you experience technical difficulties with your router and intend to contact customer support, refrain from using this command. The command erases the router's past CSU/DSU performance statistics. To clear only the CSU/DSU performance statistics, issue the clear counters command.
Perform a Self-Test
To perform a self-test on the integrated CSU/DSU, perform the following task in privileged EXEC mode:
Task
|
Command
|
Perform a self test. Specify the interface type and number.
|
test service-module interface
|
This command cannot be used if a DTE, line, or remote loopback is in progress. A series of tests are performed on the CSU/DSU, which include a ROM checksum test, RAM test, EEPROM checksum test, flash checksum test, and a DTE loopback with an internal pattern test. This self-test is also performed at power on.
Data transmission is interrupted for five seconds when you issue this command. To view the output of the most recent self-test, enable the show service-module command.
Display a Performance Report
To display the performance report for an integrated CSU/DSU, perform one of the following tasks in privileged EXEC mode:
Tasks
|
Command
|
Display a performance report. Choose either serial interface 1 or 0.
|
show service-module interface
|
Display the CSU/DSU performance statistics for the past 24 hours. This command applies only to the FT1/T1 module.
|
show service-module interface performance-statistics [interval-range]
|
The interval-range value specifies the number of 15-minute intervals displayed in the report. You can choose a range from 1 to 96, where each value represents the CSU/DSU activity performed in that 15-minute interval. For example, a range of 2-3 displays the performance statistics for the intervals two and three.
Perform Loopback Tests
You can loop packets back to the network from the integrated CSU/DSU, loop packets to DTE, and loop packets through a local CSU/DSU to a remote CSU/DSU.
Perform Loopback Line
To loop data received from the line at the local CSU/DSU back to the line, perform the following tasks in interface configuration mode:
Task
|
Command
|
Perform loopback at a point close to the network to CSU/DSU interface.
|
loopback line
|
Perform loopback at a point close to the interface between the CSU/DSU and the router.
|
loopback line payload
|
Packets are looped from an incoming network transmission back into the network at a CSU or DSU loopback point.
When the loopback line command is configured on the 2-wire 56-kbps CSU/DSU module or the 4-wire 56/64-kbps CSU/DSU modules installed on a Cisco 2524 or Cisco 2525 router, the network data loops back at the CSU and the router data loops back at the DSU. If the CSU/DSU is configured for switched mode, you must have an established connection to perform a payload-line loopback. When the loopback line payload command is configured, the CSU/DSU module loops the data through the DSU portion of the module. Data is not looped back to the serial interface.
If you enable the loopback line command on the fractional T1/T1 module, the CSU/DSU performs a full-bandwidth loopback through the CSU portion of the module and data transmission through the serial interface is interrupted for the duration of the loopback. No reframing or corrections of bipolar violation errors or cyclic redundancy check (CRC) errors are performed. When you configure the line loopback payload command on the FT1/T1 module, the CSU/DSU performs a loopback through the DSU portion of the module. The line loopback payload command reframes the data link, regenerates the signal, and corrects bipolar violations and Extended Super Frame CRC errors.
When performing a T1-line loopback with Extended Super Framing, communication over the facilities data link is interrupted but performance statistics are still updated. To show interfaces currently in loopback operation, use the show service-module EXEC command.
Enable Loopback DTE
To loop packets back to DTE from within the local CSU/DSU, perform the following task:
Task
|
Command
|
Loop packets to DTE.
|
loopback dte
|
Packets are looped from within the CSU/DSU back to the serial interface of the router. Send a test ping to see if the packets successfully looped back. To cancel the loopback test, use the no loopback dte command.
When using the 4-wire 56/64-kbps CSU/DSU module, an out-of-service signal is transmitted to the remote CSU/DSU.
Perform Loopback Remote (Interface) Using the FT1/T1 CSU/DSU Module
This command applies only when the remote CSU/DSU device is configured for this function. It is used for testing the data communication channels along with or without remote CSU/DSU circuitry. The loopback is usually performed at the line port, rather than the DTE port, of the remote CSU/DSU.
On the integrated FT1/T1 CSU/DSU module installed on a Cisco 2524 and Cisco 2525 router, the loopback remote full command sends the loopup code to the remote CSU/DSU. The remote CSU/DSU performs a full-bandwidth loopback through the CSU portion of the module. The loopback remote payload command sends the loopup code on the configured timeslots, while maintaining the D4-ExtendedSuper Framing. The remote CSU/DSU performs the equivalent of a loopback line payload request. The remote CSU/DSU loops back only those timeslots that are configured of the remote end. This loopback reframes the data link, regenerates the signal, and corrects bipolar violations and Extended Super Frame CRC errors. The loopback remote smart-jack command sends a loopup code to the remote smart jack. You cannot put the local smart jack into loopback.
To loop packets on the integrated FT1/T1 CSU/DSU module, perform the following task:
Task
|
Command
|
Loop packets at a remote CSU/DSU using the fractional T1/T1 CSU/DSU module.
|
loopback remote {full | payload | smart-jack} [0in1 | 1in1 | 1in2 | 1in5 | 1in8 | 3in24 | qrw | user-pattern 24bit-binary value]
|
Failure to loop up or initiate a remote loopback request could be caused by enabling the no service-module t1 remote-loopback command or having an alternate remote-loopback code configured on the remote end. When the loopback is terminated, the result of the pattern test is displayed.
Note
If the FT1/T1 CSU/DSU module is configured to provide internal clocking, the module ceases to generate clocking when it is placed into loopback.
2- and 4-Wire 56/64-kbps CSU/DSU Modules
This command applies only when the remote CSU/DSU device is configured for this function. It is used for testing the data communication channels along with or without remote CSU/DSU circuitry. The loopback is usually performed at the line port, rather than the DTE port, of the remote CSU/DSU.
On the 2- and 4-wire 56/64-kbps CSU/DSU modules installed on a Cisco 2524 or Cisco 2525 router, an active connection is required before a loopup can be initiated while in switched mode. When transmitting V.54 loopbacks, the remote device is commanded into loopback using V.54 messages. Failure to loop up or initiate a remote loopback request could be caused by enabling the no service-module 56k remote-loopback command.
To loop packets at the remote CSU/DSU, perform the following task:
Task
|
Command
|
Loop packets at a remote CSU/DSU using the 2- and 4-wire 56/64-kbps CSU/DSU modules.
|
loopback remote [2047 | 511 | stress-pattern pattern number]
|
To show interfaces currently in loopback operation, use the show interfaces loopback EXEC command.
Monitor the LAN Extender Interface
To monitor the LAN Extender interface, the Ethernet interface that resides on the LAN Extender, the serial interface that resides on the LAN Extender, or the serial interface connected to the LAN Extender, perform one or more of the following tasks at the EXEC prompt:
Task
|
Command
|
Display hardware and software information about the LAN Extender.
Display information on the Cisco 7000 series.
|
show controllers lex [number]
show controllers lex [slot/port]
|
Display statistics about the LAN Extender interface.
|
show interfaces lex number [ethernet | serial]
|
Display statistics about the serial interface on the host router that is physically connected to the LAN Extender.
Display statistics on the Cisco 7000 series.
|
show interfaces serial number [accounting]
show interfaces serial slot/port [accounting]
|
For more complete network troubleshooting information, refer to the Troubleshooting Internetworking Systems publication.
Monitor and Maintain a Hub
You can perform the tasks in the following sections to monitor and maintain the hub:
•
Shut Down the Hub Port
•
Reset the Hub or Clear the Hub Counters
•
Monitor the Hub
Shut Down the Hub Port
To shut down or disable a hub port, perform the following tasks, beginning in global configuration mode:
Task
|
Command
|
Specify the hub number and the hub port (or range of hub ports) and place you in hub configuration mode.
|
hub ethernet number port [end-port]
|
Shut down the hub port.
|
shutdown
|
See the examples of shutting down a hub port at the end of this chapter in "Hub Configuration Examples."
Reset the Hub or Clear the Hub Counters
To reset the hub or clear the hub counters, perform one of the following tasks in EXEC mode:
Task
|
Command
|
Reset and reinitialize the hub hardware.
|
clear hub ethernet number
|
Clear the hub counters displayed by the show hub command.
|
clear hub counters [ethernet number [port [end-port]]]
|
Monitor the Hub
To display hub information, perform the following task in EXEC mode:
Task
|
Command
|
Display hub statistics.
|
show hub [ethernet number [port [end-port]]]
|
Monitor IP Tunnels
Complete any of the following tasks in EXEC mode to monitor the IP tunnels you have configured:
Task
|
Command
|
List tunnel interface information.
|
show interfaces tunnel unit [accounting]
|
List the routes that go through the tunnel.
|
show protocol route 1
|
List the route to the tunnel destination.
|
show ip route 2
|
Clear and Reset the Interface
To clear the interface counters shown with the show interfaces command, enter the following command at the EXEC prompt:
Task
|
Command
|
Clear the interface counters.
|
clear counters [type number] [ethernet | serial]
|
Clear interface counters for the FastEthernet NIM on the Cisco 4000 series or Cisco 4500 series.
|
clear counters fastethernet number
|
Clear interface counters for the Cisco 7000 or Cisco 7200 series.
|
clear counters [type slot/port]
|
Clear interface counters for the Cisco 7000 and Cisco 7500 with VIP or VIP2 Interface Processors.
|
clear counters [type slot/port-adaptor]
|
The command clears all the current interface counters from the interface unless the optional arguments are specified to clear only a specific interface type from a specific slot and port number.
Note
This command will not clear counters retrieved using SNMP, but only those seen with the EXEC show interfaces command.
Complete the following tasks in EXEC mode to clear and reset interfaces. Under normal circumstances, you do not need to clear the hardware logic on interfaces.
Task
|
Command
|
Reset the hardware logic on an interface.
|
clear interface type number
|
Reset the hardware logic on an asynchronous serial line.
|
clear line [number]1
|
Clear the entire Token Ring RIF cache.
|
clear rif-cache
|
Shut Down and Restart the Interface
You can disable an interface. Doing so disables all functions on the specified interface and marks the interface as unavailable on all monitoring command displays. This information is communicated to other network servers through all dynamic routing protocols. The interface will not be mentioned in any routing updates. On serial interfaces, shutting down an interface causes the DTR signal to be dropped. On Token Ring interfaces, shutting down an interface causes the interface to deinsert from the ring. On FDDIs, shutting down an interface causes the optical bypass switch, if present, to go into bypass mode.
To shut down an interface and then restart it, perform the following tasks in interface configuration mode:
Command
|
Task
|
Shut down an interface.
|
shutdown
|
Reenable an interface.
|
no shutdown
|
To check whether an interface is disabled, use the EXEC command show interfaces. An interface that has been shut down is shown as administratively down in the show interfaces command display. See examples in the section "Interface Shutdown Examples" at the end of this chapter.
One reason to shut down an interface is if you want to change the electrical interface type or mode of a Cisco 7000 series port online. You replace the serial adapter cable and use software commands to restart the interface, and if necessary, reconfigure the port for the new interface. At system startup or restart, the FSIP polls the interfaces and determines the electrical interface type of each port (according to the type of port adapter cable attached). However, it does not necessarily repoll an interface when you change the adapter cable online. To ensure that the system recognizes the new interface type, shut down using the