Initially Configuring the LightStream 1010 ATM Switch

This chapter discusses the initial configuration of the LightStream 1010 ATM switch. Because the LightStream 1010 offers true plug-and-play operation, most users might not need to perform any of these procedures.

The LightStream 1010 is shipped with the ATM address autoconfigured to an address assigned by Cisco Systems. This allows the switch to automatically configure attached end-systems using the Interim Link Management Interface (ILMI) protocol and to establish itself as a node in a single-level Private Network-Network Interface (PNNI) routing domain.

The ILMI and PNNI protocols, when used with such IP address autoconfiguration mechanisms as BOOTP, allow the LightStream 1010 to be entirely self-configured. Through network management applications and the text-based command-line interface (CLI), the switch's network operator has the capability, if desired, to configure and customize all aspects of the operation of the switch.

An IP address must be assigned to allow up to eight simultaneous Telnet sessions to connect to the switch or to use the Simple Network Management Protocol (SNMP) system for the switch. The Ethernet IP address can be assigned either manually or by a BOOTP server. See the section "Configure IP Interface Parameters."

Note If your Telnet station or SNMP network management workstation is on a different network from the switch, a static routing table entry must also be added to the routing table. Use the ip route command to set the static routing table entry.

For definitions of all commands discussed in this chapter, refer to the publication LightStream 1010 ATM Switch Command Reference.

The following sections describe the LightStream 1010 initial configuration:

Before You Begin Configuration

If you want to configure some additional features, you might need the following information before you can begin your LightStream 1010 configuration:

If you want to configure a BOOTP server to inform the switch of its Ethernet IP address and mask, you need the media access control (MAC) address of the Ethernet port.

If you want to configure a new ATM address for the switch (an autoconfigured ATM address is assigned by Cisco Systems), you will need an ATM address assigned by your system administrator.

If you are not using BOOTP, you will need an IP address and a Netmask address.

To help configure your switch complete the worksheets in the section "Port Configuration Worksheets" in the appendix "Configuration Worksheets."

Verify Installed LightStream 1010 Software and Hardware

When you first power up your console and LightStream 1010, a screen similar to the following appears:

              Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.
           cisco Systems, Inc.
           170 West Tasman Drive
           San Jose, California 95134-1706
Cisco Internetwork Operating System Software
IOS (tm) PNNI Software (LS1010-WP-M), Version 11.2(1.4.WA3.0.41)
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Tue 11-Feb-97 02:59 by
Image text-base: 0x600108D0, data-base: 0x603EE000
cisco ASP (R4600) processor with 16384K bytes of memory.
R4600 processor, Implementation 32, Revision 2.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
25 ATM network interface(s)
125K bytes of non-volatile configuration memory.
8192K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Press RETURN to get started!
Switch>

The first section of the script displays the banner information, including the software version.

The next portion of the script lists installed hardware configuration.

cisco ASP1 (R4600) processor with 16384K bytes of memory.
Cisco Internetwork Operating System Software
IOS (tm) PNNI Software (LS1010-WP-M), Version 11.2(1.4.WA3.0.41)
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Tue 11-Feb-97 02:59 by
Image text-base: 0x600108D0, data-base: 0x603EE000
cisco ASP (R4600) processor with 16384K bytes of memory.
R4600 processor, Implementation 32, Revision 2.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
25 ATM network interface(s)
125K bytes of non-volatile configuration memory.
8192K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Press RETURN to get started!
Switch>

The LightStream 1010 should be operating correctly and transferring data.

Note If an rommon> prompt appears your switch requires a manual boot to recover. See the section "Manually Boot from Flash memory" in the chapter "Loading System Images, Software Images, and Configuration Files."

BOOTP Server Configuration

The LightStream 1010 Ethernet IP address can automatically be assigned using the BOOTP protocol by adding the MAC and IP addresses of the Ethernet port to the BOOTP server configuration file. When the switch boots, it automatically retrieves the IP address from the BOOTP server.

The switch performs a BOOTP request only if the current IP address is set to 0.0.0.0. (This is the default for a new switch or a switch that has had its configuration file cleared using the erase startup-config command.)

To allow your LightStream 1010 to retrieve its IP address from a BOOTP server, you must first determine the MAC address of the switch and add that MAC address to the BOOTP configuration file on the BOOTP server. The following tasks provide an example of creating a BOOTP server configuration file:

Task Command

Install the BOOTP server code on the workstation, if it is not already installed.

None

Determine MAC address from label on chassis.

None

Add an entry in the BOOTP configuration file (usually /usr/etc/bootptab) for each switch. Press Return after each entry to create a blank line between each entry. Figure 4-1 is an example of a server BOOTP configuration file.

None

Restart the LightStream 1010 to automatically request the IP address from the BOOTP server.

restart

Task	Command
Install the BOOTP server code on the workstation, if it is not already installed.	None
Determine MAC address from label on chassis.	None
Add an entry in the BOOTP configuration file (usually /usr/etc/bootptab) for each switch. Press Return after each entry to create a blank line between each entry. Figure 4-1 is an example of a server BOOTP configuration file.	None
Restart the LightStream 1010 to automatically request the IP address from the BOOTP server.	restart

Figure 4-1 is an example of a BOOTP configuration file with the LightStream 1010 ATM switch entry added at the end of the example.

Figure 4-1: Example of a Server BOOTP Configuration File

# /etc/bootptab: database for bootp server (/etc/bootpd)
#
# Blank lines and lines beginning with '#' are ignored.
#
# Legend:
#
#       first field -- hostname
#                       (may be full domain name and probably should be)
#
#       hd -- home directory
#       bf -- bootfile
#       cs -- cookie servers
#       ds -- domain name servers
#       gw -- gateways
#       ha -- hardware address
#       ht -- hardware type
#       im -- impress servers
#       ip -- host IP address
#       lg -- log servers
#       lp -- LPR servers
#       ns -- IEN-116 name servers
#       rl -- resource location protocol servers
#       sm -- subnet mask
#       tc -- template host (points to similar host entry)
#       to -- time offset (seconds)
#       ts -- time servers
#
# Be careful about including backslashes where they're needed.  Weird (bad)
# things can happen when a backslash is omitted where one is intended.
#
# First, we define a global entry which specifies the stuff every host uses.
<information deleted>
#########################################################################
# Start of individual host entries
#########################################################################
Switch:         tc=netcisco0:   ha=0000.0ca7.ce00:      ip=192.31.7.97:
dross:          tc=netcisco0:   ha=00000c000139:        ip=192.31.7.26:
<information deleted>

ATM Address Configuration

The Lightstream 1010 ATM Switch is autoconfigured with an ATM address using a hierarchical addressing model similar to the OSI network service access point (NSAP) addresses. PNNI uses this hierarchy to construct ATM peer groups. ILMI uses the first 13 bytes of this address as the switch prefix that it registers with end systems.

Note The most important rule in the addressing scheme is to maintain the uniqueness of the address across very large networks.

Autoconfigured ATM Addressing Scheme

During the initial startup the LightStream 1010 generates an ATM address using the defaults shown in Figure 4-2:

Figure 4-2: ATM Address Format

Authority Format Identifier (AFI)-1 byte
Cisco specific International Code Designator (ICD)-2 bytes
Cisco specific information-4 bytes
Cisco switch ID-6 bytes (used to distinguish multiple switches)

Note This first 13 bytes of the address is a switch prefix used by ILMI in assigning addresses to end stations connected to UNI ports.

MAC address of the switch-6 bytes (used to distinguish multiple End System Identifier (ESI) addresses)

Note Both MAC address fields are the same but they might not be the same as the address on the chassis label.

Selector equals 0-1 byte

Default Address Format Features and Implications

Using the default address format has the following features and implications:

The default address format can also be used to manually configure other switches to allow them to be used in a single-level PNNI routing domain consisting primarily of autoconfigured Cisco ATM switches. A globally unique MAC address must be used to generate the ATM address.
The same MAC address can be used for bytes 8 through 13 and bytes 14 through 19.
This address assignment format is relatively flat. To achieve scalable ATM routing, addresses need to be changed when connecting to a large ATM network with multiple levels of PNNI hierarchy.
Summary addresses less than 13 bytes long must not be used with autoconfigured ATM addresses. Other switches with autoconfigured ATM addresses matching the summary can exist outside of the default peer group.

Manually Setting the ATM Address

To configure a new ATM address that replaces the previous ATM address when running IISP software only, see the section "Configure the ATM Address" in the chapter "Configuring ILMI."

To configure a new ATM address that replaces the previous ATM address and generates a new PNNI node ID and peer group ID, see the section "Configure PNNI Node" in the chapter "Configuring ATM Routing and PNNI."

Multiple addresses can be configured for a single switch and this configuration can be used during ATM address migration. ILMI registers end systems with multiple prefixes during this period until an old address is removed. PNNI automatically summarizes all of the switch prefixes in its reachable address advertisement.

If operation with ATM addresses other than the autoconfigured ATM address is desired, use the atm address command to manually assign a 20-byte ATM address to the switch. The atm address command address_template variable can be a full 20-byte address or a 13-byte prefix followed by ellipsis (...). Entering the ellipsis will automatically add one of the switch's 6-byte MAC addresses in the ESI portion and 0 in the selector portion of the address.

Caution ATM addressing can lead to conflicts if not configured correctly. The correct address must always be present. For instance, if you are configuring a new ATM address, the old one must be completely removed from the configuration.

Configure the Interfaces

When the switch is powered on initially without any previous configuration data, the ATM interfaces are automatically configured on the physical ports. ILMI and the physical card type are used to automatically derive the following:

ATM interface type
User-Network Interface (UNI) version
Maximum virtual path identifier (VPI) and virtual channel identifier (VCI) bits
ATM interface side
ATM UNI type.

See the chapter "Configuring Port Adapter Modules Interfaces" for the interface default configuration and modification procedures.

You can accept the default ATM interface configuration or overwrite the default interface configuration.using the command-line interface commands. These commands are described in the section "Configuring Virtual Connections."

Modify Default for Physical Layer Configuration of an ATM Interface

This section describes modifying an ATM interface from the default configuration listed in the chapter "Configuring Port Adapter Modules Interfaces." You can accept the ATM interface configuration or overwrite the default interface configuration using the command-line interface commands. These commands are described in the chapter "Configuring Virtual Connections."

The following example describes modifying an OC3 interface from the default settings to the following:

Disable scrambling cell-payload.
Disable scrambling sts-streaming.
Change synchronous optical network (SONET) mode of operation from synchronous time stamp (STS) 3c mode to synchronous transport mode (STM)-1.

To change the configuration of the example interface, use the following EXEC commands. Use the no form of this command to disable:

Task Command

At the privileged EXEC prompt, enter configuration mode from the terminal.

configure¹
[terminal]

Select the physical interface to be configured.

interface atm card/subcard/port

Disable cell-payload scrambling.

no scrambling cell-payload

Disable STS-stream scrambling.

no scrambling sts-stream

Configure SONET mode as SDH/STM-1.

sonet {stm-1|sts-3c}

Exit configuration mode.

exit

¹This command is documented in the LightStream 1010 ATM Switch Command Reference publication.

Task	Command
At the privileged EXEC prompt, enter configuration mode from the terminal.	configure¹ [terminal]
Select the physical interface to be configured.	interface atm card/subcard/port
Disable cell-payload scrambling.	no scrambling cell-payload
Disable STS-stream scrambling.	no scrambling sts-stream
Configure SONET mode as SDH/STM-1.	sonet {stm-1\|sts-3c}
Exit configuration mode.	exit

Example

The following example disables cell-payload scrambling and STS-stream scrambling and changes the SONET mode of operation to synchronous digital hierarchy/synchronous transfer module 1 (SDH/STM-1) of OC3 physical interface 0/0/0:

Switch(config)#interface atm 0/0/0

Switch(config-if)#no scrambling cell-payload

Switch(config-if)#no scrambling sts-stream

Switch(config-if)#sonet stm-1

Switch(config-if)#exit

Switch(config)#

To change any of the other physical interface default configurations refer to the commands in the LightStream 1010 ATM Switch Command Reference for detailed command syntax information.

Use show controller and show running-config commands to display the interface physical layer configuration.

To display the physical interface configuration, use the following commands:

Task Command

Show the physical layer configuration.

show controllers atm card/subcard/port

Show physical layer scrambling configuration.

show running-config

Task	Command
Show the physical layer configuration.	show controllers atm card/subcard/port
Show physical layer scrambling configuration.	show running-config

Examples

The following example displays the OC3 physical interface configuration after modification of the defaults using the show controllers command:

Switch#show controller atm 0/0/0

IF Name: ATM0/0/0    Chip Base Address: A8808000
Port type: 155UTP    Port rate: 155 Mbps    Port medium: UTP
Port status:PATH LOP    Loopback:PIF    Flags:8000
TX Led: Traffic Pattern    RX Led: Traffic Pattern
TX clock source:  free-running
Framing mode:  stm-1
OC3 counters:
  Key: txcell - # cells transmitted
       rxcell - # cells received
       b1     - # section BIP-8 errors
       b2     - # line BIP-8 errors
       b3     - # path BIP-8 errors
       ocd    - # out-of-cell delineation errors - not implemented
       g1     - # path FEBE errors
       z2     - # line FEBE errors
       chcs   - # correctable HEC errors
       uhcs   - # uncorrectable HEC errors
txcell:8501, rxcell:1165
b1:0, b2:0, b3:0, ocd:0
g1:0, z2:0, chcs:0, uhcs:0
OC3 errored secs:
b1:0, b2:0, b3:0, ocd:0
g1:0, z2:0, chcs:0, uhcs:0
OC3 error-free secs:
b1:0, b2:0, b3:0, ocd:0
g1:0, z2:0, chcs:0, uhcs:0
Clock reg:80
  mr 0x30, mcfgr 0x70, misr 0xE0, mcmr 0xEF,
  mctlr 0x48, cscsr 0x50, crcsr 0x20, rsop_cier 0x40,
  rsop_sisr 0x40, rsop_bip80r 0x00, rsop_bip81r 0x00, tsop_ctlr 0xC0,
  tsop_diagr 0xC0, rlop_csr 0x00, rlop_ieisr 0x0C, rlop_bip8_240r 0x00,
  rlop_bip8_241r 0x00, rlop_bip8_242r 0x00, rlop_febe0r 0x00, rlop_febe1r 0x00,
  rlop_febe2r 0x00, tlop_ctlr 0x80, tlop_diagr 0x80, rpop_scr 0x64,
  rpop_isr 0x67, rpop_ier 0x43, rpop_pslr 0x00, rpop_pbip80r 0x00,
  rpop_pbip81r 0x00, rpop_pfebe0r 0x00, rpop_pfebe1r 0x00, tpop_cdr 0x00,
  tpop_pcr 0x00, tpop_ap0r 0x00, tpop_ap1r 0x08, tpop_pslr 0x13,
  tpop_psr 0x00, racp_csr 0x86, racp_iesr 0x10, racp_mhpr 0x00,
  racp_mhmr 0x00, racp_checr 0x00, racp_uhecr 0x06, racp_rcc0r 0x00,
  racp_rcc1r 0x00, racp_rcc2r 0x00, racp_cfgr 0xFC, tacp_csr 0x06,
  tacp_iuchpr 0x01, tacp_iucpopr 0x6A, tacp_fctlr 0x00, tacp_tcc0r 0x00,
  tacp_tcc1r 0x00, tacp_tcc2r 0x00, tacp_cfgr 0x08,
Switch#

The following example displays the OC3 physical layer scrambling configuration after modification of the defaults using the show running-config command:

Switch#show running-config

Building configuration...
Current configuration:
!
version 11.2
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.112-1.4.WA3.0.15
!
ip host-routing
ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-username dplatz
ip domain-name cisco.com
ip name-server 198.92.30.32
atm filter-set tod1 index 4 permit time-of-day 0:0 0:0
!
atm service-category-limit cbr 64512
atm service-category-limit vbr-rt 64512
atm service-category-limit vbr-nrt 64512
atm service-category-limit abr-ubr 64512
atm qos default  cbr max-cell-loss-ratio clp1plus0 12
atm qos default  vbr-nrt max-cell-loss-ratio clp1plus0 12
atm address 47.0091.8100.0000.0041.0b0a.1081.0041.0b0a.1081.00
atm address 47.0091.8100.5670.0000.0000.0000.0040.0b0a.1081.00
atm router pnni
 node 1 level 56 lowest
  redistribute atm-static
!
!
interface ATM0/0/0
 no keepalive
 atm manual-well-known-vc
 atm access-group tod1 in
 atm pvc 0 35 rx-cttr 3 tx-cttr 3  interface  ATM2/0/0 0 any-vci  encap qsaal
 sonet stm-1
 no scrambling sts-stream
 no scrambling cell-payload
--More--

Configure IP Interface Parameters

IP addresses can be configured on the LightStream 1010 ASP interfaces. Each IP address is configured for one of the following types of connections:

Ethernet port-can be configured either from the BOOTP server or by using the ip address command in interface-configuration-mode for the Ethernet 2/0/0 interface.
Classical IP over ATM-See the section "Configure IP-Over-ATM Example" in the chapter "Configuring IP-Over-ATM and LAN Emulation."
LANE client-See the section "Configure LAN Emulation Client Example" in the chapter "Configuring IP-Over-ATM and LAN Emulation."
SLIP/PPP-See the chapter "Configuring Terminal Lines and Modem Support."

Note These IP connections are only used for network management.

Configure the switch to communicate via the Ethernet interface using the following information as a guide:

Provide the IP address and subnet mask bits for the interface as follows:

IP address

: Internet addresses are 32-bit values assigned to hosts that use the IP protocols. These addresses are in dotted decimal format (four decimal numbers separated by periods) such as 192.17.5.100. Each number is an 8-bit value between 0 and 255. The following is a summary of IP addressing concepts for those who are somewhat familiar with IP addressing.
: The addresses are divided into three classes; the classes differ in the number of bits allocated to the network and host portions of the address.
: The Class A Internet address format allocates the highest 8 bits to the network field and sets the highest-order bit to 0 (zero). The remaining 24 bits form the host field.
: The Class B Internet address allocates the highest 16 bits to the network field and sets the two highest-order bits to 1, 0. The remaining 16 bits form the host field.
: The Class C Internet address allocates the highest 24 bits to the network field and sets the three highest-order bits to 1, 1, 0. The remaining 8 bits form the host field.
: Default: None.
: Action: Enter your Internet address in dotted decimal format for each interface you plan to configure.

Subnet mask bits

: Subnetting is an extension of the Internet addressing scheme, which allows multiple physical networks to exist within a single Class A, B, or C network. The usual practice is to use a few of the far left bits in the host portion of the network address for a subnet field. The subnet mask determines whether subnetting is in effect on a network.
: Internet addressing conventions allow a total of 24 host bits for Class A addresses, a total of 16 host bits for Class B addresses, and a total of 8 host bits for Class C addresses. When you are further subdividing your network (that is, subnetting your network), the number of host addressing bits is divided between subnetting bits and actual host address bits. You must specify a minimum of two host address bits, or the subnetwork is not populated by hosts.

First Class	First Byte	Network Bits	Host Bits
Max Subnet Bits	Min Address Bits
A	1-126	8	22	2
B	128-191	16	14	2
C	192-223	24	6	2

Table 4-1: Summary of Subnetting Parameters

First Class First Byte Network Bits Host Bits

Max Subnet Bits Min Address Bits

A

1-126

8

22

2

B

128-191

16

14

2

C

192-223

24

6

2

: Default: 0.

Note Because all zeros in the host field specifies the entire network, subnetting with subnet address 0 is illegal and is strongly discouraged.

Define subnet mask bits as a decimal number between 0 and 22 for Class A addresses, 0 and 14 for Class B addresses, or 0 and 6 for Class C addresses. Do not specify 1 as the number of bits for the subnet field. That specification is reserved by Internet conventions.

To configure the IP address, perform the following tasks in interface configuration mode. Use the no form of these commands to assign the default value:

Task Command

At the privileged EXEC prompt, enter configuration mode from the terminal.

configure¹
[terminal]

Select the interface to be configured.

interface ethernet 2/0/0

Configure the IP and subnetwork address.

ip address A.B.C.D sub_net_A.B.C.D

¹These commands are documented in the LightStream 1010 ATM Switch Command Reference publication.

Task	Command
At the privileged EXEC prompt, enter configuration mode from the terminal.	configure¹ [terminal]
Select the interface to be configured.	interface ethernet 2/0/0
Configure the IP and subnetwork address.	ip address A.B.C.D sub_net_A.B.C.D

Example

The following example configures the Ethernet CPU interface 2/0/0 with IP address 172.20.40.93 and subnetwork mask 255.255.255.0:

Switch#config t

Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#
Switch(config)#interface ethernet ?
  <0-13>  Ethernet interface number
/
Switch(config)#interface ethernet 2/0/0 ?
  <cr>
Switch(config)#interface ethernet 2/0/0

Switch(config-if)#ip address ?
  A.B.C.D  IP address
Switch(config-if)#ip address 172.20.40.93 ?
A.B.C.D IP subnet mask
Switch(config-if)#ip address 172.20.40.93 255.255.255.0

Switch(config-if)#

Display the IP Address

To display the IP address configuration, perform the following task in user EXEC mode:

Task Command

Display the Ethernet interface IP address.

show interface ethernet 2/0/0

Task	Command
Display the Ethernet interface IP address.	show interface ethernet 2/0/0

Examples

The following example uses the show interface ethernet 2/0/0 command to display the CPU IP address:

Switch#show interface ethernet 2/0/0

Ethernet2/0/0 is up, line protocol is up
  Hardware is SonicT, address is 0040.0b0a.1080 (bia 0040.0b0a.1080)
  Internet address is 172.20.40.93/24
  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, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:07, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     58426 packets input, 18346098 bytes, 0 no buffer
     Received 58373 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 input packets with dribble condition detected
     9350 packets output, 915319 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
Switch#

The following example uses the show running-config command to display the CPU IP address:

Switch#show running-config

Building configuration...
Current configuration:
!
version 11.2
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.112-1.4.WA3.0.15
!
ip host-routing
ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-username dplatz
ip domain-name cisco.com
ip name-server 198.92.30.32
atm filter-set tod1 index 4 permit time-of-day 0:0 0:0
atm qos default  cbr max-cell-loss-ratio clp1plus0 12
atm qos default  vbr-nrt max-cell-loss-ratio clp1plus0 12
atm address 47.0091.8100.0000.0041.0b0a.1081.0041.0b0a.1081.00
atm address 47.0091.8100.5670.0000.0000.0000.0040.0b0a.1081.00
atm route-optimization percentage-threshold 250
atm router pnni
 node 1 level 56 lowest
  redistribute atm-static
!
<Informaition Deleted>
!
interface ATM1/1/3
 no keepalive
!
interface ATM2/0/0
 no ip address
 no keepalive
 atm maxvp-number 0
 atm pvc 0 any-vci  encap aal5snap
!
interface Ethernet2/0/0
 ip address 172.20.40.93 255.255.255.0
!
no ip classless
ip route 0.0.0.0 0.0.0.0 172.20.40.201
atm route 47.0091.8100.0000... ATM0/0/0 scope 1
atm route 47.0091.8100.0000.00... ATM0/0/0 e164-address 1234567
!
line con 0
line aux 0
line vty 0 4
 login
!
end
Switch#

Configure Network Clocking

This section describes network clocking and network clocking configuration of the LightStream 1010 ATM switch.

Each port has a transmit clock and derives its receive clock from the receive data.

Transmit clocking may be configured for each port in one of the following ways:

free-running-transmit clocking derived from the local oscillator on a PAM or from ASP
network derived-transmit clocking is derived from the highest priority configured source, either from the system clock (the local oscillator on the ASP) or the public network (the default)
loop-timed-transmit clock is derived from the receive clock source

Derived clocking is received, along with data, from a specified interface. For example, in Figure 4-3 the transmit-clocking, configured as priority one, is extracted from the data received at interface 0/0/0 and distributed as the transmit clock to the rest of the switch through the backplane. Interface 4/0/0 is configured to use network-derived transmit clocking, which it receives across the backplane from interface 0/0/0.

The network clocking configuration has priorities 1 through 4 and each of these priorities defaults to "no clock" initially. Priority 5 is pseudo-priority and it defaults to "system clock" and is not a configurable priority. If priorities 1 through 4 are not configured then priority 5 is used as the derived clock.

Figure 4-3: Transmit Clock Distribution

Since the port providing network clock source could fail, the Cisco IOS software provides the ability to configure additional interfaces as clock sources with priorities one to four.

Note The ASP system clock is priority five, by default, but the system clock can be configured as any priority you wish.

If the network clock source interface goes down, the software switches to the next highest-configured priority network clock source. For example, in Figure 4-4 the following happens:

Switch LS1010 number two is configured to receive transmit clocking from an external reference clock source through interface 0/0/0.
Interface 4/0/0 uses network-derived transmit clocking.
The priority one transmit clock interface 0/0/0 fails.
The priority two interface, 0/0/4, immediately starts providing the transmit clocking to the backplane and interface 4/0/0.
When the priority one interface, 0/0/0, has been functioning correctly for at least two minutes, the interfaces using network-derived transmit clocking will again start receiving their clocking from interface 0/0/0.

Figure 4-4: Transmit Clocking Priority Configuration Example

Note If no functioning network clock source port exists at a given time, the system clock on the ASP (priority 5), is used as the default clock source.

Network clocking configuration is described in the following sections:

Configure Network Clock Priorities and Sources

To configure the network clocking priorities and sources, use the following EXEC commands. Use the no form of the network-clock-select command to disable network clocking priorities and sources.

Task Command

At the privileged EXEC prompt, enter configuration mode from the terminal.

configure ¹
[terminal]

Configure the network clock.

network-clock-select priority { atm | cbr } card/subcard/port

¹This command is documented in the LightStream 1010 ATM Switch Command Reference publication.

Task	Command
At the privileged EXEC prompt, enter configuration mode from the terminal.	configure ¹ [terminal]
Configure the network clock.	network-clock-select priority { atm \| cbr } card/subcard/port

Examples

The following example configures interface 0/0/0 (see Figure 4-3) as the highest-priority clock source to receive the network clocking:

Switch(config)#network-clock-select 1 atm 0/0/0

Switch(config)#network-clock-select 2 atm 0/0/4

Switch(config)#network-clock-select 3 atm 1/0/0

Switch(config)#

Configure Transmit Clocking Source

To configure where an interface receives its transmit clocking, use the following EXEC commands. Use the no form of this command to disable

Task Command

At the privileged EXEC prompt, enter configuration mode from the terminal.

configure ¹
[terminal]

Select the interface to be configured.

interface atm card/subcard/port

Configure the interface network clock source.

clock source {free-running | loop-timed | network-derived}

¹This command is documented in the LightStream 1010 ATM Switch Command Reference publication.

network clocking on an interface.

Task	Command
At the privileged EXEC prompt, enter configuration mode from the terminal.	configure ¹ [terminal]
Select the interface to be configured.	interface atm card/subcard/port
Configure the interface network clock source.	clock source {free-running \| loop-timed \| network-derived}

Examples

The following example configures ATM interface 4/0/0 to receive its transmit clocking from a network derived source:

Switch(config)#interface atm 4/0/0

Switch(config-if)#clock source network-derived

Switch(config-if)#

Display Network Clocking Configuration

To show the switch network clocking configuration, use the following commands:

Task Command

Show the network clocking configuration.

show network-clocks

Show the interface clock source configuration.

show running-config

Task	Command
Show the network clocking configuration.	show network-clocks
Show the interface clock source configuration.	show running-config

Examples

The following example displays the switch clock source configuration of Figure 4-3:

Switch#show network

Priority 1 clock source: ATM0/0/0
Priority 2 clock source: ATM0/0/4
Priority 3 clock source: ATM1/0/0
Priority 4 clock source: No clock
Priority 5 clock source: System clock
Current clock source: AT0/0/0, priority: 1
Switch#

The following example displays the clock source configuration of ATM interface 4/0/0:

Switch#show running-config

Building configuration...
Current configuration:
!
version 11.2
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/ls1010-wp-mz.112-1.4.WA3.0.15
!
network-clock-select 2 ATM3/1/0
<Information Deleted>
!
interface ATM4/0/0
 no keepalive
 atm manual-well-known-vc
 atm access-group tod1 in
 atm pvc 0 35 rx-cttr 3 tx-cttr 3  interface  ATM2/0/0 0 any-vci  encap qsaal
 atm route-optimization soft-vc interval 360 time-of-day 18:0 5:0
 clock-source network-derived
!
<Information Deleted>
Switch#

Network Clock Synchronization Services for CES Operations

Circuit emulation services-interworking functions (CES-IWF) and constant bit rate (CBR) traffic relate to a quality of service (QOS) classification defined by the ATM Forum for Class A (AAL1) traffic in ATM networks. In general, Class A traffic pertains to voice and video transmissions.

In a LightStream 1010 environment, CBR refers to a particular class of traffic that is generated by edge (source) devices and propagated into ATM networks for transmission to other edge (destination) devices in the network. Each CBR edge device communicating in this manner must be driven by a clocking signal of identical frequency, since this signal controls the rate of CBR data insertion into the network, as well as the rate of extraction of CBR data from the network

If the clock frequency is not the same at both the ingress and egress nodes of the circuit, the data queues and buffers in the network will either overflow or underflow, resulting in periodic line errors.

The CES modules have been designed specifically to handle CBR traffic in an ATM networking environment. To provide requisite timing functions in support of CES operations, you can specify any one of three clocking modes:

Synchronous clocking mode (required for T1/E1 structured CES operations)
Synchronous Residual Time Stamp (SRTS) clocking mode
Adaptive clocking mode

However, to support synchronous clocking or SRTS clocking in your LS1010 operating environment, your network must incorporate the following facilities:

A primary reference source (PRS)-Throughout this document, the term PRS is used to refer to a precision reference timing signal that must be made available, wherever required, to synchronize the flow of CBR data from its source to its destination.
Network clock synchronization services-This refers to a network clock synchronization and distribution service that provides a PRS to those user and network devices that require a precision reference timing signal for synchronizing the flow of CBR traffic.

This clock distribution service enables you to distribute a PRS through any the following network entities:

A CES module in a LightStream 1010 chassis.
An OC3 or OC12 PAM in a LightStream 1010 chassis.
A quad DS-3 module in a LightStream 1010 chassis.
Any T1/E1, OC3, or OC12 trunk line, or other means of interconnecting an ATM network. Note that a trunk port can propagate a clocking signal in either direction.

Plan for Network Clocking

Planning, designing, and implementing an ATM network requires many considerations. Such considerations might include, but are not limited to, the specific hardware used in the network, the purposes served by the network, the protocols implemented within the network, and the physical topology of the network.

Among these important considerations is how a clocking signal should be distributed within the network. In all cases, distributing a clocking signal within the network ensures that each constant bit rate device has access to a common reference clocking signal for synchronizing CBR data transport.

For this reason, planning for distributing a timing signal must be done on a per-chassis basis. Planning must also include a means for distributing up to three alternative clocking signals, in the event of failure of the primary clock signal. You can think of network clocking in general as a kind of protocol to be implemented in the network.

In summary, network administrators must plan for the following:

A primary reference source (PRS)-that is, a common clocking signal to be used by CBR devices.
Up to three alternative clocking sources in the event of failure of the primary reference source.
A means for distributing a clocking signal wherever required in the networking environment.

Once these network clocking facilities are established and operational, they tend to remain static until the primary clock is lost for any reason. In this case, network clocking is dynamic in the sense that an alternate clocking signal must be placed into effect immediately, so the network can remain operational.

A Word to the Wise

