From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion Date: Sat, 05 Nov 2005 02:21:17 +0100 Message-ID: <436C090D.5020201@trash.net> References: <20051104184633.GA16256@skull.piratehaven.org> <436BFE08.6030906@trash.net> <20051105010740.GR23537@postel.suug.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Brian Pomerantz , netdev@vger.kernel.org, davem@davemloft.net, kuznet@ms2.inr.ac.ru, pekkas@netcore.fi, jmorris@namei.org, yoshfuji@linux-ipv6.org, kaber@coreworks.de, linux-kernel@vger.kernel.org Return-path: To: Thomas Graf In-Reply-To: <20051105010740.GR23537@postel.suug.ch> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Thomas Graf wrote: > * Patrick McHardy 2005-11-05 01:34 > >>You assume all addresses following the primary addresses are secondary >>addresses of the primary, which is not true with multiple primaries. >>This patch (untested) makes sure only to send notification for real >>secondaries of the deleted address. > > > Even this corrected version is only a workaround, the real bug is that > or whatever reason all local routes of seconaries get deleted upon an > address promotion. I started debugging it a bit by looking at the > requests generated by fib_magic() and the resulting notifications, the > local routes just disappear when they shouldn't. > > Situation is: 10.0.0.[1-4]/24 on dev0, 10.0.0.1 is the primary address > and gets deleted while address promotion is enabled. The following > happens: > > [Format:] > Request generated by fib_magic() > Notification event received > > RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link > unicast table main protocol 2 preferred-src 10.0.0.1 > RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link > unicast table main protocol 2 preferred-src 10.0.0.1 > > RTM_DELROUTE 10.0.0.255 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.1 > RTM_DELROUTE 10.0.0.255 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.1 > > RTM_DELROUTE 10.0.0.0 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.1 > RTM_DELROUTE 10.0.0.0 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.1 > > RTM_DELROUTE 10.0.0.1 dev eth0 scope host > local table local protocol 2 preferred-src 10.0.0.1 > RTM_DELROUTE 10.0.0.1 dev eth0 scope host > local table local protocol 2 preferred-src 10.0.0.1 > > RTM_NEWROUTE 10.0.0.2 dev eth0 scope host > local table local protocol 2 preferred-src 10.0.0.2 > RTM_NEWROUTE 10.0.0.2 dev eth0 scope host > local table local protocol 2 preferred-src 10.0.0.2 > > RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link > unicast table main protocol 2 preferred-src 10.0.0.2 > RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link > unicast table main protocol 2 preferred-src 10.0.0.2 > > RTM_NEWROUTE 10.0.0.0 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.2 > RTM_NEWROUTE 10.0.0.0 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.2 > > RTM_NEWROUTE 10.0.0.255 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.2 > RTM_NEWROUTE 10.0.0.255 dev eth0 scope link > broadcast table local protocol 2 preferred-src 10.0.0.2 > > State afterwards: > 4: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 > inet 10.0.0.2/24 scope global eth0 > inet 10.0.0.3/24 scope global secondary eth0 > inet 10.0.0.4/24 scope global secondary eth0 > > broadcast 10.0.0.0 proto kernel scope link src 10.0.0.2 > local 10.0.0.2 proto kernel scope host src 10.0.0.2 > broadcast 10.0.0.255 proto kernel scope link src 10.0.0.2 > > Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_ > any notification. > > I think the correct way to fix this is to prevent the deletion of > the local routes, not just readding them. _If_ the deletion of them > is intended, which I doubt, then at least notifications must be > sent out. I agree, the routes should ideally not be deleted at all. The missing notifications appear to be a different bug. Let me have another look ..