[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the future of SNMP




--- Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>
wrote:
> 
> [I did not want to respond but I just have to since
> I see lots of
>  IMHO stupid arguments.]

please, no need for that.  agreeing to disagree is
fine, but please don't call people names.

 
> Fact #1: An AgentX subagent will not work.

without seeing the implementation, that's a pretty
sweeping statement.  saying 'fact' does not
necessarily make it so.

yes, no _direct_ call mechanism via var_mumble will
work with the loosely coupled agent-x.  for .so-style
subagents (in net-snmp, for example) this will work;
but for agent-x, an indirect call will have to be
used.  so what?  fetching data from the agent to
itself is far far better than fetching data from the
remote NMS to agent.  taking the network out of the
loop is a big gain, especially for lossy networks,
unreliable (at times) networks or times when the NMS
(or some router in between) is down.


> Fact #2: Initiating the bulk transfer is not the
> same as using it in
>          an application. Having some encoded data in
> a file is IMHO
>          far away from using the data in a
> management application.

my assumption (maybe I'm wrong here) is that the hard
work is getting the data across in a parse-friendly
(ascii CSV) format.  CSV files are the most importable
format I know of.  most serious NMS shops (that would
do billing/accounting, for example; one of the main
motivations for a bulk xfer arrangement) do their
billing based on some database, perhaps even an sql
database.  the raw mib data, as gotton via standard
snmp, is one such source of data import.  CSV files
would be another.  its not rocket science (nor would
it even require C programming) to import a CSV file
into a database so that a billing app can chomp on it.



> Fact #3: Security mappings between SNMP and FTP will
> be non-trivial.

this doesn't seem to have stopped many vendors.  at my
previous company, I was told that there was a bunch of
vendors that are using the 'push' model (storing
usernames/passwords for remote file login/xfer) on
their agent.  and while this was seen as a security
issue; and while I basically agree with that, my MIB
does provide a 'pull' model which solves that concern.

there was the issue raised of which username or
permission-set the file transfer job would run as. 
ie, once the snmp SET occurs and the data collection
begins, which 'account' does it run under (at the
agent side)?  this is a detail that the last published
MIB didn't deal with but after some email with someone
more in-the-know about security, we put some patches
together that addresses this better.  perhaps not
perfectly, but better.  I'll try to revise the current
MIB to reflect that.

but I believe the security issues can be folded into
the implementation after the initial proof-of-concept
is done.  I'm more interested in seeing the speed
gain, at first, and then adding refinements to the mib
as a 2nd pass.  I don't think the security
implications are a show-stopper and nothing really
major has to be done to the mib to satisfy the
security-minded.



> Fact #4: Deploying new protocol operations (if done
> right) boils down
>          in most cases to the cost of getting an
> update of the SNMP
>          engine and recompiling the agent.

oh really?  some mgmt code that does an
'snmp_get(varbind, varbind, varbind)' will Just Plain
Work by linking to libsnmp_new instead of libsnmp? 
somehow I just don't believe that.



> Fact #5: A 10 year old closed-source
> no-compilers-exist unix box will
>          probably not do much more than some basic
> RFC 1213 stuff and
>          we probably do not need protocol extensions
> for that.
> 

its my assertion that to setup a bulk file transfer
using my mib would require only the most basic varbind
creation.  a few SET pdu's is all that it will take in
order to get a csv.txt file to be placed on the NMS. 
it might take all of 5 shell lines, calling net-snmp's
snmpset utility (for example) to define a transfer
profile.  then when its time to request a
snapshot/file-transfer, a single snmp set with a
handful of varbinds is all that's needed.  that's
hardly a complex operation and I'm willing to bet that
10yr old NMS would easily be able to handle that.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/