[ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)

Kevin Olbrich ko at sv01.de
Tue May 14 07:49:59 UTC 2019


After some further testing, the whole hypervisor with unrelated VMs becomes
unresponsive.
OVS is running inside a Debian Stretch VM, not on the hypervisor.
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:

# ovs-ofctl del-flows br0
# ovs-ofctl add-flow br0 priority=1,action=LOCAL
# ovs-ofctl add-flow br0 priority=2,in_port=LOCAL,action=NORMAL

Any ideas?

Kind regards
Kevin

Am Di., 14. Mai 2019 um 09:15 Uhr schrieb Kevin Olbrich <ko at sv01.de>:

> Seems like it works :-)
> I used the wrong id for the in_port directive and did not know there is an
> action=LOCAL.
> Just get started to learn OVS.
>
> The mesh network needs to settle down a bit but it looks like it works!
>
> Thank you very much!
>
> Kind regards
> Kevin
>
>
> Am Di., 14. Mai 2019 um 08:53 Uhr schrieb Kevin Olbrich <ko at sv01.de>:
>
>> Ok, there already is "br0" as int interface, didn't read correctly.
>> Your command is missing some pieces, can you check again?
>>
>> Kind regards
>> Kevin
>>
>>
>> Am Di., 14. Mai 2019 um 08:32 Uhr schrieb Kevin Olbrich <ko at sv01.de>:
>>
>>> Hi Matthias,
>>>
>>> do I need to create an "int" port for this?
>>> Currently I bind an IP directly to br0.
>>>
>>> Thank you!
>>>
>>> Kind regards
>>> Kevin
>>>
>>>
>>> Am Di., 14. Mai 2019 um 08:00 Uhr schrieb Matthias May via discuss <
>>> ovs-discuss at openvswitch.org>:
>>>
>>>> On 14/05/2019 07:26, Kevin Olbrich wrote:
>>>> > Hi!
>>>> >
>>>> > I've got an OVS that has a bridge "br0" and has about 100x L2TP
>>>> tunnels.
>>>> > These tunnels run batman-adv, a mesh protocol for L2 routing over L3.
>>>> >
>>>> > For efficient routing, only nodes that are in the same building are
>>>> allowed
>>>> > to see each other.
>>>> > To filter out traffic between the ports, I used ebtables: ebtables -A
>>>> > FORWARD --logical-in br0 -j DROP
>>>> >
>>>> > This allows traffic from the node to the server hosting the bridge and
>>>> > reverse but not between the ports.
>>>> > As OVS does not work with ebtables, all nodes now see each other over
>>>> L2TP,
>>>> > resulting in all nodes meshing with each other (without any benefit).
>>>> >
>>>> > How can I implement something like "ebtables -A FORWARD --logical-in
>>>> br0 -j
>>>> > DROP" with OVS?
>>>> > I tried "ovs-ofctl mod-port ovsbr-de01-mesh "$INTERFACE" no-forward"
>>>> but
>>>> > that also stopped traffic to the host port (by host port, I mean an IP
>>>> > directly on br0).
>>>> >
>>>> > How can I do it correctly?
>>>> > The client ports of br0 never must communicate with each other, just
>>>> the
>>>> > server hosting the bridge.
>>>> >
>>>> > Thank you!
>>>> >
>>>> > Kind regards
>>>> > Kevin
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > discuss mailing list
>>>> > discuss at openvswitch.org
>>>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>>> >
>>>>
>>>> You could:
>>>> * Delete the default NORMAL action (del-flows br0)
>>>> * Create a rule with priority=1 action=<your_server_port
>>>> * Create a rule with priority=2 in_port=<your_server_port> action=NORMAL
>>>>
>>>> This should allow frames from the server to be forwarded as usual, and
>>>> frames for all other ports only to the server.
>>>>
>>>> BR
>>>> Matthias
>>>> _______________________________________________
>>>> discuss mailing list
>>>> discuss at openvswitch.org
>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20190514/d09bfa91/attachment.html>


More information about the discuss mailing list