As noted in the preceding section, network clock signal distribution in an ATM network is an important consideration. The task of determining a network clocking source and designing a distribution topology for the clocking signal is a task best left to network designers, planners, and engineers.

Sources of Network Clocking Signals

In many cases, using a clocking signal from a telephone company is the simplest and best solution for a stable and reliable clocking signal, especially in those instances where you are already using a CES circuit to interconnect telephone equipment.

For example, to meet its own need for internal consistency, a telephone company typically distributes a timing signal to govern its own networking operations. Therefore, the telephone company has already addressed timing requirements similar to those that a LightStream 1010 user must address in relation to their own CES operations. Consequently, a PBX can serve as a ready means for providing a timing signal to any user CBR device.

A LightStream 1010 network administrator can define up to four clocking signal sources per chassis, assigning a priority to each one. Under normal operating conditions, the priority 1 signal serves as the primary clocking signal. The remaining signal sources are listed in priority order for backup purposes in the event of failure of the primary (priority 1) clock.

The clock sources configured for a CES module are revertive. For example, assume that a clock of lower priority is currently in effect due to failure of a higher priority clock source. When the higher priority clock is again restored to service for at least one minute, the system automatically reverts to this signal for network clock synchronization.

To make use of network timing services in a LightStream 1010 chassis, the user must define the port from which a network timing signal is to be taken, and list the alternative clock sources for the port in the same order of priority as specified for the network at large.

You can accomplish these clock configuration tasks by issuing the CLI network-clock-select command, as described in the section entitled "Configure Network Clock Priorities and Sources."

A PRS from one of the following sources is often the timing signal of choice, because such signals from major carriers are known to be highly stable, reliable, and accurate:

AT&T
Ameritech
MCI
Bell South

Clocking Modes for CES Operations

For CES operations, as noted earlier, three clocking modes can be used in conjunction with any CES module. The following clocking modes are described in their recommended order of consideration and use:

Synchronous clocking mode-This mode requires a PRS and network clock synchronization services. Note that synchronous clocking can be used for both unstructured (clear channel) and structured (N x 64 Kbps) CES services.

: First, this clocking mode is the only one that supports full CES functionality. SRTS and adaptive clocking do not support structured CES services. Synchronous clocking is the default clocking mode for all CES services.
: Second, synchronous clocking exhibits superior stability, reliability, and wander/jitter characteristics.
: Third, synchronous clocking is typically used in public telephony systems, making a precision reference signal readily and widely available for synchronizing CBR data transport.
: This clocking mode is described in greater detail in a later section entitled "Synchronous Clocking."

Synchronous Residual Time Stamp (SRTS) clocking mode-SRTS clocking also requires a PRS and network clock synchronization services. However, SRTS clocking can be used only for unstructured (clear channel) CES services.

: This mode allows user equipment at the edges of an ATM network to use a clocking signal that is different (and completely independent) from the clocking signal being used in the ATM network proper.
: For example, user equipment at the edges of the network can be driven by clock A, while the devices within the ATM network are being driven by clock B. The SRTS clocking mode enables these different timing signals to be reconciled in the course of CBR data transport through the ATM network.
: This clocking mode is described in greater detail in a later section entitled "Synchronous Residual Time Stamp (SRTS) Clocking."

Adaptive clocking mode-This mode requires neither a PRS nor network clock synchronization services to accomplish effective CBR data transport. However, as is the case with SRTS clocking, adaptive clocking can be used only for unstructured (clear channel) CES services.

: Although this clocking mode is the simplest and easiest to implement in an ATM network, it exhibits the poorest wander and jitter performance of all the available clocking modes. Therefore, its use is not recommended, except in instances where a PRS and network clock synchronization services are not available.
: The fact that the rate at which CBR data is propagated through an ATM network is driven essentially by the rate at which CBR data is introduced into the network by the user's edge equipment. For example, adaptive clocking in a CES module infers appropriate timing for data transport by calculating an "average" data rate upon arrival and conveying that data to the output port of the module at an equivalent rate.
: The actual rate of CBR data flow through the network may vary from time to time during adaptive clocking, depending on how rapidly (or how slowly) CBR data is being introduced into the network. Nevertheless, CBR data transport through the network occurs in a "pseudo synchronous" manner that ensures the integrity of the data.
: This clocking mode is described in greater detail in a later section entitled "Adaptive Clocking."

Network Timing Modules in a LightStream 1010 Chassis

Any module in a LightStream 1010 chassis capable of receiving and distributing a network timing signal can propagate that signal to any similarly capable module in the chassis.

By issuing the CLI network-clock-select command with appropriate parameters, you can define a particular port in a LightStream 1010 chassis to serve as the source of a PRS for the entire chassis or for other devices in the networking environment. This CLI command is described in the section entitled "Configure Network Clock Priorities and Sources."

In effect, through the network-clock-select command, you can designate a particular port in a LightStream 1010 chassis to serve as a "master clock" source for distributing a single clocking signal throughout the chassis or to other network devices. Hence, this reference signal can be distributed wherever needed in the network to globally synchronize the flow of CBR data.

The following LightStream 1010 modules are capable of receiving and distributing a primary reference signal (PRS):

CES modules
OC3 modules
OC12 modules
Quad DS-3
E1/T1 trunk modules

Description of Clocking Modes

The following sections describe the clocking modes in greater detail, presenting them in the preferred order of use in your LS1010 environment.

Synchronous Clocking

When equipped with a CES module and appropriate software, any LightStream 1010 switch can serve as a means for:

Receiving and distributing a PRS to other devices in the network
Synchronizing the flow of user CBR traffic through the network

Figure 4-5 shows that a LightStream 1010 switch can make use of a PRS that originates from any one of several sources in the networking environment.

Figure 4-5 shows four possible sources of a PRS. However, do not interpret Figure 4-5 to mean that only four such clocking signals can be made available for use in the ATM network. In fact, numerous clocking signals may be present in the LightStream 1010 operating environment.

The important concepts that you should take from Figure 4-5 include the following:

Up to four clocking signals can be defined per LightStream 1010 chassis in the network.
Each LightStream 1010 chassis must be assigned the same clocking signal sources.
These clocking signal sources must be specified in the same order of priority for each LightStream 1010 chassis in the network.

Figure 4-5: Synchronous Clocking Sources in ATM Network

Note that each PRS in Figure 4-5 is externally generated-that is, the timing signal originates from a source outside the ATM network proper. Also shown is an OC3 or OC12 trunk line that can propagate a PRS between adjacent ATM networks.

If the priority 1 PRS fails for any reason, the network clock synchronization service automatically recovers network timing by using the priority 2 PRS available from another source.

Assume that the T1/E1 trunk at the top of Figure 4-5 is currently supplying a priority 1 PRS to the network. If the PRS fails for some reason, the OC3/OC12 trunk line (linking the adjacent ATM networks) can provide a secondary (priority 2) PRS for network synchronization purposes.

Either of the other PBXs connected to the network could each, in turn, provide a PRS to the ATM network in the event of failure of a higher priority PRS. With restoration to service of the priority 1 PRS, the network clock synchronization service automatically reverts to this PRS for timing purposes, regardless of which lower priority PRS might be active at the time.

Figure 4-6 shows how a PRS for synchronous clocking can be provided to an edge node of an ATM network and propagated through the network to synchronize the flow of CBR data between the communicating ATM end nodes.

In this particular network scenario, a PRS is available to the network by means of the PBX at the edge of the network. The PRS is present at the port of a CES module in edge node A (the ingress node). From there, the PRS is propagated into the first ATM network through an ATM port and conveyed across an OC3 trunk to an adjacent ATM network. This same clocking signal is then used to synchronize the handling of CBR data in edge node B (the egress node).

Figure 4-6: Synchronous Clocking in LS1010 ATM Network

Synchronous Residual Time Stamp (SRTS) Clocking

Synchronous Residual Time Stamp (SRTS) clocking can be used if the user's edge equipment is being driven by a different clocking signal than that being used in the ATM network proper. Figure 4-7 shows such an operating scenario in which a timing signal is being provided to edge nodes independently from the ATM network.

Figure 4-7: SRTS Clocking in LS1010 ATM Network

Using Figure 4-7 as a frame of reference, assume that the user of edge node 1 wants to send CBR data to a user at edge node 3. In this scenario, SRTS clocking works as follows:

1 Clock A is driving the devices within the ATM network.

2 At edge node 1, the user introduces CBR traffic into the ATM network according to clock B.

3 As edge node 1 segments the CBR bit stream into ATM cells, it measures the difference between user clock B, which drives it and network clock A.

4 As edge node 1 generates the ATM cell stream, it incorporates this delta value into every eighth cell.

5 The cells are then propagated through the network in the usual manner.

6 As destination edge node 3 receives the cells, this node not only reassembles the ATM cells into the original CBR bit stream, but also reconciles, or reconstructs, the user clock B timing signal from the delta value carried within every eighth ATM cell.

Thus, during SRTS clocking, CBR traffic is synchronized between the ingress (segmentation) side of the CES circuit and the egress (reassembly) side of the circuit according to user clock signal B, while the ATM network continues to function according to clock A.

Adaptive Clocking

Adaptive clocking requires neither the network clock synchronization service nor a global PRS for effective handling of CBR traffic. Rather than using a clocking signal to convey CBR traffic through an ATM network, adaptive clocking infers appropriate timing for data transport by calculating an average data rate for the CBR traffic.

For example, if CBR data is arriving at a CES module at a rate of so many bits per second, then that rate is used, in effect, to govern the flow of CBR data through the network. What happens behind the scenes, however, is that the CES module automatically calculates the average data rate by means of microcode (firmware) built into the board. This calculation occurs dynamically as user data traverses the network.

When the CES module senses that its segmentation and reassembly (SAR) buffer is filling up, it increases the rate of the transmit (TX) clock for its output port, thereby draining the buffer at a rate that is consistent with the rate of the data's arrival.

Similarly, the CES module slows down the transmit clock of its output port if it senses that the buffer is being drained faster than CBR data is being received. Adaptive clocking attempts to minimize wide excursions in SAR buffer loading while, at the same time, providing an effective means of propagating CBR traffic through the network.

Relative to the other clocking modes, implementing adaptive clocking is simple and straightforward. It does not require network clock synchronization services, a PRS, or the advance planning typically associated with developing a logical network timing map. However, adaptive clocking does not support structured CES services, and it exhibits relatively high wander characteristics.

Summary of Clocking Modes

Table 4-2 summarizes the characteristics of the three clocking modes available for handling CBR traffic in a LightStream 1010 networking environment. Although the wander and jitter characteristics of these clocking modes differ, all clocking modes function in a way that preserves the integrity of the user's CBR data, ensuring error-free data transport from source to destination.

Clocking Mode	Advantages	Limitations
Synchronous	Supports both unstructured (clear channel) and structured CBR traffic. Exhibits superior wander and jitter characteristics.	Requires network clock synchronization services. Ties the CES interface to the network clock synchronization services clocking signal (PRS).
SRTS (Synchronous Residual Time Stamp)	Conveys externally-generated user clocking signal through ATM network, providing independent clocking signal for each CES circuit.	Requires network clock synchronization services. Supports only unstructured (clear channel) CBR traffic. Exhibits moderate wander characteristics.
Adaptive	Does not require network clock synchronization services.	Supports only unstructured (clear channel) CBR traffic. Exhibits poorest wander characteristics.

Table 4-2: Characteristics of CES Clocking Modes

Clocking Mode Advantages Limitations

Synchronous

Supports both unstructured (clear channel) and structured CBR traffic.

Exhibits superior wander and jitter characteristics.

Requires network clock synchronization services.

Ties the CES interface to the network clock synchronization services clocking signal (PRS).

SRTS (Synchronous Residual Time Stamp)

Conveys externally-generated user clocking signal through ATM network, providing independent clocking signal for each CES circuit.

Requires network clock synchronization services.

Supports only unstructured (clear channel) CBR traffic.

Exhibits moderate wander characteristics.

Adaptive

Does not require network clock synchronization services.

Supports only unstructured (clear channel) CBR traffic.

Exhibits poorest wander characteristics.

Other Factors Relevant to CES Operations

The following factors enter into proper functioning of CES circuits:

The intended source and destination nodes for CES circuits.
The clocking mode that best suits your particular network topology and timing requirements in handling CBR data.

: Although synchronous clocking is the recommended (default) clocking mode for CES operations, this fact does not preclude other clocking modes from consideration.

The cell delay variation (CDV) characteristics of the network, measured in microseconds.

Each end-to-end CES circuit exhibits delay characteristics, based on the following factors:

The delay characteristics of the individual devices participating in the CES circuit.

: Each network device contributes some increment of delay, reflecting that device's unique electrical characteristics.

The number of intermediate hops through which the CBR data must pass in traversing the network from source to destination.

: The network designer/administrator calculates a CDV value for each hop in the data path in order to establish a maximum allowable CDV value for the network at large.

The type and speed of the trunk lines interconnecting the ATM networks.
The volume of traffic being handled by the trunk lines at any given time; that is, the degree to which the network is experiencing congestion conditions.

A maximum allowable CDV value for the network is calculated by network designers and administrators in order to establish the cell delay tolerance limits for the network. To some degree, the network's maximum allowable CDV value is a measure of the network's expected performance.

By establishing this CDV threshold for the network, appropriate buffer sizing can be derived for the network devices involved in any given CES circuit, ensuring that the network operates as expected.

In a CES module, for example, the maximum allowable CDV value for the network is used to determine an appropriate size (depth) for the SAR buffer built into the board. This sizing of the SAR buffer is done to prevent buffer overflow or underflow conditions. An overflow condition can cause a loss of frames, while an underflow condition can cause frames to be repeated.

The actual CDV value for a circuit varies according to the particular data path used for the circuit. Consequently, the depth of the SAR buffer increases or decreases in proportion to the CDV value for the CES circuit being set up.

You can issue the CLI show ces circuit interface command in an unstructured (clear channel) circuit to measure the current CDV value. See the section "Verify a Configured Hard PVC with Adaptive Clocking" in the chapter "Configuring Port Adapter Modules Interfaces."

For an unstructured hard PVC, the CDV value for the circuit (including all hops) must not exceed a maximum allowable CDV value. The procedure for setting up a hard PVC is described in the section "Configure CES PAMs for Unstructured CES Services."

For an unstructured soft PVC, the network automatically determines the best data path through the network and handles the routing of CBR traffic. The network accomplishes this dynamically through the ATM connection admission control (CAC) mechanism. The CAC mechanism determines the best path through the network by executing a routing algorithm that consults local routing tables in network devices.

If the requested data path is equal to or less than the maximum allowable CDV value established by the network administrator, the connection request is granted. If the requested CES circuit exceeds the maximum allowable CDV value, the connection request is denied. These connection admission control processes occur "on the fly" as network connection requests are initiated.

For example, when a user requests a connection from source node A at one edge of the network to destination node B at the opposite edge of the network, the CAC mechanism takes into account the CDV value for each hop in the requested connection to determine a suitable path through the network that does not exceed the network's maximum allowable CDV value.

The procedure for setting up a soft PVC is described in the section "Configure a Soft PVC with Synchronous Clocking" in the chapter "Configuring Port Adapter Modules Interfaces."

Configure the Network Routing

The default software image for the LightStream 1010 contains the PNNI routing protocol. The PNNI protocol provides the route dissemination mechanism for complete plug-and-play capability.

The section "Configure ATM Static Routes for IISP or PNNI" describe modifications that can be made to the default PNNI or IISP routing configurations.

For a detailed description of these routing protocols see the section "ATM Routing" in the chapter "LightStream 1010 Product Overview," and see the chapters "Configuring ILMI" and "Configuring ATM Routing and PNNI" for detailed configuration information.

Configure ATM Static Routes for IISP or PNNI

Use the atm route command to configure a static route. Static route configuration allows ATM call setup requests to be forwarded on a specific interface if the addresses match a configured address prefix.

Note An interface must be UNI or IISP to be configured with static route. Static routes configured as PNNI interfaces default as down.

Figure 4-8 is an example of the atm route command configuring the 13-byte-peer-group-prefix = 47.0091.8100.567.0000.0ca7.ce01 at interface 3/0/0:

Figure 4-8: atm route Command Example

Switch(config)#atm route 47.0091.8100.567.0000.0ca7.ce01 atm 3/0/0

Switch(config)#

Configure the System Information

Although not required, several system parameters should be set as part of the initial system configuration. To set the system parameters, perform the following tasks in EXEC mode:

Task Command

Set the system clock.

clock set day_of_week mm/dd/yy hh:mm:ss

At the privileged EXEC prompt, enter configuration mode from the terminal.

configure¹
[terminal]

Set the system name.

hostname name_string

¹This command is documented in the LightStream 1010 ATM Switch Command Reference publication.

Task	Command
Set the system clock.	clock set day_of_week mm/dd/yy hh:mm:ss
At the privileged EXEC prompt, enter configuration mode from the terminal.	configure¹ [terminal]
Set the system name.	hostname name_string

Syntax Description

hh:mm:ss-Current time in hours (military format), minutes, and seconds

day -Current day (by date) in the month

month-Current month (by name)

year-Current year (no abbreviation)

name_string -New case sensitive host name for the network server

Configure SNMP Management

The Simple Network Management Protocol (SNMP) system consists of three parts: an SNMP manager, an SNMP agent, and a management information bases (MIBs). SNMP is an application-layer protocol that allows SNMP manager and agent to communicate. SNMP provides a message format for sending information between an SNMP manager and an SNMP agent. The SNMP manager can be part of a Network Management System (NMS), such as CiscoWorks.

Note For definitions of all commands discussed in this chapter, refer to the publication LightStream 1010 ATM Switch Command Reference.

The agent and MIB reside on the switch. To configure SNMP on the switch, you define the relationship between the manager and the agent.

The SNMP agent contains MIB variables whose values the SNMP manager can request or change. A manager can get a value from an agent or store a value into an agent. The agent gathers data from the MIB, the repository for information about device parameters and network data. The agent can also respond to a manager's requests to get or set data.

An agent can send unsolicited traps to the manager. Traps are messages alerting the SNMP manager to a condition on the network. Traps can indicate improper user authentication, restarts, link status (up or down), closing of a TCP connection, or loss of connection to a neighbor router or switch.

Figure 4-9 illustrates the communications relationship between the SNMP manager and agent. It shows that a manager can send the agent requests to get and set MIB values. The agent can respond to these requests. Independent of this interaction, the agent can send unsolicited traps to the manager notifying the manager of network conditions.

Figure 4-9: Communication between an SNMP Agent and Manager

Cisco supports the SNMP Version 1 protocol, referred to as SNMPv1, and the SNMP Version 2 protocol, referred to as SNMPv2. Cisco's implementation of SNMP supports all MIB II variables (as described in RFC 1213) and SNMP traps (as described in RFC 1215). See the Cisco Management Information Base (MIB) User Quick Reference for a list and detailed description of each Cisco MIB variable and SNMP trap.

RFC 1447, "SNMPv2 Party MIB" (April 1993), describes the managed objects that correspond to the properties associated with SNMPv2 parties, SNMPv2 contexts, and access control policies, as defined by the SNMPv2 Administrative Model. RFC 1450, "SNMPv2 MIB," (April 1993) describes the managed objects that instrument the behavior of an SNMPv2 implementation. Cisco supports the MIB variables as required by the conformance clauses specified in these MIBs.

Cisco also provides its own MIB with every system. One of the set of MIB objects provided is the Cisco Chassis MIB that enables the SNMP manager to gather data on system card descriptions, serial numbers, hardware and software revision levels, and slot locations.

Although SNMPv2 offers more robust support than SNMPv1, Cisco continues to support SNMPv1. Not all management stations have migrated to SNMPv2 and you must configure the relationship between the agent and the manager to use the version of SNMP supported by the management station.

SNMPv1 offers a community-based form of security defined through an IP address access control list and password. SNMPv2 offers richer security configured through an access policy that defines the relationship between a single manager and agent. SNMPv2 security includes message authentication support using the Message Digest (MD5) algorithm, but because of the Data Encryption Standard (DES) export restrictions, it does not include encryption support through DES. SNMPv2 security provides data origin authentication, ensures data integrity, and protects against message stream modification.

In addition to enhanced security, SNMPv2 support includes a bulk retrieval mechanism and more detailed error message reporting to management stations. The bulk retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trips required.

The SNMPv2 improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.

There is no specific command that you use to enable SNMP. The first snmp-server command that you enter enables both versions of SNMP.

To configure SNMP support, perform the tasks in the appropriate sections:

To configure relationship between the agent and the manager on the switch, you need to know the version of the SNMP protocol that the management station supports. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol and another using the SNMPv2 protocol. To configure SNMP support, perform the tasks in one of the following sections.

Configure for both SNMPv1 and SNMPv2

You can perform tasks in the following sections to configure support for both SNMPv1 and SNMPv2:

Enable the SNMP Agent Shutdown Mechanism

Using SNMP packets, a network management tool can send messages to users on virtual terminals and the console. This facility operates in a similar fashion to the EXEC send command; however, the SNMP request that causes the message to be issued to the users also specifies the action to be taken after the message is delivered. One possible action is a shutdown request. After a system is shut down, typically it is reloaded. Because the ability to cause a reload from the network is a powerful feature, it is protected by the snmp-server system-shutdown global configuration command. If you do not issue this command, the shutdown mechanism is not enabled. To enable the SNMP agent shutdown mechanism, perform the following task:

Task Command

Use the SNMP message reload feature and request a system shutdown message.

snmp-server system-shutdown

Task	Command
Use the SNMP message reload feature and request a system shutdown message.	snmp-server system-shutdown

To understand how to use this feature with SNMP requests, read the document mib.txt available by anonymous FTP from ftp.cisco.com.

Establish the Contact, Location, and Serial Number of the SNMP Agent

You can set the system contact, location, and serial number of the SNMP agent so that these descriptions can be accessed through the configuration file. To do so, perform one or more of the following tasks in global configuration mode:

Task Command

Set the system contact string.

snmp-server contact text

Set the system location string.

snmp-server location text

Set the system serial number.

snmp-server chassis-id text

Task	Command
Set the system contact string.	snmp-server contact text
Set the system location string.	snmp-server location text
Set the system serial number.	snmp-server chassis-id text

Define the Maximum SNMP Agent Packet Size

You can set the maximum packet size permitted when the SNMP agent is receiving a request or generating a reply. To do so, perform the following task in global configuration mode:

Task Command

Establish the maximum packet size.

snmp-server packetsize byte-count

Task	Command
Establish the maximum packet size.	snmp-server packetsize byte-count

Monitor SNMP Status

To monitor SNMP input and output statistics, including the number of illegal community string entries, errors, and requested variables, complete the following task in EXEC mode:

Task Command

Monitor SNMP status.

show snmp

Task	Command
Monitor SNMP status.	show snmp

Disable the SNMP Agent

To disable both versions of SNMP (SNMPv1 and SNMPv2) concurrently, perform the following task in global configuration mode:

Task Command

Disable SNMP agent operation.

no snmp-server

Task	Command
Disable SNMP agent operation.	no snmp-server

Configure SNMPv2 Support

SNMPv2 security requires that you create an access policy that defines the relationship between a manager and the agent. For each management station that the agent communicates with, you must create a separate access policy. Creating an access policy is a multiple-task process:

Step 1 Define a view to identify the objects that can be seen, if you do not want to use one of the standard predefined views.

Step 2 Define a context to identify the object resources that can be acted on.

Step 3 Define a party for both the manager and the agent to identify them.

Step 4 Using the definitions created in the previous tasks, configure the access policy that characterizes the communications that can occur between the manager and the agent. The privileges that you define for the access policy depend on whether the agent is defined as the source or the destination. For example:

When the agent party is defined as the destination in an access policy, the access policy privileges define the management operations that the agent will accept from the manager and perform in relation to the object resources.
When the agent party is defined as the source in an access policy, the access policy privileges define the responses and traps that the agent can send to the manager.

Figure 4-10 shows the information exchanged between the manager and the agent. The top arrow, leading from the manager to the agent, shows the types of requests the manager can send to the agent. The bottom arrow, leading from the agent to the manager, shows the kind of information that the agent can send to the manager. Note that the agent sends trap messages to the manager in response to certain network conditions; trap messages are unsolicited and are not related to the request/response communication exchange between the manager and the agent that occurs in relation to MIB variables. For any given manager and agent relationship, the privileges defined in the access policy constrain communications to a specific set of operations.

Figure 4-10: Flow of Management Operations Requests, Responses, and Traps

You must create access policies for each new agent that is installed. You also must create access policies on an agent when new management stations are installed. Moreover, every time a network address changes on a management station, you must reconfigure the access policy to reflect the new information for the management station.

This section describes each task that you must perform to configure an access policy. Then it addresses the alternative method and describes the task of configuring the user ID for the simplified security conventions method.

To configure support for SNMv2, perform the following tasks:

After you create a record, you can modify the record contents by changing one or more of the record values. To do this, issue the command again, naming the record that you created originally. You must fully specify the record values, including the argument values, to remain unchanged.

Create or Modify an SNMP View Record

To create or modify an SNMP view record, perform the following task in global configuration mode

Task Command

Create or modify a view record.

snmp-server view view-name oid-tree {included | excluded}

:

Task	Command
Create or modify a view record.	snmp-server view view-name oid-tree {included \| excluded}

To remove a view record, use the no snmp-server view command.

Create or Modify an SNMP Context Record

To create or modify an SNMP context record, perform the following task in global configuration mode:

Task Command

Create or modify a context record.

snmp-server context context-name context-oid view-name

Task	Command
Create or modify a context record.	snmp-server context context-name context-oid view-name

To remove a context entry, use the no snmp-server context command. Specify only the name of the context. The name identifies the context to be deleted.

Create or Modify an SNMPv2 Party Record

To create or modify an SNMPv2 party record, perform the following task in global configuration mode

Task Command

Create or modify a party record.

