Table of Contents

Methods for Configuring the DSLAM
Port and Slot Configuration
Configuration Prerequisites
Verifying Installed DSLAM Software and Hardware
Configuring the BOOTP Server
Setting the Subtend Node Identifier
Configuring the ATM Address
Configuring ATM Addressing

Using the ATM Default Addressing Scheme
Manually Setting the ATM Address

Modifying the Physical Layer Configuration of the Default ATM Interface
Configuring IP Interface Parameters

Defining an IP address
Defining Subnet Mask Bits

Testing the Ethernet Connection
Configuring Network Clocking

Configuring Network Clock Priorities and Sources
Configuring the Transmit Clocking Source
Providing Clock Synchronization Services

Configuring the Network Routing
Configuring NI-2 Card and APS Link Redundancy

NI-2 Card Redundancy Overview

NI-2 Cold Redundancy
Automatic Protection Switching
Restrictions

Supported Platforms
Prerequisites
Configuration Tasks

Configure the NI-2 Cards for File Synchronization
Verifying File Synchronization
Troubleshooting Tips

Monitoring Redundancy States
Configuration Examples

Configuring the Time, Date, and System Name
Configuring SNMP Management

Understanding SNMP

SNMP Notifications
MIBs and RFCs
SNMP Versions

SNMP Configuration Task List

Creating or Modifying an SNMP View Record
Creating or Modifying Access Control for an SNMP Community
Specifying an SNMP-Server Engine Name (ID)
Specifying SNMP-Server Group Names
Configuring SNMP-Server Hosts
Configuring SNMP-Server Users
Setting the Contact, Location, and Serial Number of the SNMP Agent
Defining the Maximum SNMP Agent Packet Size
Limiting the Number of TFTP Servers Used via SNMP
Monitoring and Troubleshooting SNMP Status
Disabling the SNMP Agent
Configuring SNMP Notifications
Configuring the DSLAM to Send SNMP Notifications
Changing Notification Operation Values
Controlling Individual RFC 1157 SNMP Traps
Configuring the DSLAM as an SNMP Manager
Security Considerations
SNMP Sessions
Enabling the SNMP Manager
Monitoring the SNMP Manager

SNMP Configuration Examples
MIB Features in Cisco IOS Release 12.2DA

Standard MIB Modules
Cisco Enterprise MIB Modules

Storing the Configuration
Testing the Configuration

Confirming the Hardware Configuration
Confirming the Software Version
Confirming the Ethernet Configuration
Confirming the ATM Address
Testing the Ethernet Connection
Confirming the ATM Connections
Confirming the ATM Interface Configuration
Confirming the Interface Status
Confirming Virtual Channel Connections
Confirming the Running Configuration
Confirming the Saved Configuration

Initially Configuring the Cisco DSLAM

This chapter describes how to initially configure the Cisco DSLAMs, and includes these sections:

• Methods for Configuring the DSLAM
  
  
• Port and Slot Configuration
  
  
• Configuration Prerequisites
  
  
• Verifying Installed DSLAM Software and Hardware
  
  
• Configuring the BOOTP Server
  
  
• Setting the Subtend Node Identifier
  
  
• Configuring ATM Addressing
  
  
• Modifying the Physical Layer Configuration of the Default ATM Interface
  
  
• Configuring IP Interface Parameters
  
  
• Testing the Ethernet Connection
  
  
• Configuring Network Clocking
  
  
• Configuring the Network Routing
  
  
• Configuring NI-2 Card and APS Link Redundancy
  
  
• Configuring the Time, Date, and System Name
  
  
• Configuring SNMP Management
  
  
• Storing the Configuration
  
  
• Testing the Configuration
  
  

Methods for Configuring the DSLAM

The Cisco DSLAM default configuration is suitable for operation with most networks. By using network management applications and the text-based command-line interface (CLI), you can configure and customize all aspects of DSLAM operation to suit your needs.

The Cisco DSLAM ships with the ATM address autoconfigured, allowing the DSLAM to accomplish the following tasks:

• Automatically configure attached end systems using the Interim Local Management Interface (ILMI) protocol.
  
  
• Establish itself as a node in a single-level Private Network to Network Interface (PNNI) routing domain.
  
  

The ILMI and PNNI protocols allow the DSLAM to be entirely self-configured when you use these protocols with an IP address autoconfiguration mechanism such as BOOTP.

You must assign an IP address to allow up to eight simultaneous Telnet sessions to connect to the DSLAM or to use the Simple Network Management Protocol (SNMP) system for the DSLAM. The Ethernet IP address is assigned either manually or by a BOOTP server. See the "Configuring IP Interface Parameters" section.

You can use either of two methods for configuring a DSLAM (see Figure 3-1):

• From a local console or workstation—Connect to the console port or connect to the Ethernet port of a DSLAM. This connection allows you to issue CLI commands directly to the DSLAM chassis.
  
  
• From a remote console or workstation—Initiate a Telnet connection to a target DSLAM. Telnet allows you to remotely issue CLI commands to that chassis.
  
  

Port and Slot Configuration

The DSLAM contains an NI-2 card and up to 32 line (modem) cards depending on the DSLAM. The slot configurations on the different DSLAMs are as follows:

• Cisco 6015 DSLAM
  
  
• Six line card slots
  
  
• One NI-2 card slot
  
  
• Cisco 6100 DSLAM
  
  
• 32 line card slots
  
  
• Two NI-2 card slots (only one slot active)
  
  
• Cisco 6130 DSLAM
  
  
• 32 line card slots
  
  
• Two NI-2 card slots (to provide redundancy)
  
  
• Cisco 6160 DSLAM
  
  
• 32 line card slots
  
  
• Two NI-2 card slots (to provide redundancy)
  
  
• Cisco 6260 DSLAM
  
  
• 30 line card slots
  
  
• Two NI-2 card slots (to provide redundancy)
  
  

Table 3-1 lists the NI-2 cards that can be installed in each of the DSLAM chassis, as well as the associated product numbers.

Line cards are assigned ports 1 to 4 or 1 to 8 in consecutive slots. Table 3-2 lists NI-2 port assignments. See the Hardware Installation Guide for your specific DSLAM system for more detailed information about possible subtending topologies.

Configuration Prerequisites

Obtain this information before you configure your DSLAM:

