The MIB module for managing IP and ICMP implementations, but excluding their management of IP routes.
Copyright (C) The Internet Society (2006). This version of this MIB module is part of RFC 4293; see the RFC itself for full legal notices.
The indication of whether this entity is acting as an IPv4 router in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv4 routers forward datagrams. IPv4 hosts do not (except those source-routed via the host).
When this object is written, the entity should save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system. Note: a stronger requirement is not used because this object was previously defined.
ipDefaultTTL
1.3.6.1.2.1.4.2
Integer32 (1..255)
The default value inserted into the Time-To-Live field of the IPv4 header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.
When this object is written, the entity should save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system. Note: a stronger requirement is not used because this object was previously defined.
ipInReceives
1.3.6.1.2.1.4.3
Counter32
The total number of input datagrams received from interfaces, including those received in error.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInRecieves.
ipInHdrErrors
1.3.6.1.2.1.4.4
Counter32
The number of input datagrams discarded due to errors in their IPv4 headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IPv4 options, etc.
This object has been deprecated as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInHdrErrors.
ipInAddrErrors
1.3.6.1.2.1.4.5
Counter32
The number of input datagrams discarded because the IPv4 address in their IPv4 header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IPv4 routers, and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInAddrErrors.
ipForwDatagrams
1.3.6.1.2.1.4.6
Counter32
The number of input datagrams for which this entity was not their final IPv4 destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IPv4 routers, this counter will include only those packets which were Source-Routed via this entity, and the Source-Route option processing was successful.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInForwDatagrams.
ipInUnknownProtos
1.3.6.1.2.1.4.7
Counter32
The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInUnknownProtos.
ipInDiscards
1.3.6.1.2.1.4.8
Counter32
The number of input IPv4 datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsInDiscards.
ipInDelivers
1.3.6.1.2.1.4.9
Counter32
The total number of input datagrams successfully delivered to IPv4 user-protocols (including ICMP).
This object has been deprecated as a new IP version neutral table has been added. It is loosely replaced by ipSystemStatsIndelivers.
ipOutRequests
1.3.6.1.2.1.4.10
Counter32
The total number of IPv4 datagrams which local IPv4 user protocols (including ICMP) supplied to IPv4 in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutRequests.
ipOutDiscards
1.3.6.1.2.1.4.11
Counter32
The number of output IPv4 datagrams for which no problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutDiscards.
ipOutNoRoutes
1.3.6.1.2.1.4.12
Counter32
The number of IPv4 datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagrams which a host cannot route because all of its default routers are down.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutNoRoutes.
ipReasmTimeout
1.3.6.1.2.1.4.13
Integer32 · seconds
The maximum number of seconds that received fragments are held while they are awaiting reassembly at this entity.
ipReasmReqds
1.3.6.1.2.1.4.14
Counter32
The number of IPv4 fragments received which needed to be reassembled at this entity.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmReqds.
ipReasmOKs
1.3.6.1.2.1.4.15
Counter32
The number of IPv4 datagrams successfully re-assembled.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmOKs.
ipReasmFails
1.3.6.1.2.1.4.16
Counter32
The number of failures detected by the IPv4 re-assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IPv4 fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsReasmFails.
ipFragOKs
1.3.6.1.2.1.4.17
Counter32
The number of IPv4 datagrams that have been successfully fragmented at this entity.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutFragOKs.
ipFragFails
1.3.6.1.2.1.4.18
Counter32
The number of IPv4 datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by ipSystemStatsOutFragFails.
ipFragCreates
1.3.6.1.2.1.4.19
Counter32
The number of IPv4 datagram fragments that have been generated as a result of fragmentation at this entity.
This object has been deprecated as a new IP version neutral table has been added. It is loosely replaced by ipSystemStatsOutFragCreates.
ipRoutingDiscards
1.3.6.1.2.1.4.23
Counter32
The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing entries.
This object was defined in pre-IPv6 versions of the IP MIB. It was implicitly IPv4 only, but the original specifications did not indicate this protocol restriction. In order to clarify the specifications, this object has been deprecated and a similar, but more thoroughly clarified, object has been added to the IP-FORWARD-MIB.
The indication of whether this entity is acting as an IPv6 router on any interface in respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host).
When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system.
ipv6IpDefaultHopLimit
1.3.6.1.2.1.4.26
Integer32 (0..255)
Reference: RFC 2461 Section 6.3.2
The default value inserted into the Hop Limit field of the IPv6 header of datagrams originated at this entity whenever a Hop Limit value is not supplied by the transport layer protocol.
When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system.
ipv4InterfaceTableLastChange
1.3.6.1.2.1.4.27
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which a row in the ipv4InterfaceTable was added or deleted, or when an ipv4InterfaceReasmMaxSize or an ipv4InterfaceEnableStatus object was modified.
If new objects are added to the ipv4InterfaceTable that require the ipv4InterfaceTableLastChange to be updated when they are modified, they must specify that requirement in their description clause.
ipv6InterfaceTableLastChange
1.3.6.1.2.1.4.29
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which a row in the ipv6InterfaceTable was added or deleted or when an ipv6InterfaceReasmMaxSize, ipv6InterfaceIdentifier, ipv6InterfaceEnableStatus, ipv6InterfaceReachableTime, ipv6InterfaceRetransmitTime, or ipv6InterfaceForwarding object was modified.
If new objects are added to the ipv6InterfaceTable that require the ipv6InterfaceTableLastChange to be updated when they are modified, they must specify that requirement in their description clause.
ipIfStatsTableLastChange
1.3.6.1.2.1.4.31.2
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which a row in the ipIfStatsTable was added or deleted.
If new objects are added to the ipIfStatsTable that require the ipIfStatsTableLastChange to be updated when they are modified, they must specify that requirement in their description clause.
ipAddressSpinLock
1.3.6.1.2.1.4.33
TestAndIncrRepresents integer-valued information used for atomic operations. When the management protocol is used to specify that an object instance having this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance. If not, the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero; otherwise, the value held by the instance is incremented by one. (Note that regardless of whether the management protocol set operation succeeds, the variable- binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this syntax is either `read-write' or `read-create'. When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol.
When the network management portion of the system is re- initialized, the value of every object instance having this syntax must either be incremented from its value prior to the re-initialization, or (if the value prior to the re- initialization is unknown) be set to a pseudo-randomly generated value. (0..2147483647) · Integer32
An advisory lock used to allow cooperating SNMP managers to coordinate their use of the set operation in creating or modifying rows within this table.
In order to use this lock to coordinate the use of set operations, managers should first retrieve ipAddressTableSpinLock. They should then determine the appropriate row to create or modify. Finally, they should issue the appropriate set command, including the retrieved value of ipAddressSpinLock. If another manager has altered the table in the meantime, then the value of ipAddressSpinLock will have changed, and the creation will fail as it will be specifying an incorrect value for ipAddressSpinLock. It is suggested, but not required, that the ipAddressSpinLock be the first var bind for each set of objects representing a 'row' in a PDU.
ipv6RouterAdvertSpinLock
1.3.6.1.2.1.4.38
TestAndIncrRepresents integer-valued information used for atomic operations. When the management protocol is used to specify that an object instance having this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance. If not, the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero; otherwise, the value held by the instance is incremented by one. (Note that regardless of whether the management protocol set operation succeeds, the variable- binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this syntax is either `read-write' or `read-create'. When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol.
When the network management portion of the system is re- initialized, the value of every object instance having this syntax must either be incremented from its value prior to the re-initialization, or (if the value prior to the re- initialization is unknown) be set to a pseudo-randomly generated value. (0..2147483647) · Integer32
An advisory lock used to allow cooperating SNMP managers to coordinate their use of the set operation in creating or modifying rows within this table.
In order to use this lock to coordinate the use of set operations, managers should first retrieve ipv6RouterAdvertSpinLock. They should then determine the appropriate row to create or modify. Finally, they should issue the appropriate set command including the retrieved value of ipv6RouterAdvertSpinLock. If another manager has altered the table in the meantime, then the value of ipv6RouterAdvertSpinLock will have changed and the creation will fail as it will be specifying an incorrect value for ipv6RouterAdvertSpinLock. It is suggested, but not required, that the ipv6RouterAdvertSpinLock be the first var bind for each set of objects representing a 'row' in a PDU.
icmpInMsgs
1.3.6.1.2.1.5.1
Counter32
The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsInMsgs.
icmpInErrors
1.3.6.1.2.1.5.2
Counter32
The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.).
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsInErrors.
icmpInDestUnreachs
1.3.6.1.2.1.5.3
Counter32
The number of ICMP Destination Unreachable messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInTimeExcds
1.3.6.1.2.1.5.4
Counter32
The number of ICMP Time Exceeded messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInParmProbs
1.3.6.1.2.1.5.5
Counter32
The number of ICMP Parameter Problem messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInSrcQuenchs
1.3.6.1.2.1.5.6
Counter32
The number of ICMP Source Quench messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInRedirects
1.3.6.1.2.1.5.7
Counter32
The number of ICMP Redirect messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInEchos
1.3.6.1.2.1.5.8
Counter32
The number of ICMP Echo (request) messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInEchoReps
1.3.6.1.2.1.5.9
Counter32
The number of ICMP Echo Reply messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInTimestamps
1.3.6.1.2.1.5.10
Counter32
The number of ICMP Timestamp (request) messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInTimestampReps
1.3.6.1.2.1.5.11
Counter32
The number of ICMP Timestamp Reply messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInAddrMasks
1.3.6.1.2.1.5.12
Counter32
The number of ICMP Address Mask Request messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpInAddrMaskReps
1.3.6.1.2.1.5.13
Counter32
The number of ICMP Address Mask Reply messages received.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutMsgs
1.3.6.1.2.1.5.14
Counter32
The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsOutMsgs.
icmpOutErrors
1.3.6.1.2.1.5.15
Counter32
The number of ICMP messages which this entity did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error which contribute to this counter's value.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by icmpStatsOutErrors.
icmpOutDestUnreachs
1.3.6.1.2.1.5.16
Counter32
The number of ICMP Destination Unreachable messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutTimeExcds
1.3.6.1.2.1.5.17
Counter32
The number of ICMP Time Exceeded messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutParmProbs
1.3.6.1.2.1.5.18
Counter32
The number of ICMP Parameter Problem messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutSrcQuenchs
1.3.6.1.2.1.5.19
Counter32
The number of ICMP Source Quench messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutRedirects
1.3.6.1.2.1.5.20
Counter32
The number of ICMP Redirect messages sent. For a host, this object will always be zero, since hosts do not send redirects.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutEchos
1.3.6.1.2.1.5.21
Counter32
The number of ICMP Echo (request) messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutEchoReps
1.3.6.1.2.1.5.22
Counter32
The number of ICMP Echo Reply messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutTimestamps
1.3.6.1.2.1.5.23
Counter32
The number of ICMP Timestamp (request) messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutTimestampReps
1.3.6.1.2.1.5.24
Counter32
The number of ICMP Timestamp Reply messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutAddrMasks
1.3.6.1.2.1.5.25
Counter32
The number of ICMP Address Mask Request messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
icmpOutAddrMaskReps
1.3.6.1.2.1.5.26
Counter32
The number of ICMP Address Mask Reply messages sent.
This object has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by a column in the icmpMsgStatsTable.
Table details
ipAddrTable
1.3.6.1.2.1.4.20
Index: ipAdEntAddr
The table of addressing information relevant to this entity's IPv4 addresses.
This table has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by the ipAddressTable although several objects that weren't deemed useful weren't carried forward while another (ipAdEntReasmMaxSize) was moved to the ipv4InterfaceTable.
ipAdEntAddr
1.3.6.1.2.1.4.20.1.1
IpAddress SIZE (4)
The IPv4 address to which this entry's addressing information pertains.
ipAdEntIfIndex
1.3.6.1.2.1.4.20.1.2
INTEGER (1..2147483647) · Integer32
The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipAdEntNetMask
1.3.6.1.2.1.4.20.1.3
IpAddress SIZE (4)
The subnet mask associated with the IPv4 address of this entry. The value of the mask is an IPv4 address with all the network bits set to 1 and all the hosts bits set to 0.
ipAdEntBcastAddr
1.3.6.1.2.1.4.20.1.4
INTEGER (0..1) · Integer32
The value of the least-significant bit in the IPv4 broadcast address used for sending datagrams on the (logical) interface associated with the IPv4 address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcast addresses used by the entity on this (logical) interface.
ipAdEntReasmMaxSize
1.3.6.1.2.1.4.20.1.5
INTEGER (0..65535) · Integer32
The size of the largest IPv4 datagram which this entity can re-assemble from incoming IPv4 fragmented datagrams received on this interface.
The IPv4 Address Translation table used for mapping from IPv4 addresses to physical addresses.
This table has been deprecated, as a new IP version-neutral table has been added. It is loosely replaced by the ipNetToPhysicalTable.
ipNetToMediaIfIndex
1.3.6.1.2.1.4.22.1.1
INTEGER (1..2147483647) · Integer32
The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
This object predates the rule limiting index objects to a max access value of 'not-accessible' and so continues to use a value of 'read-create'.
ipNetToMediaPhysAddress
1.3.6.1.2.1.4.22.1.2
PhysAddressRepresents media- or physical-level addresses. SIZE (0..65535) · OCTET STRING · hint 1x:
The media-dependent `physical' address. This object should return 0 when this entry is in the 'incomplete' state.
As the entries in this table are typically not persistent when this object is written the entity should not save the change to non-volatile storage. Note: a stronger requirement is not used because this object was previously defined.
ipNetToMediaNetAddress
1.3.6.1.2.1.4.22.1.3
IpAddress SIZE (4)
The IpAddress corresponding to the media-dependent `physical' address.
This object predates the rule limiting index objects to a max access value of 'not-accessible' and so continues to use a value of 'read-create'.
The type of mapping.
Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively dis-associates the interface identified with said entry from the mapping identified with said entry. 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. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object.
As the entries in this table are typically not persistent when this object is written the entity should not save the change to non-volatile storage. Note: a stronger requirement is not used because this object was previously defined.
ipv4InterfaceTable
1.3.6.1.2.1.4.28
Index: ipv4InterfaceIfIndex
The table containing per-interface IPv4-specific information.
ipv4InterfaceIfIndex
1.3.6.1.2.1.4.28.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipv4InterfaceReasmMaxSize
1.3.6.1.2.1.4.28.1.2
Integer32 (0..65535)
The size of the largest IPv4 datagram that this entity can re-assemble from incoming IPv4 fragmented datagrams received on this interface.
ipv4InterfaceEnableStatus
1.3.6.1.2.1.4.28.1.3
INTEGER1 = up2 = down · Integer32
The indication of whether IPv4 is enabled (up) or disabled (down) on this interface. This object does not affect the state of the interface itself, only its connection to an IPv4 stack. The IF-MIB should be used to control the state of the interface.
ipv4InterfaceRetransmitTime
1.3.6.1.2.1.4.28.1.4
Unsigned32 · milliseconds
Reference: RFC 1122
The time between retransmissions of ARP requests to a neighbor when resolving the address or when probing the reachability of a neighbor.
ipv6InterfaceTable
1.3.6.1.2.1.4.30
Index: ipv6InterfaceIfIndex
The table containing per-interface IPv6-specific information.
ipv6InterfaceIfIndex
1.3.6.1.2.1.4.30.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipv6InterfaceReasmMaxSize
1.3.6.1.2.1.4.30.1.2
Unsigned32 (1500..65535) · octets
The size of the largest IPv6 datagram that this entity can re-assemble from incoming IPv6 fragmented datagrams received on this interface.
ipv6InterfaceIdentifier
1.3.6.1.2.1.4.30.1.3
Ipv6AddressIfIdentifierTCThis data type is used to model IPv6 address interface identifiers. This is a binary string of up to 8 octets in network byte-order. SIZE (0..8) · OCTET STRING · hint 2x:
The Interface Identifier for this interface. The Interface Identifier is combined with an address prefix to form an interface address.
By default, the Interface Identifier is auto-configured according to the rules of the link type to which this interface is attached. A zero length identifier may be used where appropriate. One possible example is a loopback interface.
ipv6InterfaceEnableStatus
1.3.6.1.2.1.4.30.1.5
INTEGER1 = up2 = down · Integer32
The indication of whether IPv6 is enabled (up) or disabled (down) on this interface. This object does not affect the state of the interface itself, only its connection to an IPv6 stack. The IF-MIB should be used to control the state of the interface.
When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system.
ipv6InterfaceReachableTime
1.3.6.1.2.1.4.30.1.6
Unsigned32 · milliseconds
Reference: RFC 2461, Section 6.3.2
The time a neighbor is considered reachable after receiving a reachability confirmation.
ipv6InterfaceRetransmitTime
1.3.6.1.2.1.4.30.1.7
Unsigned32 · milliseconds
Reference: RFC 2461, Section 6.3.2
The time between retransmissions of Neighbor Solicitation messages to a neighbor when resolving the address or when probing the reachability of a neighbor.
The indication of whether this entity is acting as an IPv6 router on this interface with respect to the forwarding of datagrams received by, but not addressed to, this entity. IPv6 routers forward datagrams. IPv6 hosts do not (except those source-routed via the host).
This object is constrained by ipv6IpForwarding and is ignored if ipv6IpForwarding is set to notForwarding. Those systems that do not provide per-interface control of the forwarding function should set this object to forwarding for all interfaces and allow the ipv6IpForwarding object to control the forwarding capability.
When this object is written, the entity SHOULD save the change to non-volatile storage and restore the object from non-volatile storage upon re-initialization of the system.
ipSystemStatsTable
1.3.6.1.2.1.4.31.1
Index: ipSystemStatsIPVersion
The table containing system wide, IP version specific traffic statistics. This table and the ipIfStatsTable contain similar objects whose difference is in their granularity. Where this table contains system wide traffic statistics, the ipIfStatsTable contains the same statistics but counted on a per-interface basis.
ipSystemStatsIPVersion
1.3.6.1.2.1.4.31.1.1.1
InetVersion0 = unknown1 = ipv42 = ipv6A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose.Reference: RFC 791, RFC 2460 · Integer32
The IP version of this row.
ipSystemStatsInReceives
1.3.6.1.2.1.4.31.1.1.3
Counter32
The total number of input IP datagrams received, including those received in error.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInReceives
1.3.6.1.2.1.4.31.1.1.4
Counter64 (0..18446744073709551615)
The total number of input IP datagrams received, including those received in error. This object counts the same datagrams as ipSystemStatsInReceives, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInOctets
1.3.6.1.2.1.4.31.1.1.5
Counter32
The total number of octets received in input IP datagrams, including those received in error. Octets from datagrams counted in ipSystemStatsInReceives MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInOctets
1.3.6.1.2.1.4.31.1.1.6
Counter64 (0..18446744073709551615)
The total number of octets received in input IP datagrams, including those received in error. This object counts the same octets as ipSystemStatsInOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInHdrErrors
1.3.6.1.2.1.4.31.1.1.7
Counter32
The number of input IP datagrams discarded due to errors in their IP headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IP options, etc.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInNoRoutes
1.3.6.1.2.1.4.31.1.1.8
Counter32
The number of input IP datagrams discarded because no route could be found to transmit them to their destination.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInAddrErrors
1.3.6.1.2.1.4.31.1.1.9
Counter32
The number of input IP datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0). For entities that are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInUnknownProtos
1.3.6.1.2.1.4.31.1.1.10
Counter32
The number of locally-addressed IP datagrams received successfully but discarded because of an unknown or unsupported protocol.
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInTruncatedPkts
1.3.6.1.2.1.4.31.1.1.11
Counter32
The number of input IP datagrams discarded because the datagram frame didn't carry enough data.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInForwDatagrams
1.3.6.1.2.1.4.31.1.1.12
Counter32
The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful.
When tracking interface statistics, the counter of the incoming interface is incremented for each datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInForwDatagrams
1.3.6.1.2.1.4.31.1.1.13
Counter64 (0..18446744073709551615)
The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. This object counts the same packets as ipSystemStatsInForwDatagrams, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsReasmReqds
1.3.6.1.2.1.4.31.1.1.14
Counter32
The number of IP fragments received that needed to be reassembled at this interface.
When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsReasmOKs
1.3.6.1.2.1.4.31.1.1.15
Counter32
The number of IP datagrams successfully reassembled.
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsReasmFails
1.3.6.1.2.1.4.31.1.1.16
Counter32
The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInDiscards
1.3.6.1.2.1.4.31.1.1.17
Counter32
The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInDelivers
1.3.6.1.2.1.4.31.1.1.18
Counter32
The total number of datagrams successfully delivered to IP user-protocols (including ICMP).
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInDelivers
1.3.6.1.2.1.4.31.1.1.19
Counter64 (0..18446744073709551615)
The total number of datagrams successfully delivered to IP user-protocols (including ICMP). This object counts the same packets as ipSystemStatsInDelivers, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutRequests
1.3.6.1.2.1.4.31.1.1.20
Counter32
The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipSystemStatsOutForwDatagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutRequests
1.3.6.1.2.1.4.31.1.1.21
Counter64 (0..18446744073709551615)
The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. This object counts the same packets as ipSystemStatsOutRequests, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutNoRoutes
1.3.6.1.2.1.4.31.1.1.22
Counter32
The number of locally generated IP datagrams discarded because no route could be found to transmit them to their destination.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutForwDatagrams
1.3.6.1.2.1.4.31.1.1.23
Counter32
The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully forwarded datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutForwDatagrams
1.3.6.1.2.1.4.31.1.1.24
Counter64 (0..18446744073709551615)
The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. This object counts the same packets as ipSystemStatsOutForwDatagrams, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutDiscards
1.3.6.1.2.1.4.31.1.1.25
Counter32
The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipSystemStatsOutForwDatagrams if any such datagrams met this (discretionary) discard criterion.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutFragReqds
1.3.6.1.2.1.4.31.1.1.26
Counter32
The number of IP datagrams that would require fragmentation in order to be transmitted.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutFragOKs
1.3.6.1.2.1.4.31.1.1.27
Counter32
The number of IP datagrams that have been successfully fragmented.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutFragFails
1.3.6.1.2.1.4.31.1.1.28
Counter32
The number of IP datagrams that have been discarded because they needed to be fragmented but could not be. This includes IPv4 packets that have the DF bit set and IPv6 packets that are being forwarded and exceed the outgoing link MTU.
When tracking interface statistics, the counter of the outgoing interface is incremented for an unsuccessfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutFragCreates
1.3.6.1.2.1.4.31.1.1.29
Counter32
The number of output datagram fragments that have been generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutTransmits
1.3.6.1.2.1.4.31.1.1.30
Counter32
The total number of IP datagrams that this entity supplied to the lower layers for transmission. This includes datagrams generated locally and those forwarded by this entity.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutTransmits
1.3.6.1.2.1.4.31.1.1.31
Counter64 (0..18446744073709551615)
The total number of IP datagrams that this entity supplied to the lower layers for transmission. This object counts the same datagrams as ipSystemStatsOutTransmits, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutOctets
1.3.6.1.2.1.4.31.1.1.32
Counter32
The total number of octets in IP datagrams delivered to the lower layers for transmission. Octets from datagrams counted in ipSystemStatsOutTransmits MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutOctets
1.3.6.1.2.1.4.31.1.1.33
Counter64 (0..18446744073709551615)
The total number of octets in IP datagrams delivered to the lower layers for transmission. This objects counts the same octets as ipSystemStatsOutOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInMcastPkts
1.3.6.1.2.1.4.31.1.1.34
Counter32
The number of IP multicast datagrams received.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInMcastPkts
1.3.6.1.2.1.4.31.1.1.35
Counter64 (0..18446744073709551615)
The number of IP multicast datagrams received. This object counts the same datagrams as ipSystemStatsInMcastPkts but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInMcastOctets
1.3.6.1.2.1.4.31.1.1.36
Counter32
The total number of octets received in IP multicast datagrams. Octets from datagrams counted in ipSystemStatsInMcastPkts MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInMcastOctets
1.3.6.1.2.1.4.31.1.1.37
Counter64 (0..18446744073709551615)
The total number of octets received in IP multicast datagrams. This object counts the same octets as ipSystemStatsInMcastOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutMcastPkts
1.3.6.1.2.1.4.31.1.1.38
Counter32
The number of IP multicast datagrams transmitted.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutMcastPkts
1.3.6.1.2.1.4.31.1.1.39
Counter64 (0..18446744073709551615)
The number of IP multicast datagrams transmitted. This object counts the same datagrams as ipSystemStatsOutMcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutMcastOctets
1.3.6.1.2.1.4.31.1.1.40
Counter32
The total number of octets transmitted in IP multicast datagrams. Octets from datagrams counted in ipSystemStatsOutMcastPkts MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutMcastOctets
1.3.6.1.2.1.4.31.1.1.41
Counter64 (0..18446744073709551615)
The total number of octets transmitted in IP multicast datagrams. This object counts the same octets as ipSystemStatsOutMcastOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsInBcastPkts
1.3.6.1.2.1.4.31.1.1.42
Counter32
The number of IP broadcast datagrams received.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCInBcastPkts
1.3.6.1.2.1.4.31.1.1.43
Counter64 (0..18446744073709551615)
The number of IP broadcast datagrams received. This object counts the same datagrams as ipSystemStatsInBcastPkts but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsOutBcastPkts
1.3.6.1.2.1.4.31.1.1.44
Counter32
The number of IP broadcast datagrams transmitted.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsHCOutBcastPkts
1.3.6.1.2.1.4.31.1.1.45
Counter64 (0..18446744073709551615)
The number of IP broadcast datagrams transmitted. This object counts the same datagrams as ipSystemStatsOutBcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipSystemStatsDiscontinuityTime.
ipSystemStatsDiscontinuityTime
1.3.6.1.2.1.4.31.1.1.46
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity.
If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value.
ipSystemStatsRefreshRate
1.3.6.1.2.1.4.31.1.1.47
Unsigned32 · milli-seconds
The minimum reasonable polling interval for this entry. This object provides an indication of the minimum amount of time required to update the counters in this entry.
ipIfStatsTable
1.3.6.1.2.1.4.31.3
Index: ipIfStatsIPVersion · ipIfStatsIfIndex
The table containing per-interface traffic statistics. This table and the ipSystemStatsTable contain similar objects whose difference is in their granularity. Where this table contains per-interface statistics, the ipSystemStatsTable contains the same statistics, but counted on a system wide basis.
ipIfStatsIPVersion
1.3.6.1.2.1.4.31.3.1.1
InetVersion0 = unknown1 = ipv42 = ipv6A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose.Reference: RFC 791, RFC 2460 · Integer32
The IP version of this row.
ipIfStatsIfIndex
1.3.6.1.2.1.4.31.3.1.2
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipIfStatsInReceives
1.3.6.1.2.1.4.31.3.1.3
Counter32
The total number of input IP datagrams received, including those received in error.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInReceives
1.3.6.1.2.1.4.31.3.1.4
Counter64 (0..18446744073709551615)
The total number of input IP datagrams received, including those received in error. This object counts the same datagrams as ipIfStatsInReceives, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInOctets
1.3.6.1.2.1.4.31.3.1.5
Counter32
The total number of octets received in input IP datagrams, including those received in error. Octets from datagrams counted in ipIfStatsInReceives MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInOctets
1.3.6.1.2.1.4.31.3.1.6
Counter64 (0..18446744073709551615)
The total number of octets received in input IP datagrams, including those received in error. This object counts the same octets as ipIfStatsInOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInHdrErrors
1.3.6.1.2.1.4.31.3.1.7
Counter32
The number of input IP datagrams discarded due to errors in their IP headers, including version number mismatch, other format errors, hop count exceeded, errors discovered in processing their IP options, etc.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInNoRoutes
1.3.6.1.2.1.4.31.3.1.8
Counter32
The number of input IP datagrams discarded because no route could be found to transmit them to their destination.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInAddrErrors
1.3.6.1.2.1.4.31.3.1.9
Counter32
The number of input IP datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., ::0). For entities that are not IP routers and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInUnknownProtos
1.3.6.1.2.1.4.31.3.1.10
Counter32
The number of locally-addressed IP datagrams received successfully but discarded because of an unknown or unsupported protocol.
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInTruncatedPkts
1.3.6.1.2.1.4.31.3.1.11
Counter32
The number of input IP datagrams discarded because the datagram frame didn't carry enough data.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInForwDatagrams
1.3.6.1.2.1.4.31.3.1.12
Counter32
The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful.
When tracking interface statistics, the counter of the incoming interface is incremented for each datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInForwDatagrams
1.3.6.1.2.1.4.31.3.1.13
Counter64 (0..18446744073709551615)
The number of input datagrams for which this entity was not their final IP destination and for which this entity attempted to find a route to forward them to that final destination. This object counts the same packets as ipIfStatsInForwDatagrams, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsReasmReqds
1.3.6.1.2.1.4.31.3.1.14
Counter32
The number of IP fragments received that needed to be reassembled at this interface.
When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsReasmOKs
1.3.6.1.2.1.4.31.3.1.15
Counter32
The number of IP datagrams successfully reassembled.
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsReasmFails
1.3.6.1.2.1.4.31.3.1.16
Counter32
The number of failures detected by the IP re-assembly algorithm (for whatever reason: timed out, errors, etc.). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received.
When tracking interface statistics, the counter of the interface to which these fragments were addressed is incremented. This interface might not be the same as the input interface for some of the fragments.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInDiscards
1.3.6.1.2.1.4.31.3.1.17
Counter32
The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInDelivers
1.3.6.1.2.1.4.31.3.1.18
Counter32
The total number of datagrams successfully delivered to IP user-protocols (including ICMP).
When tracking interface statistics, the counter of the interface to which these datagrams were addressed is incremented. This interface might not be the same as the input interface for some of the datagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInDelivers
1.3.6.1.2.1.4.31.3.1.19
Counter64 (0..18446744073709551615)
The total number of datagrams successfully delivered to IP user-protocols (including ICMP). This object counts the same packets as ipIfStatsInDelivers, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutRequests
1.3.6.1.2.1.4.31.3.1.20
Counter32
The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipIfStatsOutForwDatagrams.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutRequests
1.3.6.1.2.1.4.31.3.1.21
Counter64 (0..18446744073709551615)
The total number of IP datagrams that local IP user- protocols (including ICMP) supplied to IP in requests for transmission. This object counts the same packets as ipIfStatsOutRequests, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutForwDatagrams
1.3.6.1.2.1.4.31.3.1.23
Counter32
The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. In entities that do not act as IP routers, this counter will include only those datagrams that were Source-Routed via this entity, and the Source-Route processing was successful.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully forwarded datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutForwDatagrams
1.3.6.1.2.1.4.31.3.1.24
Counter64 (0..18446744073709551615)
The number of datagrams for which this entity was not their final IP destination and for which it was successful in finding a path to their final destination. This object counts the same packets as ipIfStatsOutForwDatagrams, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutDiscards
1.3.6.1.2.1.4.31.3.1.25
Counter32
The number of output IP datagrams for which no problem was encountered to prevent their transmission to their destination, but were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipIfStatsOutForwDatagrams if any such datagrams met this (discretionary) discard criterion.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutFragReqds
1.3.6.1.2.1.4.31.3.1.26
Counter32
The number of IP datagrams that would require fragmentation in order to be transmitted.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutFragOKs
1.3.6.1.2.1.4.31.3.1.27
Counter32
The number of IP datagrams that have been successfully fragmented.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutFragFails
1.3.6.1.2.1.4.31.3.1.28
Counter32
The number of IP datagrams that have been discarded because they needed to be fragmented but could not be. This includes IPv4 packets that have the DF bit set and IPv6 packets that are being forwarded and exceed the outgoing link MTU.
When tracking interface statistics, the counter of the outgoing interface is incremented for an unsuccessfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutFragCreates
1.3.6.1.2.1.4.31.3.1.29
Counter32
The number of output datagram fragments that have been generated as a result of IP fragmentation.
When tracking interface statistics, the counter of the outgoing interface is incremented for a successfully fragmented datagram.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutTransmits
1.3.6.1.2.1.4.31.3.1.30
Counter32
The total number of IP datagrams that this entity supplied to the lower layers for transmission. This includes datagrams generated locally and those forwarded by this entity.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutTransmits
1.3.6.1.2.1.4.31.3.1.31
Counter64 (0..18446744073709551615)
The total number of IP datagrams that this entity supplied to the lower layers for transmission. This object counts the same datagrams as ipIfStatsOutTransmits, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutOctets
1.3.6.1.2.1.4.31.3.1.32
Counter32
The total number of octets in IP datagrams delivered to the lower layers for transmission. Octets from datagrams counted in ipIfStatsOutTransmits MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutOctets
1.3.6.1.2.1.4.31.3.1.33
Counter64 (0..18446744073709551615)
The total number of octets in IP datagrams delivered to the lower layers for transmission. This objects counts the same octets as ipIfStatsOutOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInMcastPkts
1.3.6.1.2.1.4.31.3.1.34
Counter32
The number of IP multicast datagrams received.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInMcastPkts
1.3.6.1.2.1.4.31.3.1.35
Counter64 (0..18446744073709551615)
The number of IP multicast datagrams received. This object counts the same datagrams as ipIfStatsInMcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInMcastOctets
1.3.6.1.2.1.4.31.3.1.36
Counter32
The total number of octets received in IP multicast datagrams. Octets from datagrams counted in ipIfStatsInMcastPkts MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInMcastOctets
1.3.6.1.2.1.4.31.3.1.37
Counter64 (0..18446744073709551615)
The total number of octets received in IP multicast datagrams. This object counts the same octets as ipIfStatsInMcastOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutMcastPkts
1.3.6.1.2.1.4.31.3.1.38
Counter32
The number of IP multicast datagrams transmitted.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutMcastPkts
1.3.6.1.2.1.4.31.3.1.39
Counter64 (0..18446744073709551615)
The number of IP multicast datagrams transmitted. This object counts the same datagrams as ipIfStatsOutMcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutMcastOctets
1.3.6.1.2.1.4.31.3.1.40
Counter32
The total number of octets transmitted in IP multicast datagrams. Octets from datagrams counted in ipIfStatsOutMcastPkts MUST be counted here.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutMcastOctets
1.3.6.1.2.1.4.31.3.1.41
Counter64 (0..18446744073709551615)
The total number of octets transmitted in IP multicast datagrams. This object counts the same octets as ipIfStatsOutMcastOctets, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsInBcastPkts
1.3.6.1.2.1.4.31.3.1.42
Counter32
The number of IP broadcast datagrams received.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCInBcastPkts
1.3.6.1.2.1.4.31.3.1.43
Counter64 (0..18446744073709551615)
The number of IP broadcast datagrams received. This object counts the same datagrams as ipIfStatsInBcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsOutBcastPkts
1.3.6.1.2.1.4.31.3.1.44
Counter32
The number of IP broadcast datagrams transmitted.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsHCOutBcastPkts
1.3.6.1.2.1.4.31.3.1.45
Counter64 (0..18446744073709551615)
The number of IP broadcast datagrams transmitted. This object counts the same datagrams as ipIfStatsOutBcastPkts, but allows for larger values.
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ipIfStatsDiscontinuityTime.
ipIfStatsDiscontinuityTime
1.3.6.1.2.1.4.31.3.1.46
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime on the most recent occasion at which any one or more of this entry's counters suffered a discontinuity.
If no such discontinuities have occurred since the last re- initialization of the local management subsystem, then this object contains a zero value.
ipIfStatsRefreshRate
1.3.6.1.2.1.4.31.3.1.47
Unsigned32 · milli-seconds
The minimum reasonable polling interval for this entry. This object provides an indication of the minimum amount of time required to update the counters in this entry.
This table allows the user to determine the source of an IP address or set of IP addresses, and allows other tables to share the information via pointer rather than by copying.
For example, when the node configures both a unicast and anycast address for a prefix, the ipAddressPrefix objects for those addresses will point to a single row in this table.
This table primarily provides support for IPv6 prefixes, and several of the objects are less meaningful for IPv4. The table continues to allow IPv4 addresses to allow future flexibility. In order to promote a common configuration, this document includes suggestions for default values for IPv4 prefixes. Each of these values may be overridden if an object is meaningful to the node.
All prefixes used by this entity should be included in this table independent of how the entity learned the prefix. (This table isn't limited to prefixes learned from router advertisements.)
ipAddressPrefixIfIndex
1.3.6.1.2.1.4.32.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface on which this prefix is configured. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipAddressPrefixType
1.3.6.1.2.1.4.32.1.2
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The address type of ipAddressPrefix.
ipAddressPrefixPrefix
1.3.6.1.2.1.4.32.1.3
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The address prefix. The address type of this object is specified in ipAddressPrefixType. The length of this object is the standard length for objects of that type (4 or 16 bytes). Any bits after ipAddressPrefixLength must be zero.
Implementors need to be aware that, if the size of ipAddressPrefixPrefix exceeds 114 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
ipAddressPrefixLength
1.3.6.1.2.1.4.32.1.4
InetAddressPrefixLengthDenotes the length of a generic Internet network address prefix. A value of n corresponds to an IP address mask that has n contiguous 1-bits from the most significant bit (MSB), with all other bits set to 0.
An InetAddressPrefixLength value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddressPrefixLength textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddressPrefixLength textual convention, if they appear in the same logical row.
InetAddressPrefixLength values larger than the maximum length of an IP address for a specific InetAddressType are treated as the maximum significant value applicable for the InetAddressType. The maximum significant value is 32 for the InetAddressType 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value for the InetAddressType 'dns(16)' is 0.
The value zero is object-specific and must be defined as part of the description of any object that uses this syntax. Examples of the usage of zero might include situations where the Internet network address prefix is unknown or does not apply.
The upper bound of the prefix length has been chosen to be consistent with the maximum size of an InetAddress. (0..2040) · Unsigned32 · hint d
The prefix length associated with this prefix.
The value 0 has no special meaning for this object. It simply refers to address '::/0'.
ipAddressPrefixOrigin
1.3.6.1.2.1.4.32.1.5
IpAddressPrefixOriginTC1 = other2 = manual3 = wellknown4 = dhcp5 = routeradvThe origin of this prefix.
manual(2) indicates a prefix that was manually configured.
wellknown(3) indicates a well-known prefix, e.g., 169.254/16 for IPv4 auto-configuration or fe80::/10 for IPv6 link-local addresses. Well known prefixes may be assigned by IANA, the address registries, or by specification in a standards track RFC.
dhcp(4) indicates a prefix that was assigned by a DHCP server.
routeradv(5) indicates a prefix learned from a router advertisement.
Note: while IpAddressOriginTC and IpAddressPrefixOriginTC are similar, they are not identical. The first defines how an address was created, while the second defines how a prefix was found. · Integer32
The origin of this prefix.
ipAddressPrefixOnLinkFlag
1.3.6.1.2.1.4.32.1.6
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
Reference: For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462
This object has the value 'true(1)', if this prefix can be used for on-link determination; otherwise, the value is 'false(2)'.
The default for IPv4 prefixes is 'true(1)'.
ipAddressPrefixAutonomousFlag
1.3.6.1.2.1.4.32.1.7
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
Reference: For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462
Autonomous address configuration flag. When true(1), indicates that this prefix can be used for autonomous address configuration (i.e., can be used to form a local interface address). If false(2), it is not used to auto- configure a local interface address.
The default for IPv4 prefixes is 'false(2)'.
ipAddressPrefixAdvPreferredLifetime
1.3.6.1.2.1.4.32.1.8
Unsigned32 · seconds
Reference: For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462
The remaining length of time, in seconds, that this prefix will continue to be preferred, i.e., time until deprecation.
A value of 4,294,967,295 represents infinity.
The address generated from a deprecated prefix should no longer be used as a source address in new communications, but packets received on such an interface are processed as expected.
The default for IPv4 prefixes is 4,294,967,295 (infinity).
ipAddressPrefixAdvValidLifetime
1.3.6.1.2.1.4.32.1.9
Unsigned32 · seconds
Reference: For IPv6 RFC 2461, especially sections 2 and 4.6.2 and RFC 2462
The remaining length of time, in seconds, that this prefix will continue to be valid, i.e., time until invalidation. A value of 4,294,967,295 represents infinity.
The address generated from an invalidated prefix should not appear as the destination or source address of a packet.
The default for IPv4 prefixes is 4,294,967,295 (infinity).
ipAddressTable
1.3.6.1.2.1.4.34
Index: ipAddressAddrType · ipAddressAddr
This table contains addressing information relevant to the entity's interfaces.
This table does not contain multicast address information. Tables for such information should be contained in multicast specific MIBs, such as RFC 3019.
While this table is writable, the user will note that several objects, such as ipAddressOrigin, are not. The intention in allowing a user to write to this table is to allow them to add or remove any entry that isn't permanent. The user should be allowed to modify objects and entries when that would not cause inconsistencies within the table. Allowing write access to objects, such as ipAddressOrigin, could allow a user to insert an entry and then label it incorrectly.
Note well: When including IPv6 link-local addresses in this table, the entry must use an InetAddressType of 'ipv6z' in order to differentiate between the possible interfaces.
ipAddressAddrType
1.3.6.1.2.1.4.34.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The address type of ipAddressAddr.
ipAddressAddr
1.3.6.1.2.1.4.34.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The IP address to which this entry's addressing information pertains. The address type of this object is specified in ipAddressAddrType.
Implementors need to be aware that if the size of ipAddressAddr exceeds 116 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
ipAddressIfIndex
1.3.6.1.2.1.4.34.1.3
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
The type of address. broadcast(3) is not a valid value for IPv6 addresses (RFC 3513).
ipAddressPrefix
1.3.6.1.2.1.4.34.1.5
RowPointerRepresents a pointer to a conceptual row. The value is the name of the instance of the first accessible columnar object in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the ifTable (note that if ifIndex were not-accessible, then ifDescr.3 would be used instead). · OBJECT IDENTIFIER
A pointer to the row in the prefix table to which this address belongs. May be { 0 0 } if there is no such row.
ipAddressOrigin
1.3.6.1.2.1.4.34.1.6
IpAddressOriginTC1 = other2 = manual4 = dhcp5 = linklayer6 = randomThe origin of the address.
manual(2) indicates that the address was manually configured to a specified address, e.g., by user configuration.
dhcp(4) indicates an address that was assigned to this system by a DHCP server.
linklayer(5) indicates an address created by IPv6 stateless auto-configuration.
random(6) indicates an address chosen by the system at random, e.g., an IPv4 address within 169.254/16, or an RFC 3041 privacy address. · Integer32
The origin of the address.
ipAddressStatus
1.3.6.1.2.1.4.34.1.7
IpAddressStatusTC1 = preferred2 = deprecated3 = invalid4 = inaccessible5 = unknown6 = tentative7 = duplicate8 = optimisticThe status of an address. Most of the states correspond to states from the IPv6 Stateless Address Autoconfiguration protocol.
The preferred(1) state indicates that this is a valid address that can appear as the destination or source address of a packet.
The deprecated(2) state indicates that this is a valid but deprecated address that should no longer be used as a source address in new communications, but packets addressed to such an address are processed as expected.
The invalid(3) state indicates that this isn't a valid address and it shouldn't appear as the destination or source address of a packet.
The inaccessible(4) state indicates that the address is not accessible because the interface to which this address is assigned is not operational.
The unknown(5) state indicates that the status cannot be determined for some reason.
The tentative(6) state indicates that the uniqueness of the address on the link is being verified. Addresses in this state should not be used for general communication and should only be used to determine the uniqueness of the address.
The duplicate(7) state indicates the address has been determined to be non-unique on the link and so must not be used.
The optimistic(8) state indicates the address is available for use, subject to restrictions, while its uniqueness on a link is being verified.
In the absence of other information, an IPv4 address is always preferred(1).Reference: RFC 2462 · Integer32
The status of the address, describing if the address can be used for communication.
In the absence of other information, an IPv4 address is always preferred(1).
ipAddressCreated
1.3.6.1.2.1.4.34.1.8
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime at the time this entry was created. If this entry was created prior to the last re- initialization of the local network management subsystem, then this object contains a zero value.
ipAddressLastChanged
1.3.6.1.2.1.4.34.1.9
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re- initialization of the local network management subsystem, then this object contains a zero value.
ipAddressRowStatus
1.3.6.1.2.1.4.34.1.10
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
The status of this conceptual row.
The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified.
A conceptual row can not be made active until the ipAddressIfIndex has been set to a valid index.
ipAddressStorageType
1.3.6.1.2.1.4.34.1.11
StorageType1 = other2 = volatile3 = nonVolatile4 = permanent5 = readOnlyDescribes the memory realization of a conceptual row. A row which is volatile(2) is lost upon reboot. A row which is either nonVolatile(3), permanent(4) or readOnly(5), is backed up by stable storage. A row which is permanent(4) can be changed but not deleted. A row which is readOnly(5) cannot be changed nor deleted.
If the value of an object with this syntax is either permanent(4) or readOnly(5), it cannot be written. Conversely, if the value is either other(1), volatile(2) or nonVolatile(3), it cannot be modified to be permanent(4) or readOnly(5). (All illegal modifications result in a 'wrongValue' error.)
Every usage of this textual convention is required to specify the columnar objects which a permanent(4) row must at a minimum allow to be writable. · Integer32
The storage type for this conceptual row. If this object has a value of 'permanent', then no other objects are required to be able to be modified.
The IP Address Translation table used for mapping from IP addresses to physical addresses.
The Address Translation tables contain the IP address to 'physical' address equivalences. Some interfaces do not use translation tables for determining address equivalences (e.g., DDN-X.25 has an algorithmic method); if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries.
While many protocols may be used to populate this table, ARP and Neighbor Discovery are the most likely options.
ipNetToPhysicalIfIndex
1.3.6.1.2.1.4.35.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipNetToPhysicalNetAddressType
1.3.6.1.2.1.4.35.1.2
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The type of ipNetToPhysicalNetAddress.
ipNetToPhysicalNetAddress
1.3.6.1.2.1.4.35.1.3
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The IP Address corresponding to the media-dependent `physical' address. The address type of this object is specified in ipNetToPhysicalAddressType.
Implementors need to be aware that if the size of ipNetToPhysicalNetAddress exceeds 115 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
ipNetToPhysicalPhysAddress
1.3.6.1.2.1.4.35.1.4
PhysAddressRepresents media- or physical-level addresses. SIZE (0..65535) · OCTET STRING · hint 1x:
The media-dependent `physical' address.
As the entries in this table are typically not persistent when this object is written the entity SHOULD NOT save the change to non-volatile storage.
ipNetToPhysicalLastUpdated
1.3.6.1.2.1.4.35.1.5
TimeStampThe value of the sysUpTime object at which a specific occurrence happened. The specific occurrence must be
defined in the description of any object defined using this type.
If sysUpTime is reset to zero as a result of a re- initialization of the network management (sub)system, then the values of all TimeStamp objects are also reset. However, after approximately 497 days without a re- initialization, the sysUpTime object will reach 2^^32-1 and then increment around to zero; in this case, existing values of TimeStamp objects do not change. This can lead to ambiguities in the value of TimeStamp objects. · TimeTicks
The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re- initialization of the local network management subsystem, then this object contains a zero value.
The type of mapping.
Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToPhysicalTable. That is, it effectively dis- associates the interface identified with said entry from the mapping identified with said entry. 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. Proper interpretation of such entries requires examination of the relevant ipNetToPhysicalType object.
The 'dynamic(3)' type indicates that the IP address to physical addresses mapping has been dynamically resolved using e.g., IPv4 ARP or the IPv6 Neighbor Discovery protocol.
The 'static(4)' type indicates that the mapping has been statically configured. Both of these refer to entries that provide mappings for other entities addresses.
The 'local(5)' type indicates that the mapping is provided for an entity's own interface address.
As the entries in this table are typically not persistent when this object is written the entity SHOULD NOT save the change to non-volatile storage.
The Neighbor Unreachability Detection state for the interface when the address mapping in this entry is used. If Neighbor Unreachability Detection is not in use (e.g. for IPv4), this object is always unknown(6).
ipNetToPhysicalRowStatus
1.3.6.1.2.1.4.35.1.8
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
The status of this conceptual row.
The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified.
A conceptual row can not be made active until the ipNetToPhysicalPhysAddress object has been set.
Note that if the ipNetToPhysicalType is set to 'invalid', the managed node may delete the entry independent of the state of this object.
ipv6ScopeZoneIndexTable
1.3.6.1.2.1.4.36
Index: ipv6ScopeZoneIndexIfIndex
Reference: Section 2.7 of RFC 4291
The table used to describe IPv6 unicast and multicast scope zones.
For those objects that have names rather than numbers, the names were chosen to coincide with the names used in the IPv6 address architecture document.
ipv6ScopeZoneIndexIfIndex
1.3.6.1.2.1.4.36.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface to which these scopes belong. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipv6ScopeZoneIndexLinkLocal
1.3.6.1.2.1.4.36.1.2
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for the link-local scope on this interface.
ipv6ScopeZoneIndex3
1.3.6.1.2.1.4.36.1.3
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope 3 on this interface.
ipv6ScopeZoneIndexAdminLocal
1.3.6.1.2.1.4.36.1.4
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for the admin-local scope on this interface.
ipv6ScopeZoneIndexSiteLocal
1.3.6.1.2.1.4.36.1.5
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for the site-local scope on this interface.
ipv6ScopeZoneIndex6
1.3.6.1.2.1.4.36.1.6
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope 6 on this interface.
ipv6ScopeZoneIndex7
1.3.6.1.2.1.4.36.1.7
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope 7 on this interface.
ipv6ScopeZoneIndexOrganizationLocal
1.3.6.1.2.1.4.36.1.8
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for the organization-local scope on this interface.
ipv6ScopeZoneIndex9
1.3.6.1.2.1.4.36.1.9
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope 9 on this interface.
ipv6ScopeZoneIndexA
1.3.6.1.2.1.4.36.1.10
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope A on this interface.
ipv6ScopeZoneIndexB
1.3.6.1.2.1.4.36.1.11
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope B on this interface.
ipv6ScopeZoneIndexC
1.3.6.1.2.1.4.36.1.12
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The zone index for scope C on this interface.
ipv6ScopeZoneIndexD
1.3.6.1.2.1.4.36.1.13
InetZoneIndexA zone index identifies an instance of a zone of a specific scope.
The zone index MUST disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index (ifIndex as defined in the IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers to the default zone. The default zone may be used in cases where the valid zone index is not known (e.g., when a management application has to write a link-local IPv6 address without knowing the interface index value). The default zone SHOULD NOT be used as an easy way out in cases where the zone index for a non-global IPv6 address is known.Reference: RFC4007 · Unsigned32 · hint d
The table used to describe the default routers known to this entity.
ipDefaultRouterAddressType
1.3.6.1.2.1.4.37.1.1
InetAddressType0 = unknown1 = ipv42 = ipv63 = ipv4z4 = ipv6z16 = dnsA value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding InetAddress object is a zero-length string. It may also be used to indicate an IP address that is not in one of the formats defined below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be accompanied by a definition of a textual convention for use with that InetAddressType.
To support future extensions, the InetAddressType textual convention SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
Implementations must ensure that InetAddressType objects and any dependent objects (e.g., InetAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change an InetAddressType object would, for example, lead to an undefined InetAddress value. In particular, InetAddressType/InetAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1)). · Integer32
The address type for this row.
ipDefaultRouterAddress
1.3.6.1.2.1.4.37.1.2
InetAddressDenotes a generic Internet address.
An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object that provides the context. It is suggested that the InetAddressType object be logically registered before the object(s) that use the InetAddress textual convention, if they appear in the same logical row.
The value of an InetAddress object must always be consistent with the value of the associated InetAddressType object. Attempts to set an InetAddress object to a value inconsistent with the associated InetAddressType must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an index object, there may be issues with the limit of 128 sub-identifiers specified in SMIv2, STD 58. In this case, the object definition MUST include a 'SIZE' clause to limit the number of potential instance sub-identifiers; otherwise the applicable constraints MUST be stated in the appropriate conceptual row DESCRIPTION clauses, or in the surrounding documentation if there is no single DESCRIPTION clause that is appropriate. SIZE (0..255) · OCTET STRING
The IP address of the default router represented by this row. The address type of this object is specified in ipDefaultRouterAddressType.
Implementers need to be aware that if the size of ipDefaultRouterAddress exceeds 115 octets, then OIDS of instances of columns in this row will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.
ipDefaultRouterIfIndex
1.3.6.1.2.1.4.37.1.3
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface by which the router can be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipDefaultRouterLifetime
1.3.6.1.2.1.4.37.1.4
Unsigned32 (0..65535) · seconds
Reference: For IPv6 RFC 2462 sections 4.2 and 6.3.4
The remaining length of time, in seconds, that this router will continue to be useful as a default router. A value of zero indicates that it is no longer useful as a default router. It is left to the implementer of the MIB as to whether a router with a lifetime of zero is removed from the list.
For IPv6, this value should be extracted from the router advertisement messages.
An indication of preference given to this router as a default router as described in he Default Router Preferences document. Treating the value as a 2 bit signed integer allows for simple arithmetic comparisons.
For IPv4 routers or IPv6 routers that are not using the updated router advertisement format, this object is set to medium (0).
ipv6RouterAdvertTable
1.3.6.1.2.1.4.39
Index: ipv6RouterAdvertIfIndex
The table containing information used to construct router advertisements.
ipv6RouterAdvertIfIndex
1.3.6.1.2.1.4.39.1.1
InterfaceIndexA unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. (1..2147483647) · Integer32 · hint d
The index value that uniquely identifies the interface on which router advertisements constructed with this information will be transmitted. The interface identified by a particular value of this index is the same interface as identified by the same value of the IF-MIB's ifIndex.
ipv6RouterAdvertSendAdverts
1.3.6.1.2.1.4.39.1.2
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
Reference: RFC 2461 Section 6.2.1
A flag indicating whether the router sends periodic router advertisements and responds to router solicitations on this interface.
ipv6RouterAdvertMaxInterval
1.3.6.1.2.1.4.39.1.3
Unsigned32 (4..1800) · seconds
Reference: RFC 2461 Section 6.2.1
The maximum time allowed between sending unsolicited router advertisements from this interface.
ipv6RouterAdvertMinInterval
1.3.6.1.2.1.4.39.1.4
Unsigned32 (3..1350) · seconds
Reference: RFC 2461 Section 6.2.1
The minimum time allowed between sending unsolicited router advertisements from this interface.
The default is 0.33 * ipv6RouterAdvertMaxInterval, however, in the case of a low value for ipv6RouterAdvertMaxInterval, the minimum value for this object is restricted to 3.
ipv6RouterAdvertManagedFlag
1.3.6.1.2.1.4.39.1.5
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
Reference: RFC 2461 Section 6.2.1
The true/false value to be placed into the 'managed address configuration' flag field in router advertisements sent from this interface.
ipv6RouterAdvertOtherConfigFlag
1.3.6.1.2.1.4.39.1.6
TruthValue1 = true2 = falseRepresents a boolean value. · Integer32
Reference: RFC 2461 Section 6.2.1
The true/false value to be placed into the 'other stateful configuration' flag field in router advertisements sent from this interface.
ipv6RouterAdvertLinkMTU
1.3.6.1.2.1.4.39.1.7
Unsigned32
Reference: RFC 2461 Section 6.2.1
The value to be placed in MTU options sent by the router on this interface.
A value of zero indicates that no MTU options are sent.
ipv6RouterAdvertReachableTime
1.3.6.1.2.1.4.39.1.8
Unsigned32 (0..3600000) · milliseconds
Reference: RFC 2461 Section 6.2.1
The value to be placed in the reachable time field in router advertisement messages sent from this interface.
A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for reachable time.
ipv6RouterAdvertRetransmitTime
1.3.6.1.2.1.4.39.1.9
Unsigned32 · milliseconds
Reference: RFC 2461 Section 6.2.1
The value to be placed in the retransmit timer field in router advertisements sent from this interface.
A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for retrans time.
ipv6RouterAdvertCurHopLimit
1.3.6.1.2.1.4.39.1.10
Unsigned32 (0..255)
Reference: RFC 2461 Section 6.2.1
The default value to be placed in the current hop limit field in router advertisements sent from this interface. The value should be set to the current diameter of the Internet.
A value of zero in the router advertisement indicates that the advertisement isn't specifying a value for curHopLimit.
The default should be set to the value specified in the IANA web pages (www.iana.org) at the time of implementation.
ipv6RouterAdvertDefaultLifetime
1.3.6.1.2.1.4.39.1.11
Unsigned32 (0 | 4..9000) · seconds
Reference: RFC 2461 Section 6.2.1
The value to be placed in the router lifetime field of router advertisements sent from this interface. This value MUST be either 0 or between ipv6RouterAdvertMaxInterval and 9000 seconds.
A value of zero indicates that the router is not to be used as a default router.
The default is 3 * ipv6RouterAdvertMaxInterval.
ipv6RouterAdvertRowStatus
1.3.6.1.2.1.4.39.1.12
RowStatus1 = active2 = notInService3 = notReady4 = createAndGo5 = createAndWait6 = destroyThe RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is available for use by the managed device;
- `notInService', which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device (see NOTE below); 'notInService' has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the managed device;
- `notReady', which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device (i.e., one or more required columns in the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;
- `createAndWait', which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device); and, - `destroy', which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.
Whereas five of the six values (all except `notReady') may be specified in a management protocol set operation, only three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active'); it is not available for use by the managed device, though the agent has sufficient information to attempt to make it so (the status column has value `notInService'); or, it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified. That is, it is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be `active' in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU if the RowStatus would not be equal to `active' either immediately before or after processing the PDU. In other words, if the PDU also contained a varbind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to `active' as the PDU was received, or if the varbind sets the status to a value other than 'active'.
Also note that whenever any elements of a row exist, the RowStatus column must also exist.
To summarize the effect of having a conceptual row with a status column having a SYNTAX clause value of RowStatus, consider the following state diagram:
STATE +--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the agent.
(2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, and all columns have acceptable values, then return noError and goto D.
(3) if other variable bindings included in the same PDU, provide legal values for all columns which are missing but required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's value, or
noError: because the agent chooses to create the instance.
If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.
(5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following errors:
wrongValue: because the agent does not support notInService (e.g., an agent which does not support createAndWait), or
inconsistentValue: because the agent is unable to take the row out of service at this time, perhaps because it is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to remove the row at this time, perhaps because it is in use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the conceptual row are inconsistent, then the error code would be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the set request may result in a response other than noError being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any objects for which the agent does not supply a default; and, making the conceptual row available for use by the managed device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies for each conceptual row. In some cases, the instance- identifier is semantically significant, e.g., the destination address of a route, and a management station selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to distinguish conceptual rows, and a management station without specific knowledge of the conceptual row might examine the instances present in order to determine an unused instance-identifier. (This approach may be used, but it is often highly sub-optimal; however, it is also a questionable practice for a naive management station to attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row might provide one or more objects which provide assistance in determining an unused instance-identifier. For example, if the conceptual row is indexed by an integer-value, then an object having an integer-valued SYNTAX clause might be defined for such a purpose, allowing a management station to issue a management protocol retrieval operation. In order to avoid unnecessary collisions between competing management stations, `adjacent' retrievals of this object should be different.
Finally, the management station could select a pseudo-random number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in response to the management protocol set operation, the management station should simply select a new pseudo-random number and retry the operation.
A MIB designer should choose between the two latter algorithms based on the size of the table (and therefore the efficiency of each algorithm). For tables in which a large number of entries are expected, it is recommended that a MIB object be defined that returns an acceptable index for creation. For tables with small numbers of entries, it is recommended that the latter pseudo-random index mechanism be used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the management station determines if it wishes to create and activate the conceptual row in one transaction or in a negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column requirements, i.e., it must determine those columns for which it must or must not provide values. Depending on the complexity of the table and the management station's knowledge of the agent's capabilities, this determination can be made locally by the management station. Alternately, the management station issues a management protocol get operation to examine all columns in the conceptual row that it wishes to create. In response, for each column, there are three possible outcomes:
- a value is returned, indicating that some other management station has already created this conceptual row. We return to interaction 1.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it should supply a value for this column when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
Once the column requirements have been determined, a management protocol set operation is accordingly issued. This operation also sets the new instance of the status column to `createAndGo'.
When the agent processes the set operation, it verifies that it has sufficient information to make the conceptual row available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the conceptual row, and, implementation-specific defaults supplied by the agent (note that an agent must provide implementation-specific defaults for at least those objects which it implements as read-only). If there is sufficient information available, then the conceptual row is created, a `noError' response is returned, the status column is set to `active', and no further interactions are necessary (i.e., interactions 3 and 4 are skipped). If there is insufficient information, then the conceptual row is not created, and the set operation fails with an error of `inconsistentValue'. On this error, the management station can issue a management protocol retrieval operation to determine if this was because it failed to specify a value for a required column, or, because the selected instance of the status column already existed. In the latter case, we return to interaction 1. In the former case, the management station can re-issue the set operation with the additional information, or begin interaction 2 again using `createAndWait' in order to negotiate creation of the conceptual row.
NOTE WELL
Regardless of the method used to determine the column requirements, it is possible that the management station might deem a column necessary when, in fact, the agent will not allow that particular columnar instance to be created or written. In this case, the management protocol set operation will fail with an error such as `noCreation' or `notWritable'. In this case, the management station decides whether it needs to be able to set a value for that particular columnar instance. If not, the management station re-issues the management protocol set operation, but without setting a value for that particular columnar instance; otherwise, the management station aborts the row creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual Row
The management station issues a management protocol set operation which sets the desired instance of the status column to `createAndWait'. If the agent is unwilling to process a request of this sort, the set operation fails with an error of `wrongValue'. (As a consequence, such an agent must be prepared to accept a single management protocol set operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is returned, and the status column is immediately set to either `notInService' or `notReady', depending on whether it has sufficient information to (attempt to) make the conceptual row available for use by the managed device. If there is sufficient information available, then the status column is set to `notInService'; otherwise, if there is insufficient information, then the status column is set to `notReady'. Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column requirements. It issues a management protocol get operation to examine all columns in the created conceptual row. In the response, for each column, there are three possible outcomes:
- a value is returned, indicating that the agent implements the object-type associated with this column and had sufficient information to provide a value. For those columns to which the agent provides read-create access (and for which the agent allows their values to be changed after their creation), a value return tells the management station that it may issue additional management protocol set operations, if it desires, in order to change the value associated with this column.
- the exception `noSuchInstance' is returned, indicating that the agent implements the object-type associated with this column, and that this column in at least one conceptual row would be accessible in the MIB view used by the retrieval were it to exist. However, the agent does not have sufficient information to provide a value, and until a value is provided, the conceptual row may not be made available for use by the managed device. For those columns to which the agent provides read-create access, the `noSuchInstance' exception tells the management station that it must issue additional management protocol set operations, in order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating that the agent does not implement the object-type associated with this column or that there is no conceptual row for which this column would be accessible in the MIB view used by the retrieval. As such, the management station can not issue any management protocol set operations to create an instance of this column.
If the value associated with the status column is `notReady', then the management station must first deal with all `noSuchInstance' columns, if any. Having done so, the value of the status column becomes `notInService', and we proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values associated with the columns of the conceptual row, it issues a management protocol set operation to set the status column to `active'. If the agent has sufficient information to make the conceptual row available for use by the managed device, the management protocol set operation succeeds (a `noError' response is returned). Otherwise, the management protocol set operation fails with an error of `inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value `notInService' or `notReady' is unavailable to the managed device. As such, it is possible for the managed device to create its own instances during the time between the management protocol set operation which sets the status column to `createAndWait' and the management protocol set operation which sets the status column to `active'. In this case, when the management protocol set operation is issued to set the status column to `active', the values held in the agent supersede those used by the managed device.
If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station may issue a management protocol set operation which sets the instance of the status column to `notInService'. If the agent is unwilling to do so, the set operation fails with an error of `wrongValue' or `inconsistentValue'. Otherwise, the conceptual row is taken out of service, and a `noError' response is returned. It is the responsibility of the DESCRIPTION clause of the status column to indicate under what circumstances the status column should be taken out of service (e.g., in order for the value of some other column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set operation is issued which sets the instance of the status column to `destroy'. This request may be made regardless of the current value of the status column (e.g., it is possible to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are immediately removed. · Integer32
The status of this conceptual row.
As all objects in this conceptual row have default values, a row can be created and made active by setting this object appropriately.
The RowStatus TC requires that this DESCRIPTION clause states under which circumstances other objects in this row can be modified. The value of this object has no effect on whether other objects in this conceptual row can be modified.
icmpStatsTable
1.3.6.1.2.1.5.29
Index: icmpStatsIPVersion
The table of generic system-wide ICMP counters.
icmpStatsIPVersion
1.3.6.1.2.1.5.29.1.1
InetVersion0 = unknown1 = ipv42 = ipv6A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose.Reference: RFC 791, RFC 2460 · Integer32
The IP version of the statistics.
icmpStatsInMsgs
1.3.6.1.2.1.5.29.1.2
Counter32
The total number of ICMP messages that the entity received. Note that this counter includes all those counted by icmpStatsInErrors.
icmpStatsInErrors
1.3.6.1.2.1.5.29.1.3
Counter32
The number of ICMP messages that the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.).
icmpStatsOutMsgs
1.3.6.1.2.1.5.29.1.4
Counter32
The total number of ICMP messages that the entity attempted to send. Note that this counter includes all those counted by icmpStatsOutErrors.
icmpStatsOutErrors
1.3.6.1.2.1.5.29.1.5
Counter32
The number of ICMP messages that this entity did not send due to problems discovered within ICMP, such as a lack of buffers. This value should not include errors discovered outside the ICMP layer, such as the inability of IP to route the resultant datagram. In some implementations, there may be no types of error that contribute to this counter's value.
icmpMsgStatsTable
1.3.6.1.2.1.5.30
Index: icmpMsgStatsIPVersion · icmpMsgStatsType
The table of system-wide per-version, per-message type ICMP counters.
icmpMsgStatsIPVersion
1.3.6.1.2.1.5.30.1.1
InetVersion0 = unknown1 = ipv42 = ipv6A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to distinguish different address types associated with IP protocols. The InetAddressType has been designed for this purpose.Reference: RFC 791, RFC 2460 · Integer32
The IP version of the statistics.
icmpMsgStatsType
1.3.6.1.2.1.5.30.1.2
Integer32 (0..255)
Reference: http://www.iana.org/assignments/icmp-parameters and http://www.iana.org/assignments/icmpv6-parameters
The ICMP type field of the message type being counted by this row.
Note that ICMP message types are scoped by the address type in use.
icmpMsgStatsInPkts
1.3.6.1.2.1.5.30.1.3
Counter32
The number of input packets for this AF and type.
icmpMsgStatsOutPkts
1.3.6.1.2.1.5.30.1.4
Counter32
The number of output packets for this AF and type.