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

David Lamparter equinox at opensourcerouting.org
Thu May 2 15:00:02 BST 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: Digital signature
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130502/a4f07269/attachment-0001.sig>


More information about the Quagga-dev mailing list