Hi!
Thanks Dave,
I understood that there is something wrong in my snmpd.conf file
which you figured out, once again thank you.
> > If I am using context name in the master agent, how come
> >manager will come to know from which subagent he got request, when I
> >do walk operation. How manager will identify the subagents.
>That doesn't make sense.
>The manager doesn't get requests *from* a subagent - it forwards
requests *to* the subagents.
> It knows which subagent to forward the request to from the community
string (in my suggested config above), or from the source of the
original
> request (in your original config). The setting you listed seemed to
be
> bouncing the request back to the system where the MIB browser was run.
So if you ran your MIB browser on the box 10.10.1.10, it would proxy
> requests back to 10.10.1.10. If you ran it on the box 10.10.1.20, it
>would proxy requests back to 10.10.1.20.
> I'm not sure whether this is what you were intending?
what I mean is manager sends a request to the master agent(
192.168.157.52), in the master agent I have configured the snmpd.conf
file, which I have shown in the previous mail. Where as manager it just
sends a OID , snmp version, community string and ip address of the
master agent. Then Master agent sends request to the subagents
i.e.,10.10.1.10 and 10.10.1.20. Master agent recevies a request from
the respective subagents, sends back to the Manager.
Here Manager use the snmpv1 and snmpv2
Master Agent uses the snmpv3
lets assume that subagent uses the snmpv1 and
snmpv2.
Now tell me if I configured snmpd.conf file using context name
in the Master agent, How Manager will identify from which subagent
response has came. I think Manager doesn't know how many subagents are
there until unless he does a walk operation, he just sends an request.
Master agent will take care of everything. I hope this clear.
With Regards.
G.Siva Prakash Reddy.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Shield
Sent: Monday, May 14, 2007 1:57 PM
To: Siva Prakash Reddy G
Cc: [email protected]
Subject: Re: regarding creation of subagents using proxy.
Let's have a closer look at your settings:
On 14/05/07, Siva Prakash Reddy G <[EMAIL PROTECTED]> wrote:
> com2sec -Cn modemHost1 remHost1 10.10.1.10/255.255.255.255 public
I.e.
"treat the 'public' community from 10.10.1.10
as the security name 'remHost1' in the context 'modemHost1'"
> group remHost1 usm remoteHost1
I.e
"treat the SNMPv3/USM user 'remoteHost1' as part of the group
'remHost1'"
There are *two* immediate problems there.
Firstly, the com2sec entry creats a pseudo-user called "remHost1", but
the group entry is working with a user called "remoteHost1". Secondly,
the group entry refers to SNMPv3, not SNMPv1.
> access remHost1 modemHost1 usm noauth exact systemview none none
I.e.
"Grant read-only access to the view 'systemview' for SNMPv3/USM
requests
from the group 'remHost1' in the context 'modemHost1'".
Once again, this is only relevant to SNMPv3/USM requests, not SNMPv1.
> proxy -Cn modemhost1 -v2c -c public 10.10.1.10
> 1.3.6.1.4.1.6798
Very minor problem here - the name of the context is 'modemHost1', not
'modemhost1'
I'd suggest that you start with a completely empty config file, and set
things up for *one* proxied subagent initially, and without
the "local-access" settings. The less there is there, the less risk
of unexpected interference.
Try
com2sec -Cn modemHost1 rUser1 default remHost1
group rGroup1 v1 rUser1
view allView included .1.3.6.1
access rGroup1 modemHost1 v1 noauth exact allView none none
proxy -Cn modemHost2 -v2c -c public 10.10.1.10 1.3.6.1.4.1.6798
Then query the agent using the community string "remHost1" (rather than
"public").
If that works, then you can look at putting in the second remote host,
restricting the source address for such requests, and adding access to
the local agent.
But I'd get one bit working first, rather than trying to put
everything in place right from the start.
> If I am using context name in the master agent, how come
> manager will come to know from which subagent he got request, when I
> do walk operation. How manager will identify the subagents.
That doesn't make sense.
The manager doesn't get requests *from* a subagent - it forwards
requests *to* the subagents.
It knows which subagent to forward the request to from the community
string (in my suggested config above), or from the source of the
original
request (in your original config). The setting you listed seemed to be
bouncing the request back to the system where the MIB browser was run.
So if you ran your MIB browser on the box 10.10.1.10, it would proxy
requests back to 10.10.1.10. If you ran it on the box 10.10.1.20, it
would proxy requests back to 10.10.1.20.
I'm not sure whether this is what you were intending?
Dave
The information contained in, or attached to, this e-mail, contains
confidential information and is intended solely for the use of the individual
or entity to whom they are addressed and is subject to legal privilege. If you
have received this e-mail in error you should notify the sender immediately by
reply e-mail, delete the message from your system and notify your system
manager. Please do not copy it for any purpose, or disclose its contents to any
other person. The views or opinions presented in this e-mail are solely those
of the author and do not necessarily represent those of the company. The
recipient should check this e-mail and any attachments for the presence of
viruses. The company accepts no liability for any damage caused, directly or
indirectly, by any virus transmitted in this email.
www.aztecsoft.com
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
