[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: vlan support en* or br*?



On Wed, 2016-01-06 at 22:32 +0100, Andreas Henriksson wrote:
> Hello again.
> 
> On Wed, Jan 06, 2016 at 07:27:00PM +0000, Ben Hutchings wrote:
> > On Wed, 2016-01-06 at 19:40 +0100, Andreas Henriksson wrote:
> > > Hello.
> > > 
> > > Since this isn't the first time the vlan package with its deprecated
> > > vconfig command causes discussions I've gone ahead and uploaded
> > > a new version of the package to experimental. See vlan 2.0 also
> > > available from https://people.debian.org/~ah/vlan-2.0/ for the
> > > impatient who doesn't want to wait for archive updates and mirror syncs.
> > [...]
> > 
> > Nice, but you still kept vconfig's name restriction.  Could you please
> > also change the ifupdown scripts to work with any device name so long
> > as vlan-id and vlan-raw-device are specified?
> 
> Thanks for having a look at this. Please let me elaborate....
> 
> I personally don't see a point in the vlan package. I've already
> suggested it should be removed. The only reason to keep it I can agree
> with is that we still don't give users a better (automated) upgrade
> path. For new installs I see absolutely no point in using it at all.
> Obviously not everyone agrees on this and that's why I wanted to atleast
> get rid of the ioctl based vconfig which noone argues is still needed.
> 
> The reason I don't think the ifupdown integration provided by vlan
> package is needed is because ifupdown itself provides vlan configuration
> possibilities these days. From what I can tell from the manual ifupdowns
> vlan support should support whatever name you give your underlying
> (real) interface ("foo"). It only forces you to use a period (.) in the
> name (eg. "foo.123" for vlan id 123, while vconfig had several possible
> naming schemes for no apparent reason).

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:

Our home server has a trunked link to a wireless/wired switch running
OpenWRT.  VLAN 2 is bridged to a VDSL modem and VLAN 3 to the wireless
AP.  The default names for these VLAN interfaces on the server would be
'eth1.2', and 'eth1.3' respectively.

The previous hardware for this server had three separate Ethernet ports
and I dedicated one each to the modem and wireless AP.  The default
names for those interfaces would have been something like 'eth1' and
'eth2'.

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.

But currently I have this hack:

# No real inet configuration, this only carries tagged frames
iface int1 inet manual
        pre-up ip link set int1 up
        post-up ip link add link int1 name wl0 type vlan id 3; ip link add link int1 name ext0 type vlan id 2
        pre-down ip link delete wl0; ip link delete ext0
        post-down ip link set int1 down

> Thus if you don't like the limitations of the vlan packages ifupdown
> integration, just use the built-in functionality of ifupdown instead!
> For anyone interested in this please see the interfaces(5) man page
> and look at the "VLAN AND BRIDGE INTERFACES" chapter.
[...]

This does at least imply that ifupdown would be the right place to
implement flexible VLAN support now.  Thanks for pointing me in the
right direction.

Ben.

-- 
Ben Hutchings
Life would be so much easier if we could look at the source code.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: