Snmp Trap Variable Bindings

1. Snmp Trap フォーマット Variable Bindings
2. Snmp Trap Variable Bindings For Beginners
3. Snmp Trap Variable Bindings 2

16.1 SNMP OverviewSNMP is an application-layer communication protocol that allows ONS 15454 network devices to exchange management information among these systems and with other devices outside the network. Through SNMP, network administrators can manage network performance, find and solve network problems, and plan network growth. Up to ten SNMPv1/v2 trap destinations and five concurrent Cisco Transport Controller (CTC) user sessions are allowed per node.The ONS 15454 uses SNMP for asynchronous event notification to a network management system (NMS). Cisco ONS system SNMP implementation uses standard Internet Engineering Task Force (IETF) management information bases (MIBs) to convey node-level inventory, fault, and performance management information for generic DS-1, DS-3, SONET, and Ethernet read-only management.

1. The first variable in the variable bindings list identifies the interface. SNMPGENERICTRAPAUTHFAILURE: Indicates an authentication failure trap. An SNMP entity has sent an SNMP message, but it has falsely claimed to belong to a known community. SNMPGENERICTRAPEGPNEIGHLOSS: Indicates an EGP neighbor loss trap. An EGP peer has changed to the down state. The first variable in the variable bindings list identifies the IP address of the EGP peer.
2. Variable Bindings. The type parameter, if present, can also be specified using either one of the fundamental SNMP data types (such as INTEGER or OCTET STRING) or as a defined datatype as with the SMI Database's get subcommand query search string, such as RowStatus or SNMPv2-TC!RowStatus.

SNMP Trap Variable Bindings. SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.

SNMP allows a generic SNMP manager such as HP OpenView Network Node Manager (NNM) or Open Systems Interconnection (OSI) NetExpert to be utilized for limited management functions.The Cisco ONS 15454 supports SNMP Version 1 (SNMPv1), SNMP Version 2c (SNMPv2c), and SNMP Version 3 (SNMPv3). As compared to SNMPv1, SNMPv2c includes additional protocol operations and 64-bit performance monitoring support. SNMPv3 provides authentication, encryption, and message integrity and is more secure. This chapter describes SNMP versions and describes the configuration parameters for the ONS 15454. 16.2 Basic SNMP ComponentsIn general terms, an SNMP-managed network consists of a management system, agents, and managed devices.A management system such as HP OpenView executes monitoring applications and controls managed devices. Management systems execute most of the management processes and provide the bulk of memory resources used for network management. Additionally, a network might be managed by one or several management systems.

Illustrates the relationship between the network manager, the SNMP agent, and the managed devices.Figure 16-2Example of the Primary SNMP Components. NoteONS 15454 MIB files in the CiscoV1 and CiscoV2 directories are almost identical in content except for the difference in 64-bit performance monitoring features.

Snmp Trap フォーマット Variable Bindings

The CiscoV2 directory contains three MIBs with 64-bit performance monitoring counters. CERENT-MSDWDM-MIB.mib, CERENT-FC-MIB.mib, and CERENT-GENERIC-PM-MIB.mib The CiscoV1 directory does not contain any 64-bit counters, but it does support the lower and higher word values used in 64-bit counters. The two directories also have somewhat different formats. 16.4.1 SNMPv3 SupportCisco ONS 15454 Software R9.0 and later supports SNMPv3 in addition to SNMPv1 and SNMPv2c.

SNMPv3 is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices by a combination of authentication and encryption packets over the network based on the User Based Security Model (USM) and the View-Based Access Control Model (VACM).User-Based Security Model—The User-Based Security Model (USM) uses the HMAC algorithm for generating keys for authentication and privacy.

SNMPv3 authenticates data based on its origin, and ensures that the data is received intact. SNMPv1 and v2 authenticate data based on the plain text community string, which is less secure when compared to the user-based authentication model.View-Based Access Control Model—The view-based access control model controls the access to the managed objects.

RFC 3415 defines the following five elements that VACM comprises:– Groups—A set of users on whose behalf the MIB objects can be accessed. Each user belongs to a group.

The group defines the access policy, notifications that users can receive, and the security model and security level for the users.– Security level—The access rights of a group depend on the security level of the request.– Contexts—Define a named subset of the object instances in the MIB. MIB objects are grouped into collections with different access policies based on the MIB contexts.– MIB views—Define a set of managed objects as subtrees and families. A view is a collection or family of subtrees. Each subtree is included or excluded from the view.– Access policy—Access is determined by the identity of the user, security level, security model, context, and the type of access (read/write). The access policy defines what SNMP objects can be accessed for reading, writing, and creating.Access to information can be restricted based on these elements. Each view is created with different access control details.

An operation is permitted or denied based on the access control details.You can configure SNMPv3 on a node to allow SNMP get and set access to management information and configure a node to send SNMPv3 traps to trap destinations in a secure way. SNMPv3 can be configured in secure mode, non-secure mode, or disabled mode.SNMP, when configured in secure mode, only allows SNMPv3 messages that have the authPriv security level. SNMP messages without authentication or privacy enabled are not allowed. When SNMP is configured in non-secure mode, it allows SNMPv1, SNMPv2, and SNMPv3 message types. Descriptionget-requestRetrieves a value from a specific variable.get-next-requestRetrieves the value following the named variable; this operation is often used to retrieve variables from within a table.

With this operation, an SNMP manager does not need to know the exact variable name. The SNMP manager searches sequentially to find the needed variable from within the MIB.get-responseReplies to a get-request, get-next-request, get-bulk-request, or set-request sent by an NMS.get-bulk-requestFills the get-response with up to the max-repetition number of get-next interactions, similar to a get-next-request.set-requestProvides remote network monitoring (RMON) MIB.trapIndicates that an event has occurred.

An unsolicited message is sent by an SNMP agent to an SNMP manager. 16.6.3 Generic Threshold and Performance Monitoring MIBsA MIB called CERENT-GENERIC-PM-MIB allows network management stations (NMS) to use a single, generic MIB for accessing threshold and performance monitoring data of different interface types. The MIB is generic in the sense that it is not tied to any particular kind of interface. The MIB objects can be used to obtain threshold values, current performance monitoring (PM) counts, and historic PM statistics for each kind of monitor and any supported interval at the near end and far end.Previously existing MIBs in the ONS 15454 system provide some of these counts.

For example, SONET interface 15-minute current PM counts and historic PM statistics are available using the SONET-MIB. DS-1 and DS-3 counts and statistics are available through the DS1-MIB and DS-3 MIB respectively. The generic MIB provides these types of information and also fetches threshold values and single-day statistics. In addition, the MIB supports optics and dense wavelength division multiplexing (DWDM) threshold and performance monitoring information.The CERENT-GENERIC-PM-MIB is organized into three different tables:.cerentGenericPmThresholdTable.cerentGenericPmStatsCurrentTable.cerentGenericPmStatsIntervalTable.The cerentGenericPmThresholdTable is used to obtain the threshold values for the monitor types. It is indexed based on the following items:.Interface index (cerentGenericPmThresholdIndex).Monitor type (cerentGenericPmThresholdMonType).

The syntax of cerentGenericPmThresholdMonType is type cerentMonitorType, defined in CERENT-TC.mib.Location (cerentGenericPmThresholdLocation). The syntax of cerentGenericPmThresholdLocation is type cerentLocation, defined in CERENT-TC.mib.Time period (cerentGenericPmThresholdPeriod).

The syntax of cerentGenericPmThresholdPeriod is type cerentPeriod, defined in CERENT-TC.mib.Threshold values can be provided in 64-bit and 32-bit formats. (For more information about 64-bit counters, see the.) The 64-bit values in cerentGenericPmThresholdHCValue can be used with agents that support SNMPv2. The two 32-bit values (cerentGenericPmThresholdValue and cerentGenericPmThresholdOverFlowValue) can be used by NMSs that only support SNMPv1. The objects compiled in the cerentGenericPmThresholdTable are shown in.

Information ObjectscerentGenericPmThresholdIndexcerentGenericPmThresholdValuecerentGenericPmThresholdMonTypecerentGenericPmThresholdOverFlowValuecerentGenericPmThresholdLocationcerentGenericPmThresholdHCValuecerentGenericPmThresholdPeriod—The second table within the MIB, cerentGenericPmStatsCurrentTable, compiles the current performance monitoring (PM) values for the monitor types. The table is indexed based on interface index (cerentGenericPmStatsCurrentIndex), monitor type (cerentGenericPmStatsCurrentMonType), location (cerentGenericPmStatsCurrentLocation) and time period (cerentGenericPmStatsCurrentPeriod). The syntax of cerentGenericPmStatsCurrentIndex is type cerentLocation, defined in CERENT-TC.mib.

The syntax of cerentGenericPmStatsCurrentMonType is type cerentMonitor, defined in CERENT-TC.mib. The syntax of cerentGenericPmStatsCurrentPeriod is type cerentPeriod, defined in CERENT-TC.mib.The cerentGenericPmStatsCurrentTable validates the current PM value using the cerentGenericPmStatsCurrentValid object and registers the number of valid intervals with historical PM statistics in the cerentGenericPmStatsCurrentValidIntervals object.PM values are provided in 64-bit and 32-bit formats. The 64-bit values in cerentGenericPmStatsCurrentHCValue can be used with agents that support SNMPv2. The two 32-bit values (cerentGenericPmStatsCurrentValue and cerentGenericPmStatsCurrentOverFlowValue) can be used by NMS that only support SNMPv1. The cerentGenericPmStatsCurrentTable is shown in.

Informational ObjectscerentGenericPmStatsCurrentIndexcerentGenericPmStatsCurrentValuecerentGenericPmStatsCurrentMonTypecerentGenericPmStatsCurrentOverFlowValuecerentGenericPmStatsCurrentLocationcerentGenericPmStatsCurrentHCValuecerentGenericPmStatsCurrentPeriodcerentGenericPmStatsCurrentValidData—cerentGenericPmStatsCurrentValidIntervalsThe third table in the MIB, cerentGenericPmStatsIntervalTable, obtains historic PM values for the monitor types. It validates the current PM value in the cerentGenericPmStatsIntervalValid object. This table is indexed based on interface index (cerentGenericPmStatsIntervalIndex), monitor type (cerentGenericPMStatsIntervalMonType), location (cerentGenericPmStatsIntervalLocation), and period (cerentGenericPmStatsIntervalPeriod). The syntax of cerentGenericPmStatsIntervalIndex is type cerentLocation, defined in CERENT-TC.mib. The syntax of cerentGenericPmStatsIntervalMonType is type cerentMonitor, defined in CERENT-TC.mib. The syntax of cerentGernicPmStatsIntervalPeriod is type cerentPeriod, defined in CERENT-TC.mib.The table provides historic PM values in 64-bit and 32-bit formats.

The 64-bit values contained in the cerentGenericPmStatsIntervalHCValue table can be used with SNMPv2 agents. The two 32-bit values (cerentGenericPmStatsIntervalValue and cerentGenericPmStatsIntervalOverFlowValue) can be used by SNMPv1 NMS. The cerentGenericPmStatsIntervalTable is shown in. 16.7 SNMP Trap ContentThe ONS 15454 uses SNMP traps to generate all alarms and events, such as raises and clears. The traps contain the following information:.Object IDs that uniquely identify each event with information about the generating entity (the slot or port; synchronous transport signal STS and Virtual Tributary VT; bidirectional line switched ring BLSR, Spanning Tree Protocol STP, etc.).Severity and service effect of the alarm (critical, major, minor, or event; service-affecting or non-service-affecting).Date and time stamp showing when the alarm occurred. DescriptioncoldStartRFC1907-MIBAgent up, cold start.warmStartRFC1907-MIBAgent up, warm start.authenticationFailureRFC1907-MIBCommunity string does not match.newRootRFC1493/BRIDGE-MIBSending agent is the new root of the spanning tree.topologyChangeRFC1493/BRIDGE-MIBA port in a bridge has changed from Learning to Forwarding or Forwarding to Blocking.entConfigChangeRFC2737/ENTITY-MIBThe entLastChangeTime value has changed.dsx1LineStatusChangeRFC2495/DS1-MIBThe value of an instance of dsx1LineStatus has changed. The trap can be used by an NMS to trigger polls.

Snmp Trap Variable Bindings For Beginners

When the line status change results from a higher-level line status change (for example, a DS-3), no traps for the DS-1 are sent.dsx3LineStatusChangeRFC2496/DS3-MIBThe value of an instance of dsx3LineStatus has changed. This trap can be used by an NMS to trigger polls. When the line status change results in a lower-level line status change (for example, a DS-1), no traps for the lower-level are sent.risingAlarmRFC2819/RMON-MIBThe SNMP trap that is generated when an alarm entry crosses the rising threshold and the entry generates an event that is configured for sending SNMP traps.fallingAlarmRFC2819/RMON-MIBThe SNMP trap that is generated when an alarm entry crosses the falling threshold and the entry generates an event that is configured for sending SNMP traps. DescriptionAdsx1LineStatusChange (from RFC 2495)(1)dsx1LineStatusThis variable indicates the line status of the interface.

It contains loopback, failure, received alarm and transmitted alarm information.(2)dsx1LineStatusLastChangeThe value of MIB II’s sysUpTime object at the time this DS1 entered its current line status state. If the current state was entered prior to the last proxy-agent reinitialization, the value of this object is zero.(3)cerent454NodeTimeThe time that an event occurred.(4)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical. Service-affecting statuses are Service-Affecting and Non-Service Affecting.(5)snmpTrapAddressThe address of the SNMP trap.Bdsx3LineStatusChange (from RFC 2496)(1)dsx3LineStatusThis variable indicates the line status of the interface. It contains loopback state information and failure state information.(2)dsx3LineStatusLastChangeThe value of MIB II's sysUpTime object at the time this DS3/E3 entered its current line status state.

If the current state was entered prior to the last reinitialization of the proxy-agent, then the value is zero.(3)cerent454NodeTimeThe time that an event occurred.B (cont.)(4)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical. Service-affecting statuses are Service-Affecting and Non-Service Affecting.(5)snmpTrapAddressThe address of the SNMP trap.CcoldStart (from RFC 1907)(1)cerent454NodeTimeThe time that the event occurred.warmStart (from RFC 1907)(2)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical. Service-affecting statuses are Service-Affecting and Non-Service Affecting.newRoot (from RFC)(3)snmpTrapAddressThe address of the SNMP trap.topologyChange (from RFC)——entConfigChange (from RFC 2737)——authenticationFailure (from RFC 1907)——D1risingAlarm (from RFC 2819)(1)alarmIndexThis variable uniquely identifies each entry in the alarm table. When an alarm in the table clears, the alarm indexes change for each alarm listed.(2)alarmVariableThe object identifier of the variable being sampled.(3)alarmSampleTypeThe method of sampling the selected variable and calculating the value to be compared against the thresholds.(4)alarmValueThe value of the statistic during the last sampling period.D1 (cont.)(5)alarmRisingThresholdWhen the current sampled value is greater than or equal to this threshold, and the value at the last sampling interval was less than this threshold, a single event is generated. A single event is also generated if the first sample after this entry is greater than or equal to this threshold.(6)cerent454NodeTimeThe time that an event occurred.(7)cerent454AlarmStateThe alarm severity and service-affecting status.

