|
Thanks for your time, my topology is right here:
________
| |
| client |
|________|
CIP=10.1.1.90
|
|
|
VIP=10.1.1.1 (eth0)
__________
| |
| director |
|__________|
DIP=192.168.4.128 (eth1)
|
|
-----------------------------------
| | |
| | |
RIP1=192.168.4.1 N/A (yet) N/A (yet)
_____________ _____________ _____________
| | | | | |
| realserver | | realserver | | realserver |
|_____________| |_____________| |_____________|
mask on the local net /24,
default gateway on realserver 192.168.4.128
rs: traceroute -n -s 192.168.4.1 10.1.1.90
==============================( done 5 times )
traceroute to 10.1.1.90 (10.1.1.90) from 192.168.4.1, 30 hops max, 38
byte packets
1 192.168.4.128 0.454 ms 0.249 ms 0.237 ms
2 10.1.1.90 0.589 ms 0.425 ms 0.456 ms
traceroute to 10.1.1.90 (10.1.1.90) from 192.168.4.1, 30 hops max, 38
byte packets
1 192.168.4.128 0.398 ms 0.225 ms 0.230 ms
2 10.1.1.90 0.372 ms 0.400 ms 0.348 ms
traceroute to 10.1.1.90 (10.1.1.90) from 192.168.4.1, 30 hops max, 38
byte packets
1 * 192.168.4.128 0.387 ms 0.244 ms
2 10.1.1.90 0.419 ms 0.380 ms 0.373 ms
traceroute to 10.1.1.90 (10.1.1.90) from 192.168.4.1, 30 hops max, 38
byte packets
1 192.168.4.128 0.333 ms 0.244 ms 0.223 ms
2 10.1.1.90 0.347 ms 0.340 ms 0.372 ms
traceroute to 10.1.1.90 (10.1.1.90) from 192.168.4.1, 30 hops max, 38
byte packets
1 * 192.168.4.128 0.476 ms 0.394 ms
2 10.1.1.90 0.666 ms 0.767 ms 0.704 ms
===============================
rs# tcpdump -ln host 10.1.1.90
03:45:17.359468 10.1.1.90.1475 > 192.168.4.1.http: S
2756819501:2756819501(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
03:45:17.359468 192.168.4.1.http > 10.1.1.90.1475: S
4029925932:4029925932(0) ack 2756819502 win 5840 <mss
1460,nop,nop,sackOK> (DF)
lvs# tcpdump -n host 10.1.1.90 -i eth0
03:26:01.897830 10.1.1.90.1429 > 192.168.4.1.http: S
2464663323:2464663323(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
lvs# tcpdump -n host 10.1.1.90 -i eth1
03:45:17.627830 10.1.1.90.1475 > 192.168.4.1.http: S
2756819501:2756819501(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
03:45:17.627830 192.168.4.1.http > 10.1.1.90.1475: S
4029925932:4029925932(0) ack 2756819502 win 5840 <mss
1460,nop,nop,sackOK> (DF)
Note, some tcpdump on the lvs server (eth0) is taken at a different
time,
But under identical contitions. The high port numbers and a few other
things are different. If its important, I'll redo the tcpip dump.
Again, I see packets coming back to the LVS on eth1, but they get lost
there. I put "-j LOG" on the NAT PREROUTING and POSTROUTING tables.
The PREROUTING sees all the packets coming back, the POSTROUTING sees
nothing at all.
I don't have a tcpdump for the client machine, it's a windows box. But
I think the lvs# dump on eth0 shows the same thing anyway.
Thanks for your help and effort in trying to help me out, I really
appreciate it.
Kind regards,
Adam
-----Original Message-----
From: lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx
[mailto:lvs-users-admin@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Julian
Anastasov
Sent: Saturday, November 03, 2001 3:56 AM
To: Adam: Kurzawa
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: Problems setting up LVS-NAT
Hello,
On Fri, 2 Nov 2001, Adam: Kurzawa wrote:
> Hi,
>
> I have this problem with packet somehow disappearing from on the LVS
> machine
> while in transit from a real server back to the client.
>
> I followed the HOWTO (MANY times) to try to find the problem, I think
my
> problem is that all packets from the server are dropped on the way
back
> from the real server, same as this Q&A below.
But where are your traceroute results?
> The solution is however, much more difficult, my "rp_filter" is set at
0
> on ALL
> interfaces... and the iptables firewall is set to ACCEPT all packets
on
> all
> tables and chains.
>
> I must have spent over 2 days trying to figure it out, and I am really
> stuck now.
>
> Someone here must know where I should look for the problem. Thanks.
Just follow the HOWTO, step by step. Check this:
Q.2 Traceroute to client goes through LVS box and reaches the client?
May be the first packet is passed but after an ICMP redirect
from
the LVS box the real server is redirected directly to the client which
is
on same device. May be I have to change the HOWTO to execute the
traceroute 5 times, not one - these ICMP redirects are real problem.
From the HOWTO: Please, execute the following commands
and provide tcpdump outputs (even censored is not a problem):
rs# tcpdump -ln host CIP
rs# traceroute -n -s RIP CIP
lvs# tcpdump -ln host CIP
client# tcpdump -ln host CIP
Before starting the LVS commands you should be able to
traceroute from real server to client. This is the simplest test
that guarantees that masquerade is working in both directions.
Then start the IPVS commands and check again. If that fails
then you have to start the LVS debugging via /proc.
I can't see your full report with topology, etc. Did I
missed it somewhere, URL?
> Kind regards,
> Adam: Kurzawa
Regards
--
Julian Anastasov <ja@xxxxxx>
_______________________________________________
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
