* [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 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: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: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: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
* 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
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 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).