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

From: "David Harrington" <[email-masked]>
Date: Fri, 14 Mar 2008 10:20:16 -0400

Hi,

There are two technical things that jump out at me on this question,
and a question about why is the question being raised.

1) why is this about the mib-2 ipRouteTable? That has been deprecated
(or obsoleted) by later MIB modules (RFC1354, 2096, and 4292). 

If this is about the correct way to implement MIB support for ip
routing, then we should probably be talking about implementing RFC
4292, not 1213.

2) "enter a query" is not very clear. Is this "perform a
get-next-request"? What OID value is included in the request? SNMP
does not have a syntax that permits a.b.<not-c>.0, and I think the
answer depends on what the third suboid contains.

If this question is about an NMS processing messages from a (legacy)
RFC1213 implementation, and wanting to know whether the response
received is correct or not, then it is important to know exactly how
the request was formed. 

--
What is the scenario surrounding this question? Is this an agent
implementer question? Is this from an NMS implementer? Is this to
determine who's wrong? The legacy implementation probably won't be
updated to be correct per 1213 if it is currently wrong, and if the
agent CAN be updated, then it should be updated to a newer MIB module.
If the agent cannot be updated, the NMS will need to deal with the
response even  if it is technically wrong. If this is to debug current
behaviors, the question should probably focus more on the format of
the request made by the NMS, so being exact about the request details
is most important. 

-
The correct mailing list for this type of question (general MIB
discussions) is [email-masked] (copied in my reply). Please
continue this discussion on that mailing list.

David Harrington
[email-masked]
[email-masked]
[email-masked]

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

_______________________________________________
IETFMIBS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietfmibs

---

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

On Fri, 14 Mar 2008, Andy Bierman wrote:
> > My question has to do with what is returned from the MIB-II IpGroup

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.

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

> > 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
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Cole, Robert G." <[email-masked]>
Date: Fri, 14 Mar 2008 14:58:05 -0400

Dave,

Thanks for your prompt response.  Let me get myself current (read through 4292).  Then
based upon your questions below, I'll rephrase my question (if it still applies).

Thanks,
Bob

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Fri 3/14/2008 10:20 AM
To: Cole, Robert G.
Cc: [email-masked]; 'Andy Bierman'
Subject: RE: [MIB-DOCTORS] quick routeTable question
 
Hi,

-

David Harrington
[email-masked]
[email-masked]
[email-masked]

IpGroup
An
a
an
C
(a

---

From: Bill Fenner <[email-masked]>
Date: Mon, 17 Mar 2008 12:48:59 -0700

Ok, I'll bite - does anyone know of implementations of  4022, 4113,  
4292 or 4293?  When I was updating netdisco to grab v6 address/mac  
mappings to try to generate statistics for the v6 hour at IETF71, I  
had to use CISCO-IETF-IP-MIB; when we used Junipers a few meetings ago  
I had to use IPV6-MIB.  I'd really like to be able to write management  
code to use the updated MIBs, but so far I haven't found anything to  
manage.

   Bill

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Mar 2008 18:13:58 -0400

Hi,

I have not been tracking which mibs are getting implemented, so I have
no data on this at this time.

dbh 

> From: Bill Fenner [mailto:[email-masked]] 
> Sent: Monday, March 17, 2008 3:49 PM
> To: David Harrington
> Cc: [email-masked]; Cole, Robert G.
> Subject: Re: [IETFMIBS] [MIB-DOCTORS] quick routeTable question
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Mar 2008 18:25:12 -0400

Hi,

The OPSAWG has a document in development that provides a survey of
existing IETF standards-track NM protocols and data models.

As part of the review of data models, I hope to be able to report on
the rough number of known implementations of existing MIB modules. If
anybody on this list has already compiled such information, I would
appreciate your contacting me so we can reuse your research.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Monday, March 17, 2008 6:14 PM
> To: 'Bill Fenner'
> Cc: 'Cole, Robert G.'; [email-masked]