 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
On Wed, Oct 22, 2008 at 08:36:22AM +0300, Pekka Savola wrote: > $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr This essentially would be identical to DHCP leasequery, minus the bulk. Even if transported via TCP, on the wire it would look like a single client->server GETNEXT, waiting for a server->client reply before sending the next one. One PDU and one OID in it at a time. snmpbulkwalk is a minor improvement; a single UDP reply can contain many iterated GETNEXT's, or similarly over TCP. There is still a 'pause' between the client's request and reply. What the leasequery bulk methods are looking for is "all at once." The objective is to fill the socket at maximum window size. I am not aware of a means to do this with SNMP considering the kinds of data in DHCP lease tables, and the usual ways MIBs are constructed. > ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46 > IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 = > INTEGER: netmgmt(3) > IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.From ietf-bounces at ietf.org Wed Oct 22 10:16:28 2008 Return-Path: <ietf-bounces at ietf.org> X-Original-To: ietf-archive at megatron.ietf.org Delivered-To: ietfarch-ietf-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2AE028C1A2; Wed, 22 Oct 2008 10:16:27 -0700 (PDT) X-Original-To: ietf at core3.amsl.com Delivered-To: ietf at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23FD53A68AC; Wed, 22 Oct 2008 10:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPTShG7zXn6T; Wed, 22 Oct 2008 10:16:26 -0700 (PDT) Received: from hankinsfamily.info (the.hankinsfamily.info [204.152.186.148]) by core3.amsl.com (Postfix) with ESMTP id D3F8128C197; Wed, 22 Oct 2008 10:16:25 -0700 (PDT) Received: from david.isc.org (c-24-6-53-214.hsd1.ca.comcast.net [24.6.53.214]) (authenticated bits=0) by hankinsfamily.info (8.13.8/8.13.8) with ESMTP id m9MHHERx027903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO); Wed, 22 Oct 2008 10:17:15 -0700 Received: by david.isc.org (Postfix, from userid 10200) id A5AAD16E1B3; Wed, 22 Oct 2008 10:17:14 -0700 (PDT) Date: Wed, 22 Oct 2008 10:17:14 -0700 From: "David W. Hankins" <David_Hankins at isc.org> To: DHC WG <dhcwg at ietf.org> Subject: Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery (DHCPv6 Bulk Leasequery) to Proposed Standard Message-ID: <20081022171714.GL5567 at isc.org> References: <20081020123425.2DA143A69B5 at core3.amsl.com> <alpine.LRH.2.00.0810210900430.31133 at netcore.fi> <92331330810210055t3ebd4501t3198012a8b06dfa9 at mail.gmail.com> <alpine.LRH.2.00.0810220825590.2813 at netcore.fi> MIME-Version: 1.0 In-Reply-To: <alpine.LRH.2.00.0810220825590.2813 at netcore.fi> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: ietf at ietf.org X-BeenThere: ietf at ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion <ietf.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request at ietf.org?subject=unsubscribe> List-Post: <mailto:ietf at ietf.org> List-Help: <mailto:ietf-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="==============04320635==" Sender: ietf-bounces at ietf.org Errors-To: ietf-bounces at ietf.org
On Wed, Oct 22, 2008 at 08:36:22AM +0300, Pekka Savola wrote:
> $ snmpwalk -m IP-FORWARD-MIB -v 2c -c foo foo-rtr
This essentially would be identical to DHCP leasequery, minus the
bulk. Even if transported via TCP, on the wire it would look like
a single client->server GETNEXT, waiting for a server->client reply
before sending the next one. One PDU and one OID in it at a time.
snmpbulkwalk is a minor improvement; a single UDP reply can contain
many iterated GETNEXT's, or similarly over TCP. There is still a
'pause' between the client's request and reply.
What the leasequery bulk methods are looking for is "all at once."
The objective is to fill the socket at maximum window size. I am
not aware of a means to do this with SNMP considering the kinds of
data in DHCP lease tables, and the usual ways MIBs are constructed.
> ip.ipForward.ipCidrRouteTable.ipCidrRouteEntry.ipCidrRouteProto.128.214.46
> IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.0.255.255.255.0.0.0.0.0.0 =
> INTEGER: netmgmt(3)
> IP-FORWARD-MIB::ipCidrRouteProto.128.214.46.254.255.255.255.255.0.0.0.0.0 0.0 =
> INTEGER: local(2)
This kind of underlines a qualm with SNMP data management (as opposed
to network management).
For each iterated GETNEXT or GETBULK both rely upon a fixed point in
the database ("node n"), which was present in the database and was
the last PDU in the server's reply in the previous packet. But it may
not be present in the database at the time the next request is made.
This requires the database models used by the servers to be able to
find a "reliable sorting", where the previously-valid-now-invalid
OID can still be used as an index to provide continuation; it can
still grant the next OID.
This essentially is a problem, or at least a facility not present in
some DHCP databases, which caused us to motivate away from UDP based
bulk queries (the original bulk leasequery proposal was more similar
to snmpwalk in this regard, and this was a concern raised by
implementers).
In addition...
SNMP likes to present a single table of a single variable at a time.
I suppose we could overcome this by having the DHCP lease information
in an 'blob of octets' rather than in classical SNMP variable form
(INTEGER etc), so you only have one MIB to walk. But it seems foreign
to SNMP to do so.
The problem is that most leasequery clients are not positioned to
allocate fields of temporary memory in order to make sense of SNMP's
kind of "scatter-gather" approach to this kind of data transfer.
To make sense of SNMP MIBs you have to develop some strategy to
receive multiple datapoints from different locations and times.
For example, you start by walking a table of "index" advertisements,
where you receive an 'index number' that can be used into other MIBs
to find variables associated with that database entry.
For each of these indexes you discover, you could then queue single
GET PDU's for each separate variable you were interested in (lease
state, lease expiration time, ...).
There are 'performance alternatives' from there, and they are
fantastic to entertain because so many SNMP server implementations
will outright crash if too many PDUs are queued in a single packet
(others corrupt their replies if there are more than single PDU's).
This becomes more problematic when you consider that some leasequery
clients are going to want only a subset of the MIB's total contents.
The question truly is "what leases did I have in my table before I
rebooted?" Such filtration in an SNMP MIB model I think would be
done on the client end, not on the server end, meaning the client
still must traverse some entire MIB one PDU (GETNEXT or GETBULK) at a
time.
This is different from the proposed bulk leasequery models, where the
server writes to the TCP socket "all at once", with all data for a
given lease spatially located in the same position in the TCP stream,
and a primitive query language ("by query type") to provide subsets.
This doesn't mean a standard DHCP MIB isn't a bad idea for entirely
different reasons.
--
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/
--
David W. Hankins "If you don't do it right the first time,
Software Engineer you'll just have to do it again."
Internet Systems Consortium, Inc. -- Jack T. Hankins
Attachment:
pgp88bSjbR0CN.pgp
Description: PGP signature
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.