|
Use the information in this chapter to understand the types of interfaces supported on our routers. Our routers support two types of interfaces: physical and virtual interfaces. The types of physical interfaces in a router depend on its appliques or interface processors. The virtual interfaces our routers support include subinterfaces and IP tunnels.
Our routers support the following types of interfaces:
In addition, our routers support subinterfaces. See the wide-area networking chapters and the protocol chapters in this guide for specific information on how to configure a subinterface for a particular protocol.
For hardware technical descriptions and information about installing router 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 Router Products Command Reference publication.
You can perform the tasks in the following sections to configure and maintain the interfaces supported on our routers:
See the end of this chapter for "Interface Configuration Examples."
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 added to a system and can be displayed with the show interfaces EXEC command. A report is provided for each interface the router supports, as seen in the following partial sample display:
Use the show hardware EXEC command to see a list of the system software and hardware.
For example, to begin configuring serial interface 0, you would add the following line to the configuration file:
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.
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.
This section describes how to configure low-speed serial interfaces on Cisco 2520 through Cisco 2523 routers. It describes these tasks in the following sections:
The following section describes the communication between half-duplex DTE transmit and receive state machines and half-duplex DCE transmit and receive state machines.
As shown in Figure 1, 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.
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 Figure 2, 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 whoes 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.
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.
As shown in Figure 3, 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.
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 transitions through the following states:
1 ) The state machine transitions 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 transitions to the wait transmit finish state, where it waits for the transmit FIFO to empty.
3 ) Once the FIFO empties, the DCE transitions 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 Figure 4, 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.)
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.
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.
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 |
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 |
The following example shows how to change to controlled-carrier mode from the default of constant-carrier operation:
Router(config)#interface serial 2
Router(config-if)#half-duplex controlled-carrier
The following example shows how to change to constant-carrier mode from controlled-carrier mode:
Router(config)#interface serial 2
Router(config-if)#no half-duplex controlled-carrier
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:
The following examples show how to set the cts-delay timer to 1234 ms and the transmit-delay timer to 50 ms.
Router(config)#interface serial 2
Router(config-if)#half-duplex timer cts-delay 1234
Router(config-if)#half-duplex timer transmit-delay 50
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:
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.
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 |
The following example shows how to change a low-speed serial interface from synchronous to asynchronous mode:
Router(config)#interface serial 2
Router(config-if)#physical-layer async
The following examples show how to change a low-speed serial interface from asynchronous mode back to its default synchronous mode:
Router(config)#interface serial 2
Router(config-if)#physical-layer sync
Router(config)#interface serial 2
Router(config-if)#no physical-layer
The following example shows some typical asynchronous interface configuration commands:
Router(config)#interface serial 2
Router(config-if)#physical-layer async
Router(config-if)#ip address 1.0.0.2 255.0.0.0
Router(config-if)#async default ip address 1.0.0.1
Router(config-if)#async mode dedicated
Router(config-if)#async default routing
The following example shows some typical synchronous serial interface configuration commands available when the interface is in synchronous mode:
Router(config)#interface serial 2
Router(config-if)#physical-layer sync
Router(config-if)#ip address 1.0.0.2 255.0.0.0
Router(config-if)#no keepalive
Router(config-if)#ignore-dcd
Router(config-if)#nrzi-encoding
Router(config-if)#no shutdown
All of our router platforms configured with an auxiliary port support the asynchronous serial interface. To configure an asynchronous serial interface on the router, you must establish asynchronous serial line connections using PPP or SLIP. PPP and SLIP define methods of sending Internet packets over a standard RS-232 asynchronous serial line. PPP also defines methods for sending IPX packets.
To use the asynchronous device as a network interface via PPP or SLIP, complete the tasks in the following sections:
The auxiliary port's absolute line number is 1. When you configure an asynchronous serial interface with the interface async 1 command, you enable asynchronous routing over the auxiliary port to support PPP and SLIP connections to remote routers. The interface number is the same as the absolute line number.
The router automatically associates the interface number 1 with the absolute line number 1 of the auxiliary port, and treats the interface as an asynchronous line. However, to configure the auxiliary 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 entitled "Configuring Terminal Lines and Modem Support." Follow 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 the auxiliary port line as an asynchronous interface:
Task | Command |
---|---|
Specify an asynchronous serial interface. | interface async 1 |
Only IP packets can be sent across lines configured for SLIP. PPP supports transmission of both IP and IPX packets.
There are two asynchronous serial encapsulation methods:
SLIP and PPP are methods of encapsulating datagrams and other network-layer protocol information over point-to-point links. SLIP is the default method. Perform the following task in interface configuration mode to configure PPP or SLIP encapsulation on the asynchronous interface:
Task | Command |
---|---|
Configure PPP or SLIP encapsulation on an asynchronous line. | encapsulation {ppp | slip} |
The configured SLIP or PPP encapsulation method applies to an interface configured for dedicated asynchronous mode or dial-on-demand routing (DDR). On an asynchronous interface configured for interactive mode, the encapsulation type is specified by the user with the slip or ppp EXEC command. See the "Configure Dedicated or Interactive Mode" section later in this section.
In order to use SLIP or PPP, the router must be configured with an IP routing protocol or with the ip host-routing command. This configuration is done automatically if you are using old-style slip address commands. However, you must configure it manually if you configure SLIP or PPP via the interface async command.
See the section "Configure PPP" in the section "Configure a Synchronous Serial Interface" later in this chapter for more information about PPP.
You can control whether a user must specify an address when making a SLIP or PPP connection or whether the address is forced by the system. Using an address defined by the system is referred to as default addressing. Requiring the user to specify an address is called dynamic addressing. It is common to configure an asynchronous interface both to have a default address and to allow dynamic addressing.
This section describes how to do the following:
You can assign a permanent default asynchronous address to a line by performing the following task in interface configuration mode:
Task | Command |
---|---|
Assign a default IP address to the asynchronous interface. | async default ip address ip-address |
Use the no form of this command to disable the default address.
The assigned default address is used when the user enters the slip default or ppp default EXEC command. The TACACS server validates the transaction (when enabled), and the line is put into network mode using the address that is in the configuration file. This feature is useful when the user is not required to know the IP address to gain access to a system; for example, users of a server that is available to many students on a campus.
When a line is configured for dynamic assignment of asynchronous addresses, the user enters the slip or ppp EXEC command and is prompted for an address or logical host name. The TACACS validates the address, when enabled, and the line is assigned the given address and put into asynchronous mode. Assigning asynchronous addresses dynamically is also useful when you want to assign set addresses to users. For example, an application on a personal computer that automatically dials in using SLIP and polls for electronic mail messages can be set up to dial in periodically and enter the required IP address and password.
To configure asynchronous dynamic addressing, perform the following task in interface configuration mode:
Task | Command |
---|---|
Allow the IP address to be assigned at login. | async dynamic address |
The dynamic addressing features of the internetwork allow packets to get to their destinations and back regardless of the router or network they are sent from. For example, if a host such as a laptop computer moves from place to place, it can keep the same address no matter where it is dialing in from. For an example of configuring asynchronous dynamic addressing, see the section "Asynchronous Routing and Dynamic Addressing Example" at the end of this chapter.
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 |
You can assign IP addresses to incoming connections on an asynchronous interface without a known IP address in one of three ways:
Address pooling allows a set of IP addresses to be allocated for users without a known IP address who are dialing in to the access server. This allows a finite number of IP addresses to be reused quickly and efficiently by many clients. Additional benefits include the ability to maintain sessions, such as Telnet, even when a modem line fails. When the client is auto-dialed back into the server, the server will attempt to reissue the same IP address to the client and therefore resume the aborted session.
You can create address pools with the Dynamic Host Configuration Protocol (DHCP) suite of commands, or with the ip local-pool command. Alternately, you can assign a single IP address to be used on a specific interface by using the peer default ip-address command. This has the same effect as turning off pooling on this interface. These methods are described in the following sections.
The Dynamic Host Configuration Protocol (DHCP) model consists of the following components:
The DHCP client-proxy feature manages a pool of IP addresses available to PPP or SLIP dial-in clients without a known IP address. You can designate all of the access server's asynchronous interfaces to use DHCP or you can turn off DHCP on individual interfaces. You can also assign a specific IP address to use on a given interface. (See the section "Enable or Disable Specific IP Addresses for an Interface.") Cisco's implementation of DHCP complies with RFC 1541, and is compliant with Extended TACACS and AAA/TACACS+.
To enable DHCP address pooling on the access server's asynchronous interfaces, perform the following tasks, starting in global configuration mode:
Task | Command |
---|---|
Step 1 Specify that the access server uses the DHCP client-proxy on all asynchronous interfaces. | ip address-pool dhcp-proxy-client |
Step 2 (Optional) Specify the IP address of at least one and up to ten DHCP servers for the proxy-client (the Cisco access server) to use. DHCP servers provide temporary IP addresses. | ip dhcp-server [ip-address | name] |
Refer to "Configure DHCP Pooling Examples" for examples of these tasks.
To turn off DHCP address pooling on a specific interface, perform the following task in interface configuration mode:
Task | Command |
---|---|
Turn off DHCP on any asynchronous interfaces on the access server, as needed. | no peer default ip address |
To make temporary IP addresses available for dial-in asynchronous clients using SLIP/PPP on a per-interface basis, perform the following tasks, beginning in global configuration mode:
Task | Command |
---|---|
Step 1 Specify that the access server use a local IP address pool on all asynchronous interfaces. | ip address-pool local |
Step 2 Create one or more local IP address pools. | ip local-pool {default | poolname {begin-ip-address-range [end-ip-address-range]}} |
Step 3 (Optional) Enter interface configuration mode. | interface async interface-number |
Step 4 (Optional) If you want an interface to use an address pool other than default, specify which pool each interface uses. | peer default ip address pool poolname |
Refer to "Configure Local Pooling Example" for examples of these tasks.
To turn off local IP address pooling on a specific interface, perform the following task in interface configuration mode:
Task | Command |
---|---|
Turn off local IP address pooling on any asynchronous interfaces on the access server. | no peer default ip address |
To specify that a specific IP address be returned when an incoming connection requests an address, perform the following task in interface configuration mode:
Task | Command |
---|---|
Specify that the access server returns a specific IP address on this interface. | peer default ip address address |
You can use this command in conjunction with DHCP or local address pooling. Refer to "Configure Specific IP Addresses for an Asynchronous Interface Example " for an example of these tasks.
To turn off an IP address on a specific interface, perform the following task in interface configuration mode:
Task | Command |
---|---|
Turn off an IP address on any asynchronous interfaces on the access server. | no peer default ip address
or By re-enabling pooling on this interface (either through DHCP or through local address pooling). |
You can enable use of dynamic routing protocols on the asynchronous interface by performing the following task in interface configuration mode:
Task | Command |
---|---|
Configure an asynchronous interface for routing. | async dynamic routing |
You can use an asynchronous device as a network interface connection to a remote router via the auxiliary port using the PPP or SLIP protocols. Refer to the Cisco Access Connection Guide.
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 for an example of group and member interfaces.
Figure 6-1 illustrates the group-member interface concept.
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. All associated interfaces can then be configured through the group interface. | group-range low-end-of-range high-end-of-range |
Refer to "Group and Member Asynchronous Interfaces Examples" for an example configuration.
Member interfaces can have certain interface configurations that differ from their group. The following are valid interface configuration commands:
To define a member to have one or more interface configurations 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 |
This section describes how to configure service modules on Cisco 2524 and Cisco 2525 routers. It describes these tasks in the following sections:
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:
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} |
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 t1 data-coding normal
or no service-module t1 data-coding inverted |
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.
The following example enables super frame as the FT1/T1 frame type:
boa1(config-if)# service-module t1 framing sf
To decrease the outgoing signal strength to an optimum value for 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.
The following example shows a line build out setting of -7.5 dB:
Router1(config-if)#
service-module t1 lbo -7.5db
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 bi polar 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.
The following example specifies AMI as the line-code type:
Router(config-if)# service-module t1 linecode ami
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 |
Some user applications may transmit data that replicates remote alarms. If the line is configured to use super frame framing, this data causes false alarms at the remote end and disrupts data transmission. If the line is configured to use extended super frame framing, this data cannot cause false alarms at the remote end. In esf format, remote alarms are transmitted as out-of-band signals, which user applications cannot replicate.
To disable remote alarms, perform the following task in interface configuration mode:
Task | Command |
---|---|
Disable remote alarms. | no service-module t1 remote-alarm-enable |
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] |
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.
The following example displays two routers connected back-to-back through an FT1/T1 line:
Router(config-if)#no service-module t1 remote-loopback full
Router(config-if)#service-module t1 remote-loopback payload alternate
boa1(config-if)#loopback remote full
%SERVICE_MODULE-5-LOOPUPFAILED: Unit 0 - Loopup of remote unit failed boa1(config-if)#service-module t1 remote-loopback payload v54
boa1(config-if)#loopback remote payload
%SERVICE_MODULE-5-LOOPUPFAILED: Unit 0 - Loopup of remote unit failed boa1(config-if)#service-module t1 remote-loopback payload alternate
boa1(config-if)#loopback remote payload
%SERVICE_MODULE-5-LOOPUPREMOTE: Unit 0 - Remote unit placed in loopback
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}}} |
Timeslots 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.
The following example displays a series of timeslot ranges and a speed of 64 kbps:
Router(config-if)#service-module t1 timeslots 1-10,15-20,22 speed 64
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.
To loop data received from the line at the local CSU/DSU back to the line, perform the following task 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 bi polar violation errors or cyclic redundancy checksum (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 bi polar 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.
The following example shows how to configure a payload loopback:
Router1(config-if)#loopback line payload
Loopback in progress Router1(config-if)#no loopback line
The following example shows the output when you loop a packet in switched mode without an active connection:
Router1(config-if)#service-module 56k network-type switched
Router1(config-if)#loopback line payload
Need active connection for this type of loopback % Service module configuration command failed: WRONG FORMAT.
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.
The following example loops a packet from a module to the serial interface:
Router1(config-if)#loopback dte
Loopback in progress Router1#ping 12.0.0.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
To loop packets at the remote CSU/DSU, 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] |
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]
|
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-extended super 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 bi polar 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.
Failure to loopup 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.
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 loopup or initiate a remote loopback request could be caused by enabling the no service-module 56k remote-loopback command.
To show interfaces currently in loopback operation, use the show interfaces loopback EXEC command.
This section describes how to configure 2- and 4-wire 56/64 kbps service modules. The following tasks are described:
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 enable the line clock, which is the default.
The following example shows a router using internal clocking while transmitting frames at 38.4 kbps.
Router1(config-if)#service-module 56k clock source internal
Router1(config-if)#service-module 56k clock rate 38.4
Configure the line with the following speeds: 2.4, 4.8, 9.6, 19.2, 38.4, 56, and 64 . The 64-kbps line speed cannot be used with back-to-back digital data service (DDS) lines. The sub-rate line speeds are determined by the service provider.
Only the 56-kbps line speed is available in switched mode, which is enabled using the service-module 56k network-type interface configuration command on the 4-wire CSU/DSU. The 2-wire CSU/DSU default is set to switched mode.
The auto linespeed enables the CSU/DSU to decipher current line speed from the sealing current running on the network. Back-to-back DDS lines do not have sealing current, therefore use auto only when transmitting over telco DDS lines and the clocking source is taken from the line.
Use the no form of this command to enable a network line speed of 56 kbps, which is the default.
The following example displays two routers connected in back-to-back DDS mode. However, the configuration fails because the auto rate is used.
Router1(config-if)#service-module 56k clock source internal
Router1(config-if)#service-module 56k clock rate 38.4
Router2(config-if)#service-module 56k clock rate auto
% WARNING - auto rate will not work in back-to-back DDS. a1#ping 10.1.1.2
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) Router2(config-if)#service-module 56k clock rate 38.4
Router1#ping 10.1.1.2
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 52/54/56 ms
When transferring from DDS mode to switched mode, you must set the correct clock rate, as shown in the following example:
Router2(config-if)#service-module 56k network-type dds
Router2(config-if)#service-module 56k clock rate 38.4
Router2(config-if)#service-module 56k network-type switched
% Have to use 56k or auto clock rate for switched mode % Service module configuration command failed: WRONG FORMAT. Router2(config-if)#service-module 56k clock rate auto
% WARNING - auto rate will not work in back-to-back DDS. Router2(config-if)#service-module 56k network-type switched
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 |
---|---|
Specifies normal data transmission. | service-module 56k data-coding normal
or no service-module 56k data-coding |
The following example scrambles bit codes in 64 kbps DDS mode:
Router(config-if)#service-module 56k clock rate 56
Router(config-if)#service-module 56k data-coding scrambled
Can configure scrambler only in 64k speed DDS mode % Service module configuration command failed: WRONG FORMAT. Router(config-if)#service-module 56k clock rate 64
% WARNING - 64k mode will not work in back-to-back DDS. Router(config-if)#service-module 56k data-coding scrambled
To transmit packets in switched dial-up mode or DDS 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- and 4-wire 56/64-kbps CSU/DSU modules accept V.25 bis dial commands, which are configured using the dialer in-band command.
The following example displays transmission in switched dial-up mode:
Router(config-if)#service-module 56k clock rate 19.2
Router(config-if)#service-module 56k network-type switched
% Have to use 56k or auto clock rate for switched mode % Service module configuration command failed: WRONG FORMAT. Router(config-if)#service-module 56k clock rate auto
Router(config-if)#service-module 56k network-type switched
Router(config-if)#dialer in-band
Router(config-if)#dialer string 2576666
Router(config-if)#dialer-group 1
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.
The following example enables you to transmit and receive remote loopbacks using the service-module 56k remote-loopback command:
Router(config-if)#service-module 56k remote-loopback
Router(config-if)#
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down
%LINK-3-UPDOWN: Interface Serial0, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to up
%LINK-3-UPDOWN: Interface Serial0, changed state to up
%SERVICE_MODULE-5-LOOPUPREMOTE: Unit 0 - Remote unit placed in loopback
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.
The following example selects AT&T as the service provider:
Router(config-if)#service-module 56k network-type switched
Router(config-if)#service-module 56k switched-carrier att
See the "Configuring ATM" chapter 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" later in this chapter.
Support for channelized E1 is provided on the following platforms:
Each E1 adapter can support a maximum of 30 channel groups. The Cisco 7000 MIP can support one or two adapters, providing a maximum of 60 channel groups per MIP. The Cisco 4000 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:
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 of this manual for more information.
Using channelized E1 controller and serial interface configuration commands, you can perform the tasks in the following sections to configure channelized E1:
See the end of this chapter for "Interface Configuration Examples."
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 MIP and eight CX-MIP-CE1 interfaces. A Cisco 7010 router can have up to three MIP and six CX-MIP-CE1 interfaces. 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.
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 |
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.
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.
You can define up to 30 channel groups for each E1 adapter. You must define the timeslots that belong with each channel group. Channel groups are numbered 0 to 30, and timeslots are numbered 1 to 31. 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 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. 7
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.
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. 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 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.
Support for channelized T1 (also referred to as fractional T1) is provided on the following platforms:
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 CxCT1 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:
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 of this manual 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.
Using channelized T1 controller and serial interface configuration commands, you can perform the tasks in the following sections to configure channelized T1:
See the end of this chapter for "Interface Configuration Examples."
To configure the T1 physical characteristics, you first define the physical location of the MIP and CxCT1 in the Cisco 7000 series router. A Cisco 7000 router can have up to four MIP and eight CxCT1 interfaces. A Cisco 7010 router can have up to three MIP and six CxCT1 interfaces. 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.
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 |
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.
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.
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} |
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.
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) |
See the chapter "Configuring DDR" for information about how to configure a dialer interface.
Support for the Ethernet interface is supplied on one of the following Ethernet network interface cards or systems:
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.
Perform the tasks in the following sections to configure features on an Ethernet interface. The first task is required; the remaining tasks are optional.
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 series. | interface ethernet slot/port |
Currently, there are three common Ethernet encapsulation methods:
The encapsulation method you use depends upon the type of Ethernet media connected to the router 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.
You can specify the type of Ethernet network interface module (NIM) configuration on the Cisco 4000. 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 |
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 |
The Cisco 7000 series supports the Fast Ethernet interface if it has a Fast Ethernet Interface Processor (FEIP). The FEIP enables the router to communicate at speeds of 100 Mbps with network devices such as switches, servers, and other routers.
Use the show interfaces fastethernet command to display the Fast Ethernet slots and ports. The FEIP defaults to half-duplex mode and media type 10BaseTX.
The Fast Ethernet encapsulation methods are the same as the Ethernet encapsulation methods. See the section "Configure Ethernet Encapsulation."
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:
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.
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.
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.
Perform the tasks in the following sections to configure an FDDI interface. The first task is required; the remaining tasks are optional.
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 series. | interface fddi slot/port |
Our 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 CSC-FCI interface card or FIP.
The CSC-C2/FCIT interface card and FIP fully support transparent and translational bridging for the following configurations:
Enabling FDDI bridging encapsulation places the CSC-C2/FCIT interface or FIP into encapsulation mode when doing bridging. In transparent mode, the FCIT interface or FIP interoperates with earlier versions of the CSC-FCI encapsulating interfaces when performing bridging functions on the same ring. When using the CSC-C2/FCIT interface card or FIP, you can specify the encapsulation method by performing the following task in interface configuration mode:
Task | Command |
---|---|
Specify the encapsulation method for the CSC-C2/FCIT interface card or FIP. | fddi encapsulate |
When you are translationally bridging, you have to route routable protocols and translationally bridge the rest (such as LAT).
The CSC-FCI interfaces are always in encapsulating bridge mode, so disabling applies only to CSC-C2/FCIT interfaces.
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.
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.
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 |
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 |
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 |
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 |
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 |
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 |
Task | Command |
---|---|
Enable duplicate address checking capability. | fddi duplicate-address-check |
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] |
You can control whether the CMT onboard functions are on or off. The CSC-FCI and CSC-C2/FCIT interface cards and FIP provide 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 FCIT and 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:
To disable the CMT microcode, perform the following task in interface configuration mode:
Task | Command |
---|---|
Disable the FCIT CMT functions. | no fddi if-cmt |
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.
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 |
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 |
The High-Speed Serial Interface (HSSI) consists of the following components:
Perform the tasks in the following sections to configure an HSSI interface. The first task is required; the remaining tasks are optional.
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 |
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 section "Configure PPP" in the section "Configure a Synchronous Serial Interface" later in this chapter.
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. | atm-dxi map protocol address vpi vci [broadcast]1 |
You can also configure the atm-dxi map command on a serial interface.
To configure an ATM interface using an AIP card, see the chapter "Configuring ATM."
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 |
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:
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.
See the "Hub Configuration Examples" section the end of this chapter.
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 |
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 |
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 |
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."
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." For command information, refer to the chapter entitled "ISDN Commands" in the Router Products Command Reference publication.
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 Figure 6-2). 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 6-3 is an expanded view of Figure 6-2 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.
Figure 6-3 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.
Although there is a physical connection between the core router and the LAN Extender, what you actually manage is a remote Ethernet LAN. Figure 6-4 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 Figure 6-3 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 6-4.
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. Figure 6-5 illustrates this binding process.
To configure a LAN Extender interface, perform the tasks described in the following sections. The first task is required; the remainder are optional.
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.
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.
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 Figure 6-6.) 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.
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 Figure 6-7.) 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.
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:
When defining access lists, keep the following points in mind:
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 |
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.
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 Router Products Command Reference publication. 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.
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.
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:
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 |
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 |
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.
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 |
To reboot the LAN Extender and reload the software, perform the following task in privileged EXEC mode:
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 Flash memory on the core router or from a TFTP server or from Flash memory on the core router to the LAN Extender.
Task | Command |
---|---|
Download a software image from Flash memory on the core router. | copy flash lex number |
Download a software image from a TFTP server. | copy tftp lex number |
Download a software image from Flash memory. | copy flash lex number |
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 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 6-8).
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. Table 6-1 explains the LEDs.
For more complete network troubleshooting information, refer to the Troubleshooting Internetworking Systems publication.
You can specify a software-only interface called a loopback interface that emulates an interface that is always up. 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 for establishing a Telnet session from the router's console to its auxiliary port when all other interfaces are down. In applications where other routers will 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 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 does double duty as the Null0 interface.
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. | interface loopback slot/port |
See the section "Run Interface Loopback Diagnostics" later in this chapter.
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
Support for the synchronous serial interface is supplied on the following serial network interface cards or systems:
The MCI and SCI cards can query the appliques to determine their types for use in reports displayed by the EXEC show commands. However, they do so only at system startup, so the appliques must be attached when the system is started. Use the show interfaces and show controllers mci EXEC commands to display the serial port numbers. These commands provide a report for each interface the router supports.
Perform the tasks in the following sections to configure a synchronous serial interface. The first task is required; the remaining tasks are optional.
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 series. | interface serial slot/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) |
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:
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} |
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 |
Encapsulation methods are set according to the type of protocol or application you configure on your router. ATM-DXI is described in this chapter in the section "Invoke ATM over a Serial Line." PPP is described in the next section, "Configure PPP." The remaining methods are defined in their respective chapters describing the protocols or applications. Serial encapsulation methods are also discussed in the Router Products Command Reference publication in the chapter entitled "Interface Commands" under the encapsulation command.
The Point-to-Point Protocol (PPP), described in RFCs 1331 and 1332, is a method of encapsulating network layer protocol information over point-to-point links. You can configure PPP on the following types of interfaces:
The current implementation of PPP supports option 3, authentication using CHAP or PAP, option 4, Link Quality Monitoring and option 5, Magic Number configuration options. The software always sends option 5 and will negotiate for options 3 and 4 if so configured. All other options are rejected.
We support the following upper-layer protocols: AppleTalk, Bridging, CLNS, DECnet, IP, IPX, VINES, and XNS.
The software provides PPP as an encapsulation method. It also provides the Challenge Handshake Authentication Protocol (CHAP) and Password Authentication Protocol (PAP) on serial interfaces running PPP encapsulation. The following sections describe the tasks to configure these features.
Magic Number support is available on all serial interfaces. When using PPP, PPP will always attempt to negotiate for Magic Numbers, which are used to detect looped-back nets. The link might or might not be taken down upon looped-back detection, depending on the use of the down-when-looped command.
To configure PPP, complete the tasks in following sections, as needed for your networking applications:
You can enable PPP on serial lines to encapsulate IP and SLIP datagrams. To do so, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable PPP encapsulation. | encapsulation ppp |
PPP echo requests are used as keepalives to minimize disruptions to the end users of your network. The no keepalive command can be used to disable echo requests.
Access control using Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP) is available on all serial interfaces that use PPP encapsulation. The authentication feature reduces the risk of security violations on your router. You can configure either CHAP or PAP for the interface.
When CHAP is enabled on an interface, the local router sends a CHAP packet and the remote device (a PC, workstation, router, or router) attempting to connect to the local router or router is requested, or "challenged," to respond.
The challenge consists of an ID, a random number, and either the host name of the local router or the name of the user on the remote device. This challenge is transmitted to the remote device.
The required response consists of two parts:
When the local router receives the challenge response, it verifies the secret by looking up the name given in the response and performing the same encryption operation as indicated in the response. The secret passwords must be identical on the remote device and the local router.
Because the secret is never transmitted, other devices are prevented from stealing it and gaining illegal access to the system. Without the proper response, the remote device cannot connect to the local router.
CHAP transactions occur only at the time a link is established. The local router does not request a password during the rest of the call. (The local router can, however, respond to such requests from other devices during a call.)
To use CHAP, you must perform the following tasks:
Step 1 Enable CHAP on the interface.
Once you have enabled CHAP, the local router requires a password from remote devices. If the remote device does not support CHAP, no traffic will be passed to that device.
Step 2 Configure server host name or username authentication.
Configure the secret or password for each remote system with which authentication is required. As an alternative, you can also configure TACACS.
Perform the following tasks in interface configuration mode:
Task | Command |
---|---|
Step 1 Enable CHAP or PAP. | ppp authentication {chap | pap} [if-needed]
or |
Step 2 Configure host authentication or Configure TACACS. | username name password secret 1 ppp use-tacacs [single-line] 1 |
The optional keyword if-needed can be used only with TACACS or extended TACACS. The optional keyword list-name can only be used with AAA/TACACS+. CHAP is specified in RFC 1334. It is an additional authentication phase of the PPP Link Control Protocol.
To specify the password to be used in CHAP or PAP caller identification, perform the following task in global configuration mode:
Task | Command |
---|---|
Configure authentication. | username name password secret1 |
Make sure that this password does not contain spaces or underscores.
For an example of CHAP, see the section "CHAP with an Encrypted Password Examples" at the end of this chapter. CHAP and PAP are specified in RFC 1334, "The PPP Authentication Protocols." CHAP is specified as an additional authentication phase of the PPP Link Control Protocol.
Link Quality Monitoring (LQM) is available on all serial interfaces running PPP. LQM will monitor the link quality, and if the quality drops below a configured percentage, the link will be taken down. The percentages are calculated for both the incoming and outgoing directions. The outgoing quality is calculated by comparing the total number of packets and bytes sent with the total number of packets and bytes received by the peer. The incoming quality is calculated by comparing the total number of packets and bytes received with the total number of packets and bytes sent by the peer.
When LQM is enabled, Link Quality Reports (LQRs) are sent every keepalive period. LQRs are sent in place of keepalives. All incoming keepalives are responded to properly. If LQM is not configured, keepalives are sent every keepalive period and all incoming LQRs are responded to with an LQR.
LQR is specified in RFC 1333, "PPP Link Quality Monitoring," by William A. Simpson of Computer Systems Consulting Services.
To enable LQM on the interface, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable LQM on the interface. | ppp quality percentage |
The percentage argument specifies the link quality threshold. That percentage must be maintained, or the link is deemed to be of poor quality and taken down.
The Cisco IOS software automatically creates neighbor routes by default; that is, it automatically sets up a route to the peer address on a point-to-point interface when the PPP IPCP negotiation is completed.
To disable this default behavior or to reenable it once it has been disabled, complete the following tasks in interface configuration mode:
Task | Command |
---|---|
Disable creation of neighbor routes. | no peer neighbor-route |
Reenable creation of neighbor routes. | peer neighbor-route |
You can configure point-to-point software compression on serial interfaces that use PPP encapsulation. Compression reduces the size of a PPP frame via lossless data compression. The compression algorithm used is a predictor algorithm (the RAND algorithm), which uses a compression dictionary to predict what the next character in the frame will be.
PPP encapsulations support both predictor and Stacker compression algorithms.
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, it is recommended that you not use compression.
To configure compression over PPP, perform the following tasks in interface configuration mode:
Task | Command |
---|---|
Step 1 Enable encapsulation of a single protocol on the serial line. | encapsulation ppp |
Step 2 Enable compression. | compress [predictor | stac]
or ppp compress [predictor | stac]1 |
Although LAPB protocol overhead consumes some bandwidth, this can be offset by the use of PPP compression over the reliable link. PPP compression is separately configurable and is not required for use of a reliable link.
PPP reliable link is available only on synchronous serial interfaces, including ISDN BRI and ISDN PRI interfaces. PPP reliable link cannot be used over V.120.
To configure PPP reliable link on a specified interface, complete the following task in interface configuration mode:
Task | Command |
---|---|
Enable PPP reliable link. | ppp reliable-link |
Having reliable link enabled does not guarantee that all connections through the specified interface will in fact use reliable link. It only guarantees that the router will attempt to negotiate reliable link on this interface.
PPP reliable link does not work with Multilink PPP.
PPP reliable link is not available on asynchronous serial interfaces.
You can determine whether LAPB has been established on a connection by using the show interface command. You can troubleshoot PPP reliable link by using the debug lapb command and the debug ppp negotiations, debug ppp errors, and debug ppp packets commands.
You can configure point-to-point software compression on serial interfaces that use 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 what the next character in the frame will be.
Compression is performed in software and may 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.
Predictor compression is recommended when the bottleneck is the load on the router; Stacker compression is recommended when the bottleneck is 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 such lines.
If the majority of your traffic is already compressed files, it is recommended that you 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:
interface serial 0 encapsulation lapb compress predictor mtu 1509 lapb n1 12072
For information about configuring X.25 TCP/IP header compression and X.25 payload compression, see the chapter "Configuring X.25 and LAPB."
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 |
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 atm-dxi map command on a HSSI interface.
To configure an ATM interface using an AIP card, see the chapter "Configuring ATM."
Task | Command |
---|---|
Set the length of the CRC. | crc size |
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 |
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 |
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:
Task | Command |
---|---|
Invert the clock signal on an interface. | invert-transmit-clock |
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 |
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 |
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 |
You can configure the clock rate for appliques (connector hardware) on the serial interface of the MCI and SCI cards to an acceptable bit rate. To do so, perform the following task in interface configuration mode:
Task | Command |
---|---|
Configure the clock rate on serial interfaces. | clock rate bps |
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 |
This section describes the optional tasks for configuring a G.703-E1 interface on a Cisco 4000 router or Cisco 7000 series router.
G.703-E1 interfaces have two modes of operation: framed and unframed. By default, G.703-E1 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.
By default, the G.703-E1 CRC4 is not generated. To enable generation of the G.703-E1 CRC4, which is useful for checking data integrity while operating in framed mode, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable CRC4 generation. | crc4 |
By default, time slot 16 is used for signaling. It can also be used for data. To control 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 |
A G.703-E1 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 applique 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} |
Support for the Token Ring interface is supplied on one of our Token Ring network interface cards:
The Token Ring interface supports both routing (Layer 3 switching) and source-route bridging (Layer 2 switching). The use of routing and bridging is on a per-protocol basis. For example, IP traffic could be routed while SNA traffic is bridged. The routing support interacts correctly with source-route bridges.
Support for the Token Ring MIB variables is provided as described 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 supported by the router.
The Token Ring interface by default uses the SNAP encapsulation format defined in RFC 1042. It is not necessary to define an encapsulation method for this interface.
Perform the tasks in the following sections configure a Token Ring interface. The first task is required; the remaining tasks are optional, unless you are configuring a Token Ring on the CSC-1R or CSC-2R, in which case you must also select a Token Ring speed.
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 series. | interface tokenring slot/port |
The Token Ring interface on the CSC-1R and CSC-2R can run at either 4 or 16 Mbps. These Token Ring interfaces do not default to any particular ring speed; you must select the speed the first time you use them.
Configure the ring speed on the CSC-1R or CSC-2R Token Ring interfaces by performing the following task in interface configuration mode:
Task | Command |
---|---|
Select the ring speed. | ring-speed speed |
Our 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 |
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 |
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:
Figure 6-9 illustrates 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.
There are several situations where encapsulating traffic in another protocol is useful:
The following are considerations and precautions to observe when configuring tunneling:
%TUN-RECURDOWN Interface Tunnel 0 temporarily disabled due to recursive routing
If you want to configure IP tunneling, you must perform at least the first three tasks in the following sections. The remaining tunnel configuration tasks are optional.
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.
Task | Command |
---|---|
Begin interface configuration. | interface tunnel number |
Begin interface configuration for the Cisco 7000 series. | interface tunnel slot/port |
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} |
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} |
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 to interoperate with Cayman GatorBoxes. You can have our routers at either end of the tunnel, or you can have a GatorBox at one end and our router at the other end. Use Distance Vector Multicast Routing Protocol (DVMRP) mode when a router 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.
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 |
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 routers will drop 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 |
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.
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 |
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 |
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.
Point-to-point interfaces must be able to provide a remote node with its IP address through the IP Control Protocol (IPCP) address negotiation process. The IP address can be obtained from a variety of sources. The address can be configured through the command line, entered with an EXEC-level command, or provided by TACACS+, DHCP, or from a locally administered pool.
IP address pooling provides a pool of IP addresses from which an incoming interface can provide an IP address to a remote node through the IP Control Protocol (IPCP) address negotiation process. It also enhances the flexibility of configuration by allowing multiple types of pooling to be active simultaneously.
The IP address pooling feature now allows configuration of a global default address pooling mechanism, a per-interface configuration of the mechanism to use, and a per-interface configuration of a specific address or pool name to use.
A peer IP address can be allocated to an interface through several methods:
The following precedence rules of peer IP address support determine which address is used. Precedence is listed from highest to lowest:
This feature is available on all asynchronous serial, synchronous serial, ISDN BRI, and ISDN PRI interfaces running PPP or SLIP.
The IP address pooling feature now allows configuration of a global default address pooling mechanism, a per-interface configuration of the mechanism to use, and a per-interface configuration of a specific address or pool name to use.
You can define the IP address pooling mechanism to be used on router interfaces as described in the following sections:
The Global Default Mechanism applies to all point-to-point interfaces (asynchronous, synchronous, ISDN BRI, ISDN PRI, and dialer interfaces) that support PPP encapsulation and that are not configured for IP address pooling. You can define the Global Default Mechanism to be either DHCP or local address pooling.
To configure the Global Default Mechanism for IP address pooling, perform the tasks in one of following sections:
After you have defined a Global Default Mechanism, you can disable it on a specific interface by configuring the interface for some other pooling mechanism. You can define a local pool other than the default pool for the interface or you can configure the interface with a specific IP address to be used for dial-in peers.
The Dynamic Host Configuration Protocol (DHCP) specifies the following components:
To enable DHCP as the Global Default Mechanism, complete the following tasks in global configuration mode:
Task | Command |
---|---|
Step 1 Specify DHCP client-proxy as the Global Default Mechanism. | ip address-pool dhcp-proxy-client |
Step 2 (Optional) Specify the IP address of a DHCP server for the proxy client to use. | ip dhcp-server [ip-address | name] |
In Step 2, you can provide as few as one or as many as ten DHCP servers for the proxy-client (the Cisco router or access server) to use. DHCP servers provide temporary IP addresses.
To specify local pooling as the Global Default Mechanism to use, complete the following tasks in global configuration mode:
If no other pool is defined, the local pool called default is used.
When you have defined a Global Default Mechanism for assigning IP addresses to dial-in peers, you can then configure the few interfaces for which it is important to have a nondefault configuration.
You can define a nondefault address pool for use by this specific interface, you can define DHCP on this interface even if you have defined local pooling as the Global Default Mechanism, or you can specify one IP address to be assigned to all dial-in peers on this interface.
To define a nondefault address pool for use on this interface, perform the following tasks beginning in global configuration mode:
To define DHCP as the IP address mechanism for this interface, complete the following tasks beginning in global configuration mode:
Task | Command |
---|---|
Specify the interface and enter interface configuration mode. | interface type number |
Specify DHCP as the IP address mechanism on this interface. | peer default ip address pool dhcp |
To define a specific IP address to be assigned to all dial-in peers on this interface, complete the following tasks beginning in global configuration mode:
Task | Command |
---|---|
Specify the interface and enter interface configuration mode. | interface type number |
Specify the IP address to assign. | peer default ip address ip-address |
The following sections describe optional tasks that you can perform on any type of 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 controller interface, perform the following task in interface configuration mode. To add a description for a T1 controller interface, 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 Descriptions Examples" at the end of this chapter.
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 |
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} |
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.
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.
To adjust the frequency of update messages, perform the following task in interface configuration mode:
You also can configure the keepalive interval, the frequency at which the router 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.
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 |
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 |
%RSP-3-Restart:cbus complex
The dial backup service provides protection against WAN downtime by allowing you to configure a backup serial line via a circuit-switched connection.
To configure dial backup, associate a secondary serial interface as a backup to a primary serial interface. This feature requires that an external modem, CSU/DSU device, or ISDN terminal adapter (TA) attached to a circuit-switched service be connected on the secondary serial interface. The external device must be capable of responding to a DTR signal (DTR active) by auto-dialing a connection to a preconfigured remote site.
The dial backup software keeps the secondary line inactive (DTR inactive) until one of the following conditions is met:
These conditions are defined using the interface configuration commands described later in this section.
When the software detects a lost Carrier Detect signal from the primary line device or finds that the line protocol is down, it activates DTR on the secondary line. At that time, the modem, CSU/DSU, or ISDN TA must be set to dial the remote site. When that connection is made, the routing protocol defined for the serial line will continue the job of transmitting traffic over the dialup line.
You can also configure the dial backup feature to activate the secondary line based upon traffic load on the primary line.
The software monitors the traffic load and computes a five-minute moving average. If this average exceeds the value you set for the line, the secondary line is activated, and depending upon how the line is configured, some or all of the traffic will flow onto the secondary dialup line.
You can also specify a value that defines when the secondary line should be disabled and the amount of time the secondary line can take going up or down.
To configure dial backup, perform the following tasks in interface configuration mode:
Task | Command |
---|---|
Step 1 Select a serial interface as a backup line. Select a serial interface on a Cisco 7000. | backup interface serial number backup interface serial slot/port |
Step 2 Enter the load as a percentage of the primary line's available bandwidth. | backup load {enable-threshold | never} {disable-load | never} |
Step 3 Define how much time should elapse before a secondary line is set up or taken down (after a primary line transitions). | backup delay {enable-delay | never} {disable-delay | never} |
See examples of configuring dial backup service in the sections "Dial Backup Service When the Primary Line Goes Down Examples," "Dial Backup Service When the Primary Line Reaches Threshold Examples," and "Dial Backup Service When the Primary Line Exceeds Threshold Examples" at the end of this chapter. See also the chapter "Configuring DDR."
When an interface has a backup interface configured, it is often desirable that the backup interface be enabled when the primary interface is either down or in loopback. By default, the backup is only enabled if the primary interface is down. By using the down-when-looped command, the backup interface will also be enabled if the primary interface is in loopback. To achieve this condition, perform the following task in interface configuration mode:
Task | Command |
---|---|
Configure an interface to tell the system it is down when loopback is detected. | down-when-looped |
If testing an interface with the loopback command, you should not have loopback detection configured, or packets will not be transmitted out the interface that is being tested.
The Cisco 7000 series online insertion and removal (OIR) feature allows you to remove and replace CxBus 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.
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 are stored on an electronically erasable programmable read-only memory (EEPROM) component in the Route Processor (RP) instead of on the individual interface boards. 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. This 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.
Switching is the process by which packets in a router are forwarded. Our routers support four kinds of switching: process switching, fast switching, autonomous switching, and silicon switching. For more information about switching and about which platforms, interfaces, and protocols support which types of switching, refer to the "Switching" appendix in the Router Products Command Reference publication.
You can perform the tasks in the following sections to monitor and maintain the interfaces:
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 Router Products Command Reference publication.
Perform the following commands in EXEC mode:
Task | Command |
---|---|
Display the status of the asynchronous interface. | show async status |
Display compression statistics on a serial interface. | show compress |
Display current internal status information for the interface controller cards.
For the Cisco 7000 or Cisco 4000 series. | show controllers {bri | cbus | fddi | lance | mci | serial | token}
show controllers {cxbus | fddi | serial | e1 | t1 | token} |
Display the number of packets of each protocol type that have been sent through the interface.
For the Cisco 7000. | show interfaces [type {number}] [first] [last] [accounting]
show interfaces [type slot/port] [accounting] |
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 current contents of the routing information field (RIF) cache. | show rif |
Display the hardware configuration, software version, the names and sources of configuration files, and the boot images. | show version1 |
This section applies to the Cisco 7000 series only. The port adapter cable connected to each port determines the electrical interface type and mode of the port. The default mode of the ports is DCE, which allows you to perform a loopback test on any port without having to attach a port adapter cable. Although DCE is the default, there is no default clock rate set on the interfaces. When there is no cable attached to a port, the software actually identifies the port as "Universal, Cable Unattached" rather than either as a DTE or DCE interface.
Use the show controller cxbus command to show information about the interface port. The following example shows an interface port (2/0) that has an RS-232 DTE cable attached and a second port (2/1) that does not have a cable attached:
Cisco 7000# show controller cxbus
Switch Processor 7, hardware version 11.1 microcode version 1.4
512 Kbytes of main memory, 128 Kbytes cache memory, 299 1520 byte buffers
Restarts: 0 line down, 0 hung output, 0 controller error
FSIP 2, hardware version 3, microcode version 1.0
Interface 16 - Serial2/0, electrical interface is RS-232 DTE
31 buffer RX queue threshold, 101 buffer TX queue limit, buffer size 1520
Transmitter delay is 0 microseconds
Interface 17 -Serial2/1, electrical interface is Universal (cable unattached)
31 buffer RX queue threshold, 101 buffer TX queue limit, buffer size 1520
This section applies to the Cisco 7000 series only. Because the T1 or E1 line 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 line. | show controller t1 |
Display information about the E1 line. | 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.
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.
You can perform the tasks in the following sections to monitor and maintain the hub:
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."
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]]] |
To display hub information, perform the following task in EXEC mode:
Task | Command |
---|---|
Display hub statistics. | show hub [ethernet number [port [end-port]]] |
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 |
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 Cisco 7000. | clear counters [type slot/port] |
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.
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 |
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 shutdown command, and reenable the interface after changing the cable. Refer to your hardware documentation for more details.
On the Cisco 7000 series or Cisco 7500 series routers, you can display diagnostic information about the controller, interface processor, and port adapters associated with a specified slot. To display this diagnostic information, complete the following task in privileged EXEC mode:
Task | Command |
---|---|
Display diagnostic information. | show diagbus [slot] |
You can use a loopback test on lines to detect and distinguish equipment malfunctions between line and modem or Channel Service Unit/Digital Service Unit (CSU/DSU) problems on the network server. If correct data transmission is not possible when an interface is in loopback mode, the interface is the source of the problem. The DSU might have similar loopback functions you can use to isolate the problem if the interface loopback test passes. If the device does not support local loopback, this function will have no effect.
You can specify hardware loopback tests on the Ethernet and synchronous serial interfaces, and all Token Ring interfaces (except the CSC-R 4-megabit card) that are attached to CSU/DSUs and that support the local loopback signal. The CSU/DSU acts as a Data Communications Equipment (DCE) device; the router acts as a Data Terminal Equipment (DTE) device. The local loopback test generates a CSU loop--a signal that goes through the CSU/DSU to the line, then back through the CSU/DSU to the router. The ping command can also be useful during loopback operation.
The loopback tests are available on the following interfaces:
The following sections describe each test.
The HSSI allows you to do the following:
These tests apply only when the device supports them and are used to check the data communications channels. The tests are usually performed at the line port rather than the DTE port of the remote CSU/DSU.
The internal loopback concepts are illustrated in Figure 6-12.
You can configure an internal loop on the HSSI applique by performing the following task in interface configuration mode:
Task | Command |
---|---|
Loop internally on the HSSI applique. | loopback applique |
Once enabled, the loopback applique command loops the packets on the applique, thereby establishing a loopback inside the router. This command is useful for sending pings to yourself to check the functionality of the applique. The HSSI applique (HSA card) uses an internal 44.736-MHz crystal clock during the applique loopback to drive its internal circuits. Refer to your hardware installation and maintenance publication for more information.
This command is functionally equivalent to entering the loopback command with no arguments; however, when the HSCI card is installed, the configuration displayed after the show running config command is entered will show loopback applique set.
You can loop packets to DTE within the CSU/DSU at the DTE interface, when the device supports this function. Doing so is useful for testing the DTE-to-DCE cable. To loop the packets to DTE, perform the following task in interface configuration mode:
Task | Command |
---|---|
Loop packets to DTE internally. | loopback dte |
You can loop packets completely through the CSU/DSU to configure a CSU loop, when the device supports this feature. Doing so is useful for testing the DCE device (CSU/DSU) itself. To configure a CSU loop, perform the following task in interface configuration mode:
Task | Command |
---|---|
Loop packets completely through the CSU/DSU. | loopback line |
You can loop packets through the CSU/DSU, over the Digital signal level 3 (DS-3) link, and to the remote CSU/DSU and back. To do so, perform the following task in interface configuration mode:
Task | Command |
---|---|
Loop packets through the CSU/DSU to a remote CSU/DSU over the DS-3 link. | loopback remote |
This command applies only when the device supports the remote function. It is used for testing the data communication channels. The loopback usually is performed at the line port, rather than the DTE port, of the remote CSU/DSU.
The HSA applique on the HSSI contains an LED that indicates the LA, LB, and LC signals transiting through the devices. The CSU/DSU uses the LC signal to request a loopback from the router. The CSU/DSU might want to do this so that its own network management diagnostics can independently check the integrity of the connection between the CSU/DSU and the router.
When the CSU/DSU asserts the LC signal and the router enables the external loopback, the connection is blocked by the loopback and the router no longer has access to the data communication channel.
Figure 6-13 illustrates the extent of the signal during an external loopback request.
By default, this feature is disabled on the router. To enable this feature to support those CSU/DSUs that support this function, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable a two-way internal and external loopback request on HSSI from DSU/CSU. | hssi external-loop-request |
If your CSU/DSU does not support this feature, it should not be enabled in the router. This prevents spurious line noise from accidentally tripping the external loopback request line, which would interrupt the normal data flow.
A useful diagnostic is available that allows fault isolation of possible defects on the HSCI card. This diagnostic is not part of the normal system diagnostics, but is offered to help technicians test for controller defects at installation or when the system is upgraded. The diagnostic involves recabling the HSCI card and then entering a diagnostic script. The tasks required to perform this diagnostic are described in the hardware installation and maintenance publication for your router.
The MCI and SCI serial interface cards support the loopback function when a CSU/DSU or equivalent device is attached to the router. To enable loopback mode on them, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable loopback through a CSU/DSU to configure a CSU loop on the MCI and SCI synchronous serial interfaces. | loopback |
The Ethernet interfaces on the MCI and MEC cards support loopback mode. To enable loopback mode on them, perform the following task in interface configuration mode:
Task | Command |
---|---|
Enable loopback to verify that the interface receives back every packet it sends. | loopback |
The router software provides an Ethernet loopback server that supports Digital Equipment Corporation (Digital), Intel, and Xerox systems specified by the "blue book," a joint specification written by Digital, Intel, and Xerox that defines the Ethernet protocol. The loopback server responds to forward data loopback messages sent either to the server's MAC address or to the broadcast address. Currently, the Ethernet loopback server does not respond to the loopback assistance multicast address.
Use the Ethernet loopback server to test communications between your internetworking products and Digital systems that do not support the IP ping command, such as DECnet-only VMS systems.
To originate a loop test on your VMS system with a Cisco server, use the Digital Network Control Program (NCP) command loop circuit. For more information about the loop circuit command, consult the DECnet VAX documentation. Cisco network servers support all options that can be specified by the VMS hosts.
You can place the FDDI (CSC-FCI) into loopback mode by performing the following task in interface configuration mode:
Task | Command |
---|---|
Enable loopback to verify that the FDDI (CSC-FCI) interface receives back every packet it sends. | loopback |
You can place all of the Token Ring interface cards except the 4-MB CSC-R card into loopback mode by performing the following task in interface configuration mode:
Task | Command |
---|---|
Enable loopback to verify that the Token Ring interface receives back every packet it sends. | loopback |
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.
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.
For the T1 controller, two loopbacks are available for testing.
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 if any. 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) |
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.
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.
Two loopbacks are available for channel groups:
Interface Local Loopback. Interface local loopback is a bi-directional 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.
This section describes how to monitor and maintain service modules on Cisco 2524 and Cisco 2525 routers. It describes the following tasks:
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.
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 |
A series of tests are performed on the CSU/DSU, which include a ROM checksum test, RAM test, EEPROM test, flash test, and an internal pattern test.
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.
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. | 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 the last 15-minute interval. For example, a range of 2-3 displays the performance statistics for the last two to three 15-minute intervals.
The following example is sample output from the show service-module command:
Router1#sho service-module s 0
Module type is T1/fractional Hardware revision is B, Software revision is 1.1i, Image checksum is 0x21791D6, Protocol revision is 1.1 Receiver has AIS alarm, Unit is currently in test mode: line loopback is in progress Framing is ESF, Line Code is B8ZS, Current clock source is line, Fraction has 24 timeslots (64 Kbits/sec each), Net bandwidth is 1536 Kbits/sec. Last user loopback performed: remote loopback Failed to loopup remote Last module self-test (done at startup): Passed Last clearing of alarm counters 0:05:50 loss of signal : 1, last occurred 0:01:50 loss of frame : 0, AIS alarm : 1, current duration 0:00:49 Remote alarm : 0, Module access errors : 0, Total Data (last 0 15 minute intervals): 1466 Line Code Violations, 0 Path Code Violations 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs Data in current interval (351 seconds elapsed): 1466 Line Code Violations, 0 Path Code Violations 25 Slip Secs, 49 Fr Loss Secs, 40 Line Err Secs, 1 Degraded Mins 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 49 Unavail Secs Router1#sho service-module s 1
Module type is 4-wire Switched 56 Hardware revision is B, Software revision is X.07, Image checksum is 0x45354643, Protocol revision is 1.0 Connection state: active, Receiver has loss of signal, loss of sealing current, Unit is currently in test mode: line loopback is in progress Current line rate is 56 Kbits/sec Last user loopback performed: dte loopback duration 00:00:58 Last module self-test (done at startup): Passed Last clearing of alarm counters 0:13:54 oos/oof : 3, last occurred 0:00:24 loss of signal : 3, current duration 0:00:24 loss of sealing curren: 2, current duration 0:04:39 loss of frame : 0, rate adaption attempts: 0,
To display debugging messages that monitor the detection and clearing of network alarms on the local CSU/DSU, perform the following task in privileged EXEC mode:
Task | Command |
---|---|
Debug a service module. | debug service-module |
To exit debug for the integrated CSU/DSU modules, perform the following task in privileged EXEC mode:
Task | Command |
---|---|
Stop debugging a service module. | no debug service-module |
The following example is output from the debug service-module command:
Router1#debug service-module
Service module debugging is on SERVICE_MODULE(1): loss of signal ended after duration 00:05:36 SERVICE_MODULE(1): oos/oof ended after duration 01:05:14 SERVICE_MODULE(0): Unit has no clock SERVICE_MODULE(0): detects loss of signal SERVICE_MODULE(0): loss of signal ended after duration 00:00:33 Router1#undebug service-module
Service module debugging is off
You can test the performance of the integrated CSU/DSU by looping packets from modules back to the serial interface of the router. To test the performance, follow this task in interface configuration mode:
Task | Command |
---|---|
Test the performance of the integrated CSU/DSU. | loopback dte |
To evaluate whether packets loop back, you can send a test ping.
The following example loops a packet from a module to the serial interface:
Router1(config-if)#loopback dte
Loopback in progress Router1#ping 12.0.0.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 12.0.0.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/12/28 ms
The following example illustrates how to begin interface configuration on a serial interface. It assigns Point-to-Point (PPP) encapsulation to serial interface 0.
interface serial 0 encapsulation ppp
The same example on a Cisco 7000 requires the following commands:
interface serial 1/0 encapsulation ppp
The following example assigns an IP address to an asynchronous interface and places the line in dedicated network mode:
interface async 1 async default ip address 182.32.7.51 async mode dedicated
The following example assumes that users are restricted to certain servers designated as asynchronous servers, but that normal terminal users can access anything on the local network.
! access list for normal connections access-list 1 permit 131.108.0.0 0.0.255.255 ! access-list 2 permit 131.108.42.55 access-list 2 permit 131.108.111.1 access-list 2 permit 131.108.55.99 ! line 1 speed 19200 flow hardware modem inout interface async 1 async mode interactive async dynamic address ip access-group 1 out ip access-group 2 in
The following example shows a simple configuration that allows routing and dynamic addressing. In this configuration, the router will act as either a telecommuting server or a router, depending on whether the user specifies /routing in the EXEC slip or ppp command.
interface async 1 async dynamic routing async dynamic address async mode interactive
This example shows how to configure the access server so that it will use the default address pool on all interfaces except interface 7, on which it will use an address pool called cess:
ip address-pool local ip local-pool cess 172.30.0.1 async interface interface 7 peer default ip address cess
ip address-pool dhcp-proxy-client
The following global configuration example illustrates how to specify which DHCP servers are used on your network. You can specify up to four severs using IP addresses or names. If you do not specify servers, the default is to use the IP limited broadcast address of 255.255.255.255 for transactions with any and all discovered DHCP servers.
ip dhcp-server jones smith wesson
The following interface configuration example illustrates how to disable DHCP proxy-client functionality on asynchronous interface 1:
async interface interface 1 no peer default ip address
! this command tells the access server to use a local pool ip address-pool local ! this command defines the ip address pool ip local-pool default 172.30.0.1 172.30.0.28
The following example shows how to create an asynchronous group interface 0 with group interface members 2 through 7, starting in global configuration mode:
interface group-async 0 group-range 2 7
The following example shows how you need to configure asynchronous interfaces 1, 2, and 3 separately if you do not have a group interface configured:
! interface Async1 ip unnumbered Ethernet0 encapsulation ppp async default ip address 172.30.1.1 async mode interactive async dynamic routing ! interface Async2 ip unnumbered Ethernet0 encapsulation ppp async default ip address 172.30.1.2 async mode interactive async dynamic routing ! interface Async3 ip unnumbered Ethernet0 ! encapsulation ppp async default ip address 172.30.1.3 async mode interactive async dynamic routing
The following example configures the same interfaces, but from a single group asynchronous interface:
! interface Group-Async 0 ip unnumbered Ethernet0 encapsulation ppp async mode interactive async dynamic routing group-range 1 3 member 1 async default ip address 172.30.1.1 member 2 async default ip address 172.30.1.2 member 3 async default ip address 172.30.1.3
The following example configures a Cisco 7000 series router to acknowledge an E1 line. For an example of configuring circuits refer to the next section; circuits are configured in the same way, whether the line is E1 or T1.
controller e1 3/0 channel-group 0 timeslots 1 channel-group 8 timeslots 5-15, 20-30 channel-group 12 timeslots 2 channel-group 29 timeslots 31
The following example applies only to a Cisco 7000 series router. It configures the router to acknowledge a T1 line and its circuits. Four different circuits are defined for the second CxCT1 attached to the MIP in slot 4.
controller t1 4/1 framing esf linecode b8zs channel-group 0 timeslots 1 channel-group 8 timeslots 5,7,12-15, 20 speed 64 channel-group 12 timeslots 2 channel-group 23 timeslots 24
The following example configures circuit 0 for Point-to-Point (PPP) encapsulation:
interface serial 4/1:0 ip address 131.108.13.1 255.255.255.0 encapsulation ppp
The following example configures circuit 8 for IP routing and disables IP route cache:
interface serial 4/1:8 ip address 131.108.1.1 255.255.255.0 no ip route-cache
The following example configures circuit 12 for Frame Relay encapsulation and subinterface support:
interface serial 4/1:12 encapsulation frame-relay ! interface serial 4/1:12.1 ip address 1.1.1.1 255.0.0.0 ! interface serial 4/1:12.2 ip address 2.2.2.2 255.0.0.0
The following example configures circuit 23 for IP routing and enables autonomous switching:
interface serial 4/1:23 ip address 3.3.3.3 255.0.0.0 ip route-cache cbus
These commands enable standard Ethernet Version 2.0 encapsulation on the Ethernet interface processor in slot 4 on port 2 of a Cisco 7000:
interface ethernet 4/2 encapsulation arpa
The following simple example configures and creates a LAN Extender interface. In this example, the MAC address of the LAN Extender is 0000.0c00.0001.
interface serial 4 encapsulation ppp interface lex 0 lex burned-in-address 0000.0c00.0001 ip address 131.108.172.21 255.255.255.0
This section provides the following examples:
The following is an example that controls which traffic from Macintosh computers on the remote Ethernet LAN reaches the core router:
access-list 710 permit 0800.0298.0000 0000.0000.FFFF access-list 710 deny 0800.0276.2917 0000.0000.0000 access-list 710 permit 0800.0000.0000 0000.FFFF.FFFF interface lex 0 lex input-address-list 710
The first line of this access list permits traffic from any Macintosh whose MAC address starts with 0800.0298. The remaining two octets in the MAC address can be any value because the mask for these octets is FFFF ("don't care" bits).
The second line specifically rejects all traffic originating from a Macintosh with the MAC address of 0800.0276.2917. Note that none of the mask bits are "don't care" bits.
The third line specifically permits all traffic from other Macintoshes whose MAC addresses start with 0800. Note that in the mask, the "don't care" bits are the rest of the address.
At the end of the list is an implicit "deny everything" entry, meaning that any address that does not match an address or address group on the list is rejected.
Using the same configuration as in the previous section, you could allow only the Macintosh traffic by Ethernet type code with the following access list:
access-list 220 permit 0x809B 0x0000 interface lex 0 lex input-type-list 220
This access list permits only those messages whose protocol number matches the masked protocol number in the first line. The implicit last entry in the list is a "deny everything" entry.
This section provides the following examples:
The following example enables PPP reliable link and Stac compression on BRI 0:
interface BRI0 description Enables stac compression on BRI 0 ip address 172.1.1.1 255.255.255.0 encapsulation ppp dialer map ip 172.1.1.2 name baseball 14195386368 compress stac ppp authentication chap dialer-group 1 ppp reliable-link
The following example shows output of the show interface command when PPP reliable link is enabled. The LAPB output lines indicate that PPP reliable link is provided over LAPB.
Router# show interface serial 0 Serial0 is up, line protocol is up Hardware is HD64570 Description: connects to enkidu s 0 Internet address is 172.21.10.10/8 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255 Encapsulation PPP, loopback not set LCP Open Open: IPCP, CDP LAPB DTE, state CONNECT, modulo 8, k 7, N1 12048, N2 20 T1 3000, T2 0, interface outage (partial T3) 0, T4 0, PPP over LAPB VS 1, VR 1, tx NR 1, Remote VR 1, Retransmissions 0 Queues: U/S frames 0, I frames 0, unack. 0, reTx 0 IFRAMEs 1017/1017 RNRs 0/0 REJs 0/0 SABM/Es 1/1 FRMRs 0/0 DISCs 0/0 Last input 00:00:18, output 00:00:08, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0 (size/max/drops); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/64/0 (size/threshold/drops) Conversations 0/1 (active/max active) Reserved Conversations 0/0 (allocated/max allocated) 5 minute input rate 3000 bits/sec, 4 packets/sec 5 minute output rate 3000 bits/sec, 7 packets/sec 1365 packets input, 107665 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 2064 packets output, 109207 bytes, 0 underruns 0 output errors, 0 collisions, 4 interface resets 0 output buffer failures, 0 output buffers swapped out 4 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
The following configuration examples enable CHAP on interface serial 0 of three routers.
hostname yyy interface serial 0 encapsulation ppp ppp authentication chap username xxx password secretxy username zzz password secretzy
hostname xxx interface serial 0 encapsulation ppp ppp authentication chap username yyy password secretxy username zzz password secretxz
hostname zzz interface serial 0 encapsulation ppp ppp authentication chap username xxx password secretxz username yyy password secretzy
When you look at the configuration file, the passwords will be encrypted and the display will look similar to the following:
hostname xxx interface serial 0 encapsulation ppp ppp authentication chap username yyy password 7 121F0A18 username zzz password 7 1329A055
The following example shows an IP tunneling configuration with commented (!) explanations:
!Creates the interface interface tunnel 0 !enables IPX on the interface novell network 1e !enables appletalk appletalk cable-range 4001-4001 128 !enables IP ip address 10.1.2.3. 255.255.255.0 !enables DECnet DECnet cost 4 !sets the source address, or interface, for packets tunnel source ethernet 0 !determines where the encapsulated packets are to go tunnel destination 131.108.14.12 !sets the encapsulator protocol tunnel mode gre !computes a checksum on passenger packets if protocol doesn't already have reliable !checksum tunnel checksum needed !sets the id key tunnel key 42 !set to drop out of order packets tunnel sequence-datagrams
Figure 6-14 is an example of connecting multiprotocol subnetworks across a single-protocol backbone. The configurations of Router A and Router B follow.
interface ethernet 0 description physics department AppleTalk lan AppleTalk cable-range 4001-4001 32 ! interface fddi 0 description connection to campus backbone ip address 36.0.8.108 255.255.255.0 interface tunnel 0 tunnel source fddi 0 tunnel destination 36.0.21.20 appletalk cable-range 5313-5313 1
interface ethernet 0 description chemistry department appletalk lan AppleTalk cable-range 9458-9458 3 ! interface fddi 0 description connection to campus backbone ip address 36.0.21.20 255.255.255.0 interface tunnel 0 tunnel source fddi 0 tunnel destination 36.0.8.108 appletalk cable-range 5313-5313 2
Figure 6-15 is an example of routing a private IP network and a Novell network across a public service provider.
interface ethernet 0 description boston office ip address 10.1.1.1 255.255.255.0 novell network 1e ! interface serial 0 description connection to NEARnet ip address 192.13.2.1 255.255.255.0 ! interface tunnel 0 tunnel source serial 0 tunnel destination 131.108.5.2 ip address 10.1.2.1 255.255.255.0 novell network 1f
interface ethernet 0 description menlo park office ip address 10.1.3.1 255.255.255.0 novell network 31 ! interface serial 4 description connection to BARRnet ip address 131.108.5.2 255.255.255.0 ! interface tunnel 0 tunnel source serial 4 tunnel destination 192.13.2.1 ip address 10.1.2.2 255.255.255.0 novell network 1f
The following example illustrates how to add a description about an interface that will appear in configuration files and monitoring command displays.
interface ethernet 0 description First Ethernet in network 1 ip address 101.13.15.78 255.255.255.0
The following example for a Cisco 7000 describes an administration network attached to the Ethernet processor in slot 2, port 4:
interface ethernet 2/4 description 2nd floor administration net
The following example turns off the Ethernet interface in slot 2 at port 4:
interface ethernet 2/4 shutdown
The following example turns the interface back on:
interface ethernet 2/4 no shutdown
The following example illustrates how to shut down a Token Ring interface:
interface tokenring 0 shutdown
The following example shuts down a T1 circuit number 23 running on a Cisco 7000:
interface serial 4/0:23 shutdown
The following next example shuts down the entire T1 line physically connected to a Cisco 7000:
controller t1 4/0 shutdown
The following example configures serial 1 as a backup line that becomes active only when the primary line (serial 0) goes down. The backup line will not be activated because of load on the primary line.
interface serial 0 backup interface serial 1 backup delay 30 60
The backup line is configured to activate 30 seconds after the primary line goes down and to remain on for 60 seconds after the primary line is reactivated.
The same example on the Cisco 7000 would be as follows:
interface serial 1/1 backup interface serial 2/2 backup delay 30 60
The following example configures the secondary line (serial 1) to be activated only when the load of the primary line reaches a certain threshold:
interface serial 0 backup interface serial 1 backup load 75 5
In this case, the secondary line will not be activated when the primary goes down. The secondary line will be activated when the load on the primary line is greater than 75 percent of the primary's bandwidth. The secondary line will then be brought down when the aggregate load between the primary and secondary lines fits within 5 percent of the primary bandwidth.
The same example on the Cisco 7000 would be as follows:
interface serial 1/1 backup interface serial 2/2 backup load 75 5
The following example configures the secondary line to activate once the traffic threshold on the primary line exceeds 25 percent:
interface serial 0 backup interface serial 1 backup load 25 5 backup delay 10 60
Once the aggregate load of the primary and the secondary lines return to within 5 percent of the primary bandwidth, the secondary line is deactivated. The secondary line waits 10 seconds after the primary goes down before activating, and remains active for 60 seconds after the primary returns and becomes active again.
The same example on the Cisco 7000 is as follows:
interface serial 1/1 backup interface serial 2/2 backup load 25 5 backup delay 10 60
The following sections provide examples of hub configuration:
The following example configures port 1 on hub 0 of Ethernet interface 0:
hub ethernet 0 1 no shutdown
The following example configures ports 1 through 8 on hub 0 of Ethernet interface 0:
hub ethernet 0 1 8 no shutdown
The following example configures the hub to allow only packets from MAC address 1111.2222.3333 on port 2 of hub 0:
hub ethernet 0 2 source-address 1111.2222.3333
The following example configures the hub to remember the first MAC address received on port 2, and allow only packets from that learned MAC address:
hub ethernet 0 2 source-address
The following example shuts down ports 3 through 5 on hub 0:
hub ethernet 0 3 5 shutdown
The following example shuts down port 3 on hub 0:
hub ethernet 0 3 shutdown
|