Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932152AbbHFKNX (ORCPT ); Thu, 6 Aug 2015 06:13:23 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:35538 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753378AbbHFKNV (ORCPT ); Thu, 6 Aug 2015 06:13:21 -0400 MIME-Version: 1.0 In-Reply-To: <55C24BAE.7090702@gmail.com> References: <55C1D207.3040905@iogearbox.net> <55C24BAE.7090702@gmail.com> From: Zang MingJie Date: Thu, 6 Aug 2015 18:13:01 +0800 Message-ID: Subject: Re: [BUG] net/ipv4: inconsistent routing table To: Alexander Duyck Cc: Daniel Borkmann , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2709 Lines: 90 On Thu, Aug 6, 2015 at 1:45 AM, Alexander Duyck wrote: > On 08/05/2015 02:06 AM, Daniel Borkmann wrote: >> >> [ please cc netdev ] >> >> On 08/05/2015 10:56 AM, Zang MingJie wrote: >>> >>> Hi: >>> >>> I found a bug when remove an ip address which is referenced by a routing >>> entry. >>> >>> step to reproduce: >>> >>> ip li add type dummy >>> ip li set dummy0 up >>> ip ad add 10.0.0.1/24 dev dummy0 >>> ip ad add 10.0.0.2/24 dev dummy0 > > > Okay, so up to this point you have 2 addresses on the same subnet that are > now on dummy0. > >>> ip ro add default via 10.0.0.2/24 > > > This makes the default route go through 10.0.0.2. > >>> ip ad del 10.0.0.2/24 dev dummy0 > > > Then you remove 10.0.0.2 from the local system, however since 10.0.0.1 is on > the same subnet dummy0 would still be the correct interface to access > 10.0.0.2 it is just no longer local to the system. > >>> after deleting the secondary ip address, the routing entry still >>> pointing to 10.0.0.2 > > > You didn't delete the default routing entry so why would you expect it to > change? All you did is remove 10.0.0.2 from the local system. I believe > the assumption is that 10.0.0.2 is still out there somewhere, it just isn't > on the local system anymore. Yes, 10.0.0.2 is migrated to somewhere else > >>> # ip ro >>> default via 10.0.0.2 dev dummy0 >>> 10.0.0.0/24 dev dummy0 proto kernel scope link src 10.0.0.1 > > > This matches up with what I would expect. 10.0.0.2 is the default gateway > and it is accessible from dummy0 since 10.0.0.0/24 is accessible from > dummy0. This means 0.0.0.0/0 is accessible via 10.0.0.2 on the network of dummy0 > >>> but actually, kernel considers the default route is directly connected. >>> >>> # ip ro get 1.1.1.1 >>> 1.1.1.1 dev dummy0 src 10.0.0.1 >>> cache > > > I'm not sure how you came to the "directly connected" conclusion. It is > still routing things out through 10.0.0.2 from 10.0.0.1. > > Maybe your example would work better if you used 10.0.0.1 and 10.0.1.1 > instead. Then I think you might be able to better see that when you delete > the second address the route would be broken. No, it isn't. when ping 1.1.1.1, kernel will directly send arp request braodcast to 1.1.1.1, this is not what I expect. it should send arp request to 10.0.0.2, following should be the correct routing entry: # ip ro get 1.1.1.1 1.1.1.1 via 10.0.0.2 dev dummy0 src 10.0.0.1 cache > > - Alex -- 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/