Re: Specifying names for tap interfaces

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Jun 24, 2012 at 03:55:54AM +1000, Darren Reed wrote:
> On 24/06/2012 1:13 AM, Manuel Bouyer wrote:
> >> Yes, but you're a developer.
> >> Not everyone is a developer.
> > 
> > Administrators can understand this too. Users usually don't deal with
> > interface names directly, they use some high-level tool.
> 
> Such as?

I don't know, I'm an admin, I use ifconfig and route :)
But I know there are graphical tools out there to manage network. 
I just don't use them.

> >>> Can you give examples ?
> >>
> >> For example, "lanscan" from HP-UX.
> >>
> >> A good example of its output is here:
> >> http://jreypo.wordpress.com/2010/02/09/playing-with-lanadmin-lanscan/
> > 
> > not sure how this would be useful for me.
> 
> Because it presents network interface information in a much
> easier to parse format than does ifconfig.
> 
> In addition to HP-UX's lanscan there is Solaris's dladm,
> which is better again for administering network interfaces.
> 
> One of the more useful pieces of information available from
> lanscan is the "Path". This represents the device tree to
> which the network interface is connected. Thus it is easier
> to determine if "wm2" is on the same piece of hardware as "wm0",

This would be drvctl's job. This is the kind of informations you may want
to any device, not only network interface.

> > This was what I meant. I misunderstood what you would use sysctl for.
> > I still think sysctl is the wrong place for what you want, but
> > it could be part of ifconfig
> 
> In what way?
> 
> ifconfig is becoming a bigger and bigger mess. Whilst it started
> out life as a tool predominately focused on configuring layer 3
> network addresses (plus some layer 1 things like up/down), it is
> now used for everything from layer 4 to "layer 0" (it creates
> network interface instances and I don't know how to put that in
> the OSI model other than at "layer 0".)
> 
> NetBSD needs to seriously look at the command set for network
> interface administration and enhance the model beyond being
> centered around ifconfig.
> 
> Trying to keep shoe horning everything into ifconfig is just
> going to make ifconfig more and more unwieldly as time goes by.

This is possible. I don't care much as long as I get the infos I want.

> 
> > It's just a matter of what we want to provide as primary information:
> > proxy0 or wm6. As proxy0 could also be
> > some_very_long_name_because_there_s_lot_of_interfaces
> > then I think we should stay with wm6 as the primary information
> > (or output of things like netstat will be awfull).
> 
> Why should wm6 be the primary thing used in output?
> 
> If you want to encourage people to use some other name when
> doing various network administration tasks then why shouldn't
> they see it used in output?
> 
> For example, if I do:
> 
> ifconfig newprojectvlan0 192.168.1.1/24 up
> 
> and then do
> 
> netstat -nrf inet
> 
> then if I don't see a "192.168.1.0/24" route in the routing
> table next to "newprojectvlan0",  I'm going to be awfully
> confused.

You won't see "newprojectvlan0", you'll see "newprojectv". This is
a typical example where long names will be a problem. For anything that
uses a tabular display, you need short names.
 
> 
> Being able to use both the label and some other name for
> the network interface simultaneously will end up just creating
> confusion because there will be some instances where you can
> use the label and some where you can't,

If there are place where it can't this has to be fixed

> some where it is
> output and some where it isn't.

No: the interface name should always be used for output, not the label.

> And none of those decisions
> about where or when it is or isn't used will be under the
> user's control.
> 
> In light of that, if a more meaningful name for a network
> device is desired, it is simpler in every way for there to
> be one name that is used everywhere and to provide the means
> to not only assign the name to a device but to also see what
> names have been assigned to what devices.

If some tools can't use "label,mylabelname" they're likely to also
be problems with arbitrary interface names.

> >> And why can't it benefit from more dynamic interface creation?
> > 
> > I'm not sure what you mean with "more dynamic"
> 
> By dynamic, I mean on demand. Or at least the impression that I
> got from this email thread was that they weren't.

They're created and destroyed with domU creation/destruction.

> >> rather generic rule of "name" followed by "number".
> > 
> > By this rule the name can't be "team-foo-vlan". From there, it doesn't
> > matter much if the tool is not happy with a label prefix, it can't be
> > used anyway and the tool needs to be fixed.
> 
> I think that it is rather widely accepted that a network
> interface name is limited to a string of alphanumeric
> characters of some finite length. It's not just tools on
> NetBSD that you need to worry about but all of those that
> someone might download and install, etc.
> 
> Is it really necessary to be deliberately troublesome?

Well, if "menaingfull names" are limited to 16 chars and shall end with
a number, they're not so usefull for me ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--