Re: Specifying names for tap interfaces

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 25.06.2012 00:33, Scott Solmonson wrote:
> This has been a pain point for me before-
> 
> Since MACs are UUIDs-

No they are not. You can use MACs to generate UUIDs (the RFC says so),
but it does not turn it into an UUID per-see.

> Is there a good reason why any interface "naming" (essentially,
> aliasing) should be automated at all?
> (specifically to avoid and card removal/replacement/moving problems)
> Is there any reason why, in the system/OS-level config, a fully manual
> mapping of MAC1->eth0, MAC2->eth1, MAC(n)->eth(n) shouldn't be
> *required*?
> It's difficult for me to find one.
> 
> If I replace a NIC with another, and the automation swaps its naming
> with another NIC, my firewall is now broken, potentially in a VERY
> BAD(TM) way. If I'm adding more NICs and move an existing one to a
> different slot, and the automation changes up its naming based upon
> seeing the same MAC in a different slot (and/or gets entirely
> confused, which has happened to me in Linuxland), that's VERY
> ANNOYING(TM).
> 
> I'm eager to hear any and all arguments in support of automated NIC
> naming, versus a one-time static-mapping config similar to that which
> is needed to simply assign an IP address and netmask etc :)

When you work with VMs the MAC is very, very often randomly generated,
because you do not have a centralized entity (the NIC's manufacturer)
that assigns a unique MAC address to the card. Well, the guy running VMs
should play that role anyway, but in the real world nobody does nor
cares. It is the half-bogus way of ensuring you do not end up having
multiple VMs with the same MAC address somewhere on your LAN.

If the name assignment was not (partially) automated, you would have to
rewrite your firewall/network config files each time your system boots,
because the one-time mapping is not valid anymore. Annoying, even more
so when you are a VPS provider with thousands of thousands of VMs based
on the same skeleton.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost