[quagga-dev 10507] Re: Adding "encapsulation dot1q" option to interfaces
bluelightning at mantech.ro
Thu May 2 17:01:20 BST 2013
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
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
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
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
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.
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
> - 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
> - 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
> - how will this integrate with the system's assumptions and
> configuration, especially on Linux with its multitude of
> 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.
More information about the Quagga-dev