[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETFMIBS] [MIB-DOCTORS] quick routeTable question
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 ietfmibs at ietf.org (copied in my reply). Please
continue this discussion on that mailing list.
David Harrington
dbharrington at comcast.net
ietfdbh at comcast.net
dharrington at huawei.com
>
> 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
IETFMIBS at ietf.org
https://www.ietf.org/mailman/listinfo/ietfmibs