Re: [Bridge] [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE

On Mon, Aug 21, 2017 at 10:15 AM, David Lamparter wrote: > Hi all, > > > this is an update on the earlier "[RFC net-next] VPLS support". Note > I've changed the subject lines on some of the patches to better reflect > what they really do (tbh the earlier subject lines were

Re: [Bridge] [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE

On Mon, Aug 21, 2017 at 05:01:51PM -0700, Stephen Hemminger wrote: > On Mon, 21 Aug 2017 19:15:17 +0200 David Lamparter wrote: > > > P.S.: For a little context on the bridge FDB changes - I'm hoping to > > > find some time to extend this to the MDB to allow aggregating dst > >

Re: [Bridge] [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE

On Mon, 21 Aug 2017 19:15:17 +0200 David Lamparter wrote: > Hi all, > > > this is an update on the earlier "[RFC net-next] VPLS support". Note > I've changed the subject lines on some of the patches to better reflect > what they really do (tbh the earlier subject lines

[Bridge] [PATCH 5/6] mpls: add VPLS entry points

This wires up the neccessary calls for VPLS into the MPLS forwarding pieces. Since CONFIG_MPLS_VPLS doesn't exist yet in Kconfig, it'll never be enabled, so we're on the stubs for now. [TODO: maybe rename VPLS_FLAGS to MPLS_FLAGS and use it for non-pseudowire OAM bits too (e.g. enabling G-ACh or

[Bridge] [PATCH 4/6] mpls: split forwarding path on rx/tx boundary

This makes mpls_rt_xmit() available for use in upcoming VPLS code. Same for mpls_route_input_rcu(). Signed-off-by: David Lamparter --- net/mpls/af_mpls.c | 48 ++-- net/mpls/internal.h | 4 2 files changed, 34

[Bridge] [PATCH 3/6] gretap: support lwtunnel under bridge (NVGRE)

This enables using an IPv4 multicast destination for gretap and enables learning unicast destinations through the bridge fdb. Alternatively, a zero destination can be used together with manual entry creation via netlink. This is essentially basic NVGRE support, if the GRE key is configured

[Bridge] [PATCH 2/6] bridge: lwtunnel netlink interface

This makes each FDB entry's metadata dst accessible through the same ENCAP uapi as lwtunnel uses. The function signature is slightly different due to metadata_dst <> lwtunnel_state. Netlink encapsulation is done by callbacks in net_device_ops. This is because the metadata is always used in the

[Bridge] [PATCH 1/6] bridge: lwtunnel support in FDB

This implements holding tunnel config in the form of metadata_dst information in the bridge layer, though only for unicast right now. Multicast is still left to design and implement. While struct lwtunnel_state might seem the more appropriate structure to use here, there are two problems with

[Bridge] [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE

Hi all, this is an update on the earlier "[RFC net-next] VPLS support". Note I've changed the subject lines on some of the patches to better reflect what they really do (tbh the earlier subject lines were crap.) As previously, iproute2 / FRR patches are at: -