On Mon, 2005-08-01 at 09:42 -0700, Rav wrote:
> Basically my project requirement is that there will be 2 net-snmp
> agents .... the agent with port number 161 should act as the proxy for
> the agent with the port number 5050. Any snmpget request to this linux
> box, the response should be from the agent with port number 5050
> through the proxy agent.
What information (if any) should the 161-agent supply itself?
If none, then you will need to configure it accordingly - either
by building a minimal version of the agent (basically with just the
access control and proxy modules), or by explicitly controlling
which modules are initialised.
The idea of the proxy mechanism is to *extend* the capabilities of
the main agent, so it will typically report both its own information
*and* that from the proxy agent.
> 1. I started the first net-snmp agent with the command "service snmpd
> start" (default agent)
> 2. I started the second agent with the command
> "/usr/sbin/snmpd -c <home directory>/user/snmp.conf udp:5050"
>
> 3. In the /etc/snmp/snmpd.conf file I introduced a line like "proxy -v
> 3 -u <username> -A <password> -l authNoPriv -p 5050 192.168.1.100 .1"
> for the proxy configuration.
That's fine as far as it goes.
But the other thing to be aware of is that if the agent has two
possible sources for some area of the MIB tree, then it will prefer
the more specific one. So if there's a fairly general registration
(covering the whole of the .1 subtree - from the proxy directive), and
a more specific registration (covering just the system group - from the
internal module), then you'll get the information from the more
specific (internal) module.
This is what's happening here:
> 5. When I quered 192.168.1.100 with snmpget from a second linux box
> which is on the same LAN, like "snmpget -v 3 -u <username> -l
> authNoPriv -a MD5 -A <password> 192.1.100.1 sysUpTime.0", it still
> gives me the response from the default agent rather than from the
> agent with port number 5050. Basically the proxy fails.
No - it's probably not failing. If there's a MIB region that your 5050
agent implements (and the main 161 agent doesn't), then you should be
able to query it successfully. But if there are overlapping areas of
the MIB tree, then you're probably getting the "wrong" set from your
point of view.
Try starting the original agent with something like
/usr/sbin/snmpd -I-system_mib
(plus whatever other options the "service snmpd start" command uses).
That will turn off the internal system group implementation, so you
should see the proxied one instead.
Dave
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
