Re: Specifying names for tap interfaces

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

On 23/06/2012 1:42 AM, Manuel Bouyer wrote:
> On Fri, Jun 22, 2012 at 10:13:30PM +1000, Darren Reed wrote:
>>> Right now, the unique identifier of an interface is its name, which is
>>> set by the system when the interface is discovered. I don't think we should
>>> change this part, because we are used to the names as they are now, and it
>>> also carry some information (wm0 is an intel adapter, tap0 is a pseudo
>>> interface, xvif5-0 is a Xen PV backend interface connected to the interface
>>> of index 0 in the guest id 5, etc).
>>
>> The naming of interfaces is dependent on the driver, not the user.
> 
> Yes. I don't see this as a problem.

Because it means nothing to the user.
It only means something to the kernel.

>> The point here is that the driver based interface name conveys some
>> coded information that is meaningful to people that know which drivers
>> use which abbreviations and that's it. That is unless there is some
>> magical way in which random people equate "wm" with "Intel" (yes I know,
>> "man wm".) But note that the user or administrator never gets any choice
>> in whether it is "fxp0" or "wm0", it's decided by programmers that
>> write the drivers.
> 
> But precisely, 'man wm' is usefull, and a way to associate an interface
> name with its driver name is a must have. Actually this is done with
> the name. If we allow the name to change at runtime, there has to be
> a way to find this information (other than "dmesg |grep name", precisely
> because name can change).

Yes and I think that pursuing a way to find that information will
hopefully lead us to developing a tool that delivers more useful
information, not just that "lan0 is wm4".

>> To me this screams out for better management of network interfaces.
>> Something that allows the strings output at bootup to be reported
>> via the CLI, perhaps including how it is attached (but maybe that
>> is going just a bit too far.)
>>
>>> But sometimes we'd like to have more, user-defined information easily
>>> available for interfaces, on systems with lots of interfaces.
>>
>> Definitely.
>>
>>> example 1: xvif5-0 is connected to interface 0 of domU 5. But what is
>>> domU 5 ? I have to use xm list to match the id against a domU's name.
>>> example 2: I have a system with 2 quad-port intel. I know wm6 is
>>> the third port of the second quad-port adapter, but what is it connected to 
>>> ?
>>
>> There's two of issues here that we can address:
>> - why can't xvif5-0 be a more meaningful name?
> 
> Because the kernel (which creates the interface) doesn't have easy access to
> this information.

Yes, this is a fault with the interface cloning interfaces
and perhaps more generally, network interface naming on
NetBSD.

>> - how do we get meaning out of the name"wm6"?
> 
> what we get is "this is the 6th instance of the wm driver".
> We need this information too.

But that's not nearly as useful as you might think it is.

What's important is meaning as to what port and card/slot
the port is associated with.

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?


>>> With xaliases (which could also be called label, this is probably the righ
>>> name for that), users could add some informations to interfaces
>>> (either by hand or by some script). 
>>> In example 1, the /usr/pkg/etc/xen/scripts/vif-bridge script could
>>> label xvif5-0 with the domU's name followed by interface index in the domU
>>> (say, if by domU's name is proxy, the label would be proxy0).
>>> In example 2, /etc/ifconfig.wm5 could contains (this is just an example of
>>> course):
>>> label team-foo-vlan
>>
>> Wouldn't it be better to dispense with the "xvif5-0" altogether
>> and just have "proxy0" as the interface name with nothing else?
>>
>> Do I really need to know that proxy0 is a xvif5-0 when I do
>> check to see which IP addresses are associated with it, etc?
>> Do I even care?
> 
> I want to know it's a xvif, at last. Now, proxy0 could be the name and
> xvif is another data in ifconfig's output, but this information is needed.
> And (sadly) proxy0 can't be created with this name, it has to be changed
> later by the configure script.

What can be done here with Xen and qemu to make it better?

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.

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?

>> In the very least, the way in which network interfaces are created
>> for Xen is rather primitive as the creation of the domU should be
>> when the interface is dynamically created and named rather than
>> depend on a static naming approach.
> 
> I don't understand what you mean here.

See above.

Cloned network interfaces can be created dynamically, which is great,
but unfortunately the entire name needs to be specified and be related
to the name of the driver, e.g.

# ifconfig tun0 create

The problem for scripts is that they need to handle errors in case of
tun0 being in use already. It might even be better to allow something
like this:

# ifconfig tun create
tun4

where the output of ifconfig is the name of the interface created.

This might be a worthwhile change independent of labels.

>>> Then, ifconfig would display the label as part of interface data,
>>> which can give the information to the admin.
>>>
>>> In addition, if we make sure labels are unique in a system, we
>>> could refer to interfaces by label instead of by name (just like
>>> I'd like to use a GPT label in fstab instead of /dev/dkX), we could
>>> use labels in places where names are actually used. If we make the kernel
>>> know that label:X in ifreq is interface's label X and not interface's
>>> name label:X, modifications to network tools should be minimal.
>>
>> What you're depending on here is the fact that all of the
>> existing interface names are much shorter than IFNAMSIZ.
>> That plus the user string being short. The current value
>> of IFNAMSIZ is 16. So the above string...
>>
>> team-foo-vlan:tap0
>>
>> is already too long. So in addition to adding the label string
>> structure, increasing IF_NAMESIZE (probably double it) is also
>> required. That might bear some extra thinking about.
> 
> You're right, 16 is not enough. But with the rename approach, it's not enough
> either (plus, you probably want to keep short name for netstat and other
> outputs, while the admin may want to use long name to describe what the
> interface is).

Well, if I can name the interface with a custom string without the
need for the word label, then there is less pressure on the interface
name length. But if there is a desire for longer interface names such
as "new-project-vlan0", then change is required.

>> On top of that, you'll probably find various parsers will treat
>> the above string as not being an interface name as colons are
>> often used to separate parameters.
> 
> another separator can be used (label,team-foo-vlan, or label/team-foo-vlan)

The name used for network interfaces should be limited to
[a-z], [A-Z], [0-9] and maybe "-" and/or "_".

> I think you're mixing both here. In my proposal we can refer to an
> interface (reusing you example) as:
> tap0
> (this is the name) or
> label:team-foo-vlan

I'm afraid that the alphabet that you want to use for network
interface names (when including the label prefix) is going to
be incompatible with what programs expect/allow.

>> What this really points toward is we need to support being able
>> to rename "tap0" to "team-foo-vlan0" and for there to be some
>> way to identify what "team-foo-vlan0" is (for those that care.)
>> The means for doing that might also enable more information to
>> be displayed about things like "wm0" and "lo0" than are typically
>> easily available today.
> 
> Yes, that may work too. But I fear some people will want to use a string
> that is persistant (at last until the system is rebooted) to refer
> to interface, not something that can be changed ...

Well there should be nothing to force people to use meaningful names.

My perspective on this is that if NetBSD is going to support virtual
network stacks then it is likely those stacks will need to have their
own "lo0", even if it would normally be "lo1". When I approach it from
that perspective, NetBSD will need to support the name in the interface
list for the virtual network stack being different from the "physical"
network interface name. The more general solution for that problem
would seem to me to solve the problem you're trying to address with
a label.

Darren