netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Thomas Graf <tgraf@suug.ch>
Cc: Brian Pomerantz <bapper@piratehaven.org>,
	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
Subject: Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
Date: Sat, 05 Nov 2005 02:21:17 +0100	[thread overview]
Message-ID: <436C090D.5020201@trash.net> (raw)
In-Reply-To: <20051105010740.GR23537@postel.suug.ch>

Thomas Graf wrote:
> * Patrick McHardy <kaber@trash.net> 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 ..

  reply	other threads:[~2005-11-05  1:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-04 18:46 [PATCH] [IPV4] Fix secondary IP addresses after promotion Brian Pomerantz
2005-11-05  0:34 ` Patrick McHardy
2005-11-05  0:58   ` Brian Pomerantz
2005-11-05  1:07   ` Thomas Graf
2005-11-05  1:21     ` Patrick McHardy [this message]
2005-11-05  4:28       ` Patrick McHardy
2005-11-05 13:46         ` Thomas Graf
2005-11-07 21:50           ` Thomas Graf
2005-11-08 14:11             ` Patrick McHardy
2005-11-09  0:56               ` Thomas Graf
2005-11-11 13:16                 ` Patrick McHardy
2005-11-16 19:21               ` Brian Pomerantz
2005-11-05 18:39     ` Alexey Kuznetsov
2005-11-05 19:06       ` Thomas Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=436C090D.5020201@trash.net \
    --to=kaber@trash.net \
    --cc=bapper@piratehaven.org \
    --cc=davem@davemloft.net \
    --cc=jmorris@namei.org \
    --cc=kaber@coreworks.de \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pekkas@netcore.fi \
    --cc=tgraf@suug.ch \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).