This is a discussion on Re: regarding creation of subagents using proxy. - SNMP ; Let's have a closer look at your settings: On 14/05/07, Siva Prakash Reddy G 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 ...
Let's have a closer look at your settings:
On 14/05/07, Siva Prakash Reddy G
> com2sec -Cn modemHost1 remHost1 10.10.1.10/255.255.255.255 public
"treat the 'public' community from 10.10.1.10
as the security name 'remHost1' in the context 'modemHost1'"
> group remHost1 usm remoteHost1
"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
"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 22.214.171.124.4.1.6798
Very minor problem here - the name of the context is '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.
com2sec -Cn modemHost1 rUser1 default remHost1
group rGroup1 v1 rUser1
view allView included .126.96.36.199
access rGroup1 modemHost1 v1 noauth exact allView none none
proxy -Cn modemHost2 -v2c -c public 10.10.1.10 188.8.131.52.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?
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.
Net-snmp-coders mailing list