[quagga-dev 10506] Re: Adding "encapsulation dot1q" option to interfaces

Adrian Ban bluelightning at mantech.ro
Thu May 2 16:59:07 BST 2013


Hi Davin,

I was thinking about those scenario also. I didn't have time to put them 
into an email. I was looking for code for vlans for several OSes.

 From my point of view:

   - what's the delineation on what we do and what we don't do?
     - will zebra actually delete the interface when it terminates?

Could delete the interface if wasn't created before, for example. But can leave the interface in the system as well. I don't see anything bad in this.
But this software is build to stay UP in the system all the time. Only when you reboot the machine should terminates or when you do an upgrade of the software.

     - what if the interface already exists, but has a different parent
       interface or VLAN id?

This is one scenario that I was thinking about. Quagga should recreates the VLAN with the new parent.
Because this software is dedicated to turn on a box into a router we must presume that the administrator KNOWS what is doing.
Also there is possibility to NOT AFFECT anything if "encapsulation dot1q" is NOT enabled on that interface. So you can configure the interface in OS environment and work in Quagga like in previous versions of Quagga. Simple and elegant.
In the moment that you SET this command I presume that YOU know for sure what you want from the system, right?

      - will we handle this dynamically when the parent
       disappears/reappears?

Well from what I saw in the Quagga sources there is a hook for up/down interface. When the physical interface is disappear
the subinterface will do nothing. Will become another pseudo interface. Nothing bad here.
If the physical interface is coming up, well we should check all subinterfaces with that parent and bring it up all.

      - when we do VLANs, will we also do tunnels?  GRE maybe?  What about
       PPP, shouldn't we be able to configure a serial interface in
       zebra?

Like I mention in a previous mail: I will try to add port-channel option. So if the other interfaces can be configured for all OSes why not?

      - how will this integrate with the system's assumptions and
       configuration, especially on Linux with its multitude of
       distributions?

Simple: you don't configure those interfaces into the init scripts. Like 
I said before: if you are doing this means that you KNOW what are you 
doing.

This is how I see the picture.

Best regards,
Adrian

On 5/2/2013 5:00 PM, David Lamparter wrote:
> On Wed, May 01, 2013 at 02:39:17PM +0300, Adrian Ban wrote:
>> I want to try to add the possibility to create VLANs subinterfaces
>> directly from Quagga.
>> The reason is that I hate to do it all the time from the OS with iproute
>> or OS specific init.d scripts. More elegant is to do it from one
>> combined CLI.
> Well...  this is a bit of a can of worms.  Not the worst one, but still
> worms involved.
>
> Right now Quagga has a more or less well defined boundary to the rest of
> the system.  It's 3 parts:
>
> Part 1:  routes.  Quagga claims authority on at least what it installed,
>   and in general it takes some consideration before mucking with the
>   route table, and it's a seriously bad idea if it involves routes that
>   zebra installed.
>
> Part 2:  addressses.  Quagga tries to cooperate here, you can use either
>   the system tools, or zebra, or even both.
>
> Part 3:  interface preparation, link configuration, etc.  This is never
>   handled by zebra until now.  Stuff that falls under this is all
>   creation of interfaces, L2 configuration, and up/down state.
>
> You're suggesting taking one particular item from part 3 - creation of
> VLAN interfaces - and adding code for that.  The issues I see here are
> these:
>    - what's the delineation on what we do and what we don't do?
>      - will zebra actually delete the interface when it terminates?
>      - what if the interface already exists, but has a different parent
>        interface or VLAN id?
>      - will we handle this dynamically when the parent
>        disappears/reappears?
>      - when we do VLANs, will we also do tunnels?  GRE maybe?  What about
>        PPP, shouldn't we be able to configure a serial interface in
>        zebra?
>      - how will this integrate with the system's assumptions and
>        configuration, especially on Linux with its multitude of
>        distributions?
>
> All in all, I believe you need to write an exact specification of what
> you want to do and what not.  In the end the people packaging or using
> Quagga will need to look at it, so it'll need to be written sooner or
> later.  Might as well be sooner, so we can discuss it on here.
>
> Cheers,
>
>
> -David





More information about the Quagga-dev mailing list