[Xorp-hackers] Some thoughts

Mark Handley M.Handley@cs.ucl.ac.uk
Tue, 8 Nov 2005 00:19:11 +0000


On 11/7/05, Hasso Tepper <hasso@linux.ee> wrote:
> OK. So basically this means that if someone (I'm not saying that this
> "someone" will be me, but it might happen ;) will implement vlans in
> linux, configuration will look like something like this?:
>
> interfaces {
>     interface eth0 {
>         vif eth0 {
>         }
>         vif eth0.1 {
>         }
>     }
> }
>
> In *BSD systems this will be something like this:
>
> interfaces {
>     interface fxp0 {
>         vif fxp0 {
>         }
>         vif vlan0 {
>         }
>     }
> }

That's certainly what I was thinking, yes.

> Several small problems/questions:
>
> * BSD's need command to configure vlan tag, in Linux it's already there
>   in vlan name. Mandate command to Linux scheme as well? Maybe it's even
>   good idea to show that it's vlan? ("vlan-id <tag>" command in Junos)

The config should probably have an a vif-type attribute to identify
that this is a tagged VLAN, just to make everything explicit.  And
then an attribute to indicate the tag.  I'm not sure of the precise
syntax, but perhaps:

interfaces {
     interface fxp0 {
         vif fxp0 {
         }
         vif vlan0 {
            type vlan {
               tag: 0
            }
         }
     }
 }

That's a little verbose, but it would avoid namespace clashes with
other vif types such as ATM VCs or various forms of tunnels.  Done
right, you might be able to default the setting of these parameters on
some OSes, so you don't need to type superflous stuff when the FEA can
infer that it's a VLAN and that it has a tag of 0.

> * In BSD's vlans on different interfaces must not conflict, no problem
>   in Linux.

Yes, you'd need some way to prevent commit-time errors.  Not sure what
that would be.

> * Additional command in interface node to show that vif's (except
>   default) will be vlans (vlan-tagging in Junos)?

I'm not quite sure what you mean by this.  Is this what I already
wrote above, or were you talking about operational mode ocommands?

Cheers,
Mark