jamal wrote:
> > interface. I don't see what makes you think that what 'ifconfig -a'
> > shows are devices they are _interfaces_. Interface can be attached to
> > device (eth0), can be not (dummy0, lo), one interface can be attached to
> > many devices (bridging), many interfaces can be attached to single
> > device (tunneling, vlans).
>
> Ok, so do you use ifconfig to attach a vlan to a device? And why not?
> Sure go ahead and extend ifconfig so now it knows about attaching and
> deleting VLANs on a device. After all, it is another interface ;->
ifconfig is a big hairy beast, so I wrote a separate program to create/destroy
VLANs, and do specific VLAN things. However, once they are created, then I am
able to use ifconfig to set their IP address, UP/DOWN, and everything else
you might want to do to an ethernet 'device'. Both programs do what they
do best, and no existing user level applications need to be patched.
> A VLAN is a way of logically separating traffic, across the same device
> (or equipment)
> Device being a physical entity; i would prefer to call a VLAN a circuit
> And sure i dont mind re-writting ifconfig so it knows about such things.
> But i dont know if it would still be called ifconfig.
So how about we call it a circuit, and then use a struct net_device to hold
the circuit information? Since it walks, looks, and quacks like an ethernet
device, we could just put it in the same kernel management structures that hold
the other ethernet devices... :)
> I am not ruling out IPX or Gleb's protocol. If IPX was so important
> why are we "routing", which is an IP term? I understand there are legacy
> protocols such as appletalk etc which have to be supported.
> In their native form they work just fine today over Linux.
> If you want to wrap them in a VLAN, how is my proposal stopping you?
Most protocols that run over an ethernet interface, may want to run over a
VLAN interface. So, if we can make VLAN look *just* like an ethernet device
to them, the beauty is that we don't actually have to know anything about
them, they just magically work. To me, that is much more appealing than
tweaking every protocol to teach it how to bind to a VLAN.
>
> > Oh, and when we get bridging working, will your implementation allow us
> > to add VLANs to PPP (bridging ethernet) devices? That is something we
> > may want out of whatever VLAN implementation survives...
>
> Why dont you take up the challenge and write up an RFC? Its not about
> what "survives"; its about what a good solution is. "Survival" with
I figure someone already knows how to bridge stuff over a PPP link. Maybe
RFC 1490 or something? It's been done for ages with FrameRelay. To bridge
ethernet shouldn't be too hard, and if VLANs are net_devices, it shouldn't
be any harder to bridge them too.
As for the comments on survival. It's obvious that what is obvious and good
to both of us is not the same thing. So I think survival is a valid term!
--
Ben Greear (greearb@xxxxxxxxxxxxxxx) http://www.candelatech.com
Author of ScryMUD: scry.wanfear.com 4444 (Released under GPL)
http://scry.wanfear.com http://scry.wanfear.com/~greear
|