All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] dont create cached routes from ARP requests
@ 2010-09-22 16:22 Ulrich Weber
  2010-09-23  3:34 ` David Miller
  0 siblings, 1 reply; 14+ messages in thread
From: Ulrich Weber @ 2010-09-22 16:22 UTC (permalink / raw)
  To: netdev

Do we really have to cache routes based on ARP requests?
Are there any other reasons than expecting new connections?

Attached is a patch to skip caching for ARP requests
not related to local IP addresses or ARP proxy.

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.

Cheers
 Ulrich

---
[PATCH] dont create cached routes from ARP requests

except for local destination or enabled ARP proxy. Otherwise
Neighbour table can overflow on broken network setups.

Signed-off-by: Ulrich Weber <uweber@astaro.com>
---
 include/linux/in_route.h |    1 +
 net/ipv4/route.c         |    5 ++++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/linux/in_route.h b/include/linux/in_route.h
index b261b8c..d97dd35 100644
--- a/include/linux/in_route.h
+++ b/include/linux/in_route.h
@@ -18,6 +18,7 @@
 #define RTCF_MASQ	0x00400000 /* unused */
 #define RTCF_SNAT	0x00800000 /* unused */
 #define RTCF_DOREDIRECT 0x01000000
+#define RTCF_NOCACHE	0x02000000
 #define RTCF_DIRECTSRC	0x04000000
 #define RTCF_DNAT	0x08000000
 #define RTCF_BROADCAST	0x10000000
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e24d48d..7f05e45 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1090,7 +1090,7 @@ restart:
 	candp = NULL;
 	now = jiffies;
 
-	if (!rt_caching(dev_net(rt->dst.dev))) {
+	if (rt->rt_flags & RTCF_NOCACHE || !rt_caching(dev_net(rt->dst.dev))) {
 		/*
 		 * If we're not caching, just tell the caller we
 		 * were successful and don't touch the route.  The
@@ -2001,6 +2001,9 @@ static int __mkroute_input(struct sk_buff *skb,
 			err = -EINVAL;
 			goto cleanup;
 		}
+		if (!(out_dev->dev->flags & IFF_LOOPBACK) &&
+		    !IN_DEV_PROXY_ARP(in_dev) && !IN_DEV_PROXY_ARP_PVLAN(in_dev))
+			flags |= RTCF_NOCACHE;
 	}
 
 
-- 
1.7.0.4


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  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
  0 siblings, 1 reply; 14+ messages in thread
From: David Miller @ 2010-09-23  3:34 UTC (permalink / raw)
  To: uweber; +Cc: netdev

From: Ulrich Weber <uweber@astaro.com>
Date: Wed, 22 Sep 2010 18:22:09 +0200

> Do we really have to cache routes based on ARP requests?
> Are there any other reasons than expecting new connections?
> 
> Attached is a patch to skip caching for ARP requests
> not related to local IP addresses or ARP proxy.
> 
> 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.

If you get neighbour table overflows, something is holding a reference
to the routing cache entry and/or the neighbour entries those routing
cache entries are attached to.

If these really are transient entries, they should be trivially
garbage collected and not cause any problems at all.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-23  3:34 ` David Miller
@ 2010-09-23 14:47   ` Ulrich Weber
  2010-09-23 15:05     ` Eric Dumazet
  2010-09-23 19:04     ` David Miller
  0 siblings, 2 replies; 14+ messages in thread
From: Ulrich Weber @ 2010-09-23 14:47 UTC (permalink / raw)
  To: David Miller; +Cc: netdev

On Wed, Sep 22, 2010 at 08:34:42PM -0700, David Miller wrote:
> From: Ulrich Weber <uweber@astaro.com>
> Date: Wed, 22 Sep 2010 18:22:09 +0200
> 
> > 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.
> 
> If you get neighbour table overflows, something is holding a reference
> to the routing cache entry and/or the neighbour entries those routing
> cache entries are attached to.
> 
> If these really are transient entries, they should be trivially
> garbage collected and not cause any problems at all.
rt_garbage_collect is not called within rt_intern_hash,
because the call is done within softirq context.

Forcing the call of rt_garbage_collect didn't help either,
there are no routes freed afterwards...

Cheers
 Ulrich

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-23 14:47   ` Ulrich Weber
@ 2010-09-23 15:05     ` Eric Dumazet
  2010-09-24 15:00       ` Ulrich Weber
  2010-09-23 19:04     ` David Miller
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2010-09-23 15:05 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: David Miller, netdev

Le jeudi 23 septembre 2010 à 16:47 +0200, Ulrich Weber a écrit :
> On Wed, Sep 22, 2010 at 08:34:42PM -0700, David Miller wrote:
> > From: Ulrich Weber <uweber@astaro.com>
> > Date: Wed, 22 Sep 2010 18:22:09 +0200
> > 
> > > 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.
> > 
> > If you get neighbour table overflows, something is holding a reference
> > to the routing cache entry and/or the neighbour entries those routing
> > cache entries are attached to.
> > 
> > If these really are transient entries, they should be trivially
> > garbage collected and not cause any problems at all.
> rt_garbage_collect is not called within rt_intern_hash,
> because the call is done within softirq context.
> 
> Forcing the call of rt_garbage_collect didn't help either,
> there are no routes freed afterwards...
> 

Please give us more information.

grep . /proc/sys/net/ipv4/route/*

rtstat -c10 -i1

Thanks



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-23 14:47   ` Ulrich Weber
  2010-09-23 15:05     ` Eric Dumazet
@ 2010-09-23 19:04     ` David Miller
  1 sibling, 0 replies; 14+ messages in thread