snmp-server party party-name party-oid [protocol-address] [packetsize size] [local | remote] [authentication md5 key [clock clock] [lifetime lifetime]

:

Task	Command
Create or modify a party record.	snmp-server party party-name party-oid [protocol-address] [packetsize size] [local \| remote] [authentication md5 key [clock clock] [lifetime lifetime]

To remove a party record, use the no snmp-server party command.

Create an SNMPv2 Access Policy

To create or modify an SNMPv2 access policy, perform the following task in global configuration mode:

Task Command

Create or modify an access policy.

snmp-server access-policy destination-party source-party context privileges

Task	Command
Create or modify an access policy.	snmp-server access-policy destination-party source-party context privileges

To remove an SNMPv2 access-policy, use the no snmp-server access-policy command. Specify all three arguments to correctly identify the access policy to be deleted. A difference of one value constitutes a unique access policy entry.

Define SNMPv 2 Trap Operations

A trap is an unsolicited message sent by an SNMP agent to an SNMP manager indicating that some event has occurred. The SNMP trap operations allow you to configure the Cisco IOS software to send information to a network management application when a particular event occurs. You can specify the following features for SNMPv2 agent trap operations:

Source interface
Recipient of the trap message
Trap message authentication
Trap types
Retransmission interval
Message (packet) queue length for each trap host

To define the recipient of the trap message, you configure a party record for the manager, including the protocol address, and specify the party record as the destination party for the snmp-server access policy command. To define traps for the agent to send to the manager, perform one or more of the following tasks in global configuration mode:

Task Command

Specify the source interface (and hence IP address) of the trap message.

snmp-server trap-source interface

Specify the access policy that defines the traps that the agent can send to the manager.

snmp-server access-policy destination-party source-party context privileges

Specify the recipient of the trap message.

snmp-server host address community-string [trap-type]

Establish trap message authentication.

snmp-server trap-authentication [snmpv1 | snmpv2]

Specify the types of traps sent.

snmp-server enable traps [trap-type] [trap-option]

Define how often to resend trap messages on the retransmission queue.

snmp-server trap-timeout seconds

Establish the message queue length for each trap host.

snmp-server queue-length length

Task	Command
Specify the source interface (and hence IP address) of the trap message.	snmp-server trap-source interface
Specify the access policy that defines the traps that the agent can send to the manager.	snmp-server access-policy destination-party source-party context privileges
Specify the recipient of the trap message.	snmp-server host address community-string [trap-type]
Establish trap message authentication.	snmp-server trap-authentication [snmpv1 \| snmpv2]
Specify the types of traps sent.	snmp-server enable traps [trap-type] [trap-option]
Define how often to resend trap messages on the retransmission queue.	snmp-server trap-timeout seconds
Establish the message queue length for each trap host.	snmp-server queue-length length

Because SNMP traps are inherently unreliable and much too important to lose, at least one syslog message, the most recent, is stored in a history table on the switch. You can also specify the level of syslog traps (Cisco Syslog MIB) that get stored in the history table and sent to the SNMP network management station.

Configure SNMPv1 Support

If the manager supports only the SNMPv1 protocol, you must configure the relationship between the manager and the agent using SNMPv1 support.

Using the snmp-server community command, you specify a string, and, optionally, a MIB view and an access list. The string is used as a password. The MIB view defines the subset of all MIB objects that the given community can access. The access list identifies the IP addresses of systems on which SNMPv1 managers reside that might use the community string to gain access to the SNMPv1 agent.

To configure support for SNMPv1, you perform tasks in the following sections:

Create or Modify Access Control for an SNMPv1 Community

You can configure a community string, which acts like a password, to permit access to the agent on the switch. Optionally, you can associate a list of IP addresses with that community string to permit only managers with these IP addresses to use the string.

To configure a community string, perform the following task in global configuration mode:

Task Command

Define the community access string.

snmp-server community string [view view-name] [ro | rw] [access-list number]

Task	Command
Define the community access string.	snmp-server community string [view view-name] [ro \| rw] [access-list number]

You can configure one or more community strings. To remove a specific community string, use the no snmp-server community command.

For an example of a community string, see the section "Use show running-config to Confirm Configuration" at the end of this chapter.

Define SNMP Trap Operations for SNMPv1

The SNMP trap operations allow a system administrator to configure the agent switch to send information to a manager when a particular event occurs. You can specify the following features for SNMP server trap operations:

Source interface
Recipient
Trap message authentication
Trap types
Retransmission interval
Define the message (packet) queue length for each trap host

Perform the following tasks in global configuration mode to define traps for the agent to send to the specified manager:

Task Command

Specify the source interface (and hence IP address) of the trap message.

snmp-server trap-source interface

Specify the recipient of the trap message.

snmp-server host address community-string [trap-type]

Establish trap message authentication.

snmp-server trap-authentication [snmpv1 | snmp2]

Specify the types of traps sent.

snmp-server enable traps [trap-type] [trap-option]

Define how often to resend trap messages on the retransmission queue.

snmp-server trap-timeout seconds

Establish the message queue length for each trap host.

snmp-server queue-length length

Task	Command
Specify the source interface (and hence IP address) of the trap message.	snmp-server trap-source interface
Specify the recipient of the trap message.	snmp-server host address community-string [trap-type]
Establish trap message authentication.	snmp-server trap-authentication [snmpv1 \| snmp2]
Specify the types of traps sent.	snmp-server enable traps [trap-type] [trap-option]
Define how often to resend trap messages on the retransmission queue.	snmp-server trap-timeout seconds
Establish the message queue length for each trap host.	snmp-server queue-length length

Configure RMON Support

The Remote Monitoring (RMON) option provides visibility of individual nodal activity and allows you to monitor all nodes and their interaction on a LAN segment. RMON, used in conjunction with the SNMP agent in the switch, allows you to view both traffic that flows through the switch and segment traffic not necessarily destined for the switch. Combining RMON alarms and events with existing MIBs allows you to choose where proactive monitoring will occur.

RMON can be very data and processor intensive. Users should measure usage effects to ensure that switch performance is not degraded and to minimize excessive management traffic overhead. Native mode is less intensive than promiscuous mode.

All Cisco IOS software images ordered without the explicit RMON option include limited RMON support (RMON alarms and event groups only). Images ordered with the RMON option include support for all nine groups (statistics, history, alarms, hosts, hostTopN, matrix, filter, capture, and event). As a security precaution, support for the packet capture group allows capture of packet header information only; data payloads are not captured.

Note This section describes general SNMP RMON configuration. See the chapter "Configuring ATM Accounting and ATM RMON" for ATM RMON configuration.

To set an RMON alarm or event, perform one of the following tasks in global configuration mode:

Task Command

Set an alarm on a MIB object.

rmon alarm number variable interval {delta | absolute} rising-threshold value [event-number] falling-threshold value [event-number] [owner string]

Add or remove an event in the RMON event table.

rmon event number [log] [trap community] [description string] [owner string]

Task	Command
Set an alarm on a MIB object.	rmon alarm number variable interval {delta \| absolute} rising-threshold value [event-number] falling-threshold value [event-number] [owner string]
Add or remove an event in the RMON event table.	rmon event number [log] [trap community] [description string] [owner string]

You can set an alarm on any MIB object in the access server. To disable an alarm, you must enable the no form of this command on each alarm you configure. You cannot disable all the alarms you configure at once. Refer to RFC 1757 to learn more about alarms and events and how they interact with each other.

To display the current RMON status, perform the following task in EXEC mode:

Task Command

Display general RMON statistics.

show rmon

or

show rmon task

Display the RMON alarm table.

show rmon alarms

Display the RMON event table.

show rmon events

Examples

The following example enables the rmon event command:

Switch#rmon event 1 log trap eventtrap description "High ifOutErrors" owner sdurham

This example configures the following RMON event:

RMON event number 1
defined as High ifOutErrors
generates a log entry when the event is triggered by an alarm
user sdurham owns the row that is created in the event table by this command
generates a Simple Network Management Protocol (SNMP) trap when the event is triggered

The following example configures an RMON alarm using the rmon alarm command:

Switch#rmon alarm 10 ifEntry.20.1 20 delta rising-threshold 15 1 falling-threshold 0 
owner jjohnson

This example configures the following RMON alarm:

RMON alarm number 10
The alarm monitors the MIB variable ifEntry.20.1 once every 20 seconds until the alarm is disabled, and checks the change in the variable's rise or fall.
If the ifEntry.20.1 value shows a MIB counter increase of 15 or more, such as from 100000 to 100015, the alarm is triggered.
The alarm in turn triggers event number 1, which is configured with the rmon event command.

Possible events include a log entry or an SNMP trap. If the ifEntry.20.1 value changes by 0, the alarm is reset and can be triggered again.

Store the Configuration

When autoconfiguration and any manual configurations are complete you should copy the configuration into nonvolatile random-access memory (NVRAM). If you should power off your LightStream 1010 prior to saving the configuration in NVRAM, all manual configuration changes are lost. Figure 4-11 is an example of the copy running-config command.

Figure 4-11: Storing Configuration in NVRAM Example

Switch#copy running-config startup-config

Building configuration...
[OK]
Switch#

Test the Configuration

When you have finished configuring the LightStream 1010 ATM switch, you can use the following commands to confirm the hardware, software, and interface configuration:

Use show hardware to Confirm Hardware Configuration

Use the show hardware command to confirm the correct hardware installation. Figure 4-12 provides an example of this command:

Figure 4-12: show hardware Command Example

Switch#show hardware

LS1010 named Switch, Date: 12:50:30 UTC Wed Apr 24 1996
Slot Ctrlr-Type    Part No.  Rev  Ser No  Mfg Date  RMA No. Hw Vrs  Tst EEP
---- ------------  ---------- -- -------- -------- -------- ------- --- ---
0/0  155UTP PAM    73-1572-02 01 02749041  1/17/96 00-00-00   3.0     0   2
0/1  155MM PAM     73-1496-03 06 02180424  1/16/96 00-00-00   3.0     0   2
1/0  155MM PAM     73-1496-03 06 02180444  1/17/96 00-00-00   3.0     0   2
1/1  155MM PAM     73-1496-03 06 02202228  1/11/96 00-00-00   3.0     0   2
2/0  ATM Swi/Proc  73-1402-02 00 02827677  0/07/13 00-00-00   2.3     0   2
Switch#

Use show version to Confirm Software

Use the show version command to confirm the correct version and type of LightStream 1010 software and the configuration register are installed. Figure 4-13 is an example of the show version command:

Figure 4-13: show version Command Example

Switch#show version

Cisco Internetwork Operating System Software
IOS (tm) PNNI Software (LS1010-WP-M), Version 11.2(1.4.WA3.0.41)
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Tue 11-Feb-97 02:59 by
Image text-base: 0x600108D0, data-base: 0x603EE000
ROM: System Bootstrap, Version 201(1025), SOFTWARE
Switch uptime is 1 week, 4 days, 22 hours, 19 minutes
System restarted by reload
System image file is "slot0:ls1010-wp-mz.112-1.4.WA3.0.41", booted via console
cisco ASP (R4600) processor with 16384K bytes of memory.
R4600 processor, Implementation 32, Revision 2.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
25 ATM network interface(s)
125K bytes of non-volatile configuration memory.
8192K bytes of Flash PCMCIA card at slot 0 (Sector size 128K).
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x0
Switch#

Use show interface ethernet to Confirm Ethernet Configuration

Use the show interface ethernet command to confirm the ethernet interface on the ASP is configured correctly. Figure 4-14 displays this command:

Figure 4-14: show interface ethernet 2/0/0 Command Example

Switch#show interface ethernet 2/0/0

Ethernet2/0/0 is up, line protocol is up
  Hardware is SonicT, address is 0000.0ca7.ce00 (bia 0000.0ca7.ce00)
  Internet address is 172.20.40.43 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, ARP Timeout 4:00:00
  Last input 0:00:26, output 0:00:16, output hang never
  Last clearing of "show interface" counters never
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     6021 packets input, 2145763 bytes, 0 no buffer
     Received 6019 broadcasts, 0 runts, 0 giants
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 input packets with dribble condition detected
     113 packets output, 31148 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets, 0 restarts
     0 output buffer failures, 0 output buffers swapped out
Switch#

Use show atm addresses to Confirm ATM Address

Use the show atm addresses command to confirm correct configuration of the ATM address for the LightStream 1010. Figure 4-15 provides an example of this command:

Figure 4-15: show atm addresses Command Example

Switch#show atm addresses

Switch Address(es):
  47.00918100000000400B0A2B81.00400B0A2B81.00 active
Soft VC Address(es):
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.0030.00 ATM-P0/0/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.1000.00 ATM0/1/0
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.1010.00 ATM0/1/1
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.1020.00 ATM0/1/2
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.1030.00 ATM0/1/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.8000.00 ATM1/0/0
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.8010.00 ATM1/0/1
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.8020.00 ATM1/0/2
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.8030.00 ATM1/0/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.9000.00 ATM1/1/0
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.9010.00 ATM1/1/1
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.9020.00 ATM1/1/2
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c80.9030.00 ATM1/1/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.8000.00 ATM3/0/0
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.8010.00 ATM3/0/1
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.8020.00 ATM3/0/2
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.8030.00 ATM3/0/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.9000.00 ATM3/1/0
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.9010.00 ATM3/1/1
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.9020.00 ATM3/1/2
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c81.9030.00 ATM3/1/3
  47.0091.8100.0000.0040.0b0a.2b81.4000.0c82.0030.00 ATM-P4/0/3
ILMI Switch Prefix(es):
  47.0091.8100.0000.0040.0b0a.2b81
ILMI Configured Interface Prefix(es):
LECS Address(es):
Switch#

Use ping to Test the Ethernet Connection

After you have configured the IP address(es) for the Ethernet interface, test for connectivity between the switch and a host. The host can reside anywhere in your network. To test for Ethernet connectivity, perform the following task:

Task Command

Test the configuration using the ping command. The ping command sends an echo request to the host specified in the command line.

ping ip ip_address

For example, to test Ethernet connectivity from the switch to a workstation with an IP address of 172.20.40.201, enter the command ping ip 172.20.40.201. If the switch receives a response, the following message is displayed:

Switch#ping ip 172.20.40.201

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.20.40.201, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/202/1000 ms
Switch#

Use ping atm to Confirm the ATM Connections

Use the ping atm command to confirm that the ATM interfaces are configured correctly. Figure 4-16 is an example of this command:

Figure 4-16: ping atm Command Example

Switch#ping atm interface atm 3/0/0 0 5 seg-loopback

Type escape sequence to abort.
Sending Seg-Loopback 5, 53-byte OAM Echoes to a neighbour,timeout is 5 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Switch#

Use show atm interface to Confirm ATM Interface Configuration

Use the show atm interface command to confirm the atm interfaces are configured correctly. Figure 4-17 is an example of this command:

Figure 4-17: show atm interface Command Example

Switch#show atm interface

Interface:      ATM0/0/0        Port-type:    oc3suni
IF Status:      UP              Admin Status: up
Auto-config:    disabled        AutoCfgState: not applicable
IF-Side:        User            IF-type:      IISP
Uni-type:       not applicable  Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       32768
ATM Address for Soft VC: 47.0091.8100.0000.0060.3e5a.db01.4000.0c80.0000.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      3        0       0       2        0       0           5                4
Logical ports(VP-tunnels):     1
Input cells:    200             Output cells: 813
5 minute input rate:             0 bits/sec,       0 cells/sec
5 minute output rate:            0 bits/sec,       0 cells/sec
Input AAL5 pkts: 200, Output AAL5 pkts: 813, AAL5 crc errors: 0
Interface:      ATM0/0/0.99     Port-type:    vp tunnel
IF Status:      UP              Admin Status: up
Auto-config:    disabled        AutoCfgState: not applicable
IF-Side:        Network         IF-type:      UNI
Uni-type:       Private         Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         0               Max-VC:       32768
ATM Address for Soft VC: 47.0091.8100.0000.0060.3e5a.db01.4000.0c80.0000.63
Configured virtual links:
  PVCLs SoftVCLs   SVCLs  Total-Cfgd  Installed-Conns
      5        0       0           5                5
Interface:      ATM0/0/1        Port-type:    oc3suni
IF Status:      UP              Admin Status: up
Auto-config:    disabled        AutoCfgState: not applicable
IF-Side:        User            IF-type:      IISP
Uni-type:       not applicable  Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       32768
ATM Address for Soft VC: 47.0091.8100.0000.0060.3e5a.db01.4000.0c80.0010.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      3        0       0       0        0       0           3                3
Logical ports(VP-tunnels):     0
Input cells:    814             Output cells: 202
5 minute input rate:             0 bits/sec,       0 cells/sec
 --More--
<Information Deleted>
Switch#

Use show atm status to Confirm Interface Status

Use the show atm status command to confirm the status of ATM interfaces. Figure 4-18 is an example of this command:

Figure 4-18: show atm status Command Example

Switch#show atm status

NUMBER OF INSTALLED CONNECTIONS: (P2P=Point to Point, P2MP=Point to MultiPoint)
Type       PVCs  SoftPVCs      SVCs      PVPs  SoftPVPs      SVPs      Total
P2P          10         0         0         0         0         0         10
P2MP          0         0         0         0         0         0          0
                                    TOTAL INSTALLED CONNECTIONS =         10
PER-INTERFACE STATUS SUMMARY AT 11:18:04 UTC Mon Apr 14 1997:
   Interface      IF         Admin  Auto-Cfg    ILMI Addr     SSCOP    Hello
     Name       Status      Status    Status    Reg State     State    State
------------- -------- ------------ -------- ------------ --------- --------
ATM-P0/0/3          UP           up  waiting          n/a  OConPend      n/a
ATM0/1/0            UP           up     done  UpAndNormal    Active  LoopErr
ATM0/1/1          DOWN         down  waiting          n/a      Idle      n/a
ATM0/1/2          DOWN         down  waiting          n/a      Idle      n/a
ATM0/1/3            UP           up     done  UpAndNormal    Active      n/a
ATM1/0/0            UP           up      n/a  UpAndNormal    Active      n/a
ATM1/0/1          DOWN         down  waiting          n/a      Idle      n/a
ATM1/0/2          DOWN         down  waiting          n/a      Idle      n/a
ATM1/0/3            UP           up     done  UpAndNormal    Active  LoopErr
ATM1/1/0          DOWN         down  waiting          n/a      Idle      n/a
ATM1/1/1          DOWN         down  waiting          n/a      Idle      n/a
ATM1/1/2          DOWN         down  waiting          n/a      Idle      n/a
ATM1/1/3          DOWN         down  waiting          n/a      Idle      n/a
ATM2/0/0            UP           up      n/a  UpAndNormal      Idle      n/a
ATM3/0/0          DOWN         down      n/a          n/a      Idle      n/a
ATM3/0/1          DOWN         down  waiting          n/a      Idle      n/a
ATM3/0/2          DOWN         down  waiting          n/a      Idle      n/a
ATM3/0/3          DOWN         down  waiting          n/a      Idle      n/a
ATM3/1/0          DOWN         down  waiting          n/a      Idle      n/a
ATM3/1/1          DOWN         down  waiting          n/a      Idle      n/a
ATM3/1/2          DOWN         down  waiting          n/a      Idle      n/a
ATM3/1/3          DOWN         down  waiting          n/a      Idle      n/a
ATM-P4/0/3          UP           up  waiting          n/a      Idle      n/a
Switch#

Use show atm vc to Confirm Virtual Connection

Use the show atm vc command to confirm the status of ATM virtual channels. Figure 4-19 is an example of this command:

Figure 4-19: show atm vc Command Example

Switch#show atm vc

Interface    VPI     VCI     Type   X-Interface  X-VPI   X-VCI   Status
ATM0/0/0     0       5        PVC     ATM2/0/0     0       32      DOWN
ATM0/0/0     0       16       PVC     ATM2/0/0     0       33      DOWN
ATM0/0/0     0       18       PVC     ATM2/0/0     0       34      DOWN
ATM0/0/0.99  99      3        PVC     ATM2/0/0     0       83      DOWN
ATM0/0/0.99  99      4        PVC     ATM2/0/0     0       84      DOWN
ATM0/0/0.99  99      5        PVC     ATM2/0/0     0       80      DOWN
ATM0/0/0.99  99      16       PVC     ATM2/0/0     0       81      DOWN
ATM0/0/0.99  99      18       PVC     ATM2/0/0     0       82      DOWN
ATM0/0/1     0       5        PVC     ATM2/0/0     0       35      DOWN
ATM0/0/1     0       16       PVC     ATM2/0/0     0       36      DOWN
ATM0/0/1     0       18       PVC     ATM2/0/0     0       37      DOWN
ATM0/0/2     0       5        PVC     ATM2/0/0     0       38      UP
ATM0/0/2     0       16       PVC     ATM2/0/0     0       39      UP
ATM0/0/2     0       18       PVC     ATM2/0/0     0       40      UP
ATM0/0/3     0       5        PVC     ATM2/0/0     0       41      UP
ATM0/0/3     0       16       PVC     ATM2/0/0     0       42      UP
ATM0/0/3     0       18       PVC     ATM2/0/0     0       43      UP
ATM0/1/0     0       5        PVC     ATM2/0/0     0       44      UP
ATM0/1/0     0       16       PVC     ATM2/0/0     0       45      UP
ATM0/1/0     0       18       PVC     ATM2/0/0     0       46      UP
ATM0/1/1     0       5        PVC     ATM2/0/0     0       47      UP
ATM0/1/1     0       16       PVC     ATM2/0/0     0       48      UP
 --More--
Switch#

Use show running-config to Confirm Configuration

Use the show running-configuration command to confirm the configuration being used is configured correctly. Figure 4-20 is an example of this command:

Figure 4-20: show running-configuration Command Example

Switch#show running-config

Building configuration...
Current configuration:
!
version 11.2
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
!
username dplatz
ip rcmd rcp-enable
ip rcmd remote-host dplatz 171.69.194.9 dplatz
ip rcmd remote-username dplatz
atm template-alias training 47.1328...
atm template-alias bit_set 47.9f9(1*0*)88ab...
atm template-alias byte_wise 47.9*f8.33...
atm accounting enable
atm accounting file acctng_file1
atm accounting selection 1
!
atm e164 translation-table
 e164 address 1111111 nsap-address 11.111111111111111111111111.112233445566.11
 e164 address 2222222 nsap-address 22.222222222222222222222222.112233445566.22
 e164 address 3333333 nsap-address 33.333333333333333333333333.112233445566.33
!
atm service-category-limit cbr 64544
atm service-category-limit vbr-rt 64544
atm service-category-limit vbr-nrt 64544
atm service-category-limit abr-ubr 64544
atm address 47.0091.8100.0000.0040.0b0a.2b81.0040.0b0a.2b81.00
atm router pnni
 node 1 level 56 lowest
  redistribute atm-static
!
!
interface CBR0/0/0
 no ip address
!
interface CBR0/0/1
 no ip address
!
interface CBR0/0/2
 no ip address
!
interface CBR0/0/3
 no ip address
 --More--
<Information Deleted>
!
interface ATM3/0/3
 no keepalive
!
interface ATM3/1/0
 no keepalive
!
interface ATM3/1/1
 no keepalive
!
interface ATM3/1/2
 no keepalive
!
interface ATM3/1/3
 no keepalive
!
interface CBR4/0/0
 no ip address
!
interface CBR4/0/1
 no ip address
!
interface CBR4/0/2
 no ip address
!
interface CBR4/0/3
 no ip address
!
no ip classless
atm route 47.0091.8100.0000.0000.0ca7.ce01... ATM3/0/0
tftp-server atm-accounting acctng_file1 1
rmon event 1 trap test description test owner nms_3
!
line con 0
line aux 0
 monitor
line vty 0 4
 login
!
end
Switch#

Use show startup-config to Confirm Saved Configuration

Use the show configuration command to confirm the configuration saved in NVRAM is configured correctly. Figure 4-21 is an example of this command:

Figure 4-21: show startup-config Command Example

Switch#show startup-config

Using 2026 out of 129016 bytes
!
version 11.2
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.112-1.4.WA3.0.15
!
ip host-routing
ip rcmd rcp-enable
ip rcmd rsh-enable
ip rcmd remote-username dplatz
ip domain-name cisco.com
ip name-server 198.92.30.32
atm filter-set tod1 index 4 permit time-of-day 0:0 0:0
atm service-category-limit cbr 64512
atm service-category-limit vbr-rt 64512
atm service-category-limit vbr-nrt 64512
atm service-category-limit abr-ubr 64512
atm qos default  cbr max-cell-loss-ratio clp1plus0 12
atm qos default  vbr-nrt max-cell-loss-ratio clp1plus0 12
atm address 47.0091.8100.0000.0041.0b0a.1081.0041.0b0a.1081.00
atm address 47.0091.8100.5670.0000.0000.0000.0040.0b0a.1081.00
atm router pnni
 node 1 level 56 lowest
  redistribute atm-static
!
!
interface ATM0/0/0
 no keepalive
 atm manual-well-known-vc
 atm access-group tod1 in
 atm pvc 0 35 rx-cttr 3 tx-cttr 3  interface  ATM2/0/0 0 any-vci  encap qsaal
!
interface ATM0/0/1
 no keepalive
!
interface ATM0/0/2
 no keepalive
!
interface ATM0/0/3
 no keepalive
 atm pvc 2 100  interface  ATM0/0/0 0 50
!
interface ATM0/1/0
 no keepalive
!
interface ATM0/1/1
 no keepalive
!
interface ATM0/1/2
 no keepalive
!
interface ATM0/1/3
 no keepalive
!
interface ATM1/0/0
 no keepalive
 atm pvp 99
!
interface ATM1/0/0.99 point-to-point
 atm maxvp-number 0
!
interface ATM1/0/1
 no keepalive
!
interface ATM1/0/2
 no keepalive
!
interface ATM1/0/3
 no keepalive
!
interface ATM1/1/0
 no keepalive
!
interface ATM1/1/1
 no keepalive
!
interface ATM1/1/2
 no keepalive
!
interface ATM1/1/3
 no keepalive
!
interface ATM2/0/0
 no ip address
 no keepalive
 atm maxvp-number 0
 atm pvc 0 any-vci  encap aal5snap
!
interface Ethernet2/0/0
 ip address 172.20.40.93 255.255.255.0
!
no ip classless
ip route 0.0.0.0 0.0.0.0 172.20.40.201
atm route 47.0091.8100.0000... ATM0/0/0 scope 1
atm route 47.0091.8100.0000.00... ATM0/0/0 e164-address 1234567
!
line con 0
line aux 0
line vty 0 4
 login
!
end
Switch#

Task	Command
Display general RMON statistics.	show rmon or show rmon task
Display the RMON alarm table.	show rmon alarms
Display the RMON event table.	show rmon events

Table of Contents

Initially Configuring the LightStream 1010 ATM Switch

Example

Examples

Example

Examples

Examples

Examples

Examples

Syntax Description

Examples