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 =
> 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:
pgpjFm79jIRIv.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf