[Top] [All Lists]

Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: 802.1q Was (Re: Plans for 2.5 / 2.6 ???
From: Lennert Buytenhek <buytenh@xxxxxxx>
Date: Fri, 2 Jun 2000 15:19:15 +0200 (MEST)
Cc: Ben Greear <greearb@xxxxxxxxxxxxxxx>, netdev@xxxxxxxxxxx, Gleb Natapov <gleb@xxxxxxxxxxxxxxxxxxxxx>
In-reply-to: <Pine.GSO.4.20.0006020741140.13652-100000@xxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Fri, 2 Jun 2000, jamal wrote:

> > 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.

What do you mean? (Sorry, I didn't follow the rest of the thread, and I
can't seem to find netdev archives. The page doesn't help a
lot either (Where can I find the xfs cvs details for example?)).

My idea is that VLANs enable you to run multiple logical ethernets over
one physical ethernet. A host that is on multiple VLANs has different IP
addresses for each VLAN it is on. That is why it made sense to me to make
VLANs interfaces. Just like the bridge is an interface.

> > 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).

Yeah, and while we're at it, modify every program that needs to look at
ethernet headers (dhcpd is a nice example).

You say we shouldn't create VLANs as separate interfaces?

> > I want to route, firewall, bridge and do everything else that a
> > device would do.
> VLANs are primarily for switching.

I can think of two uses for 802.1q in linux machines:
1. switching
2. multi-homed host with less NICs than subnet memberships

1 can be done easily. 2 is the case I was interested in. That's why I
didn't optimise the lookup (yet) and made each VLAN a separate interface.
I think most people using VLANs on linux will want to use option 2. In
this case, having a separate device for each VLAN makes sense to me.

> 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.

Well, routing is maybe not the best example. But the fact is that VLANs
look and feel a lot like separate interfaces. That's probably why both
802.1q patches treat them as such.

> Out of ignorance: Is there anyone (vendor) who does routing of VLANs?

I think it would make perfect sense. Connect a bunch of machines from
different VLANs to a VLAN switch, and connect the switch to a VLANning
router via a trunk line.

> firewalling: I believe the bridging folks are trying to move
> netfilter/ipchains down there; i dont know what the progress status
> is.

Eeeeh... those bridging folks would be me. I'm working on it, as time

> 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 new
> devices.

I don't really see yet how we can do clean support without fake devices.
Will his 'solution' let us attach IP addresses to VLAN interfaces for

Do you have a URL?

> 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.

This makes sense, but the fact that both these solutions use fake devices
probably indicates the three of us don't get your point... :)


<Prev in Thread] Current Thread [Next in Thread>