Subject: Re: [MIB-DOCTORS] quick routeTable question

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Mar 2008 06:07:10 -0700

Cole, Robert G. wrote:
> Andy,

Hi,

I am forwarding to the MIB Doctors because I am not sure
of the answer, and I'm too jet-lagged to figure it out....

Andy

> My question has to do with what is returned from the MIB-II IpGroup
> routing table (an extract of RFC1213 is below).
> 
> Suppose I have three entries:
> 
> IpRouteDest    IpRouteMask
> a.0.0.0        /8
> a.b.0.0        /16
> a.b.c.0        /24
> 
> I enter a query to the table, indexed with a.b.x.0  where x not equal to c.
> The way I read the MIB, it would return the first two entries.  True?
> 
> What would I have to change if I only wanted a match only on
> a.b.0.0 entry, which is the longest prefix match?
> 
> Thanks,
> Bob
> 
> 
> 
> extracted from RFC 1213 - MIB-II IpGroup
> -------------------------------------------
>           -- the IP routing table
> 
>           -- The IP routing table contains an entry for each route
>           -- presently known to this entity.
> 
>           ipRouteTable OBJECT-TYPE
>               SYNTAX  SEQUENCE OF IpRouteEntry
>               ACCESS  not-accessible
>               STATUS  mandatory
>               DESCRIPTION
>                       "This entity's IP Routing table."
>               ::= { ip 21 }
> 
>           ipRouteEntry OBJECT-TYPE
>               SYNTAX  IpRouteEntry
>               ACCESS  not-accessible
>               STATUS  mandatory
>               DESCRIPTION
>                       "A route to a particular destination."
>               INDEX   { ipRouteDest }
>               ::= { ipRouteTable 1 }
> 
>           IpRouteEntry ::=
>               SEQUENCE {
>                   ipRouteDest
>                       IpAddress,
>                   ipRouteIfIndex
>                       INTEGER,
>                   ipRouteMetric1
>                       INTEGER,
>                   ipRouteMetric2
>                       INTEGER,
>                   ipRouteMetric3
>                       INTEGER,
>                   ipRouteMetric4
>                       INTEGER,
>                   ipRouteNextHop
>                       IpAddress,
>                   ipRouteType
>                       INTEGER,
>                   ipRouteProto
>                       INTEGER,
>                   ipRouteAge
>                       INTEGER,
>                   ipRouteMask
>                       IpAddress,
>                   ipRouteMetric5
>                       INTEGER,
>                   ipRouteInfo
>                       OBJECT IDENTIFIER
>               }
> 
>           ipRouteDest OBJECT-TYPE
>               SYNTAX  IpAddress
>               ACCESS  read-write
>               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.  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."
>               ::= { ipRouteEntry 1 }
> 
> .... (objects removed)
> 
>           ipRouteMask 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 ipRouteDest field.  For those systems
>                       that do not support arbitrary subnet masks, an
>                       agent constructs the value of the ipRouteMask by
>                       determining whether the value of the correspondent
>                       ipRouteDest field belong to a class-A, B, or C
>                       network, and then using one of:
> 
>                            mask           network
>                            255.0.0.0      class-A
>                            255.255.0.0    class-B
>                            255.255.255.0  class-C
> 
>                       If the value of the ipRouteDest is 0.0.0.0 (a
>                       default route), then the mask value is also
>                       0.0.0.0.  It should be noted that all IP routing
>                       subsystems implicitly use this mechanism."
>               ::= { ipRouteEntry 11 }
> 
> 
> 

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Mar 2008 16:50:07 -0700 (PDT)

> > routing table (an extract of RFC1213 is below).

First allow me to point out that ipRouteTable was obsoleted in 1992 
by ipForwardTable (RFC 1354), to alleviate the major shortcoming 
that ipRouteTable could not contain more than one ipRouteEntry for a 
given destination (and so, e.g., could not represent the routing 
tables on a host with more than one default router on a given link). 
Next, both ipRouteTable and ipForwardTable suffer from the defect 
that neither one works properly with classless IPv4 addressing.  
Think what happens in your example below if "b"  happens to be zero, 
which is quite legitimate if datagrams with destinations of the form 
a.x.y.z with x <> 0 and y <> c are to be routed differently than 
datagrams with destinations of the form a.0.y.z with y <> c, which 
is a legitimate example of CIDR "hole punching".  To solve this 
problem RFC 2096 introduced ipCidrRouteTable in 1997.  But this 
table only supports IPv4, so RFC 4292 introduced inetCidrRouteTable 
to support both IPv4 and IPv6.

Quoting from ftp://ftp.isi.edu/in-notes/rfc-index.txt:

1354 IP Forwarding Table MIB. F. Baker. July 1992. (Format: TXT=24905
     bytes) (Obsoleted by RFC2096) (Status: PROPOSED STANDARD)

2096 IP Forwarding Table MIB. F. Baker. January 1997. (Format:
     TXT=35930 bytes) (Obsoletes RFC1354) (Obsoleted by RFC4292) (Status:
     PROPOSED STANDARD)

4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format:
     TXT=69321 bytes) (Obsoletes RFC2096) (Status: PROPOSED STANDARD)

OK, enough unhelpful admonitions, I'll now try to answer the questions.

> > The way I read the MIB, it would return the first two entries.  True?

No.  If you send a GetRequest-PDU then you will receive a 
Response-PDU with a noSuchInstance exception code (or a 
GetResponse-PDU with a noSuchName error code).  If you send a 
GetNextRequest-PDU then you'll get the 3rd entry if 0 < x < c or an 
exception/error (if there are no more table entries) if x > c.

> > a.b.0.0 entry, which is the longest prefix match?

Use the ipCidrRouteTable or the inetCidrRouteTable, which has enough
indexing structure to allow you to do such things.

> > Bob

Mike Heard