Severities are Minor, Major, and Critical. Service-affecting statuses are Service-Affecting and Non-Service Affecting.(8)snmpTrapAddressThe address of the SNMP trap.D2fallingAlarm (from RFC 2819)(1)alarmIndexThis variable uniquely identifies each entry in the alarm table. When an alarm in the table clears, the alarm indexes change for each alarm listed.(2)alarmVariableThe object identifier of the variable being sampled.(3)alarmSampleTypeThe method of sampling the selected variable and calculating the value to be compared against the thresholds.(4)alarmValueThe value of the statistic during the last sampling period.(5)alarmFallingThresholdWhen the current sampled value is less than or equal to this threshold, and the value at the last sampling interval was greater than this threshold, a single event is generated. A single is also generated if the first sample after this entry is less than or equal to this threshold.(6)cerent454NodeTimeThe time that an event occurred.D2 (cont.)(7)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical.

Service-affecting statuses are Service-Affecting and Non-Service Affecting.(8)snmpTrapAddressThe address of the SNMP trap.EfailureDetectedExternalToTheNE (from CERENT-454-mib)(1)cerent454NodeTimeThe time that an event occurred.(2)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical. Service-affecting statuses are Service-Affecting and Non-Service Affecting.(3)cerent454AlarmObjectTypeThe entity that raised the alarm. The NMS should use this value to decide which table to poll for further information about the alarm.(4)cerent454AlarmObjectIndexEvery alarm is raised by an object entry in a specific table.

This variable is the index of objects in each table; if the alarm is interface-related, this is the index of the interface in the interface table.(5)cerent454AlarmSlotNumberThe slot of the object that raised the alarm. If a slot is not relevant to the alarm, the slot number is zero.(6)cerent454AlarmPortNumberThe port of the object that raised the alarm. If a port is not relevant to the alarm, the port number is zero.(7)cerent454AlarmLineNumberThe object line that raised the alarm. If a line is not relevant to the alarm, the line number is zero.(8)cerent454AlarmObjectNameThe TL1-style user-visible name that uniquely identifies an object in the system.E (cont.)(9)cerent454AlarmAdditionalInfoAdditional information for the alarm object. In the current version of the MIB, this object contains provisioned description for alarms that are external to the NE. If there is no additional information, the value is zero.(10)snmpTrapAddressThe address of the SNMP trap.FperformanceMonitorThresholdCrossingAlert (from CERENT-454-mib)(1)cerent454NodeTimeThe time that an event occurred.(2)cerent454AlarmStateThe alarm severity and service-affecting status. Severities are Minor, Major, and Critical.

Service-affecting statuses are Service-Affecting and Non-Service Affecting.(3)cerent454AlarmObjectTypeThe entity that raised the alarm. The NMS should use this value to decide which table to poll for further information about the alarm.(4)cerent454AlarmObjectIndexEvery alarm is raised by an object entry in a specific table. This variable is the index of objects in each table; if the alarm is interface-related, this is the index of the interface in the interface table.(5)cerent454AlarmSlotNumberThe slot of the object that raised the alarm. If a slot is not relevant to the alarm, the slot number is zero.(6)cerent454AlarmPortNumberThe port of the object that raised the alarm. If a port is not relevant to the alarm, the port number is zero.(7)cerent454AlarmLineNumberThe object line that raised the alarm. 16.9 SNMPv1/v2 Proxy Over FirewallsSNMP and NMS applications have traditionally been unable to cross firewalls used for isolating security risks inside or from outside networks. CTC enables network operations centers (NOCs) to access performance monitoring data such as RMON statistics or autonomous messages across firewalls by using an SNMP proxy element installed on a firewall.The application-level proxy transports SNMP protocol data units (PDU) between the NMS and NEs, allowing requests and responses between the NMS and NEs and forwarding NE autonomous messages to the NMS.

Snmp Trap Variable Bindings 2

