Using Linux servers with Foundry ServerIron doing Load Balancing

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 10.20.30.41. The ServerIron has an IP address of 10.20.30.42.

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 10.20.30.41 from 10.20.30.42, 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 10.20.30.42 -> 10.20.30.41 TCP 1449 > http [SYN] Seq=0 Len=0 MSS=1460
6.999688 10.20.30.42 -> 10.20.30.41 TCP 1449 > http [SYN] Seq=0 Len=0 MSS=1460
6.999917 10.20.30.42 -> 10.20.30.41 TCP 1449 > http [RST] Seq=1 Len=0
7.671676 10.20.30.42 -> 10.20.30.41 TCP 1450 > http [RST] Seq=0 Len=0
9.499900 10.20.30.42 -> 10.20.30.41 TCP 1451 > http [SYN] Seq=0 Len=0 MSS=1460
10.499841 10.20.30.42 -> 10.20.30.41 TCP 1451 > http [RST] Seq=1 Len=0
12.672588 10.20.30.42 -> 10.20.30.41 TCP 1452 > http [RST] Seq=0 Len=0
12.999849 10.20.30.42 -> 10.20.30.41 TCP 1453 > http [SYN] Seq=0 Len=0 MSS=1460
13.999757 10.20.30.42 -> 10.20.30.41 TCP 1453 > http [RST] Seq=1 Len=0
16.499795 10.20.30.42 -> 10.20.30.41 TCP 1454 > http [SYN] Seq=0 Len=0 MSS=1460
17.499693 10.20.30.42 -> 10.20.30.41 TCP 1454 > http [RST] Seq=1 Len=0
17.672166 10.20.30.42 -> 10.20.30.41 TCP 1455 > http [RST] Seq=0 Len=0
19.999817 10.20.30.42 -> 10.20.30.41 TCP 1456 > http [SYN] Seq=0 Len=0 MSS=1460
20.999668 10.20.30.42 -> 10.20.30.41 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 10.20.30.41 lo:0 doesn't tell the
Linux machine to respond to packets to 10.20.30.41 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 10.20.30.42 -> 10.20.30.41 TCP 1479 > http [SYN] Seq=0 Len=0 MSS=1460
5.927849 10.20.30.41 -> 10.20.30.42 TCP http > 1479 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
5.928265 10.20.30.42 -> 10.20.30.41 HTTP GET /oci8test.php HTTP/1.1
5.928284 10.20.30.41 -> 10.20.30.42 TCP http > 1479 [ACK] Seq=1 Ack=90 Win=5840 Len=0
6.005417 10.20.30.41 -> 10.20.30.42 HTTP HTTP/1.1 200 OK (text/html)
6.005426 10.20.30.41 -> 10.20.30.42 HTTP Continuation or non-HTTP traffic

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

I tried:

/sbin/ifconfig eth1:1 10.20.30.41/29 -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 10.20.30.41 coming in on eth1 even though
10.20.30.41 is on lo:0. This would be consistent with the Foundry
documentation.

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

Any thoughts or suggestions?

Thanks...

Andrew