LightStream 1010 ATM Switch Software Configuration Guide
Initially Configuring the LightStream 1010 ATM Switch

Table Of Contents

Initially Configuring the LightStream 1010 ATM Switch

Methods for Configuring the LightStream 1010 ATM Switch

Configuration Prerequisites

Verify Installed LightStream ATM Switch Software and Hardware

Configuring the BOOTP Server

Configuring the ATM Address

Autoconfigured ATM Addressing Scheme

Modify the Default for Physical Layer Configuration of an ATM Interface

Configure IP Interface Parameters

Test the Ethernet Connection

Configuring Network Clocking

Configure Network Clock Priorities and Sources

Configure the Transmit Clocking Source

Display the Network Clocking Configuration

Network Clock Services for CES Operations and CBR Traffic

Clocking Modes for CES Operations

Other Factors Relevant to CES Operations

Configuring the Network Routing

Configure ATM Static Routes for IISP or PNNI

Configuring the System Information

Configuring SNMP Management

Configuring for both SNMPv1 and SNMPv2

Configuring SNMPv2 Support

Configuring SNMPv1 Support

Configuring SNMP RMON Support

Storing the Configuration

Testing the Configuration

Confirm the Hardware Configuration

Confirm the Software Version

Confirm Power-on Diagnostics

Confirm the Ethernet Configuration

Confirm the ATM Address

Test the Ethernet Connection

Confirm the ATM Connections

Confirm the ATM Interface Configuration

Confirm the Interface Status

Confirm Virtual Channel Connections

Confirm the Running Configuration

Confirm the Saved Configuration


4

Initially Configuring the LightStream 1010 ATM Switch


This chapter discusses how to initially configure the LightStream 1010 ATM switch, and includes the following sections:

Methods for Configuring the LightStream 1010 ATM Switch

Configuration Prerequisites

Configuring the BOOTP Server

Configuring the ATM Address

Configuring Network Clocking

Configuring the Network Routing

Configuring the System Information

Configuring SNMP Management

Storing the Configuration

Testing the Configuration


Note   For a complete description of the commands mentioned in this chapter, refer to the LightStream 1010 ATM Switch Command Reference publication.



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.


Methods for Configuring the LightStream 1010 ATM Switch

The switch defaults to a working configuration suitable for most networks. However, you might need to customize the configuration for your network. The LightStream 1010 ATM switch ships with the ATM address autoconfigured, 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 ATM switch 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."

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 ATM switch. (See Figure 4-1.) This connection allows you to issue CLI commands directly to the LightStream 1010 ATM switch chassis.

From a remote console or workstation—Initiate a Telnet connection to a target LightStream 1010 ATM 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

Configuration Prerequisites

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

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.

Verify Installed LightStream ATM Switch Software and Hardware

When you first power up your console and LightStream 1010 ATM switch, 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 XX.X(X.X.WAX.X.XX)
Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Tue 11Jan-98 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!

The script then displays the banner information, including the software version, followed by 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 XX.X(X.X.WAX.X.XX)
Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Tue 11-Jan-98 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!

The LightStream 1010 ATM switch 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 " ."


Configuring 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 ATM switch 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:

Step
Command
Task
1

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

2

Determine the MAC address from the label on the chassis.

3

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. See the example BOOTP configuration file that follows.

4

reload

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


Example

The following example BOOTP configuration file shows the added LightStream 1010 ATM switch entry:

# /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.


<display truncated>

#########################################################################
# 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>

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



Note   Also refer to the chapter " " in the section " ATM Addresses" for PNNI address considerations.


Autoconfigured ATM Addressing Scheme

During the initial startup, the LightStream 1010 ATM switch generates an ATM address using the defaults shown in .

Figure 4-2 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 " ."

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 an ATM Address and PNNI Node Level" in the chapter " ."

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.

For operation with ATM addresses other than the autoconfigured ATM address, 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 ellipses (...). Entering the ellipses 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.

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

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

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, perform the following tasks, beginning in global configuration mode:

Step
Command
Task
1

