<div dir="ltr"><div dir="ltr">After some further testing, the whole hypervisor with unrelated VMs becomes unresponsive.</div><div>OVS is running inside a Debian Stretch VM, not on the hypervisor.</div><div>As soon as I add these rules, the packetloss to the server reaches about 40% - even from hosts that have nothing to do with this bridge:</div><div><br></div><div># ovs-ofctl del-flows br0<br># ovs-ofctl add-flow br0 priority=1,action=LOCAL<br># ovs-ofctl add-flow br0 priority=2,in_port=LOCAL,action=NORMAL<br></div><div><br></div><div>Any ideas?</div><div><br></div><div>Kind regards</div><div>Kevin</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 14. Mai 2019 um 09:15 Uhr schrieb Kevin Olbrich &lt;<a href="mailto:ko@sv01.de">ko@sv01.de</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Seems like it works :-)</div><div>I used the wrong id for the in_port directive and did not know there is an action=LOCAL.</div><div>Just get started to learn OVS.</div><div><br></div><div>The mesh network needs to settle down a bit but it looks like it works!</div><div><br></div><div>Thank you very much!</div><div><br></div><div>Kind regards<br>Kevin<br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 14. Mai 2019 um 08:53 Uhr schrieb Kevin Olbrich &lt;<a href="mailto:ko@sv01.de" target="_blank">ko@sv01.de</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Ok, there already is &quot;br0&quot; as int interface, didn&#39;t read correctly.</div><div>Your command is missing some pieces, can you check again?</div><div><br></div><div>Kind regards</div><div>Kevin</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 14. Mai 2019 um 08:32 Uhr schrieb Kevin Olbrich &lt;<a href="mailto:ko@sv01.de" target="_blank">ko@sv01.de</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Matthias,</div><div dir="ltr"><br></div><div>do I need to create an &quot;int&quot; port for this?</div><div>Currently I bind an IP directly to br0.</div><div><br></div><div>Thank you!</div><div><br></div><div>Kind regards</div><div>Kevin</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 14. Mai 2019 um 08:00 Uhr schrieb Matthias May via discuss &lt;<a href="mailto:ovs-discuss@openvswitch.org" target="_blank">ovs-discuss@openvswitch.org</a>&gt;:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 14/05/2019 07:26, Kevin Olbrich wrote:<br>
&gt; Hi!<br>
&gt; <br>
&gt; I&#39;ve got an OVS that has a bridge &quot;br0&quot; and has about 100x L2TP tunnels.<br>
&gt; These tunnels run batman-adv, a mesh protocol for L2 routing over L3.<br>
&gt; <br>
&gt; For efficient routing, only nodes that are in the same building are allowed<br>
&gt; to see each other.<br>
&gt; To filter out traffic between the ports, I used ebtables: ebtables -A<br>
&gt; FORWARD --logical-in br0 -j DROP<br>
&gt; <br>
&gt; This allows traffic from the node to the server hosting the bridge and<br>
&gt; reverse but not between the ports.<br>
&gt; As OVS does not work with ebtables, all nodes now see each other over L2TP,<br>
&gt; resulting in all nodes meshing with each other (without any benefit).<br>
&gt; <br>
&gt; How can I implement something like &quot;ebtables -A FORWARD --logical-in br0 -j<br>
&gt; DROP&quot; with OVS?<br>
&gt; I tried &quot;ovs-ofctl mod-port ovsbr-de01-mesh &quot;$INTERFACE&quot; no-forward&quot; but<br>
&gt; that also stopped traffic to the host port (by host port, I mean an IP<br>
&gt; directly on br0).<br>
&gt; <br>
&gt; How can I do it correctly?<br>
&gt; The client ports of br0 never must communicate with each other, just the<br>
&gt; server hosting the bridge.<br>
&gt; <br>
&gt; Thank you!<br>
&gt; <br>
&gt; Kind regards<br>
&gt; Kevin<br>
&gt; <br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; discuss mailing list<br>
&gt; <a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
&gt; <a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
&gt; <br>
<br>
You could:<br>
* Delete the default NORMAL action (del-flows br0)<br>
* Create a rule with priority=1 action=&lt;your_server_port<br>
* Create a rule with priority=2 in_port=&lt;your_server_port&gt; action=NORMAL<br>
<br>
This should allow frames from the server to be forwarded as usual, and<br>
frames for all other ports only to the server.<br>
<br>
BR<br>
Matthias<br>
_______________________________________________<br>
discuss mailing list<br>
<a href="mailto:discuss@openvswitch.org" target="_blank">discuss@openvswitch.org</a><br>
<a href="https://mail.openvswitch.org/mailman/listinfo/ovs-discuss" rel="noreferrer" target="_blank">https://mail.openvswitch.org/mailman/listinfo/ovs-discuss</a><br>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>