Configuring the Interfaces

This chapter contains information on enabling, shutting down, and displaying messages pertinent to interface configuration and operation. Also discussed are the procedures and command descriptions for configuring and maintaining the following router interface components:

• Serial interfaces

• ISDN Basic Rate Interfaces (BRI)

• Ethernet interfaces

• Token Ring interfaces

• Fiber Distributed Data Interface (FDDI)

• High-Speed Serial Interface (HSSI)

• UltraNet interface

You also will find information about configuring the serial Dial Backup feature and learn how to configure a null interface and the Point-to-Point Protocol (PPP) and HDLC.

To enable an interface, you must be in the configuration command collection mode. To enter this mode, type the EXEC command configure at the EXEC prompt. Once in the command collection mode, start configuring the interface by entering the interface command. When the interface is configured, you can check its status by entering EXEC show commands at the EXEC prompt.

This chapter provides software configuration information only. For hardware technical descriptions, and for information about installing these interfaces, refer to the appropriate hardware installation and maintenance publication.

Summaries of the interface configuration commands and EXEC monitoring commands described in this chapter are included at the end of the chapter.

Online Insertion and Removal (OIR)

The Online Insertion and Removal (OIR) feature of boards on the Cisco 7000 series allows you to remove and replace CxBus interface processors (IPs) while the system is on line. With minimal disruption of service, you can shut down the IP 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 a 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 a 3-second to 5-second disruption to normal operation during interface processor removal. There is an 11-second to 15-second disruption during interface processor insertion.

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 interface(s).

Hardware (MAC-level) addresses for all interfaces in the system 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 will change to those specified in the address allocator on the new RP.

Specifying an Interface

Enter the interface global configuration command in configuration mode to identify a specific network interface (for example, a serial port, Ethernet port, or Token Ring port). By entering this command you begin the configuration subcommand collection mode for the specified interface.

For all routers except the Cisco 7000 series, the interface command has the following syntax:

The argument type identifies the interface type; the argument unit identifies the connector or interface card number. Unit 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 command.

Example

This example begins interface configuration subcommand collection mode for serial connector 0 (interface serial 0):

interface serial 0

Use the EXEC command show interfaces (described later in this chapter) to determine the interface type and unit numbers.

In the interface configuration subcommand collection mode, you enter the interface subcommands for your particular routing or bridging protocol. The interface configuration subcommand collection mode ends when you enter a command that is not an interface subcommand or when you type the Ctrl-Z sequence.

For the Cisco 7000 series, to identify a specific network interface, use the following global configuration command in configuration mode:

The argument type identifies the interface type and can be one of the following: ethernet, serial, tokenring, or fddi.

The slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The slots are numbered from left to right.

The port argument is the port number of the interface and can be 0, 1, 2, 3, 4, or 5 depending on the type of interface, as follows:

• SIP (Serial Interface Processor) 0, 1, 2, or 3

• EIP (Ethernet Interface Processor) 0, 1, 2, 3, 4, or 5

• TRIP (Token Ring Interface Processor) 0, 1, 2, or 3

• FIP (FDDI Interface Processor) 0

• HIP (HSSI Interface Processor) 0

Ports on each interface processor are numbered from the top down. The interface slot and port numbers can be displayed with the show interfaces command.

Example

This example shows the interface configuration subcommand for Ethernet port 4 on the EIP that is installed in (or recently removed from) slot 2:

interface ethernet 2/4

Use the EXEC command show interfaces (described later in this chapter) to determine the interface type, slot numbers, and port numbers.

Remain in interface configuration subcommand collection mode as long as you are entering interface subcommands for a routing or bridging protocol. The interface configuration subcommand collection mode ends when you enter a command that is not an interface subcommand or when you type the Ctrl-Z sequence to get out of configuration mode and return to privileged EXEC mode.

Adding a Descriptive Name to an Interface

To add a descriptive name to an interface, use the description interface subcommand.

The argument name-string is descriptive text to help you remember what is attached to this interface. The description command is meant solely as a comment to be put in the configuration to help you remember what certain interfaces are for. The description will appear in the output of the following commands: show configuration, write terminal, and show interfaces. The no version removes the name-string.

Examples

This example describes a 3174 controller on serial interface 0:

interface serial 0
description 3174 Controller for test lab

This example for the Cisco 7000 series describes an administration network attached to the Ethernet processor in slot 2, port 4:

interface ethernet 2/4
description 2nd floor administration net

Shutting Down and Restarting an Interface

To disable an interface, use the shutdown interface subcommand. The full syntax for this command follows.

The shutdown command disables all functions on the specified interface and prevents all packet transmission. The command also marks the interface as unavailable; 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, this command causes the DTR signal to be dropped. On FDDI interfaces, this command causes the optical bypass switch, if present, to go into bypass mode. On Token Ring interfaces, this command causes the interface to deinsert from the ring.

To restart a disabled interface, use the no shutdown interface subcommand.

To check whether an interface is disabled, use the EXEC command show interfaces as described in the next section. An interface that has been shut down is shown as administratively down in this command's display:

Examples

This example turns off the interface Ethernet 0:

interface ethernet 0
shutdown

This example turns the interface back on:

interface ethernet 0
no shutdown

For the Cisco 7000 series, this example turns off the Ethernet interface in slot 2 at port 4:

interface ethernet 2/4
shutdown

For the Cisco 7000 series, this example turns the interface back on:

interface ethernet 2/4
no shutdown

Clearing Interface Counters

To clear the interface counters shown with the show interfaces command, enter the following command at the EXEC prompt:

The command clears all the current interface counters from the interface unless the optional arguments type and unit, or type, slot, and port, are specified to clear only a specific interface type (serial, Ethernet, Token Ring, and so on) from a specific unit or card number.

Displaying Information About an Interface

The software contains commands that you can enter at the EXEC prompt to display information about the interface, including the software and hardware versions, the controller status, and some statistics about the interfaces. These commands begin with the word show. (The full list of these commands can be displayed by entering the command show ? at the EXEC prompt.) A description of interface-specific show commands follows.

Displaying the System Configuration

The show version command displays the configuration of the system hardware, the software version, the names and sources of configuration files, and the boot images. Enter this command at the EXEC prompt:

The following shows sample output from this command:

GS Software, Version 9.1(1)
Copyright (c) 1986-1992 by cisco Systems, Inc.
Compiled Fri 14-Aug-92 12:37
System Bootstrap, Version 4.3
thor uptime is 2 days, 10 hours, 0 minutes
System restarted by reload
System image file is unknown, booted via tftp from 131.108.13.111
Host configuration file is "thor-boots", booted via tftp from 131.108.13.111
Network configuration file is "network-confg", booted via tftp from 131.108.13.111
CSC3 (68020) processor with 4096K bytes of memory.
X.25 software.
Bridging software.
1 MCI controller (2 Ethernet, 2 Serial).
2 Ethernet/IEEE 802.3 interface.
2 Serial network interface.
32K bytes of non-volatile configuration memory.
Configuration register is 0x0

In the output, the first block of text lists information about the system software, which includes the software release version number. Always specify the complete version number when reporting a possible software problem. In the sample output, the version number is 9.1, initial release.

The second block of text lists the system bootstrap version, in this case 4.3.

The third block of text includes the system name and uptime, or the amount of time the system has been up and running. Also displayed is a log of how the system was last booted, both as a result of normal system startup and of system error. For example, information can be displayed to indicate a bus error that is generally the result of an attempt to access a nonexistent address.

System restarted by bus error at PC0XC4CA address 0X210C0C0

If the software was booted over the network, the the Internet address of the boot host is shown. If the software was loaded from onboard ROM, the information displayed is running default software. In addition, the names and sources of the host and network configuration files are shown.

The remaining output shows the hardware configuration and any nonstandard software options. The configuration register contents are displayed in hexadecimal notation.

Displaying Controller Status

The show controllers command displays current internal status information for different interface cards. The information displayed is generally useful for diagnostic tasks performed by technical support personnel only. Enter this command at the EXEC prompt:

Use the following version of the show controllers command on low-end routers (Cisco 2500, Cisco 3000 series, and Cisco 4000):

Use the following keywords to display the information about each card:

• ethernet--For the Ethernet interface card

• serial--For the Serial interface card

• token or tokenring--For the Token Ring interface card

• mci--For the Multiport Communications interface card

• cbus--For the cBus controller card

• fddi--For the FDDI controller card

• bri--For the ISDN Basic Rate Interface (BRI) card

For the Cisco 7000 series, use the following keywords to display the information about each processor:

• token--Token Ring Interface Processors (TRIP)

• serial--Serial Interface Processor (SIP)

• cxBus--Switch Processor (SP) CxBus controller

• fddi--FDDI Interface Processor (FIP)

Sample output for the MCI controller card follows. Table 1-1 describes the fields.

MCI 0, controller type 1.1, microcode version 1.8
  128 Kbytes of main memory, 4 Kbytes cache memory
22 system TX buffers, largest buffer size 1520
  Restarts: 0 line down, 0 hung output, 0 controller error
  Interface 0 is Ethernet0, station address 0000.0c00.d4a6
    15 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Transmitter delay is 0 microseconds
  Interface 1 is Serial0, electrical interface is V.35 DTE
    15 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface
  Interface 2 is Ethernet1, station address aa00.0400.3be4
    15 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Transmitter delay is 0 microseconds
  Interface 3 is Serial1, electrical interface is V.35 DCE
    15 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface 

The following is sample output of the show controllers ethernet command:

router# show controller ethernet 
LANCE unit 0, NIM slot 1, NIM type code 4, NIM version 1
Media Type is 10BaseT, Link State is Up, Squelch is Normal
idb 0x4060, ds 0x5C80, regaddr = 0x8100000
IB at 0x600D7AC: mode=0x0000, mcfilter 0000/0001/0000/0040
station address 0000.0c03.a14f  default station address 0000.0c03.a14f
buffer size 1524
RX ring with 32 entries at 0xD7E8
Rxhead = 0x600D8A0 (12582935), Rxp = 0x5CF0(23)
00 pak=0x60336D0 ds=0x6033822 status=0x80 max_size=1524 pak_size=98
01 pak=0x60327C0 ds=0x6032912 status=0x80 max_size=1524 pak_size=98
02 pak=0x6036B88 ds=0x6036CDA status=0x80 max_size=1524 pak_size=98
03 pak=0x6041138 ds=0x604128A status=0x80 max_size=1524 pak_size=98
04 pak=0x603FAA0 ds=0x603FBF2 status=0x80 max_size=1524 pak_size=98
05 pak=0x600DC50 ds=0x600DDA2 status=0x80 max_size=1524 pak_size=98
06 pak=0x6023E48 ds=0x6023F9A status=0x80 max_size=1524 pak_size=1506
07 pak=0x600E3D8 ds=0x600E52A status=0x80 max_size=1524 pak_size=1506
08 pak=0x6020990 ds=0x6020AE2 status=0x80 max_size=1524 pak_size=386
09 pak=0x602D4E8 ds=0x602D63A status=0x80 max_size=1524 pak_size=98
10 pak=0x603A7C8 ds=0x603A91A status=0x80 max_size=1524 pak_size=98
11 pak=0x601D4D8 ds=0x601D62A status=0x80 max_size=1524 pak_size=98
12 pak=0x603BE60 ds=0x603BFB2 status=0x80 max_size=1524 pak_size=98
13 pak=0x60318B0 ds=0x6031A02 status=0x80 max_size=1524 pak_size=98
14 pak=0x601CD50 ds=0x601CEA2 status=0x80 max_size=1524 pak_size=98
15 pak=0x602C5D8 ds=0x602C72A status=0x80 max_size=1524 pak_size=98
16 pak=0x60245D0 ds=0x6024722 status=0x80 max_size=1524 pak_size=98
17 pak=0x6008328 ds=0x600847A status=0x80 max_size=1524 pak_size=98
18 pak=0x601EB70 ds=0x601ECC2 status=0x80 max_size=1524 pak_size=98
19 pak=0x602DC70 ds=0x602DDC2 status=0x80 max_size=1524 pak_size=98
20 pak=0x60163E0 ds=0x6016532 status=0x80 max_size=1524 pak_size=98
21 pak=0x602CD60 ds=0x602CEB2 status=0x80 max_size=1524 pak_size=98
22 pak=0x6037A98 ds=0x6037BEA status=0x80 max_size=1524 pak_size=98
23 pak=0x602BE50 ds=0x602BFA2 status=0x80 max_size=1524 pak_size=98
24 pak=0x6018988 ds=0x6018ADA status=0x80 max_size=1524 pak_size=98
25 pak=0x6033E58 ds=0x6033FAA status=0x80 max_size=1524 pak_size=98
26 pak=0x601BE40 ds=0x601BF92 status=0x80 max_size=1524 pak_size=98
27 pak=0x6026B78 ds=0x6026CCA status=0x80 max_size=1524 pak_size=98
28 pak=0x6024D58 ds=0x6024EAA status=0x80 max_size=1524 pak_size=74
29 pak=0x602AF40 ds=0x602B092 status=0x80 max_size=1524 pak_size=98
30 pak=0x601FA80 ds=0x601FBD2 status=0x80 max_size=1524 pak_size=98
31 pak=0x6038220 ds=0x6038372 status=0x80 max_size=1524 pak_size=98
TX ring with 8 entries at 0xDA20, tx_count = 0
tx_head = 0x600DA58 (12582919), head_txp = 0x5DC4 (7)
tx_tail = 0x600DA58 (12582919), tail_txp = 0x5DC4 (7)
00 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
01 pak=0x000000 ds=0x602126A status=0x03 status2=0x0000 pak_size=60
02 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
03 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
04 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
05 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
06 pak=0x000000 ds=0x600CF12 status=0x03 status2=0x0000 pak_size=118
07 pak=0x000000 ds=0x6003ED2 status=0x03 status2=0x0000 pak_size=126
0 missed datagrams, 0 overruns, 2 late collisions, 2 lost carrier events
0 transmitter underruns, 0 excessive collisions,  0 tdr, 0 babbles
0 memory errors, 0 spurious initialization done interrupts
0 no enp status, 0 buffer errors, 0 overflow errors
10 one_col, 10 more_col, 22 deferred, 0 tx_buff
0 throttled, 0 enabled
Lance csr0 = 0x73

