|
On Sat, 16 Sep 2000, Stephen Rowles wrote:
> I'm still not sure that people understand my original configuration /
> problem. I will try to explain clearly:
thanks for the detail
> 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.
your LVS is on ethernet and connnected (possibly by ethernet switches)
to ethernet ports on an ATM router.
> 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.
(I'm not an ATM person, so I wonder why the following: If your director
and real-servers are connected to the same ATM router, I can't imagine why
the ethernet MAC addresses are being preserved or translated to a format
that ATM understands. I would expect that all packets once they arrive on
the ATM network, would have an ATM address from the router.)
> have the MAC address of the ethercard on the ATM router.
> 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 still go for the solution I offered last weekend, to make the director
the default route for all the real-servers and then use one of Julian's
methods to handle the source martian problem (the director is being
asked to forward a packet from the real-server which has src=VIP,
when the director also has the VIP, these packets are called source
martians and are dropped).
1. accept packets on the directory by transparent proxy, ie there is no
VIP on the director and no source martian problem. (haven't tried this,
but it's simple and uses only standard code)
or
2. apply Julian's martian modification to the kernel. (have tried this,
and it works)
In this way all packets coming from the LVS will have the MAC address of
the ethernet card on the outside of the director.
Joe
--
Joseph Mack mack@xxxxxxxxxxx
|
