Bug 2041859
| Summary: | Failed to limit traffic to VM with ovs firewall qos | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Alex Katz <akatz> | ||||
| Component: | openstack-neutron | Assignee: | Slawek Kaplonski <skaplons> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Eran Kuris <ekuris> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 16.2 (Train) | CC: | apevec, ccamposr, chrisw, i.maximets, mtomaska, ralonsoh, scohen, skaplons | ||||
| Target Milestone: | z3 | Keywords: | Triaged | ||||
| Target Release: | 16.2 (Train on RHEL 8.4) | Flags: | skaplons:
needinfo-
|
||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2023-07-24 09:36:56 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 2138339 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
In the description I've provided wrong versions for some packages. Below are the correct ones: network-scripts-openvswitch2.15-0:2.15.0-38.el8fdp.x86_64 openvswitch-selinux-extra-policy-0:1.0-28.el8fdp.noarch openvswitch2.15-0:2.15.0-38.el8fdp.x86_64 rhosp-network-scripts-openvswitch-0:2.15-4.el8ost.1.noarch rhosp-openvswitch-0:2.15-4.el8ost.1.noarch Is there an OpenFlow rule with the "set_queue:0" action? As per the documentation, it is required for QoS to work: https://docs.openvswitch.org/en/latest/faq/qos/ If there is such rule, do packets actually hit it? Created attachment 1851559 [details]
openflow rules
There is no such rule in the output of the `ovs-ofctl dump-flows br-int` (please see the attached file). Do you mean that such a rule should be created in addition to the QoS policy and Queue?
(In reply to Alex Katz from comment #3) > Created attachment 1851559 [details] > openflow rules > > There is no such rule in the output of the `ovs-ofctl dump-flows br-int` > (please see the attached file). Do you mean that such a rule should be > created in addition to the QoS policy and Queue? Yes. You need to create it. See the following part in the FAQ: """ At this point, bridge br0 is configured with the ports and eth0 is configured with the queues that you need for QoS, but nothing is actually directing packets from vif1.0 or vif2.0 to the queues that we have set up for them. That means that all of the packets to eth0 are going to the “default queue”, which is not what we want. """ If you don't want to modify OpenFlow rules, you may configure ingress policing for a VM port instead: https://docs.openvswitch.org/en/latest/howto/qos/ It's a per-port configuration that doesn't require change of OF rules. Ingress policing is working in the opposite direction as far as I understand. We have it enabled for the outgoing traffic (from VM to some resource outside) and it actually enforced with no problems. The issue we are facing here is that we can't limit the traffic towards the VM. Looks like neutron creates the OVS resources (such as QoS policy and Queue) but doesn't set the correct OpenFlow rule. Git it. DPDK ports with userspace datapath also have support for egress policing, but kernel datapath does not. So, the usual OpenFlow QoS seems to be your only option for this scenario. Hence, you need to find out why neutron doesn't configure it correctly. Thanks for the explanation. I'm moving the bug to openstack-neutron for now. *** Bug 2143487 has been marked as a duplicate of this bug. *** |
Description of problem: Inbound traffic (from some external node to the VM) is not limited. Iperf shows that the throughput is identical with and without QoS is applied to the port. The configuration looks correct. # ovs-vsctl show Bridge br-int ... Port tap78734793-0c tag: 86 Interface tap78734793-0c ... # ovs-vsctl list Port ... _uuid : c03625d5-6382-4829-bfd5-b5ed8e874273 bond_active_slave : [] bond_downdelay : 0 bond_fake_iface : false bond_mode : [] bond_updelay : 0 cvlans : [] external_ids : {} fake_bridge : false interfaces : [45cbb7e8-3b3d-46eb-8697-ee523bf28745] lacp : [] mac : [] name : tap78734793-0c other_config : {net_uuid="f88dc882-1475-4a92-a70c-9310c739b19a", network_type=vxlan, physical_network=None, segmentation_id="3", tag="86"} protected : false qos : 080f5c48-5922-440b-92fc-57b29419a2d7 rstp_statistics : {} rstp_status : {} statistics : {} status : {} tag : 86 trunks : [] vlan_mode : [] ... # ovs-vsctl list Queue _uuid : 42ed87c0-faef-49c3-95bf-5d815cc0c9d5 dscp : [] external_ids : {id=tap78734793-0c, queue_type="0"} other_config : {burst="2400000", max-rate="3000000"} # ovs-vsctl list QoS _uuid : 080f5c48-5922-440b-92fc-57b29419a2d7 external_ids : {id=tap78734793-0c} other_config : {max-rate="3000000"} queues : {0=42ed87c0-faef-49c3-95bf-5d815cc0c9d5} type : linux-htb Version-Release number of selected component (if applicable): network-scripts-openvswitch2.15-0:2.15.0-38.el8fdp.x86_64 openvswitch-selinux-extra-policy-0:1.0-28.el8fdp.noarch openvswitch2.15-0:2.15.0-38.el8fdp.x86_64 rhosp-network-scripts-openvswitch-0:2.15-5.el8ost.noarch rhosp-openvswitch-0:2.15-5.el8ost.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: