[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 10 Nov 2013 19:12:44 -1000
From: Maciej Żenczykowski <zenczykowski@...il.com>
To: Alexei Starovoitov <ast@...mgrid.com>
Cc: Isaku Yamahata <yamahata@...inux.co.jp>,
Nicolas Dichtel <nicolas.dichtel@...nd.com>,
"David S. Miller" <davem@...emloft.net>,
Linux NetDev <netdev@...r.kernel.org>
Subject: Re: spurious ip forwarding inside namespaces
I've already suggested a month or so back that that patch should be reverted.
On Tue, Nov 5, 2013 at 8:32 PM, Alexei Starovoitov <ast@...mgrid.com> wrote:
> Hi All,
>
> commit 06a23fe31c
> "core/dev: set pkt_type after eth_type_trans() in dev_forward_skb()"
> and refactoring 64261f230a
> "dev: move skb_scrub_packet() after eth_type_trans()"
>
> are forcing pkt_type to be PACKET_HOST when skb traverses veth.
>
> which means that ip forwarding will kick in inside netns
> even if skb->eth->h_dest != dev->dev_addr
>
> The way we hit the problem is the following:
> create 4 or more of netns with veth and attach them to a bridge.
> disable learning on a bridge (via setageing 0), so it will flood
> packets to all namespaces.
> Since ip forwarding and icmp redirect by default is on,
> single icmp request packet from one netns creates a storm of packets,
> since every netns receives it and incorrectly does ip forward on it
> and also incorrectly sends icmp redirect which are multiplied once
> again by flooding in the bridge.
> ping -c1 generates 1 outgoing packet and ~13K incoming packets with
> just 4 netns.
> Running any tcp traffic between such namespaces becomes impossible
> and ksoftirqd cpu usage goes to 100% on all cpus.
>
> Please suggest how to fix this cleanly.
>
> Thanks
> Alexei
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists