Re: Specifying names for tap interfaces

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

On Sat, Jun 23, 2012 at 07:56:17PM +1000, Darren Reed wrote:
> 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.

It depends of the user. It means something to me.

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

Can you give examples ?

> 
> >> 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.

No. In this specific case it's because of the way Xen works.
A xvif interface is created because an entry is written to the
xenstore for it. We have to work with the informations available in
the xenstore; when the entry for the xvif is written the guest's name
may not be availble yet. We have to live with that.
A cloning interface can create an interface with arbitrary name (there's
no limitation in the kernel other than the name lenght). The limitation
are
- what is available when the kernel creates the interface
- POLA (a user wouldn't expect a tap device to be named anything else
  but tapX).


> 
> >> - 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?

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.

> 
> 
> >>> 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?

For qemu I don't know (maybe it already have what's needed).
For Xen, we'd have to check in which order informations are
written to the xenstore (for all xen versions we support).

> 
> 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 usefull.

> 
> 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.

> 
> >> 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.

I see. It doens't apply to xvif because they're not created with
a userland tool.
I agree it would be usefull.


> 
> >>> 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.

I think there is a need for longuer label, yes. With lots of interface,
16 characters won't be enough to give meaningfull label to all of them.
I looked at the vlan descriptions at work, more than half of them have
description (in the cisco world) longer than 16 chars.

> 
> >> 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 "_".

Why ? I can understand that some chars are troubesome in scripts,
but not all of them are.

> 
> > 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.

This has to be explored I guess

> 
> >> 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.

For this is looks like you want unique interface name in a name domain,
but not accross domains. It looks like a different problem and I'm not
sure how your "more general solution" would fix this

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