Bug 175815 - Wrong src address on replies, multihomed machine.
Wrong src address on replies, multihomed machine.
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: net-snmp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Depends On:
  Show dependency treegraph
Reported: 2005-12-15 05:40 EST by Björn Augustsson
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-10 08:20:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Björn Augustsson 2005-12-15 05:40:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 Red Hat/1.7.12-

Description of problem:
This machine is a Real Server in an LVS "cluster", which it has the weirdish setup, but this bug should happen on any multihomed box, I expect.

It has one interface on an internal net (10.70.0/16) and one on a public one, but the interface has a /32 mask.

[root@box ~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 eth0     U     0      0        0 eth1     U     0      0        0 eth1         UG    0      0        0 eth1
[root@box ~]#

Now, if I try to talk to snmpd via the address on the eth0 interface, the replies goes out the eth1 interface (which is correct), but with that (10.70.x.y) source address (which isn't). 

So the snmp manager gets replies from another address than the one it sent the requests to, and drops them.

There are two workarounds that I've found:

1) Use snmp over tcp, not udp. (Which I would do, but it requires hacking the SNMP manager.)
2) Specify the address on the snmpd command line. (Just append it to the OPTIONS= line in the /etc/init.d-script.) But then (naturally) it won't reply to requests coming in through the other interface.

Both of the above mean hacking in the /etc/init.d-script though, which is kind of weird.


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set up multihomed machine
2. Send it SNMP requests on the interface that isn't the default route.
3. Wrong src address on the replies.

Actual Results:  snmpwalk -v2c -cpublic box .
Timeout: No Response from box

Expected Results:  Lots of output.

Additional info:
Comment 1 Robert Story 2006-05-10 08:11:04 EDT
use the agentaddress token in snmpd.conf to specify the addresses you want the
agent to listen on (and respond from). Otherwise the OS picks the return address
(i.e. it's not something net-snmp chooses).

Robert Story (upstream developer)
Comment 2 Radek Vokal 2006-05-10 08:20:17 EDT
Based on comment #1 closing as NOTABUG
Comment 3 Björn Augustsson 2006-05-10 11:22:24 EDT
Respectfully, I don't agree.

I didn't know about the "agentaddress" keyword, and that helps a bit.
(I can change the config file instead of the init.d-script.)
But I don't agree with
[...] Otherwise the OS picks the return address
(i.e. it's not something net-snmp chooses).

This is a bit of a classic problem with UDP apps. There are two fairly standard

1: Listen to, and use setsockopt(..., IP_PKTINFO, ...) to
   choose the proper src address.
2: Open up (potentially) lots of sockets, one on each IP (that you want
   to listen to.)

The problem with #1 is that there used to be platforms that didn't have
IP_PKTINFO, but I'm not sure that's a big problem anymore.

The problem with #2 is that you'll fail to reply to packets on new interfaces
that has been brought up since the app started.

You can sort of do #2 manually using the config file, but then you have to keep
track of every ip change, hack the file, and restart snmpd all the time.

For (much!) more details, see this entry in the ntpd bugzilla


or just google for "IP_PKTINFO udp"

/August, tried repoening the bug, but it didn't work... Hmm?
Comment 4 Robert Story 2006-05-10 13:27:54 EDT
According to the link you posted, IP_PKTINFO seems to be Linux/Windows only. I
tried a grep on all the SourceForge compile farm machines, and it wasn't defined
on Solaris or the BSD families.

That said, I don't know what the rest of the team will think about OS specific
code in the packet handling. I'd say try opening a net-snmp bug report and/or
post a message to net-snmp-coders@lists.sf.net.
Comment 5 Björn Augustsson 2006-05-12 05:11:06 EDT
Hmm, OK, I thought it was more portable than that...

On the one hand, this bug report is against RHEL, so they could certainly fix it
using IP_PKTINFO, OTOH I can see them not wanting to divert too much from upstream. 

I'll send a mail to the mailing list you mentioned. I'm surprised this isn't a
more well known problem, since as far as I can tell, it ought to happen to any
multihomed machine.


Note You need to log in before you can comment on or make changes to this bug.