netdev - Re: [PATCH v2 iproute2 0/6] Add support for vrf keyword

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 29 Jun 2016 11:06:13 -0600
From:	David Ahern <dsa@...ulusnetworks.com>
To:	Stephen Hemminger <stephen@...workplumber.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH v2 iproute2 0/6] Add support for vrf keyword

On 6/29/16 9:07 AM, Stephen Hemminger wrote:
> On Mon, 27 Jun 2016 11:50:55 -0700
> David Ahern <dsa@...ulusnetworks.com> wrote:
>
>> Currently the syntax for VRF related commands is rather kludgy and
>> inconsistent from one subcommand to another. This set adds support
>> for the VRF keyword to the link, address, neigh, and route commands
>> to improve the user experience listing data associated with vrfs,
>> modifying routes or doing a route lookup.
>>
>> v2
>> - rebased to top of tree
>> - all checkpatch warnings are usage lines. The change in these
>>   patches is consistent with existing code for usage lines
>
> Does this break current user scripts?

I don't see how it can. Existing syntax is not touched so if a user 
wants to run:

$ ip link show master red
$ ip ro sh table 1001

it still works. Using the vrf keyword just makes for a more natural syntax:

$ ip link show vrf red
$ ip ro sh vrf red

in this case I don't have to lookup what table device red is associated 
with ip learns it and shows that table.

>
> It seems this method will cause lots of additional netlink requests
> to check if device is a vrf. Won't this impact users with 1000's of devices?
>

It only adds 1 GETLINK request if the vrf keyword is used. The lookup 
verifies the name is actually a VRF. It's really no different than the 
ll_name_to_index lookups used when processing the command line 
(ll_name_to_index relies on a cache or an ioctl, if_nametoindex).