[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: the future of SNMP
--- "Harrington, David" <email@example.com> wrote:
> #1 For any solution to work effectively, it will
> need to be supported by both the agent and the
> manager. Fixing it on one side only is not an
I agree that the best solution is double-ended. but I
believe that even just having an snmpv2/v3 agent and a
new mib module _will_ allow a non-upgraded NMS to
perform a bulk file snapshot and transfer. that's
part 1 of the solution.
part 2 is the data import into something useful. if
you believe that any serious bulk file application
will operate on a database rather than in-memory
snmp-retrieved data, then import of a CSV file is
pretty trivial and really isn't such a big deal. I
may be wrong here, but my assumption is that data
chomping _will_ be from a database and that is why I
chose simple ascii CSV files as the 'language' for
sending bulk data across. it requires little or no
decoding for most databases.
> #2 It isn't enough to deliver a large blob of data
> to an NMS; the NMS needs to be able to break it out
> and process it to display and/or convert the raw
> data into information to make the blob of data
> meaningful to an operator. Without that step it is
> not a useful solution.
again, I believe my CSV solution addresses that
> #3 using another protocol to transport gathered data
> requires defining some mappings to coordinate that
> usage. It is not as simple as defining a mib and
> then just saying "send it over FTP".
or scp. I used ftp only as an example, not to say
that's the only transfer protocol. in a push model,
the agent would initiate a transfer using the protocol
set by the NMS. in the pull model, the NMS would
initiate using the protocol of its choice. perhaps
the agent would place the file in a secret directory
known only by the agent and NMS and the NMS would do a
wget (for example) to pull the data across, using http
or https, etc.
>What are the
> possible error conditions that could occur, and how
> should they be handled? There have been earlier
> attempts to send file of gathered data, such as
> RFC2513, and these have not been widely deployed to
> my knowledge. I would assume that if this design
> brought great beneift to the SNMP community, the
> approach would have been extended for use in other
> scenrios. Do we know why this never gained much
I don't have the specifics, but our product manager
showed me several vendors that do ship agents (on a
router or switch or dslam or whatever) that _do_ push
bulk mib data across. and I had an RFP in hand from a
major backone carrier that called for almost exactly
the solution I proposed. it solves customer problems
today and there _is_ a market need for it. the issue
is that each vendor did it in a vendor-specific way
and none, to my knowledge, had the level of power that
my proposed mib has.
> #4 As Juergen pointed out, the security mapping
> between FTP and SNMPv3 will be non-trivial. As a
> vendor, it is difficult for me to convince a
> customer they should buy our products because we
> have SNMPv3-strength security and then suggest they
> should use a non-secure protocol like FTP
again, remember there are both a push and a pull
model, and that ftp is only _one_ such protocol that
could be used.
> to ship
> bulk data. Even if the file could be transported
> over SSH or SSL or a VPN or IPSec, no mappings have
> been proposed about how to do that in a standardized
> manner, or what rules need to be followed to balance
> the security between the two.
true, I have not spent a lot of time trying to fine
tune this proposal to meet the needs of the security
community. I admit that is not my strength and I
welcome input in that area. but I believe that the
problems of making this secure and making this
efficient are orthogonal, and I would hope the lack of
security design in the current mib rev would not
hamper the proof-of-concept and further development of
this proposal. I see the security improvements being
folded into the proposal over time, as the mib (and
implementation) are evaluated and matured.
> Which security
> precautions must be follwoed sending bulk responses
> to a noAuthNoPriv request? which are acceptable for
> an authPriv response? Can they be mixed into the
> same buffer?
I don't have answers to those questions. I would
welcome advice in making the mib more secure by those
who are better qualified in the area of security.
> #5 Even if the file can be transported securely
> using the correct message security level, a
> file-based transfer does not have user-specific
> access control like VACM. I haven't read the mib
> recently; have mechanisms been defined for
> coexistence with VACM?
there were some patches almost a year back that helped
address this concern, I believe. while they're not in
the current mib text, they should be in the EOS mail
history. but I agree that they should be folded back
into the mib and resubmitted for peer review - if the
community agrees (in theory) that there's merit to the
> #6 As Juergen pointed out, adding new protocol
> additions may require nothing more than a recompile,
yes, he pointed that out. and I'm specious about that
assertion. I guess the proof will be in the pudding,
once an implementation is released and we see if a
simple rebuild of the nms apps is all that's needed.
> because many agents and applications use a toolkit
> and if the toolkit has the extra functionality the
> agent and manager will get it by default. However, I
> will point out that #2 still applies. Even if I can
> add a protocol extension with no work, I still need
> to modify my code to take advantage of the feature.
> For an NMS, this will include probing to determine
> whether the functionality is supported by different
> agents. If the SNMP stack provides the feature if a
> developer calls the appropriate API, then the
> developers need to be educated about the relative
> benefits of the new solution so they will call the
> new API rather than just continuing to call the
> getNext() API for all devices.
so right there, you say that its not going to be a
simple recompile. I believe that new code will have
to be written. for example, if a routine exists at
the nms called 'get_me_the_whole_iftable(...)' and
that currently implements to a bunch of ifTable walks
(and error handling, etc), then for the new model that
routine will have to be re-written entirely to detect
and call the new snmp stack routines if the agent
supports it, or switch to the old style if the agent
isn't new-protocol capable. that doesn't seem to be a
'simple recompile' to me.
> It is easier to just
> call the same API for all tables rather than having
> to test and debug conditional branches of code. I am
> not convinced that GetBulk has seen wide usage by
> major NMS vendors yet, for similar reasons.
I also believe that getBulk isn't widely used, but
that's mere speculation on my part, as I don't have a
survey of enough NMSs to say that as a fact. but I
share your belief in that its probable that getBulk
isn't widely used, for various reasons.
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more