|
Hello,
On Sun, 10 Sep 2000, Stephen Rowles wrote:
> My test cluster works fine on the local subnet - the trouble is when you
> connect from a different subnet, and the ATM gets involved in the routing.
>
> > You have to try LVS/DR with hiding the devices in
> > the real servers:
>
> I have two NIC's in each real-server. One is allocated the VIP, NOT
> connected to any network, and hidden to ensure that there is no way that it
> answers arp requests.
Try to set VIP on lo (in the real servers) and not on ATM
device:
ifconfig lo:0 VIP netmask 255.255.255.255
You don't need second device in the real servers!
My assumptions is that all IP addresses configured on
atm device are reported to the ARP server. Hey, I'm not ATM guru :)
You can put only one VIP (on the director) on ATM device.
VIPs in the real servers must be on lo (with netmask 255.255.255.255)
or on dummy device but not on ATM device. If this is not working,
it seems the real servers can't talk using VIP as source of the
packets.
>
> > You can't have two hosts that send ARP replies for
> > one VIP. This is true not only for ATM LIS but also for the
> > Ethernet.
>
> The problem is not with ARP replies but when the real-servers send packets
> back to the client which is trying to connect to the cluster. The
> real-server sends out packets that claim to be from the VIP but they come
> from a different MAC address to that of the director.
Why this is a problem? This is IP, not ARP. Of course, the
ATMARP server will refuse to register second VIP with different ATM
address but we don't need to trigger this problem. But why this
restriction for the source IP address in the packets? In fact, we
send packets from the same subnet.
>
> So, because the ATM sees the ARP replies from the director, it assigns the
> MAC address of the director to the VIP. When the real-servers send out
> packets preporting to be from the VIP the ATM looks at the packets and finds
> a different MAC address. The ATM routing software then just refuses to route
> the packets.
If this is true, LVS/DR can't work on ATM. But I'm not sure
this is the problem.
>
> > This is mandatory! Please, report your results with the
> > hidden flag, you are the first who plays with ATM on this list :)
> >
>
> Having contact the ATM manufactures (via another member of staff who deals
> with ATM maintenance and control) they say that because of the way their IP
> over ATM routers work, there is no way to get the required functionality.
> doh!
I can't believe the IP address check is performed on each
packet. We have to investigate this problem. May be the docs will
help here.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