interface atm card/subcard/port

Select the physical interface to be configured.

2

no scrambling cell-payload

Disable cell-payload scrambling.

3

no scrambling sts-stream

Disable STS-stream scrambling.

4

sonet {stm-1 | sts-3c}

Configure SONET mode as SDH/STM-1.


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

To change any of the other physical interface default configurations, refer to the commands in the LightStream 1010 ATM Switch Command Reference.

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

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

Command
Task

show controllers atm card/subcard/port

Show the physical layer configuration.

show running-config

Show the physical layer scrambling configuration.


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

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 XX.X
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.11X-X.X.WA4.X.XX
!
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 " Configuring IP Over ATM" in the chapter " ."

LANE client—See the section " Configuring a LAN Emulation Client on the Switch" in the chapter " ."

Serial Line Internet Protocol/Point-to-Point Protocol (SLIP/PPP)—See the chapter " ."


Note   These IP connections are used only for network management.


To configure the switch to communicate via the Ethernet interface, provide the IP address and subnet mask bits for the interface, as described in the following sections.

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.

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

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.


provides a summary of subnetting parameters.

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


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, beginning in global configuration mode:

Step
Command
Task
1

interface ethernet 2/0/0

Select the interface to be configured.

2

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

Configure the IP and subnetwork address.


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 term
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, use the following EXEC command:

Command
Task

show interface ethernet 2/0/0

Display the Ethernet interface IP address.


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

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

Switch# show running-config
Building configuration...

Current configuration:
!
version XX.X
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.XXX-X.X.WA4.X.XX
!
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
!

<Information 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

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, use the following command in EXEC mode:

Command
Task

ping ip ip_address

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


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

Configuring 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 the 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 clocking is derived from the receive clock source.

Derived clocking is received, along with data, from a specified interface. For example, in 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 1 to 4, each of which initially defaults to "no clock." Priority 5 is a pseudo-priority that defaults to "system clock" and is not configurable. If priorities 1 to 4 are not configured, then priority 5 is used as the derived clock.

Figure 4-3 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 1 to 4.


Note   By default, the ASP system clock is priority 5; 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, 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 1 transmit clock interface 0/0/0 fails.

The priority 2 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 1 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-4 Transmit Clocking Priority Configuration Example


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


Network clocking configuration is described in the following sections:

Configure Network Clock Priorities and Sources

Configure the Transmit Clocking Source

Display the Network Clocking Configuration

Network Clock Services for CES Operations and CBR Traffic

Planning for Network Clocking

Clocking Modes for CES Operations

Other Factors Relevant to CES Operations

Configure Network Clock Priorities and Sources

To configure the network clocking priorities and sources, use the following command in global configuration mode:

Command
Task

network-clock-select priority {atm | cbr} {system1 | card/subcard/port} [revertive]

Configure the network clock.

1 Selects the ASP reference clock.


Examples

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

Switch# config term
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 the Transmit Clocking Source

To configure where an interface receives its transmit clocking, perform the following tasks, beginning in global configuration mode:

Step
Command
Task
1

interface atm card/subcard/port

Select the interface to be configured.

2

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

Configure the interface network clock source.


Example

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 the Network Clocking Configuration

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

Command
Task

show network-clocks

Show the network clocking configuration.

show running-config

Show the interface clock source configuration.

show controllers [atm card/subcard/port]

Show the interface controller status.


Examples

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

Switch# show network-clocks
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

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

Switch# show running-config
Building configuration...

Current configuration:
!
version ZZ.X
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/ls1010-wp-mz.11X-X.X.WA4.X.XX
!
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>

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

Network Clock Services for CES Operations and CBR Traffic

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 ATM switch 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 overflow or underflow, resulting in periodic line errors.

The CES modules have been designed specifically to handle CBR traffic in an ATM networking environment. To provide 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 ATM switch 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.

Planning 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, a common clocking signal to be used by CBR devices

Up to three alternative clocking sources if the primary reference source fails

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.

