3.2.3. IP Statistics Tables
3.2.3. IP Statistics Tables
The IP statistics tables (ipSystemStatsTable and ipIfStatsTable) contain objects to count the number of datagrams and octets that a given entity has processed. Unlike the previous attempt, this document uses a single table for multiple address types. Typically the only two types of interest are IPv4 and IPv6; however, the table can support other types if necessary.
The first table, ipSystemStatsTable, conveys system wide information. (That is, the various counters are for all interfaces and not a specific set of interfaces.) Its index is formed from a single sub-id that represents the address type for which the statistics were counted.
The second table, ipIfStatsTable, conveys interface specific information. Its index is formed from two sub-ids. The first represents the address type (IPv4 and IPv6), and the interface within that address type is represented by the second sub-id.
The two tables have a similar set of objects that are intended to count the same things, except for the difference in granularity. The object ID "ipSystemStatsEntry.2" is reserved in order to align the object IDs of the counters in the first table with their counterparts in the second table.
Several objects to note are ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate, and ipIfStatsRefreshRate. These objects provide information about the row in the table more than about the system itself.
The discontinuity objects allow a management entity to determine if a discontinuity event that would invalidate the management entity's understanding of the counters has occurred. The system being re-initialized or the interface being cycled are possible examples of a discontinuity event.
The refresh objects allow a management entity to determine a proper polling interval for the rest of the objects.
Packet Counter Flow Diagram
The following diagram represents the general ordering of the packet counters. The prefixes "ipSystemStats" and "ipIfStats" have been removed from counter names for clarity:
from from
interface upper
layers
V V
| |
+ InReceives (1) + OutRequests
| |
| |
+--> InHdrErrors (5) +--> OutNoRoutes
| |
| |
+-->-+ InMcastPkts (1) |
| V |
+<--+ |
| |
+-->-+ InBcastPkts (1) |
| V |
+<--+ |
| |
| |
+--> InTruncatedPkts (5) |
| |
| |
+--> InAddrErrors |
| |
| |
+--> InDiscards (2) |
| |
| |
+--------+------>------+----->-----+----->-----+
| InForwDatagrams (6) | OutForwDatagrams (6)|
| V +-->-+ OutFragReqds
| InNoRoutes | | (packets)
/ (local packet (3) | |
| IF is that of the address | +--> OutFragFails
| and may not be the receiving IF) | | (packets)
| | |
| | V OutFragOks
| | | (packets) (7)
| | |
+-->-+ ReasmReqds (fragments) +<--+ OutFragCreates
| | | (fragments)
| | |
| +--> ReasmFails (fragments (4)) +-->-+ OutMcastPkts (1)
| | | V
| | +<--+
+<--+ ReasmOKs (reassembled packets) |
| +-->-+ OutBcastPkts (1)
| | V
+--> InUnknownProtos +<--+
| |
| |
+--> InDiscards (2) +--> OutDiscards (2)
| |
| |
+ InDelivers + OutTransmits (1)
| |
V V
to to
upper interface
layers
Notes
-
The HC counters and octet counters are also found at these points but have been left out for clarity.
-
The discard counters may increment at any time in the processing path. Packets discarded to the left of InNoRoutes cause the InDiscards counter to increment, while those discarded to the right are counted in the OutDiscards counters.
-
Local packets on the input side are counted on the interface associated with their destination address, which may not be the interface on which they were received. This requirement is caused by the possibility of losing the original interface during processing, especially re-assembly.
-
Some re-assembly algorithms may lose track of the number of fragments during processing and so some fragments may not be counted in this object.
-
InTruncatedPkts should only be incremented if the frame contained a valid header but was otherwise shorter than required. Frames that are too short to contain a valid header should be counted as InHdrErrors.
-
The forwarding objects may be incremented, even for packets that originated locally or are destined for the local host, if their addresses are such that the local host would need to forward the packet to pass it to the correct interface.
-
When fragmenting a packet, an entity should increment the OutFragFails counter, rather than the OutDiscards counter, in order to preserve the equation FragOks + FragFails == FragRqds.
The objects in both tables are spread amongst several conformance groups based on the bandwidth required to wrap the counters within an hour. The base system group is mandatory for all entities. The other system groups are optional depending on bandwidth. The interface specific-groups are optional.