• To configure a BOOTP server to inform the DSLAM of its Ethernet IP address and mask, you need the Media Access Control (MAC) address of the Ethernet port.
  
  
• To configure a new ATM address for the DSLAM (an autoconfigured ATM address is assigned by Cisco), you need an ATM address assigned by your system administrator.
  
  
• If you are not using BOOTP, obtain an IP address and a subnet mask.
  
  

Verifying Installed DSLAM Software and Hardware

When you first power on your console and DSLAM, a screen similar to the following example appears:

The script then displays the banner information, including the software version, followed by the installed hardware configuration.

Configuring the BOOTP Server

BOOTP 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 DSLAM boots, it automatically retrieves the IP address from the BOOTP server.

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

To allow the DSLAM to retrieve its IP address from a BOOTP server you must first determine the MAC address of the DSLAM and then add that MAC address to the BOOTP configuration file on the BOOTP server.

Complete the following tasks to create a BOOTP server configuration file:

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

Step 2   Determine the MAC address from the label on the chassis.

Step 3   Add an entry in the BOOTP configuration file (usually /usr/etc/bootptab) for each DSLAM. Press Enter after each entry to create a blank line between each entry. See the sample BOOTP configuration file that follows this step list.

Step 4   Restart the DSLAM to automatically request the IP address from the BOOTP server.

Example

This example of a BOOTP configuration file shows the newly added DSLAM entry:

Setting the Subtend Node Identifier

In a subtended network configuration, the head node acts as the host node connecting all the nodes to the network. The head node at the top of the subtend tree—that is, the node that is connected to the trunk—must have the subtend ID 0. (Subtend ID 0 is the default.)

You identify the node to the network with the subtend-id command. You must assign a unique subtend ID to each node in a subtend tree so that all subtended nodes have fair access to the trunk port of the head node.

To set the subtend node identifier, use the following command:

Example

In this example, the DSL subtend node identifier is set to node 12:

Configuring the ATM Address

The DSLAM is autoconfigured with an ATM address that uses 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   If you manually change an ATM address, you must maintain the uniqueness of the address across the network.

Configuring ATM Addressing

This section describes the ATM addressing scheme and tells you how to accomplish the following tasks:

• Using the ATM Default Addressing Scheme
  
  
• Manually Setting the ATM Address
  
  

Using the ATM Default Addressing Scheme

This section describes the default addressing scheme and the features and implications of using this scheme.

During the initial startup, the DSLAM generates an ATM address using the defaults shown in Figure 3-2.

The default addressing scheme includes:

• 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). 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). Both the DSLAM ID and ESI 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. Use the ATM address fields when you configure the ATM addressing scheme.
  
  
• Selector (SEL) equals 0—1 byte
  
  

If you use the default address format, the following features and implications apply:

• 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.
  
  
• You can assign the same MAC address for bytes 8 through 13 and bytes 14 through 19.
  
  
• To achieve scalable ATM routing, you need two addresses when you connect to a large ATM network with multiple levels of PNNI hierarchy.
  
  
• Do not use summary addresses with fewer than 13 bytes with autoconfigured ATM addresses. Other switches with autoconfigured ATM addresses that match the DSLAM summary can exist outside of the default peer group.
  
  

Manually Setting the ATM Address

You can configure a new ATM address that replaces the previous ATM address when running IISP software only, or that replaces the previous ATM address and generates a new PNNI node ID and peer group ID as follows:

• To configure a new ATM address that replaces the previous ATM address when running IISP software only, see the ATM Switch Router Software Configuration Guide, Chapter 10.
  
  

http://www.cisco.com/univercd/cc/td/doc/product/atm/c8540/12_1/lhouse/sw_confg/ilmi_cnf.htm

• 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 ATM Switch Router Software Configuration Guide, Chapter 11.
  
  

http://www.cisco.com/univercd/cc/td/doc/product/atm/c8540/12_1/lhouse/sw_confg/access.htm

You can configure multiple addresses for a single switch and use this configuration during ATM address migration. ILMI registers end systems with multiple prefixes during this period until you remove an old address. 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 automatically adds one of the 6-byte switch MAC addresses in the ESI portion and 0 in the selector portion of the address.

Caution   ATM addressing can lead to conflicts if you do not configure it correctly. For example, when configuring a new ATM address, you must remove the old one from the configuration.

When the switch initially powers on without previous configuration data, the ATM interfaces configure automatically on the physical ports. The DSLAM uses ILMI and the physical card type to automatically derive the following information:

• ATM interface type
  
  
• UNI version
  
  
• Maximum virtual path identifier (VPI) and virtual channel identifier (VCI) bits
  
  
• ATM interface side
  
  
• ATM UNI type
  
  

You can accept the default ATM interface configuration or overwrite the default interface configuration using the CLI commands (see the ATM Switch Router Software Configuration Guide, Chapter 5, Configuring ATM Network Interfaces ).

Modifying the Physical Layer Configuration of the Default ATM Interface

This section describes how to modify an ATM interface from the default configuration listed in "Configuring In-Band Management." You can accept the ATM interface configuration or overwrite the default interface configuration using the CLI commands, which are described in ATM Switch Router Software Configuration Guide, Chapter 6, Configuring Virtual Connections .

Example

This example shows how to modify an OC-3 interface from the default settings to:

• Disable scrambling cell-payload.
  
  
• Disable scrambling STS-streaming.
  
  
• Change the 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 an ATM interface, follow these steps:

Example

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

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

Example

In this example, the OC-3 physical interface configuration is displayed after you modify the defaults:

In this example, the OC-3 physical layer configuration is displayed after you modify the defaults:

Configuring IP Interface Parameters

This section describes how to configure IP addresses on the DSLAM processor interfaces. You configure each IP address for one of the following types of connections:

• Ethernet port—Configure either from the BOOTP server or by using the ip address command in interface-configuration mode for the Ethernet 0/0 interface.
  
  
• Serial Line Internet Protocol/Point-to-Point Protocol (SLIP/PPP)—See "Configuring Terminal Lines and Modem Support."
  
  

---

Note   These IP connections are used only for network management.

---

To configure the DSLAM to communicate using the Ethernet interface, provide the IP address and subnet mask bits for the interface as described in this section.

Defining an IP address

This section provides a summary of IP addressing concepts for those who are familiar with IP addressing.

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.

IP addresses are divided into three classes. These classes differ in the number of bits allocated to the network and host portions of the address:

• The Class A Internet address format allocates the highest 8 bits to the network field and sets the highest-order bit to 0 (zero). The remaining 24 bits form the host field.
  
  
• The Class B Internet address allocates the highest 16 bits to the network field and sets the two highest-order bits to 1, 0. The remaining 16 bits form the host field.
  
  
• The Class C Internet address allocates the highest 24 bits to the network field and sets the three highest-order bits to 1, 1, 0. The remaining 8 bits form the host field.
  
  

The default IP address is none.

Enter your Internet address in dotted decimal format for each interface you plan to configure.

Defining Subnet Mask Bits

Subnetting is an extension of the Internet addressing scheme that allows multiple physical networks to exist within a single Class A, B, or C network. The subnet mask determines whether subnetting is in effect on a network. The usual practice is to use a few of the far-left bits in the host portion of the network address to assign a subnet field.

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.

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

Table 3-3 provides a summary of subnetting parameters.

You define subnet mask bits as a decimal number between:

• 0 and 22 for Class A addresses
  
  
• 0 and 14 for Class B addresses
  
  
• 0 and 6 for Class C addresses
  
  

---

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

Example

This example shows how to configure the Ethernet CPU interface 0/0 with IP address 172.20.40.93 and subnetwork mask 255.255.255.0, and displays the interface information:

Testing the Ethernet Connection

After you configure the IP addresses for the Ethernet interface, test for connectivity between the DSLAM and a host. The host can reside anywhere in your network. To test for Ethernet connectivity, use this command in EXEC mode:

For example, to test Ethernet connectivity from the DSLAM to a workstation with an IP address of 172.20.40.201, enter the command ping ip 172.20.40.201. If the DSLAM receives a response, this message appears:

Configuring Network Clocking

This section describes how to configure network clocking for the DSLAM. Each port has a transmit clock and derives its receive clock from the receive data. You can configure transmit clocking for each port in one of these ways:

• Network derived—Transmit clocking is derived from the highest priority configured source, either from the internal clock (the default) or the public network.
  
  
• Loop-timed—Transmit clocking is derived from the receive clock source.
  
  

The DSLAM receives derived clocking, along with data, from a specified interface. For example, in Figure 3-3, the DSLAM extracts transmit clocking from the data received at ATM 0/1 and distributes it as the transmit clock to the rest of the DSLAM. ATM 0/2 then uses network-derived transmit clocking received from ATM 0/1.

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

If the network clock source interface stops responding, the software switches to the next highest-configured priority network clock source. For example, Figure 3-4 shows:

• DSLAM number two is configured to use ATM 0/2 as its highest-priority clock source, and an external reference clock as its second highest-priority clock source.
  
  
• ATM 0/1 uses network-derived transmit clocking.
  
  
• ATM 0/2 fails.
  
  
• The external reference clock becomes the active clock signal and is distributed to the WAN ports and line cards. ATM 0/1 uses the external reference clock.
  
  
• If the configuration option network-clock-select revertive is set, the DSLAM continuously attempts to revert to the valid clock source with the highest priority. To be considered valid, a clock source must remain stable for a least 1 minute.
  
  

---

Note   By default, the network clock is nonrevertive. Nonrevertive means that once a network clock source fails and the DSLAM switches to the clock source with the next highest priority, manual intervention is required to force the DSLAM to switch back to a higher-priority clock source. The algorithm to switch to the highest priority best clock only runs if you configure the network-clock-select command as revertive.

---

These sections describe network clocking:

• Configuring Network Clock Priorities and Sources
  
  
• Configuring the Transmit Clocking Source
  
  
• Providing Clock Synchronization Services
  
  

Configuring Network Clock Priorities and Sources

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

Examples

This example sets up the DSLAM building-integrated time source (BITS) interface as the highest-priority clock source, then configures the BITS interface for T1 at 0.6 dB (0 to 133 feet, or 0 to 40.5 meters).

This example configures ATM 0/1, the trunk, as the second-highest priority timing source.

This example configures the DSLAM system clock as the third-highest priority timing source.

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

Configuring the Transmit Clocking Source

To configure the location from which an interface receives its transmit clocking, perform the following steps, beginning in global configuration mode:

Note   When an interface has its clock source set to Network-Derived, the interface uses the highest-priority valid clock source available (assuming that the network clock source is configured to be revertive).

Examples

This example configures ATM 0/1 to receive its transmit clocking from a network-derived source:

This example displays the network clocking configuration shown in Figure 3-4:

This example displays the clock source configuration of ATM 0/2:

Providing Clock Synchronization Services

Any module in a DSLAM chassis capable of receiving and distributing a network timing signal can propagate that signal to any similarly capable module in the chassis. These modules are capable of receiving and distributing a primary reference source (PRS) for the clock:

• A BITS clock through the I/O card
  
  
• An OC-3 in a DSLAM chassis
  
  
• A quad DS3 module in a DSLAM chassis that derives the clock from the trunk interface
  
  

---

Note   A trunk port can propagate a clocking signal in either direction.

---

If you issue the network-clock-select command with the appropriate parameters, you can define a particular port in a DSLAM chassis (subject to the above limitations) 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 "Configuring Network Clock Priorities and Sources" section.

You can also use the network-clock-select command to designate a particular port in a DSLAM chassis to serve as a master clock source for distributing a single clocking signal throughout the chassis or to other network devices. You can distribute this reference signal in any location the network needs to globally synchronize the flow of constant bit rate (CBR) data.

Configuring the Network Routing

For network routing, the default software image for the DSLAM contains the PNNI routing protocol. The PNNI protocol provides the route dissemination mechanism for complete plug-and-play capability. This section describes modifications you can make to the default PNNI or Interim-Interswitch Signaling Protocol (IISP) routing configurations.

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 if it is configured with a static route. Static routes configured as PNNI interfaces default as down.

Example

This example shows how to use the atm route command to configure the 13-byte peer group prefix as 47.0091.8100.567.0000.0ca7.ce01 at ATM 0/1:

Configuring NI-2 Card and APS Link Redundancy

This section describes how to configure redundancy for the NI-2 card and APS link and includes the following information:

• NI-2 Card Redundancy Overview
  
  
• Supported Platforms
  
  
• Prerequisites
  
  
• Configuration Tasks
  
  
• Monitoring Redundancy States
  
  
• Configuration Examples
  
  

NI-2 Card Redundancy Overview

The NI-2 Card redundancy feature provides redundancy on the Cisco 6130, Cisco 6160, and Cisco 6260 DSLAM systems. This redundancy feature has two main components.

