Re: Can the proxy agent work with internal query?

On 12/02/2008, ericj <[email protected]> wrote:
> I had set up a proxy agent with net-snmp 5.4.1 on linux,and I have a
> switch with snmpv3 agent.
>
> I can run
>   "snmpwalk -v 3 -u testuser -A 12345678 -l authNoPriv 10.10.32.4 system"
> and have return values so that I'm sure the snmpv3 configuration on
> switch is okay.

Those are the settings for querying the remote switch.



> I want the queries via proxy agent, and I added follow lines in
> snmpd.conf
>
> proxy -Cn ctx_remotehost2

which sets up proxing for requests received using this context

>     -v 3 -u testuser -a MD5 -A "12345678" -l authNoPriv 10.10.32.4

and forwards such requests using these credentials
(which you've confirmed work).

OK so far.


But note that this proxying has been set up for incoming requests
in the context "ctx_remotehost2"


> but it seems that I still have to add in snmpd.conf
>
> com2sec -Cn ctx_remotehost2 proxied default cmty_2

Which is what this line does.
It maps the community "cmty_2" into the (internal) context
"ctx_remotehost2".   That means the agent recognises it
as relating to the "proxy" directive (which specified the same
context) and passes the request on to the switch.

Without this com2sec line, the agent would treat the
incoming request as being in the default context, and
attempt to process the requested varbinds itself.


Note that if you were using SNMPv3 for the incoming
requests, then you could specify the context explicitly.
But SNMPv1/2c pre-date the idea of contexts, so this
mapping needs to be done within the agent.



> Since the net-snmp had implement the disman event MIB with internal
> query,
> I was wondering that how if I setup a proxy agent, and could disman
> could monitor the proxy agent's MIB objects?

That *might* work.
I'm just concerned that bug #1689163 might be relevant here.
But you can but try.


> As far as I know, if the proxy agent can only queried via v1/v2c
> community,and the disman implement is based on internal query with
> securityName, then my thoughts should not work, right?

The only reason that the DisMan Event implementation always
uses SNMPv3, is that the Net-SNMP agent cannot handle
community-based loopback queries.   (In particular, the access
control checks don't like such a setup).
    There's nothing in the DisMan Event code itself that's tied
to SNMPv3 requests - if you're sending a request to a remote
target, then you should be able to use SNMPv1 or 2c or 3,
as the mood takes you :-)


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-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users