> 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.

> 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.

> 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.

> clientaddr

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

> 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.

> 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.



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: