On Wed, 31 May 2000, Ben Greear wrote:
> jamal wrote:
> > Ben,
> > Your architecture of maintaining a device per VLAN does not scale;
> > (as you might have heard from your numerous attempts to change device
> > lookups).
> I have no intention of changing device lookups. I did write my own method
> of naming them, but that's quite trivial.
> > What is the specific reason that you insist on mapping a VLAN to a device?
> > Have you thought of using a VLAN lookup table instead?
> I do use a vlan lookup table, did you think I do a linear search through
> the vlans for incomming pkts or something??? As far as I recall, every
> lookup involved in any critical path is constant time. That is one of
> the reasons I believe my implementation will scale better than the
> other project... (could be wrong...)
I just scanned through the other code and this is _exactly_ what i had in
mind. ccing the authors incase they are not in the list.
Their scanning algorithm certainly needs improvement
> A VLAN should look just like an ethernet port. I **WANT** it to look
> exactly like a device, so why not actually make it one?? I want to
> use tcpdump on it,
Modify tcpdump to do Vlan recognition (if it doesnt already).
> I want to route, firewall, bridge and do everything
> else that a device would do.
VLANs are primarily for switching. Fair enough that you want to route
them. But you can certainly still do this with policy routing for example.
The only place i see routing taking effect is in the boundary between
VLANs and non-VLAN domains.
Out of ignorance: Is there anyone (vendor) who does routing of VLANs?
firewalling: I believe the bridging folks are trying to move
netfilter/ipchains down there; i dont know what the progress status is.
> How can that be done if the VLAN is not
> a device, and if it could be done, why would it be any more efficient?
Again from the above, you really dont need a device.
Really, take a look at James Leu's MPLS which is a similar (introduces the
extra shim headers etc) but a more complex issue. He doesnt introduce any
Use a table or whatever structure (radix tree etc); allow search by
VLANid, priority etc;
With these you are free to put whatever search schemes, naming conventions
etc that you want instead of subjecting the rest of the kernel to
something that you need for your feature.
In any case when there are two solutions, they need to get unified before
making it into the kernel proper.
On Thu, 1 Jun 2000, Michael Richardson wrote:
> >>>>> "jamal" == jamal <hadi@xxxxxxxxxx> writes:
> jamal> What is the specific reason that you insist on mapping a VLAN
> It is a nice abtraction. It has known interfaces (ifconfig, netstat,route).
hope my comments above answer this.
On Wed, 31 May 2000, Mitchell Blank Jr wrote:
> Is it just impossible to make this scale in 2.5? There are other things
> which could require large numbers of network devices (like large-scale
> PPPoA/PPPoE termination), it would be nice to support them.
1) Fix pppd. Paulus is planning on a total re-write (i think you were
copied on that email) 2) allow for multiple channels per device.
With the new pppox architecture, you can then have a single socket
selecting/polling for multiple circuits.