[Openvpn-devel] Add unknown-unicast flooding to p2mp tap bridge.

Message ID 20190208194018.20325-1-gert@greenie.muc.de
State Changes Requested
Headers show
Series
  • [Openvpn-devel] Add unknown-unicast flooding to p2mp tap bridge.
Related show

Commit Message

Gert Doering Feb. 8, 2019, 7:40 p.m.
Enable flooding of "unknown-unicast" packets from the server to
all connected clients (+tap).

These are packets that are sent to an unknown destination MAC address
and which are not broadcast/multicast packets.  "Normal" switches also
flood these packets, which allows client-to-client MAC learning without
having to have an initial broadcast packet.

Without the patch, the p2mp tap server will only forward such packets
to the tap interface on the host.

This is only active if --client-to-client is configured on the server.

Signed-off-by: Gert Doering <gert@greenie.muc.de>
---
 src/openvpn/multi.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Gert Doering Feb. 8, 2019, 7:45 p.m. | #1
Hi,

On Fri, Feb 08, 2019 at 08:40:18PM +0100, Gert Doering wrote:
> Enable flooding of "unknown-unicast" packets from the server to
> all connected clients (+tap).

Hrmph, this is incomplete.

While it enables flooding of UU-Packets "from client 1 to client 2",
packets coming in from the TAP interface towards an UU MAC will still
be dropped.

"More code paths in multi.c".

But I still like feedback on this patch.  As I said, normal switches
behave like this (UU is flooded, as is broad- and multicast) but it
seems James was afraid of flooding clients with "stuff they do not 
want".

So, we could have an option here.  Options!  We need more options! :-)

gert
Gert Doering Feb. 8, 2019, 7:50 p.m. | #2
Hi,

On Fri, Feb 08, 2019 at 08:45:53PM +0100, Gert Doering wrote:
> On Fri, Feb 08, 2019 at 08:40:18PM +0100, Gert Doering wrote:
> > Enable flooding of "unknown-unicast" packets from the server to
> > all connected clients (+tap).
> 
> Hrmph, this is incomplete.

And broken.

Packets coming in "from TAP" do not trigger MAC learning, so if you
ping "from client 1" to "out the tap", every single ping packet 
client 1 -> tap will trigger an

Fri Feb  8 20:47:39 2019 us=707460 freebsd-82-amd64/2001:608:0:814::f000:2 MULTI: unknown unicast destination [00:bd:50:58:45:00], flood

... we do have a trac ticket regarding MAC learning and TAP interface,
so it seems I need to revisit this...

"Now I see why our code does not do UU flooding".

gert

Patch

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 55c167b..aa5ae26 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2689,6 +2689,13 @@  multi_process_incoming_link(struct multi_context *m, struct multi_instance *inst
                                     }
                                     c->c2.to_tun.len = 0;
                                 }
+				else
+				{
+                                    /* flood "unknown unicast" packets */
+                                    msg(D_MULTI_LOW, "MULTI: unknown unicast destination [%s], flood",
+                                        mroute_addr_print(&src, &gc));
+                                    multi_bcast(m, &c->c2.to_tun, m->pending, NULL);
+				}
                             }
                         }
 #ifdef ENABLE_PF