Problems with 2.4.2

Julian Anastasov ja at ssi.bg
Fri Aug 17 02:34:48 BST 2001


	Hello,

On 16 Aug 2001, Kjetil Torgrim Homme wrote:

> I'm using Red Hat's stock kernel from 7.1, and use ipvsadm from
> Powertools 7.1.
>
> The LVS is set up like this:
>
>   ipvsadm -A -t lvs:http -s rr
>   ipvsadm -a -t lvs:http -r rs1:80 -m -w 1
>   ipvsadm -a -t lvs:http -r rs2:80 -m -w 1
>
> The director has two network interfaces, one public and one private.
> The two real servers are connected to a hub in the private net.  There
> are no firewall rules.  The masquerading is set up using ipchains.
>
>   ipchains -A forward -j MASQ -s 10.218.128.0/24 -d 0.0.0.0/0
>
> The problem: The request from the outside goes into the director, is
> masqueraded and passed on, and the real server sends a reply.
> Unfortunately, the reply is not demasqueraded and it gets dropped.

	Why is dropped? OUTPUT rule? rp_filter-ed?

> This is the output of tcpdump on the director (139.119.191.249) as it
> gets a request from a client (139.119.191.49):
>
>  :13.770082 eth0 < 139.119.191.49.1754 > 139.119.191.249.http: S 1204706457:1204706457(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
>  :13.770082 eth1 > 139.119.191.49.1754 > 10.218.128.12.http: S 1204706457:1204706457(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
>  :13.770082 eth1 < 10.218.128.12.http > 139.119.191.49.1754: S 2868758999:2868758999(0) ack 1204706458 win 5840 <mss 1460,nop,nop,sackOK> (DF)

You have to read http://www.linuxvirtualserver.org/~julian/L4-NAT-HOWTO.txt
You can report if you discover a new reason for NAT problems. It is always
interesting when someone is hit by new problem.

>  :17.010082 eth0 < 139.119.191.49.1754 > 139.119.191.249.http: S 1204706457:1204706457(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
>  :17.010082 eth1 > 139.119.191.49.1754 > 10.218.128.12.http: S 1204706457:1204706457(0) win 16384 <mss 1460,nop,nop,sackOK> (DF)
>  :17.010082 eth1 < 10.218.128.12.http > 139.119.191.49.1754: S 2868758999:2868758999(0) ack 1204706458 win 5840 <mss 1460,nop,nop,sackOK> (DF)
>  :17.170082 eth1 < 10.218.128.12.http > 139.119.191.49.1754: S 2868758999:2868758999(0) ack 1204706458 win 5840 <mss 1460,nop,nop,sackOK> (DF)
>
> Has anyone seen something like this before?  Is it just a buggy
> kernel?

	Wow. Can happen sometimes in tests. This is an usual setup and
I can't believe that the kernel could be broken. I don't remember for
any 2.4 bugs in the ipchains compat modules. There is a wrong route
call but it is copied from the 2.2.x (x<14) age.

> Kjetil T.

Regards

--
Julian Anastasov <ja at ssi.bg>





More information about the lvs-users mailing list