Subject: Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion

From: Patrick McHardy <[email-masked]>
Date: Sat, 05 Nov 2005 02:21:17 +0100

Thomas Graf wrote:
> * Patrick McHardy <[email-masked]> 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: <BROADCAST,MULTICAST,UP> 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 ..