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 13:26:04 -0600 [thread overview]
Message-ID: <201201041326.04403.bcook@breakingpoint.com> (raw)
In-Reply-To: <1325699600.2428.39.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wednesday, January 04, 2012 11:53:20 AM Eric Dumazet wrote:
> Le mercredi 04 janvier 2012 à 11:35 -0600, Brent Cook a écrit :
> > On Wednesday, January 04, 2012 11:25:31 AM Eric Dumazet wrote:
> > > Le mercredi 04 janvier 2012 à 11:02 -0600, Brent Cook a écrit :
> > > > I forgot to mention, I'm testing 3.2 rc7:
> > > >
> > > > Linux target1 3.2.0-7-generic #13-Ubuntu SMP Sat Dec 24 18:06:57 UTC
> > > > 2011 x86_64 x86_64 x86_64 GNU/Linux
> > > >
> > > > but the same behavior occurs with 2.6.35
> > >
> > > Please check :
> > >
> > > grep . /proc/sys/net/ipv6/route/*
> >
> > /proc/sys/net/ipv6/route/gc_elasticity:9
> > /proc/sys/net/ipv6/route/gc_interval:30
> > /proc/sys/net/ipv6/route/gc_min_interval:0
> > /proc/sys/net/ipv6/route/gc_min_interval_ms:500
> > /proc/sys/net/ipv6/route/gc_thresh:1024
> > /proc/sys/net/ipv6/route/gc_timeout:60
> > /proc/sys/net/ipv6/route/max_size:4096
> > /proc/sys/net/ipv6/route/min_adv_mss:1220
> > /proc/sys/net/ipv6/route/mtu_expires:600
> >
> > This is a system with 8GB of ram.
> >
> > If I modify gc_thresh to be >= the number of bits the client varies, the
> > system works OK:
> >
> > /proc/sys/net/ipv6/neigh/default/gc_thresh1:128
> > /proc/sys/net/ipv6/neigh/default/gc_thresh2:512
> > /proc/sys/net/ipv6/neigh/default/gc_thresh3:1024
> >
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh1
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh2
> > root@target1:~# echo 200000 > /proc/sys/net/ipv6/neigh/default/gc_thresh3
> >
> > But it seems to be a losing battle since the client has a delegated
> > prefix of /64.
>
> 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.
next prev parent reply other threads:[~2012-01-04 19:26 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 [this message]
2012-01-05 4:22 ` Brent Cook
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=201201041326.04403.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).