Re: Specifying names for tap interfaces

[Darren Reed <darrenr%netbsd.org@localhost>]

On 24/06/2012 1:13 AM, Manuel Bouyer wrote:
> On Sun, Jun 24, 2012 at 12:38:28AM +1000, Darren Reed wrote:
>>>> Because it means nothing to the user.
>>>> It only means something to the kernel.
>>>
>>> It depends of the user. It means something to me.
>>
>> 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?

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

>>>> For example, I would love to see drivers and/or networking
>>>> populate a sysctl tree with information about each network
>>>> interface. Driver name, instance number, PHY and MII information
>>>> might be a good place to start?
>>>
>>> I don't think sysctl is a good place for that; I suspect this information
>>> is already available and drvctl can (partially) provide it. drvctl could
>>> be improved for that.
>>
>> drvctl is doing what it does.
>>
>> If what you're saying is that more information should be exported
>> via properties, ok, but the tool to summarise it should be something
>> else and not drvctl. There's nothing to be gained by putting network
>> specific things into drvctl.
>>
>> On the other hand, if you were going to add something to drvctl to
>> simply output the entire device tree, along with device names
>> (similar to Solaris's "prtconf"), that would kind of fit in with
>> drvctl's raison d'etre.
> 
> 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.

>>>> I suppose where I'm coming from is why can't we have something
>>>> like this:
>>>>
>>>> # ifconfig tap create name proxy0
>>>>
>>>> ... where rather creating "tap0" or tap15", the interface gets
>>>> created as "proxy0" and "tap" with a number is never seen.
>>>
>>> But I want a easy way to know that proxy0 is a tap and not something
>>> else. And we're back to something specific to cloning devices, where
>>> a more general mechanism would be useful.
>>
>> So on the one hand you want to create proxy0 or some other label
>> and for people to use that because it is more meaningful but on
>> the other hand, you don't like abstract names like that because
>> they don't tell you anything about the driver.
> 
> No, I didn't say that. I said that if we go with dynamic names instead of
> labels, I want to have the driver name and instance number in ifconfig
> output so I can find the information.
> 
>>
>> The only way you get that is by having the name be something
>> like "wm_proxy0" or something like that.
>>
>> If I have to run a command, such as ifconfig, or something else
>> to get an understanding of what "proxy0" is then it doesn't matter
>> if "proxy0" is just a label for wm6 or wm6 renamed.
> 
> 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.

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, some where it is
output and some where it isn't. 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.

>>> Rinse and repeat for use with xvif.
>>>>
>>>> Ultimately, doesn't the "xvif" part become just an implementation
>>>> detail of what's required to talk to the domU?
>>>
>>> It is. But it's a user-visible detail.
>>
>> Why does a user need to be aware of an implementation detail?
>> Or why does it need to remain exposed?
> 
> Because it's a network interface of the system and we don't have anything
> better to display in network tools ?

Right, so we need something else, aside from ifconfig, that
can go fishing in the kernel for network interface information
and show it to us.

>>> I see. It doens't apply to xvif because they're not created with
>>> a userland tool.
>>
>> So how are the xvif interfaces created?
> 
> When a new network backend appears in the domain's tree in the xenstore
> (usually network backends are in domain0, but they could be in some
> other domains - the Xen architecture allows that - so the interface
> is not always created in the domain where xm create was run).
> 
>>
>> 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.


>>> Why ? I can understand that some chars are troublesome in scripts,
>>> but not all of them are.
>>
>> Because for Un*x the name needs to fit in with applications that
>> expect a name that refers to a network interface following the
>> 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?

Darren