|
Okay, I've just upgraded to the lastest tcpdump on both the director and
realserver.
I also just re-downloaded kernel 2.4.7, patched with IPVS_0.8.1 and
recompliled as per directions in the LVS mini-howto for kernel 2.4.X.
I'm working with Joseph Mack on getting his configure script to work on the
servers, but after running it I cannot see the outside world from the
director, although I can still see the CIP on the same network.
In the mean time, I've changed my LVS_NAT config to be very simple. No
virtual interfaces, and just using telnet.
This is my ipvsadm setup:
ipvsadm -C
ipvsadm -A -t 216.163.XXX.13:telnet -s rr
ipvsadm -a -t 216.163.XXX.13:telnet -R 10.75.0.2:telnet -m
216.163.XXX.13 is the eth0 ip address of the director
10.75.0.2 is the eth0 ip address of the realserver
10.75.0.1 is the eth1 ip address of the director, and the default gateway of
the realserver.
My client is 216.163.120.2 on a different box then the director.
If I telnet to the director before running ipvsadm I get a telnet session on
the director. If I telnet to the realserver from the director I get an ftp
session to the realserver. After running the above ipvsadm commands, and
try telneting to the director's ip address it just hangs in the SYN_RECV
mode
Running tcpdump on the director on all the interfaces I do ***not see any
traffic what so ever*** trying to go to the realserver. It's like port
forwarding isn't on. But:
# cat /proc/sys/net/ipv4/ip_forward
1
So it appears to be ON to me. Since packets don't appear to be making it to
the realserver, I think there is a problem with the director, not the
realserver.
Also here is my ifconfig from the director:
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:D0:A8:00:3C:EB
inet addr:216.163.120.13 Bcast:216.163.120.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2644 errors:0 dropped:0 overruns:0 frame:0
TX packets:1354 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:10 Base address:0xef00 Memory:e08bb000-e08bbc40
eth1 Link encap:Ethernet HWaddr 00:D0:A8:00:3C:EC
inet addr:10.75.0.1 Bcast:10.255.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:243 errors:0 dropped:0 overruns:0 frame:0
TX packets:415 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:5 Base address:0xee80 Memory:e08bd000-e08bdc40
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:38 errors:0 dropped:0 overruns:0 frame:0
TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
-----Original Message-----
From: Julian Anastasov [mailto:ja@xxxxxx]
Sent: Thursday, September 06, 2001 8:51 PM
To: Jeremy Kusnetz
Cc: 'lvs-users@xxxxxxxxxxxxxxxxxxxxxx'
Subject: RE: SYN_RECV LVS_NAT on 2.4.7 kernel
Hello,
On Thu, 6 Sep 2001, Jeremy Kusnetz wrote:
> I'm using ipvs-0.8.1
> -----------------------------
>
> On the realserver I've tried both:
> tcpdump -ln host dip
> and
> tcpdump -ln host vip
> and just a plain tcpdump
The both commands are wrong. On the real server you have only
two options:
tcpdump -ln host RIP
or
tcpdump -ln host CIP
the second works for all forwarding methods but your commands
don't work for NAT.
> All show no packets hitting the realserver.
This is correct considering the commands you are using. I
assume you are seeing the traffic to the real servers through eth1?
> Q.3 Is the traffic forwarded from the LVS box, in both directions?
>
> I think I fall under:
>
> A.4 All packets from the client are dropped (since it never seems to go to
> the realserver)
>
> - the requests are received on wrong interface with rp_filter
> protection
/proc/sys/net/ipv4/conf/*/rp_filter
I can't believe that you can hit this problem, it is very
difficult. I don't know how many eth devices you have on the real
server(s). I see that you are using an old tcpdump version and
you have to start tcpdump with specific -i ifname option for all
devices. Then check again this A.4 point.
> - firewall rules drop the requests
>
> I don't have any other firewall rules setup other then the masquerading.
>
> I don't know what rp_filter protection is, can you explain the first
reason
> for failure there?
The rp_filter protection can drop packets if you are trying
to deliver traffic through one device but the reverse path points to
another device.
For example, may be you have {all,eth0}/rp_filter=1 in the
real server but your default route is on eth1. So, eth0/rp_filter can
drop your packets. In such case ping and traceroute can work if they
successfully select the right path. But they can fail even for right
routing setup. If traceroute does not work then someone have to fix
it to call bind() before sendto() through the raw socket.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