• Recovery from failure on an NI-2 card lets the standby card take over if the active card fails.
  
  
• Recovery from failure due to a cut fiber or the failure of an optical transmitter or receiver (SONET APS) lets the active NI-2 switch to the fiber interface on the standby NI-2.
  
  

NI-2 Cold Redundancy

On a system with two NI-2 cards of the same interface types (trunk and subtend), the NI-2 cold redundancy feature allows a standby NI-2 card to assume system operations if the active NI-2 card completely fails. The NI-2 card in slot 10 is called the primary card and the card in slot 11 is called the secondary card. Either card can be active or standby.

The standby NI-2 begins the boot process but does not process its configuration. While the standby unit is monitoring the state of the active unit, the active unit synchronizes configuration changes with the standby unit if it is configured to do so. This allows the standby unit to become active with the most recent configuration possible following a switchover. Configuration information could be lost during the switchover if configuration synchronization is disabled.

The switchover from one NI-2 to the other NI-2 does not cause a reset of the line cards. The active unit communicates line card information to the standby unit to decrease switchover time. When the switchover is complete, the object database on the newly active unit may not match the objects in the system, but this situation will correct itself during normal operation as the active unit discovers the new cards or discovers that cards have been removed.

Automatic Protection Switching

SONET APS provides recovery from a cut fiber or the failure of an optical transmitter or receiver for OC-3 interfaces on an NI-2 card. APS redundancy is available on OC-3c/2DS3 NI-2 card trunk interfaces and OC-3c/OC-3c NI-2 card trunk and subtend interfaces. The active interface switches over when a SONET failure condition (loss of signal or loss of frame) is detected.

When both primary and secondary fiber connections are cabled, the active NI-2 card transmits and receives identical data signals over both fiber connections and can switch the receive path between the two upon a fiber or OC-3c port failure.

APS fiber redundancy is nonrevertive. The NI-2 will switch back to the primary fiber only if manually forced through a CLI command or if a failure condition occurs on the secondary fiber. If both fibers are failed, the system will switch to the first good fiber that is available.

Restrictions

Cold redundancy is redundancy in which the standby unit does not completely mirror the state of the active unit. With cold redundancy, the standby unit loses transient state information and must process its configuration during the switchover, which may lead to a period of data loss.

Cisco recommends testing the redundancy feature in the local test environment before placing the unit in production.

Supported Platforms

Table 3-4 lists the NI-2 cards and compatible chassis that support cold redundancy.

Ensure that the following product revisions are installed on your system:

• Cisco NI-2 card, daughterboard item number 73-3952-05 Rev. AO or later. Use the Cisco IOS command show hardware slot 10 or show hardware slot 11 to determine the currently installed NI-2 card daughterboard item number and revision.
  
  
• For the Cisco 6260 chassis, Cisco 6260 backplane item number 73-3999-05 Rev. AO or later. Use the Cisco IOS command show hardware chassis to determine the Cisco 6260 backplane item number and revision.
  
  

Prerequisites

To properly configure and activate redundancy, ensure that you are running Cisco IOS Release 12.1(7)DA or a later version of IOS on one of the Supported Platforms. You must install a second NI-2 card (must be the same type as the primary NI-2 card).

Configuration Tasks

Perform the task in the "Configure the NI-2 Cards for File Synchronization" section to configure NI-2 cards and SONET ports.

Configure the NI-2 Cards for File Synchronization

NI-2 cold redundancy supports autosynchronization of the primary and secondary NI-2 card file systems, but you must manually synchronize the flash files and bootflash files before you can enable autosynchronization.

To manually synchronize the flash and bootflash on the NI-2 cards, complete the following steps:

After you manually synchronize the flash and bootflash, configure the NI-2 cards for automatic synchronization. To enable autosynchronization of the primary and secondary NI-2 cards, complete the following steps:

Verifying File Synchronization

Use the show running-config command to verify that you entered the commands correctly. Use the dir flash, dir secondary-flash, dir bootflash, and dir secondary-bootflash commands to verify that the files synchronized properly.

Note   Because the config and running-config synchronizations are enabled by default, they do not show up in the running configuration.

Troubleshooting Tips

Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools.

For Cisco.com registered users, additional troubleshooting tools are available from the TAC website. To obtain troubleshooting help, go to the Cisco Troubleshooting Assistant web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/support/tac/troubleshoot.shtml. Also see the "Monitoring Redundancy States" section.

Monitoring Redundancy States

Use the show redundancy states command to display the current redundancy states of the NI-2 cards.

Use the show aps command to display the APS status of each SONET port on both NI-2 cards.

Configuration Examples

This section provides output from the show running-config command.

Configuring the Time, Date, and System Name

You can set several system parameters as part of the initial system configuration, but these parameters are not required. To set the system parameters, perform the following steps, beginning in privileged EXEC mode:

Examples

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

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

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

Configuring SNMP Management

This section describes the Simple Network Management Protocol (SNMP), SNMP MIBs, and how to configure SNMP on Cisco DSLAMs in the following sections:

• Understanding SNMP
  
  
• SNMP Configuration Task List
  
  
• SNMP Configuration Examples
  
  
• MIB Features in Cisco IOS Release 12.2DA
  
  

Understanding SNMP

SNMP is an application-layer protocol that provides a message format for communication between SNMP managers and agents. SNMP provides a standardized framework and a common language used for the monitoring and management of devices in a network.

The SNMP framework has three parts:

• An SNMP manager
  
  
• An SNMP agent
  
  
• A MIB
  
  

The SNMP manager is the system used to control and monitor the activities of network hosts using SNMP. For Cisco DSLAMS, this system is called the Cisco Digital Subscriber Line (DSL) Manager (CDM) and its associated framework, the Cisco Element Manager Framework (Cisco EMF). A plug-in software module, referred to as an element manager, adds custom graphical user interface (GUI) windows and modeling behavior to the standard Cisco EMF system. Element manager software allows you to manage specific types of network equipment, such as Cisco DSLAMs. Cisco EMF software is the framework that supports the functions of the CDM element manager..

The SNMP agent is the software component within the managed device that maintains the data for the device and reports these data, as needed, to managing systems. The agent and MIB reside on the routing device (DSLAM, access server, or switch). To enable the SNMP agent on a Cisco routing device, you must define the relationship between the manager and the agent.

