From: Patrick McHardy <kaber@trash.net>
To: Horms <horms@verge.net.au>
Cc: Ken Brownfield <krb@irridia.com>,
Roberto Nibali <ratz@drugphish.ch>,
netfilter-devel@lists.netfilter.org,
Farid Sarwari <fsarwari@exchangesolutions.com>,
Julian Anastasov <ja@ssi.bg>, David Black <dave@jamsoft.com>,
Joseph Mack NA3T <jmack@wm7d.net>,
David Miller <davem@davemloft.net>
Subject: Re: LVS-NAT and source routing
Date: Tue, 29 Aug 2006 11:06:37 +0200 [thread overview]
Message-ID: <44F4039D.2060909@trash.net> (raw)
In-Reply-To: <20060829073751.GB23278@verge.net.au>
Horms wrote:
> Hi,
>
> sorry that this is a little off-topic, but I'm hoping for some
> advice in relation to a problem with LVS.
>
> When LVS-NAT is in use (basically load-balancing using DNAT)
> then the return packets need to honour any source routing rules
> on the linux-director (machine runing LVS). If you think it as
> if the packets originate from the linux-director then this makes
> sense (if you think about it other ways it doesn't, but I'm pretty
> convinced that this is the right way to think about it.
>
> A long time ago Ken Brownfield sent a patch that resolves this problem
> by using an old variant of ip_route_me_harder() in ip_vs_out(),
> the return patch for LVS-NATed packets.
>
> http://archive.linuxvirtualserver.org/html/lvs-users/2006-03/msg00106.html
>
> I ported this to net-2.6.19 this afternoon, and it seems to
> fall out to a call to ip_route_me_harder() . (Nevermind the skb = *pskb,
> I'd like to clean that up, but its a separate issue.)
>
> I spoke breifly with Dave Miller about whether calling
> ip_route_me_harder() was apprpriate here. His answer was yes, but try
> and call it as infrequently as possible as it is expensive. He pointed
> me at nf_ip_reroute() and how this is used to minimise calls to
> ip_route_me_harder(). However I'm not entirely sure if that techinque is
> applicable to LVS, as the need for ip_route_me_harder() seems to be
> based on the presance of applicable source routing rules and nothing
> else. So here I am.
>
> + /* For policy routing, packets originating from this
> + * machine itself may be routed differently to packets
> + * passing through. We want this packet to be routed as
> + * if it came from this machine itself. So re-compute
> + * the routing information.
ip_route_me_harder is meant for the opposite case, rerouting locally
originating packets as if they were forwarded (if the source is
non-local). For your case just calling ip_route_output_key should be
faster since it saves the inet_addr_type call. I think nf_ip_reroute
doesn't help much since you always seem to change the source address,
but you could make the whole thing depend on CONFIG_IP_MULTIPLE_TABLES.
next prev parent reply other threads:[~2006-08-29 9:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 7:37 LVS-NAT and source routing Horms
2006-08-29 9:06 ` Patrick McHardy [this message]
2006-08-29 9:31 ` David Miller
2006-08-29 12:52 ` Patrick McHardy
2006-08-29 9:40 ` Horms
2006-09-04 3:37 ` Horms
2006-09-10 9:54 ` Patrick McHardy
2006-09-10 13:48 ` Horms
2006-09-15 4:34 ` Patrick McHardy
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=44F4039D.2060909@trash.net \
--to=kaber@trash.net \
--cc=dave@jamsoft.com \
--cc=davem@davemloft.net \
--cc=fsarwari@exchangesolutions.com \
--cc=horms@verge.net.au \
--cc=ja@ssi.bg \
--cc=jmack@wm7d.net \
--cc=krb@irridia.com \
--cc=netfilter-devel@lists.netfilter.org \
--cc=ratz@drugphish.ch \
/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.