netdev - Re: [PATCH net-next v4] af_mpls: fix undefined reference to ip6_route

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] [day] [month] [year] [list]

Message-ID: <55B8BE92.7080807@brocade.com>
Date:	Wed, 29 Jul 2015 12:52:50 +0100
From:	Robert Shearman <rshearma@...cade.com>
To:	Thomas Graf <tgraf@...g.ch>
CC:	roopa <roopa@...ulusnetworks.com>, <davem@...emloft.net>,
	<netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v4] af_mpls: fix undefined reference to ip6_route_output

On 29/07/15 11:51, Thomas Graf wrote:
> On 07/29/15 at 11:38am, Robert Shearman wrote:
>> On 28/07/15 17:16, roopa wrote:
>>> RTA_OIF is optional for ipv4 and ipv6 routes and we wanted to keep it
>>> that way for mpls routes as well (Quagga is the application in our use
>>> case).
>>> It was a simple patch...until i realized the IPV6 dependency issues (I
>>> will sure remember this next time).
>>
>> Having read the code, I realise the nexthop isn't derived from the lookup.
>> Given that this can only work for the case where a path is recursive via a
>> connected nexthop, it seems to be of limited use.
>>
>> I'm not familiar with the Quagga code, but is it worth adding this
>> additional complexity to the kernel rather than making a change to Quagga
>> instead, where presumably it already has code to derive the output interface
>> in the case of having a recursive route via a non-connected nexthop?
>
> I think it's wrong to assume that it's always a single management
> application that manages both parts of the route. At least for
> underlays and overlays it is fairly common to run something like
> Quagga to manage the underlay and use multiple other orchestration
> tools on top to create virtual networks which should not be aware of
> any underlay specifics.

I agree, but this kernel mechanism doesn't serve that purpose in the 
general case - it only works for a connected nexthop. In other cases, 
the application creating the overlay network (assuming it's not using 
tunnels) will need to the recursive route resolution itself.

I'd like to see recursive route resolution including responding to 
changes in the via route being done in the kernel for other reasons too, 
but IMHO just the derivation of the output interface for a connected 
nexthop on the initial route add doesn't offer much benefit.

Thanks,
Rob
--
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