Re: vlan support en* or br*?
Hello.
On Thu, Jan 07, 2016 at 02:47:31AM +0000, Ben Hutchings wrote:
[...]
> The real problem is that vconfig (or rather the kernel interface it
> used) imposed any scheme at all. Requiring a '.' is equally short-
> sighted. Let me give an example:
IMHO not equally, but yes... too shortsighted.
[...]
> But instead of letting the names depend on the underlying hardware
> configuration, some time ago I started naming them 'ext0' (modem) and
> 'wl0' (wireless AP) and it's pretty clear which of this is which. When
> I changed the hardware and added VLANs there was very little need to
> change configuration outside of /etc/network/interfaces.
Seems like we're wandering into discussing best-practises and let me
share my view for the potential benefit of mailing list readers...
Obviously the below applies only to a "managed server", not to something
which is basically unmanaged/autoconfigured/zeroconf system (like a
roaming laptop or some embedded device).
I fully agree with giving meaningful "functional" names to your interfaces.
These should NOT be based on what hardware is used, protocol types, vlan,
tunneled, or anything like that but instead on what they're used for,
eg. wan, lan, dmz, ... (or if you prefer: ext, int, ...)
(IMHO it's good to avoid numbers completely in these names, eg. if you
provide separation of your internal network in zones with different
"trust level" instead of int0 and int1, use eg. intwired and intwlan
or whatever your separation/trust-level is based on.)
Using functional names (hopefully/likely) means you've set up a reliable
way to get the same interface named and you're not subject to hardware
ordering, initialization ordering, someone enabling "predicable interface
naming" schemes, etc.
It also provides a good abstraction.
- your firewall rules will be more functional and easier to read when you set
them up as "... -i wan -o lan ..." rather than relying on some hardware
name.
- if you're ISP fscks their routing or similar partial outtakes you can simply
set up a tunnel to somewhere, temporarily take down your "real" wan and name
the tunnel wan and everything else on your system should be ready to go....
This has proven really useful when you provide a somewhat critical service
in my experience.
- ... many other reasons, zero cost abstractions are really useful.
Let me also state that even if you can enable predictable interface naming
using systemd, or whatever, these names are still not functional so you've
still failed to follow best practises if you rely on them. (Let alone if
you think eth* names are reliable you're simply wrong.)
Following these best-practises means the discussions about if systemd
enables predictable interface naming scheme or not is (for people
managing servers) completely uninteresting. You'll simply treat anything
which does not have a functional name as if it's an unused spare. You give
it a functional name /before/ even considering bringing UP the interface.
(I hope it's also obvious that in any zeroconf situation it's useful that an
interface gets the same (initially random as far as I'm concerned) for each
consecutive boot. But for your managed server usecase, this is completely
uninteresting.)
Regards,
Andreas Henriksson
Reply to: