LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: hard wired solution to arp problem

To: Joseph Mack <mack@xxxxxxxxxxx>
Subject: Re: hard wired solution to arp problem
Cc: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 27 Nov 1999 09:00:06 +0200 (EET)
        Hi,

On Sat, 27 Nov 1999, Joseph Mack wrote:

> On Sat, 27 Nov 1999, Julian Anastasov wrote:
> 
> Hi Julian, are you up real early or real late. I normally get up at 4:30am
> and so am in bed by about 9:30pm and so normally would not be up now, but
> am shifting my circadian rythm back an hour a day to match Australian
> time.
> 
> > > 
> > > I have assumed that the realservers do not ask "who has ROUTER tell VIP"
> > > - I thought they only asked "who has ROUTER tell realserverIP".
> > 
> >     This is incorrect assumption. If You apply one of the two patches
> 
> one of your two patches (not Stephen's and yours)?

        I'm talking about Stephen's (and others) patch and my patch
(arp_invisible) in http://www.linuxvirtualserver.org/arp.html

> 
> > You will see in the kernel log that real servers send ARP queries with
> > SIP=VIP (who-has LVS tell VIP).
> 
> you have the switches on in the patch?

        Yes, the changes in the ARP packets are reported in the
kernel log. For now.

> 
> I haven't looked real hard for these arp requests with tcpdump
> as the VIP was on wierd devices that I didn't think tcpdump
> listened too (eg tunl0 or lo:0). I will go look.

        You have to tcpdump -i eth0

> 
> > > The realserver has a packet src=VIP,dest=ClientIP but
> > > when it asks for a route to ClientIP it does so from
> > > the realserverIP (I thought). The LVS works fine for
> > > me if there is no route for the VIP on the realservers.
> > 
> >     No. It works because there are no other hosts to ask "who-has VIP
> > tell HOST". 
> 
> Why does a realserver what to know who has the VIP? Doesn't 
> each realserver think it has the VIP and not need to ask 
> (I don't see any arp table entries for the VIP on the
> realservers).

        The other hosts (if any) can ask about VIP but the real servers
ask about their default gateway (LVS, director).

> 
> > But the real servers always ask "who-has LVS tell VIP" and may
> > be reply is not send from LVS as the VIP is configured in LVS too.
> 
> I take it that what you are calling the LVS, I am calling the director (I
> call the LVS=director+realservers). In this case are you saying that the
> realservers are asking for MAC address of the director? Why are
> they doing that? 

        It's their default gateway.

> >     Sorry, I'm always talking about the more complex configuration
> > where any number of the real servers can work as LVS when the host LVS is
> > down. But the above configuration works, i.e. one LVS box and no other
> > hosts on the LAN which can ask "who-has VIP tell HOST".
> > 
> 
> Are you saying that there is one director box and no other realservers
> on the LVS local LAN which can ask "who-has VIP tell realserver"?

        I mean if the director and the real servers are the only hosts and
noone talks with them => there is no ARP problem. The router and the
director are connected on LAN1 and only the director replies to the
router.

> What's going to happen to all of this with the 2.4.x kernels? Are we going
> to have to start all over again like we did with the 2.2.x kernels? Is
> netfilter (which I know almost nothing about) going to change the arp
> problem?

        These patches have to be modified for 2.4. Netfilter can't solve
this problem. Its job is connection tracking, packet mangling and
firewalling. It can only deny ARP queries from the router to the director
but it can't handle the ARP queries "who-has ROUTER/DIRECTOR tell VIP" and
to rewrite them to "who-has ROUTER/DIRECTOR tell WEB1". It's job for the
ARP code.

Regards,

Julian Anastasov


----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx

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