[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1285347509.2503.357.camel@edumazet-laptop>
Date: Fri, 24 Sep 2010 18:58:29 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Ulrich Weber <uweber@...aro.com>
Cc: Ulrich Weber <ulrich.weber@...glemail.com>,
David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] dont create cached routes from ARP requests
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
--
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