Hello,
On Fri, May 05, 2000 at 08:47:31AM +0300, Julian Anastasov wrote:
> In essential the problem is: we have IPV4 address
> (VIP, Virtual IP) configured on many hosts on one LAN. This
> can be a web cluster for example. All web hosts are "hidden"
> on this LAN after a Director (on the same LAN). The clients
> see only the Director and they send their packets to him.
> But these replies are forwarded to the internal web server
> and the answer is not returned through the Directed, i.e.
> this is the difference from the masquerading. The ougoing
> trafficc has its own path. The Director is not a default
> gateway for the web servers. This setup is normal for a such
> cluster:
>
[snip]
> client -> router -> director -> web1/web2 -> router -> client
>
> This is the simplest variant. The more complex is using many
> routers for the incoming and many routers for the outgoing
> traffic.
>
> The Director is just a router which forwards the incoming
> requests to the real servers based on some policy:
> scheduling methods.
>
> We want:
>
> 1. only one to reply to the ARP requests for VIP, i.e. the
> traffic to come to the Director and to be forwarded to one
> of the real (internal) servers. If all hosts reply to the
> Router's ARP broadcast requests we have a problem.
>
> Filters? OK, the above can be handled using filters. Just
> stop the ARP replies from the real servers.
You may solve the issue in a more simple way: fix VIP->MAC translation to
Director's address on your router, so that ARP isn't used at all.
The filters proposed by Andi work here, too.
>
> 2. the real servers must not broadcast ARP requests with
> saddr=VIP because only the Director must announce VIP. For
> this the real servers must announce another IP as source
> address for the ARP request. I.e. requests such as "who-has
> ROUTER tell VIP" are allowed for the Director only. The
> real hosts must announce another visible (and uniq) IP
> address to the router or the reply will not be received.
> This can't be handled using a filter. This is a logic.
You may easily implement it without any kernel modifications.
Check how ARP engine selects source address. In the current kernels it picks
up the address from the same network without "secondary" flag.
Select which address do you want to see by setting up this address as the
primary. If you may choose IP address for Director->node communications from
the different network than node->router communications, then it's done.
Otherwise, you may set IP address for node->router communications as primary
and address for Director->node communications as secondary, and assign proper
preffered sources for all routes. Not very hard, too.
BTW, I fix the plain-and-dumb ARP source selection in my patch.
ftp://ftp.sw.com.sg/pub/Linux/people/saw/kernel/v2.3/route.generic
(look at arp.c changes).
When I manage to integrate it into the mainstream kernel, this problem will
be solvable even more simplier.
In any case, you don't need special kernel hacks to do implement your
requirement #2.
>
> These are the minimum requirements from this
> functionality for the LVS project. The LVS users hide "lo",
> "dummy*" and even "tunl*". In fact, we want to hide IP
> addresses, not devices.
That's my point!
The solution in 2.2 kernels tries to solve problems messing about wrong
objects, sorry for being frank.
If you do not like existing features, add special address flags.
Or add special table for ARP engine specifying what address to use and which
replies to ignore. Let's do it in a natural way :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:16 EST