|
Hi,
On Fri, 14 Jan 2000, Joseph Mack wrote:
> On Fri, 14 Jan 2000, Julian Anastasov wrote:
>
> > > If the body is sent to an
> > > httpd, what IP must the httpd be listening on for it to accept the
> > > packet - 127.0.0.1, the VIP? (I can check this myself in a minute).
> >
> > It must listen to 0.0.0.0 or to VIP.
>
> if the packet is processed locally, then this is not the
> same thing as sending it to the lo device?
The our end of the connection can be from local
address or if we use transparent proxy from any address. The
transparent proxy support allows the root to bind to any
address (VIP).
>
> > For the software it
> > seems that this IP is local. But there is some services which
> > can make big troubles. They get the list of all local IP addresses
> > from the kernel and bind to them. But with transparent proxy the VIP
> > is not in this list!
>
> why is the VIP not part of 0.0.0.0?
VIP is not in the list of the interfaces when using
transparent proxy. The list with the interfaces can be read
using SIOCGIFCONF ioctl. You can see how the servers use this:
sendmail - option "DontProbeInterfaces", this is mandatory for
the real servers using smtp.
>
> > > I was wondering if it would be possible to adapt Horms' REDIRECT for
> > > VS-Tun to bypass the arp problem. With 2.0.36 kernels on the realserver
> > > and an LVS running VS-Tun, the VIP can be on a lo:0 (or dummy0) device. I
> > > presume this works because the incoming packet is recognised as being of
> > > type IPIP and is decapsulated and it doesn't matter whether the packet
> > > arrives on a tunl, dummy or lo device. With 2.2.x kernels the VIP must be
> > > on a tunl (and not lo or dummy) device for VS-Tun to work. I don't know
> > > why IPIP packets are treated differently in 2.0.36 and 2.2.x kernels.
> >
> > Is it required that VIP must be configured on tunl0 ?
>
> I did this by testing (the results are in the HOWTO). For VS-Tun on 2.0.36
> kernels the VIP can be on lo:0, dummy0 or tunl0 but with 2.2.x kernels the
> VIP only works on a tunl0 device. With VS-DR on a 2.2.x kernel however the
> VIP can be on lo:0, dummy0, tunl0, eth0:0 or eth1.
VIP in the real server must be local uniq in the
LAN/hidden address or handled using transparent proxy. When the
IPIP packet is received it is handled by its protocol type,
i.e. IPIP. Then the decapsulated packet looks like it is
received by the tunl device.
>
> > Why?
>
> no idea. I didn't understand it and when I asked on the list, I didn't get
> a reply.
Our needs are only to accept the connection by:
- using VIP on local interface
- using transparent proxy
Where is configured this VIP in the real server we
don't care. But we must solve the ARP problem when assigning
this VIP to the local interface. The connections is always
from VIP to CIP - with and without the transparent proxy.
>
> > May be the LVS documentation is incorrect too?
>
> it will look a lot different after we understand this :-)
>
Yes, we still expect comments about the wrong
requirement for the tunl IP specified in the docs.
> >
> > You can try this setup for the real server:
> >
> > - eth0 - REALIP
> > - tunl0 - REALIP or another UNIQ IP
>
> just did it.
> client, director, realservers all on 192.168.1.0/24 network
>
> works if tunl0 is 1. 0.0.0.0, no entry for tunl0 in netstat
> or 2. IP=REALIP/255.255.255.0,
> netstat shows tunl0 routes the network REALIP/24
> and eth0 routes the network REALIP/24
> or 3. UNIQIP/255.255.255.0
> netstat shows tunl0 routes the network UNIQIP/24
>
All packets from the Director come through eth0, they
are decapsulated through tunl0 due to IPIP protocol type
and the result packet is processed again. The connection must be from
VIP to CIP.
> > - Transparent proxy for VIP
> >
> > The setup in the Director is same:
> >
> > - eth0 - DIP
> > - eth0:0 - VIP
> > - VS/TUN -> REALIP
> >
> > The requirement is that the real server must accept
> > connections destined for VIP. This is true when:
> >
> > - VIP is local IP address (configured on any interface)
> > - VIP is not local IP but we use Transparent proxy solution to
> > accept connections. Very good solution!
> >
> > So, we must test these two variants for VS/TUN (we know that
> > TRANSPARENT PROXY is working perfectly with VS/DR):
> >
> > 1> With local VIP
> >
> > 1.1> VIP on tunl0 interface, sorry, we can serve only
> > one VIP
> >
> > eth0 - REALIP
> > tunl0 - VIP, ARP problem => tunl0/hidden=1 (2.2.14)
>
> this is the standard setup (with the arp problem handled)?
Yes, I just explained all known variants for VS/TUN setup
in the real server according to the ARP problem solving.
>
> >
> > 1.2> We can serve many VIPs on 'lo' aliases or dummy
> > devices
> >
> > eth0 - REALIP
> > tunl0 - REALIP
> > lo:*/dummy* - VIP, ARP problem => lo/hidden=1 (2.2.14)
> >
> > Is this variant working? Can someone test it and
> > we can change the docs too.
> > I.e. the VS/TUN redirection for VIP to
> > REALIP?
>
> can't test this right now, will try later
> since you seem to understand this, what is the connection
> between the VIP being on any device and tunl0 being on
> the RIP and the IPIP packet having dst=VIP?
Already tested but there is something to investigate.
As you can see from the other my posting we even don't need
to set up valid IP address for tunl0. The Director redirects
the encapsulated packet to our RIP and then it is decapsulated
by magic :)
>
> >
> > 2> No local VIP, use transparent proxy
> >
> > eth0 - REALIP
> > tunl0 - REALIP
> > -d VIP -j REDIRECT
> >
> > Again, not tested.
>
> works (see above)
>
Yes, by this way we can use IPIP with transparent proxy
in the real servers. No ARP problems (thanks to transparent proxy).
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
|