The proxy agent requires little provisioning at the NOC and no additional provisioning at the NEs.The firewall proxy is intended for use in a gateway network element-end network element (GNE-ENE) topology with many NEs through a single NE gateway. Up to 64 SNMP requests (such as get, getnext, or getbulk) are supported at any time behind single or multiple firewalls. The proxy interoperates with common NMS such as HP OpenView.For security reasons, the SNMP proxy feature must be enabled at all receiving and transmitting NEs to function. For instructions to do this, refer to theCisco ONS 15454 Procedure Guide. 16.10 SNMPv3 Proxy ConfigurationThe GNE can act as a proxy for the ENEs and forward SNMP requests to other SNMP entities (ENEs) irrespective of the types of objects that are accessed.

For this, you need to configure two sets of users, one between the GNE and NMS, and the other between the GNE and ENE. In addition to forwarding requests from the NMS to the ENE, the GNE also forwards responses and traps from the ENE to the NMS.The proxy forwarder application is defined in RFC 3413. Each entry in the Proxy Forwarder Table consists of the following parameters:.Proxy Type—Defines the type of message that may be forwarded based on the translation parameters defined by this entry. If the Proxy Type is read or write, the proxy entry is used for forwarding SNMP requests and their response between the NMS and the ENE. If the Proxy Type is trap, the entry is used for forwarding SNMP traps from the ENE to the NMS.Context Engine ID/Context Name—Specifies the ENE to which the incoming requests should be forwarded or the ENE whose traps should be forwarded to the NMS by the GNE.TargetParamsIn—Points to the Target Params Table that specifies the GNE user who proxies on behalf of an ENE user. When the proxy type is read or write, TargetParamsIn specifies the GNE user who receives requests from an NMS, and forwards requests to the ENE. When the proxy type is trap, TargetParamsIn specifies the GNE user who receives notifications from the ENE and forwards them to the NMS.

TargetParamsIn and the contextEngineID or the contextName columns are used to determine the row in the Proxy Forwarder Table that could be used for forwarding the received message.Single Target Out—Refers to the Target Address Table. After you select a row in the Proxy Forwarder Table for forwarding, this object is used to get the target address and the target parameters that are used for forwarding the request.

This object is used for requests with proxy types read or write, which only requires one target.Multiple Target Out (Tag)—Refers to a group of entries in the Target Address Table. Notifications are forwarded using this tag. The Multiple Target Out tag is only relevant when proxy type is Trap and is used to send notifications to one or more NMSs. ONS 15454 system RMON is based on the IETF-standard MIB RFC 2819 and includes the following five groups from the standard MIB: Ethernet Statistics, History Control, Ethernet History, Alarm, and Event.Certain statistics measured on the ML-Series Ethernet cards are mapped to a standard MIB if one exists. Otherwise, they are mapped to a nonstandard MIB variable.

The naming convention used by the standard/nonstandard MIB is not the same as the statistics variable used by the card. Because of this, statistics of this type that are obtained through get-requests, get-next-requests, and SNMP traps do not match the name used on the card or as seen by CTC/TL1.For example, the STATSMediaIndStatsRxFramesTooLong statistics are mapped to cMediaIndependentInFramesTooLong variable in CERENT MIB, whereas the STATSRxTotalPkts is mapped to mediaIndependentInPkts in HC-RMON-rfc3273.mib.

16.11.1 64-Bit RMON Monitoring over DCCThe ONS 15454 DCC is implemented over the IP protocol, which is not compatible with Ethernet. The system builds Ethernet equipment History and Statistics tables using high data level control (HDLC) statistics that are gathered over the data communications channel (DCC) that is running point-to-point protocol (PPP). RMON DCC monitors the health of remote DCC connections for IP and Ethernet.RMON DCC contains two MIBS for DCC interfaces. They are:.cMediaIndependentTable—Standard, RFC3273; the proprietary extension of the HC-RMON MIB used for reporting statistics.cMediaIndependentHistoryTable—Proprietary MIB used to support history. 16.11.1.1 Row Creation in MediaIndependentTableThe SetRequest PDU contains all needed values to activate a row of the mediaIndependentTable in a single operation as well as assign the status variable to createRequest (2).

