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

["C. M. Heard" <heard at pobox.com>]

On Fri, 14 Mar 2008, Andy Bierman wrote:
> 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).

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.

> > 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?

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.

> > 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?

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

> > Thanks,
> > Bob

Mike Heard
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS at ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
IETFMIBS mailing list
IETFMIBS at ietf.org
https://www.ietf.org/mailman/listinfo/ietfmibs