Network Clocking Signal Sources

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 ATM switch 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 ATM switch 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 ATM switch 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 a major telephone carrier is often the timing signal of choice, because such signals are known to be highly stable, reliable, and accurate.

Clock Synchronization Services

Any module in a LightStream 1010 ATM switch chassis capable of receiving and distributing a network timing signal can propagate that signal to any similarly capable module in the chassis.The following entities are capable of receiving and distributing a PRS:

A CES module in a LightStream 1010 ATM switch chassis

An OC-3 or OC-12 PAM in a LightStream 1010 ATM switch chassis

A quad DS-3 module in a LightStream 1010 ATM switch 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.


By issuing the network-clock-select command with appropriate parameters, you can define a particular port in a LightStream 1010 ATM switch 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."

You can also use the network-clock-select command to designate a particular port in a LightStream 1010 ATM switch 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.

Clocking Modes for CES Operations

For CES operations and CBR traffic, as noted earlier, three locking modes can be used with any CES module. Table 4-2 summarizes, in order of preference, the characteristics of the three clocking modes available for handling CBR traffic in a LightStream 1010 ATM switch networking environment.

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 a PRS and 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 a PRS and network clock synchronization services.

Supports only unstructured (clear channel) CBR traffic.

Exhibits moderate wander characteristics.

Adaptive

Does not require a PRS or network clock synchronization services.

Supports only unstructured (clear channel) CBR traffic.

Exhibits poorest wander characteristics.


Although the wander and jitter characteristics of these clocking modes differ, all clocking modes preserve the integrity of the your CBR data, ensuring error-free data transport from source to destination. However, there are important differences, summarized as follows:

Synchronous 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. In addition, synchronous clocking is typically used in public telephony systems, making a precision reference signal readily and widely available for synchronizing CBR data transport.

SRTS clocking mode allows user equipment at the edges of a network to use a clocking signal that is different (and completely independent) from the clocking signal being used in the ATM network. 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 reconciles these different timing signals in the course of CBR data transport through the ATM network.

Adaptive clocking mode, though the simplest and easiest to implement in an ATM network, exhibits the poorest wander and jitter performance of all the available clocking modes. Therefore, its use is not recommended, except where a PRS and network clock synchronization services are not available.

The three clocking modes are described in greater detail in the following sections, " Synchronous Clocking," " SRTS Clocking," and " Adaptive Clocking."

Synchronous Clocking

When equipped with a CES module and appropriate software, any LightStream 1010 ATM switch can:

Receive and distribute a PRS to other devices in the network

Synchronize the flow of user CBR traffic through the network

shows that a LightStream 1010 ATM switch can use a PRS that originates from any one of four possible sources. However, this does not 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 ATM switch operating environment.

The important concepts shown in Figure 4-5 include the following:

Up to four clocking signals can be defined per LightStream 1010 ATM switch chassis in the network.

Each LightStream 1010 ATM switch 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 ATM switch chassis in the network.

Figure 4-5 Synchronous Clocking Sources in ATM Network

Note that each PRS in is externally generated—that is, the timing signal originates from a source outside the ATM network. 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, the network clock synchronization service automatically recovers network timing by using the priority 2 PRS available from another source.

Assume that the T1/E1 trunk at the top of Figure 4-5 is currently supplying a priority 1 PRS to the network. If the PRS fails, 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 is active at the time.

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

In this network scenario, a PRS is available to the network by 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-6 Synchronous Clocking in a LightStream 1010 ATM switch Network

See the preceding sections for clocking configuration examples:

Configure Network Clock Priorities and Sources

Configure the Transmit Clocking Source

Display the Network Clocking Configuration

SRTS 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. Figure 4-7 shows such an operating scenario, in which a timing signal is provided to edge nodes independently from the ATM network.

Figure 4-7 SRTS Clocking in a LightStream 1010 ATM switch Network

Using Figure 4-7, 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.

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

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

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

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

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 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 the Hard PVC with Adaptive Clocking" in the chapter " ."

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 chapter " " in the section " Configure T1/E1 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 the Network Routing

The default software image for the LightStream 1010 ATM switch contains the PNNI routing protocol. The PNNI protocol provides the route dissemination mechanism for complete plug-and-play capability. The following section, " Configure ATM Static Routes for IISP or PNNI," describes modifications that can be made to the default PNNI or Interim-Interswitch Signalling Protocol (IISP) routing configurations.

For a detailed description of these routing protocols see the section " ATM Routing" in the chapter " ." For detailed configuration information, see the chapters " " and " ."

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.


The following example shows how to use the atm route command to configure the 13-byte peer group prefix = 47.0091.8100.567.0000.0ca7.ce01 at interface 3/0/0:

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

Configuring 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, beginning in privileged EXEC mode:

Step
Command
Task
1

clock set hh:mm:ss day month year

Set the system clock.

2

configure
[terminal]

Enter global configuration mode from the terminal.

3

hostname name

Set the system name.


Examples

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

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

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

Switch# configure terminal
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#

Configuring SNMP Management

SNMP is an application-layer protocol that allows the SNMP manager and agent to communicate. SNMP provides a message format for sending information between an SNMP manager and an SNMP agent. The SNMP system consists of three parts:

SNMP manager

SNMP agent

Management Information Bases (MIBs)

The SNMP manager can be part of a network management system (NMS), such as CiscoWorks.

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.

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-8 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).

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:

Configuring for both SNMPv1 and SNMPv2

Configuring SNMPv2 Support

Configuring SNMPv1 Support

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.

Configuring 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

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

Define the Maximum SNMP Agent Packet Size

Monitor SNMP Status

Disable the SNMP Agent

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, use the following command in global configuration mode:

Command
Task

snmp-server system-shutdown

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


To understand how to use this feature with SNMP requests, read the document mib.txt available by anonymous FTP from Cisco Connection Online.

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. Use one or more of the following commands in global configuration mode:

Command
Task

snmp-server contact text

Set the system contact string.

snmp-server location text

Set the system location string.

snmp-server chassis-id text

Set the system serial number.


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, use the following command in global configuration mode:

Command
Task

snmp-server packetsize byte-count

Establish the maximum packet size.


Monitor SNMP Status

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

Command
Task

show snmp

Monitor SNMP status.


Disable the SNMP Agent

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

Command
Task

no snmp-server

Disable SNMP agent operation.


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

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

To configure support for SNMv2, perform the following tasks:

Create or Modify an SNMP View Record

Create or Modify an SNMP Context Record

Create or Modify an SNMPv2 Party Record

Create an SNMPv2 Access Policy

Define SNMPv2 Trap Operations

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, use the following command in global configuration mode

Command
Task

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

Create or modify a view record.


:

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, use the following command in global configuration mode:

Command
Task

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

Create or modify a context record.


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, use the following command in global configuration mode

Command
Task

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

Create or modify a party record.


:

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, use the following command in global configuration mode:

Command
Task

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

Create or modify an access policy.


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 SNMPv2 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, use one or more of the following commands in global configuration mode:

Command
Task

snmp-server trap-source interface

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

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

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

snmp-server trap-authentication [snmpv1 | snmpv2]

Establish trap message authentication.

snmp-server trap-timeout seconds

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

snmp-server queue-length length

Establish the message queue length for each trap host.


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.

Configuring 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, perform the tasks in the following sections:

Create or Modify Access Control for an SNMPv1 Community

Define SNMP Trap Operations for SNMPv1

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, use the following command in global configuration mode:

Command
Task

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

Define the community access string.


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

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

Step
Command
Task
1

snmp-server trap-source interface

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

2

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

Specify the recipient of the trap message.

3

snmp-server trap-authentication [snmpv1 | snmp2]

Establish trap message authentication.

5

snmp-server trap-timeout seconds

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

6

snmp-server queue-length length

Establish the message queue length for each trap host.


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.

Configuring SNMP RMON Support

Remote Monitoring (RMON) 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.

Cisco IOS software images are available in versions with or without the explicit RMON option. Images without the explicit RMON option include limited RMON support (RMON alarms and event groups only). Images 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 " " for ATM RMON configuration.


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

Command
Task

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

Set an alarm on a MIB object.

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

Add or remove an event in the RMON event table.


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, use the following EXEC commands:

Command
Task

show rmon

or

show rmon task

Display general RMON statistics.

show rmon alarms

Display the RMON alarm table.

show rmon events

Display the RMON event table.


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.

Storing 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 ATM switch prior to saving the configuration in NVRAM, all manual configuration changes are lost. An example of the copy running-config command follows:

Switch# copy running-config startup-config
Building configuration...
[OK]

For detailed configuration storage information see the section " Storing System Images and Configuration Files" in the chapter " ."

Testing 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:

Confirm the Hardware Configuration

Confirm the Software Version

Confirm Power-on Diagnostics

Confirm the Ethernet Configuration

Confirm the ATM Address

Test the Ethernet Connection

Confirm the ATM Connections

Confirm the ATM Interface Configuration

Confirm the Interface Status

Confirm Virtual Channel Connections

Confirm the Running Configuration

Confirm the Saved Configuration


Note   The following examples differ depending on the feature card installed on the ASP.


Confirm the Hardware Configuration

Use the show hardware command to confirm the correct hardware installation:

Switch# show hardware

LS1010 named ls1010_c5500, Date: 15:07:56 UTC Thu Jan 8 1998
Feature Card's FPGA Download Version: 10

Slot Ctrlr-Type    Part No.  Rev  Ser No  Mfg Date   RMA No. Hw Vrs  Tst EEP
---- ------------  ---------- -- -------- --------- -------- ------- --- ---
0/0  T1 PAM        12-3456-78 00 00000022 Aug 01 95 00-00-00   0.4     0   2
0/1  T1 PAM        12-3456-78 00 00000025 Aug 01 95 00-00-00   0.4     0   2
1/0  155MM PAM     73-1496-03 06 02180446 Jan 17 96 00-00-00   3.0     0   2
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 00 02180455 Jan 17 96 00-00-00   3.0     0   2
2/0  ATM Swi/Proc  73-1402-06 D0 07202996 Dec 20 97 00-00-00   4.1     0   2
2/1  FeatureCard1  73-1405-05 B0 07202788 Dec 20 97 00-00-00   3.2     0   2

DS1201 Backplane EEPROM:
Model  Ver.  Serial  MAC-Address  MAC-Size  RMA  RMA-Number   MFG-Date
------ ---- -------- ------------ --------  ---  ----------  -----------
LS1010  2   69000050 00400B0A2E80   256      0        0      Aug 01 1995

Confirm the Software Version

Use the show version command to confirm the correct version and type of software and the configuration register are installed:

Switch# show version
Cisco Internetwork Operating System Software
IOS (tm) PNNI Software (LS1010-WP-M), Version XX.X(X), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1998 by cisco Systems, Inc.
Compiled Tue 07-Jan-98 04:53 by
Image text-base: 0x60010910, data-base: 0x604E6000
ROM: System Bootstrap, Version XX.X(X.X.WA4.X) [integ X.X.WA4.X], RELEASE SOFTWARE
Switch uptime is 2 weeks, 2 days, 39 minutes
System restarted by power-on
System image file is "bootflash:ls1010-wp-mz.XXX-X.X.X.FWA4.X.XX", 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

Confirm Power-on Diagnostics

Use the show diag power-on command to confirm the power-on diagnostics:

Switch# show diag power-on
LS1010 Power-on Diagnostics Status (.=Pass,F=Fail,U=Unknown,N=Not Applicable)
-----------------------------------------------------------------------------
   Last Power-on Diags  Date: 97/12/29   Time: 16:27:18   By: V 3.40

   BOOTFLASH:  .   PCMCIA-Slot0: .   PCMCIA-Slot1: .
   CPU-IDPROM: .   FCard-IDPROM: .   NVRAM-Config: .
   SRAM:       .   DRAM:         .

   PS1:        N   PS2:          N   PS (12V):     .
   FAN:        .   Temperature:  .   Bkp-IDPROM:   .

   MMC-Switch Access: .              Accordian Access: .
   LUT: .   ITT: .   OPT: .   OTT: .   STK: .   LNK: .   ATTR: .   Queue: .
   Cell-Memory:  .

   Feature-Card Access: .
   ICC: .   OCC: .   OQP: .   OQE: .   CC:  .   RT:  .
   TM0: .   TM1: .   TMC: .   IT:  .   LT:  .   RR:  .   ABR: .

