|
Hello,
On Thu, 18 Jan 2001, Joseph Mack wrote:
> 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
This is a different network address, internal.
> hmm I'm not clear on "logical" network here (you use this term a bit
> so I'd better find out what you mean).
Different subnets. Many logical networks in one physical.
"Subnets" is not a correct term. 10.0.0/24 is not a subnet in 192.168/16.
May be both are subnets in 0.0.0.0/0 :)
>
> 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
Wonderful
> 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).
Hm, I now understand. So, is it really working or there are
problems?
>
> > > 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.
Oh, well.
> > 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?
The gateway address is not reachable. It must be onlink, i.e.
on directly connected link. This is true for any network mask for the
RIP address if you delete the link route. If you delete the def gw and
try to add it this operation must fail. Of course, I may be wrong.
> > > 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.
Well, the redirects are disabled. If they are enabled I assume the
client will be redirected using ICMP message to the real server. Can
you repeat this test: make sure send_redirects are 0 and always flush
the routing cache in each host.
> > > 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 :-)
Very good!
> Joe
>
> --
> Joseph Mack mack@xxxxxxxxxxx
Regards
--
Julian Anastasov <ja@xxxxxx>
|
