|
Hello,
On Tue, 26 Aug 2003, Joseph Mack wrote:
> if/since this works, why do we need transparent proxy (if we ever did)?
The people have alternatives, all these methods differ in some
way and can be selected according to their behaviour. IPVS is
liberal for the local delivery method.
> Can I put this in the HOWTO as a generalised way of accepting packets
> on the director when using fwmark with LVS.
Note the main things:
- fwmark is a common way to mark packets in the kernel, provided
from the firewall functionality
- IPVS can use this marking to know which packets are part from
the virtual service (fwmark-based servers)
- the local delivery does not depend on fwmark, i.e. you can safely
route locally without using fwmarks, eg:
# select incoming packets by DADDR
ip rule add prio 100 to VIP1 table 100
ip rule add prio 100 to VIP2 iif eth0 table 100
ip rule add prio 100 to VIP3 iif eth1 table 100
# and deliver them locally
ip route add local 0/0 dev ANY_DEVICE table 100
Note ANY_DEVICE: it does not matter until you try to play
with the device state, lo is preferred as it is always up
This method does not generate well ICMP errors because it is assumed
the VIPs are not configured as local IPs. The current kernels
have checks for local source IP when generating packets (icmp_send
uses ip_route_output which has such checks starting from 2.4) and
if they are not configured as local IPs the reply is not generated.
So, there are some corner cases where the kernel does not like
our local delivery methods. If that is considered a problem,
better the VIP to be configured locally.
As for the original subject, the LVS directors can not be
real servers, clients and backup servers at the same time
for the same virtual service, the VIP must be announced only
from one director, if the backup director has the VIP configured
then he can not communicate with other hosts from the cluster.
Also, the backup server must not create ARP problem if the VIP
is configured there.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
