|
|
This chapter describes the organization and contents of the Cisco WAN Manager (CWM) Service Agent MIB (Management Information Base). The Service Agent MIB is structured as three separate MIBs:
To fully understand the information in this chapter, you must have a working knowledge of SNMP MIB conventions and standards.
The CWM Service Agent Network and Service MIBs are organized sets of objects, each of which contains information regarding the BPX 8600, MGX 8850, MGX 8250, MGX 8230,
MGX 8220, and IGX 8400/IPX network and services.
The SNMP community string is treated differently on these MIBs. It is used for authentication in the Service MIB, and used as part of the instance in the Network MIB. The community string for identifying a node is the Domain Node (for example, Network1.node3) in the Network MIB's Node and Trunk Tables, and is not used for the rtm MIB.
Each object is assigned a unique identifier within the MIB. Objects are accessed by the SNMP Manager Get and GetNext commands which specify the object's unique identifier. The Service Agent obtains the value of the specified object and transmits it to the SNMP Manager.
In the Network MIB, all objects are read-only. In the Service MIB, most tables are read-write.
When a single piece of information contained in a single object is required, a simple Get of that object by the SNMP Manager will retrieve the information. To obtain more complex information about the network, it requires the retrieval of several objects and the interpretation of their values. This is the case when the SNMP Manager needs to construct and display the network topology.
The Network MIB provides several interfaces, including the fault management related mechanisms and read-only configuration information for network resources. The configuration views presented by the Network MIB are primarily on a per-node basis; in this proxying role, the Service Agent provides a single point of contact to multiple instances of the same MIBs, each representing the configuration of resources for a specific node.
 |
