|
Hello,
On Sat, 12 Sep 2015, Alex Gartrell wrote:
> On Fri, Sep 11, 2015 at 12:24 PM, Julian Anastasov <ja@xxxxxx> wrote:
> > We can use "ipvs" here. I remember people used
> > matching by src MAC to solve such problem for DR. For TUN
> > fwmark or match by input device can work too. In all cases,
> > a fwmark-based service is needed...
>
> Yeha, to be honest, this approach isn't my ideal. We've had a much
> nastier version of this patch (that adds a field to skbuff...) for a
> long time, and this was just a less awful way of doing this.
>
> The problem for us is that moving the whole of our load balancing to
> fwmark-based pools is a giant nightmare. On top of the obvious stuff
> (redeploying the userspace element to our load balancers), we'd also
> need to find a way to prevent conflict between that and our firewalls.
> It was more engineering than I had time for, sadly.
>
> Other ideas I had to address this:
> * Add some mechanism wherein certain fwmark's are ignored
> * Add an iptables target that sets ipvs_property=1
>
> I'm also totally open to ideas
For now I do not see fatal problems with
this patch except:
- XT_IPVS_IPVS_PROPERTY in xt_ipvs.c can return wrong match,
i.e. someone may think the IPIP traffic from sockets is
generated by IPVS. There can be a warning in ipvs-sysctl.txt
- In the future, if one implements IPIP protocol for IPVS,
the feature will not work
But as the feature is controlled with flag the patch
looks acceptable to me. Just send v2 with changing
"net_ipvs(net)" to "ipvs".
Also, think for adding info for all flags you add
in Documentation/networking/ipvs-sysctl.txt, for this patch
and for your previous work.
Regards
--
Julian Anastasov <ja@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
