netdev - Re: [PATCH net-next 7/8] mpls: Multicast route table change notifications

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Feb 2015 08:03:35 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	roopa <roopa@...ulusnetworks.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Stephen Hemminger <stephen@...workplumber.org>,
	santiago@...reenet.org,
	Vivek Venkatraman <vivek@...ulusnetworks.com>
Subject: Re: [PATCH net-next 7/8] mpls: Multicast route table change notifications

roopa <roopa@...ulusnetworks.com> writes:

> On 2/25/15, 9:19 AM, Eric W. Biederman wrote:
>> Unlike IPv4 this code notifies on all cases where mpls routes
>> are added or removed as that was the simplest to implement.
>>
>> In particular routes being removed because a network interface
>> goes down or is removed are notified about.  Are there technical
>> arguments for handling this differently ? Userspace developers
>> don't particularly like the way IPv4 handles route removal
>> on ifdown.
> that is true. However, from previous emails on this topic on netdev,
> there is no reason to notify these deletes to userspace thereby creating a
> notification storm
> when userspace can figure this out. Which seems like a valid reason.
> (Your approach resembles IPv6 which does generate these notifications and
> userspace is usually happy with this).

Grr.  There is an even better way to do this.

The semantically best way to handle this is to simply not use routes for
forwarding where the network inteface is down, the carrier is down, or
the network device has gone away for forwarding.

Apparently there are some multi-path scenearios that already do this
legitimately, and routes going away auto-matically can cause userspace
other kinds of problems.

In MPLS I especially don't want to free the routing table slot until I
know that the change has propagated in the network and I can be
reasonably confident that no-one will send me traffic on that label.
Otherwise there is a chance the label will be reused too soon.

Grumble.  That is a code change I need to make.  Grumble.

I also need to look and see if those multi-path scenarios report a next
hop as dead or just rely on the network interface state (which I think
it is) to be sufficient information relayed to userspace

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html