I've been trying to set up server load balancing using a pair of Linux web
servers and a ServerIron. The basic setup is working. But I'm trying to
use DSR to (1) improve performance and (2) have the proper IP addresses
logged in the access_log files. DSR is where the ServerIron forwards the
packets to the web servers with a source IP not of the ServerIron but
of the actual source of the request. The response is sent back to the
originator w/o passing through the ServerIron.

But this is causing a problem. The documentation for DSR indicates that
the web servers need to have the IP of the virtual server as an alias on
the loopback interface (ie. on interface lo:0).

The IP of the virtual server is the public IP of the "cluster"; it is
the address to which all requests are sent. In this case, it is the
address The ServerIron has an IP address of

When I follow the documentation and put the virtual server IP on lo:0,
though, a problem arises: the Linux machine doesn't respond to the
ServerIron's "health check" (periodic HTTP requests to a given URl).

I also see the errors:

ll header: 00:30:48:5b:4a:e9:00:04:80:62:66:6e:08:00
printk: 4 messages suppressed.
martian source from, on dev eth1

on the web server's console.

I tried clearing all the rp_filter values, but this made no difference. I
also cleared all the log_martian values, but this did nothing but
eliminate that error message from the console.

Looking at the output of:
tshark -i eth1 -f "tcp dst port 80 || icmp || tcp src port 80"

I see this when the virtual server IP is on lo:0:

5.999987 -> TCP 1449 > http [SYN] Seq=0 Len=0 MSS=1460
6.999688 -> TCP 1449 > http [SYN] Seq=0 Len=0 MSS=1460
6.999917 -> TCP 1449 > http [RST] Seq=1 Len=0
7.671676 -> TCP 1450 > http [RST] Seq=0 Len=0
9.499900 -> TCP 1451 > http [SYN] Seq=0 Len=0 MSS=1460
10.499841 -> TCP 1451 > http [RST] Seq=1 Len=0
12.672588 -> TCP 1452 > http [RST] Seq=0 Len=0
12.999849 -> TCP 1453 > http [SYN] Seq=0 Len=0 MSS=1460
13.999757 -> TCP 1453 > http [RST] Seq=1 Len=0
16.499795 -> TCP 1454 > http [SYN] Seq=0 Len=0 MSS=1460
17.499693 -> TCP 1454 > http [RST] Seq=1 Len=0
17.672166 -> TCP 1455 > http [RST] Seq=0 Len=0
19.999817 -> TCP 1456 > http [SYN] Seq=0 Len=0 MSS=1460
20.999668 -> TCP 1456 > http [RST] Seq=1 Len=0

This is also what I see if the virtual server IP is on no interface on the
web server. So it is as if having lo:0 doesn't tell the
Linux machine to respond to packets to received on eth1.

In fact, that kind of makes sense to me. But the Foundry
documentation seems to assume that the Linux machine should be
responding to these packets.

On a hunch, I tried putting the virtual server I on eth1:1. This actually
worked, in that the ServerIron's health checks - the HTTP requests to a
given URL on the web servers - worked.

5.927826 -> TCP 1479 > http [SYN] Seq=0 Len=0 MSS=1460
5.927849 -> TCP http > 1479 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
5.928265 -> HTTP GET /oci8test.php HTTP/1.1
5.928284 -> TCP http > 1479 [ACK] Seq=1 Ack=90 Win=5840 Len=0
6.005417 -> HTTP HTTP/1.1 200 OK (text/html)
6.005426 -> HTTP Continuation or non-HTTP traffic

However, the Linux servers will also sometimes respond to ARP requests
for This causes packets received from the outside world
to be sent to a web server directly rather than passing through the

I tried:

/sbin/ifconfig eth1:1 -arp up

so that it wouldn't respond to ARP requests. But this didn't seem to
do the trick (though I don't know why). Packets will occasionally -
if rarely - be received directly by a web server w/o passing through
the ServerIron.

I'm thinking that there are two possible solutions, but I don't know
how to do either. The first idea is to somehow get the Linux machine
to respond to packets to coming in on eth1 even though is on lo:0. This would be consistent with the Foundry

The second possible solution is getting onto eth1:1 but
w/o responding to ARP requests.

Any thoughts or suggestions?