RFC: interface description

[Bjoern A. Zeeb]

On Fri, 14 Aug 2009, Andrey V. Elsukov wrote:

Hi,

> Xin LI wrote:
>> The only question I have would be, that is it possible to uniquely
>> identify a NIC without assistance from kernel?  For instance, one can
>> change an interface from being called "em0" to "eth0" and from "bge0" to
>> "em0".  It's easy to track this information through ifconfig(8) with a
>> callback, clean up the file upon restart, but we can not prevent other
>> programs from calling IOCSIFNAME on the interface.  Any idea for this?
>
> What about using interface index as a key(see if_nameindex(3))?

So here comes the usual catch 22 on a classic PC system:
 	you can change everything.

Using RFC 2553 Section 4 is probably the best indeed but has drawbacks
as well.


If you match by xname, renaming the interface will break things.
If you match by dname+unit, unit can still change between boots (see
     further on).
If you match by MAC address the MAC address can be changed by the
     user.
If you match by (PCI/..) slot, cards can be moved.
If you match by card serial number, *oops* most of those don't have
     that in the consumer or even server world so that's not an option.
Because of the above we don't have any metadata that would allow us to
     have persistent ifIndexes between boots.
Once you add portable interfaces (pcmcia, usb, pc card, ..) to the game
     even your ifIndex upon boot may vary depending on if a card is
     plugged in or not or if you added another one, possibly using the
     same driver changing the unit number if unlucky (see above).
Now add cloned interfaces from gif, tun, .. to wlan and you'll
     understand the big (problem|picture).


Now let us look at this from a different view - what can venders do to
avoid all this or how can they handle things:

They might have ways to uniquely identify each interface so an ifIndex
     could possibly always be the same after the interface was first
     put into a device (interface serial number for example).
They usually do not allow renaming of interface names.
They usually do not have physical interfaces coming and going very
     often.
They do have "cloned-a-like" interfaces as well so they have to handle
     them somehow. I have seldomly seen descriptions on those if they
     come and go.  They possibly treat static "tunnel" interfaces, etc.
     more statically having a well defined bringup order.
The cards lose their description if moved to a different slot or
     rather as the interface goes away usually and even if plugged into
     a different slot would lose the description but maybe not the
     ifIndex.


What does that mean for us?

For "dynamic" interfaces storing things with the kernel would for sure
     be easier as if you remove the interface the description is gone.
If not storing in the kernel we get interface insertion and removal
     events already to userspace/devd imho we could use.
The moment you add the description it doesn't matter what the
     interface is, as you can name it always some way.
If you take the classic BSD scheme and will seed the "storage" upon
     boot from scratch from rc.conf or other places you will have a
     consitent ifIndex for all hard wired physical interfaces
     (non-hotpluggable).
     [Unless you move hardware that should even be the same if we don't
     change bus scanning orders, etc.]
For all the cloned stuff things are harder, as we to my knowledge even
     recycle ifIndexes to not have huge gaps in the array (which is a
     real pain), so there are kernel limitations as well in the way
     we store/lookup things that also had come up during the vnet
     merges and that people are aware of.
Bsnmp should have to handle parts of this all already and is for sure
     one of the first consumers so talking to harti and syrinx or
     looking at that code might also be a good thing todo.


My biggest worry comes with the cloned interfaces like tuns or similar
ones if they come and go often; if an ifIndex is recycled and even if
the interface name is the same afterwards there should be no old
description left, so "purging" entries on interface deletion and
possibly asserting that on interface creation would be a good idea.


JustMy2ctAndEndOfBrainDumpInTheMorningBeforeTheFirstCupOfCoffe

/bz


-- 
Bjoern A. Zeeb           What was I talking about and who are you again?