netdev - Re: [PATCH 2/2] drivers: add vpls support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 12 Aug 2017 15:40:07 +0200
From:   Amine Kherbouche <amine.kherbouche@...nd.com>
To:     Roopa Prabhu <roopa@...ulusnetworks.com>,
        David Lamparter <equinox@...c24.net>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] drivers: add vpls support



On 11/08/2017 17:14, Roopa Prabhu wrote:
> On Fri, Aug 11, 2017 at 5:55 AM, David Lamparter <equinox@...c24.net> wrote:
>> On Thu, Aug 10, 2017 at 10:28:37PM +0200, Amine Kherbouche wrote:
>>> This commit introduces the support of VPLS virtual device, that allows
>>> performing  L2VPN multipoint to multipoint communication over MPLS PSN.
>>>
>>> VPLS device encap received ethernet frame over mpls packet and send it the
>>> output device, in the other direction, when receiving the right configured
>>> mpls packet, the matched mpls route calls the handler vpls function,
>>> then pulls out the mpls header and send it back the entry point via
>>> netif_rx().
>>>
>>> Two functions, mpls_entry_encode() and mpls_output_possible() are
>>> exported from mpls/internal.h to be able to use them inside vpls driver.
>>>
>>> Signed-off-by: Amine Kherbouche <amine.kherbouche@...nd.com>
> [snip]
>
>> [...]
>>> +union vpls_nh {
>>> +     struct in6_addr         addr6;
>>> +     struct in_addr          addr;
>>> +};
>>> +
>>> +struct vpls_dst {
>>> +     struct net_device       *dev;
>>> +     union vpls_nh           addr;
>>> +     u32                     label_in, label_out;
>>> +     u32                     id;
>>> +     u16                     vlan_id;
>> I looked at VLAN support and decided against it because the bridge layer
>> can handle this perfectly fine by using the bridge's vlan support to tag
>> a port's pvid.
> yes, agreed. there is no need for vlan here. The bridge can be
> configured with the required vlan
> mapping on the vpls port.
what if the output device cannot handle vlan encapsulation? because on my
example of configuration in the cover letter, I sent the vpls packets over
a simple physical net device (not a bridge nor a vlan port).
>
>
>>> +     u8                      via_table;
>>> +     u8                      flags;
>>> +     u8                      ttl;
>>> +};
>> [...]
>>> +struct vpls_priv {
>>> +     struct net              *encap_net;
>>> +     struct vpls_dst         dst;
>>> +};
>>> +
>>> +static struct nla_policy vpls_policy[IFLA_VPLS_MAX + 1] = {
>>> +     [IFLA_VPLS_ID]          = { .type = NLA_U32 },
>>> +     [IFLA_VPLS_IN_LABEL]    = { .type = NLA_U32 },
>>> +     [IFLA_VPLS_OUT_LABEL]   = { .type = NLA_U32 },
>>> +     [IFLA_VPLS_OIF]         = { .type = NLA_U32 },
>>> +     [IFLA_VPLS_TTL]         = { .type = NLA_U8  },
>>> +     [IFLA_VPLS_VLANID]      = { .type = NLA_U8 },
>>> +     [IFLA_VPLS_NH]          = { .type = NLA_U32 },
>>> +     [IFLA_VPLS_NH6]         = { .len = sizeof(struct in6_addr) },
>>> +};
>> The original patchset was point-to-multipoint in a single netdev, and
>> had some starts on optimized multicast support (which, admittedly, is a
>> bit of a fringe thing, but still.)
>>
> I had been thinking about this as a single netdevice as well...which
> can work with
> the bridge driver using per vlan dst_metadata infra (similar to vxlan
> single device and per vlan - vxlan mapping).
>
> Multiple netdevice with one per vlan-vpls-id will work as well... but
> starting with a single netdev
> will be better (helps with scaling).
That's why I added the vpls id, to have in the future many vpls tunnels with
a single device, so the vpls id let us keep tracking the device working like
the vni of vxlan. (vpls lwtunnels in the TODO list).