|
On Wednesday 21 December 2005 20:14 Joseph Mack NA3T wrote:
> > It's my way to solve the good old arp problem - simply
> > drop all arp replies coming from a specific VIP on the
> > realserver...
>
> really? How do packets from the VIP (ie 10.0.4.[12]) get
> back to the client? Wouldn't they be dropped too?
It's arptable, not iptable. ;)
> >> there's a lot of detail here. Are you using a different VIP
> >> for the database than for the web front end (I assume yes)?
> >
> > Yes, of course.
>
> Just checking that I understood what you said. We do have
> code that allows a realserver to be a client of the LVS to a
> VIP that is also on the realserver (see the HOWTO) but
> no-one's tested it yet.
Webservers and database servers are on different machines. I think for further
investigation we can ignore the fact that our webservers are also a balanced
cluster and simply name it "database client" ;)
> Summary:
>
> The SYN packet arrives from the webserver realserver (in the
> webserver LVS). This realserver is a client for the database
> LVS and the packet goes through the database director to the
> database realserver. The database realserver doesn't appear
> to see the SYN packet, but the src/dest IP and ports, and
> the MAC address are OK.
A tcpdump on the database realserver sees the packet, but it's not replied
with a synack (and not with a reset or anything else).
> You only see this with 0.1% if SYN
> packets but not with other packets. You don't see this with
> other (non SYN) packets. Do you know if non-SYN packets
> aren't recognised too and you don't see any problem because
> the packets are resent, or is it that it's only a problem
> with SYN packets?
This only happens to SYN packets. But we've meanwhile found another strange
phenomenon which I've described in a separate thread.
> The problem doesn't occur if the database
> client contacts the database server directly.
> Is the director (VIP) for the database on the same box as
> the director (VIP) for the webserver?
No, this are different machines.
Jan
|
