On 07/02/2008, Giuseppe Modugno <[EMAIL PROTECTED]> wrote:
[discussing "a single agent for each device"]
> each device has an agent (main and sub-) and an IP address. The
> user that wants to walk through two devA can do:
> snmpwalk -v2c -c public -IR <ip1> devA
> snmpwalk -v2c -c public -IR <ip2> devA
> He can select the device to interrogates by its IP address.
> I think it's the normal situation with network equipments. If I buy a router
> (from Cisco or some other) I have a device running a complete SNMP agent. If I
> buy another router of the same type, I'll have another device running another
> SNMP agent of the same type with a different IP address.
> There are no "table of devices" concept in this situation.
That's the normal situation for network equipment - yes.
But as you say, this involves talking directly to each network box.
So (for example), if you want to get information from several different
routers on your network, you'd have to send the relevant SNMP queries
to each of them individually - and then pull together the results.
But from your description, this doesn't match your setup.
You say:
> ....I want to use a single Linux box with a single main and sub-agent
> that talks to devices.
So the network administrator would be talking to a single box
(the Linux system) which would then do some magic internally,
and come back with the requested results. That would most
typically be represented as one or more tables.
(e.g. the existing 'hrStorageTable" to report on the various
disks attached to a single box).
That feels a more natural comparison to me. Having the Linux
controller mimic the various DVD systems independently
seems somewhat artificial.
Note that a table-based approach also has the benefit that the admin
could send a single SNMP query and monitor/manage several
different boxes at the same time. This is particularly useful when
it comes to active management - i.e. SET requests. I'll give you an
example.
Suppose one of your customers has got a DVD recorder hooked
up directly to a player (e.g. for copying discs) using the composite
connection. And now he wants to switch them to using the SCART
connection instead. But he needs to switch them *both* - it's no
use switching the player if the recorder doesn't switch as well.
In fact, it's better for neither box to change than for only one of
them to do so.
With the separate IP approach, he'd have to send the two SET
requests separately, and examine the results. If either of them
has failed, then he'd need to switch the other one back to what
it was using before, and hope that this works. All perfectly
possible - but it's all too easy for something to go wrong.
Now consider the same requirement using a table-based approach.
All your customer needs to do is send a single SET request,
containing the two assignments. The main agent will take care
of directing the sub-requests to the appropriate box, examining
the results, and deciding whether any changes need to be reversed.
Your customer simply gets a response saying "yes they switched"
or "no they didn't".
But it's not me you should be taking advice from here - ask your
customers how they would typically view what you are selling them.
Would they naturally think of getting a single system that contains
(say) three recorders and two players? Or would they think of this
as five separate systems (of two different types), that just happen to
be wired together?
They're the ones you need to keep happy - not me!
And until you know how they would prefer to view such a configuration,
you can't really make a sensible decision regarding the appropriate
way to structure the MIBs.
Anyway - it's 5pm now, and I've a choral rehearsal to get to.
I'll leave you to the tender mercies of the rest of the team until
tomorrow morning.
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
