IP Forwarding MIB: IP Forwarding Table MIB
SNMP objects for managing a router's routing table and multi-path routes
Baker, F., "IP Forwarding Table MIB", RFC 1354, DOI 10.17487/RFC1354, July 1992, <https://www.rfc-editor.org/info/rfc1354>.
@misc{rfc1354,
series = {Request for Comments},
number = 1354,
howpublished = {RFC 1354},
publisher = {RFC Editor},
doi = {10.17487/RFC1354},
url = {https://www.rfc-editor.org/info/rfc1354},
author = {F. Baker},
title = {{IP Forwarding Table MIB}},
pagetotal = 12,
year = 1992,
month = jul,
} RFC text
Contents
Network Working Group F. Baker
Request For Comments: 1354 ACC
July 1992
IP Forwarding Table MIB
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing routes in the IP
Internet.
It is proposed that the ipRouteTable defined by MIB-II (RFC 1213) be
deprecated and replaced with this table. This adds the ability to
set or display multi-path routes, and varying routes by network
management policy.
Table of Contents
1. The Network Management Framework ............................ 1
2. Objects ..................................................... 2
2.1 Format of Definitions ...................................... 2
3. Overview .................................................... 3
3.1 Structure of MIB ........................................... 3
4. Definitions ................................................. 4
4.1 IP Forwarding Table ........................................ 4
5. Acknowledgements ............................................ 11
6. References .................................................. 11
7. Security Considerations........................................ 12
8. Author's Address............................................... 12
1. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212 defines a
more concise description mechanism, which is wholly consistent with
the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for the
Internet suite of protocols. RFC 1213 defines MIB-II, an evolution
of MIB-I based on implementation experience and new operational
requirements.
RFC 1157 which defines the SNMP, the protocol used for network access
to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
2. Objects
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
this purpose. However, the SMI [3] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP.
2.1. Format of Definitions
Section 4 contains contains the specification of all object types
contained in this MIB module. The object types are defined using the
conventions defined in the SMI, as amended by the extensions
specified in [9].
3. Overview
3.1. Structure of MIB
The IP Forwarding Table is quite analogous to the older ipRoute
Table. The principal differences are:
(1) It is somewhat re-organized, for aesthetic reasons,
(2) It has the Next Hop Autonomous System Number, useful
primarily to the administrators of regional networks,
(3) It is instanced by Policy and Next Hop as well as by
ultimate destination. Thus, multiple multipath routes
can be managed, not just a single route, along with the
circumstances under which the any given route might be
chosen.
4. Definitions
RFC1354-MIB DEFINITIONS ::= BEGIN
IMPORTS
Gauge, IpAddress
FROM RFC1155-SMI
mib-2, ip
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9].
ipForward OBJECT IDENTIFIER ::= { ip 24 }
ipForwardNumber OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of current ipForwardTable entries
that are not invalid."
::= { ipForward 1 }
-- IP Forwarding Table
-- The IP Forwarding Table obsoletes and replaces the ipRoute
-- Table current in MIB-I and MIB-II. It adds knowledge of
-- the autonomous system of the next hop, multiple next hop
-- support, and policy routing support.
ipForwardTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpForwardEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"This entity's IP Routing table."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 2 }
ipForwardEntry OBJECT-TYPE
SYNTAX IpForwardEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"A particular route to a particular destina-
tion, under a particular policy."
INDEX {
ipForwardDest,
ipForwardProto,
ipForwardPolicy,
ipForwardNextHop
}
::= { ipForwardTable 1 }
IpForwardEntry ::=
SEQUENCE {
ipForwardDest
IpAddress,
ipForwardMask
IpAddress,
ipForwardPolicy
INTEGER,
ipForwardNextHop
IpAddress,
ipForwardIfIndex
INTEGER,
ipForwardType
INTEGER,
ipForwardProto
INTEGER,
ipForwardAge
INTEGER,
ipForwardInfo
OBJECT IDENTIFIER,
ipForwardNextHopAS
INTEGER,
ipForwardMetric1
INTEGER,
ipForwardMetric2
INTEGER,
ipForwardMetric3
INTEGER,
ipForwardMetric4
INTEGER,
ipForwardMetric5
INTEGER
}
ipForwardDest OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The destination IP address of this route. An
entry with a value of 0.0.0.0 is considered a
default route.
This object may not take a Multicast (Class D)
address value.
Any assignment (implicit or otherwise) of an
instance of this object to a value x must be
rejected if the bitwise logical-AND of x with
the value of the corresponding instance of the
ipForwardMask object is not equal to x."
::= { ipForwardEntry 1 }
ipForwardMask OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to
the value in the ipForwardDest field. For
those systems that do not support arbitrary
subnet masks, an agent constructs the value of
the ipForwardMask by reference to the IP Ad-
dress Class.
Any assignment (implicit or otherwise) of an
instance of this object to a value x must be
rejected if the bitwise logical-AND of x with
the value of the corresponding instance of the
ipForwardDest object is not equal to ipForward-
Dest."
DEFVAL { '00000000'h } -- 0.0.0.0
::= { ipForwardEntry 2 }
-- The following convention is included for specification
-- of TOS Field contents. At this time, the Host Requirements
-- and the Router Requirements documents disagree on the width
-- of the TOS field. This mapping describes the Router
-- Requirements mapping, and leaves room to widen the TOS field
-- without impact to fielded systems.
ipForwardPolicy OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The general set of conditions that would cause
the selection of one multipath route (set of
next hops for a given destination) is referred
to as 'policy'.
Unless the mechanism indicated by ipForwardPro-
to specifies otherwise, the policy specifier is
the IP TOS Field. The encoding of IP TOS is as
specified by the following convention. Zero
indicates the default path if no more specific
policy applies.
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30
Protocols defining 'policy' otherwise must ei-
ther define a set of values which are valid for
this object or must implement an integer-
instanced policy table for which this object's
value acts as an index."
::= { ipForwardEntry 3 }
ipForwardNextHop OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"On remote routes, the address of the next sys-
tem en route; Otherwise, 0.0.0.0."
::= { ipForwardEntry 4 }
ipForwardIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The ifIndex value which identifies the local
interface through which the next hop of this
route should be reached."
DEFVAL { 0 }
::= { ipForwardEntry 5 }
ipForwardType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
invalid (2), -- logically deleted
local (3), -- local interface
remote (4) -- remote destination
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The type of route. Note that local(3) refers
to a route for which the next hop is the final
destination; remote(4) refers to a route for
which the next hop is not the final destina-
tion.
Setting this object to the value invalid(2) has
the effect of invalidating the corresponding
entry in the ipForwardTable object. That is,
it effectively disassociates the destination
identified with said entry from the route iden-
tified 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 current-
ly in use. Proper interpretation of such en-
tries requires examination of the relevant ip-
ForwardType object."
DEFVAL { invalid }
::= { ipForwardEntry 6 }
ipForwardProto OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
is-is (9), -- Dual IS-IS
es-is (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15) -- InterDomain Policy Routing
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The routing mechanism via which this route was
learned. Inclusion of values for gateway rout-
ing protocols is not intended to imply that
hosts should support those protocols."
::= { ipForwardEntry 7 }
ipForwardAge OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"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."
DEFVAL { 0 }
::= { ipForwardEntry 8 }
ipForwardInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol which is responsi-
ble for this route, as determined by the value
specified in the route's ipForwardProto value.
If this information is not present, its value
should be set to the OBJECT IDENTIFIER { 0 0 },
which is a syntactically valid object identif-
ier, and any implementation conforming to ASN.1
and the Basic Encoding Rules must be able to
generate and recognize this value."
DEFVAL { { 0 0 } } -- 0.0
::= { ipForwardEntry 9 }
ipForwardNextHopAS OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The Autonomous System Number of the Next Hop.
When this is unknown or not relevant to the
protocol indicated by ipForwardProto, zero."
DEFVAL { 0 }
::= { ipForwardEntry 10 }
ipForwardMetric1 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The primary routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
ipForwardProto value. If this metric is not
used, its value should be set to -1."
DEFVAL { -1 }
::= { ipForwardEntry 11 }
ipForwardMetric2 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
ipForwardProto value. If this metric is not
used, its value should be set to -1."
DEFVAL { -1 }
::= { ipForwardEntry 12 }
ipForwardMetric3 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
ipForwardProto value. If this metric is not
used, its value should be set to -1."
DEFVAL { -1 }
::= { ipForwardEntry 13 }
ipForwardMetric4 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
ipForwardProto value. If this metric is not
used, its value should be set to -1."
DEFVAL { -1 }
::= { ipForwardEntry 14 }
ipForwardMetric5 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
DESCRIPTION
"An alternate routing metric for this route.
The semantics of this metric are determined by
the routing-protocol specified in the route's
ipForwardProto value. If this metric is not
used, its value should be set to -1."
DEFVAL { -1 }
::= { ipForwardEntry 15 }
END
5. Acknowledgements
This document was produced by the Router Requirements Working Group,
of which Phil Almquist is the chair.
Chris Gunner (DEC) and Keith McCloghrie (Hughes LAN Systems) made
significant comments on it, and it is better for their input.
6. References
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", RFC
1213, Performance Systems International, March 1991.
[7] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems,
March 1991.
[10] McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", RFC
1213, Performance Systems International, March 1991.
[11] Baker, F., and R. Coltun, "OSPF Version 2 Management Information
Base", RFC 1253, ACC, Computer Science Center, August 1991.
7. Security Considerations
Security issues are not discussed in this memo.
8. Author's Address
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, CA 93117-6014
Phone: (805) 685-4455
EMail: fbaker@acc.com
AI ELI5
On this page
§1The IP Forwarding Table
SNMP (Simple Network Management Protocol) lets network management systems monitor and control network devices. A Management Information Base (MIB) defines the objects that management systems can read and modify using SNMP. RFC 1213 (MIB-II) defined the ipRouteTable for managing routes, but it had limitations: it could only represent a single route per destination and did not support policy-based routing.
This RFC defines a replacement table, the ipForwardTable, that improves on MIB-II by adding support for multi-path routes (multiple next hops for the same destination), policy-based routing (choosing a path based on packet characteristics like Type of Service), and Autonomous System numbers of the next hop (useful for operators managing regional networks).
The old routing table could only remember one way to get somewhere. The new table can remember many ways, and remember which way to pick depending on what kind of traffic it is.
§2SNMP and MIB Framework
Managed objects in the MIB are described using the Structure of Management Information (SMI), a subset of Abstract Syntax Notation One (ASN.1). Each object has a name (an object identifier), a syntax (data type), and an encoding rule for transmission over the network.
The ipForwardTable follows the standard SNMP conventions. It is a table where each row represents a single route. The table is indexed by the destination address, routing protocol, policy, and next-hop address. This multi-level index allows the SNMP manager to retrieve specific routes or iterate through all routes efficiently.
Each row contains a sequence structure called IpForwardEntry with up to 15 fields describing the route: the destination, the subnet mask, the policy identifier, the next-hop address, the outgoing interface, the route type (local or remote), the routing protocol, the age of the route, metrics, and the Autonomous System number.
SNMP uses a standard way to describe things routers know about. Each route is a row in a table, like a row in a spreadsheet, with columns for where it goes, how to get there, and why the router chose that way.
§3Table Entries and Fields
The ipForwardTable contains one entry (IpForwardEntry) for each distinct route. A route is identified by four keys: ipForwardDest (destination IP address, with 0.0.0.0 as the default route), ipForwardMask (the subnet mask, ANDed with the destination to determine the network prefix), ipForwardPolicy (a policy identifier, typically based on the IP Type of Service field, which can be 0 for default or 0-30 for other policies), and ipForwardNextHop (the address of the next router).
Additional fields include: ipForwardIfIndex (the outgoing interface), ipForwardType (local, remote, invalid, or other), ipForwardProto (the source protocol: static, RIP, OSPF, BGP, and others), ipForwardAge (seconds since last update), and five metric fields (ipForwardMetric1 through ipForwardMetric5) whose meaning depends on the routing protocol.
Each field is marked as read-only (for automatic values) or read-write (for configuration). A special field, ipForwardInfo, is an object identifier that points to protocol-specific MIB definitions when available.
Each route record says where the packet goes, which way to get there, which router told us about it, and how good that path is. Some fields can be read, some can be changed, and some are just for information.
§4Policy-Based Routing
The ipForwardPolicy field encodes routing policies, primarily the IP Type of Service (TOS) field. The TOS field is an 8-bit value in the IP header: the first 3 bits are Precedence (priority level) and the next 4 bits are Type of Service (cost, delay, reliability, throughput). The remaining bit is reserved.
Policy code 0 represents the default path when no more specific policy applies. Other policy codes (2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30) map to specific TOS values. Different routing protocols can define their own policy values when the TOS-based encoding is not sufficient; in such cases, a separate policy table may be defined.
This allows a router to have multiple routes to the same destination and choose which one to use based on the characteristics of the traffic, such as routing high-priority traffic over an expensive link and best-effort traffic over a cheaper one.
A router can have different rules for different kinds of traffic. Important traffic might go one way, cheap traffic another way. The policy number says which rule to use.
§5Multi-Path Routes
The key innovation of this MIB is support for multiple routes to the same destination. In the older ipRouteTable, only one route per destination was allowed. Here, if a router has two or more equal-cost paths to the same destination (for example, via two different neighbor routers), it can represent both by creating two rows in the ipForwardTable, each with the same destination and mask but a different next-hop address.
The combination of destination, mask, policy, and next hop as the table index ensures that all unique routes are captured without collision. The ipForwardNumber scalar object indicates how many routes are currently active (not marked invalid).
Multi-path routing is especially useful for load balancing, redundancy, and traffic engineering in modern networks. The table structure makes it straightforward to inspect and manage these multiple alternatives using SNMP.
If there are two equally good ways to get somewhere, the router can use both. Each one is a separate row, so the management program can see all of them.