The Management Information Base (MIB) is a virtual information storage area for network management information, which consists of collections of managed objects. Within the MIB there are collections of related objects, defined in MIB modules. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580 (see the ""MIBs and RFCs" section" for an explanation of RFC and STD documents). Note that individual MIB modules are also referred to as MIBs; for example, the Interfaces Group MIB (IF-MIB) is a MIB module within the MIB on your system.

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

Figure 3-5 illustrates the communications relationship between the SNMP manager and agent. 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 notifications (traps or informs) to the manager to notify the manager of network conditions.

Note   This chapter discusses how to enable the SNMP agent on your Cisco device, and how to control the sending of SNMP notifications from the agent. For information on using SNMP management systems, see the appropriate documentation for your NMS application.

SNMP Notifications

A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Unsolicited (asynchronous) notifications can be generated as traps or inform requests. Traps are messages alerting the SNMP manager to a condition on the network. Inform requests (informs) are traps that include a request for confirmation of receipt from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor DSLAM, or other significant events.

Traps are less reliable than informs because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.

However, traps are often preferred because informs consume more resources in the DSLAM and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, traps and inform requests provide a trade-off between reliability and resources. If it is important that the SNMP manager receives every notification, use inform requests. However, if you are concerned about traffic on your network or memory in the DSLAM and you need not receive every notification, use traps.

Figure 3-6 through Figure 3-9 illustrate the differences between traps and inform requests.

In Figure 3-6, the agent DSLAM successfully sends a trap to the SNMP manager. Although the manager receives the trap, it does not send any acknowledgment to the agent. The agent has no way of knowing that the trap reached its destination.

In Figure 3-7, the agent DSLAM successfully sends an inform request to the manager. When the manager receives the inform request, it sends a response to the agent. Thus, the agent knows that the inform request reached its destination. Notice that, in this example, twice as much traffic is generated as in Figure 3-6; however, the agent knows that the manager received the notification.

In Figure 3-8, the agent sends a trap to the manager, but the trap does not reach the manager. Because the agent has no way of knowing that the trap did not reach its destination, the trap is not sent again. The manager never receives the trap.

In Figure 3-9, the agent sends an inform request to the manager, but the inform request does not reach the manager. Because the manager did not receive the inform request, it does not send a response. After a period of time, the agent will resend the inform request. The second time, the manager receives the inform request and replies with a response. In this example, there is more traffic than in Figure 3-8; however, the notification reaches the SNMP manager.

MIBs and RFCs

MIB modules typically are defined in RFC documents submitted to the Internet Engineering Task Force (IETF), an international standards body. RFCs are written by individuals or groups for consideration by the Internet Society and the Internet community as a whole, usually with the intention of establishing a recommended Internet standard. Before being given RFC status, recommendations are published as Internet Draft (I-D) documents. RFCs that have become recommended standards are also labeled as standards (STD) documents. You can learn about the standards process and the activities of the IETF at the Internet Society website at http://www.isoc.org . You can read the full text of all RFCs, I-Ds, and STDs referenced in Cisco documentation at the IETF website at http://www.ietf.org .

The Cisco implementation of SNMP uses the definitions of MIB II variables described in RFC 1213 and definitions of SNMP traps described in RFC 1215.

Cisco provides its own private MIB extensions with every system. Cisco enterprise MIBs comply with the guidelines described in the relevant RFCs unless otherwise noted in the documentation. You can find the MIB module definition files and list of which MIBs are supported on each Cisco platform on the Cisco MIB website on Cisco.com.

For a list of MIB-related functionality, see the "MIB Features in Cisco IOS Release 12.2DA" section".

SNMP Versions

Cisco IOS software supports the following versions of SNMP:

• SNMPv1—The Simple Network Management Protocol: A Full Internet Standard, defined in RFC 1157. (RFC 1157 replaces the earlier versions that were published as RFC 1067 and RFC 1098.) Security is based on community strings.
  
  
• SNMPv2c—The community-string based Administrative Framework for SNMPv2. SNMPv2c (the "c" stands for "community") is an Experimental Internet Protocol defined in RFC 1901, RFC 1905, and RFC 1906. SNMPv2c is an update of the protocol operations and data types of SNMPv2p (SNMPv2 Classic), and uses the community-based security model of SNMPv1.
  
  
• SNMPv3—Version 3 of SNMP. SNMPv3 is an interoperable standards-based protocol defined in RFCs 2273 to 2275. SNMPv3 provides secure access to devices by a combination of authenticating and encrypting packets over the network.
  
  

The security features provided in SNMPv3 are as follows:

• Message integrity—Ensuring that a packet has not been tampered with in transit.
  
  
• Authentication—Determining that the message is from a valid source.
  
  
• Encryption—Scrambling the contents of a packet prevent it from being learned by an unauthorized source.
  
  

Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers able to access the agent MIB is defined by an IP address Access Control List and password.

SNMPv2c 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 SNMPv2C improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type. Three kinds of exceptions are also reported: no such object exceptions, no such instance exceptions, and end of MIB view exceptions.

SNMPv3 provides for both security models and security levels. A security model is an authentication strategy that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level will determine which security mechanism is employed when handling an SNMP packet.

Three security models are available: SNMPv1, SNMPv2c, and SNMPv3. Table 3-5 identifies what the combinations of security models and levels mean.

Note   SNMPv2p (SNMPv2 Classic) is not supported in any Cisco IOS releases after 11.2. SNMPv2c replaces the Party-based Administrative and Security Framework of SNMPv2p with a Community-based Administrative Framework. SNMPv2c retained the bulk retrieval and error handling capabilities of SNMPv2p.

You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SMNPv3.

The SNMPv3 feature supports RFCs 1901 to 1908, 2104, 2206, 2213, 2214, and 2271 to 2275. For additional information on SNMPv3, refer to RFC 2570, Introduction to Version 3 of the Internet-standard Network Management Framework (note that this is not a standards document).

SNMP Configuration Task List

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

To configure SNMP support, perform the tasks described in the following sections.

