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.
--
prev parent 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