Sample output for the show controllers token command follows:

router> show controllers token
Tokenring4/0: state administratively down
  current address: 0000.3040.8b4a, burned in address: 0000.3040.8b4a
  Last Ring Status: none
    Stats: soft: 0/0, hard: 0/0, sig loss: 0/0
           tx beacon: 0/0, wire fault 0/0, recovery: 0/0
           only station: 0/0, remote removal: 0/0
  Monitor state: (active), chip f/w: '000000........', [bridge capable]
    ring mode: 0"
    internal functional: 00000000 (00000000), group: 00000000 (00000000)
    internal addrs: SRB: 0000, ARB: 0000, EXB 0000, MFB: 0000
                    Rev: 0000, Adapter: 0000, Parms 0000
    Microcode counters:
      MAC giants 0/0, MAC ignored 0/0
      Input runts 0/0, giants 0/0, overrun 0/0
      Input ignored 0/0, parity 0/0, RFED 0/0
      Input REDI 0/0, null rcp 0/0, recovered rcp 0/0
      Input implicit abort 0/0, explicit abort 0/0
      Output underrun 0/0, tx parity 0/0, null tcp 0/0
      Output SFED 0/0, SEDI 0/0, abort 0/0
      Output False Token 0/0, PTT Expired 0/0
    Internal controller counts:
      line errors: 0/0,  internal errors: 0/0
      burst errors: 0/0,  ari/fci errors: 0/0
      abort errors: 0/0, lost frame: 0/0
      copy errors: 0/0, rcvr congestion: 0/0
      token errors: 0/0, frequency errors: 0/0
    Internal controller smt state:
      Adapter MAC:     0000.0000.0000, Physical drop:     00000000
      NAUN Address:    0000.0000.0000, NAUN drop:         00000000
      Last source:     0000.0000.0000, Last poll:         0000.0000.0000
      Last MVID:       0000,           Last attn code:    0000
      Txmit priority:  0000,           Auth Class:        0000
      Monitor Error:   0000,           Interface Errors:  0000
      Correlator:      0000,           Soft Error Timer:  0000
      Local Ring:      0000,           Ring Status:       0000
      Beacon rcv type: 0000,           Beacon txmit type: 0000
      Beacon type:     0000,           Beacon NAUN:       0000.0000.0000
      Beacon drop:     00000000,       Reserved:          0000
      Reserved2:       0000

Table 1-2 describes key show controllers token display fields.

router# show controllers serial
SSP 3, hardware version 2.0, microcode version 1.3
  128 Kbytes of main memory, 4 Kbytes cache memory
  23 system TX buffers, largest buffer size 1520
  Restarts: 0 line down, 0 hung output, 0 controller error
  Interface 0 is Serial3/0, electrical interface is V.35 DTE
    14 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Tx buffer free count is 11
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface
  Interface 1 is Serial3/1, electrical interface is V.35 DCE
    14 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Tx buffer free count is 11
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface
  Interface 2 is Serial3/2, electrical interface is V.35 DTE
    14 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Tx buffer free count is 11
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface
  Interface 3 is Serial3/3, electrical interface is V.35 DTE
    14 total RX buffers, 11 buffer TX queue limit, buffer size 1520
    Tx buffer free count is 11
    Transmitter delay is 0 microseconds
    High speed synchronous serial interface

Table 1-3 describes the show controllers serial display fields.

router> show controllers cxbus
Switch Processor 5, hardware version 11.1, microcode version 130.2
  Microcode loaded from system
  512 Kbytes of main memory, 128 Kbytes cache memory
  120 1520 byte buffers, 70 4484 byte buffers, 212 byte system buffer
  Restarts: 0 line down, 0 hung output, 0 controller error
 FIP 3, hardware version 6.1, microcode version 141.7
  Microcode loaded from system
  Interface 24 - Fddi3/0, station addr 0000.0c02.adf1 (bia 0000.0c02.adf1)
    70 buffer RX queue threshold, 71 buffer TX queue limit, buffer size 4484
    ift 0006, rql 66, tq 0000 0000, tql 70
 EIP 4, hardware version 5.1, microcode version 128.10
  Interface 32 - Ethernet4/0, station addr 0000.0c02.d0cc (bia 0000.0c02.d0cc)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
    Transmitter delay is 0 microseconds
  Interface 33 - Ethernet4/1, station addr 0000.0c02.d0cd (bia 0000.0c02.d0cd)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
    Transmitter delay is 0 microseconds
  Interface 34 - Ethernet4/2, station addr 0000.0c02.d0ce (bia 0000.0c02.d0ce)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
    Transmitter delay is 0 microseconds
  Interface 35 - Ethernet4/3, station addr 0000.0c02.d0cf (bia 0000.0c02.d0cf)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
    Transmitter delay is 0 microseconds
  Interface 36 - Ethernet4/4, station addr 0000.0c02.d0d0 (bia 0000.0c02.d0d0)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
    Transmitter delay is 0 microseconds
  Interface 37 - Ethernet 4/5, station addr 0000.0c02.d0d1 (bia0000.0c02.d0d1)
    20 buffer RX queue threshold, 28 buffer TX queue limit, buffer size 1520
    ift 0000, rql 20, tq 0000 0000, tql 28
Transmitter delay is 0 microseconds

Table 1-4 describes the show controllers cxbus display fields.

Sample output of the show controllers fddi command follows.

router> show controllers fddi
Fddi3/0 - hardware version 1.3, microcode version 141.7
  Phy-A registers:
    cr0 4, cr1 0, cr2 0, status 3, cr3 0
  Phy-B registers:
    cr0 4, cr1 4, cr2 0, status 3, cr3 0
  FORMAC registers:
    irdtlb  723B, irdtneg F85E, irdthtt 5036, irdmir  FFFF0BDC
    irdtrth F85F, irdtmax FBC5, irdtvxt 8585, irdstmc 0810
    irdmode 6A20, irdimsk 0000, irdstat 8060, irdtpri 0000
  FIP registers
    ccb:   0032  cmd:   0006  fr:   000F  mdptr: 0000  mema: 0000
    icb:   00F0  arg:   0003  app:  0004  mdpg:  0000  af:   0700
    clm:   E002  bcn:   E016  clbn: 0198  rxoff: 002A  en:   0001
    clmbc: 8011  bcnbc: 8011  robn: 0006  park:  0000  fop:  9478
    txchn: 0000  pend:  0000  act:  0000  tail:  0000  cnt:  0000
    state: 0003  check: 0000  eof:  0000  tail:  0000  cnt:  0000
    rxchn: 0000  buf0:  0504  nxt0: 0528  eof:   0000  tail: 0000
    eofch: 0000  buf1:  0510  nxt1: 0540  pool:  0050  err:  005C
    head:  0984  cur:   0000  t0:   0030  t1:    003E  t2:   002A
    tail:  0984  cnt:   0001  t3:   0000  rxlft: 000B  used: 0000
    txq_s: 000E  txq_f: 000E  Aarm: 0000  Barm:  1388  fint: 9478

The information in this display is of use mainly to technical support personnel.

Displaying Interface Statistics

The software also provides the show interfaces command, which displays statistics for the network interfaces on the network server. Enter the following command at the EXEC prompt:

Specify the optional arguments type and unit to display statistics for a particular network interface. The argument type can be one of the following: ethernet, serial, tokenring, fddi, hssi, or ultranet. Use the argument unit to specify the interface unit number.

Specify the optional arguments type, slot, and port to display statistics for a particular network interface. The argument type can be one of the following: serial, ethernet, tokenring, or fddi.

The slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4.

The port argument is the port number of the interface and can be 0, 1, 2, 3, 4, or 5 depending on the type of interface, as follows:

• SIP (Serial Interface Processor) 0, 1, 2, or 3

• EIP (Ethernet Interface Processor) 0, 1, 2, 3, 4, or 5

• TRIP (Token Ring Interface Processor) 0, 1, 2, or 3

• FIP (FDDI Interface Processor) 0

• HIP (HSSI Interface Processor) 0

The interface slot and port numbers can be displayed with the show interfaces command.

The optional keyword accounting displays the number of packets of each protocol type that has been sent through the interface. You can show these numbers for all interfaces, or you can specify a specific interface.

Except for protocols that are encapsulated inside other protocols, such as IP over X.25, the accounting option also shows the total of all bytes sent and received, including the MAC header. For example, it totals the size of the Ethernet packet or the size of a packet that includes HDLC encapsulation.

Table 1-5 lists the protocols for which per-packet accounting information is kept.

The show interface command is used frequently while configuring and monitoring modules.

For further explanations and examples about specific interfaces, refer to the following sections in this chapter: "Monitoring the Serial Interface," "Monitoring the Ethernet Interface," "Monitoring the Token Ring Interface," "Monitoring the FDDI," "Monitoring the HSSI," and "Monitoring the UltraNet Interface."

Serial Interface Support

For all routers except the Cisco 7000 series, support for serial interfaces is supplied on the following serial network interface cards:

• The Multiport Communications Interface (CSC-MCI), a single card that provides up to two high-speed synchronous serial port connectors that support RS-232, V.35, RS-449, and X.21 connections.

• The Serial Port Communications Interface (CSC-SCI) a single card that provides up to four high-speed serial ports that support RS-232, V.35, RS-449, and X.21 connections.

The high-speed synchronous serial interface also is supported on the IGS network server.

For the Cisco 7000 series, support for serial interfaces is supplied on the serial interface processor (SIP) and the fast serial interface processor (FSIP). The FSIP provides four or eight channel-independent, synchronous serial ports that support full-duplex operation at DS-1 (1.544 Mbps) and E-1 (2.048 Mbps) speeds. Each port supports any of the available interface types (RS-232,RS-449, V.35, X.21, RS-530, and G.703), and each can be configured individually to operate with either internal or external timing signals.

Specifying a Serial Interface

To specify a serial interface, use this configuration command:

Specify the serial interface connector number with the argument unit.

For the Cisco 7000 series, specify the serial interface slot number with the argument slot. Specify the port number with the argument port.

Follow this command with the routing or bridging interface subcommands for your particular protocol or application, as described later in this manual.

The SCI and MCI cards can query the appliques to determine their types. However, they do so only at system startup, so the appliques must be attached when the system is started. Issue a show controllers serial or show controllers mci command to determine how the serial card has identified them. The command also will show the capabilities of the serial card and report controller-related failures.

The FSIP can query the port adapters to determine their cable types at system startup. Issue a show controllers cxbus command to determine how the serial processor has identified them. The command also shows the capabilities of the serial processor and reports controller-related failures.

Example

This command begins configuration on interface serial 0:

interface serial 0

On the Cisco 4000 platform, you can specify the serial Network Interface Module timing signal configuration with the following commands:

When the board is operating as a DCE and the DTE provides terminal timing (SCTE or TT), the dce-terminal-timing-enable command will cause the DCE to use SCTE from the DTE. When running the line at high speeds and long distances this prevents phase shifting of the data with respect to the clock. If SCTE is not available from the DTE, use no dce-terminal-timing-enable, which will cause the DCE to use its own clock instead of SCTE from the DTE.

When the board is operating as a DTE, the dte-invert-txc command inverts the TXC clock signal it gets from the DCE that the DTE uses to transmit data. Use this command 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. If the DCE accepts SCTE from the DTE, use no dte-invert-txc.

Using the NRZI Line Coding Format

All FSIP interface types 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. To enable NRZI format, use the following interface subcommand:

The default is no nrzi-encoding.

Example

In the following example, serial interface 3/0 is configured for NRZI encoding.

interface serial 3/0
nrzi-encoding

Enabling 32-bit CRC

All interfaces use a 16-bit cyclic redundancy check (CRC) by default but also support a 32-bit CRC. CRC is an error-checking technique that uses a calculated numeric value to detect errors in transmitted data. The designators 16 and 32 indicate the number of check digits per frame that are used to calculate the frame check sequence (FCS). CRC-16, which transmits streams of 8-bit characters, generates a 16-bit FCS. CRC-32 transmits longer streams at faster rates and therefore provides better ongoing error correction with few retransmissions. Both the sender and receiver must use the same setting.

CRC-16, the most widely used throughout the United States and Europe, is used extensively with wide-area networks (WANs).CRC-32 is specified by IEEE 802 and as an option by some point-to-point transmission standards. It is often used on SMDS networks and LANs.

The default for all serial interfaces is for 16-bit CRC. Use the following interface subcommand to enable 32-bit CRC on a serial interface:

Example

In the following example, the 32-bit CRC is enabled on serial interface 3/0.

interface serial 3/0
crc 32

Enabling the Internal Clock

When a DTE does not return a transmit clock, use the following interface subcommand to enable the internally generated clock on a serial interface:

The default setting is no transmit-clock-internal.

Example

In the following example, the internally generated clock is enabled on serial interface 3/0.

interface serial 3/0
transmit-clock-internal

Inverting the Transmit Clock Signal

Delays between the SCTE clock and data transmission indicate that the transmit clock signal might not be appropriate for the interface rate and length of cable being used. Different ends of the wire may have variances that differ slightly. Invert the clock signal to compensate for these factors.

Use the following interface subcommand to invert the clock signal on an interface:

Example

