All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: "Timo Teräs" <timo.teras@iki.fi>
Cc: netfilter-devel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: bad nat connection tracking performance with ip_gre
Date: Tue, 18 Aug 2009 12:38:39 +0200	[thread overview]
Message-ID: <4A8A84AF.7050901@trash.net> (raw)
In-Reply-To: <4A8A7F14.3010103@iki.fi>

Timo Teräs wrote:
> Hi,
> 
> I noticed (in relation to my nbma gre multicast testing) that
> the nat connection tracking code does not cache flows for
> locally originating traffic that is routed to gre tunnel
> (forwarded traffic is ok).
> 
> I basically have a router box with nbma gre tunnel. It gets
> 10/8 traffic. And is routed to internet interface. An ipsec
> xfrm is applied.
> 
> Now, if the router box is forwarding traffic from some
> physical interface, everything works as expected.
> 
> However, if a local process on the router box is sending
> packets that go to gre tunnel, each packet causes a new
> lookup on nat table OUTPUT chain. This is easily verified
> by doing flood ping on router box on private IP and the
> counters on nat table OUTPUT chain default policy start
> to get incremented wildly.
> 
> I tried to oprofile this and it says most of the time is
> spent in ipt_do_table(). I would suppose that the place
> where netfilter hook is called is
> ip_gre.c:ipgre_tunnel_xmit() when it invokes macro
> IPTUNNEL_XMIT() calling ip_local_out().
> 
> Monitoring the connection tracking stats, it looks like
> all packets are reusing the proper connection tracking
> cache entry. But somehow the nat target still gets
> called for the locally originating packets to gre.
> 
> Any ideas how to fix this?

Please use the TRACE target in raw/OUTPUT to trace the flow of
packets through the netfilter hooks:

modprobe ipt_LOG
iptables -t raw -A OUTPUT -j TRACE
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-08-18 10:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-18 10:14 bad nat connection tracking performance with ip_gre Timo Teräs
2009-08-18 10:38 ` Patrick McHardy [this message]
2009-08-18 12:45   ` Timo Teräs
2009-08-18 13:01     ` Patrick McHardy
2009-08-18 13:53       ` Timo Teräs
2009-08-18 14:58         ` Patrick McHardy
2009-08-18 17:39           ` Timo Teräs
2009-08-18 19:36             ` Timo Teräs
2009-08-19  8:40               ` Timo Teräs

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=4A8A84AF.7050901@trash.net \
    --to=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=timo.teras@iki.fi \
    /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.