Mike Ayers wrote:
>> From: Glenn McAllister [mailto:glenn@somanetworks.com]
>> Sent: Thursday, October 16, 2008 9:45 AM

>> We have the requirement that we need to send informs from a specific
>> ipv4 address, as we use the source address to do a lot of the
>> routing on
>> our device. The device can have multiple ipv4 addresses, and in that
>> situation there is typically a separate address intended for
>> management
>> traffic. We can get snmpd to bind to that address on port
>> 161 for the
>> usual GET, SET, etc. processing via the agentaddress token. Where we
>> are having trouble is getting v3 informs sent off that same
>> interface.

> Then you have misconfigured your IP routing.

My apologies, but no we haven't. I'll get into greater detail on this
below, but the system is configured correctly to do source-address based

>> In our setup we use trapsess to configure the targets, and
>> all informs
>> are going through snmpd (either snmpd is sending its own informs, or
>> informs are originating from AgentX subagents).

> This is typical.

Which is exactly why we did it this way. :-)

>> My apologies in advance if any of the example output or config files
>> wrap badly.
>> A sample configuration file (mildly obfuscated) looks like:
>> rwuser userblah
>> agentaddress localhost:161,

> I vaguely recall trying to use agentaddress and not having it work as expected. I see no documentation indicating that comma separated lists are acceptable. Try using the snmpd command line listening address specification.

This works fine, and has for some time. From 'man snmpd.conf':

agentaddress [:][,...]
defines a list of listening addresses, on which to receive
incoming SNMP requests. See the section LISTENING ADDRESSES in
the snmpd(8) manual page for more information about the format
of listening addresses.

The default behaviour is to listen on UDP port 161 on all IPv4

>> clientaddr

> The clientaddr directive belongs in snmpconf, not snmpd.conf - no mix-n-match.

And as I mentioned further on in the email, I realized that was likely
the case. I removed it from snmpd.conf and placed it in snmp.conf, with
exactly the same results.

>> trapsess -v 3 -u userblah -l authNoPriv -A somepassword -a MD5 -Ci
>> trapsess -v 3 -u userblah -l authNoPriv -A somepassword -a MD5 -Ci
>> From 'tcpdump -i any port 162' I get:
>> -3:-52:-11.248169 IP >
>> F=r [|snmp]
>> -3:-52:-10.248665 IP >
>> F=r
>> [|snmp]
>> Obviously at this point I was expecting to see as the
>> source address, not which is the first ipv4 address
>> configured for the box.

> ...and, I'd guess, the default gateway?
>> And to be complete 'lsof -p -P' gives me:
>> snmpd 6732 root 7u IPv4 482968 UDP *:32785
>> snmpd 6732 root 8u IPv4 482969 UDP *:32786
>> snmpd 6732 root 9u IPv4 482972 UDP
>> localhost.localdomain:161
>> snmpd 6732 root 10u IPv4 482973 UDP
>> Again, I was expecting the sockets to be bound to
>> rather
>> than INADDR_ANY.

> See above re agentaddr.

The two addresses I registered with agentaddr show up correctly in the
lsof list (localhost.localdomain:161 and
respectively). agentaddr works fine. Its the two that are defined from
the trapsess command that are using INADDR_ANY.

>> Grubbing through the various mailing list archives and patches, I
>> thought this had been resolved in 5.4.2 with patch 1775124.
>> Specifically, I thought that the clientaddr configuration token would
>> correctly set the source address of the outgoing UDP packet to the
>> configured address. Instead, we see that its still binding to
>> INADDR_ANY and the inform is coming from the first available
>> ip address.

> See above re clientaddr.
>> To be thorough, I thought that perhaps it mattered which
>> configuration
>> file the clientaddr directive was used; it doesn't. I tried
>> it in both
>> snmp.conf and snmpd.conf and there was no discernible result.

> Correct - snmp.conf does not apply to snmpd.conf.
>> Am I barking up the wrong tree with clientaddr? Is there something
>> we've missed in our use of the trapsess token? I checked all the
>> options available to trapsess in 'man snmpcmd' and there is
>> nothing to
>> specify the source address.


> Setting a source address should not be necessary. Add a routes for
> your 192.168.222/24 network and keep you target addresses in it, and the
> notifications will always come from that adapter, because that's how
> it's supposed to route. You cannot have per-application routing tables,
> at least not on any OS I have yet encountered.

We are using policy based routing, of which source address based routing
is simply one type:


I don't want to get into a discussion about the merits of source address
based routing. All I'm trying to do is determine if there is a
supported way to have all traps/informs coming from snmpd come from the
same address, and not simply the first one defined on the box. From
everything I'd read, I had assumed that clientaddr would do the job but
it doesn't appear to be working as advertised.

Glenn McAllister +1 416 348 1594
SOMA Networks, Inc. http://www.somanetworks.com/ +1 416 977 1414

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Net-snmp-users mailing list
Please see the following page to unsubscribe or change other options: