netdev
[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: Gleb Natapov <gleb@xxxxxxxxxxx>
Date: Thu, 08 Jun 2000 15:01:31 +0000
Cc: Mitchell Blank Jr <mitch@xxxxxxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, Ben Greear <greearb@xxxxxxxxxxxxxxx>, rob@xxxxxxxxxxx, buytenh@xxxxxxx, netdev@xxxxxxxxxxx, gleb@xxxxxxxxxxxxxxxxxxxxx
Organization: NBase-Xyplex
References: <Pine.GSO.4.20.0006072056240.25240-100000@shell.cyberus.ca>
Sender: owner-netdev@xxxxxxxxxxx
jamal wrote:
> 
> On Wed, 7 Jun 2000, Mitchell Blank Jr wrote:
> 
> > jamal wrote:
> > >
> > > And you can do this just fine with VLANS abstracted on top of devices.
> >
> > OK, explain how.  I've enumerated a dozen or more places either in
> > protocol support or in the user-kernel interface where the
> > configuration or functionality depends on a named device per individual
> > vlan.  You keep ignoring them when I point them out, but they are
> > still there.  For instance, if both the VLANs are called "eth0", how
> > do I set individual settings in /proc/sys/net/ipv4/conf/ for the two
> > different VLANs?  Or any of the other ones I pointed out - take your
> > pick.
> 
> I dont think if i would call both VLANS "eth0"; VLANS would be just
> circuits on top of eth0.
> I would think something like VLAN would require its own config
> tool. ifconfig is probably not the best tool to configure VLANS
> and definetly no close to a swiss army knife; pointing to ifconfig or
> route as reason to set a vlan as a device is a bad excuse.
> 'nuf said.
> 
> Here's what i would have done:
> 
> "vlantool attach to eth0 VLAN10 IP a.b.c.d priority x ... blablah"
> 
> The tool would:
> - use netlink or ioctl to add the IP as another alias to eth0;
> - my own private table inside the kernel would take the rest vlan info;
> searchable by vlanid primarily etc put all your funky search algorithms
> there. I see the ACL stored there as well.
> You might need to maintain some daemon in user space ("vland")
> 
> * Incoming packets get looked up on the table for demuxing, ACL get
> applied etc; they might be dropped right here for example
> -switching happens based on the VLAN table details; or things may be
> sent up to IP;
> * outgoing packets:
> -not a problem if you are switching; just replace VLAN headers;off you go
> ACL rules apply.
> -coming down the stack; extend dst output to be specialized for
> your specific routes entered for your VLANs. This is a little tricky but
> well done by James Leu's MPLS code.
> - add notification on VLAN adds/deletes, device deletes maps to "all vlans
> have been deleted" and Zebra or whatever your favorite Route daemon is
> happy. How the route daemon abstracts things is its own problem;it should
> not force how the kernel should implement things.
> 
> The moral of this:
> - ARP and routing both work ..
> - Your packet mungling (header replacements/adds) work just fine
> 
> Did i miss anything?
> 

 Yes. If you are going to implement VLANs as you've just described you
will have to change each L3 protocol implementation to support VLANs.

--
                        Gleb.

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