• Creating or Modifying an SNMP View Record (Optional)
  
  
• Creating or Modifying Access Control for an SNMP Community (Required)
  
  
• Specifying an SNMP-Server Engine Name (ID) (Optional)
  
  
• Specifying SNMP-Server Group Names (Optional)
  
  
• Configuring SNMP-Server Hosts (Required)
  
  
• Configuring SNMP-Server Users (Optional)
  
  
• Setting the Contact, Location, and Serial Number of the SNMP Agent (Optional)
  
  
• Setting the Contact, Location, and Serial Number of the SNMP Agent (Optional)
  
  
• Defining the Maximum SNMP Agent Packet Size (Optional)
  
  
• Limiting the Number of TFTP Servers Used via SNMP (Optional)
  
  
• Monitoring and Troubleshooting SNMP Status (Optional)
  
  
• Disabling the SNMP Agent (Optional)
  
  
• Configuring SNMP Notifications (Required)
  
  
• Configuring the DSLAM as an SNMP Manager (Optional)
  
  

Creating or Modifying an SNMP View Record

You can assign views to community strings to limit which MIB objects an SNMP manager can access. You can use a predefined view, or create your own view. If you are using a predefined view or no view at all, skip this task.

To create or modify an SNMP view record, use the following command in global configuration mode:

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

You can enter this command multiple times for the same view record. Later lines take precedence when an object identifier is included in two or more lines.

Creating or Modifying Access Control for an SNMP Community

Use an SNMP community string to define the relationship between the SNMP manager and the agent. The community string acts like a password to regulate access to the agent on the DSLAM. Optionally, you can specify one or more of the following characteristics associated with the string:

• An access list of IP addresses of the SNMP managers that are permitted to use the community string to gain access to the agent.
  
  
• A MIB view, which defines the subset of all MIB objects accessible to the given community.
  
  
• Read and write or read-only permission for the MIB objects accessible to the community.
  
  

To configure a community string, use the following command in global configuration mode:

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

For an example of configuring a community string, see the "SNMP Configuration Examples" section."

Specifying an SNMP-Server Engine Name (ID)

To specify an identification name (ID) for a local SNMP engine, use the following command in global configuration mode:

To specify an ID for a remote SNMP engine, use the following command in global configuration mode:

Specifying SNMP-Server Group Names

To specify a new SNMP group, or a table that maps SNMP users to SNMP views, use the following command in global configuration mode:

Configuring SNMP-Server Hosts

To configure the recipient of an SNMP trap operation, use the following command in global configuration mode:

Configuring SNMP-Server Users

To configure a new user to an SNMP group, use the following command in global configuration mode:

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

You can set the system contact, location, and serial number of the SNMP agent so that these descriptions can be accessed through the configuration file. To do so, use the following commands in global configuration mode, as needed:

Defining the Maximum SNMP Agent Packet Size

You can define 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:

Limiting the Number of TFTP Servers Used via SNMP

You can limit the number of TFTP servers used for saving and loading configuration files via SNMP to the servers specified in an access list. To do so, use the following command in global configuration mode:

Monitoring and Troubleshooting SNMP Status

To monitor and troubleshoot SNMP status and information, use the following commands in EXEC mode, as needed:

To monitor SNMP trap activity in real time for the purposes of troubleshooting, use the SNMP debug commands, including the debug snmp packet EXEC command. For documentation of SNMP debug commands, see the Cisco IOS Debug Command Reference.

Disabling the SNMP Agent

To disable any version of the SNMP agent, use the following command in global configuration mode:

Configuring SNMP Notifications

To configure the DSLAM to send SNMP traps or informs, perform the tasks described in the following sections:

• Configuring the DSLAM to Send SNMP Notifications (Required)
  
  
• Changing Notification Operation Values (Optional)
  
  
• Controlling Individual RFC 1157 SNMP Traps (Optional)
  
  

---

Note   Most Cisco IOS commands use the word "traps" in their command syntax. Unless there is an option within the command to specify either traps or informs, the keyword traps should be taken to mean either traps or informs, or both. Use the snmp-server host command to specify whether you want SNMP notifications to be sent as traps or informs.

---

Configuring the DSLAM to Send SNMP Notifications

To configure the DSLAM to send traps or informs to a host, use the following commands in global configuration mode:

The snmp-server host command specifies which hosts will receive SNMP notifications, and whether you want the notifications sent as traps or inform requests. The snmp-server enable traps command globally enables the production mechanism for the specified notification types (such as traps, config traps, entity traps, and so on).

Changing Notification Operation Values

You can specify a value other than the default for the source interface, message (packet) queue length for each host, or retransmission interval.

To change notification operation values, use the following commands in global configuration mode, as needed:

For inform requests, you can configure inform-specific operation values in addition to the operation values mentioned. To change inform operation values, use the following command in global configuration mode:

Controlling Individual RFC 1157 SNMP Traps

You can globally enable or disable authenticationFailure, linkUp, linkDown, warmStart, and coldStart notifications (traps or informs) individually. (These traps constitute the "generic traps" defined in RFC 1157.) To enable any of these notification types, use the following command in global configuration mode:

For example, to globally enable only linkUp and linkDown SNMP traps or informs for all interfaces, use the snmp-server enable traps snmp linkup linkdown form of this command.

Note that linkUp and linkDown notifications are enabled by default on specific interfaces, but will not be sent unless they are enabled globally. To control (disable or re-enable) the sending of linkUp/linkDown notifications for specific interfaces, use the no snmp trap link-status command in interface configuration mode. You can also specify the linkUp and linkDown traps from within a DSL profile. See the "Enabling and Disabling LinkUp/Down Traps" section for more information about enabling and disabling them.

Configuring the DSLAM as an SNMP Manager

The SNMP manager feature allows a DSLAM to serve as an SNMP manager. As an SNMP manager, the DSLAM can send SNMP requests to agents and receive SNMP responses and notifications from agents. When the SNMP manager process is enabled, the DSLAM can query other SNMP agents and process incoming SNMP traps.

Security Considerations

Most network security policies assume that DSLAMs will accept SNMP requests, send SNMP responses, and send SNMP notifications.

With the SNMP manager functionality enabled, the DSLAM may also send SNMP requests, receive SNMP responses, and receive SNMP notifications. Your security policy implementation may need to be updated prior to enabling this feature.

SNMP requests typically are sent to User Datagram Protocol (UDP) port 161. SNMP responses are typically sent from UDP port 161. SNMP notifications are typically sent to UDP port 162.

SNMP Sessions

Sessions are created when the SNMP manager in the DSLAM sends SNMP requests, such as inform requests, to a host, or receives SNMP notifications from a host. One session is created for each destination host. If there is no further communication between the DSLAM and host within the session timeout period, the session will be deleted.

