rfc-2096

IP Forwarding Table MIB

F. Baker
date1997-01 streamIETF areartg wgospf statusPROPOSED STANDARD pages21 canonicalhttps://www.rfc-editor.org/rfc/rfc2096 doi10.17487/RFC2096
This memo defines an update to RFC 1354. The significant difference between this MIB and RFC 1354 is the recognition (explicitly discussed but by consensus left to future work) that CIDR routes may have the same network number but different network masks. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (24)

design-rationale §4

The reject(2) route type, which discards matching traffic as unreachable, is used in some routing protocols as a mechanism for correctly aggregating routes — providing a black-hole for address space covered by a summary but not by any specific route.

routing, ip

design-rationale §1

The significant difference between RFC 2096 and RFC 1354 is explicit recognition that CIDR routes may have the same network number but different network masks. RFC 1354 discussed this but by consensus left it to future work; this MIB addresses it.

routing, ip

design-rationale §4

The TOS field encoding convention was chosen to match the Router Requirements document mapping (not Host Requirements, which disagrees on TOS field width) and leaves room to widen the TOS field without impact to deployed systems.

routing, ip, qos

interoperability-note §1

RFC 2096 obsoletes RFC 1354 in its entirety. Implementors should note that several objects defined in RFC 1354 are explicitly marked obsolete here and should not be used in new implementations.

routing, ip

interoperability-note §3

The ipCidrRouteTable obsoletes both the RFC 1213 ipRouteTable (MIB-I/II) and the ipForwardTable from RFC 1354. The older ipForwardTable and its associated objects are marked STATUS obsolete in this MIB module.

routing, ip

normative-requirement §4 MUST NOT

Any assignment of ipCidrRouteDest to value x must be rejected if the bitwise logical-AND of x with the corresponding ipCidrRouteMask is not equal to x. This enforces consistency between destination address and mask.

routing, ip

normative-requirement §4 MUST NOT

Any assignment of ipCidrRouteMask to value x must be rejected if the bitwise logical-AND of x with the corresponding ipCidrRouteDest is not equal to ipCidrRouteDest. This prevents masks inconsistent with the route destination.

routing, ip

normative-requirement §4 REQUIRED

SNMPv2 entities implementing the ipForward MIB must conform to ipForwardCompliance, which mandates the ipForwardCidrRouteGroup containing all ipCidrRoute* objects.

routing, ip, snmp

protocol-element §4

ipCidrRouteAge (Integer32, read-only, default 0) counts seconds since the route was last updated or confirmed correct. No 'too old' semantics are implied; interpretation requires knowledge of the routing protocol.

routing, ip

protocol-element §4

ipCidrRouteDest (IpAddress, read-only) is the destination IP address of a route. Multicast (Class D) addresses are not permitted. Any assigned value x must satisfy: x AND ipCidrRouteMask == x.

routing, ip

protocol-element §4

ipCidrRouteEntry is indexed by four fields: ipCidrRouteDest (destination address), ipCidrRouteMask (subnet mask), ipCidrRouteTos (TOS/policy), and ipCidrRouteNextHop. This four-part index uniquely identifies a route under a particular policy.

routing, ip

protocol-element §4

ipCidrRouteInfo (OBJECT IDENTIFIER, read-create) references MIB definitions specific to the routing protocol responsible for the route. When absent, it must be set to { 0 0 }, which every ASN.1/BER implementation must be able to generate and recognize.

routing, ip

protocol-element §4

ipCidrRouteMask (IpAddress, read-only) is the subnet mask to be AND-ed with the destination address before comparing to ipCidrRouteDest. Systems not supporting arbitrary subnet masks construct this value by reference to IP Address Class.

routing, ip

protocol-element §4

ipCidrRouteMetric1 through ipCidrRouteMetric5 (Integer32, read-create, default -1) hold up to five routing metrics whose semantics are determined by ipCidrRouteProto. Unused metrics must be set to -1.

routing, ip

protocol-element §4

ipCidrRouteNextHop (IpAddress, read-only) is the address of the next system for remote routes; set to 0.0.0.0 for locally-reachable destinations.

routing, ip

protocol-element §4

ipCidrRouteNextHopAS (Integer32, read-create, default 0) carries the Autonomous System Number of the next hop. Its semantics depend on ipCidrRouteProto; set to zero when unknown or irrelevant.

routing, ip, bgp

protocol-element §4

ipCidrRouteNumber (Gauge32, read-only) reports the count of current ipCidrRouteTable entries that are not invalid, providing a way to determine route count without scanning the entire table.

routing, ip

protocol-element §4

ipCidrRouteProto (INTEGER, read-only) identifies the routing protocol that installed the route, with values for other(1), local(2), netmgmt(3), icmp(4), and dynamic protocols including egp, rip, ospf(13), bgp(14), and ciscoEigrp(16).

routing, ip, bgp

protocol-element §4

ipCidrRouteStatus (RowStatus, read-create) is the standard SNMPv2 row status variable governing row installation and removal in the ipCidrRouteTable.

routing, ip

protocol-element §4

ipCidrRouteTable is the primary CIDR-aware IP routing table. It obsoletes and replaces both the RFC 1213 ipRouteTable and the ipForwardTable from RFC 1354, adding support for CIDR routes with identical network numbers but differing masks.

routing, ip, snmp

protocol-element §4

ipCidrRouteTos (Integer32, read-only) encodes the IP TOS field as the policy specifier for multipath route selection. Zero indicates the default path. The encoding maps 8-bit TOS bytes to integer policy codes per a specific table.

routing, ip, qos

protocol-element §4

ipCidrRouteType (INTEGER, read-create) classifies each route as other(1), reject(2), local(3), or remote(4). Routes not resulting in forwarding or rejection should not be displayed even if stored internally.

routing, ip

protocol-element §4

ipForwardTable (STATUS obsolete) was the RFC 1354 multipath routing table, indexed by {ipForwardDest, ipForwardProto, ipForwardPolicy, ipForwardNextHop}. It is superseded by ipCidrRouteTable and retained here only for backward compatibility documentation.

routing, ip

security-consideration §7

The Security Considerations section states that security is explicitly not an objective of this MIB view. No access controls, authentication, or authorization mechanisms for route table management are defined in this document.

security, routing