RFC: interface description

[Louis Mamakos]

On Aug 14, 2009, at 3:58 AM, Bjoern A. Zeeb wrote:

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


Interface names (bge0, fxp1, etc.) name ports on the local
host/router.  The use of "interface descriptions" is almost
always an attempt to name or describe what's connected on the other
side of the network interface.  This is what the various "discovery"
protocols, like CDP[1] and LLDP[2] try to solve; to dynamically discover
WTF this port is plugged into.

The problem with ifIndex stability is somewhat related, but you could
imagine choosing some physical identifier (like the manufactured MAC
address) as the name.  The ifIndex in the general case doesn't account
for the user deciding to externally swap the ethernet cables between
a pair of ports.

Louis Mamakos

[1] http://en.wikipedia.org/wiki/Cisco_Discovery_Protocol
[2] http://en.wikipedia.org/wiki/Link_Layer_Discovery_Protocol