Access/Interrupt/Loopback/CPU-MCast/Port-MCast/FC-MCast/FC-TMCC Test Status:
Ports                      0         1         2         3
----------------------------------------------------------------------------

   Ethernet-port Access:   .         Ethernet-port CAM-Access: .
   Ethernet-port Loopback: .         Ethernet-port Loadgen:    .

Power-on Diagnostics Passed.

Confirm the Ethernet Configuration

Use the show interface ethernet command to confirm the ethernet interface on the ASP is configured correctly:

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

Confirm the ATM Address

Use the show atm addresses command to confirm correct configuration of the ATM address for the LightStream 1010 ATM switch:

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):

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

Command
Task

ping ip ip_address

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


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 displays:

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

Confirm the ATM Connections

Use the ping atm command to confirm that the ATM interfaces are configured correctly:

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#

Confirm the ATM Interface Configuration

Use the show atm interface command to confirm the atm interfaces are configured correctly:

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#

Confirm the Interface Status

Use the show atm status command to confirm the status of ATM interfaces:

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#

Confirm Virtual Channel Connections

Use the show atm vc command to confirm the status of ATM virtual channels:

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:

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.

The following example shows the display output with feature card per-class queueing (FC-PCQ) installed:

Switch# show atm vc interface atm 1/0/0 83 93

Interface: ATM1/0/0, Type: oc3suni
VPI = 83  VCI = 93
Status: UP
Time-since-last-status-change: 00:00:40
Connection-type: PVC
Cast-type: point-to-point
Packet-discard-option: disabled
Usage-Parameter-Control (UPC): pass
Number of OAM-configured connections: 0
OAM-configuration: disabled
OAM-states:  Not-applicable
Cross-connect-interface: ATM3/0/0, Type: oc3suni
Cross-connect-VPI = 19
Cross-connect-VCI = 67
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
Rx cells: 0, Tx cells: 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      cdvt: 1024 (from default for interface)
Rx       mbs: none
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      cdvt: none
Tx       mbs: none

Switch#

The following example shows the display output with feature card per-flow queueing (FC-PFQ) installed:

Switch# show atm vc interface atm 1/1/0 77 42
Interface: ATM1/1/0, Type: oc3suni
VPI = 77  VCI = 42
Status: UP
Time-since-last-status-change: 00:27:54
Connection-type: PVC
Cast-type: point-to-point
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: ATM1/0/0, Type: oc3suni
Cross-connect-VPI = 100
Cross-connect-VCI = 90
Cross-connect-UPC: pass
Cross-connect OAM-configuration: disabled
Cross-connect OAM-state:  Not-applicable
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      cdvt: 1024 (from default for interface)
Rx       mbs: none
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      cdvt: none
Tx       mbs: none

Switch#

Confirm the Running Configuration

Use the show running-configuration command to confirm that the configuration being used is configured correctly:

Switch# show running-config
Building configuration...

Current configuration:
!
version XX.X
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
interface CBR0/0/0
 no ip address
!
<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
!
line con 0
line aux 0
 monitor
line vty 0 4
 login
!
end

Switch#

Confirm the Saved Configuration

Use the show startup-configuration command to confirm that the configuration saved in NVRAM is configured correctly:

Switch# show startup-config
Using 2026 out of 129016 bytes
!
version XX.X
no service pad
service udp-small-servers
service tcp-small-servers
!
hostname Switch
!
boot bootldr bootflash:/tftpboot/rbhide/ls1010-wp-mz.XXX-X.X.WA4.X.XX
!
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#