Note The actual Network MIB file (SV+Network.mib) is located in the /usr/users/svplus/mibs directory. |
The Network MIB plays a vital role in fault management and must be utilized in collecting SNMP traps from the network. The tables defined in this MIB that support fault management functions include:
This table (trapConfigTable) is used when you are interested in registering to receive SNMP traps from the Service Agent.
This table (trapUploadTable) is used when you are interested in retrieving missing traps through the Robust Trap Mechanism (RTM).
|
Note Textual events are not the only means of accessing fault management information. As described in "Fault Management Interface" section, resources undergoing state changes may generate alarms that are converted into SNMP traps. |
The Network MIB contains read-only configuration information pertaining to the network, nodes, trunks, circuit lines, Frame Relay ports, and connections in the network. The tables defined in this MIB that provide configuration information include:
This table (svTrunkTable) contains trunk-related configuration information for the specified node (for example, card supported in a specified slot, trunk line load, local and remote line numbers, and the remote node ID [CWM node ID] used for determining the topology). This read-only table is indexed by slot and physical port number.
This table (lineTable) contains read-only configuration information about the specified IPX node's circuit lines, and is indexed by circuit line number and port number. This table is supported only for IGX 8400/IPX card types: CDP, CIP, FRP, and TXR.
This table (svNodeTable) contains the list of nodes in the network(s) managed and monitored by the CWM associated with this Service Agent. Feeder elements, such as IPX's feeding into BPX 8600 routing nodes, are not represented in this table.
This table (svNetworkTable) contains the list of all networks managed and monitored by the associated CWM. The table is indexed by network name, and contains the CWM ID assigned to the network, as well as the IPX network ID.
|
Note Indexing into several of the above tables specifies a slot number and other indices. Unlike the Service MIB, these Network MIB tables present information on a per-node basis. Distinguishing between each node's view of resources is accomplished by specifying the community string, as described in a subsequent subsection. |
The Network MIB defines a set of objects belonging to the svNodeGroup group. These objects specify certain characteristics of the node, such as the node's alarm state, platform type (that is,
BPX 8600, MGX 8850, MGX 8250, MGX 8230, MGX 8220, or IGX 8400/IPX), and ForeSight increase rate. These objects are briefly described in the following subsection on nodal community string access, and can be found in the Network MIB specification.
The configuration tables described above, with the exception of the Node Table and Network Table, provide information on a per-node basis, and require nodal community strings to access the proper instance of the table. The community strings, in essence, index these tables. Other objects defined in the Network MIB also require nodal community string access, such as the svNodeGrpAlarmState object, which specifies the node's alarm status (clear, minor, major, or unreachable). The general format of the community strings for these tables and objects is shown in Table 2-1.
| Community String Syntax | Table/Object Name | Description |
|---|---|---|
Domain.Node | svTrunkTable | Trunk configuration table |
| LineTable | Circuit line configuration table |
| Objects from svNodeGroup: | Group node parameters: |
| svNodeGrpName | Node name |
| svNodeGrpNetNme | Network name |
| svNodeGrpAlarmState | Node alarm state |
| svNodeGrpGateway | Indicator of gateway status |
| svNodeGrpActive | Node activity status |
| svNodeGrpPlatform | Node platform type |
| svNodeGrpRelease | CWM release revision number |
| svNodeFsIncRate | FRP ForeSight increase rate |
| svNodeFsDecRate | FRP ForeSight decrease rate |
| svNodeFsFastRate | FRP ForeSight fast decrease rate |
| svNodeRstTimeout | QIR reset time-out for PVCs |
| lastSequenceNumber | Sequence number of last generated trap |
For example, access to the Trunk Table for a node called "node34" in a network called "network1", requires the community string "network1.node34" to be used in an SNMP request.
The use of community strings as a means of indexing and distinguishing multiple instances of the same MIB may change. Future releases may use a network-wide view of configuration information. These tables would likely be indexed by node name and other indices, and consequently would utilize a single community string for all connection information.
The Service MIB provides extensive provisioning services for end-to-end connection. In Release 10 of CWM, end-to-end connections between any interface cards supporting Frame Relay (FR), ATM, and Circuit Emulation (CE) combinations are supported. This includes the following:
The Service MIB also contains port provisioning services. Through the SNMP tables, ports can be configured on MGX 8850 Release 1, MGX 8250, MGX 8230, and MGX 8220 shelves and on
IGX 8400/IPX platforms. Configurable port parameters include: port speed, signaling protocol, DE threshold, etc. The following subsections describe the types of services available through Service MIB's tables and objects.
|
Note The actual Service MIB file (SV+Service.mib) is located in the /usr/users/svplus/mibs directory. |
The Service MIB includes several tables to facilitate the provisioning of end-to-end connections via SNMP. End-to-end connections are specified by two end points, local and remote.
From an SNMP perspective connections are composed of MIB objects representing the end points and a connection object that links or describes the relationship between the local and remote end points. The Connection Tables provide the capability to establish connections, modify parameters associated with the connections, and perform diagnostics on the connections. The following tables provide this information.
This table gives information all about end-to-end connections in the network managed by the associated Cisco CWM workstation and provides capabilities for creating, modifying, testing, and deleting connections. This table is indexed by a connection index, which is a unique positive value generated by the Service Agent during connection creation. The value of 0 is specified during the creation of new connections.
This table gives connection characteristic information about all Frame Relay end points of every Virtual Connection (VC) in the network. This information includes: QIR, CIR, MIR, PIR, VC queue size, and percent utilization. This table is indexed by node name, shelf name, slot number, physical line number, physical port number, and DLCI.
See Section "Frame Relay End Point Table," in "Detailed MIB DescriptionNetwork MIB," for a description of the Frame Relay End Point Table objects.
This table gives connection characteristic information about all ATM end points in the network, including the middle segments associated with a Frame Relay Network Interworking connection. In a tiered-network architecture, end-to-end connections are comprised of up to three segments: the local feeder element to the local routing node, local routing node to remote routing node, and remote routing node to remote feeder element. Frame Relay connections spanning an ATM core network result in the creation of ATM end points in this table. This table also includes the ATM end points associated with Frame Relay/ATM Service Interworking connections between FRSM and ASI cards. This table is indexed by node name, shelf name, slot number, physical port number, VPI, and VCI.
See Section "ATM End Point Table," in "Accessing the Network and Service MIBs" for a description of the ATM End Point Table objects.
See Section, "Circuit Emulation End Point Table," in "Accessing the Network and Service MIBs".
This table is used to troubleshoot failed SNMP Set requests during the connection configuration or provisioning process. Based on the SNMP PDU request ID associated with the Set request, a Manager process can locate the specific error relating to the failed request. Examples of reported errors include port not found, end point already exists, and invalid bandwidth parameters.
See the sections "," "Multicast Connection View Table," "Connection Alarm Table," "Voice End Point Table," "Data End Point Table," and "RPM End Point Table" in Chapter 3 for a description of the Connection Group errors.
The Service MIB defines trap types associated with the operational state of end-to-end connections. These end-to-end traps are generated by CWM when a service fault affecting the network is received. Each trap provides information about the local and remote end points affected, the connection status, the connection A-bit status, and the connection type. The trap types defined are
The community strings used for accessing the Service MIB are stored in the /usr/users/svplus/config/SNMPProxy.conf configuration file. The community strings control access to the tables and are read during startup, and cannot be dynamically changed during runtime. The default values are
Creating a connection via the Service Agent's interface is achievable via a single SNMP Set request. The connection paradigm supported in Release 10 of CWM requires interaction with two types of tables:
The basic steps involved when creating connections via the Service MIB are briefly outlined here:
This process involves creation of the ports and specification of characteristics including signaling, port speed, and timer values. For Frame Relay/ATM Service Interworking connections between FRSM and ASI end points, the ATM port cannot be provisioned through the CWM Release 9.2 Service Agent interface. ATM and Frame Relay ports are supported in CWM Release 9.2.
Step 2 Create service end points. Once the ports are created, the end points defining the connection are created.
The end point definitions include several parameters associated with bandwidth, queueing, and traffic metrics. For Frame Relay/ATM Service Interworking, the remote end point of the connection must be defined in the end point table reserved for ATM end points.
Step 3 Create the connection including service end points. The final step involves the establishment of the relationship between two user end points, and specification of routing related characteristics.
The simple model for connection provisioning allows for connection creation using a single SNMP Set request on multiple MIB objects. When the ports terminating the connections already exist, the following minimum set of MIB objects are all that's required to create a connection:
| MIB Object | Table | Description |
|---|---|---|
frEndPointRowStatus (local end point) | frEndPointTable | An entry in the frEndPointTable must be created to represent the local end point. |
frEndPointRowStatus (remote end point) | frEndPointTable | An entry in the frEndPointTable must be created to represent the remote end point. |
svConnLocalEndPt | svConnTable | Pointer to the local end point. The value for this object is the Object ID of the first attribute of the local end point in the frEndPointTable. |
svConnRemoteEndPt | svConnTable | Pointer to the remote end point. The value for this object is the Object ID of the first attribute of the remote end point in the frEndPointTable. |
svConnRowStatus | svConnTable | This attribute controls the existence of entries in the svConnTable. Set this svConnRowStatus object to createAndGo (4) to create a new connection. |
This table maintains information about all Frame Relay end points of every VC in the network. See Section "Frame Relay End Point Table," in Chapter 3, for a detailed description of this table.
The Object IDentifier (OID) used for specifying attributes in the Frame Relay end point table consists of the ASN.1 identifier associated with the object, followed by the indices into the SNMP table. This allows creation of end points to be controlled via a single MIB object, frEndPointRowStatus. Specification of this object includes the name of the end point being created, and results in a specified action upon that object. The indices in CWM Release 9.2 are physical in nature, and include the node name, shelf name, slot number, physical line number, port number, and DLCI. For currently available IGX 8400/IPX cards, the end points typically specify a 0 value line number.
Specification of the node and shelf names in the OID is accomplished by using a simple encoding/translation from strings to integers. The ASN.1 representation for strings is comprised of the string length followed by the ASCII integer representation for each individual character. Thus the "AXIS245" string would be encoded as: 7.65.88.73.83.50.52.53, where 7 represents the number of characters in the string, 65 represents the character "A", and so on.
Thus, specification of the frEndPointRowStatus object for a Frame Relay end point with DLCI 200, located on slot 6, line 2, and port 1 of an MGX 8220 shelf called "AXIS245" connected to a BPX 8600 called "nmsbpx03" appears as follows (shown on multiple lines):
1.3.6.1.4.1.351.1.101.1.16.1.8. 8.110.109.115.98.112.120.48.51. 7.65.88.73.83.50.52.53. 6.2.1.200 | // ASN.1 ID of frEndPointRowStatus // ASN.1 representation of "nmsbpx03" // ASN.1 representation of "AXIS245" // slot.line.port.DLCI |
The user can create an end point by specifying a single MIB object, if the default end point parameters are acceptable. See Section "Frame Relay End Point Table," in Chapter 3, for details about this table.
This table maintains information about all ATM end points of every virtual circuit (VC) in the network. These entries include ATM end points constituting BPX 8600 routing segments. In Release 10 of CWM, this table is for provisioning the ATM end point of a Frame Relay/ATM Service Interworking connection or ATM—ATM connections. Note, ATM connections provisioned through the command line interface have BPX 8600 end points defined in the table, but do not have references to or representative entries in the Connection Table. See Section "ATM End Point Table", in Chapter 3, for a details about this table.
The OID used for specifying attributes in the ATM end point table consists of the ASN.1 identifier associated with the object, followed by the indices into the SNMP table. This allows creation of end points to be controlled via a single MIB object, atmEndPointRowStatus. Specification of this object includes the name of the end point being created, and results in a specified action upon that object. The indices in Release 10 of CWM include the node name, shelf name, slot number, physical port number, and VPI/VCI.
Specification of the node and shelf names in the OID is accomplished by using a simple encoding/translation from strings to integers. The ASN.1 representation for strings is comprised of the string length followed by the ASCII integer representation for each individual character. Thus the "AXIS245" string would be encoded as: 7.65.88.73.83.50.52.53, where 7 represents the number of characters in the string, 65 represents the character "A", and so on.
Thus, specification of the atmEndPointRowStatus object for an ATM end point with VPI 200 and
VCI 20, located on slot 6, port 1 of an MGX 8220 shelf called "AXIS245" connected to a BPX 8600 called "nmsbpx03" appears as follows (shown on multiple lines):
1.3.6.1.4.1.351.1.101.1.15.1.9. 8.110.109.115.98.112.120.48.51. 7.65.88.73.83.50.52.53. 6.1.20.200 | // ASN.1 ID of atmEndPointRowStatus // ASN.1 representation of "nmsbpx03" // ASN.1 representation of "AXIS245" // slot.line.port.VPI.VCI |
Creation of an end point can be accomplished via the specification of a single MIB object, if the default end point parameters are acceptable. See Section "ATM End Point Table," in Chapter 3 for detailed descriptions of this table.
This table maintains characteristic information about all Frame Relay and ATM end points of every VC in the network. The entries in this table describe the association between a local and a remote end point. These two end points define the end-to-end connection, regardless of the network topology. In a tiered network, where feeder elements (for example, MGX 8220 shelves or IPX feeders) are connected to a routing mesh network, an end-to-end connection comprises at most, three segments. Figure 2-1 shows the constituent segments of user connections in different scenarios involving routing nodes and feeder nodes. The boundary between segments is marked with white circles. The "a_local-to-a_remote" connection comprises three segments, while the "b_local-to-b_remote" connection is comprises two segments, and the "c_local-to-c_remote" connection comprises one segment. In a flat network with no feeder elements, each end-to-end connection consists of a single segment.
The parameters and attributes associated with an entry in the Connection Table typically relate to routing, and are independent of the types of end points. Each connection in the table is indexed by an integer determined by the Service Agent when the connection is created. A connection operational status object indicates the connection's state. Other connection objects include a hop-by-hop route description, a ForeSight enable/disable object, and string descriptions of the end points.
The remote and local end points defining the connection are referenced in the Connection Table by the OID of the first attribute of the end point in their respective end point tables. In Release 10 of CWM, when provisioning a connection, the local and remote end points can be Frame Relay or ATM end point. The "incomplete" operational status for an entry in the Connection Table indicates that segments exist, but others are unknown or nonexistent.
For an example of how to provision a connection using SNMP, consider the creation of a Frame Relay end-to-end connection from an IPX node to an MGX 8220 shelf. The local end point is located on a node named "nmsipx10" which has a channelized FRP card in slot 6, and a provisioned 128kbps port on DS-0 timeslot 1. The desired DLCI for this end point is 150.
For the remote end point, consider a Frame Relay end point located on an MGX 8220 shelf named "AXIS245" feeding into a BPX 8600 node named "nmsbpx03." The end point is located on an FRSM card in slot 6 of the MGX 8220 shelf, on a preprovisioned 128kbps port on physical line 1, DS-0 timeslot 2. The desired DLCI for this end point is 200.
Each end point will be customized with specific parameters defined for the traffic travelling in each direction. The provisioned connection will have a high class of service (that is, a high priority for rerouting—on a scale of 0-15, this connection will be assigned a value of 1). In the local-to-remote direction, traffic will be provisioned with an MIR of 2400bps, CIR of 3600bps, PIR of 9200bps, and QIR of 4000bps. In the remote-to-local direction, the asymmetric traffic will be provisioned with an MIR of 2300bps, CIR of 3200bps, PIR of 5600bps, and QIR of 3200bps.
The MIB objects described in Table 2-3 must be set in the SNMP request.
| MIB Object | OID (Segmented) | OID Segment Comment | Value |
|---|---|---|---|
frEndPointRowStatus | 1.3.6.1.4.1.351.1.101.1.16.1.8. | ASN.1 of | createAndGo (4). |
frEndPointRowStatus | 1.3.6.1.4.1.351.1.101.1.16.1.8. | ASN.1 of | createAndGo (4). |
svConnLocalEndPt | 1.3.6.1.4.1.351.1.101.1.3.1.2.0 | ASN.1 of svConnLocalEndPt | Same as OID of local end point, however, with a 1.3.6.1.4.1.351.3.4.1.1 prefix. |
svConnRemoteEndPt | 1.3.6.1.4.1.351.1.101.1.3.1.3.0 | ASN.1 of svConnRemoteEndPt | Same as OID of remote end point, however, with a 1.3.6.1.4.1.351.3.4.1.1 prefix. |
svConnRowStatus | 1.3.6.1.4.1.351.1.101.1.3.1.6.0 | ASN.1 of svConnRowStatus | createAndGo (4). |
frEndPointMIR | 1.3.6.1.4.1.351.1.101.1.16.1.9. | ASN.1 of frEndPointMIR | 2400 |
frEndPointMIR | 1.3.6.1.4.1.351.1.101.1.16.1.9. | ASN.1 of frEndPointMIR | 2300 |
frEndPointCIR | 1.3.6.1.4.1.351.1.101.1.16.1.10. | ASN.1 of frEndPointCIR | 3600 |
frEndPointCIR | 1.3.6.1.4.1.351.1.101.1.16.1.10. | ASN.1 of frEndPointCIR | 3200 |
frEndPointQIR | 1.3.6.1.4.1.351.1.101.1.16.1.17. | ASN.1 of frEndPointQIR | 4000 |
frEndPointQIR | 1.3.6.1.4.1.351.1.101.1.16.1.17. | ASN.1 of frEndPointQIR | 3200 |
frEndPointPIR | 1.3.6.1.4.1.351.1.101.1.16.1.14. | ASN.1 of frEndPointPIR | 9200 |
frEndPointPIR | 1.3.6.1.4.1.351.1.101.1.16.1.14. | ASN.1 of frEndPointPIR | 5600 |
svConnClassOfService | 1.3.6.1.4.1.351.1.101.1.3.1.10.0 | ASN.1 of svConnClassOfService | 1 (scale of 1-15). |
The port provisioning interface is described in this section. See Section "Frame Relay End Point Table" in Chapter 3 for a description of the Frame Relay Port Table objects.
The OID used for specifying attributes in the Frame Relay Port Table (svFrPortTable) consists of the ASN.1 identifier associated with the object, followed by the indices into the table. This allows creation of ports to be controlled via a single MIB object: svFrPortRowStatus. Specification of this object includes the name of the port being created, and results in a specified action upon that object. The indices in Release 10 of CWM are physical in nature, and include the node name, shelf name, slot number, physical line number, and port number. For currently available IGX 8400/IPX cards, the end points typically specify a 0 value line number and a null value for the shelf name.
Specification of the node and shelf names in the OID is accomplished by using a simple encoding/translation from strings to integers. The ASN.1 representation for strings is comprised of the string length followed by the ASCII integer representation for each individual character. Thus the "AXIS245" string would be encoded as: 7.65.88.73.83.50.52.53, where 7 represents the number of characters in the string, 65 represents the character "A", and so on.
Thus, specification of the svFrPortRowStatus object for a Frame Relay FRSM port, located in slot 6, line 2, and DS-0 timeslot 4 of an MGX 8220 shelf called "AXIS245" connected to a BPX 8600 called "nmsbpx03" appears as follows (shown on multiple lines):
1.3.6.1.4.1.351.1.101.2.4.1.5. 8.110.109.115.98.112.120.48.51. 7.65.88.73.83.50.52.53. 6.2.4 | // ASN.1 ID of svFrPortRowStatus // ASN.1 representation of "nmsbpx03" // ASN.1 representation of "AXIS245" // slot.line.port |
Similarly, for an FRP port located in slot 4 and DS-0 timeslot 16 of an IPX node called "nmsipx10", the specification of the svFrPortRowStatus object would appear as follows (shown on multiple lines):
1.3.6.1.4.1.351.1.101.2.4.1.5. 8.110.109.115.105.112.120.49.48. 0. 4.0.16 | // ASN.1 ID of svFrPortRowStatus // ASN.1 representation of "nmsipx10" // ASN.1 representation of no shelf // slot.line.port |
Creation of a port can be accomplished via the specification of a single MIB object, if the default port parameters are acceptable. See Section "Frame Relay End Point Table" in Chapter 3 for a description of the Frame Relay port objects.
In Release 10 of CWM, fault management by external OSSs is based on robust SNMP traps. This trap mechanism, known as Robust Trap Mechanism (RTM), is supported by the SNMP Service Agent running in conjunction with a CWM management system. Through the Service Agent, up to eight external SNMP Managers can register to receive network and service related traps.
In understanding the fault management capabilities available to external SNMP Managers in Release 10 of CWM, it is important to first understand at a high level the fault management capabilities of CWM and the network elements. In Release 10 of CWM some network resources utilize SNMP traps to relay fault information up to CWM, while others utilize proprietary robust alarms and string events. Robust alarms, in Cisco terms, refer to the state representations of network resources at a specific time, while string or textual events refer to descriptive events triggered by certain activities and sent up to the management system.
The two fault management mechanisms are mutually nonexclusive. They have no correlation. Actions occurring in the network, such as resource failures, may result in the generation of textual events as well as a change in alarm status. Other actions may result in no alarm status; however, they generate a textual event. Furthermore, the order in which robust alarms are received may not reflect the chronological sequence of network events, as robust alarms reflect state changes at time <x>. These issues must be considered when constructing Managers that will be receiving these faults.
The primary interface for fault management is through SNMP traps emitted by the SNMP Service Agent. This agent provides a uniform interface that partially hides the hybrid fault management interfaces supported by the various network elements. Managers that register to receive traps from the SNMP Service Agent can receive trap representations of robust alarm status changes as well as textual events. Managers also receive, through the Service Agent, traps from network elements supporting native traps. Therefore, the complete fault management interface presented to users of the Service Agent includes:
The differences and usage of these traps is discussed in the following subsections.
Severity levels in Release 10 of CWM classify the type of textual event received from the network. Each network element that generates a textual event, associates an appropriate security level to the message it is sending. This severity level, which may be forwarded on in the form of a VARBIND contained in an SNMP trap, falls into one of five categories:
The severity is used in textual events received by CWM, in the textual event filters that generate SNMP traps from qualifying events, and in the filteredLogRecord trap that originates from a filtered textual event. In the MIBs, the severity is represented by a display string of up to five characters.
Just as there are different levels of severity for the textual events sent by network elements, there are also various alarm statuses associated with the robust alarms. These alarm statuses are assigned by the network element providing the status update, and may be forwarded on by the Service Agent in the form of a VARBIND contained in an SNMP trap. The alarm status levels are also used by systems that generate native SNMP traps, such as CWM. CWM is the entity responsible for generating traps on end-to-end connections. The different alarm states, which are represented by integers, include:
Typically, not all alarm states apply to all network resources that report alarms. Ports, trunks, and circuit lines typically report alarm states of either clear or fail.
The general procedure for implementing fault management capabilities based on the Service Agent's trap stream includes the following:
1. Register with the Service Agent (via the trapConfigTable) to receive traps. This registration process results in the Service Agent storing some context information about the Manager, such as its IP address and its trap retrieval status.
2. Process incoming SNMP traps. For each trap, check the sequence number when you are concerned about missing traps.
3. When a missing trap is detected and it is important to retrieve it, enter the RTM mode (described in the following section). This allows the Manager to synchronously retrieve missing traps one at a time. The Manager has control over where to start trap retrieval by setting the trap sequence number to be retrieved. Successive missing traps are obtained via repetitive trap retrieval requests.
4. When the end of the trap queue is reached, the Manager exits the RTM retrieval mode and resumes normal trap reception mode.
The RTM mechanism implemented within the SNMP Service Agent requires subscribers to traps to register themselves with the agent. As part of the registration process, the Manager can specify a specific port as a destination for all traps. When a port is not specified, the agent sends all traps to port 162 on the Manager.
The Service Agent can handle up to eight subscribers. The managerNumOfValidEntries MIB variable stores the number of subscribed Managers in the RTM table.
The agent maintains a configuration entry for each registered Manager interested in receiving a trap stream. The subscription process for Managers involves the creation of an entry in the trapConfigTable. This table stores Manager context information such as the Manager's IP address and the port number for receiving traps. The basic process for creating a new entry in this table involves setting the appropriate values in this table for registering the Manager, and setting the managerRowStatus object to addRow (1).
With the managerRowStatus attribute set to addRow, the readTrapsFlag is set to FALSE and the nextTrapSeqNum is set to 0 in the registration table for each entry. See Section "Trap Configuration Table", in Chapter 3 for a description of the trapConfigTable entries.
The Service Agent internally maintains an object called nextTrapPointer for each registered Manager. This object is a pointer to the next trap in the FIFO (first in, first out) queue to be read by the Manager receiving traps, and is updated by the agent. It can also be set by the Manager issuing an SNMP Set request on the nextTrapSeqNum variable. When the Manager initially registers with the agent, this variable is set to the head of the FIFO queue.
The Service Agent also maintains the sequence number of the last generated trap in the lastSequenceNumber MIB variable. This variable is accessible by all Managers.
Posted: Thu Sep 28 16:09:10 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.