Hello Ratz,
On Tue, 23 Jan 2001, ratz wrote:
> > These URLs are from the linux-kernel discussion. You can find here
> > all the arguments:
> >
> > http://marc.theaimsgroup.com/?t=95743539800002&w=2&r=1
>
> I've read through it ... <big pause> ... well, sigh, I mean: Let's
> also propose the "different routing table" approach with arp_filter
> to lvs users. I mean, as long as they're not going to implemenet or
> even accept the way you/we want to have it (hidden if) this is s
> solution and maybe not even so dirty, just as Andi said, it's dirty
> in configuration but not in c:
>
> ip rule add prio 100 from VIP-net/24 iif eth0 table 100
> ip route add table 100 blackhole VIP
> ip rule add prio 101 from 0/0 iif eth0 table 101
> ip route add table 101 local VIP dev eth0
>
> Is this a solution?
Yes, this solution is in /arp.html: 3. The policy routing approach
But with reduced rules that are enough.
But you can see that this is not a complete solution, we can't
support clients on the same LAN. These rules block both the IP and
the ARP traffic. There is no way to distinguish the requests (arrived
from the LVS box) with saddr=CIP from the ARP probes who-has VIP tell CIP.
The above rules block not only the ARP but also the IP traffic. So,
we can't test the DR method with clients from the LAN. This solution
is for the users that don't run clients on the same LAN. They will block
the ARP probes from the router. We assume connections with saddr=ROUTER
will not come to the real servers :) The router sends only traffic
with saddr=CIP (from the world) to the VIP. But this assumption can
fail very soon. Do we know the standards very well? I don't. I'm not
sure whether the router will not send to the real server packet with
saddr=ROUTER that will be fatally ignored.
> > May be someone can come with exotic advanced routing rules to
> > solve the arp problem. May be I can't see something obvious that allows
> > arpfilter to solve the DR/TUN ARP problem.
>
> In next life probable, I mean you can always write up supercomplex
> routing table setups and mix them with arp_filter and rp_filter and
> fw_mark and whatever you like but I agree with you, that the hidden
> if solution is with LVS the best solution.
No, I'm serious :) May be there is something simple, two or three
commands that will block the ARP but will allow the IP traffic from
the clients. May be by using fwmark in the real server (I'm so happy that
LVS is after the routing in 2.4 :) ):
# Mark only IP, forget ARP
ipchains -A input -d VIP 80 -m 1
# Accept locally the marked IP traffic for VIP
ip rule add prio 100 fwmark 1 table 100
ip route add table 100 local 0/0 dev lo
but make sure the spoofing will not occur (the uplink router must
check the source addresses). Because packet with saddr=VIP and daddr=VIP
will not be detected as spoofed (BTW, you can have many VIPs).
So, the result is:
- we don't have local VIP, so we don't reply for it
- we don't have local VIP, so we don't announce it in the ARP probes
"who-has ROUTER tell VIP". Instead, we use
"who-has ROUTER tell RIP"
- we have rules to accept the IP traffic locally
Are we happy?
May be someone after a little testing can achieve the expected
results. But may be there is something wrong that I'm missing now.
But why so many problems to setup adv routing when you can patch with
the hidden feature and to forget for the problems :))) No security
problems, no complex setups :) But this is only my advice :)
echo 1 > /proc/sys/net/ipv4/conf/all/hidden
echo 1 > /proc/sys/net/ipv4/conf/lo/hidden
Now add your VIPs:
# Single VIP
ip addr add VIP/32 brd + dev lo scope host
# Class C
ip addr add VIP_NET/24 brd + dev lo scope host
It seems everything in 2.4 goes in the opposite direction for
LVS :))) May be because only LVS needs such features :) So, we wait
the kernel features to stabilize and ... then to provide patches for
our needs :)
> Thank you for all the links and explanations,
> Roberto Nibali, ratz
>
> --
> mailto: `echo NrOatSz@tPacA.cMh | sed 's/[NOSPAM]//g'`
Regards
--
Julian Anastasov <ja@ssi.bg>