From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Simon Horman <horms@verge.net.au>
Cc: lvs-devel@vger.kernel.org, netdev@vger.kernel.org,
netfilter-devel@vger.kernel.org, netfilter@vger.kernel.org,
Wensong Zhang <wensong@linux-vs.org>,
Julian Anastasov <ja@ssi.bg>, Patrick McHardy <kaber@trash.net>
Subject: Re: [PATCH] ipvs: restore support for iptables SNAT
Date: Thu, 02 Jun 2011 13:51:27 +0200 [thread overview]
Message-ID: <4DE7793F.1060108@netfilter.org> (raw)
In-Reply-To: <1306973394-29504-2-git-send-email-horms@verge.net.au>
On 02/06/11 02:09, Simon Horman wrote:
> From: Julian Anastasov <ja@ssi.bg>
>
> Fix the IPVS priority in LOCAL_IN hook,
> so that SNAT target in POSTROUTING is supported for IPVS
> traffic as in 2.6.36 where it worked depending on
> module load order.
>
> Before 2.6.37 we used priority 100 in LOCAL_IN to
> process remote requests. We used the same priority as
> iptables SNAT and if IPVS handlers are installed before
> SNAT handlers we supported SNAT in POSTROUTING for the IPVS
> traffic. If SNAT is installed before IPVS, the netfilter
> handlers are before IPVS and netfilter checks the NAT
> table twice for the IPVS requests: once in LOCAL_IN where
> IPS_SRC_NAT_DONE is set and second time in POSTROUTING
> where the SNAT rules are ignored because IPS_SRC_NAT_DONE
> was already set in LOCAL_IN.
>
> But in 2.6.37 we changed the IPVS priority for
> LOCAL_IN with the goal to be unique (101) forgetting the
> fact that for IPVS traffic we should not walk both
> LOCAL_IN and POSTROUTING nat tables.
>
> So, change the priority for processing remote
> IPVS requests from 101 to 99, i.e. before NAT_SRC (100)
> because we prefer to support SNAT in POSTROUTING
> instead of LOCAL_IN. It also moves the priority for
> IPVS replies from 99 to 98. Use constants instead of
> magic numbers at these places.
I have applied this to my net-next-2.6 tree. Once it hits linus tree,
I'll pass it to -stable.
http://1984.lsi.us.es/git/?p=net-next-2.6/.git;a=shortlog;h=refs/heads/pablo/nf-next-2.6-updates
next prev parent reply other threads:[~2011-06-02 11:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-02 0:09 [GIT PULL pablo/nf-2.6-updates] IPVS Simon Horman
2011-06-02 0:09 ` [PATCH] ipvs: restore support for iptables SNAT Simon Horman
2011-06-02 11:51 ` Pablo Neira Ayuso [this message]
2011-06-02 13:01 ` Simon Horman
-- strict thread matches above, loose matches on Subject: below --
2011-05-29 22:01 Julian Anastasov
2011-05-31 13:26 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DE7793F.1060108@netfilter.org \
--to=pablo@netfilter.org \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=kaber@trash.net \
--cc=lvs-devel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=netfilter@vger.kernel.org \
--cc=wensong@linux-vs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.