public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@vyatta.com>
To: Julian Anastasov <ja@ssi.bg>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: BUG - routes not correctly deleted when address is deleted
Date: Wed, 1 Dec 2010 12:34:26 -0800	[thread overview]
Message-ID: <20101201123426.082f224f@nehalam> (raw)
In-Reply-To: <alpine.LFD.2.00.1012011136420.1645@ja.ssi.bg>

On Wed, 1 Dec 2010 12:08:42 +0200 (EET)
Julian Anastasov <ja@ssi.bg> wrote:

> 
>  	Hello,
> 
> On Tue, 30 Nov 2010, Stephen Hemminger wrote:
> 
> > If multiple addresses are assigned to an interface, and
> > a route is created that uses that address.  The route is not
> > deleted when the address is deleted.  Linux does cleanup properly
> > when the last address is deleted; it seems the FIB lacks the callback
> > to cleanup routes referencing an address.
> >
> > Simple example:
> >
> > # modprobe dummy
> > # ip li set dev dummy0 up
> > # ip addr add 192.168.74.160/24 dev dummy0
> > # ip addr add 192.168.18.11/24 dev dummy0
> > # ip ro add 74.11.49.0/24 via 192.168.74.160
> 
>  	Such routes look as old way to create direct
> routes over some device, used by "route" tool.
> Device is inherited from the local IP used as gateway.
> Such local gateways IPs are not used, see rt_set_nexthop()
> where nh_scope is checked. FIB removes routes only when
> the deleted IP is a prefsrc for this route, so may be
> it is a good idea to use prefsrc.

These are the kind of routes routing daemons like Quagga
create.

> > # ip addr del 192.168.74.160/24 dev dummy0
> > # ip ro show dev dummy0
> > 74.11.49.0/24 via 192.168.74.160
> > 192.168.18.0/24  proto kernel  scope link  src 192.168.18.11
> >
> > Before I go off and either brute force it (add another call back
> > into fib_hash and fib_trie), is there a better way?
> 
>  	Adding prefsrc is recommended. For me, it is not fatal
> such routes to stay because nh_gw is not used. It is a
> way to say at configuration time:

This isn't done by routing daemons.


> ip ro add 74.11.49.0/24 dev eth0
> 
>  	If you need such route to depend on the lifetime
> of some local IP then you need to specify prefsrc.
> 
>  	If you go ahead with changes may be you should call 
> fib_sync_down_dev from fib_del_ifaddr by providing the IP
> as new argument. While fib_sync_down_addr is called when this
> IP is removed from the last device where it was configured,
> now for nh_gw fib_sync_down_dev should be called for every
> fib_del_ifaddr call. For me, it is a complication, not sure
> what others think.

Probably just going to make the existing fib_sync_down_dev
take an optional address.

-- 

      reply	other threads:[~2010-12-01 20:34 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-01  0:55 BUG - routes not correctly deleted when address is deleted Stephen Hemminger
2010-12-01 10:08 ` Julian Anastasov
2010-12-01 20:34   ` Stephen Hemminger [this message]

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=20101201123426.082f224f@nehalam \
    --to=shemminger@vyatta.com \
    --cc=davem@davemloft.net \
    --cc=ja@ssi.bg \
    --cc=netdev@vger.kernel.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