Re: [ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)
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 : > 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 : > >> 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 : >> >>> 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@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 > disc...@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=>>> * Create a rule with priority=2 in_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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)
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 : > 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 : > >> 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@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 >>> > disc...@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=>> * Create a rule with priority=2 in_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 >>> disc...@openvswitch.org >>> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >>> >> ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)
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 : > 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@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 >> > disc...@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=> * Create a rule with priority=2 in_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 >> disc...@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss >> > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)
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@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 > > disc...@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= * Create a rule with priority=2 in_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 > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Only allow traffic between the bridge port and OVS (not other ports)
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 > disc...@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= 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 disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
