On 09/11/2007, Rajendra, Singh <[EMAIL PROTECTED]> wrote:
> Below is what my snmpd.conf looks like

Which snmpd.conf?   There should be two (one for A, and one for B).
I'm assuming this is the A version.


> com2sec  testgroup2     default         testgroup2
>
> group testgroup2        v1        testgroup2
> group testgroup2        v2c       testgroup2
> group testgroup2        usm       testgroup2
>
> view mib2        included  .1.3.6.1.2.1                  fc
>
> access testgroup2    ""          v1      noauth     exact    mib2    none none
> access testgroup2    ""          v2c    noauth     exact    mib2    none none
> access testgroup2    ""          usm   authNoPriv exact    mib2    none none

That configuration is set to allow read access to the subtree   .1.3.6.1.2.1
(and nothing else)  when using the community "testgroup2".


> proxy directive I am using is :
>
> proxy -v 2c -c testgroup2  192.168.205.33  .1.3.6.1.4.1.562.3.21.6

Forget about the proxy stuff for now.
You've got problems before that kicks in.



> But when I do a getnext / get  the query times out.
> snmpgetnext -v 2c -c testgroup2 192.168.205.33 .1.3.6.1.4.1.562.3.21.6.1.1.1
> Timeout: No Response from 192.168.205.33.

That's correct.
You are asking for values underneath .1.3.6.1.4.1,
which is not part of the accessible subtree .1.3.6.1.2.1

So the main SNMP agent (A) is rejecting this request,
without ever bothering to ask the proxied agent at all.



I would strongly recommend that you don't bother with the
full com2sec/group/view/access directives.
   Just use "rocommunity" - it's *much* simpler.

You'll also need to set up access control on the proxied agent B,
to allow the agent A to query it.

Make sure that you can:
   a)  query the full OID tree on agent A from your main management station.
   b)  query the subagent B from the system where A is running
          (using snmpgetnext/snmpwalk/etc)

Do this *before* looking at the proxy directive itself.
You need to get the individual bits working before you start
trying to stitch them all together.


Dave

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
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

Reply via email to