From: David Lamparter <equinox@diac24.net> To: Roopa Prabhu <roopa@cumulusnetworks.com> Cc: David Lamparter <equinox@diac24.net>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, bridge@lists.linux-foundation.org, Amine Kherbouche <amine.kherbouche@6wind.com>, "stephen@networkplumber.org" <stephen@networkplumber.org> Subject: Re: [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE Date: Tue, 22 Aug 2017 13:24:51 +0200 [thread overview] Message-ID: <20170822112451.GA773745@eidolon> (raw) In-Reply-To: <CAJieiUiz2EmzeaREa4PAd_=2J_MBWUMVh_4abS2HdtcmK30EBQ@mail.gmail.com> On Mon, Aug 21, 2017 at 09:43:15PM -0700, Roopa Prabhu wrote: > > This is relevant to the discussion because it's a feature which is > > non-obvious (to me) on how to do with the VXLAN model of having an > > entirely separate FDB. Meanwhile, with this architecture, the proof of > > concept / hack is coming in at a measly cost of: > > 8 files changed, 176 insertions(+), 15 deletions(-) > > David, what is special about the vpls igmp/mld snooping code ?...do > you have to snoop vpls attrs ?. It just needs to snoop which tunnel endpoint[s] a multicast group is subscribed on. > in the vxlan model.., the vxlan driver can snoop its own attrs eg > vxlan-id, remote dst etc. > and the pkt is passed up to the bridge where it will hit the normal > bridge igmp/mpld snooping code. > can you pls elaborate ? Yes, that's exactly what the hack I have is doing, it's snooping the driver-specific attrs into a metadata_dst, passing it up to the bridge, which puts the metadata_dst on the MDB entry. What I'm arguing against is duplicating the entire MDB into all of the drivers. The snooping machinery is a pretty complex piece of code which holds information as a cartesian combination of MAC * VLAN * Group. It has several configuration knobs and can even send its own packets. It's complex enough to have been the subject of several CVEs over its history (e.g. CVE-2013-4129, CVE-2013-2636.) > keeping vpls specific code and api in a separate vpls driver allows > for cleanly extending it in the future. That's exactly my point: it's not VPLS specific. It's exactly the same functionality for VXLAN, VPLS, NVGRE and 802.11. The functionality is "remember the tunnel endpoint." It's the same bits as lwtunnel uses, which is why the 2nd patch in this series reuses the existing lwtunnel netlink encapsulation functions. -David
WARNING: multiple messages have this Message-ID (diff)
From: David Lamparter <equinox@diac24.net> To: Roopa Prabhu <roopa@cumulusnetworks.com> Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>, bridge@lists.linux-foundation.org, Amine Kherbouche <amine.kherbouche@6wind.com>, David Lamparter <equinox@diac24.net> Subject: Re: [Bridge] [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE Date: Tue, 22 Aug 2017 13:24:51 +0200 [thread overview] Message-ID: <20170822112451.GA773745@eidolon> (raw) In-Reply-To: <CAJieiUiz2EmzeaREa4PAd_=2J_MBWUMVh_4abS2HdtcmK30EBQ@mail.gmail.com> On Mon, Aug 21, 2017 at 09:43:15PM -0700, Roopa Prabhu wrote: > > This is relevant to the discussion because it's a feature which is > > non-obvious (to me) on how to do with the VXLAN model of having an > > entirely separate FDB. Meanwhile, with this architecture, the proof of > > concept / hack is coming in at a measly cost of: > > 8 files changed, 176 insertions(+), 15 deletions(-) > > David, what is special about the vpls igmp/mld snooping code ?...do > you have to snoop vpls attrs ?. It just needs to snoop which tunnel endpoint[s] a multicast group is subscribed on. > in the vxlan model.., the vxlan driver can snoop its own attrs eg > vxlan-id, remote dst etc. > and the pkt is passed up to the bridge where it will hit the normal > bridge igmp/mpld snooping code. > can you pls elaborate ? Yes, that's exactly what the hack I have is doing, it's snooping the driver-specific attrs into a metadata_dst, passing it up to the bridge, which puts the metadata_dst on the MDB entry. What I'm arguing against is duplicating the entire MDB into all of the drivers. The snooping machinery is a pretty complex piece of code which holds information as a cartesian combination of MAC * VLAN * Group. It has several configuration knobs and can even send its own packets. It's complex enough to have been the subject of several CVEs over its history (e.g. CVE-2013-4129, CVE-2013-2636.) > keeping vpls specific code and api in a separate vpls driver allows > for cleanly extending it in the future. That's exactly my point: it's not VPLS specific. It's exactly the same functionality for VXLAN, VPLS, NVGRE and 802.11. The functionality is "remember the tunnel endpoint." It's the same bits as lwtunnel uses, which is why the 2nd patch in this series reuses the existing lwtunnel netlink encapsulation functions. -David
next prev parent reply other threads:[~2017-08-22 11:24 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-08-21 17:15 [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 1/6] bridge: lwtunnel support in FDB David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 2/6] bridge: lwtunnel netlink interface David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 3/6] gretap: support lwtunnel under bridge (NVGRE) David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 4/6] mpls: split forwarding path on rx/tx boundary David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 5/6] mpls: add VPLS entry points David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-21 17:15 ` [PATCH 6/6] mpls: VPLS support David Lamparter 2017-08-21 17:15 ` [Bridge] " David Lamparter 2017-08-28 9:21 ` Amine Kherbouche 2017-08-28 9:21 ` [Bridge] " Amine Kherbouche 2017-08-22 0:01 ` [RFC net-next v2] bridge lwtunnel, VPLS & NVGRE Stephen Hemminger 2017-08-22 0:01 ` [Bridge] " Stephen Hemminger 2017-08-22 0:29 ` David Lamparter 2017-08-22 0:29 ` [Bridge] " David Lamparter 2017-08-22 11:01 ` Nikolay Aleksandrov 2017-08-22 11:01 ` [Bridge] " Nikolay Aleksandrov 2017-08-22 11:32 ` David Lamparter 2017-08-22 11:32 ` [Bridge] " David Lamparter 2017-08-22 11:55 ` Nikolay Aleksandrov 2017-08-22 11:55 ` [Bridge] " Nikolay Aleksandrov 2017-08-22 12:06 ` David Lamparter 2017-08-22 12:06 ` [Bridge] " David Lamparter 2017-08-22 4:43 ` Roopa Prabhu 2017-08-22 4:43 ` [Bridge] " Roopa Prabhu 2017-08-22 11:24 ` David Lamparter [this message] 2017-08-22 11:24 ` David Lamparter 2017-09-11 8:02 ` Amine Kherbouche 2017-09-11 8:02 ` [Bridge] " Amine Kherbouche 2017-09-19 14:46 ` Amine Kherbouche 2017-09-19 14:46 ` [Bridge] " Amine Kherbouche
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170822112451.GA773745@eidolon \ --to=equinox@diac24.net \ --cc=amine.kherbouche@6wind.com \ --cc=bridge@lists.linux-foundation.org \ --cc=netdev@vger.kernel.org \ --cc=roopa@cumulusnetworks.com \ --cc=stephen@networkplumber.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.