net-snmp proxy configuration

[Young, Alistair]

Hello all,

I am trying to configure the net-snmp to use another agent for certain
requests. I've added a line like this to my snmpd.conf file and have
restarted the daemon:

proxy -v 3 -lauthNoPriv -aMD5 -Apassword -uuser agenthost .1.3.6.etc

I can successfully query the second agent directly:

$ snmpget -v 3 -lauthNoPriv -aMD5 -Apassword -uuser agenthost .1.3.6.etc

But this fails when I try to access the OID through the proxy:

$ snmpget -v 3 -lauthNoPriv -aMD5 -Apassword -uuser localhost .1.3.6.etc

Looking at the logging on the second agent, it is rejecting the request
because of an invalid engine ID.

I have tried configuring the proxy to use SNMPv1, like so:

proxy -v 1 -c public agenthost .1.3.6.etc

And this then works rather nicely.

So my question is - how can I configure net-snmp to talk to the second
agent via SNMPv3? I've tried specifying the second agent's engine ID in
snmpd.conf but this didn't appear to help.

I'm running net-snmp 5.3 on a Linux box. The second agent is an
SNMP4J-based agent running on a separate, Windows, machine.

Thanks,


Alistair.


Please help Logica to respect the environment by not printing this email / Merci d'aider Logica à préserver l'environnement en évitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente não imprimindo este correio electrónico.



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Dave Shield]

Post by Young, Alistair
I've tried specifying the second agent's engine ID in
snmpd.conf but this didn't appear to help.

That would be my first approach, certainly.
How exactly did you try to do this?


Dave

[Dave Shield]

Attaching a packet sniffer it looks like, when the first request is
sent, there's a whole series of exchanges between net-snmp and my other
agent (over a period of around 4 seconds), which culminates in my other
agent returning the requested value.

That sounds quite possible.
The "client" (i.e. the proxying system) needs to synchronise with the
internal clock on the "server" for the SNMPv3 request to succeed.
This is handled automatically, but may well take longer than the
timeout for the original management app.

 However, by this time, the snmpget
request has returned "NULL".  The next request is fine (and seems to
only involve a single get/response pair - presumably net-snmp is now

One possibility might be to insert a dummy MIB module,
which sent a query to the remote system when the proxy
server first starts up.

[Young, Alistair]

-----Original Message-----

 However, by this time, the snmpget request
has returned "NULL".  The next request is fine (and seems to only
involve a single get/response pair - presumably net-snmp is now able

One possibility might be to insert a dummy MIB module, which sent a query to the remote system when the proxy
server first starts up.

[Young, Alistair]

Hi Dave,

I added a '-e' flag to the proxy line in snmpd.conf:

proxy -e 80001370010A00002A -v 3 ...as before...

However, I've just realised that regardless of whether or not the engine
ID is specified, it's only my /first/ request that fails. Subsequent
requests are fine. Obviously in my previously testing I didn't have
time to issue /two/ requests in a row! :)

Attaching a packet sniffer it looks like, when the first request is
sent, there's a whole series of exchanges between net-snmp and my other
agent (over a period of around 4 seconds), which culminates in my other
agent returning the requested value. However, by this time, the snmpget
request has returned "NULL". The next request is fine (and seems to
only involve a single get/response pair - presumably net-snmp is now
able to maintain the details of the second agent):

$ /etc/init.d/snmpd restart
$ snmpget -v3 -lauthNoPriv -aMD5 -Apassword -uuser localhost
.1.3.6.1.4.1.162.etc
(returns almost immediately)
SNMPv2-SMI::enterprises.162.etc = NULL
$ snmpget -v3 -lauthNoPriv -aMD5 -Apassword -uuser localhost
.1.3.6.1.4.1.162.etc
(returns almost immediately)
SNMPv2-SMI::enterprises.162.etc = INTEGER: 1

So the problem is not what I first thought - but it looks like the
request that is being made to net-snmp is being sent a response before
net-snmp has finished negotiating with the second agent.

This is not such a big deal (there's a pretty simple workaround), but it
does seem curious.

Cheers,


Alistair.


-----Original Message-----
From: ***@googlemail.com [mailto:***@googlemail.com] On
Behalf Of Dave Shield
Sent: 12 March 2009 16:17
To: Young, Alistair
Cc: net-snmp-***@lists.sourceforge.net
Subject: Re: net-snmp proxy configuration

I've tried specifying the second agent's engine ID in snmpd.conf
but this didn't appear to help.

That would be my first approach, certainly.
How exactly did you try to do this?


Dave


Please help Logica to respect the environment by not printing this email / Merci d'aider Logica � pr�server l'environnement en �vitant d'imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a respeitar o ambiente n�o imprimindo este correio electr�nico.



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Mike Ayers]

Sent: Thursday, March 12, 2009 9:50 AM
This is not such a big deal (there's a pretty simple
workaround), but it
does seem curious.

For SNMP monitoring in general, a lost packet or two is nothing to worry about. It's tough to get used to, but things get a lot easier once you get used to that.


HTH,

Mike