In order to create the row and status, the SetRequest PDU for entry creation must have a value of zero for each of the object IDs. That is, all object IDs (OIDs) should be of the type OID.0.In order to create a row, the SetRequest PDU should contain the following:.mediaIndependentDataSource and its desired value.mediaIndependentOwner and its desired value (up to 32 characters).mediaIndependentStatus with a value of createRequest (2)The mediaIndependentTable creates a row if the SetRequest PDU is valid according to these rules. The SNMP agent decides the value of mediaIndependentIndex when the row is created, and a value can change if an Ethernet interface is added or deleted. The values are not sequentially allotted or contiguously numbered. The newly created row will have an mediaIndependentTable value of valid (1). If the row already exists, or if the SetRequest PDU values are insufficient or do not make sense, the SNMP agent returns an error code.

16.11.1.2 Row Creation in cMediaIndependentHistoryControlTableSNMP row creation and deletion for the cMediaIndependentHistoryControlTable follows the same processes as for the MediaIndependentTable; only the variables differ. In order to create a row, the SetRequest PDU should contain the following:.cMediaIndependentHistoryControlDataSource and its desired value.cMediaIndependentHistoryControlOwner and its desired value.cMediaIndependentHistoryControlStatus with a value of createRequest (2). 16.11.2 HC-RMON-MIB SupportFor the ONS 15454, the implementation of the high-capacity remote monitoring information base (HC-RMON-MIB, or RFC 3273) enables 64-bit support of existing RMON tables. This support is provided with the etherStatsHighCapacityTable and the etherHistoryHighCapacityTable. An additional table, the mediaIndependentTable, and an additional object, hcRMONCapabilities, are also added for this support. All of these elements are accessible by any third-party SNMP client should have the ability to upload RFC 3273 SNMP MIB variables in the etherStatsHighCapacityTable, etherHistoryHighCapacityTable, or mediaIndependentTable.

16.11.3.1 Row Creation in etherStatsTableThe SetRequest PDU for creating a row in this table contains all needed values to activate a table row in a single operation as well as assign the status variable to createRequest. The SetRequest PDU OID) entries must have an instance value, or type OID, of 0.In order to create a row, the SetRequest PDU should contain the following:.The etherStatsDataSource and its desired value.The etherStatsOwner and its desired value (up to 32 characters).The etherStatsStatus with a value of createRequest (2)The etherStatsTable creates a row if the SetRequest PDU is valid according to these rules. The SNMP agent decides the value of etherStatsIndex when the row is created and this value changes when an Ethernet interface is added or deleted; it is not sequentially allotted or contiguously numbered. A newly created row will have an etherStatsStatus value of valid (1). If the etherStatsTable row already exists, or if the SetRequest PDU values are insufficient or do not make sense, the SNMP agent returns an error code. 16.11.4.1 History Control TableThe RMON is sampled at one of four possible intervals. Each interval, or period, contains specific history values called buckets.

Lists the four sampling periods and corresponding buckets.The historyControlTable maximum row size is determined by multiplying the number of ports on a card by the number of sampling periods. For example, an ONS 15454 E100 card contains 24 ports, which multiplied by periods allows 96 rows in the table. An E1000 card contains 14 ports, which multiplied by four periods allows 56 table rows.

16.11.4.2 Row Creation in historyControlTableTo activate a historyControlTable row, the SetRequest PDU must contain all needed values and have a status variable value of 2 (createRequest). 16.11.6.2 Row Creation in alarmTableTo create a row in the alarmTable, all OIDs in the SetRequest PDU should be type OID.0. The table has a maximum number of 256 rows.To create a SetRequest PDU for the alarmTable, the following values are required:.The alarmInterval and its desired value.The alarmVariable and its desired value.The alarmSampleType and its desired value.The alarmStartupAlarm and its desired value.The alarmOwner and its desired value.The alarmStatus with a value of createRequest (2)If the SetRequest PDU is valid, a historyControlTable row is created.