From: David Miller @ 2010-09-23 19:04 UTC (permalink / raw)
  To: uweber; +Cc: netdev

From: Ulrich Weber <uweber@astaro.com>
Date: Thu, 23 Sep 2010 16:47:08 +0200

> Forcing the call of rt_garbage_collect didn't help either,
> there are no routes freed afterwards...

Then you need to find out why :-)

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-23 15:05     ` Eric Dumazet
@ 2010-09-24 15:00       ` Ulrich Weber
  2010-09-24 15:28         ` Eric Dumazet
  0 siblings, 1 reply; 14+ messages in thread
From: Ulrich Weber @ 2010-09-24 15:00 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi Eric,

please find the output in the attached text file.

Neighbor garbage collection wont't work because all
neighbor records are bound to cached routes.

Forced route garbaged collections returns without freeing
any routes, probably because the route threshold is quite high
with 65536 compared to the small neighbor threshold of 1024,
resulting in a fixed amount of 1024 cached routes...

Instead of running the garbage collection we could flush the route
cache completely if the neighbor cache overflows.
But why do we have to cache that routes in first place ?
See the previous patch which skips caching for that kind of routes.

Cheers
 Ulrich

[-- Attachment #2: cache_debug.txt --]
[-- Type: text/plain, Size: 8009 bytes --]

/proc/sys/net/ipv4/route/error_burst:1250
/proc/sys/net/ipv4/route/error_cost:250
/proc/sys/net/ipv4/route/gc_elasticity:8
/proc/sys/net/ipv4/route/gc_interval:60
/proc/sys/net/ipv4/route/gc_min_interval:0
/proc/sys/net/ipv4/route/gc_min_interval_ms:500
/proc/sys/net/ipv4/route/gc_thresh:65536
/proc/sys/net/ipv4/route/gc_timeout:300
/proc/sys/net/ipv4/route/max_size:1048576
/proc/sys/net/ipv4/route/min_adv_mss:256
/proc/sys/net/ipv4/route/min_pmtu:552
/proc/sys/net/ipv4/route/mtu_expires:600
/proc/sys/net/ipv4/route/redirect_load:5
/proc/sys/net/ipv4/route/redirect_number:9
/proc/sys/net/ipv4/route/redirect_silence:5120

/proc/sys/net/ipv4/neigh/default/gc_interval:30
/proc/sys/net/ipv4/neigh/default/gc_stale_time:60
/proc/sys/net/ipv4/neigh/default/gc_thresh1:128
/proc/sys/net/ipv4/neigh/default/gc_thresh2:512
/proc/sys/net/ipv4/neigh/default/gc_thresh3:1024

net-next:
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
 entries|  in_hit|in_slow_|in_slow_|in_no_ro|  in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
        |        |     tot|      mc|     ute|        |  an_dst|  an_src|        |    _tot|     _mc|        |      ed|    miss| verflow| _search|t_search|
      10|     255|       2|       1|       0|       0|       0|       0|     128|      17|       2|       0|       0|       0|       0|      15|       3|
     199|       1|     189|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     433|     190|     234|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
     433|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       1|       0|
     433|     235|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     533|     119|     100|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       1|       0|
     533|     219|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     533|     219|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     551|     406|      18|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
     551|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
     551|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
     973|       1|     422|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       9|       0|
     973|     423|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
     973|     423|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     357|      68|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     413|      11|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     413|      11|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     124|     300|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     124|     300|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|
    1030|     125|     300|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       2|       0|

next-next with forced rt_garbage_collect
rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|rt_cache|
 entries|  in_hit|in_slow_|in_slow_|in_no_ro|  in_brd|in_marti|in_marti| out_hit|out_slow|out_slow|gc_total|gc_ignor|gc_goal_|gc_dst_o|in_hlist|out_hlis|
        |        |     tot|      mc|     ute|        |  an_dst|  an_src|        |    _tot|     _mc|        |      ed|    miss| verflow| _search|t_search|
       8|      43|       2|       0|       0|       0|       0|       0|     129|      20|       3|       0|       0|       0|       0|       1|       1|
     138|       1|     130|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     431|     131|     293|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     431|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     431|     294|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     531|     120|     100|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     531|     220|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     531|     220|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|
     550|     405|      19|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     550|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     550|     424|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       3|       0|
     972|       1|     422|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       1|       0|
     972|     423|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       1|       0|
     972|     423|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       0|       1|       0|
    1029|     358|      66|       0|       0|       0|       0|       0|       0|       0|       0|       9|       0|       0|       0|       1|       0|
    1029|     415|       9|       0|       0|       0|       0|       0|       0|       0|       0|       9|       0|       0|       0|       1|       0|
    1029|     415|       9|       0|       0|       0|       0|       0|       0|       0|       0|       9|       0|       0|       0|       1|       0|
    1029|     122|     302|       0|       0|       0|       0|       0|       0|       0|       0|     302|       0|       0|       0|       2|       0|
    1029|     122|     302|       0|       0|       0|       0|       0|       0|       0|       0|     302|       0|       0|       0|       2|       0|
    1029|     122|     302|       0|       0|       0|       0|       0|       0|       0|       0|     302|       0|       0|       0|       2|       0|

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  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:38           ` Ulrich Weber
  0 siblings, 2 replies; 14+ messages in thread
