Re: Sending informs from a specific ip address

Mike Ayers wrote:
>> From: Glenn McAllister [mailto:[email protected]] 
>> 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 
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.

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,192.168.222.5: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 [<transport-specifier>:]<transport-address>[,...]
   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
   interfaces.


> 
>> clientaddr 192.168.222.5
> 
> 	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 
>> 10.11.10.92
>>
>> trapsess -v 3 -u userblah -l authNoPriv -A somepassword -a MD5 -Ci 
>> 192.168.223.10
>>
>>  From 'tcpdump -i any port 162' I get:
>>
>> <snip/>
>> -3:-52:-11.248169 IP 10.116.0.210.32785 > 
>> 10.11.10.92.snmptrap:  F=r [|snmp]
>> -3:-52:-10.248665 IP 10.116.0.210.32786 > 
>> 192.168.223.10.snmptrap:  F=r 
>> [|snmp]
>> <snip/>
>>
>> Obviously at this point I was expecting to see 192.168.222.5 as the 
>> source address, not 10.116.0.210 which is the first ipv4 address 
>> configured for the box.
> 
> 	...and, I'd guess, the default gateway?
> 
>> And to be complete 'lsof -p <pid> -P' gives me:
>>
>> <snip/>
>> 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 
>> 192.168.222.5:161
>> <snip/>
>>
>> Again, I was expecting the sockets to be bound to 
>> 192.168.222.5 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 192.168.222.5:161 
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:

http://en.wikipedia.org/wiki/Policy-based_routing
http://www.cisco.com/warp/public/732/Tech/plicy_wp.htm
http://www.faqs.org/docs/Linux-HOWTO/Adv-Routing-HOWTO.html#LARTC.RPDB.SIMPLE

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     <[email protected]>      +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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users