Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756039AbZINQKb (ORCPT ); Mon, 14 Sep 2009 12:10:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751276AbZINQKZ (ORCPT ); Mon, 14 Sep 2009 12:10:25 -0400 Received: from gw1.cosmosbay.com ([212.99.114.194]:39473 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751078AbZINQKY (ORCPT ); Mon, 14 Sep 2009 12:10:24 -0400 Message-ID: <4AAE6AED.1070609@gmail.com> Date: Mon, 14 Sep 2009 18:10:21 +0200 From: Eric Dumazet User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stephan von Krawczynski CC: Stephen Hemminger , linux-kernel@vger.kernel.org, davem@davemloft.net, Linux Netdev List Subject: Re: ipv4 regression in 2.6.31 ? References: <20090914150935.cc895a3c.skraw@ithnet.com> <4AAE4BAF.2010406@gmail.com> <20090914175505.a3f132ee.skraw@ithnet.com> In-Reply-To: <20090914175505.a3f132ee.skraw@ithnet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [0.0.0.0]); Mon, 14 Sep 2009 18:10:22 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4369 Lines: 109 Stephan von Krawczynski a ?crit : > On Mon, 14 Sep 2009 15:57:03 +0200 > Eric Dumazet wrote: > >> Stephan von Krawczynski a ?crit : >>> Hello all, >>> >>> today we experienced some sort of regression in 2.6.31 ipv4 implementation, or >>> at least some incompatibility with former 2.6.30.X kernels. >>> >>> We have the following situation: >>> >>> ---------- vlan1@eth0 192.168.2.1/24 >>> / >>> host A 192.168.1.1/24 eth0 ------- host B >>> \ >>> ---------- eth1 192.168.3.1/24 >>> >>> >>> Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B and let >>> host A ping 192.168.2.1 everything works. But if you route 192.168.1.0/24 via >>> interface eth1 on host B and let host A ping 192.168.2.1 you get no reply. >>> With tcpdump we see the icmp packets arrive at vlan1@eth0, but no icmp echo >>> reply being generated neither on vlan1 nor eth1. >>> Kernels 2.6.30.X and below do not show this behaviour. >>> Is this intended? Do we need to reconfigure something to restore the old >>> behaviour? >>> >> Asymetric routing ? >> >> Check your rp_filter settings >> >> grep . `find /proc/sys/net -name rp_filter` >> >> rp_filter - INTEGER >> 0 - No source validation. >> 1 - Strict mode as defined in RFC3704 Strict Reverse Path >> Each incoming packet is tested against the FIB and if the interface >> is not the best reverse path the packet check will fail. >> By default failed packets are discarded. >> 2 - Loose mode as defined in RFC3704 Loose Reverse Path >> Each incoming packet's source address is also tested against the FIB >> and if the source address is not reachable via any interface >> the packet check will fail. >> >> Current recommended practice in RFC3704 is to enable strict mode >> to prevent IP spoofing from DDos attacks. If using asymmetric routing >> or other complicated routing, then loose mode is recommended. >> >> conf/all/rp_filter must also be set to non-zero to do source validation >> on the interface >> >> Default value is 0. Note that some distributions enable it >> in startup scripts. > > Ok, here you can see 2.6.31 values from the discussed box: > (remember, no ping reply in this setup) > > /proc/sys/net/ipv4/conf/all/rp_filter:1 > /proc/sys/net/ipv4/conf/default/rp_filter:0 > /proc/sys/net/ipv4/conf/lo/rp_filter:0 > /proc/sys/net/ipv4/conf/eth2/rp_filter:0 > /proc/sys/net/ipv4/conf/eth0/rp_filter:0 > /proc/sys/net/ipv4/conf/eth1/rp_filter:0 > /proc/sys/net/ipv4/conf/vlan1/rp_filter:0 > > > And these are from the same box with 2.6.30.5: > (ping reply works) > > /proc/sys/net/ipv4/conf/all/rp_filter:1 > /proc/sys/net/ipv4/conf/default/rp_filter:0 > /proc/sys/net/ipv4/conf/lo/rp_filter:0 > /proc/sys/net/ipv4/conf/eth2/rp_filter:0 > /proc/sys/net/ipv4/conf/eth0/rp_filter:0 > /proc/sys/net/ipv4/conf/eth1/rp_filter:0 > /proc/sys/net/ipv4/conf/vlan1/rp_filter:0 > > As you can see they're all the same. Does this mean that rp_filter never > really worked as intended before 2.6.31 ? Or does it mean that rp_filter=0 > (eth1 and vlan1) gets overriden by all/rp_filter=1 in 2.6.31 and not before? > Yes, previous kernels ignored /proc/sys/net/ipv4/conf/all/rp_filter value, it was a bug. commit 27fed4175acf81ddd91d9a4ee2fd298981f60295 Author: Stephen Hemminger Date: Mon Jul 27 18:39:45 2009 -0700 ip: fix logic of reverse path filter sysctl Even though reverse path filter was changed from simple boolean to trinary control, the loose mode only works if both all and device are configured because of this logic error. Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller In your case, you *need* echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter or echo 2 >/proc/sys/net/ipv4/conf/all/rp_filter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/