On 6/29/16 9:07 AM, Stephen Hemminger wrote:
On Mon, 27 Jun 2016 11:50:55 -0700
David Ahern <d...@cumulusnetworks.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).
