From: Eric Dumazet <eric.dumazet@gmail.com>
To: Ulrich Weber <uweber@astaro.com>
Cc: Ulrich Weber <ulrich.weber@googlemail.com>,
David Miller <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH] dont create cached routes from ARP requests
Date: Fri, 24 Sep 2010 18:58:29 +0200 [thread overview]
Message-ID: <1285347509.2503.357.camel@edumazet-laptop> (raw)
In-Reply-To: <4C9CD466.4010909@astaro.com>
Le vendredi 24 septembre 2010 à 18:40 +0200, Ulrich Weber a écrit :
> On 09/24/2010 06:05 PM, Eric Dumazet wrote:
> > Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
> >> steps to reproduce:
> >> server:
> >> ip route add 1.0.0.0/8 dev dummy0
> >>
> >> client:
> >> ip route add 1.0.0.0/8 dev eth0
> >> nmap --min-rate 500 -sP 1.0.0.0/8
> >>
> >
> > Great, you use nmap and fill 'client' neighbour cache.
>
> Nope, I fills the 'server' neighbor cache too
> due cached routes in arp_process():
> if (arp->ar_op == htons(ARPOP_REQUEST) &&
> ip_route_input_noref(skb, tip, sip, 0, dev) == 0)
It fills the "server neighbor cache" because you specifically said it
has 2^24 ip addresses.
If using a normal route to gateway on eth0, it only fills route cache,
with a max of 65536 slots on your config, not 1024. When max is reached,
garbage collection takes place.
>
> > Now, back to the _real_ problem, please ?
> >
> > <quote>
> >
> > Background: At home I have two Internet connections, DSL and Cable.
> > DSL is the primary uplink while Cable is the secondary.
> > My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
> > which creates routes via the primary uplink.
> > There are thousands of cached routes and after some time
> > I get "Neighbour table overflow" messages.
> >
> > </quote>
> >
> > You receive an ARP request on device eth1,
> > this creates a route on eth0 ?
> >
> > Could you send your routing/address setup ?
> >
> > ip addr
> > ip ro
> >
>
> ARP request flood comes in via eth2.
>
> Have to correct myself: With configuration below only route cache
> increases but no "Neighbour table overflow".
>
> By adding "ip route add 10.0.0.0/8 dev eth0" the Neighbor table overflow
> will occur.
>
Because you want instead "ip route add 10.0.0.0/8 via gateway"
Or else you are vulnerable to an attack, as you discovered.
Here it works perfectly.
rtstat -c20 -i1|cut -c1-60
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cac
entries| in_hit|in_slow_|in_slow_|in_no_ro| in_brd|in_mar
| | tot| mc| ute| | an_d
1984| 2| 1| 0| 0| 0|
1984| 2| 0| 0| 0| 0|
1984| 2| 0| 0| 0| 0|
1985| 4| 2| 0| 0| 0|
1988| 0| 4| 0| 0| 0|
2020| 1| 33| 0| 0| 0|
2042| 1| 23| 0| 0| 0|
2104| 0| 63| 0| 0| 0|
2117| 0| 14| 0| 0| 0|
2141| 0| 26| 0| 0| 0|
2159| 1| 19| 0| 0| 0|
2175| 0| 17| 0| 0| 0|
2221| 0| 48| 0| 0| 0|
2241| 0| 20| 0| 0| 0|
2256| 0| 17| 0| 0| 0|
2269| 3| 15| 0| 0| 0|
2286| 0| 17| 0| 0| 0|
2295| 1| 10| 0| 0| 0|
2326| 1| 33| 0| 0| 0|
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> inet 127.0.0.1/8 scope host lo
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UP qlen 1000
> inet 78.43.x.x/22 brd 78.43.35.255 scope global eth2
> 12: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc hfsc
> state UNKNOWN qlen 3
> inet 95.114.x.x peer 213.20.56.129/32 scope global ppp0
>
>
> default via 213.20.56.129 dev ppp0
> 78.43.32.0/22 dev eth2 proto kernel scope link src 78.43.x.x
> 127.0.0.0/8 dev lo scope link
> 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
> 213.20.56.129 dev ppp0 proto kernel scope link src 95.114.x.x
>
>
Thanks
next prev parent reply other threads:[~2010-09-24 16:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-22 16:22 [RFC PATCH] dont create cached routes from ARP requests Ulrich Weber
2010-09-23 3:34 ` David Miller
2010-09-23 14:47 ` Ulrich Weber
2010-09-23 15:05 ` Eric Dumazet
2010-09-24 15:00 ` Ulrich Weber
2010-09-24 15:28 ` Eric Dumazet
2010-09-24 15:34 ` Eric Dumazet
2010-09-24 15:43 ` Ulrich Weber
2010-09-24 15:38 ` Ulrich Weber
2010-09-24 16:05 ` Eric Dumazet
2010-09-24 16:40 ` Ulrich Weber
2010-09-24 16:58 ` Eric Dumazet [this message]
2010-09-27 13:11 ` Ulrich Weber
2010-09-23 19:04 ` David Miller
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=1285347509.2503.357.camel@edumazet-laptop \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=ulrich.weber@googlemail.com \
--cc=uweber@astaro.com \
/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