Initially Configuring the LightStream 1010 ATM Switch

This chapter discusses how to initially configure the LightStream 1010 ATM switch. Because the LightStream 1010 offers plug-and-play operation, you might not need to perform any of these procedures in this chapter.

The LightStream 1010ships with the ATM address autoconfigured by Cisco Systems, allowing the switch to automatically configure attached end systems using the Interim Local 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 an IP address autoconfiguration mechanism such as BOOTP, allow the LightStream 1010 to be entirely self-configured. Through network management applications and the text-based command line interface (CLI), you can configure and customize all aspects of the operation of the switch.

You must assign an IP address 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 is 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, you must add a static routing table entry 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 (11.2).

The following sections describe the LightStream 1010 initial configuration:

Methods Available for Configuring the LightStream 1010 Switch

Two methods are available for configuring a LightStream 1010 ATM switch:

From a local console or workstation---Connect to the console port or connect to the Ethernet port of a LightStream 1010 switch. (See Figure 4-1.) This connection allows you to issue CLI commands directly to the LightStream 1010 chassis.
From a remote console or workstation---Initiate a Telnet connection to a target LightStream 1010 switch. (See Figure 4-1.) Telnet allows you to remotely issue CLI commands to that chassis.

Figure 4-1: Methods of Configuring a LightStream 1010 ATM Switch

Confirm Before You Begin

You might need the following information before you configure your LightStream 1010:

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), you need an ATM address assigned by your system administrator.
If you are not using BOOTP, you 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 the 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."

If the LightStream 1010 switch does not boot correctly see the chapter "Confirming the Installation" of the LightStream 1010 ATM Switch Hardware Installation Guide for troubleshooting procedures.

Configure the BOOTP Server

The BOOTP protocol automatically assigns an Ethernet IP address 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-2 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-2 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-2 shows a BOOTP configuration file, with the LightStream 1010 ATM switch entry added at the end of the example.

Figure 4-2: 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>

Configure the ATM Address

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 ATM addressing scheme, if you chose to manually change any ATM address, is to maintain the uniqueness of the address across large networks.

Autoconfigured ATM Addressing Scheme

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

Figure 4-3: ATM Address Format

Authority and 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 The first 13 bytes of the address is a switch prefix used by ILMI in assigning addresses to end stations connected to User-Network Interface (UNI) ports.

MAC address of the switch---6 bytes (used to distinguish multiple end system identifier [ESI] addresses)

Note Both MAC address fields in the ATM address are the same but they might not be the same as the address printed 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 enables you to manually configure other switches to be used in a single-level PNNI routing domain consisting primarily of autoconfigured Cisco ATM switches. You must use a globally unique MAC address 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, you need to addresses 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 the 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 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.

	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.

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
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 Module 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 CLI commands, which are described in the section "Configuring Virtual Connections."

Modify the 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 Module Interfaces." You can accept the ATM interface configuration or overwrite the default interface configuration using the CLI commands, which are described in the chapter "Configuring Virtual Connections."

The following example describes modifying an OC-3 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 level 3c (STS-3c) mode to Synchronous TRansfer Module level 1 (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 (11.2) 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 shows how to disable 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 OC-3 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 (11.2) 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 OC-3 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:SECTION LOS    Loopback:None    Flags:8300
TX Led: Traffic Pattern    RX Led: Traffic Pattern  TX clock source:  network-de
rived
Framing mode:  sts-3c
Cell payload scrambling on
Sts-stream scrambling on
 
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:0, rxcell:0
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:8F
 
  mr 0x30, mcfgr 0x70, misr 0x00, mcmr 0x0F,
  mctlr 0x48, cscsr 0x50, crcsr 0x48, rsop_cier 0x00,
  rsop_sisr 0x47, rsop_bip80r 0x00, rsop_bip81r 0x00, tsop_ctlr 0x80,
  tsop_diagr 0x80, rlop_csr 0x02, rlop_ieisr 0x00, 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 0x1C,
  rpop_isr 0x00, rpop_ier 0x50, rpop_pslr 0xFF, rpop_pbip80r 0x00,
  rpop_pbip81r 0x00, rpop_pfebe0r 0x00, rpop_pfebe1r 0x00, tpop_cdr 0x00,
  tpop_pcr 0x00, tpop_ap0r 0x00, tpop_ap1r 0x90, tpop_pslr 0x13,
  tpop_psr 0x00, racp_csr 0x84, racp_iesr 0x00, racp_mhpr 0x00,
  racp_mhmr 0x00, racp_checr 0x00, racp_uhecr 0x00, racp_rcc0r 0x00,
  racp_rcc1r 0x00, racp_rcc2r 0x00, racp_cfgr 0xFC, tacp_csr 0x04,
  tacp_iuchpr 0x00, tacp_iucpopr 0x6A, tacp_fctlr 0x00, tacp_tcc0r 0x00,
  tacp_tcc1r 0x00, tacp_tcc2r 0x00, tacp_cfgr 0x08,
  phy_tx_cnt:0, phy_rx_cnt:0
 Switch#

The following example displays the OC-3 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 ATM switch processor (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."
Serial Line Internet Protocol/Point-to-Point Protocol (SLIP/PPP)---See the chapter "Configuring Terminal Lines and Modem Support."

Note These IP connections are used only 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; which 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, of 16 host bits for Class B addresses, and 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, between 0 and 14 for Class B addresses, or between 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 (11.2) 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 shows how to configure 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 shows how to use 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#

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

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#

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 can be configured for each port in one of the following ways:

Free-running---Transmit clocking is derived from the local oscillator on a port adapter module (PAM) or from ATM Switch Processor (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-4 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, received across the backplane from interface 0/0/0.

The network clocking configuration has uses priorities one to four, each of which initially defaults to "no clock." Priority five is a pseudo-priority that defaults to "system clock" and is not configurable. If priorities one to four are not configured, then priority five is used as the derived clock.

Figure 4-4: Transmit Clock Distribution

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

Note By default, the ASP system clock is priority five; however, you can configure the system clock 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, Figure 4-5 shows the following:

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/3, immediately starts providing the transmit clocking to the backplane and interface 4/0/0.
If the network-clock-select command is configured as revertive, when the priority one interface, 0/0/0, has been functioning correctly for at least one minute, the interfaces using network-derived transmit clocking will start to receive their clocking again from interface 0/0/0.

Note The network clock is, by default, configured as non-revertive. The algorithm to switch to the highest priority best clock only runs if the network-clock-select command is configured as revertive.

Figure 4-5: 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 five), 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} {system² | card/subcard/port} [revertive]

¹This command is documented in the LightStream 1010 ATM Switch Command Reference (11.2) publication.
²Selects the ASP reference clock.

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} {system² \| card/subcard/port} [revertive]

Examples

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

Switch#config t

Enter configuration commands, one per line.  End with CNTL/Z. 
Switch(config)#network-clock-select 1 atm 0/0/0

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

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

Switch(config)#

The following example shows how to configure the network clock to revert back to the highest priority clock source after a failure:

Switch(config)#network-clock-select revertive

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 the clock source 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 (11.2) 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

Show the interface controller status.

show controllers [atm card/subcard/port]

Task	Command
Show the network clocking configuration.	show network-clocks
Show the interface clock source configuration.	show running-config
Show the interface controller status.	show controllers [atm card/subcard/port]

Examples

The following example displays the switch clock source configuration shown in Figure 4-4:

Switch#show network

Priority 1 clock source: ATM0/0/0
Priority 2 clock source: ATM0/0/3
Priority 3 clock source: ATM1/0/0
Priority 4 clock source: No clock
Priority 5 clock source: System clock
Current clock source: ATM0/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#

The following example displays the interface controller status of ATM interface 0/0/0:

Switch#show controllers 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:SECTION LOS    Loopback:None    Flags:8300
TX Led: Traffic Pattern    RX Led: Traffic Pattern  TX clock source:  network-derived
Framing mode:  sts-3c
Cell payload scrambling on
Sts-stream scrambling on
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:0, rxcell:0
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:8F
  mr 0x30, mcfgr 0x70, misr 0x00, mcmr 0x0F,
  mctlr 0x48, cscsr 0x50, crcsr 0x48, rsop_cier 0x00,
  rsop_sisr 0x47, rsop_bip80r 0x00, rsop_bip81r 0x00, tsop_ctlr 0x80,
  tsop_diagr 0x80, rlop_csr 0x02, rlop_ieisr 0x00, rlop_bip8_240r 0x02,
  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 0x1C,
  rpop_isr 0x00, rpop_ier 0x50, rpop_pslr 0xFF, rpop_pbip80r 0x00,
  rpop_pbip81r 0x00, rpop_pfebe0r 0x00, rpop_pfebe1r 0x00, tpop_cdr 0x00,
  tpop_pcr 0x00, tpop_ap0r 0x00, tpop_ap1r 0x90, tpop_pslr 0x13,
  tpop_psr 0x00, racp_csr 0x84, racp_iesr 0x00, racp_mhpr 0x00,
  racp_mhmr 0x00, racp_checr 0x00, racp_uhecr 0x00, racp_rcc0r 0x00,
  racp_rcc1r 0x00, racp_rcc2r 0x00, racp_cfgr 0xFC, tacp_csr 0x04,
  tacp_iuchpr 0x00, tacp_iucpopr 0x6A, tacp_fctlr 0x00, tacp_tcc0r 0x00,
  tacp_tcc1r 0x00, tacp_tcc2r 0x00, tacp_cfgr 0x08,
  phy_tx_cnt:0, phy_rx_cnt:0
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 (ATM adaption layer 1 [AAL1]) traffic in ATM networks. In general, Class A traffic pertains to voice and video transmissions.

In the 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 either overflows or underflows, resulting in periodic line errors.

The CES modules have been designed specifically to handle CBR traffic in an ATM networking environment. To provide the required timing functions to support 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 LightStream 1010 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 OC-3 or OC-12 PAM in a LightStream 1010 chassis
A quad DS-3 module in a LightStream 1010 chassis
Any T1/E1, OC-3, or OC-12 trunk line, or other means of interconnecting an ATM network

Note 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 CBR 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:

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

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

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 private branch exchange (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, you 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 using the network-clock-select command, as described in the section "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."

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 the section "Synchronous Residual Time Stamp Clocking."

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

: Although adaptive 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 name adaptive clocking mode reflects 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 the section "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. For example, the following LightStream 1010 modules are capable of receiving and distributing a PRS:

CES modules
OC-3 modules
OC-12 modules
Quad DS3
E1/T1 trunk modules

By issuing the 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 command is described in the section "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.

Description of Clocking Modes

The following sections describe the clocking modes in greater detail, presenting them in the preferred order of use in your LightStream 1010 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-6 shows that a LightStream 1010 switch can use a PRS that originates from any one of several sources in the networking environment.

Figure 4-6 shows four possible sources of a PRS. However, do not interpret Figure 4-6 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-6 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-6: Synchronous Clocking Sources in ATM Network

Note that each PRS in Figure 4-6 is externally generated---that is, the timing signal originates from a source outside the ATM network proper. Also shown is an OC-3 or OC-12 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-6 is currently supplying a priority 1 PRS to the network. If the PRS fails for some reason, the OC-3/OC-12 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-7 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 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 OC-3 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-7: Synchronous Clocking in LightStream 1010 ATM Network

See the following sections for clocking configuration examples:

Synchronous Residual Time Stamp Clocking

SRTS clocking can be used if the your edge equipment is driven by a different clocking signal than that being used in the ATM network proper. Figure 4-8 shows such an operating scenario, in which a timing signal is provided to edge nodes independently from the ATM network.

Figure 4-8: SRTS Clocking in LS1010 ATM Network

Using Figure 4-8, 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 data 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 your 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 the unique electrical characteristics of that device

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 Hard PVC with Adaptive Clocking" in the chapter "Configuring Port Adapter Module Interfaces."

For an unstructured hard permanent virtual circuit (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 task 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 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 accounts for 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 Module 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 Interim-Interswitch Signaling Protocol (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-9 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-9: 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 hh:mm:ss day_of_month month year

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 (11.2) publication.

Task	Command
Set the system clock.	clock set hh:mm:ss day_of_month month year
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

Examples

The following example shows how to configure the time, date, month using the clock set command:

Switch# clock set 15:01:00 17 October 1997

Switch#

The following example shows how to configure the hostname using the hostname command:

Switch# config t

Enter configuration commands, one per line.  End with CNTL/Z.
Switch(config)#hostname Publications

Publications#

The following example shows how to confirm the clock setting using the show clock command:

Publications# show clock

.15:03:12.015 UTC Fri Oct 17 1997
Publications#

Configure SNMP Management

The SNMP system consists of three parts:

SNMP manager
SNMP agent
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 (11.2).

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 that alert 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-10 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-10: 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 appendix "LightStream 1010 MIB Information" for information about 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 5 (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. The following three kinds of exceptions are also reported:

No such object exceptions
No such instance exceptions
End of MIB view exceptions

There is no specific command 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 the 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, so 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 File Transport Protocol (FTP) from cco.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-11 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-11: 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 but 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 are 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.

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

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 are stored in the history table and sent to the SNMP network management station.

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. You 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]

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 shows how to enable the rmon event command:

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

This example shows how to configure 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 SNMP trap when the event is triggered

The following example shows how to configure 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 shows how to configure 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 rise or fall of the variable
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-12 is an example of the copy running-config command.

Figure 4-12: Storing Configuration in NVRAM Example

Switch# copy running-config startup-config

Building configuration...
[OK]
Switch#

For detailed configuration storage information see the section "Store System Images and Configuration Files" in the chapter "Loading System Images, Software Images, and Configuration Files."

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:

Note The following examples differ depending on the Feature Card installed on the ASP.

Use show hardware to Confirm Hardware Configuration

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

Figure 4-13: show hardware Command Example

Switch#show hardware

 
LS1010 named Switch, Date: 16:06:11 UTC Wed Nov 5 1997
Feature Card's FPGA Download Version: 0
 
Slot Ctrlr-Type    Part No.  Rev  Ser No  Mfg Date   RMA No. Hw Vrs  Tst EEP
---- ------------  ---------- -- -------- --------- -------- ------- --- ---
1/1  QUAD DS3 PAM  73-2197-02 00 03656116 Dec 18 96 00-00-00   1.0     0   2
3/0  155MM PAM     73-1496-03 06 02180446 Jan 17 96 00-00-00   3.0     0   2
3/1  155MM PAM     73-1496-03 00 02180455 Jan 17 96 00-00-00   3.0     0   2
4/0  T1 PAM        12-3456-78 00 00000022 Aug 01 95 00-00-00   0.4     0   2
4/1  T1 PAM        12-3456-78 00 00000025 Aug 01 95 00-00-00   0.4     0   2
2/0  ATM Swi/Proc  73-1402-06 C2 05426230 Sep 23 97 00-00-00   4.0     0   2
2/1  FC-PFQ        73-2281-04 01 04845638 Sep 17 97 00-00-00   4.0     0   2
 
DS1201 Backplane EEPROM:
Model  Ver.  Serial  MAC-Address  MAC-Size  RMA  RMA-Number   MFG-Date
------ ---- -------- ------------ --------  ---  ----------  -----------
7506  0   0 000000000000   0      0        0       00 00
 
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-14 is an example of the show version command:

Figure 4-14: show version Command Example

Switch# show version

Cisco Internetwork Operating System Software
IOS (tm) PNNI Software (LS1010-WP-M), Version 11.2(99), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1997 by cisco Systems, Inc.
Compiled Tue 07-Oct-97 04:53 by
Image text-base: 0x60010910, data-base: 0x604E6000
 
ROM: System Bootstrap, Version 11.2(1.4.WA3.0) [integ 1.4.WA3.0], RELEASE SOFTWARE
 
Switch uptime is 2 weeks, 2 days, 39 minutes
System restarted by power-on
System image file is "bootflash:ls1010-wp-mz.112-8.0.1.FWA4.0.16", booted via bootflash
 
cisco ASP (R4600) processor with 65536K bytes of memory.
R4700 processor, Implementation 33, Revision 1.0
Last reset from power-on
1 Ethernet/IEEE 802.3 interface(s)
20 ATM network interface(s)
123K bytes of non-volatile configuration memory.
 
8192K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2101
 
Switch#

Use show diag power-on to Confirm Power-on Diagnostics

Use the show diag power-on command to confirm the power-on diagnostics. Figure 4-15 provides an example of this command:

Figure 4-15: show diag power-on Command Example

Switch#show diag power-on

LS1010 Power-on Diagnostics Status (.=Pass,F=Fail,U=Unknown,N=Not Applicable)
----------------------------------------------------------------------------
   Last Power-on Date: 97/10/11   Time: 15:49:45
 
   BOOTFLASH:  .   PCMCIA-Slot0: N   PCMCIA-Slot1: N
   CPU-IDPROM: .   FCard-IDPROM: .   NVRAM-Config: .
   SRAM:       .   DRAM:         .
 
   PS1:        N   PS2:          N   PS (12V):     .
   FAN:        .   Temperature:  .   Bkp-IDPROM:   F
 
   MMC-Switch Access: .              Accordian Access: .
   LUT: .   ITT: .   OPT: .   OTT: .   STK: .   LNK: .   ATTR: .   Queue: .
   Cell-Memory:  .
 
Access/Interrupt/Loopback/CPU-MCast/Port-MCast/FC-MCast/FC-TMCC Test Status:
Ports                      0         1         2         3
----------------------------------------------------------------------------
PAM 1/1 (DS3Q)          .....NN   .....NN   .....NN   .....NN
PAM 3/0 (155MM)         .....NN   .....NN   .....NN   .....NN
PAM 3/1 (155MM)         .....NN   .....NN   .....NN   .....NN
PAM 4/0 (T1)            .....NN   .....NN   .....NN   .....NN
PAM 4/1 (T1)            .....NN   .....NN   .....NN   .....NN
 
   Ethernet-port Access:   .         Ethernet-port CAM-Access: .
   Ethernet-port Loopback: .         Ethernet-port Loadgen:    .
 
Power-on Diagnostics Passed.
 
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-16 displays this command:

Figure 4-16: 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.0000.0000 (bia 0000.0000.0000)
  Internet address is 172.20.52.20/26
  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:00, 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 1000 bits/sec, 2 packets/sec
  5 minute output rate 0 bits/sec, 1 packets/sec
     69435 packets input, 4256035 bytes, 0 no buffer
     Received 43798 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 input packets with dribble condition detected
     203273 packets output, 24079764 bytes, 0 underruns
     0 output errors, 0 collisions, 2 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#

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-17 provides an example of this command:

Figure 4-17: show atm addresses Command Example

Switch#show atm addresses

 
Switch Address(es):
  47.009181000000000100000001.000100000001.00 active
 
Soft VC Address(es):
  47.0091.8100.0000.0001.0000.0001.4000.0c80.9000.00 ATM1/1/0
  47.0091.8100.0000.0001.0000.0001.4000.0c80.9010.00 ATM1/1/1
  47.0091.8100.0000.0001.0000.0001.4000.0c80.9020.00 ATM1/1/2
  47.0091.8100.0000.0001.0000.0001.4000.0c80.9030.00 ATM1/1/3
  47.0091.8100.0000.0001.0000.0001.4000.0c81.8000.00 ATM3/0/0
  47.0091.8100.0000.0001.0000.0001.4000.0c81.8000.63 ATM3/0/0.99
  47.0091.8100.0000.0001.0000.0001.4000.0c81.8010.00 ATM3/0/1
  47.0091.8100.0000.0001.0000.0001.4000.0c81.8020.00 ATM3/0/2
  47.0091.8100.0000.0001.0000.0001.4000.0c81.8030.00 ATM3/0/3
  47.0091.8100.0000.0001.0000.0001.4000.0c81.9000.00 ATM3/1/0
  47.0091.8100.0000.0001.0000.0001.4000.0c81.9010.00 ATM3/1/1
  47.0091.8100.0000.0001.0000.0001.4000.0c81.9020.00 ATM3/1/2
  47.0091.8100.0000.0001.0000.0001.4000.0c81.9030.00 ATM3/1/3
  47.0091.8100.0000.0001.0000.0001.4000.0c82.0000.00 ATM4/0/0
  47.0091.8100.0000.0001.0000.0001.4000.0c82.0010.00 ATM4/0/1
  47.0091.8100.0000.0001.0000.0001.4000.0c82.0020.00 ATM4/0/2
  47.0091.8100.0000.0001.0000.0001.4000.0c82.0030.00 ATM4/0/3
  47.0091.8100.0000.0001.0000.0001.4000.0c82.1000.00 ATM4/1/0
  47.0091.8100.0000.0001.0000.0001.4000.0c82.1010.00 ATM4/1/1
  47.0091.8100.0000.0001.0000.0001.4000.0c82.1020.00 ATM4/1/2
  47.0091.8100.0000.0001.0000.0001.4000.0c82.1030.00 ATM4/1/3
 
ILMI Switch Prefix(es):
  47.0091.8100.0000.0001.0000.0001
 
ILMI Configured Interface Prefix(es):
 
LECS Address(es):
Switch#

Use ping to Test the Ethernet Connection

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-18 is an example of this command:

Figure 4-18: 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-19 is an example of this command:

Figure 4-19: show atm interface Command Example

Switch# show atm interface

Interface:      ATM1/1/0        Port-type:    ds3suni_Quad
IF Status:      DOWN            Admin Status: down
Auto-config:    enabled         AutoCfgState: waiting for response from peer
IF-Side:        Network         IF-type:      UNI
Uni-type:       Private         Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       16383
Svc Upc Intent: pass            Signalling:   Enabled
ATM Address for Soft VC: 47.0091.8100.0000.0001.0000.0001.4000.0c80.9000.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      2        0       0       0        0       0           2                0
Logical ports(VP-tunnels):     0
Input cells:    0               Output cells: 0
5 minute input rate:             0 bits/sec,       0 cells/sec
5 minute output rate:            0 bits/sec,       0 cells/sec
Input AAL5 pkts: 0, Output AAL5 pkts: 0, AAL5 crc errors: 0
 
 
Interface:      ATM1/1/1        Port-type:    ds3suni_Quad
IF Status:      DOWN            Admin Status: down
Auto-config:    enabled         AutoCfgState: waiting for response from peer
IF-Side:        Network         IF-type:      UNI
Uni-type:       Private         Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       16383
Svc Upc Intent: pass            Signalling:   Enabled
ATM Address for Soft VC: 47.0091.8100.0000.0001.0000.0001.4000.0c80.9010.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      2        0       0       0        0       0           2                0
Logical ports(VP-tunnels):     0
Input cells:    0               Output cells: 0
5 minute input rate:             0 bits/sec,       0 cells/sec
5 minute output rate:            0 bits/sec,       0 cells/sec
Input AAL5 pkts: 0, Output AAL5 pkts: 0, AAL5 crc errors: 0
 
 
Interface:      ATM1/1/2        Port-type:    ds3suni_Quad
IF Status:      DOWN            Admin Status: down
Auto-config:    enabled         AutoCfgState: waiting for response from peer
IF-Side:        Network         IF-type:      UNI
Uni-type:       Private         Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       16383
Svc Upc Intent: pass            Signalling:   Enabled
ATM Address for Soft VC: 47.0091.8100.0000.0001.0000.0001.4000.0c80.9020.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      2        0       0       0        0       0           2                0
Logical ports(VP-tunnels):     0
Input cells:    0               Output cells: 0
5 minute input rate:             0 bits/sec,       0 cells/sec
5 minute output rate:            0 bits/sec,       0 cells/sec
Input AAL5 pkts: 0, Output AAL5 pkts: 0, AAL5 crc errors: 0
 
 
Interface:      ATM1/1/3        Port-type:    ds3suni_Quad
IF Status:      DOWN            Admin Status: down
Auto-config:    enabled         AutoCfgState: waiting for response from peer
IF-Side:        Network         IF-type:      UNI
Uni-type:       Private         Uni-version:  V3.0
Max-VPI-bits:   8               Max-VCI-bits: 14
Max-VP:         255             Max-VC:       16383
Svc Upc Intent: pass            Signalling:   Enabled
ATM Address for Soft VC: 47.0091.8100.0000.0001.0000.0001.4000.0c80.9030.00
Configured virtual links:
  PVCLs SoftVCLs   SVCLs   PVPLs SoftVPLs   SVPLs  Total-Cfgd  Installed-Conns
      2        0       0       0        0       0           2                0
 
--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-20 is an example of this command:

Figure 4-20: 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          30         0         0         1         1         0         32
P2MP          0         0         0         1         0         0          1
                                    TOTAL INSTALLED CONNECTIONS =         33
 
PER-INTERFACE STATUS SUMMARY AT 16:07:59 UTC Wed Nov 5 1997:
   Interface      IF         Admin  Auto-Cfg    ILMI Addr     SSCOP    Hello
     Name       Status      Status    Status    Reg State     State    State
------------- -------- ------------ -------- ------------ --------- --------
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            UP           up      n/a  UpAndNormal    Active  LoopErr
ATM3/0/0.99         UP           up  waiting  WaitDevType      Idle      n/a
ATM3/0/1            UP           up     done  UpAndNormal    Active  LoopErr
ATM3/0/2            UP           up      n/a  UpAndNormal    Active  LoopErr
ATM3/0/3            UP           up     done  UpAndNormal    Active  LoopErr
ATM3/1/0            UP           up     done  UpAndNormal    Active  LoopErr
ATM3/1/1            UP           up     done  UpAndNormal    Active  LoopErr
ATM3/1/2            UP           up     done  UpAndNormal    Active  LoopErr
ATM3/1/3            UP           up     done  UpAndNormal    Active  LoopErr
ATM4/0/0          DOWN         down  waiting          n/a      Idle      n/a
ATM4/0/1          DOWN         down  waiting          n/a      Idle      n/a
ATM4/0/2          DOWN         down  waiting          n/a      Idle      n/a
ATM4/0/3          DOWN         down  waiting          n/a      Idle      n/a
ATM4/1/0          DOWN         down  waiting          n/a      Idle      n/a
ATM4/1/1          DOWN         down  waiting          n/a      Idle      n/a
ATM4/1/2          DOWN         down  waiting          n/a      Idle      n/a
ATM4/1/3          DOWN         down  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-21 is an example of this command:

Figure 4-21: show atm vc Command Example

Switch# show atm vc

Interface    VPI   VCI   Type    X-Interface  X-VPI X-VCI  Encap Status
ATM1/1/0     0     5      PVC     ATM2/0/0     0     52    QSAAL  DOWN
ATM1/1/0     0     16     PVC     ATM2/0/0     0     32    ILMI   DOWN
ATM1/1/1     0     5      PVC     ATM2/0/0     0     53    QSAAL  DOWN
ATM1/1/1     0     16     PVC     ATM2/0/0     0     33    ILMI   DOWN
ATM1/1/2     0     5      PVC     ATM2/0/0     0     54    QSAAL  DOWN
ATM1/1/2     0     16     PVC     ATM2/0/0     0     34    ILMI   DOWN
ATM1/1/3     0     5      PVC     ATM2/0/0     0     55    QSAAL  DOWN
ATM1/1/3     0     16     PVC     ATM2/0/0     0     35    ILMI   DOWN
ATM2/0/0     0     32     PVC     ATM1/1/0     0     16    ILMI   DOWN
ATM2/0/0     0     33     PVC     ATM1/1/1     0     16    ILMI   DOWN
ATM2/0/0     0     34     PVC     ATM1/1/2     0     16    ILMI   DOWN
ATM2/0/0     0     35     PVC     ATM1/1/3     0     16    ILMI   DOWN
ATM2/0/0     0     36     PVC     ATM3/0/0     0     16    ILMI   UP
ATM2/0/0     0     37     PVC     ATM3/0/1     0     16    ILMI   UP
ATM2/0/0     0     38     PVC     ATM3/0/2     0     16    ILMI   UP
ATM2/0/0     0     39     PVC     ATM3/0/3     0     16    ILMI   UP
ATM2/0/0     0     40     PVC     ATM3/1/0     0     16    ILMI   UP
ATM2/0/0     0     41     PVC     ATM3/1/1     0     16    ILMI   UP
ATM2/0/0     0     42     PVC     ATM3/1/2     0     16    ILMI   UP
ATM2/0/0     0     43     PVC     ATM3/1/3     0     16    ILMI   UP
ATM2/0/0     0     44     PVC     ATM4/0/0     0     16    ILMI   DOWN
ATM2/0/0     0     45     PVC     ATM4/0/1     0     16    ILMI   DOWN
Interface    VPI   VCI   Type    X-Interface  X-VPI X-VCI  Encap Status
ATM2/0/0     0     46     PVC     ATM4/0/2     0     16    ILMI   DOWN
ATM2/0/0     0     47     PVC     ATM4/0/3     0     16    ILMI   DOWN
ATM2/0/0     0     48     PVC     ATM4/1/0     0     16    ILMI   DOWN
ATM2/0/0     0     49     PVC     ATM4/1/1     0     16    ILMI   DOWN
ATM2/0/0     0     50     PVC     ATM4/1/2     0     16    ILMI   DOWN
ATM2/0/0     0     51     PVC     ATM4/1/3     0     16    ILMI   DOWN
ATM2/0/0     0     52     PVC     ATM1/1/0     0     5     QSAAL  DOWN
ATM2/0/0     0     53     PVC     ATM1/1/1     0     5     QSAAL  DOWN
ATM2/0/0     0     54     PVC     ATM1/1/2     0     5     QSAAL  DOWN
ATM2/0/0     0     55     PVC     ATM1/1/3     0     5     QSAAL  DOWN
ATM2/0/0     0     56     PVC     ATM3/0/0     0     5     QSAAL  UP
ATM2/0/0     0     57     PVC     ATM3/0/1     0     5     QSAAL  UP
ATM2/0/0     0     58     PVC     ATM3/0/2     0     5     QSAAL  UP
ATM2/0/0     0     59     PVC     ATM3/0/3     0     5     QSAAL  UP
ATM2/0/0     0     60     PVC     ATM3/1/0     0     5     QSAAL  UP
ATM2/0/0     0     61     PVC     ATM3/1/1     0     5     QSAAL  UP
ATM2/0/0     0     62     PVC     ATM3/1/2     0     5     QSAAL  UP
ATM2/0/0     0     63     PVC     ATM3/1/3     0     5     QSAAL  UP
ATM2/0/0     0     64     PVC     ATM4/0/0     0     5     QSAAL  DOWN
ATM2/0/0     0     65     PVC     ATM4/0/1     0     5     QSAAL  DOWN
ATM2/0/0     0     66     PVC     ATM4/0/2     0     5     QSAAL  DOWN
ATM2/0/0     0     67     PVC     ATM4/0/3     0     5     QSAAL  DOWN
 
 --More--
Switch#

Use the show atm vc interface command to confirm the status of ATM virtual channels on a specific interface. Figure 4-22 is an example of this command:

Figure 4-22: show atm vc interface Command Example

Switch# show atm vc interface atm 3/0/0

Interface    VPI   VCI   Type    X-Interface  X-VPI X-VCI  Encap Status
ATM3/0/0     0     5      PVC     ATM2/0/0     0     56    QSAAL  UP
ATM3/0/0     0     16     PVC     ATM2/0/0     0     36    ILMI   UP
ATM3/0/0     0     18     PVC     ATM2/0/0     0     85    PNNI   UP
ATM3/0/0     50    100    PVC     ATM3/0/1     60    200          DOWN
                                  ATM3/0/2     70    210          UP
                                  ATM3/0/3     80    220          UP
ATM3/0/0     100   200    SoftVC  NOT CONNECTED
Switch#

Use the show atm vc interface atm card/subcard/port vpi vci command to confirm the status of a specific ATM interface and virtual channel. Figure 4-23 is an example of this command:

Figure 4-23: show atm vc interface atm card/subcard/port vpi vci Command Example

Switch# show atm vc interface atm 3/0/0 50 100

 
Interface: ATM3/0/0, Type: oc3suni
VPI = 50  VCI = 100
Status: DOWN
Time-since-last-status-change: 21:04:33
Connection-type: PVC
Cast-type: point-to-multipoint-root
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Wrr weight: 32
Number of OAM-configured connections: 0
OAM-configuration: disabled
OAM-states:  Not-applicable
Cross-connect-interface: ATM3/0/1, Type: oc3suni
Cross-connect-VPI = 60
Cross-connect-VCI = 200
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
Cross-connect-interface: ATM3/0/2
Cross-connect-VPI = 70
Cross-connect-VCI = 210
Cross-connect-interface: ATM3/0/3
Cross-connect-VPI = 80
Cross-connect-VCI = 220
Threshold Group: 5, Cells queued: 0
Rx cells: 0, Tx cells: 0
Tx Clp0:0,  Tx Clp1: 0
Rx Clp0:0,  Rx Clp1: 0
Rx Upc Violations:0, Rx cell drops:0
Rx Clp0 q full drops:0, Rx Clp1 qthresh drops:0
Rx connection-traffic-table-index: 1
Rx service-category: UBR (Unspecified Bit Rate)
Rx pcr-clp01: 7113539
Rx scr-clp01: none
Rx mcr-clp01: none
Rx tolerance: 1024 (from default for interface)
Tx connection-traffic-table-index: 1
Tx service-category: UBR (Unspecified Bit Rate)
Tx pcr-clp01: 7113539
Tx scr-clp01: none
Tx mcr-clp01: none
Tx tolerance: none
 
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-24 is an example of this command:

Figure 4-24: 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-25 is an example of this command:

Figure 4-25: 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
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
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

Examples