|
Hello,
On Fri, 15 Feb 2002, Jason Wies wrote:
> [replying to an old thread]
I remember you :)
> So I'm a bit confused, any thoughts or previous experiences with
> situations like this would be appreciated.
It seems I have posted misleading information in one of
my answers to you, sorry for this. The trick is near the usage of the
terms DIP and VIP: Under DIP we name the main IP (the preferred
source address) that is used from director to talk to the other
hosts from the subnet where DIP resides. The problem when using
DIP==VIP comes when the director needs to resolve the RIP's link
layer address. The ARP probe looks in this way:
who-has RIP tell VIP
In such case, the real server simply drops this probe
and we can notice that the traffic is not delivered immediately.
I say "immediately" because there is a way director to
obtain the RIP's lladdr: by listening to its ARP broadcasts
when the ARP entry is in incomplete state.
So, to avoid other problems strictly follow the following
postulates:
Postulate #1: How to choose address for VIP
- For DR and TUN methods always use VIP different from the
preferred source address used to talk with the real servers.
This can be checked by using:
ip route get RIP
If the command shows a VIP as preferred source IP you
can expect problems. Solution can be to get all lladdrs from
all real servers and to permanently store them in the director,
may be by using /etc/ethers. This will avoid the above ARP
probes but, of course, the director will not be able to
establish new connections initiated from its VIP to RIPs
because the real servers will treat all traffic announced
from VIP (ARP/IP) as spoofed. If director does not need to
initiate connections to the real servers then you can safely
use /etc/ethers and DIP==VIP setup for DR method but never for
TUN. The TUN method simply originates IPIP traffic with
preferred source IP and this breaks the 1st postulate.
The second most deployed solution is always to use
VIP!=DIP. DIP remains the preferred source IP while VIP is
not used in ARP or IP talks to RIPs:
ifconfig DEV DIP
ifconfig DEV:1 VIP1
ifconfig DEV:2 VIP2
...
the conventional way
> Questions:
>
> a) How stable is the 0.9.x series?
Good enough, we already have a release candidate for stable
version:
http://marc.theaimsgroup.com/?l=linux-virtual-server&m=101248840529968&w=2
> b) Do the hidden flags need to be set before the device is brought up
> and/or before the VIP is added to the device? I have them set in
> /etc/sysctl.conf now, which gets re-read after the devices are up.
Postulate #2: Hiding addresses with the hidden flag
hidden.txt has the needed information:
Never configure shared IP address (hidden VIP) before preconfiguring
the used network interface for this.
The problem is that if the address is added before
fully setting the hidden flags for the used device and in the
all/ section we risk to answer ARP probe(s) for this shared IP
address before the things are successfully configured. If
your rc.d services start too slowly and other hosts on the
LAN probe for VIP on each second they will receive the
wrong answer before the hidden flags are set later at boot.
So, the order is (I don't know what the distros do):
- configure the device for IP (this step allows we to set any
flags for this device later)
ifconfig DEV 0.0.0.0 up
or
ifconfig DEV RIP up
- configure all needed device flags before adding addresses and
routes that will lead this device to receive and send traffic
for i in all dummy* lo # what you need
do
echo 1 > $i/hidden
done
- configure the addresses and routes
ip addr add VIP1 dev lo [scope host]
ip addr add VIP2 dev dummy0 [scope host]
ip addr add VIPNET1/24 dev lo [scope host]
> Thanks,
> Jason Wies
Regards
--
Julian Anastasov <ja@xxxxxx>
|
