From: Brent Cook <bcook@breakingpoint.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: <netdev@vger.kernel.org>
Subject: Re: Possible DoS with 6RD border relay
Date: Wed, 4 Jan 2012 22:22:52 -0600 [thread overview]
Message-ID: <201201042222.53147.bcook@breakingpoint.com> (raw)
In-Reply-To: <201201041326.04403.bcook@breakingpoint.com>
On Wednesday, January 04, 2012 01:26:04 PM Brent Cook wrote:
> On Wednesday, January 04, 2012 11:53:20 AM Eric Dumazet wrote:
> >
> > I am not sure of this.
> >
> > Try to change /proc/sys/net/ipv6/route/max_size
> >
> > and /proc/sys/net/ipv6/route/gc_thresh
> >
> > [To something larger than number of in flight packets on your gateway ]
>
> Thanks for the suggestion, I tried 200k:
>
> root@target1:~# echo 200000 > /proc/sys/net/ipv6/route/max_size
> root@target1:~# echo 200000 > /proc/sys/net/ipv6/route/gc_thresh
>
> It did not seem to improve the behavior - once neighbor table overflow
> hits, things go downhill. So far, only modifying the neighbor cache
> threshold seems to improve things.
After some more examination, it appears that the extra neighbor entries are
only allocated for traffic flowing from the native IPv6 host to the 6rd
client. Packets generated from the 6rd client to the native IPv6 host did not
experience a problem by themselves. I originally tested bidirectional TCP
traffic, but switching to unidirection UDP to isolate the routing paths.
Pid: 0, comm: swapper/3 Not tainted 3.2.0-rc7 #8
Call Trace:
<IRQ>
[<ffffffffa013a476>] ? rt6_bind_peer+0x36/0x80 [ipv6]
[<ffffffff8153bed0>] neigh_create+0x30/0x550
[<ffffffff8153923d>] ? neigh_lookup+0xcd/0x100
[<ffffffffa013a182>] rt6_alloc_cow+0x202/0x240 [ipv6]
[<ffffffffa013aa0b>] ip6_pol_route.isra.36+0x38b/0x3a0 [ipv6]
[<ffffffffa013aa7d>] ip6_pol_route_input+0x2d/0x30 [ipv6]
[<ffffffffa015caa1>] fib6_rule_action+0xd1/0x1f0 [ipv6]
[<ffffffffa013aa50>] ? ip6_pol_route_output+0x30/0x30 [ipv6]
[<ffffffff815316b1>] ? dev_queue_xmit+0x1c1/0x630
[<ffffffff81546acd>] fib_rules_lookup+0xcd/0x150
[<ffffffffa015ce64>] fib6_rule_lookup+0x44/0x80 [ipv6]
[<ffffffffa013aa50>] ? ip6_pol_route_output+0x30/0x30 [ipv6]
[<ffffffffa013ab44>] ip6_route_input+0xc4/0xf0 [ipv6]
[<ffffffffa0130177>] ipv6_rcv+0x317/0x3c0 [ipv6]
[<ffffffff8152ed1a>] __netif_receive_skb+0x51a/0x5c0
[<ffffffff8152f990>] netif_receive_skb+0x80/0x90
[<ffffffff8152fd89>] ? dev_gro_receive+0x1b9/0x2c0
[<ffffffff8152fad0>] napi_skb_finish+0x50/0x70
[<ffffffff81530005>] napi_gro_receive+0xb5/0xc0
[<ffffffffa001034b>] e1000_receive_skb+0x5b/0x70 [e1000e]
[<ffffffffa0012122>] e1000_clean_rx_irq+0x352/0x460 [e1000e]
[<ffffffffa00117f8>] e1000_clean+0x78/0x2b0 [e1000e]
[<ffffffff81530214>] net_rx_action+0x134/0x290
[<ffffffff8106c4f8>] __do_softirq+0xa8/0x210
[<ffffffff8160736e>] ? _raw_spin_lock+0xe/0x20
[<ffffffff816116ac>] call_softirq+0x1c/0x30
[<ffffffff81015195>] do_softirq+0x65/0xa0
[<ffffffff8106c8de>] irq_exit+0x8e/0xb0
[<ffffffff81611f63>] do_IRQ+0x63/0xe0
[<ffffffff8160782e>] common_interrupt+0x6e/0x6e
Is this expected behavior? All of the peers in this case are really the same
6RD client - it's really simulating a customer edge router with a few thousand
hosts behind it. I suspect that adding a static route entry for the CE's
prefix via 'sit' will also make the problem go away.
next prev parent reply other threads:[~2012-01-05 4:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 16:48 Possible DoS with 6RD border relay Brent Cook
2012-01-04 17:02 ` Brent Cook
2012-01-04 17:25 ` Eric Dumazet
2012-01-04 17:35 ` Brent Cook
2012-01-04 17:53 ` Eric Dumazet
2012-01-04 19:26 ` Brent Cook
2012-01-05 4:22 ` Brent Cook [this message]
2012-01-05 19:20 ` David Miller
2012-01-04 17:02 ` Eric Dumazet
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=201201042222.53147.bcook@breakingpoint.com \
--to=bcook@breakingpoint.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).