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