|
On Thu, 18 Jan 2001, Julian Anastasov wrote:
> > |
> > ------------------------------------
> > | | |
> > | | |
> > RIP1=192.168.1.2 RIP2=192.168.1.3 RIP3=10.1.1.4 (all eth0)
^^^^^^^^
hmm this should be 192.168.1.4
> > _____________ _____________ _____________
> > | | | | | |
> > | real-server | | real-server | | real-server |
> > |_____________| |_____________| |_____________|
> >
>
> Joe, the setup with two different logical networks can work
> but when the client and the real server share same logical network
> the masquerading can't work.
hmm I'm not clear on "logical" network here (you use this term a bit
so I'd better find out what you mean).
In the original HOWTO I had a 1 NIC director with client,VIP on
192.168.1.0/24 and the real-servers,director_insideip on 10.1.1.1/24.
This works fine. (I assume this is 1 physical network, 2 logical
networks.)
A 2 NIC director with 2 networks is easy.
Here I've got a VS-NAT to work with 1 physical network, and all machines
on the same 192.168.1.0/24 network (1 logical network).
> > Remove the route to 192.168.1.0/24.
> >
> > realserver:/etc/lvs#route del -net 192.168.1.0 netmask 255.255.255.0 dev
> > eth0
> >
> > This will leave you with
> >
> > realserver:/etc/lvs# netstat -r
> > Kernel IP routing table
> > Destination Gateway Genmask Flags MSS Window irtt
> > Iface
> > 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
> > 0.0.0.0 director 0.0.0.0 UG 0 0 0
> > eth0
>
> Wow, if you don't have RIP how the LVS traffic is working :)
this is the output of netstat -r, not ifconfig -a. The RIP is still there.
> > The VS-NAT LVS now works. If LVS is forwarding telnet, you can
> > telnet from the client to the VIP and connect to the real-server.
>
> May be to another real server with RIP configured ?
no I watched the hostname at the login prompt when I telnet'ed in.
> > You can ping from the client to the real-server.
> >
> > You can also connect _directly_ to services on the real-server NOT
> > being forwarded by LVS (in this case e.g. ftp).
>
> To which IP ? Hm, are the packets really accepted from the
> real server?
yes, when you ftp to the RIP, you get the correct hostname at the prompt.
(ftp is NOT being LVS'ed)
> The theory is true here. What can happen is that when a packet
> reaches the real server and there is no RIP in the real server, the
> packet will be forwarded to the next hop: the director because it is
> a default gateway. May be the packet will loop until the IP TTL is
> expired or may be it will be dropped. But soon after the ARP entry in
> the director's cache is invalidated the traffic from LVS to the
> director will stop.
do you have an explanation if there is a RIP on the real-server?
> > I don't know why I don't see the connect request from client->real-server.
>
> Because the director redirects the client via ICMP redirect
> directly to the real server. The real servers sends SYN+ACK through the
> director (showed in the tcpdump output) to the client. But the director
> does not have such connection entry (the initail SYN skipped the director
> after the ICMP redirect) and replies with PORT_UNREACH to the real
> server. This terminates the handshake in the real server.
>
> I assume the tcpdump will show ICMP redirects from the director
> to the client: "go to the real server directly". Are there such redirects?
redirects are off on the director :-)
however tcpdump is not showing PORT_UNREACH packets etc.
> > The first packet I see is the ack from the real-server,
> > which will be forwarded via the director.
> > The director will rewrite the ack to be from the director.
>
> But there is no such LVS entry, PORT_UNREACH is replied.
yes
> Joe, can you perform tests with two different Class C networks: one
> for the client, the external DIP and the VIP and one "internal" network
> for the NAT-ed real servers and the internal director DIP used as def
> gw in the real servers. Something like the above picture, with
> send_redirects=0. I assume this should work without any problems.
yes it does. It's in the HOWTO :-)
Joe
--
Joseph Mack mack@xxxxxxxxxxx
|
