Table of Contents

Catalyst 2800 and SNMP Management Platforms
Supported TCP/IP Protocols
Configuring Catalyst 2000 for SNMP with BOOTP
Configuring Catalyst 2000 for SNMP
The Management Group

netMgmtIpAddress
netMgmtIpSubnetMask (IpAddress)
netMgmtDefaultGateway (IpAddress)

Community Strings
Set Clients

netMgmtSetClientTable
netMgmtSetClientEntry
netMgmtSetClientIndex (integer)
netMgmtSetClientAddr (IpAddress)
netMgmtSetClientStatus (integer)

Trap Clients

netMgmtTrapClientTable
netMgmtTrapClientEntry
netMgmtTrapClientIndex (integer)
netMgmtTrapClientAddr (IpAddress)
netMgmtTrapClientComm (display string)
netMgmtTrapClientStatus (integer)

Catalyst 2000 Traps

The coldStart Trap
The warmStart Trap
The linkDown Trap

netMgmtEnableLinkTraps (integer)

The linkUp Trap
The authenticationFailure Trap

netMgmtEnableAuthenTraps (integer)

The logonIntruder Trap

logonIntruder

The switchDiagnostic Trap
The addressViolation Trap
Traps for Use by Bridges

The newRoot TRAP
The topologyChange TRAP

Standard MIBs and MIB Extensions

Catalyst 2000 Enterprise-Specific MIB
Catalyst 2800 Module MIB
Bridge MIB (RFC 1493)
FDDI MIB (RFC 1512)
RS-232 MIB (RFC1317)

Introduction

This manual describes how to configure and manage Catalyst 2000 switches using a standard SNMP-based network-management application. This manual also describes the standard MIB objects and MIB object extensions supported by Catalyst 2000 switches and includes information on precompiled schemas for SunNet Manager and profiles for Novell NetWare Management System (NMS).

Using the Simple Network Management Protocol (SNMP), Catalyst 2000 switches communicate with the third-party network-management application via its in-band management interface (the SNMP agent). The management information used to monitor and configure a Catalyst 2000 switch and its ports is represented as objects in a database called a Management Information Base (MIB). Catalyst 2000 switches supports standard MIB II objects as well as custom extensions designed to maximize control of Catalyst 2000 switching and hub capabilities.

Catalyst 2800 and SNMP Management Platforms

In general, you use the SNMP network-management application to locate a Catalyst 2000 icon and access the table of Catalyst 2000 objects. You can then view the characteristics and counters that describe the switch and set certain object values as defined in the Catalyst 2000-supported MIB.

Supported TCP/IP Protocols

Catalyst 2000 switches use a subset of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite as the underlying mechanism to transport the SNMP. The following protocols are implemented in Catalyst 2000 switches:

• Internet Protocol (IP)

• Internet Control Message Protocol (ICMP)

• User Datagram Protocol (UDP)

• Trivial File Transfer Protocol (TFTP)

• Bootstrap Protocol (BOOTP)

• Address Resolution Protocol (ARP)

Configuring Catalyst 2000 for SNMP with BOOTP

A Catalyst 2000 switch must be configured with an IP address before it can make available any in-band management. Addresses can be assigned individually in the administrative domain, or you can use BOOTP to maintain a database of such addresses.

Configuring Catalyst 2000 for SNMP

As an alternative to the BOOTP protocol, you can configure the IP address by using a combination of the out-of-band management console and MIB object extensions.

The first step is to configure the IP address with the IP Configuration Menu. You can then continue to use this menu to configure the corresponding subnet masks and default gateway addresses, or use the in-band MIB objects described below.

MIB objects are followed by the type of value required in parentheses. Then there is a brief description, possible values, and the default, if any.

The Management Group

netMgmtIpAddress

This is the Catalyst 2000 administrative IP address. The Catalyst 2000 may automatically discover a value for this object using the BootStrap protocol (BOOTP). The object value is also duplicated in the MIB-II ipAddrTable.

When VLANs are present, the Catalyst 2000 may be configured with up to four administrative IP addresses, one per VLAN. This object configures the IP address for the first VLAN. See the object vlanTable for how to configure the other IP addresses.

Assigning multiple VLAN IP addresses is only necessary if the VLANs in use represent separate physical IP subnets. This allows a management station residing on a VLAN to directly manage Catalyst 2000 switches without the need for an intervening router or gateway.

netMgmtIpSubnetMask (IpAddress)

