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

Adrian Ban bluelightning at mantech.ro
Thu May 2 09:22:55 BST 2013

Hi Joachim,

Indeed in the old version of VLAN configuration Linux uses IOCTL. Check 
the vconfig tool which is obsolete.
New netlink/rtnetlink protocol in Linux is completely different.

Starting from here the Linux part will use netlink/rtnetlink 
communication to add/remove VLAN interfaces which must set the name of 
the new interface and set the physical interface in the netlink message. 
So the checking for interface in format (.*).[0-9]* and get the physical 
from there.
I don't think that is a drawback on embedded systems because inside the 
Linux kernel doesn't matter if the interface is called vlanY or ethX.Y. 
The interface index is getting by searching the interface name.

In Quagga this part will be done only once o initialization of interface 
or when you enter the "encapsulation dot1q" command. The rest is done by 

But last night I got another idea how to specify the physical interface.
Instead using "binding physical interface" command I'm thinking to 
extend a little bit the "encapsulation dot1q" command like this:

encapsulation dot1q <1-4094> physical interface IFNAME

What do you think about this?

Best regards,

On 5/2/2013 3:46 AM, Joachim Nilsson wrote:
> Hi,
> this is very intriguing work. Thanks for taking the time to work on it!
> I too would very much like to do more interface setup with Zebra.
> Currently for VLAN interfaces in Linux we¹ change the default name
> space from "eth0.5" to "vlan5" using the SIOCSIFVLAN ioctl. Some
> documentation, as of Linux 3.9.0, is available in
>     http://lxr.linux.no/#linux+v3.9/include/uapi/linux/if_vlan.h
> Changing the kernel name space is faster than renaming the interface,
> which is very important on embedded devices at startup with a lot of
> VLAN interfaces. We did some profiling on it and found that
> was the way to go for us, abstracting away the base interfaces that
> we use to connect to a hardware Layer-2 switch core. (Yes, you do
> lose the visibility of the base interface name, but sometimes that is
> what you want.)
> I'm rambling, but some may hopefully see this as useful. Anyway,
> the code we use is this:
>    struct vlan_ioctl_args ifr;
>    DBG("Changing kernel default namespace from eth0.5 to vlan5 for 
> VLAN interfaces.");
>    ifr.cmd = SET_VLAN_NAME_TYPE_CMD;
>    /* System default is VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD => eth0.5
>     * We want it to be  VLAN_NAME_TYPE_PLUS_VID_NO_PAD     => vlan5   
> --Jocke */
>    ifr.u.name_type = VLAN_NAME_TYPE_PLUS_VID_NO_PAD;
>    result = ioctl (sd, SIOCSIFVLAN, &ifr);
>    if (result)
>    {
>       PERROR("Failed changing kernel default namespace for VLANs.");
>    }
> Dunno if this helps you in any way, but a setting to change the OS
> name space in zebra.conf would be neat to have, and may resolve
> some of the cross-OS problems you might run into.  E.g., with such
> a setting, having different defaults per OS would be OK?
> Regards
>  /Joachim
> ¹) I work at Westermo R&D
> On 05/02/2013 01:30 AM, Adrian Ban wrote:
>> I've checked the sources of ifconfig of NetBSD. Also I've made a 
>> source code for creation of a new interface and VLAN in NetBSD.
>> Indeed the naming in the NetBSD of the interfaces are limited to this 
>> list:
>> agr bridge vlan stf gif gre tap tun strip sl pppoe ppp lo
>> From my point of view is a drawback for this OS because it doesn't 
>> permit to set a custom name for the interface. Fortunately we can 
>> create a lot of vlans name which they shouldn't match the ID of the 
>> real VLAN :).
>> Starting from this point I can tell that I can do the "encapsulation 
>> dot1q" command for both Linux and BSD OSes with the additional 
>> command "binding physical interface" command.
>> I will split the code in two logical parts:
>> 1. Linux part using interface naming: eth0.123 which the "binding 
>> physical interface" command will be optional and will overwrite the 
>> physical interface token from interface name.
>> 2. Linux and BSD OSes using specific names and force to use "binding 
>> physical interface" command and obvious will skip the part that is 
>> taking the physical interface from interface name.
>> For Solaris instead I don't know anything for the moment in source 
>> coding of VLANs. From what I saw is using dladm and ipadm to create 
>> vlans and here in this document
>> http://docs.oracle.com/cd/E23824_01/html/821-1458/fpjve.html
>> they tell that the:
>> vlan-link
>>     Specifies the name of the VLAN, which can also be an
>>     administratively-chosen name.
>> But until I will install a Solaris OS on a VM and take a look into 
>> the dladm sources I can't say anything.
>> Also I think that a Port-Channel should be welcome from a first look 
>> in the sources code.
>> It's good in this way? Any suggestions? :)
>> Best regards,
>> Adrian
>> On 5/1/2013 4:06 PM, Adrian Ban wrote:
>>> Thanks for the info.
>>> I saw that the ifconfig is the main target for BSD.
>>> The naming of the subinterface can be reconfigured as well. Only the 
>>> problem remains if we can't create a custom name interface in BSD I 
>>> should add a new command like:
>>> binding physical interface tlp0
>>> encapsulation dot1q 6
>>> This is a solution which can work on both OS Linux and BSD also. In 
>>> Linux if the first command is given will not do the sanity check for 
>>> interface name, just check if the interface name is free in system, 
>>> check the if the VLAN id is not already on the physical interface 
>>> and create the VLAN.
>>> If is not given will do sanity check, extract the physical 
>>> interface, check the VLAN on that physical interface and create the 
>>> VLAN.
>>> In BSD is the first command is not given the "encapsulation dot1q 6" 
>>> will return an error something like this:
>>> %% no physical interface binding. Please configure "binding physical 
>>> interface" subcommand.
>>> Any suggestions are welcome :).
>>> Best regards,
>>> Adrian
>>> After I'm finish the Linux part I will install a BSD based OS on a 
>>> VM and change the VLAN configuration for it.
>>> About Solaris .. hope I will find some "ifconfig" parts there too or 
>>> the tool which is creating the VLANs.
>>> On 5/1/2013 3:50 PM, Greg Troxel wrote:
>>>> Adrian Ban <bluelightning at mantech.ro> writes:
>>>>> I don't know if the BSD supports creating the VLAN via kernel 
>>>>> netlink,
>>>>> not 100% sure. Maybe somebody with more experience in BSD programming
>>>>> can give me a hint.
>>>> netlink is a Linux-only interface.  BSD systems use the routing socket
>>>> for learning about things and ioctl for configuring.
>>>>> For example in this document:
>>>>> http://www.openbsd.org/cgi-bin/man.cgi?query=vlan&sektion=4 seems 
>>>>> that
>>>>> the creating of vlan is done via IOCTL.
>>>>> What I'm trying to implement is with netlink/rtnellink socket in 
>>>>> Linux
>>>>> kernel for beginning. If everything is fine I will document how to do
>>>>> the same think on the BSD.
>>>> Sure, stepwise implementation is ok.  But you will be defining
>>>> interfaces that will later have to be implemented on multiple systems,
>>>> and it's important to get them right the first time. Otherwise 
>>>> behavior
>>>> may end up changing to accomodate portability, which is awkward.
>>>> Because of that, I would be not in favor of merging vlan patches until
>>>> at least Linux and BSD are supported.  (And perhaps *solaris; I'm not
>>>> clear on how they configure vlans.)
>>>> The sources for ifconfig(8) on *BSD will be pretty straightforward;
>>>> that is basically a command-line wrapper around the ioctls.
>>>> The basic paradigm is
>>>>             ifconfig vlan0 create
>>>>             ifconfig vlan0 vlan 6 vlanif tlp0
>>>> to create a vlan interface and associate it with a particular id on a
>>>> parent (physical) interface.  After that it can be treated as any 
>>>> other
>>>> interface.
>>>> It sounds like the Linux naming scheme may be different, and how to
>>>> reconcile all this is important to get right before implementing.
>>>>> I want to do this because by default Quagga is a routing software so
>>>>> this can be interpreted like "a routing box" not "a switching box" 
>>>>> and
>>>>> the "encapsulation dot1q" is available only in Cisco routes.
>>>> Understood that at least people would like this.
>>> _______________________________________________
>>> Quagga-dev mailing list
>>> Quagga-dev at lists.quagga.net
>>> http://lists.quagga.net/mailman/listinfo/quagga-dev
>> _______________________________________________
>> Quagga-dev mailing list
>> Quagga-dev at lists.quagga.net
>> http://lists.quagga.net/mailman/listinfo/quagga-dev
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev at lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev

More information about the Quagga-dev mailing list