In the following example, the clock signal on interface serial 3/0 is inverted.

interface serial 3/0
invert-transmit-clock

Enabling Framed Mode

G.703-E1 interfaces have two modes of operation, framed and unframed. To enable framed mode, use the timeslot interface configuration command. To disable framed mode and use unframed mode, use the no form of this command.

The slot numbers can be in the range 0 through 31. Setting start-slot to 0 disables framing.

By default, G.703-E1 interfaces are configured for unframed operation. To restore the default, use the no form of this command or set the starting time slot to 0.

Enabling CRC4 Generation

To enable generation of the G.703-E1 CRC4, which is useful for checking data integrity while operating in framed mode, use the following interface configuration command:

By default, the G.703-E1 CRC4 is not generated. To restore the default, use the no form of this command.

Using Time Slot 16 for Data

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, use the following interface configuration command:

To restore the default, use the no form of this command.

Specifying a Clock to Use

A G.703-E1 interface can clock its transmitted data either from its internal clock or from a clock recovered from the line's receive data stream. To control which clock is used, use the following interface configuration command:

By default, the port adapter uses clock source line to clock its data.

Serial Encapsulation Methods

The serial interfaces support the following kinds of serial encapsulations:

• High-level Data Link Control (HDLC)

• HDLC Distant Host (HDH)

• Frame Relay

• Point-to-Point Protocol (PPP)

• Synchronous Data Link Control (SDLC)

• Switched Multimegabit Data Services (SMDS)

• Cisco Serial Tunnel (STUN)

• X.25-based encapsulations

With the exception of the PPP and HDLC encapsulations, these serial encapsulation methods are described in the "Configuring Packet-Switched Software" chapter of this manual. The HDLC serial encapsulation method is described in this section. PPP serial encapsulation is described later in this chapter in the section "Configuring the Point-to-Point Protocol."

Change the encapsulation method by using the interface configuration subcommand encapsulation, followed by a keyword that defines the encapsulation method.

The encapsulation-type argument is a keyword that identifies one of the following serial encapsulation types that the software supports:

• bfex25--Blacker Front End Encryption X.25 operation

• ddnx25-dce--DDN X.25 DCE operation

• ddnx25--DDN X.25 DTE operation

• frame-relay--Frame Relay

• hdh--HDH protocol

• hdlc--HDLC protocol

• lapb-dce--X.25 LAPB DCE operation

• lapb--X.25 LAPB DTE operation

• multi-lapb-dce--X.25 LAPB multiprotocol DCE operation

• multi-lapb--X.25 LAPB multiprotocol DTE operation

• ppp--Point-to-Point Protocol (PPP)

• sdlc-primary--IBM serial SNA

• sdlc-secondary--IBM serial SNA

• smds--SMDS service

• stun--STUN protocol functions

• x25-dce--X.25 DCE operation

• x25--X.25 DTE operation

HDLC Serial Encapsulation Method

Cisco provides HDLC serial encapsulation for serial lines. This encapsulation method provides the synchronous framing and error detection functions of HDLC without windowing or retransmission. Although HDLC is the default serial encapsulation method, it can be reinstalled using the hdlc keyword with the encapsulation command as follows:

Configuring the Point-to-Point Protocol

The Point-to-Point Protocol (PPP), described in RFCs 1331 and 1332, is designed to encapsulate Internet Protocol (IP) datagrams and other network layer protocol information over point-to-point links.

The current implementation of PPP supports no configuration options. The software sends no options, and any proposed options are rejected.

Of the possible upper-layer protocols, only IP is supported at this time. Thus, the only upper-level protocol that can be sent or received over a point-to-point link using PPP encapsulation is IP. Refer to RFC 1134 for definitions of the codes and protocol states.

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.

The Point-to-Point Protocol is enabled on an interface using the encapsulation interface subcommand followed by the ppp keyword.

Example

These commands enable PPP encapsulation on serial interface 1/0:

interface serial 1/0
encapsulation ppp

Maintaining the Serial Interface

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

The arguments type and unit specify a particular interface type and its unit number. In this case, the argument type is serial.

For the Cisco 7000 series, specify serial for the argument type. The slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface and can be 0, 1, 2, or 3 for the serial interface.

Monitoring the Serial Interface

In general, use the command show interfaces to display information about the serial interface. Enter this command at the EXEC prompt:

The argument type is specified as serial and unit is the interface unit number. If you do not provide values for the parameters type and unit, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

For the Cisco 7000 series, specify serial for the argument type. If you do not provide values for type, slot, and port, the command displays statistics for all network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample outputs of this command for Cisco's HDLC synchronous serial interfaces follows. Table 1-6 describes the fields.

> show interfaces serial 0 
Serial 0 is up, line protocol is up
  Hardware is MCI Serial
  Internet address is 150.136.190.203, subnet mask is 255.255.255.0
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 0:00:07, output 0:00:00, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     16263 packets input, 1347238 bytes, 0 no buffer
     Received 13983 broadcasts, 0 runts, 0 giants
     2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts
     1 carrier transitions 

When you use the accounting option, only the accounting statistics are displayed.

> show interfaces serial 0 accounting
Serial0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Using the NRZI Line Coding Format

Nonreturn to zero inverted (NRZI) is a line coding format that is required for serial connections in some environments. Any type of serial connection (RS-232, V.35, RS-449, and X.21) can use NRZI encoding, and it is often implemented in IBM environments using RS-232 connections. Software control of NRZI encoding is a feature on the Cisco 3104 and Cisco 3204 only.

Use the following interface subcommand to enable NRZI encoding on a serial interface:

The default is no nrzi-encoding.

Example

In the following example, interface 1 is configured for NRZI encoding.

interface serial 1
nrzi-encoding

Monitoring the Interface Port

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, discussed earlier in this chapter, 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:

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

The following example shows an interface port that has a G.703 cable attached:

7000# show controller cxbus
FSIP 2, hardware version 1.0, microcode version 170.10
  Microcode loaded from flash rharagan/fsip_q170-10
  Interface 16 - Serial2/0, electrical interface is G.703 Unbalanced
    10 buffer RX queue threshold, 15 buffer TX queue limit, buffer size 1520
    ift 0001, rql 9, tq 0000 0000, tql 15
    Transmitter delay is 0 microseconds
  Interface 17 - Serial2/1, electrical interface is G.703 Unbalanced
    11 buffer RX queue threshold, 14 buffer TX queue limit, buffer size 2104
    ift 0001, rql 10, tq 0000 0000, tql 14
    Transmitter delay is 0 microseconds
  Interface 18 - Serial2/2, electrical interface is G.703 Balanced
    10 buffer RX queue threshold, 15 buffer TX queue limit, buffer size 1520
    ift 0001, rql 8, tq 0000 0420, tql 15
    Transmitter delay is 0 microseconds
  Interface 19 - Serial2/3, electrical interface is G.703 Balanced
    10 buffer RX queue threshold, 15 buffer TX queue limit, buffer size 1520
    ift 0001, rql 8, tq 0000 0428, tql 15
    Transmitter delay is 0 microseconds

To change the electrical interface type or mode of a 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 and reenable the interface after changing the cable.

Debugging the Serial Interface

Use the commands debug serial-interface and debug serial-packet to debug serial interface events. The EXEC commands are as follows:

Use debug serial-packet for detailed debugging information and debug serial-interface for more general information.

Use undebug serial-interface and undebug serial-packet to turn off messaging from these debug commands.

ISDN Basic Rate Interface (BRI) Support

The Integrated Services Digital Network ( ISDN) Basic Rate Interface (BRI) is currently supported on the Cisco 3000 only. The BRI includes one Ethernet connection and one ISDN Basic Rate connection. The Basic Rate connection consists of a D channel and two B channels, both of which are full-duplex, 64-kbps channels. The D channel is used for call setup only, and the B channels transmit user data. The B channels are treated as serial lines and support HDLC and PPP encapsulation.

Specifying an ISDN BRI

Use the following interface command to configure an interface for ISDN support:

This interface configuration is propagated to each of the B channels. B channels cannot be individually configured.

The interface must be configured with dial-on-demand commands in order for calls to be placed on that interface. See the "Configuring Dial-on-Demand Routing" section later in this chapter.

Cisco's BRI supports a variety of central office switches. Use this interface command to configure a central office switch:

Possible values for the switch-type argument are as follows:

• basic-5ess--ATT 5ESS

• basic-dms100--NT DMS 100

• vn2--French VN2 standard

• kdd--KDD ISDN switch

• ntt--NTT ISDN switch

• basic-1tr6--German switch standard

You must configure a single switch type.

ISDN BRI Encapsulation Methods

Each of the B channels is treated as a serial line and supports HDLC and PPP encapsulation.

Change the encapsulation method by using the interface configuration subcommand encapsulation, followed by a keyword that defines the encapsulation method.

The encapsulation-type argument is a keyword that identifies one of the encapsulation types supported on a BRI: hdlc or ppp.

Maintaining the ISDN BRI

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

Monitoring the ISDN BRI

Use this command to display information about the BRI D and B channels:

Use the optional arguments to display B-channel information. The argument first can be either 1 or 2. The argument last can only be 2, indicating B channels 1 and 2. D-channel information is obtained by using the command without the optional arguments.

Sample outputs of this command for BRI interfaces follows. Table 1-7 describes the fields.

BRI0 is up, line protocol is up (spoofing)
  Hardware is BRI
  Internet address is 150.136.190.203, subnet mask is 255.255.255.0
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 0:00:07, output 0:00:00, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     16263 packets input, 1347238 bytes, 0 no buffer
     Received 13983 broadcasts, 0 runts, 0 giants
     2 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort
     22146 packets output, 2383680 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts
     1 carrier transitions 

Debugging the ISDN BRI

Use the commands debug serial-interface and debug serial-packet to debug interface events. The EXEC commands are as follows:

Use debug serial-packet for detailed debugging information and debug serial-interface for more general information.

Use undebug serial-interface and undebug serial-packet to turn off messaging from these debug commands.

Use the following debug commands to debug traffic on the D channel, running CCITT-standard q921 and q931 protocols:

Use the following command to obtain summary information about ISDN events:

HSSI Interface Processor (HIP) Support

The high-speed serial interface processor (HIP) provides a single HSSI network interface for the Cisco 7000 series. The network interface resides on a modular interface processor (IP) that provides a direct connection between the high-speed Cisco Extended Bus (CxBus) and an external network.

Specifying the HIP

To configure the HSSI interface, specify the HIP with this configuration command:

The slot argument is the backplane slot number. It can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface. For the HIP interface, it must be 0.

After entering this command, you should immediately enter the routing or bridging interface subcommands for your particular protocol or application.

Issue a show controllers cbus command to determine how the HSSI card has identified the HIP. The command also will show the capabilities of the card and report controller-related failures.

Example

This command begins configuration on HIP interface 1/0:

interface hip 1/0

HIP Encapsulation Methods

The HIP supports the serial encapsulation methods described in the section "Serial Encapsulation Methods" earlier in this chapter.

Maintaining the HIP

Use the command clear interface to reset the hardware logic on a HIP interface. Enter this command at the EXEC prompt:

The argument type is the interface type, which is hssi. Specify the interface slot number with the argument slot. Specify the port number with the argument port. This is always 0 for a HIP port because each HIP provides only one interface.

Monitoring the HSSI Interface

Use the show interfaces command to display information about the HSSI interface. Enter this command at the EXEC prompt. (If you omit all the arguments, the command displays information about every interface in the router.)

Specify the optional arguments type, slot, and port to display statistics for a particular network interface. The argument type is hssi. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

The following is a sample output of this command. Table 1-8 describes the fields.

router# show interface hssi 1/0
Hssi1/0 is up, line protocol is up
  Hardware is cxBus HSSI
  Internet address is 131.108.38.14, subnet mask is 255.255.255.0
  MTU 1500 bytes, BW 45045 Kbit, DLY 1000000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 0:00:00, output 0:00:08, output hang never
  Last clearing of "show interface" counters never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 1000 bits/sec, 2 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     630573548 packets input, 2077237628 bytes, 0 no buffer
     Received 2832063 broadcasts, 0 runts, 0 giants
              0 parity, 1970 rx disabled
     113 input errors, 20 CRC, 93 frame, 0 overrun, 0 ignored, 0 abort
     629721628 packets output, 1934313295 bytes, 0 underruns
     0 output errors, 0 applique, 62 interface resets, 0 restarts
     309 carrier transitions
> show interfaces hssi 1/0 accounting
HIP1/0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Debugging the HIP

Use the command debug serial-interface to debug HSSI events. Enter this command at the EXEC prompt:

Enter the undebug serial-interface command to turn off debugging.

Ethernet Interface Support

Support for the Ethernet interface is supplied on one of the following Ethernet network interface cards:

• The Multiport Communications Interface (CSC-MCI) card, which provides up to two Ethernet connectors compatible with Ethernet Versions 1 and 2 and the IEEE 802.3 protocol.

• The Multiport Ethernet Controller (CSC-MEC) interface card, which provides two, four, or six high-speed Ethernet connectors compatible with Ethernet Versions 1 and 2 and the IEEE 802.3 protocol.

• The high-speed Ethernet Interface Processor (EIP) for two, four, or six AUI ports. The EIP ports are in compliance with Ethernet versions 1 and 2 and the IEEE 802.3 specifications.

The Ethernet interface also is supported on the IGS network server.

The AGS+, Cisco 4000, and Cisco 7000 routers support fast switching of IP packets between Ethernet and FDDI interfaces. When packets are being sent from FDDI to Ethernet interfaces and you are not using MTU Path Discovery, FDDI packets with data lengths larger than 1500 bytes will be fragmented into multiple Ethernet packets. This will slow performance. If the majority of your router traffic travels off the FDDI ring, you might want to either lower the MTU size on your host FDDI interfaces to 1500 bytes or run IP MTU Path Discovery.