From: Eric Dumazet @ 2010-09-24 15:28 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev

Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
> Hi Eric,
> 
> please find the output in the attached text file.
> 
> Neighbor garbage collection wont't work because all
> neighbor records are bound to cached routes.
> 
> Forced route garbaged collections returns without freeing
> any routes, probably because the route threshold is quite high
> with 65536 compared to the small neighbor threshold of 1024,
> resulting in a fixed amount of 1024 cached routes...
> 
> Instead of running the garbage collection we could flush the route
> cache completely if the neighbor cache overflows.
> But why do we have to cache that routes in first place ?
> See the previous patch which skips caching for that kind of routes.

What are the packets you receive ? A flood of ARP answers ?

a "tcpdump -X" of a few packets would help to understand.




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  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
  1 sibling, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2010-09-24 15:34 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev

Le vendredi 24 septembre 2010 à 17:28 +0200, Eric Dumazet a écrit :

> What are the packets you receive ? A flood of ARP answers ?
> 
> a "tcpdump -X" of a few packets would help to understand.
> 
> 


Also please report 

grep . `find /proc/sys -name arp_accept`




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 15:28         ` Eric Dumazet
  2010-09-24 15:34           ` Eric Dumazet
@ 2010-09-24 15:38           ` Ulrich Weber
  2010-09-24 16:05             ` Eric Dumazet
  1 sibling, 1 reply; 14+ messages in thread
From: Ulrich Weber @ 2010-09-24 15:38 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev

Yes, as I wrote before my Cable ISP is flooding me with
ARP requests from 10.0.0.0/8, which get a route
via the primary PPP link.

I know thats not a common setup but why do that
kind of routes have to be cached ? :)


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


