|
> 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?
> In short: the arpfilter flag is the other variant to
> block ARP: if you have two interfaces you can restrict the
> ARP responses only for the routes that point to the same interface
> the ARP requests come from. For example:
>
> eth0: 192.168.0.1/24, arpfilter=1
> eth1: 192.168.1.1/24, arpfilter=0
>
> ARP broadcast request for local IP 192.168.0.1:
>
> come from eth0: who-has 192.168.0.1 tell 192.168.0.2 answer, same dev
> come from eth0: who-has 192.168.0.1 tell 192.168.1.2 drop, 1.2 is on eth1
> come from eth1: who-has 192.168.0.1 tell 192.168.0.2 answer
> come from eth1: who-has 192.168.0.1 tell 192.168.1.2 answer
No it's definitely clear, thanks ;)
> 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.
Thank you for all the links and explanations,
Roberto Nibali, ratz
--
mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
|
