Module rasn_mib::ip

source ·
Expand description

The Internet Protocol (IP) Group

Implementation of the IP group is mandatory for all systems.

Structs§

  • The IP address to which this entry’s addressing information pertains.
  • The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry.
  • 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 interfaces::Index.
  • The subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0.
  • The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface.
  • The addressing information for one of this entity’s IP addresses.
  • The table of addressing information relevant to this entity’s IP addresses.
  • The default value inserted into the “Time-To-Live” field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol.
  • The number of input datagrams for which this entity was not their final IP 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 IP Gateways, this counter will include only those packets which were “Source-Routed” via this entity, and the Source-Route option processing was successful.
  • The indication of whether this entity is acting as an IP gateway in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP gateways forward datagrams. IP hosts do not (except those source-routed via the host).
  • The number of IP datagram fragments that have been generated as a result of fragmentation at this entity.
  • The number of IP 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.
  • The number of IP datagrams that have been successfully fragmented at this entity.
  • The number of input 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.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address.
  • The total number of input datagrams successfully delivered to IP user-protocols (including ICMP).
  • The number of input IP 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.
  • The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc.
  • The total number of input datagrams received from interfaces, including those received in error.
  • The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol.
  • A reference to MIB definitions specific to the particular routing
  • 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 interfaces::Index.
  • The IpAddress corresponding to the media-dependent NetToMediaPhysAddress.
  • The media-dependent “physical” address.
  • A reference to MIB definitions specific to the particular routing
  • The type of mapping.
  • The number of output IP 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 ForwDatagrams if any such packets met this (discretionary) discard criterion.
  • The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ForwDatagrams which meet this `no-route’ criterion. Note that this includes any datagrams which a host cannot route because all of its default gateways are down.
  • The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ForwDatagrams.
  • 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.
  • The number of IP datagrams successfully re-assembled.
  • The number of IP fragments received which needed to be reassembled at this entity.
  • The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity.
  • The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of “too old” can be implied except through knowledge of the routing protocol by which the route was learned.
  • The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default route. Multiple routes to a single destination can appear in the table, but access to such multiple entries is dependent on the table-access mechanisms defined by the network management protocol in use.
  • A router to a particular destination.
  • The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of interfaces::Index.
  • A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route’s RouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntactically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value.
  • Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the RouteDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the RouteMask by determining whether the value of the correspondent RouteDest field belong to a class-A, B, or C network, and then using one of:
  • The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route’s ipRouteProto value. If this metric is not used, its value should be set to -1.
  • An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route’s RouteProto value. If this metric is not used, its value should be set to -1.
  • An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route’s RouteProto value. If this metric is not used, its value should be set to -1.
  • An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route’s RouteProto value. If this metric is not used, its value should be set to -1.
  • An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route’s RouteProto value. If this metric is not used, its value should be set to -1.
  • The IP address of the next hop of this route. (In the case of a route bound to an interface which is realized via a broadcast media, the value of this field is the agent’s IP address on that interface.)
  • The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols.
  • The type of route. Note that the values Self::DIRECT and [Self::INDIRECT] refer to the notion of direct and indirect routing in the IP architecture.
  • 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 entity’s IP Routing table.