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

Sami Halabi sodynet1 at gmail.com
Thu May 2 05:44:42 BST 2013

Indeed awsome job. You should as well check FreeBSD.

On May 2, 2013 3:48 AM, "Joachim Nilsson" <troglobit at gmail.com> 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<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<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<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<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<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<http://lists.quagga.net/mailman/listinfo/quagga-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130502/b7da450f/attachment-0001.html>

More information about the Quagga-dev mailing list