On 09/24/2010 05:28 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:00 +0200, Ulrich Weber a écrit :
>> Hi Eric,
>>
>> please find the output in the attached text file.
>>
>> Neighbor garbage collection wont't work because all
>> neighbor records are bound to cached routes.
>>
>> Forced route garbaged collections returns without freeing
>> any routes, probably because the route threshold is quite high
>> with 65536 compared to the small neighbor threshold of 1024,
>> resulting in a fixed amount of 1024 cached routes...
>>
>> Instead of running the garbage collection we could flush the route
>> cache completely if the neighbor cache overflows.
>> But why do we have to cache that routes in first place ?
>> See the previous patch which skips caching for that kind of routes.
> 
> What are the packets you receive ? A flood of ARP answers ?
> 
> a "tcpdump -X" of a few packets would help to understand.
> 
> 
> 


-- 
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 15:34           ` Eric Dumazet
@ 2010-09-24 15:43             ` Ulrich Weber
  0 siblings, 0 replies; 14+ messages in thread
From: Ulrich Weber @ 2010-09-24 15:43 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev

/proc/sys/net/ipv4/conf/all/arp_accept:0
/proc/sys/net/ipv4/conf/default/arp_accept:0
/proc/sys/net/ipv4/conf/lo/arp_accept:0
/proc/sys/net/ipv4/conf/eth0/arp_accept:0
/proc/sys/net/ipv4/conf/dummy0/arp_accept:0

On 09/24/2010 05:34 PM, Eric Dumazet wrote:
> Le vendredi 24 septembre 2010 à 17:28 +0200, Eric Dumazet a écrit :
> 
>> What are the packets you receive ? A flood of ARP answers ?
>>
>> a "tcpdump -X" of a few packets would help to understand.
>>
>>
> 
> 
> Also please report 
> 
> grep . `find /proc/sys -name arp_accept`
> 
> 
> 


-- 
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 15:38           ` Ulrich Weber
@ 2010-09-24 16:05             ` Eric Dumazet
  2010-09-24 16:40               ` Ulrich Weber
  0 siblings, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2010-09-24 16:05 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev

Le vendredi 24 septembre 2010 à 17:38 +0200, Ulrich Weber a écrit :
> Yes, as I wrote before my Cable ISP is flooding me with
> ARP requests from 10.0.0.0/8, which get a route
> via the primary PPP link.
> 
> I know thats not a common setup but why do that
> kind of routes have to be cached ? :)
> 
> 
> 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.

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




^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 16:05             ` Eric Dumazet
@ 2010-09-24 16:40               ` Ulrich Weber
  2010-09-24 16:58                 ` Eric Dumazet
  0 siblings, 1 reply; 14+ messages in thread
From: Ulrich Weber @ 2010-09-24 16:40 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Ulrich Weber, David Miller, netdev

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)

> 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.


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


-- 
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 16:40               ` Ulrich Weber
@ 2010-09-24 16:58                 ` Eric Dumazet
  2010-09-27 13:11                   ` Ulrich Weber
  0 siblings, 1 reply; 14+ messages in thread
From: Eric Dumazet @ 2010-09-24 16:58 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: Ulrich Weber, David Miller, netdev

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH] dont create cached routes from ARP requests
  2010-09-24 16:58                 ` Eric Dumazet
@ 2010-09-27 13:11                   ` Ulrich Weber
  0 siblings, 0 replies; 14+ messages in thread
From: Ulrich Weber @ 2010-09-27 13:11 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev

Hi Eric,

thanks for the correction! Searched through the log files and discovered
that the initial "Neighbor overflow" message was caused by an IPv6 ping
scan from the Internet.

rt_garbage_collect() is called from dst_alloc and rt_intern_hash. In any
case no routes will be freed if the total entries are smaller than
ipv4.route.gc_thresh.

neigh.default.gc_thresh is static while ipv4.route.gc_thresh is based on
system memory. Wouldn't it make sense to set neigh.default.gc_thresh
based on system memory too?

Cheers
 Ulrich

-- 
Ulrich Weber | uweber@astaro.com | Software Engineer
Astaro GmbH & Co. KG | www.astaro.com | Phone +49-721-25516-0 | Fax –200
An der RaumFabrik 33a | 76227 Karlsruhe | Germany

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2010-09-27 13:27 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
2010-09-27 13:11                   ` Ulrich Weber
2010-09-23 19:04     ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.