The DSLAM tracks statistics, such as the average round-trip time required to reach the host, for each session. Using the statistics for a session, the SNMP manager in the DSLAM can set reasonable timeout periods for future requests, such as informs, for that host. If the session is deleted, all statistics are lost. If another session with the same host is later created, the request timeout value for replies will return to the default value.

Sessions consume memory. A reasonable session timeout value should be large enough that regularly used sessions are not prematurely deleted, yet small enough such that irregularly used, or one-time sessions, are purged expeditiously.

Enabling the SNMP Manager

To enable the SNMP manager process and set the session timeout value, use the following commands in global configuration mode:

Monitoring the SNMP Manager

To monitor the SNMP manager process, use the following commands in EXEC mode, as needed:

SNMP Configuration Examples

The following example enables SNMPv1, SNMPv2c, and SNMPv3. The configuration permits any SNMP manager to access all objects with read-only permissions using the community string named public. This configuration does not cause the DSLAM to send any traps.

The following example permits any SNMP to access all objects with read-only permission using the community string named public. The DSLAM also will send alarm traps to the hosts 172.16.1.111 and 172.16.1.33 using SNMPv1 and to the host 172.16.1.27 using SNMPv2c. The community string named public is sent with the traps.

The following example allows read-only access for all objects to members of access list 4 that specify the comaccess community string. No other SNMP managers have access to any objects. SNMP Authentication Failure traps are sent by SNMPv2c to the host cisco.com using the community string named public.

The following example sends Entity MIB inform notifications to the host cisco.com. The community string is restricted. The first line enables the DSLAM to send Entity MIB notifications in addition to any traps or informs previously enabled. The second line specifies that the notifications should be sent as inform requests, specifies the destination of these informs, and overwrites any previous snmp-server host commands for the host cisco.com.

The following example enables the DSLAM to send all traps to the host myhost.cisco.com using the community string public:

The following example will not send traps to any host. The syslog traps are enabled for all hosts, but only ATM soft traps are enabled to be sent to a host.

The following example enables the DSLAM to send all inform requests to the host myhost.cisco.com using the community string named public:

In the following example, the SNMP manager is enabled and the session timeout is set to a larger value than the default:

MIB Features in Cisco IOS Release 12.2DA

This section describes the MIB features available in Cisco IOS Release 12.2DA. You can download the SNMP (version2) standard and Cisco enterprise specific MIBs from the following URL:

ftp://ftp.cisco.com/pub/mibs/v2/

Standard MIB Modules

ACCOUNTING-CONTROL-MIB

The MIB module is for managing the collection and storage of accounting information for connections in a connection-oriented network such as ATM.

ADSL-CAP-LINE-MIB

The MIB module describes managed objects for ADSL CAP line interfaces.

ADSL-DMT-LINE-MIB

The MIB module describes managed objects for ADSL DMT line interfaces. This MIB contains a table to configure the DSL profile.

ADSL-LINE-MIB

The MIB module defines objects for the management of a pair of ADSL modems at each end of the ADSL line. This MIB contains a table to configure the DSL profile.

ADSL-TC-MIB

The MIB module which provides an ADSL line coding textual convention to be used by ADSL lines.

ATM-MIB

This is the MIB Module for ATM and AAL5-related objects for managing ATM interfaces, ATM virtual links, ATM cross-connects, AAL5 entities, and AAL5 connections.

ATM-SOFT-PVC-MIB

Updated version of the Soft PVC MIB released with the PNNI V1.0 Errata and PICS (af-pnni-81.00). This MIB reflects the characteristics unique to soft PVC.

ENTITY-MIB

The MIB module is for representing physical entities in the system.

IANAifType-MIB

The MIB module defines the IANAifType textual convention, and thus the enumerated values of the ifType object defined in MIB-II's ifTable.

IF-MIB

The MIB module, derived from RFC-2233, describes generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC-1229.

IMA-MIB

The MIB module manages Inverse Multiplexing for ATM (IMA) interfaces.

PerfHist-TC-MIB

This MIB module provides textual conventions to be used by systems supporting 15-minute based performance history counts.

PNNI-MIB

The MIB module manages ATM PNNI routing.

RFC1213-MIB

This MIB module defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets.

RFC1406-MIB

This MIB module defines objects for managing DS1 interfaces, including T1 and E1.

RFC1407-MIB

This MIB module defines objects for managing DS3 and E3 interfaces.

RFC1595-MIB

The MIB module describes SONET/SDH interfaces objects.

SNMP-FRAMEWORK-MIB

This MIB Module defines the SNMP Management Architecture. See RFC-2271 for a description of this MIB module.

SNMP-TARGET-MIB

This MIB module defines MIB objects that provide mechanisms to remotely configure the parameters used by an SNMP entity for the generation of SNMP messages. See RFC-2273 for a description of this MIB module.

SNMP-USM-MIB

This MIB module contains management information definitions for the SNMP User-based Security Model. See RFC-2274 for a description of this MIB module.

SNMPv2-CONF

This MIB module is the SNMPv2 conformance MIB. See RFC-1904 for a description of this MIB module.

SNMPv2-MIB

This MIB module defines all SNMPv2 entities. See RFC-1907, Management Information Base for Version 2 of the Simple Network Management Protocol, for a description of this MIB module.

SNMPv2-SMI

See RFC-1902, Structure of Management Information for Version 2 of the Simple Network Management Protocol, for a description of this MIB module.

SNMPv2-TC

See RFC-1903, Textual Conventions for Version 2 of the Simple Network Management Protocol for a description of this MIB module.

SNMP-VACM-MIB

The management information definitions for the View-based Access Control Model for SNMP. See RFC-2275 for a description of this MIB module.

Cisco Enterprise MIB Modules

CISCO-ADSL-CAP-LINE-MIB

This MIB module defines managed objects that extend the ADSL-DMT-LINE-MIB. This MIB contains a table to configure the DSL profile.

CISCO-ADSL-DMT-LINE-MIB

This MIB module defines managed objects that extend the ADSL-DMT-LINE-MIB. This MIB contains a table to configure the DSL profile.

CISCO-ATM2-MIB

This MIB module extends the capabilities of the ATM-MIB. Specifically, it defines the managed objects that support signal monitoring and SVC signaling management.

CISCO-ATM-ACCESS-LIST-MIB

This MIB module defines the managed objects that support ATM access control.

