> Devices map to physical devices i.e ports in your lingo. How many of those
> do you see in your average Linux machine?
The problem is that if you only think about the "common" network types
(ethernet, PPP, etc) this line gets blurred, since there's a one-to-one
* physical devices
* network devices (i.e. things that you can bind IP addresses to,
netfilter based on, tcpdump of)
Any sane implementation of VLANs needs to be a network device in the
> VLANs are virtuals circuits which are abstracted on the device. So are
> PPPOE sessions, ATM *VCs, MPLS LSPs, FR etc and the list goes on.
> They all 'suffer' from the same problem as you, i dont understand why you
> are such a special case.
Neither do I. PPPoE shows up as a device (ppp0). ATM LANE shows up as a
device (lec0). ATM CLIP shows up as a device (atm0).
Currently, atm *cards* don't show up as a network device (since they
can't be bound directly to L3 protocols), but that may need to change
for benefit of SNMP (which wants it to be an enumerable device for
statistics purposes). This is how Cisco deals with ATM - there is
one device for the physical interface and one for each LANE/CLIP running
> You try adding all those thousands of
> VLANs as devices and i can _guarantee you_ that you are not optimizing for
> the common case.
...or thousands of routes, or gigabytes of RAM, etc... do you suggest we
drop kernel support for those too? It's all a matter of finding an
algorithm that scales.
> I like Lennert and Gleb's because they dont use devices for the
> abstraction rather they attach themselves to the device. You dont.
Again, how do I write an IP filter that discerns traffic on
two different VLANSs - for instance imagine we had one shared
ethernet switch that included
* (VLAN 1) Router to outside world
* (VLAN 1, VLAN 2) Linux box acting as masquerading firewall
* (VLAN 2) Internal machines
How do I do this under your system? Keep in mind that for security's
sake we need to make sure that traffic on VLAN1 doesn't spoof an
internal IP address.
> I have heard that the authors of 802.1q
> have already apologized to the world for the mess ;->
Do you have a reference, or is this just flamebait?
I'm sure 802.1q has some interesting applications. Just because it
doesn't solve every problem doesn't mean that it's not worth
supporting well (much like ATM :-)