|
hi.
> I'm not sure whether this is the problem. For now, I prefer to
> think there is an ARP problem. May be the real server reports the VIP
> to the ARP server because it is configured on atm device.
>
> Regards
> --
> Julian Anastasov <ja@xxxxxx>
I'm still not sure that people understand my original configuration /
problem. I will try to explain clearly:
We have a high capacity fibre ATM backbone which is used to connect several
buildings and levels of buildings together. All inter-building / inter-floor
/ external (internet) traffic is routed over the ATM switching gear. The ATM
hardware that we are using provides "edge-devices" which allow the routing
of IP traffic over the ATM backbone.
At a local level all that is physically connected to any ATM hardware /
routing is standard ethernet switches. These in turn are either connected
directly to servers, or via hubs to each of the machines on a given floor of
the building. Each switch is connected to a separate port on the edge-device
to provide different sub-nets.
LVS-DR works fine over the local sub-net where no traffic is routed across
the ATM backbone, all the traffic is just over a local sub-net of 100 or so
machines. Having followed the FAQ for ARP work-arounds I have had no
problems with setup (1 director and 2 real-servers) provided they are
accessed from the same sub-net.
The problem begins when I attempt to connect from a machine which requires
routing across the ATM backbone. To investigate the problem I have used
packet sniffers (ethereal - Wonderful package!) and discovered that packets
from the real-servers never make it across the ATM backbone to the client
machine which requested the connection (I can see them leave the real-server
but they do not appear at the client).
When this happens the ATM management software complains about duplicate IP
addresses and refuses to route the packets. The company that provides the
ATM hardware and management software have stated that it is not possible for
the ATM to route packets which have the "wrong" MAC address for the IP.
The ATM can only route packets for an IP which has the MAC address as
advertised by an ARP-reply packet. Any IP packet which has a different MAC
address will not (and according to the company CANNOT) be routed.
I wish there was an easy solution to the problem but at the moment I cannot
find one. I am glad to see someone else has had the same problems - it just
confirms I'm not going completely mad! I hope that a solution can be found
but whatever the solution is I am sure that it is not an ARP problem /
solution.
|
