LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: as if you need more direct routing questions..

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: as if you need more direct routing questions..
From: "John Lukac" <johnl@xxxxxxxx>
Date: Mon, 27 Nov 2000 16:58:43 -0800
Hi,

our mail server here went down last week, but it's all fine and working
now.  I trust ya'll had a nice thanksgiving break (for those that had
one).

I had the chance to continue trying to test out the DR method, and I
think I'm beginning to understand it a bit more.  

As it's been more than a week since I've dealt with this, here's the
uber long refresher.  I setup a DR method using ipchains redirect like
this:

some client
 |
router/gw 209.144.204.129
 |
director 209.144.204.132 on eth0 (the VIP)
         netmask 255.255.255.248
         10.23.2.2 on eth1
         netmask 255.255.255.0
 |
real server 10.23.2.101 on eth1
more real servers in 10.23.2.0/24 (e.g. 10.23.2.102)
        the default gw goes to 209.144.204.129

All cables connect to the same vlan on the switch (not segmented).

director commands:
ifconfig eth0 209.144.204.132 netmask 255.255.255.248 up
route add -host 209.144.204.132 dev eth0
route add -net 209.144.204.128 netmask 255.255.255.248 dev eth0
route add default gw 209.144.204.129
--similar steps for the device on eth1 to 10.23.2.2
echo 1 > /proc/sys/net/ipv4/ip_forward
ipchains -A input -j ACCEPT -p tcp -m 1 -s 0.0.0.0/0 -d 209.144.204.132
http
ldirectord.conf set to forward fwmark 1 to the internal web servers  on
80.

real server commands:
add the 10.23.2.101 ip and routes.
route add -net 209.144.204.128 netmask 255.255.255.248
route add default gw 209.144.204.129
echo 1 > /proc/sys/net/ip_forward
ipchains -A input -j REDIRECT 80 -p tcp -d 209.144.204.132 80
arp -s 209.144.204.129 MAC-address

The setup looks good.  When my client is anyone in that 255.255.255.248
netmask (e.g. 209.144.204.130 or .133), I get through to the website NO
problem! However, soon as I step outside the network with the client
(e.g. some ip accross the nation out there), the web client sits there
and doesn't do anything.  

The tcpdumps when I connect from outside the netmasked network:

director ("more stuff" is what looked unimportant):
tcpdump -len tcp port 80:
16:35:26.548133 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:26.548196 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:29.540579 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:29.540600 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:35.549625 eth0 < 0:2:4b:8f:c3:20 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:35.549647 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)

tcpdump -len arp:
16:34:53.458539 eth0 < 0:d0:b7:65:cf:7c 0:0:0:0:0:1 arp 60: arp who-has
209.144.204.132 tell 209.144.204.130
16:34:53.458560 eth0 > 0:0:0:0:0:0 0:d0:b7:bd:5c:5f arp 42: arp reply
209.144.204.132 (0:d0:b7:bd:5c:5f) is-at 0:d0:b7:bd:5c:5f
(0:d0:b7:65:cf:7c)
16:35:31.543165 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:1d:32 arp 42: arp who-has
10.23.2.102 tell 10.23.2.2 (0:d0:b7:c7:1d:32)
16:35:31.543300 eth1 < 0:d0:b7:c7:19:26 0:0:0:0:0:1 arp 60: arp reply
10.23.2.102 is-at 0:d0:b7:c7:19:26 (0:d0:b7:c7:1d:32)

on REALSERVER web2 (10.23.2.102 (setup exact same as web1, 10.23.2.101):

tcpdump -len tcp port 80:
16:35:28.783468 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:31.775804 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)
16:35:37.784717 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 ip 62:
209.144.204.137.4491 > 209.144.204.132.www: (more stuff)

tcpdump -len arp:
16:35:33.778323 eth1 < 0:d0:b7:c7:1d:32 0:0:0:0:0:1 arp 60: arp who-has
10.23.2.102 tell 10.23.2.2
16:35:33.778350 eth1 > 0:0:0:0:0:0 0:d0:b7:c7:19:26 arp 42: arp reply
10.23.2.102 (0:d0:b7:c7:19:26) is-at 0:d0:b7:c7:19:26 (0:d0:b7:c7:1d:32)

And that's all I'm getting.  Anything make any sense?  Do I need to
supply more information?  I tried the other method for hiding arps (echo
1 into the proc/hidden), but it didn't work at all (this ipchains
redirect works to some extent, hehehe).

Phew.  Sorry it's so boring :(

Thank you for any insight you can provide into this, and thanks for the
help last week.
Jano


<Prev in Thread] Current Thread [Next in Thread>