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]

Message-ID: <54EF37E2.1040506@cumulusnetworks.com>
Date:	Thu, 26 Feb 2015 07:12:34 -0800
From:	roopa <roopa@...ulusnetworks.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

On 2/26/15, 6:03 AM, Eric W. Biederman wrote:
> 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.

agreed, And we have an internal patch that does this for regular routing
on carrier down (which we will upstream soon).
>
> 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.
ack
>
> 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
>
they are marked DEAD on ifdown today (AFAIR they dont generate a 
notification in IPv4)  and are skipped during route lookup.
Only when all the nexthops in a multi-path route are dead, is the route 
multipath route declared dead
and is deleted today (with no notification to userspace in the IPv4 case).

Thanks,
Roopa

--
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