Specifying an Ethernet Interface

To specify an Ethernet interface, use this configuration command:

Specify the Ethernet interface connector number with the argument unit. For the Cisco 7000 series, specify the Ethernet interface connector location with the arguments slot and port.

Follow this command with the routing or bridging interface subcommands for your particular protocol or application as described later in this manual.

Example

This command begins configuration on interface Ethernet 1.

interface ethernet 1

On the Cisco 4000 platform, you can specify the Ethernet Network Interface Module configuration with the following interface subcommands:

When you are connecting to Ethernet by means of the 15-pin connector, use the aui keyword.

When you are connecting to Ethernet by means of the RJ45 connector, use the 10baset keyword. Additionally, you can extend the twisted-pair 10BaseT capability beyond the standard 100 meters by using the squelch reduced command.

Ethernet Encapsulation Methods

The Ethernet interface supports a number of encapsulation methods. These methods are assigned by using the interface subcommand encapsulation followed by a keyword that defines the encapsulation method. The encapsulation method used depends on the protocol. Currently, there are three common Ethernet encapsulation methods:

• The standard Ethernet Version 2.0 encapsulation that uses a 16-bit protocol type code

• The IEEE 802.3 encapsulation, in which the type code becomes the frame length for the IEEE 802.2 LLC encapsulation (destination and source Service Access Points and a control byte)

• The SNAP method, as specified in RFC 1042, which allows Ethernet protocols to run on IEEE 802.2 media

The syntax of the encapsulation command follows.

The encapsulation-type is one of the following three keywords:

• arpa--Standard Ethernet Version 2.0 encapsulation

• iso1--IEEE 802.3 encapsulation

• snap--IEEE 802.2 Ethernet media

Example

These commands enable standard Ethernet Version 2.0 encapsulation on interface Ethernet 0:

interface ethernet 0
encapsulation arpa

Maintaining the Ethernet Interface

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

The arguments type and unit specify a particular interface type and its unit number. In this case, the argument type is ethernet.

For the Cisco 7000 series, the argument type specifies a particular interface type. In this case, it is ethernet. The slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface and can be 0, 1, 2, 3, 4, or 5 for Ethernet interfaces. The interface slot and port numbers can be displayed with the show interfaces command, as described in the next section.

Monitoring the Ethernet Interface

Use the command show interfaces to display information about the Ethernet interface. Enter this command at the EXEC prompt:

The argument type is ethernet and unit is the interface unit number. If you do not provide values for the parameters type and unit, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

For the Cisco 7000 series, type is the ethernet keyword, slot is the slot location of the interface processor, and port is the interface port number. If you do not provide values for the parameters type, slot, and port, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample output of this command follows.Table 1-9 describes the fields.

> show interfaces ethernet 0
Ethernet 0 is up, line protocol is up
  Hardware is MCI Ethernet, address is aa00.0400.0134 (bia 0000.0c00.4369)
  Internet address is 131.108.1.1, subnet mask is 255.255.255.0
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, PROBE, ARP Timeout 4:00:00
  Last input 0:00:00, output 0:00:00, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 2 drops
  Five minute input rate 61000 bits/sec, 4 packets/sec
  Five minute output rate 1000 bits/sec, 2 packets/sec
     2295197 packets input, 305539992 bytes, 0 no buffer
     Received 1925500 broadcasts, 0 runts, 0 giants
     3 input errors, 3 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3594664 packets output, 436549843 bytes, 0 underruns
     8 output errors, 1790 collisions, 10 interface resets, 0 restarts

When you use the accounting option, only the accounting statistics are displayed.

> show interfaces ethernet 0 accounting
Ethernet0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Debugging the Ethernet Interface

Use the command debug broadcast to debug MAC broadcast packets. Enter this command at the EXEC prompt:

Use the undebug broadcast command to turn off messaging.

Use the command debug packet to enable a log of packets that the network is unable to classify. Examples of this are packets with unknown link type or IP packets with an unrecognized protocol field. Enter this command at the EXEC prompt:

Use the undebug packet command to turn off messaging.

Token Ring Interface Support

Support for the Token Ring interface is supplied on one of the following Token Ring network interface cards:

• The single-port 4-Mbps Token Ring card (CSC-R), which interconnects network servers to IEEE 802.5 and IBM-compatible Token Ring media.

• The 4/16-Mbps Token Ring cards, which interconnect network servers to IEEE 802.5 and IBM-compatible Token Ring media at speeds of 4 or 16 megabits per second. The 4/16-Mbps cards are the CSC-C2CTR,CSC-R16 (or CSC-R16M), CSC-1R, and CSC-2R (dual Token Ring card).

• The high-speed Token Ring Interface Processor (TRIP), which has four DB-9 ports and interconnects network servers to IEEE 802.5 and IBM-compatible Token Ring media.

The Token Ring interface supports both routing (Level 3 switching) and source-route bridging (Level 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 not the optional Timer Table of the Token Ring MIB. The Token Ring MIB has been implemented for the CSC-1R, CSC-R16, CSC-2R (dual-port Token Ring), and CSC-C2CTR (Token Ring card for the CSC-CTL2 controller) cards. No support for the CSC-R card has been provided.

Specifying a Token Ring Interface

To configure a Token Ring interface, use this configuration command:

Specify the card number with the argument unit.

For the Cisco 7000 series, the slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface and can be 0, 1, 2, or 3 for Token Ring interfaces. The interface slot and port numbers can be displayed with the show interfaces command.

Follow this command with the bridging interface subcommands for your particular protocol or applications as described later in this manual.

Example

This command begins configuration on the first Token Ring interface:

interface tokenring 0

Configuring Ring Speed for IGS/TR

The Token Ring interface on the IGS/TR can run at either 4 or 16 Mbps. This speed is software selectable. The IGS/TR does not default to any particular ring speed; the default must be provided the first time the IGS/TR is used.

Caution Configuring a ring speed that is wrong or incompatible with the connected Token Ring will cause the ring to beacon, which effectively takes the ring down and makes it nonoperational.

Use the ring-speed interface subcommand to set ring speed for an IGS/TR Token Ring interface. The command syntax is as follows:

The argument speed can be either 4 or 16. When specified as 4, ring speed is set for 4-Mbps operation; when specified to 16, ring speed is set for 16-Mbps operation. The default is 16.

Example

The following commands set an IGS/TR Token Ring interface ring speed to 4 Mbps:

interface tokenring 0
ring-speed 4

Configuring Early Token Release

The CSC-C2CTR, CSC-R16 (or CSC-R16M), CSC-2R, CSC-1R, and TRIP cards, as well as the IGS-TR, Cisco 3000, and Cisco 4000 systems, all support early token release, a method whereby these interfaces can release 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. The following interface subcommands control the use of this feature:

By default, early token release is not enabled on the interface. The no early-token-release command disables this feature.

Example

For example, to enable the use of early token release on your token ring 1 interface, issue the following configuration commands:

interface tokenring 1
early-token-release

Token Ring Encapsulation Methods

It is not necessary to define an encapsulation method for the Token Ring interface; by default it uses the SNAP encapsulation format defined in RFC 1042.

Maintaining the Token Ring Interface

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

The arguments type and unit specify a particular interface type and its unit number. For the Cisco 7000 series, the arguments type, slot, and port specify a particular interface processor type and its location.In this case, the argument type is tokenring.

Monitoring the Token Ring Interface

Use the command show interfaces to display information about the Token Ring interface and the state of source-route bridging. Enter this command at the EXEC prompt:

The argument type is the keyword tokenring and unit is the interface unit number. If you do not provide values for the parameters type and unit, the command will display statistics for all the network interfaces.

For the Cisco 7000 series the slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface and can be 0, 1, 2, or 3. The interface processor slot and port numbers can be displayed with the show interfaces command.

The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample output of this command follows.Table 1-10 describes the fields.

> show interfaces tokenring 0
TokenRing 0 is up, line protocol is up
  Hardware is 16/4 Token Ring, address is 5500.2000.dc27 (bia 0000.3000.072b)
  Internet address is 150.136.230.203, subnet mask is 255.255.255.0
  MTU 8136 bytes, BW 16000 Kbit, DLY 630 usec, rely 255/255, load 1/255
  Encapsulation SNAP, loopback not set, keepalive set (10 sec)
  ARP type: SNAP, ARP Timeout 4:00:00
  Ring speed: 16 Mbps
  Single ring node, Source Route Bridge capable
  Group Address: 0x00000000, Functional Address: 0x60840000
  Last input 0:00:01, output 0:00:01, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     16339 packets input, 1496515 bytes, 0 no buffer
     Received 9895 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     32648 packets output, 9738303 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets, 0 restarts
     5 transitions

When you use the accounting option, only the accounting statistics are displayed.

> show interfaces tokenring 0 accounting
TokenRing 0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Debugging the Token Ring Interface

Use the EXEC command debug token-ring to display messages about the Token Ring interface activity. This command reports several lines of information for each packet sent or received and is intended for low traffic, detailed debugging.

The Token Ring interface records detailed information regarding the current state of the ring. These messages are only displayed when debug token-events is enabled.

Enter the undebug token-ring and undebug token-event commands to turn off the messages.

The last ring status message is displayed in the EXEC command show interfaces display for a Token Ring interface.Table 1-11 describes the messages displayed by this command.

FDDI Support

FDDI is an ANSI-defined standard for timed 100-Mbps token passing over fiber-optic cable. Support for the Fiber Distributed Data Interface (FDDI) is provided on Cisco Systems' FDDI interface cards, which include the CSC-FCI and the CSC-C2/FCIT. The CSC-C2/FCIT interface card operates with the cBus II controller complex. Support is also provided on the high-speed multimode-to-multimode, single mode-to-single mode, multimode-to-single mode, or single mode-to-multimode FDDI Interface Processor (FIP).

Cisco's implementation of FDDI complies with Version 6.1 of the X3T9.5 FDDI specification, offering a Class A dual-attach interface that supports the fault-recovery methods of the Dual-Attach Stations (DASs).

For the Cisco 4000 series routers, two types of FDDI network processor module are supported:

• Dual-attachment FDDI network processor module, PHY-A multimode/PHY-B multimode

• Single-attachment FDDI network processor module, PHY-S multimode

This implementation of FDDI complies with Version 6.2 of the X3T9.5 FDDI specification, offering Class A dual-attachment interfaces that support the fault-recovery methods of dual-attached stations (DASs), and Class B single-attached stations (SASs).

An FDDI network consists of two counter token-passing fiber-optic rings. On most networks, the primary ring is used for data communication and the secondary ring is used as a hot standby. The FDDI standard sets total fiber lengths of 2 kilometers for multimode fiber and 10 kilometers for single-mode fiber, both of which are supported by Cisco's FDDI interface controller. (The maximum circumference of the FDDI network is only half the specified kilometers because of the wrapping or the looping back of the signal that occurs during fault isolation.) The FDDI standard allows a maximum of 500 stations with a maximum distance between active stations of two kilometers. The FDDI frame can contain a minimum of 22 bytes and a maximum of 4500 bytes.

Cisco also provides 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 Cisco supports is snmpFddiSMTCFState.

The AGS+, Cisco 4000, and Cisco 7000 routers support fast switching of IP packets between Ethernet and FDDI interfaces. When packets are being sent from FDDI to Ethernet interfaces and you are not using MTU Path Discovery, FDDI packets with data lengths larger than 1500 bytes will be fragmented into multiple Ethernet packets. This will slow performance. If the majority of your router traffic travels off the FDDI ring, you might want to either lower the MTU size on your host FDDI interfaces to 1500 bytes or run IP MTU Path Discovery.

Specifying an FDDI

To specify an FDDI, use the following configuration command:

Specify the interface number with the argument unit.

For the Cisco 7000 series, the slot argument is the backplane slot number and can be 0, 1, 2, 3, or 4. The port argument is the port number of the interface and is 0 for FDDI interfaces. The interface slot and port numbers can be displayed with the show interfaces command.

Follow this command with the routing or bridging interface subcommands for your particular protocol or application as described later in this manual.

FDDI Encapsulation Methods

By default, the FDDI module uses the SNAP encapsulation format defined in RFC 1042. Therefore, it is not necessary to define an encapsulation method for this interface when using the CSC-FCI interface card or FDDI network processor module.

The CSC-C2/FCIT interface card fully supports transparent and translational bridging for the following configurations:

• FDDI to FDDI

• FDDI to Ethernet

• FDDI to Token Ring

When using the CSC-C2/FCIT interface card or FDDI module, specify the encapsulation method by using the following FDDI interface subcommand:

The command fddi encapsulate puts the FDDI interface into encapsulation mode when performing bridging functions. FDDI encapsulation causes the FDDI interface to interoperate with CSC-FCI and CSC-FCIT cards if these cards are set for encapsulation and are performing bridging functions on the same ring. The command no fddi encapsulate turns off encapsulation bridging and returns the FCIT interface to its translational, nonencapsulating mode. The no fddi encapsulate command applies only to the FDDI module and the new FCIT interface on the AGS+ platform family, because the CSC-FCI interfaces are always in encapsulating bridge mode.

When you are translationally bridging, you have to route routable protocols and translationally bridge the rest (such as LAT).

Warning Bridging between dissimilar media presents several problems that can prevent communications from occurring. These problems include bit-order translation (or usage of MAC addresses as data), maximum transmission unit (MTU) differences, frame status differences, and multicast address usage. Some or all of these problems may be present in a multimedia bridged LAN, thus preventing communication from taking place. These problems are most prevalent when bridging between Token Rings and Ethernets or between Token Rings and FDDI nets. This is because of the different way Token Ring is implemented by the end nodes.

Cisco currently knows that the following protocols have problems when bridged between Token Ring and other media: Novell IPX, DECnet Phase IV, AppleTalk, VINES, XNS, and IP. Further, the following protocols may have problems when bridged between FDDI and other media: Novell IPX and XNS. Cisco recommends that these protocols be routed whenever possible.

Auto-Shutdown of FDDI

On the Cisco 4000 series router, you can set a connection management (CMT) threshold value with the cmt-max-rate command. If the CMT event rate exceeds the cmt-max-rate specified, the FDDI shuts down. This indicates a serious problem with the Physical or MAC layer of the FDDI, and you should contact your Cisco representative. You can issue a no shut comand to bring the interface back up.

The argument number is the threshold number of CMT events at which the FDDI shuts down. The lowest possible value for number is 500; it defaults to 2500. You can disable the detection of this threshold and the resulting automatic shutdown feature of FDDI by setting the cmt-max-rate very high, 100000, for example. However, doing so will prevent the threshold detection and cause a performance impact that may include your router locking up and no packets being routed.

The no cmt-max-rate command returns the cmt-max-rate to the default value of 1500 events per second.

Ethernet-to-FDDI Fast Switching of IP

The Cisco 4000 series router supports fast switching of IP packets between Ethernet and FDDI interfaces.

Enabling Fast Switching

Use the following command to control the use of a high-speed switching cache for IP routing:

The route cache is enabled by default and allows outgoing packets to be load balanced on a per-destination basis. To enable load balancing on a per-packet basis, use the no ip route-cache command to disable fast switching.

Cisco routers generally offer better packet transfer performance when fast switching is enabled, with one exception. On networks using slow serial links (56K and below), disabling fast switching to enable per-packet load sharing is usually the best choice.

When packets are being sent from FDDI to Ethernet interfaces (and you are not using MTU Path Discovery), FDDI packets with data lengths larger than 1500 bytes will be fragmented into multiple Ethernet packets. This will slow performance. If the majority of your router traffic travels off of the FDDI ring through the routers you might want to lower the MTU size on your host FDDI interfaces to 1500 bytes or run IP MTU Path Discovery.

Ethernet-to-FDDI Fast Switching of IPX

The Cisco 4000 series router supports fast switching of IPX packets between Ethernet and FDDI interfaces.

Enabling Novell Fast Switching

Novell fast switching allows higher throughput by using a cache created by previous transit packets to switch the packet. Fast switching also provides load sharing on a per-packet basis.

Use the following interface subcommand to enable fast switching:

When Novell routing is enabled, Novell fast switching is enabled by default on the appropriate interface. Use the no novell route-cache command to disable fast switching.

Displaying the Novell Cache Entries

Use the following command at the EXEC prompt to display a list of fast-switching cache entries:

Example

Following is sample output of the show novell cache command:

> show novell cache
Novell routing cache version is 9
Destination	       Interface 	MAC Header
*1006A                     Ethernet0              00000C0062E600000C003EB0064
*14BB                      Ethernet 1             00000C003E2A00000C003EB0064

In the sample display, valid entries are marked by an asterisk (*).

Table 1-12 describes the show novell cache display fields.

Monitoring the FDDI

Use the command show interfaces to display information about the FDDI interface. Enter this command at the EXEC prompt:

The argument type is the keyword fddi, unit is the interface unit number, slot is the slot number, and port is the port numhber. If you do not provide values for the parameters type and unit, the command will display statistics for all network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Examples

Following is a sample of a partial display of FDDI-specific data from the show interfaces command output on a Cisco 4000 series router. Table 1-13 describes the fields displayed. Additional messages that could appear are provided at the end of the table.

Router> show interfaces fddi 0
Fddi 0 is up, line protocol is up
  Hardware is DAS FDDI, address is 0000.0c01.77d6 (bia 0000.0c01.77d6)
  Internet address is 192.195.77.9, subnet mask is 255.255.255.248
  MTU 4470 bytes, BW 100000 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation SNAP, loopback not set, keepalive not set
  ARP type: SNAP, ARP Timeout 4:00:00
  Phy-A state is connect, neighbor is unknown, status no signal
  Phy-B state is active, neighbor is A, status ILS
  CFM is Wrap_B, requested token rotation 60000 usec, negotiated 5000 usec
  Configured tvx is 2000 usec, using 5242.90 usec, ring operational 0:00:04
  6507 SMT frames processed, 81 dropped, 4 SMT buffers
  Upstream neighbor 5500.2000.a82c, downstream neighbor 5500.2000.a82c
  Last input 0:00:02, output 0:00:00, output hang never
  Last clearing of "show interface" counters never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     702435 packets input, 2310306095 bytes, 0 no buffer
     Received 4620 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     698864 packets output, 2305913785 bytes, 0 underruns
     0 output errors, 0 collisions, 3 interface resets, 0 restarts
     20 transitions

When you use the accounting option, only the accounting statistics are displayed; that is, the number of packets of each protocol type that have been sent through the interface.

> show interfaces fddi 0 accounting
Fddi0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Using Connection Management (CMT) Information

Connection management (CMT) is an FDDI process that handles the transition of the ring through its various states (off, on, active, connect, and so on) as defined by the X3T9.5 specification. Information about CMT bits that is received as a result of the FDDI monitoring commands discussed in this section can be helpful if your network server is not successfully establishing a connection to the remote physical connections.

The show interfaces fddi display 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 neighbor is determined from the received signal bits, as follows:

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 next state. The ten bits of CMT information are transmitted and received in the Signal State. Each state displays the number of times it was entered. In the preceding display, the Next State (Nxt) was entered 11 times.

The CFM state is wrap A in the sample output because the network server has not completed CMT with its neighbor to connect to Physical B.

The display (or nondisplay) of the upstream and downstream neighbor does not affect the ability to route data. The determination of the upstream and downstream neighbors is dependent upon all stations on the ring running the same version of Station Management (SMT). 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.

Debugging the FDDI

Use the following EXEC commands to monitor the state of the FDDI interface. (Note that each command has a corresponding undebug command that turns off the messages displayed by these commands.)

The debug fddi-smt-packets command enables the logging of FDDI station management (SMT) packets. The headers for inbound SMT frames and complete output of SMT frames are displayed. The debug fddi-cmt-events command enables the logging of FDDI connection management (CMT) transactions. You will not see any output with this command; it has no observable effect. See the X3T9.5 specification for more information about these packets and transactions.

FDDI Special Commands and Configurations

You can use special FDDI interface subcommands to request a token rotation time, set the transmission valid timer, and start and stop FDDI. This section also describes FDDI dual homing, which is a configuration capability that is built into FDDI software.

Setting Token Rotation Time

Large FDDI networks that have many nodes, such as large networks on single-mode FDDI, require longer token rotation times (TRTs ). You also may want to increase the token rotation time if you are seeing FDDI performance problems.

Use the following interface subcommand to request a token rotation time:

The argument microseconds is the requested token rotation time. The default value is 5000 microseconds. The microseconds value can be between 4000 and 165,000.

As defined in the X3T9.5 specification, the value remaining in the 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.

Example

These commands set the rotation time to 24000 microseconds:

interface fddi 0
fddi token-rotation-time 24000

Setting the Transmission Valid Timer

Use the following interface subcommand to set the transmission valid timer (TVX) interval:

The argument microseconds sets the TVX interval. It can have a value from 40 to 1342200. The chipset can use only discrete TVX values, so the hardware will not always use the exact value you enter; it rounds up to the next discrete value. The default TVX value is 3400 microseconds. Use the show interfaces command to display the value currently in use.

Example

These commands change the transmission timer interval to 3000 microseconds. For the Cisco 4000 series routers, the chipset can use only discrete TVX values; therefire, when you select 3000, the actual value will be 5242 microseconds.

interface fddi 0
fddi valid-transmission-time 3000

Transmitting a Physical Sublayer Line State

Use the fddi tl-min-time interface subcommand to control the FDDI TL_MIN time. The FDDI TL_MIN time is the minimum time to transmit a Physical Sublayer (PHY) line state before advancing to the next physical connection management (PCM) state, as defined by the X3T9.5 specification.

The specification defines the argument microseconds to be a value of 30. This value is used during the connection management (CMT) phase to ensure that signals are maintained for at least the value of TL_MIN so the remote station can acquire the signal.

Example

These commands change the TL_MIN time from 30 microseconds to 100 microseconds:

interface fddi 0
fddi tl-min-time 100

Setting Bit Control

Use the fddi cmt-signal-bits interface subcommand to control the information transmitted during the CMT signaling phase.

The argument signal-bits is written as a hexadecimal number preceded by "0x"; for example, "0x208." The keywords phy-a and phy-b select the Physical Sublayer (Physical A or Physical B station), for control of each fiber.

The FDDI standard defines nine bits of signaling information (signal-bits) that must be transmitted:

• bit 0--Escape bit. Reserved for future assignment by the FDDI standards committee.

• bits 1 and 2--Physical type, as defined in Table 1-14.

Bits 1 and 2 are transmitted (signaled), and each physical type determines whether it is allowed to connect to a type at the other end.

• bit 3--Physical compatibility. Set if topology rules include the connection of a physical-to-physical type at the end of the connection.

• bits 4 and 5--Link Confidence test duration; set as defined in Table 1-15.

Controlling CMT Microcode

The CSC-FCI and CSC-C2/FCIT interface cards provide Connection Management (CMT) functions in microcode. These functions are separate from those provided on the processor card and accessed through EXEC commands. The following interface subcommand controls whether the CMT onboard functions are on or off:

The default is for the FCIT CMT functions to be on. A typical use of the no fddi if-cmt command is when you work with new FDDI equipment and have problems bringing up the ring. When you use this command to disable the CMT microcode, the following actions occur:

• The FCIT CMT microcode is disabled.

• The main system code performs the CMT function while debugging output is generated.

Starting and Stopping the FDDI

In normal operation, the FDDI interface is operational once the interface is connected and configured and is turned off using the shutdown interface subcommand described in the section "Shutting Down and Restarting an Interface" earlier in this chapter. The privileged EXEC commands cmt connect and cmt disconnect allow the operator to start and stop the processes that perform the Connection Management (CMT) function and particularly, allow the ring on one fiber to be stopped.

Use the following privileged EXEC commands to start and stop the processes that perform the connection management (CMT) function and particularly, allow the ring on one fiber to be stopped:

The optional argument interface-name specifies the particular FDDI interface. The optional keywords phy-a and phy-b specify a Physical Sublayer (A or B).

Examples--Starting FDDI

The following commands demonstrate use of the cmt connect commands for starting the CMT processes on the FDDI ring.

This command starts all FDDI interfaces:

cmt connect

This command starts both fibers on the FDDI interface unit 0 (zero):

cmt connect fddi 0

This command starts only Physical Sublayer A on the FDDI interface unit 0 (zero):

cmt connect fddi 0 phy-a

Examples--Stopping FDDI

The following commands demonstrates using the cmt disconnect command for stopping the CMT processes on the FDDI ring.

This command stops all FDDI interfaces:

cmt disconnect

This command stops FDDI interfaces unit 0:

cmt disconnect fddi 0

This command stops only Physical Sublayer A on the FDDI interface unit 0 (zero). This command causes the FDDI media to go into a wrapped state so that the ring will be broken.

cmt disconnect fddi 0 phy-a

FDDI Dual-Homing Configuration

Dual homing occurs when each PHY on a DAS station is connected to a different concentrator on the same FDDI ring. Using this configuration, a failure of one of the concentrators will not cause lost connections.

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.

Setting the Connection Management Event Threshold

You can configure a threshold of connection management (CMT) events that will cause the FDDI interface to automatically shut down once the threshold is exceeded.

Set the threshold of CMT events using the following command:

number is the threshold, in events per second. The default threshold is 1500, and the minimum is 500. There is no upper bound on this value. However, setting a very large threshold (100000 or above) effectively disables the automatic shutdown capability.

Controlling FDDI SMT Frame Buffering

Although most configuration for FDDI interfaces involves specific interface settings, a router's ability to buffer FDDI Station Management (SMT) frames is controlled globally. The following brief description outlines how you can control the buffering of SMT messages that are queued for processing.

Setting SMT Message Queue Size

In FDDI, upstream and downstream neighbors are determined by transmitting and receiving SMT Neighbor Information Frames (NIFs). An increase in the number of dropped SMT frames indicates that there are not enough SMT buffers. The smt-queue-threshold command helps ensure that the routers keep track of FDDI upstream and downstream neighbors.

The router can appear to lose track of neighbors when it receives an SMT frame and the queue currently contains an unprocessed frame. This occurs because the router discards incoming SMT frames if the queue is full. Discarding SMT NIF frames can cause the router to lose its upstream or downstream neighbor.

Use the following global configuration command to set the maximum number of unprocessed station management (SMT) frames that will be held for processing:

The argument number specifies the number of buffers used to store unprocessed SMT messages that are to be queued for processing. Acceptable values are positive integers.

The value of number can be 0 to 255 buffers. Setting it to 0 will stop any SMT frames from being processed. The default value for number is 20.

The command no smt-queue-threshold configures a queue of 20 buffers.

Example

The following example specifies that the SMT queue can hold ten messages. As SMT frames are processed by the system, the queue is decremented by one.

smt-queue-threshold 10

High-Speed Serial Interface (HSSI) Support

The High-Speed Serial Interface (HSSI) consists of the following two components:

• CSC-HSCI controller card, which is cBus-resident

• CSC-HSA, which is a back panel applique

The controller card provides a single, full-duplex, synchronous serial interface capable of transmitting and receiving data at up to 52 megabits per second. The HSSI is a de facto industry standard providing connectivity to T3 (DS-3), E3, SMDS (at a DS-3 route), and other high-speed wide-area services through a DSU or Line Termination Unit.

The high-speed, full-duplex, synchronous serial interface is supported only on Cisco's modular network server products.

Specifying the HSSI

To specify the HSSI, use this configuration command:

Specify the interface connector number with the argument unit.

Follow this command with the routing or bridging interface subcommands for your particular protocol or application as described in later in this manual.

The cBus cards can query the appliques to determine their types. However, they do so only at system startup, so the appliques must be attached when the system is started. Issue a show controllers cbus command to determine how the HSSI card has identified them. The command also will show the capabilities of the card and report controller-related failures.

Example

This command begins configuration on interface HSSI 0:

interface hssi 0

HSSI Encapsulation Methods

The HSSI supports the serial encapsulation methods described in the section "Serial Encapsulation Methods," earlier in this chapter.

Maintaining the HSSI

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

The arguments type and unit specify a particular interface type and its unit number. In this case, the argument type is hssi.

Monitoring the HSSI

Use the command show interfaces to display information about the HSSI interface. Enter this command at the EXEC prompt:

Here, type is the keyword hssi and unit is the interface unit number. If you do not provide values for the parameters type and unit, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample output of this command for HSSI is provided below. Table 1-16 describes the fields.

> show interfaces hssi 0
HSSI 0 is up, line protocol is up
  Hardware is cBus HSSI
  Internet address is 150.136.67.190, subnet mask is 255.255.255.0
  MTU 4470 bytes, BW 45045 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 0:00:03, output 0:00:00, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     0 packets input, 0 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
              0 parity, 0 rx disabled
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     17 packets output, 994 bytes, 0 underruns
     0 output errors, 0 applique, 4 interface resets, 0 restarts
     2 carrier transitions   

When you use the accounting option, only the accounting statistics are displayed.

> show interfaces hssi 0 accounting
HSSI0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Debugging the HSSI

Use the command debug serial-interface to debug HSSI events. Enter this command at the EXEC prompt:

Enter the undebug serial-interface command to turn off messaging.

UltraNet Interface Support

The UltraNet Interface consists of the following two components:

• The CSC-HSCI, which is a cBus resident card

• The CSC-ULA, which is a back panel applique.

The UltraNet Interface provides connectivity to the UltraNet product offered by Ultra Network Technologies.

Specifying an UltraNet Interface

To specify an UltraNet interface, use this configuration command:

Specify the UltraNet interface connector number with the argument unit.

Follow this command with the appropriate routing or bridging interface subcommands for your particular protocol or application as described in later in this manual.

Example

This command begins configuration on UltraNet interface 0:

interface ultranet 0

UltraNet Encapsulation Method

The UltraNet interface supports the UltraNet encapsulation only. Therefore, there is no encapsulation command for the interface. It will default to UltraNet encapsulation.

Maintaining the UltraNet Interface

Use the command clear interface to reset the hardware logic on an interface. Enter this command at the EXEC prompt:

The arguments type and unit specify a particular interface type and its unit number. In this case, the argument type is ultranet.

Monitoring the UltraNet Interface

Use the command show interfaces to display information about the serial interface and the state of source bridging. Enter this command at the EXEC prompt:

The argument type is the keyword ultranet and unit is the interface unit number. If you do not provide values for the parameters type and unit, the command will display statistics for all the network interfaces. The optional keyword accounting displays the number of packets of each protocol type that have been sent through the interface.

Sample output of this command for synchronous serial interfaces follows. Table 1-17 describes the fields.

> show interfaces ultranet 0
UltraNet 0 is up, line protocol is up
  Hardware is cBus UltraNet, address is 8/32
  Internet address is 150.136.68.190, subnet mask is 255.255.255.0
  MTU 3500 bytes, BW 125000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
  Encapsulation ULTRANET, loopback not set, keepalive set (10 sec)
  ARP type: ULTRA
  Last input 0:00:09, output 0:00:09, output hang never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  Five minute input rate 0 bits/sec, 0 packets/sec
  Five minute output rate 0 bits/sec, 0 packets/sec
     6 packets input, 236 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants
              0 parity, 0 rx disabled
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     6 packets output, 236 bytes, 0 underruns
     0 output errors, 0 applique, 1 interface resets, 0 restarts   

When you use the accounting option, only the accounting statistics are displayed.

> show interfaces ultranet 0 accounting
Ultranet0
       Protocol    Pkts In   Chars In   Pkts Out  Chars Out
             IP       7344    4787842       1803    1535774
      Appletalk      33345    4797459      12781    1089695
        DEC MOP          0          0        127       9779
            ARP          7        420         39       2340

Statically Assigning UltraNet Addresses

Sometimes it is necessary to statically assign the UltraNet MAC layer address to the interface. This mechanism is needed if dynamic address assignment is not implemented on the Ultra Network Technologies interface on the network. Use the ultranet address interface subcommand to assign the MAC layer address of the interface:

The argument ultranet-mac-address is the MAC address of the UltraNet service line.

Example

These commands assign address 8/32 to the UltraNet interface:

interface ultranet 0
ultranet address 8/32

Loopback Interface Support

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.

To specify a loopback interface, use the following configuration command:

The unit argument is the number of the loopback interface that you want to create or configure. There is no limit on the number of loopback interfaces you can create.

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 aux 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.

Example

These commands enable loopback mode and assign an IP network address and network mask to the interface. The loopback interface established here will always appear to be up.

Configuring Dial Backup Service

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:

• The primary line goes down.

• The transmitted traffic load on the primary line exceeds a defined limit.

These conditions are defined using the interface subcommands 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 Terminal Adapter (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 also can 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 also can 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.

Configuring the Dial Backup Line

Use the backup interface interface subcommands to configure the serial interface as a secondary, or dial backup, line. The commands have this syntax:

The argument interface-name or slot/port specifies the serial port to be set as the secondary interface line.

Use the no backup interface command with the appropriate serial port designation to turn this feature off.

Example

These commands set serial 1 as the backup line to serial 0:

interface serial 0
backup interface serial 1

Defining the Traffic Load Threshold

Use the backup load interface subcommands to set the traffic load thresholds. The commands have this syntax:

Enter the arguments enable-threshold and disable-load using percentage numbers representing the load as a percentage of the primary line's available bandwidth.

When the transmitted or received load on the primary line is greater than the value assigned to the enable-threshold argument, the secondary line is enabled.

When the transmitted load on the primary line plus the transmitted load on the secondary line is less than the value entered for the disable-load argument, and the received load on the primary line plus the received load on the secondary line is less than the value entered for the disable-load argument, the secondary line is disabled.

If the never keyword is used instead of an enable-threshold value, the secondary line is never activated due to load. If the never keyword is used instead of an disable-load value, the secondary line is never deactivated due to load.

By default, no backup loads are defined.

Example

This example sets the traffic load threshold to 60 percent on the primary line. When that load is exceeded, the secondary line is activated, and will not be deactivated until the combined load is less than 5 percent of the primary bandwidth.

interface serial 0
backup load 60 5

Defining the Backup Line Delay

Use the backup delay interface subcommands to define how much time should elapse before a secondary line is set up or taken down (after a primary line transitions). The commands have the following syntax:

The argument enable-delay is the delay in seconds after the primary line goes down before the secondary line is activated.

The argument disable-delay is the delay in seconds after the primary line goes up before the secondary line is deactivated.

When the primary line goes down, the router delays the amount of seconds defined by the enable-delay argument before enabling the secondary line. If, after the delay period, the primary line is still down, the secondary line is activated.

When the primary line comes back up, the router will delay the amount of seconds defined by the disable-delay argument. If the disable-load condition described previously can be satisfied, or if the secondary is never activated due to load, then the secondary line also is deactivated.

Use the never keyword to prevent the secondary line from being activated or deactivated.

The never version is the default value for backup delay. In order for the secondary line to be activated when the primary line fails, a backup delay value must be specified.

Example

This example sets a ten-second delay on deactivating the secondary line; however, the line is activated immediately.

interface serial 0
backup delay 0 10

Dial Backup Configuration Examples

This section contains three examples of different dial backup configurations.

Example 1

The following example configures serial 1 as a secondary line that activates only when the primary line (serial 0) goes down. The secondary line will not be activated due to load of the primary.

interface serial 1/1
backup interface serial 2/2
backup delay 30 60

The secondary 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.

Example 2

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.

Example 3

This 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.

Configuring Dial-on-Demand Routing

Dial-on-demand routing (DDR) provides network connections in an environment using the public switched telephone network (PSTN). Traditionally, networks have been interconnected using dedicated lines for WAN connections. When used with modems, ISDN terminal adapters, or integrated ISDN capabilities, DDR provides low-volume, periodic network connections over a PSTN. This section details the commands required to interconnect Cisco routers and the PSTN using data communications equipment (DCE) devices and dial-on-demand routing.

Cisco's DDR Implementation

DDR allows attachment to modems and ISDN terminal adapters (TAs) that support V.25 bis dialing. It is also used with integrated ISDN support. V.25 bis is a CCITT recommendation for initiating calls using an automatic calling unit (ACU). V25 bis is useful for establishing calls when transmitting synchronous data.

DDR supports large internetworks with many routers through its support of public circuit-switched networks such as telephone lines, ISDN, or switched services provided by the telephone companies.

The V.25 bis specification describes two modes of establishing or receiving calls: the direct call mode and the addressed call mode. Cisco routers support connections using the addressed call mode and synchronous, bit-oriented operation. The addressed call mode allows the use of control signals and commands sent over the DCE data interface to establish and terminate calls. These commands are packaged in synchronous data frames (HDLC type) and are sent when the interface is not in use for data transfer (that is, when a call does not exist on the line).

Cisco routers support connections from synchronous serial interfaces on the router to any DCE device that supports V.25 bis. Typically, these devices are V.32 (9.6 kbps) or V.32 bis modems (14.4 kbps). Supported devices also include ISDN TAs for ISDN B-channel connections.

The DDR call-initiating process is driven by certain characteristics of bridged or IP-routed packets. A router activates the dial-on-demand feature when it receives a bridged or routed IP packet destined for a location on the other side of the dial-up line. After the router dials the destination phone number and establishes the connection, packets of any protocol that Cisco supports can be transmitted. When the transmission is complete, the line is automatically disconnected.

In order for the router to use a device for dialing out, in addition to V.25 bis, the device must support certain hardware signals. When the router drops DTR, the device must disconnect any calls that are currently connected. When the device connects to the remote side, the device must have DCD become active.

For bridged traffic, packets of interest are based on packet type as specified with the hexadecimal value in a bridge access list. Refer to the "Configuring Transparent Bridging" chapter of this manual for more information about bridge access lists.

For IP traffic, packets of interest are based on the destination address; with a routed IP packet, the destination address used is the next hop address. Packets of interest are defined with IP access lists. Refer to the "Routing IP" chapter of this manual for more information about IP access lists.

Figure 1-1 illustrates a typical interconnection featuring dial-on-demand routing.

Specifying Dialer Type

Use the dialer in-band interface subcommand to specify that dial-on-demand routing is to be supported on a synchronous serial line. The syntax for this command is as follows:

This command specifies that V.25 bis dialing is to be used on the specified interface. It is used only with serial interfaces. Also, you can specify parity. This is provided because the 1984 version of the V.25bis specification states that characters must have odd parity. The parity applies to the dialer string that is sent out to the V.25bis modem. If you do not specify a parity, or if you specify the no-parity keyword, no parity is applied to the output number. If odd-parity is configured, the dialed number will have odd parity (7-bit ASCII characters and 8th bit [MSB] being the parity bit).

The no dialer in-band command disables dial-on-demand routing for the interface.

Example

The following example specifies dial-on-demand routing for serial 0:

interface serial 0
dialer in-band

When dialer in-band is specified, CRN is added to the front of the strings that are sent to the V.25 bis DCE. CRN is a V.25 bis command that specifies that the string that follows is a number to be called. This number is specified using the dialer string or dialer map commands described later in this chapter.

ISDN Support

A dialer type does not need to be specified for ISDN interfaces. The software will automatically configure these interfaces to be dialer type ISDN.

Controlling Dialer Idle Time

Use the optional dialer idle-timeout interface subcommand to specify the idle time before the line is disconnected. The syntax for this command is as follows:

The argument number-of-seconds specifies in seconds how much idle time must occur on an interface before the line is disconnected. Acceptable values are positive, nonzero integers. If no value is entered, the default is 120 seconds.

The no dialer idle-timeout command resets the idle timeout to the default.

Example

The following example specifies of an idle timeout of three minutes (180 seconds) on interface serial 1:

interface serial 1
dialer idle-timeout 180

Setting Idle Time for Busy Interfaces

Use the optional dialer fast-idle interface subcommand to specify the idle time before the line is disconnected for interfaces for which there is an unusually high level of contention. The syntax for this command is as follows:

The argument number-of-seconds specifies in seconds how much idle time must occur on an interface before the line is disconnected. Acceptable values are positive, nonzero integers. If no value is entered, the default is 20 seconds.

This timer is used when an interface is connected and a packet is received for a different destination (phone number). If the duration specified for the dialer fast-idle command is exceeded and no traffic has been detected on the connection during the fast idle period, the link is disconnected. This makes the port available for making connections to an alternate destination (after the dialer enable-timeout period expires) and reduces idle time on an interface.

This command only applies if multiple destinations have been specified for a given interface using the dialer map interface subcommand.

The no dialer fast-idle resets the timeout period to the default.

Example

The following example specifies a fast idle timeout of 35 seconds on interface serial 1:

interface serial 1
dialer fast-idle 35

Specifying Dialer Enable Time

Use the optional dialer enable-timeout interface subcommand to set the length of time an interface stays down before it is available to dial again. The command syntax is as follows:

Acceptable values for number-of-seconds are positive, nonzero integers. If no value is entered, the default is 15 seconds. When a call terminates (for example hangs up or is busy), this is the amount of time that the router waits before the next call can occur on the specific interface.

The no dialer enable-timeout command resets the enable timeout value to the default.

Example

The following example specifies a waiting period of 30 seconds on interface serial 1:

interface serial 1
dialer enable-timeout 30

Specifying Carrier Wait Time

Use the optional dialer wait-for-carrier-time interface subcommand to specify how long to wait for a carrier. The command syntax is as follows:

The argument number-of-seconds specifies in seconds how long to wait for carrier to come up when a call is placed. Acceptable values are positive, nonzero integers. If no value is entered, the default is 30 seconds. If a carrier signal is not detected in this amount of time, the interface is disabled until the enable timeout occurs.

The wait-for-carrier time is set to a default of 30 seconds, because this is the estimated time required to make a typical connection over telephone lines. However, if connections are being made via ISDN links, this time probably would be configured for five or ten seconds.

The no dialer wait-for-carrier-time command resets the carrier wait time value to the default.

Example

The following example specifies a carrier wait time of 45 seconds on interface serial 1:

interface serial 1/1
dialer wait-for-carrier-timeout 45

Specifying a Single DDR Telephone Number

Use the dialer string interface subcommand to specify the string (telephone number) to be called. The command syntax is:

The argument dial-string specifies the character string to be called. Dialers configured as in-band, pass the string to the external DCE. ISDN devices call the number specified in the string. One dialer string command is specified per interface.

To specify multiple strings, use the dialer map command, discussed next. However, you must use the dialer string command if you intend to bridge traffic over the serial link or transmit broadcast traffic. In general, you include a dialer string or dialer map command if you intend to use a specific interface to initiate a dial-on-demand call.

The dial-string number specified in the dialer string command is the default number used under the following conditions:

• A dialer map command is not included in the interface configuration

• The next-hop-address specified in a packet is not included in any of the dialer map interface subcommands recorded--assuming that the destination address passes any access lists specified for dial-on-demand via the dialer-list command (discussed later in this section)

• When bridging

CCITT V.25 bis Options

Depending on the type of modem or ISDN Terminal Adapter (TA) you are using, CCITT V.25 bis options are supported as dial-string parameters of the dialer string command. The functions of the parameters are nation specific, and they may have different implementations in your country. These options apply only if you have enabled DDR with the dialer in-band command. These options are not supported in the dialer string for native ISDN BRI interfaces. Refer to your manual for the modem or TA you are using for a list of supported options.

The no dialer string command deletes the dialer string specified for the interface.

Examples

The following example specifies a dial-on-demand telephone number on interface serial 1 using the dialer string command:

interface serial 1
dialer string 14085553434

Multiple Destinations

The dialer string command is useful for environments in which a single site is calling another site but the other site is not calling out. Often, however, configurations are more complex, such as the hub-and-spoke environment shown in Figure 1-2. In this configuration multiple sites are calling in to a central site, and the central site is calling out to the remote sites.

In this configuration, PPP with CHAP authentication often is used to inform the central site about which remote routers are connected to it. (ISDN can provide the caller's phone number for identification, but the ISDN network often is configured to block this information.) Using CHAP authentication, each remote router identifies itself by a name, which informs the central router what routers are currently connected to it. This identification process prevents the central router from placing a call to a remote router if it is already connected to that router.

Specifying Multiple Destinations

There are three forms of the interface subcommand you can use to define multiple dial-on-demand numbers for a particular interface. They are as follows:

The first form of the dialer map command is used in central-site configurations in which remote sites are calling a central site, but the central site is not calling the remote site. With this command, the remote device will authenticate the central site using CHAP, which will cause its name to be transmitted to the central site. The central site will then use this name and the next-hop-address to correctly transmit packets to the remote site. Because there is no dialer string specified, the central site cannot call the remote router.

The second form of the command is used if only one site is being called or if ISDN is supported and the ISDN network will provide the caller's phone number. Note that the dialer string in this last case must be in the same format as the number provided by the ISDN network.

The third form is used if many remote sites are calling the central site and the central site also can call the remote sites. With this format, the central router can use the name to identify the remote routers after they authenticate and also can use the dialer string to call the remote routers if they are not currently connected. When you use a dialer map command with the name option on an interface, PPP and CHAP must be configured on that interface.

The keyword name indicates a remote system that the local router communicates with.

The following arguments can be used with this command:

• The argument protocol has only one option at this time: ip.

• The argument next-hop-address specifies the IP address used to match against addresses to which packets are destined.

• The argument hostname is the name of the remote device.

• The dial-string argument is the telephone number sent to the DCE dialing device when it sees packets with the specified next-hop-address that match the access lists defined.

Unlike the dialer string command, multiple dialer map commands can be specified per interface.

The dialer map command complements the dialer string command. The dial-string defined for the dialer string command is considered the default dialer string. If a packet does not match the protocol and the next-hop-address defined in the dialer map commands (but does pass an access list that requires initiation of automatic dialing), the default dialer string is used. This is often the case for broadcasts and is always the case for bridging.

The no dialer map command deletes a particular dialer map entry. To delete the entry, include the complete configuration string (no dialer map protocol next-hop-address dial-string).

Examples

In the following examples, a remote site is calling a central site, but the central site is not calling the remote site. The remote device will authenticate the central site using CHAP, which will cause its name,YYY, to be transmitted to the central site. The central site will then use this name and the next-hop-address, 131.108.2.5, to correctly transmit packets to the remote site. Because there is no dialer string specified, the central site cannot call the remote router.

interface serial 1
dialer map ip 131.108.2.5 name YYY

The following example specifies a dial-on-demand telephone number on interface serial 1 for a specific destination address using the dialer map command:

interface serial 1
dialer map ip 131.108.2.5 14155553434

The remote site is calling the central site, and the central site is calling the remote site. The central router can use the name, ZZZ, to identify the remote router after they authenticate and also can use the dialer string 14155553434 to call the remote router if it is not currently connected.

interface serial 1
dialer map ip 131.108.2.5 name ZZZ 14155553434

Dialer Rotary Groups

Dialer rotary groups allow you to apply a single interface configuration to a set of interfaces. Once the interface configuration is propagated to a set of interfaces, those interfaces can then be used to place calls using the standard dial-on-demand criteria. When many destinations are configured, any of these interfaces can be used for outgoing calls.

Dialer rotary groups are useful in environments that require many calling destinations. Only the rotary group needs to be configured with all of the dialer map commands. The only configuration required for the interfaces is the dialer rotary-group command indicating that each interface is part of a dialer rotary group.

Although a dialer rotary group is configured as an interface, it is not a physical interface. Instead it represents a group of interfaces. Any number of dialer groups can be defined.

Use the following interface command to designate a dialer rotary group leader:

The argument n is any number and indicates a dialer group.

Interface subcommands entered after the interface dialer command will be applied to all physical interfaces assigned to rotary group n.

Example

This example identifies interface dialer 1 as the dialer rotary group leader. Interface dialer 1 is not a physical interface, but represents a group of interfaces. The interface subcommands that follow apply to all interfaces included in this group. See the dialer rotary-group command, defined next.

interface dialer 1
encapsulation ppp
dialer in-band
dialer map ip 131.108.2.5 name YYY 1415553434
dialer map ip 131.126.4.5 name ZZZ

Use the following interface subcommand to include an interface in a dialer rotary group:

The argument n is the number of the rotary group (defined by the interface dialer command).

Example

The following configuration places serial interfaces 0 and 1 into dialer rotary group 1, defined by the interface dialer 1 command.

! PPP encapsulation is enabled for interface dialer 1. 
interface dialer 1
encapsulation ppp
dialer in-band
! The first dialer map command allows remote site YYY and the
! central site to call each other. The second dialer map command, with no
! dialer string, allows remote site ZZZ to call the central site but
! the central site can not call remote site ZZZ (no phone number).
dialer map ip 131.108.2.5 name YYY 1415553434
dialer map ip 131.126.4.5 name ZZZ
! The DTR pulse signals for three seconds on the interfaces in dialer 
! group 1. This holds the DTR low so the modem can recognize that DTR has been
! dropped. 
pulse-time 3
! Interfaces serial 0 and serial 1 are placed in dialer rotary group 1. All of
! the interface subcommands (the encapsulation and dialer map commands shown
! earlier in this example)applied to interface dialer 1 apply
! to these interfaces. 
interface serial 0
dialer rotary-group 1
interface serial 1
dialer rotary-group 1

Assigning Access Lists to a DDR Interface

Use the dialer-group interface subcommand to assign an interface to a set of access list expressions. These access list expressions define which packets cause a connection to be established and which packets keep an interface from being idle. The syntax for this command is as follows:

The argument group-number specifies the number of the dialer group to which the specific interface belongs. Acceptable values are nonzero, positive integers. This group number corresponds to a dialer group defined using the dialer-list command (described in the next section).

An interface only can be associated with a single dialer group; multiple dialer-group assignment is not allowed.

The no dialer-group command removes an interface from the specified dialer group.

Example

The following example specifies dialer group number 1. This dialer group number will be compared against any global dialer-list specifications. If there is a group number match, the destination address of the packet in question is evaluated against the access list specified in the associated dialer-list command. If it passes, a call is initiated or the idle timer is reset (if a call is currently connected).

interface serial 1
dialer-group 1

Using Access Lists with DDR

Control automatic dialing using DDR with the following combination: standard IP or bridging access lists; the dialer-list global command; and the dialer-group interface subcommand (described in the preceding section). Refer to the "Routing IP" and "Configuring Transparent Bridging" chapters of this manual for more information about access lists. The dialer-list global configuration command has two forms. They have the following syntaxes:

The argument dialer-group-number specifies the number of a dialer group identified in any dialer group interface subcommand.

The argument list-number is the access list number specified in any IP or bridging access list.

The argument protocol-name is one of the following supported protocols:

• ip--IP

• decnet--DECnet

• chaos--CHAOSnet

• xns--XNS

• novell--Novell IPX

• appletalk--AppleTalk

• vines--Banyan Vines

• apollo--Apollo Domain

• pup--PUP

• clns--OSI Connectionless Network Service

• bridge--Bridging

• stun--Serial tunneling

• cmns--OSI Connection-Mode Network Services

Example

Dialing occurs when an interesting packet (one that matches access list specifications) needs to be output on an interface. Using the standard access list method, packets can be classified as interesting or uninteresting. For example, to specify that IGRP updates are not interesting (relative to dial-on-demand automatic dialing), the following access list would be defined:

access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0

To permit all other IP traffic, the above would be followed by:

access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255

Then, the following command would be used to place list 101 into dialer group 1:

dialer-list 1 list 101

Dial-on-Demand Access-List Configuration Examples

The examples provided in this section illustrate various DDR configurations using access lists linked to DDR facilities provided with the router.

Example 1

The following example illustrates how dial-on-demand routing can be used in an IP environment:

interface serial 0
ip address 131.108.126.1 255.255.255.0
dialer in-band
dialer idle-timeout 600
dialer string 555-1234
pulse-time 1
dialer-group 1
!
access-list 101 deny   igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 list 101
ip route 131.108.29.0 131.108.126.2
ip route 131.108.1.0 131.108.126.2

Configuration specifications in this example define the following characteristics:

• dialer in-band command selects V.25 bis dialing.

• dialer idle-timeout 600 command sets the dialer idle timeout to ten minutes (600 seconds).

• dialer string 555-1234 command sets the phone number to be called to 555-1234.

• pulse-time 1 command (defined in the "Adjusting Interface Characteristics" chapter of this manual) sets the DTR pulse time to be one second. This is to give the modem enough time to recognize that DTR has dropped so the modem will disconnect the call.

• dialer-group 1 adds this interface to the dialer group defined with the dialer-list command.

• The first access list statement used specifies that IGRP updates to any address will not cause dialing. However, if a connection is already established, IGRP updates will be transmitted but will not reset the idle timers.

• The second access-list statement specifies that all other IP traffic--such as Ping, Telnet, or any other IP packet--will cause dialing.

• The dialer-list command then creates dialer group 1 and states that access list 101 is to be used to match for automatic dialing.

• The ip route commands specify that there is a route to network 131.108.29.0 and to network 131.108.1.0 via 131.108.126.2. This means that several destination networks are available via the serial port.

Example 2

The following example illustrates a configuration for bridging:

interface serial 0
ip address 131.108.126.10 255.255.255.0
dialer in-band
dialer string 555-1234
pulse-time 1
bridge-group 1
dialer-group 1
!
bridge 1 protocol dec
access-list 201 deny   0x6002 0x0000
access-list 201 deny   0x6003 0x0000
access-list 201 permit 0x0000 0xFFFF
dialer-list 1 LIST 201

As in Example 1, the dialer is set to use V.25 bis, the dialer string is specified and a pulse time is assigned. This interface is then added to bridge group 1 and dialer group 1.

The access lists work as follows:

• The first one states that DEC MOP packets are not to cause dialing.

• The second states that DECnet Phase IV should not cause dialing.

• The last states that all other bridged packets should cause dialing.

This example could be used in a case where LAT is the only traffic to be transmitted over the link.

Example 3

The following example is a combination of Examples 1 and 2. It illustrates how to handle DDR for bridging and IP routing over a single interface.

The first access-list statement specifies that RIP updates to the broadcast address do not cause dialing. However, if a connection is already established, RIP updates are transmitted, although they do not reset the idle timers and do not keep the line up.

interface serial 0
ip address 131.108.126.10 255.255.255.0
dialer in-band
dialer string 555-1234
pulse-time 1
bridge-group 1
dialer-group 1
!
bridge 1 protocol dec
access-list 101 deny  udp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0 eq 520     
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
access-list 201 deny   0x6002 0x0000
access-list 201 deny   0x6003 0x0000
access-list 201 permit 0x0000 0xFFFF
dialer-list 1 LIST 101
dialer-list 1 LIST 201

Example 4

The following example demonstrates how to specify multiple destination dial strings (phone numbers):

interface serial 0
ip address 131.108.126.1 255.255.255.0
dialer in-band
dialer wait-for-carrier-time 10
dialer string 555-1234
pulse-time 1
dialer-group 1
dialer map ip 131.108.126.10 555-8899
dialer map ip 131.108.127.1 555-5555
!
access-list 101 deny   igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101

As in Example 1, the serial interface is configured for V.25 bis. It also is set to have a wait-for-carrier-time of ten seconds, which is too short for POTS telephone lines but might be appropriate for ISDN lines. As before, a default dial string is configured, a pulse time assigned, and a dialer group specified.

The first dialer map command specifies that the number 555-8899 is to be dialed for IP packets with a next-hop-address of 131.108.126.10. The second dialer map then specifies that the number 555-5555 will be called when an IP packet with a next-hop-address of 131.108.127.1 is detected.

Access lists for this example match those defined in Example 1.

Example 5

The following example illustrates using floating static routes (see the section "Overriding Static Routes" in the "IP Routing Protocols" chapter of this manual) and dial-on-demand to perform the same functionality as dial backup, except using V.25 bis for dialing.

interface serial 0
ip address 131.108.126.1 255.255.255.0
dialer in-band
dialer wait-for-carrier-time 10
dialer string 555-1234
pulse-time 1
dialer-group 1
dialer map ip 131.108.126.10 555-8899
dialer map ip 131.108.127.1 555-5555
!
access-list 101 deny   igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101
ip route 131.108.42.0 131.108.126.10 150

The configuration is essentially the same as in Example 4, except for the addition of an ip route statement. This statement specifies that to reach network 131.108.42.0 through this router, traffic must use 131.108.126.10 as the gateway. This causes dialing to occur to 555-8899.

Because the ip route statement specifies an administrative distance (150), dynamic routing information will override the static route--no packets will normally be sent to 131.108.126.10. However, if the route that is learned dynamically disappears, and no other dynamic route is available, the static route will be used and dialing will occur. See the "IP Routing Protocols" chapter of this manual for more information on static routes.

Example 6

The following example demonstrates how to specify multiple destination dial strings (phone numbers) on the ISDN interfaces:

interface bri 0
ip address 131.108.126.1 255.255.255.0
dialer in-band
dialer wait-for-carrier-time 10
dialer string 555-1234
dialer-group 1
! Connection to 131.108.126.10 and 131.108.127.1 can be active 
! simultaneously if one network uses one B channel, while the other network
! uses the second B channel
dialer map ip 131.108.126.10 555-8899
dialer map ip 131.108.127.1 555-5555
!
access-list 101 deny igrp 0.0.0.0 255.255.255.255 255.255.255.255 0.0.0.0
access-list 101 permit ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255
dialer-list 1 LIST 101

Monitoring Dial-on-Demand Routing

To obtain a general diagnostic display for serial interfaces configured for dial-on-demand routing, use the show dialer EXEC command. The command syntax is as follows:

This command displays information about the dialer interfaces. If show dialer is specified, all dialers are displayed. An interface can be specified using show dialer interface option. The arguments interface and type specify the particular interface, and can be formed either as a two-part identifier (such as serial 0, ser 1, s 2, and so on) or as a name (serial1).

The following is a sample of output from the show dialer command with a serial interface:

Serial 0 - dialer type = IN-BAND
Idle timer (600 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dial String      Successes   Failures    Last called   Last status
8985                   0         2        0:24:10      Failed       Default
8986                   1         0        1:20:07      Successful

The following information is provided in this display:

• "IN-BAND" specification indicating that DDR is enabled

• Idle timeout specification (seconds)

• Fast-idle timer specification (seconds)

• Wait-for-carrier timer specification (seconds)

• Enable timeout specification (seconds)

• Dial strings of logged calls (telephone numbers)

• Successful connections (even if no data is passed)

• Failed connections--line busy when call attempted

• Time that last call occurred to specific dial string

• Last status of calls to specific dial string (successful or failed)

• If the DDR facility is using the dial string specified with the dialer string command, the word Default is appended to the Last status entry

The following is sample output from the show dialer command with an ISDN interface:

BRI - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
Dial String      Successes   Failures    Last called   Last status
4444401                0         1        15:28:53 	Failed       Default
81012345678901         0         0        never
81012345678902 	0	0	never
5555501	0	0	never
--More--
BRI0: B-Channel 1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (15 secs)
--More--
BRI0: B-Channel 2 - dialer type = ISDN
Idle timer (120 secs), Fast idle type = ISDN
Wait for carrier (30 secs), Re-enable (15 secs)

If the dialer is connected to another dialer (and the system from which the show dialer command was entered was the initiator of the call), a display is provided that indicates the idle time before the line is disconnected (decrements each second) and the duration of the current connection. The following is a sample of this display; it would appear after the third line in the show dialer display:

Time until disconnect 596 secs
Current call connected 0:00:25

After a call disconnects, the system displays the time remaining before being available to dial again. The following is a sample of this display; it would appear after the third line in the show dialer display.

Time until interface enabled 8 secs

If the show dialer interface command is issued for an interface on which DDR is not enabled, the system displays an error message. The following is a sample error message:

Serial 1 - Dialing not enabled on this interface.

If an interface is configured for DDR, the show interfaces command now displays the following:

Serial 0 is up, line protocol is up (spoofing)
Hardware is MCI Serial

The spoofing indicates that the line really is not up, but the dialer is forcing the line to masquerade as "up" so that upper-level protocols will continue to operate as expected.

Debugging Dial-on-Demand Routing

When DDR is configured for a serial interface, the EXEC commands debug serial-interface (described earlier in this chapter) and debug serial-packet can provide information associated with DDR activity, as follows:

This command enables monitoring of serial interface activity. For DDR, the following information may appear:

• A message indicating that a call is being attempted

• A message stating that no dialer group has been defined and dialing will not occur

• Messages indicating that idle timeouts, re-enable timeouts, and wait-for-carrier timeouts have occurred

• A message from the DCE device indicating the dial string attempted

The debug serial-packet command enables monitoring of serial packets.

When activated, and DDR is enabled on the interface, information concerning the cause of any calls (called Dialing cause) may be displayed. The cause for IP packets lists the source and destination addresses; the cause for bridged packets lists the type of packet in hexadecimal.

Configuring the Point-to-Point Protocol

The Point-to-Point Protocol (PPP), described in RFC 1134, is designed to encapsulate Internet Protocol (IP) datagrams and other network layer protocol information over point-to-point links. The document "Point-to-Point Initial Configuration Options" defines the set of options that are negotiated during startup.

The current implementation of PPP supports no configuration options. The software sends no options, and any proposed options are rejected.

Of the possible upper-layer protocols, only IP is supported at this time. Thus, the only upper-level protocol that can be sent or received over a point-to-point link using PPP encapsulation is IP. Refer to RFC 1134 for definitions of the codes and protocol states.

Cisco's implementation of PPP is compatible with RFCs 1331 and 1332, rather than RFC 1134.

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.

The Point-to-Point Protocol is enabled on an interface using the encapsulation interface subcommand followed by the ppp keyword.

Example

These commands enable PPP encapsulation on serial interface 0 (zero):

interface serial 0
encapsulation ppp

Challenge Handshake Authentication Protocol (CHAP)

Access control using Challenge Handshake Authentication Protocol (CHAP) is available on all serial interfaces. The authentication feature reduces the risk of security violations on your router. CHAP is supported only on lines using PPP encapsulation.

When CHAP is enabled, a remote device (a PC, workstation, router, or communication server) attempting to connect to the local router is requested, or "challenged," to respond. The challenge consists of a random number and the host name of the local router. This challenge is transmitted to the remote device. The required response is an encrypted version of a secret password, or "secret," plus the host name of the remote device. The remote device verifies the secret by looking up the host name that was received in the challenge. When the local router receives the challenge response, it verifies the secret by looking up the name of the remote device given in the response. The secret passwords must be identical on the remote device and the local router. These names and secret passwords are configured as described in the "Configuring Host Name Authentication" section later in this chapter.

By transmitting this response, the secret is never transmitted, thus preventing other devices 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 when 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 steps:

Step 1: Enable CHAP on the interface.

Step 2: Configure server authentication.

These steps are described later in this section.

CHAP is specified in RFC 1334. It is an additional authentication phase of the PPP Link Control Protocol.

Enabling CHAP on the Interface

To enable CHAP on the interface, use this interface command:

Once you have enabled CHAP, the local router requires a password from remote devices. If the remote device does not support CHAP, no traffic is passed to that device.

Configuring Host Name Authentication

Configure the secret using the following command:

Add a username entry for each remote system that the local router communicates with and requires authentication from. The remote device must have a username entry for the local router. This entry must have the same password as the local router's entry for that remote device.

The name argument is the host name of either the local router or a remote device.

The secret argument specifies the secret for the local router or the remote device. If no secret is specified, and debug serial-interface is enabled, an error is displayed when a link is established and protocol traffic is not passed. Debugging information on CHAP is available using the debug serial-interface and debug serial-packet commands. See the section "Interface Support EXEC Command Summary" later in this chapter for a description of these debugging commands.

The secret is encrypted when it is stored on the local router. This prevents it from being stolen. It can consist of any string of up to 11 printable ASCII characters. There is no limit to the number of username/password combinations that can be specified, allowing any number of remote devices to be authenticated using CHAP.

Example

The following example configuration enables CHAP on interface serial 0. It also defines a password for the remote server "YYY."

hostname XXX
interface serial 0
encapsulation ppp
ppp authentication chap
username YYY password theirsystem

When you look at your configuration file, the passwords are encrypted and the display looks similar to the following:

hostname XXX
interface serial 0
encapsulation ppp
ppp authentication chap
username YYY password 7 121F0A18

Example: Configuring Host Name Authentication

The following example configuration sets up secret passwords on routers A, B, and C, thus enabling the three routers to connect to each other.

To authenticate connections between routers A and B, enter the following commands:

On router A:

username B password a-b_secret

On router B:

username A password a-b_secret

To authenticate connections between routers A and C, enter the following commands:

On router A:

username C password a-c_secret

On router C:

username A password a-c_secret

To authenticate connections between routers B and C, enter the following commands:

On router B:

username C password b-c_secret

On router C:

username B password b-c_secret

Example: Dial-on-Demand PPP Configuration

The following example shows a configuration in which several aspects of DDR are used to provide DDR capabilities between local and remote routers. The following features are shown in this example.

• dialer map command

• PPP encapsulation

• CHAP

• Dialer rotary groups

• pulse-time command (see the "Adjusting Interface Characteristics" chapter of this manual for a description of this command)

! Enable PPP encapsulation and CHAP on interface dialer 1. 
interface dialer 1
ip address 131.108.2.1 255.255.255.0
encapsulation ppp
ppp authentication chap
! Specify dial-on-demand routing supported on a synchronous serial line 
! and assign a set of access-list expressions.
dialer in-band
dialer group 1
! The first dialer map command indicates that calls between the remote site
! YYY and the central site will be placed at either end. The second dialer
! map command, with no dialer string, indicates that remote site ZZZ will
! call the central site but the central site will not call out.
dialer map ip 131.108.2.5 name YYY 1415553434
dialer map ip 131.108.2.7 name ZZZ
! The DTR pulse holds the DTR low for three seconds, so the modem can
! recognize that DTR has been dropped. 
pulse-time 3
! Place serial interfaces 0 and 1 in dialer rotary group 1. The
! interface subcommands applied to dialer rotary group 1 (for example,
! PPP encapsulation and CHAP) apply to these interfaces. 
interface serial 0
dialer rotary-group 1
interface serial 1
dialer rotary-group 1
! CHAP passwords are specified for local and remote servers. 
username YYY password theirsystem
username ZZZ password thatsystem

Figure 1-3 shows a configuration in which remote routers YYY and ZZZ and local router XXX are using dial-on-demand routing, as configured in the previous example. In this configuration, remote routers YYY and ZZZ can call router XXX. Router XXX has dialer string information only for router YYY and cannot call router ZZZ.

Configuring the Null Interface

Support is provided for a null interface. This pseudo-interface functions similarly to the null devices available on most operating systems. This interface is always up and can never forward or receive traffic; encapsulation always fails.

The null interface provides an alternative method of filtering traffic. The overhead involved with using access lists can be avoided by directing undesired network traffic to the null interface.

To specify the null interface, specify null 0 (or null0) as the interface name and unit. The null interface can be used in any command that has an interface type as a parameter.

Example

This command configures a null interface for IP route 127.0.0.0:

ip route 127.0.0.0 null 0

Fast Switching on the Cisco 4000 Series

Table 1-19 shows the interfaces and protocols that support fast switching on the Cisco 4000 series.

Global Configuration Command Summary

The following summary lists the global configuration commands used for interface support.

[no] dialer-list dialer-group list list-number
[no] dialer-list dialer-group protocol protocol-name {permit|deny}

The argument dialer-group specifies the number of a dialer group identified in any dialer group interface subcommand.

[no] dialer idle-timeout number-of-seconds

The argument number-of-seconds specifies in seconds how much idle time must occur on an interface before the line is disconnected. Acceptable values are positive, nonzero integers. If no value is entered, the default is 120 seconds.

dialer map protocol next-hop-address name name
dialer map protocol next-hop-address dial-string
dialer map protocol next-hop-address name name dial-string