The Catalyst 2000 administrative IP subnet mask. The Catalyst 2000 may automatically discover a value for this read-write MIB object using the BootStrap protocol (BOOTP). The object value is also duplicated in the MIB-II ipAddrTable.

When VLANs are present, the Catalyst 2000 may be configured with up to four administrative IP subnet masks, one per VLAN. This object configures the subnet mask for the first VLAN. See the object vlanTable for how to configure the other subnet masks. Assigning multiple VLAN subnet masks is only necessary if the VLANs in use represent separate physical IP subnets.

A write to this value will take effect immediately.

netMgmtDefaultGateway (IpAddress)

The default gateway IP address is the address of the next-hop router the Catalyst 2000 uses to reach a non-local IP host when the Catalyst 2000 does not know the return route. During a normal management protocol exchange with an IP client host, the Catalyst 2000 simply sends its response onto the same route from which the request was received. The default gateway route is only used when the Catalyst 2000 itself initiates an exchange, such as a TFTP upgrade with the client.

The default gateway IP address is global to all VLANs, which is unlike the unique per-VLAN management IP address and subnet mask.

A write to this read-write object will take effect immediately, replacing the previous address, if any.

Community Strings

The Catalyst 2000 supports trivial authentication with community strings. You can change these strings with the management console as described in the respective Catalyst 2000 administrator's guides. There are two distinct community strings:

• Get

  This community string, or password, has a default ASCII value of public and can be used by a network-management application to send Get and Get-Next requests to the Catalyst 2000.

• Set

  With a default value of public, this community string can be used for Get, Get-Next, and Set requests.

When configured to do so, the Catalyst 2000 can generate authenicationFailure traps when it receives a request with an invalid community string.

Set Clients

Up to four IP addresses can be defined as Set clients, giving them authority to issue Set requests and add other Set clients. The list of Set clients is initially empty; any Set client workstation can then set the first address. To configure Set clients, use the following MIB objects:

netMgmtSetClientTable

This MIB object displays a table (four entries) containing a list of IP addresses of workstations permitted to issue SET requests. Such a workstation is called a Set client. If this table is empty then any SET request with a matching SET community string is allowed. If at least one Set client is specified, then an incoming SET request must have its source IP address matched against an entry in this table before the SET is allowed.

A Set client entry whose IP address is 0.0.0.0 is considered invalid and will be ignored. This table is considered empty when all Set client addresses are zeroes (0.0.0.0).

netMgmtSetClientEntry

This MIB object displays an IP address of a management station allowed to issue SET requests to this management agent.

netMgmtSetClientIndex (integer)

This read-only MIB object provides identification of a SET client entry.

netMgmtSetClientAddr (IpAddress)

The SET client is assumed to be Internet UDP/IP based. This read-write MIB object is the client's IP address.

netMgmtSetClientStatus (integer)

Setting this read-write MIB object to the value invalid has the effect of invalidating the corresponding entry. That is, it effectively disassociates the IP address identified with said entry from the table. It is an implementation specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use.

Trap Clients

A trap client is a management workstation configured to receive and process traps. Catalyst 2000 supports up to four trap clients, but has no trap clients defined as a default. An empty trap client list disables the generation of all traps.

netMgmtTrapClientTable

This table contains a list of Network Management Stations that are to receive traps generated by this Network Management Agent. Such an NMS is called a trap client. A trap client entry whose IP address is 0.0.0.0 is considered invalid and will be ignored.

netMgmtTrapClientEntry

This MIB object displays a destination address and community string to a particular trap client.

netMgmtTrapClientIndex (integer)

This read-only MIB object provides identification of a trap client entry.

netMgmtTrapClientAddr (IpAddress)

The trap client is assumed to be Internet UDP/IP based. This read-write MIB object is the client's IP address.

netMgmtTrapClientComm (display string)

This read-write MIB object displays the community string of up to 32 characters used for traps sent to this trap client.

netMgmtTrapClientStatus (integer)

When this read-write MIB object is set to the value invalid, it has the effect of invalidating the corresponding entry. That is, it effectively disassociates the IP address/community string identified with said entry from the table. It is an implementation specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use.

Catalyst 2000 Traps

The Catalyst 2000 can generate five standard traps and two enterprise-specific traps. You can use MIB objects to suppress the generation of the authenticationFailure traps and the linkUp and linkDown traps.

The coldStart Trap

This trap is generated on power-on reset, or on completion of a firmware upgrade, where the new firmware is immediately selected for execution.

The warmStart Trap

You set this trap by setting the sysConfigReset MIB object, the sysConfigDefaultReset object, or by executing the reset command from one of the out-of-band Management Console menus.

The linkDown Trap

This trap is produced whenever a port changes to a suspended or disabled state due to a secure address violation (mismatch or duplication), network connection error (loss of Link Beat, jabber error), or an explicit management disable action. The trap frame carries the index value of the port. The following MIB is used to enable or disable the generation of this trap.

netMgmtEnableLinkTraps (integer)

This read-write MIB object indicates whether the Catalyst 2000 is permitted to generate linkUp/linkDown traps. The value of this object overrides any configuration information; as such, it provides a means whereby all linkUp/linkDown traps may be disabled.

The linkUp Trap

This trap reports a port transition from a suspended or disabled state to the enabled state. The trap frame contains the index value of the affected port. The netMgmtEnableLinkTraps MIB, described under the section "The linkDown Trap," can be used to enable or disable this trap.

The authenticationFailure Trap

This trap is generated whenever the Catalyst 2000 receives an SNMP message that is not properly authenticated, that is, not accompanied by a valid community string. Use the following MIB to set this trap.

netMgmtEnableAuthenTraps (integer)

This read-write MIB object indicates whether the Catalyst 2000 is permitted to generate authenticationFailure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authenticationFailure traps may be disabled.

This object manipulates the same value for the snmpEnableAuthenTraps object instance. The object is specified in this group for convenience.

The logonIntruder Trap

This enterprise-specific trap is generated when the out-of-band Management Console experiences successive logon failures due to invalid passwords. You can define the number of unsuccessful attempts with the netMgmtConsolePasswordThresh MIB object. Depending on the configuration of the netMgmtConsoleSilentTime MIB, the Catalyst 2000 can shut down the Management Console after the generation of this trap. The trap frame contains the name of the sending the Catalyst 2000 (the value of the sysName MIB object, or a null name).

logonIntruder

A user is repeatedly trying to log on using an invalid password. The number of attempts exceeds the preset limit given in netMgmtConsolePasswordThresh. Depending on how the object netMgmtConsoleSilentTime is configured, the Catalyst 2000 may shut down the Management Console following the generation of this trap.

The switchDiagnostic Trap

The Catalyst 2000 issues this enterprise-specific trap when its Power-On Self-Test (POST) does not pass all tests. Some POST failures are fatal and may prevent the generation of this trap. The trap frame contains the name of the sending the Catalyst 2000 (the value of the sysName MIB object) or a null name. A trap client can query the failing the Catalyst 2000 for the actual failure codes as stored in the sysInfoPOSTResult and sysInfoPOSTPortVector MIB objects.

The addressViolation Trap

The addressViolation trap is issued when an address violation is detected on a secured port. The generation of the addressViolation trap can be enabled or suppressed using the object sysConfigAddressViolationAlert.

Traps for Use by Bridges

The following traps are for the Spanning-Tree Protocol.

The newRoot TRAP

The newRoot trap indicates that the sending agent has become the new root of the spanning tree; the trap is sent by a bridge soon after its election as the new root, upon expiration of the Topology Change Timer immediately subsequent to its election. Implementation of this trap is optional.

The topologyChange TRAP

A topologyChange trap is sent by a bridge when any of its configured ports transitions from the Learning state to the Forwarding state, or from the Forwarding state to the Blocking state. The trap is not sent if a newRoot trap is sent for the same transition. Implementation of this trap is optional.

Standard MIBs and MIB Extensions

The Catalyst 2000 supports all groups in MIB II except the Transmission Control Protocol (TCP) and the Exterior Gateway Protocol.

The following pages list the actions you use to manage and configure a Catalyst 2000, and the MIB objects associated with each action.

The following are the five supported MIBs:

• Catalyst 2000 enterprise-specific MIB

• Catalyst 2800 Modules MIB (Catalyst 2800 only)

• RFC1493: Bridge MIB

• RFC1512: FDDI MIB (Catalyst 2800 only)

• RFC1317: RS-232 MIB

Catalyst 2000 Enterprise-Specific MIB

Catalyst 2800 Module MIB

Bridge MIB (RFC 1493)

FDDI MIB (RFC 1512)

RS-232 MIB (RFC1317)

Posted: Wed Aug 1 17:20:24 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.