CISCO-ATM-CONN-MIB

This MIB module augments the atmVplTable and atmVclTable defined by the ATM-MIB. In addition, it provides address tables for SVPs and SVCs.

CISCO-ATM-IF-MIB

This MIB module defines the managed objects that support the configuration of ATM interfaces.

CISCO-ATM-IF-PHYS-MIB

A set of managed objects for tracking the status of DS3/E3/DS1/E1 and SONET interfaces.

CISCO-ATM-RM-MIB

This MIB module defines the managed objects that support ATM resource management.

CISCO-ATM-SIG-DIAG-MIB

This MIB module defines the managed objects that facilitate the diagnosis of failures of ATM signaling requests.

CISCO-ATM-SWITCH-FR-IWF-MIB

This MIB module manages Frame Relay to ATM interworking connections, and Frame Relay to Frame Relay switched connections via an ATM switching fabric, on a Cisco ATM switch.

CISCO-ATM-SWITCH-FR-RM-MIB

This MIB module describes a set of objects used for switch Resource Management (RM) for Frame Relay/Frame based User-to-Network (FUNI) to ATM interworking function (IWF) connections.

CISCO-ATM-TRAFFIC-MIB

This MIB module augments the definition of the atmTrafficDescrParamTable defined by the ATM-MIB.

CISCO-BULK-FILE-MIB

This MIB module defines the managed objects that support the creation (and deletion) of bulk files of SNMP data.

CISCO-CONFIG-COPY-MIB

This MIB facilitates writing of configuration files in the following ways: to and from the net, copying running configurations to startup configurations and vice-versa, and copying a configuration (running or startup) to and from the local IOS file system.

CISCO-CONFIG-MAN-MIB

This MIB module defines the managed objects that facilitate the management of configuration files.

CISCO-ENTITY-ALARM-MIB

This MIB module defines the managed objects that support the monitoring of alarms generated by physical entities contained by the system.

CISCO-ENTITY-ASSET-MIB

This MIB module monitors the asset information of items in the ENTITY-MIB, such as serial numbers, and software and hardware revision levels.

CISCO-ENTITY-PROVISIONING-MIB

This MIB module defines the objects that support provisioning of "container'" class physical entities.

CISCO-ENTITY-VENDORTYPE-OID-MIB

This MIB module defines the enterprise-specific object identifiers that Cisco products use to populate the entPhysicalTable of the ENTITY-MIB.

CISCO-FTP-CLIENT-MIB

The MIB module is for invoking Internet File Transfer Protocol (FTP) operations for network management purposes.

CISCO-IDSL-LINE-MIB

This MIB module describes IDSL (ISDN Digital Line Subscriber) line interfaces. The structure of this module resembles that of the ADSL-LINE-MIB (RFC-2662).

CISCO-OAM-MIB

The MIB module describes objects for invoking OAM loopback ping on ATM connections.

CISCO-PNNI-MIB

The MIB module defines objects for managing Cisco specific extensions to the PNNI MIB.

CISCO-PRODUCTS-MIB

This MIB module defines the Cisco enterprise-specific object identifiers assigned to platforms. A platform assigns its corresponding object identifier to the sysObjectID object.

CISCO-SDSL-LINE-MIB

This MIB module describes all variations of the symmetric DSL line interfaces. The structure of this module resembles and maintains consistency with the ADSL-LINE-MIB, ADSL-DMT-LINE-MIB, CISCO-ADSL-DMT-LINE-MIB, and CISCO-ADSL-CAP-LINE-MIB.

CISCO-SMI

This MIB module defines the Cisco enterprise-specific structure of management information.

CISCO-SYSLOG-MIB

This MIB module defines the managed objects that support syslog monitoring.

CISCO-SYSTEM-MIB

The systemGroup (see RFC-1907) provides a standard set of basic system information. This MIB module contains Cisco-defined extensions to the systemGroup

CISCO-TABLE-MODIFICATION-TRACKING-MIB

The MIB module tracks and stores the modifications in data of NMS specified MIB tables implemented in the SNMP agent.

CISCO-XDSL-LINE-MIB

The MIB module contains a collection of managed objects that are general in nature and apply to different types of DSL modems. The structure of this module resembles the ADSL-LINE-MIB, CISCO-SDSL-LINE-MIB, ADSL-DMT-LINE-MIB, and CISCO-ADSL-DMT-LINE-MIB.

Storing the Configuration

After you complete autoconfiguration and any manual configurations, copy the configuration into NVRAM. If you power off your DSLAM prior to saving the configuration in NVRAM you lose all manual configuration changes.

An example of the copy running-config command is:

Testing the Configuration

After you finish configuring the DSLAM, you can use the commands described in this section to confirm the hardware, software, and interface configuration:

• Confirming the Hardware Configuration
  
  
• Confirming the Software Version
  
  
• Confirming the Ethernet Configuration
  
  
• Confirming the ATM Address
  
  
• Testing the Ethernet Connection
  
  
• Confirming the ATM Connections
  
  
• Confirming the ATM Interface Configuration
  
  
• Confirming the Interface Status
  
  
• Confirming Virtual Channel Connections
  
  
• Confirming the Running Configuration
  
  
• Confirming the Saved Configuration
  
  

Confirming the Hardware Configuration

Use the show hardware command to confirm the correct hardware installation. For example:

Confirming the Software Version

Use the show version command to confirm that the correct version and type of software are being used and that the configuration register has been installed. For example:

Confirming the Ethernet Configuration

Use the show interface ethernet command to confirm that the Ethernet interface is configured correctly. For example:

Confirming the ATM Address

Use the show atm addresses command to confirm correct configuration of the ATM address for the DSLAM. For example:

Testing the Ethernet Connection

After you configure the IP addresses for the Ethernet interface, test for connectivity between the DSLAM and a host. The host can reside in any location on your network. To test for Ethernet connectivity, use this command:

For example, to test Ethernet connectivity from the DSLAM to a workstation with an IP address of 172.20.40.201, enter the command ping ip 172.20.40.201. If the DSLAM receives a response, this message appears:

Confirming the ATM Connections

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

Confirming the ATM Interface Configuration

Use the show atm interface command to confirm the ATM interfaces are configured correctly. For example:

Confirming the Interface Status

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

Confirming Virtual Channel Connections

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

Confirming the Running Configuration

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

Confirming the Saved Configuration

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

Posted: Tue Dec 10 09:43:32 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.