When a Port is deleted, the QoS extension will reset any rule (QoS
and Queue registers) applied on this port or will reset the
related Interface policing parameters.
If the Port and the related Interface are deleted during the QoS
extension operation, those commands will fail. This patch makes those
operations more resiliant by not checking the errors when writing on
the Port or the Interface register.
NOTE: this patch is squashed with [1]. That will fix the problem
with empty "vsctl" transactions when using this OVS DB implementation.
[1]https://review.opendev.org/#/c/738574/
Change-Id: I2cc4cdf5be25fab6adbc64acabb3fffebb693fa6
Closes-Bug: #1884512
(cherry picked from commit e2d1c2869a)
(cherry picked from commit 84ac8cf9ff)
(cherry picked from commit 3785868bfb)
(cherry picked from commit 7edfb0ef4a)
Neutron-ovs-agent can now enable IGMP snooping in integration bridge
if config option "igmp_snooping_enable" in OVS section in config will
be set to True.
It will also set mcast-snooping-disable-flood-unregistered=true
so flooding of multicast packets to all unregistered ports will be
disabled also.
Both changes are applied on integration bridge.
Change-Id: I12f4030a35d10d1715d3b4bfb3ed5efb9aa28f2b
Closes-Bug: #1840136
(cherry picked from commit 5b341150e2)
skb mark is not supported when using ovs hw-offload and using it
breaks the vxlan offload.
This patch clear skb mark only if ovs hw-offload is disabled.
This should be fine as ovs with hw-offload runs on the
compute node (DVR is not supported), so clear the skb mark for
the qrouter is not needed.
Closes-Bug: #1855888
Conflicts:
neutron/agent/common/ovs_lib.py
Change-Id: I71f45fcd9b7e7bdacaafc7fa96c775e88333ab48
(cherry picked from commit a75ec08ddb)
(cherry picked from commit bee5059ccb)
Looks like by default OVS tunnels inherit skb marks from
tunneled packets. As a result Neutron IPTables marks set in
qrouter namespace are inherited by VXLAN encapsulating packets.
These marks may conflict with marks used by underlying networking
(like Calico) and lead to VXLAN tunneled packets being dropped.
This patch ensures that skb marks are cleared by OVS before entering
a tunnel to avoid conflicts with IPTables rules in default namespace.
Closes-Bug: #1839252
Change-Id: Id029be51bffe4188dd7f2155db16b21d19da1698
(cherry picked from commit 7627735252)
This parameter applies to the OVSDB Controller table when the
native openflow driver is used. There are reports that increasing
it can reduce errors on busy systems. This patch also sets the
default value to 10s which is more than the OVS default of 5s.
See the ovs-vswitchd.conf.db man page for full description.
Conflicts:
neutron/tests/functional/agent/common/test_ovs_lib.py
Change-Id: If0d42919412dac75deb4d7f484c42cea630fbc59
Partial-Bug: #1817022
(cherry picked from commit 540d00f68e)
(cherry picked from commit 6e661ecd2d)
In the OVS agent, when setting up the ancillary bridges, the parameter
external_id:bridge-id is retrieved. If this parameter is not defined
(e.g.: manually created bridges), ovsdbapp writes an error in the logs.
This information is irrelevant and can cause confusion during debugging time.
Change-Id: Ic85db65f651eb67fcb56b937ebe5850ec1e8f29f
Closes-Bug: #1815912
(cherry picked from commit 769e971293)
In one specific compute node, the security group rules
can be enormous quantity. This patch adds a step-by-step
processing method to deal with the large number of the
security group rules. And also changes or adds some LOG.
Related-Bug: #1813703
Related-Bug: #1813704
Related-Bug: #1813707
Conflicts:
neutron/common/constants.py
Change-Id: I57bf27ec75cf848271c5a28b22beee12b8bd5faa
(cherry picked from commit 6ac420df7e)
The native OVS/ofctl controllers talk to the bridges using a
datapath-id, instead of the bridge name. The datapath ID is
auto-generated based on the MAC address of the bridge's NIC.
In the case where bridges are on VLAN interfaces, they would
have the same MACs, therefore the same datapath-id, causing
flows for one physical bridge to be programmed on each other.
The datapath-id is a 64-bit field, with lower 48 bits being
the MAC. We set the upper 12 unused bits to identify each
unique physical bridge
This could also be fixed manually using ovs-vsctl set, but
it might be beneficial to automate this in the code.
ovs-vsctl set bridge <mybr> other-config:datapath-id=<datapathid>
You can change this yourself using above command.
You can view/verify current datapath-id via
ovs-vsctl get Bridge br-vlan datapath-id
"00006ea5a4b38a4a"
(please note that other-config is needed in the set, but not get)
Closes-Bug: #1697243
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I575ddf0a66e2cfe745af3874728809cf54e37745
(cherry picked from commit 379a9faf62)
By default number of MAC addresses which ovs stores in memory
is quite low - 2048.
Any eviction of a MAC learning table entry triggers revalidation.
Such revalidation is very costly so it cause high CPU usage by
ovs-vswitchd process.
To workaround this problem, higher value of mac-table-size
option can be set for bridge. Then this revalidation will happen
less often and CPU usage will be lower.
This patch adds config option for neutron-openvswitch-agent to allow
users tune this setting in bridges managed by agent.
By default this value is set to 50000 which should be enough for most
systems.
Change-Id: If628f52d75c2b5fec87ad61e0219b3286423468c
Closes-Bug: #1775797
Python 3 is not able to type int from string but max_bw_in_bytes is a
string in float format. This patch types first to float and then to int,
hence no ValueError is raised.
Change-Id: I7a527a58f79c1451d8593330d433f620cb0a4107
Closes-bug: #1771409
Agent OVS interface code adds ports without a vlan tag,
if neutron-openvswitch-agent fails to set the tag, or takes
too long, the port will be a trunk port, receiving
traffic from the external network or any other port
sending traffic on br-int.
Also, those kinds of ports are triggering a code path
on the ovs-vswitchd revalidator thread which can eventually
hog the CPU of the host (that's a bug under investigation [1])
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1558336
Co-Authored-By: Slawek Kaplonski <skaplons@redhat.com>
Change-Id: I024bbbdf7059835b2f23c264b48478c71633a43c
Closes-Bug: 1767422
This change add support for OpenFlow 1.5 for
OVSBridge.use_at_least_protocol().
This will allow, in particular, the use of bucket_id in
Id8f5318746cdee507beb112ba69800a43c7f6f20 .
Change-Id: If8f2374e1bff42ff4b1030bbb17e284f31c6ce45
Needed-By: Id8f5318746cdee507beb112ba69800a43c7f6f20
Sometimes ports can have a lot of security group rules. Adding OpenFlow
rules to the integration bridge can be a bottle neck when bundle option
is not used.
As OVS firewall currently uses CLI interface, the bundle support is
implemented only for that. The native interface has on-going work but
before we switch completely to the native, we can benefit from bundle
option now.
e.g. when adding 100 000 flows the bundle option takes the time down
from ~10 seconds to 1 seconds. So it's about 10 times faster.
Change-Id: I1feaeb659c8badf23230e36145235d49d50b6bfb
Adding ability to set DSCP field in OVS tunnels outer header, or
inherit it from the inner header's DSCP value for OVS and linuxbridge.
Change-Id: Ia59753ded73cd23019605668e60cfbc8841e803d
Closes-Bug: #1692951
For OVS based DPDK ports ingress bandwidth limit is now implemented
using egress-policer qos type.
Additionally limit values are set in other_config of QoS because there
is no queue used in this case.
This patch moves also helper methods used to conversion between
bytes and bits and between bits and kilobits to neutron.common.utils
to be able to use it also in ovs_lib module.
Change-Id: I94d1e8dfb82df5c602476db8aaa884ae91fecd7f
Closes-Bug: #1724729
ovsdb maps accept strings as values only. This patch converts integer to
be passed to ovsdb in case vxlan_udp_port config value is used.
Change-Id: Idba77939a80d80a4bc9625d10c8b37b23b91b9c5
Closes-bug: #1742931
According to Open vSwitch FAQ [1], max-rate value which is set for
all queues in qos is set as link speed in case when it is not specified.
This can lead to inaccurate ingress bandwidth limits in case when QoS is
applied e.g. directly on tapXXX port (which is "tun" interface type) and
configured bandwidth limit is higher than interface's link_speed.
This patch set max-rate parameter in qos's other_config table to not use
default value determined by Open vSwitch and to make rate limits more
accurate.
The modification is covered by functional tests in
https://github.com/openstack/neutron/blob/master/neutron/tests/
functional/agent/test_ovs_lib.py.
[1] http://docs.openvswitch.org/en/latest/faq/qos/
Change-Id: Id937216a724fbf776298efd11f74ac71056cfe06
Closes-Bug: #1730605
When we delete vm port with attached QoS policy,
it is just doing nothing if vif_port does not exist.
This is fine for egress bandwidth limit as it is configured
directly on vif_port in OVS.
For ingress bw limit however it uses additional records in
Openvswitch database: qos and queue. Those records are not
cleaned up in such case.
This patch also records port in self.ports in the case of
bandwidth limit rules, just as in the case of dscp rules.
Never execute port clear if vif_port not exists. Finally, ovs
driver can clean such qos and queue records
Change-Id: Iddeb49e1e6538a178ca468df0fdf9e0617ca4f1c
Closes-Bug: #1726732
It's not specific to cli implementation of ovsdb interface.
Also moved the option under [agent] section.
Change-Id: Ic5e38d0c36ae29a9fef23038a9262d14ef1ede90
neutron-lib contains a number of the plugin related constants from
neutron.plugins.common.constants. This patch consumes those constants
from neutron-lib and removes them from neutron. In addition the notion
of the dummy plugin service type is moved strictly into the test
package of neutron since it's not a real service plugin.
NeutronLibImpact
Change-Id: I767c626f3fe6159ab3abd6a7ae3cb9893b79bf66
If port update event is received by L2 agent and there is
no QoS policy assigned to such port, agent tries to delete
any existing QoS rules from port.
For bandwidth limit rules OVS qos driver tries to update
port in OVS database.
In case if port not exists in OVS database agent raised
exception.
This patch fixes that by checking if port really exists and
removing QoS bandwidth limit rules only for existing ports.
Change-Id: I3775ee7b383ada6e4e4ace53b5405aa3c7c22027
Closes-Bug: 1712913
This change moves into ovs_lib the behavior ensuring that
ovs-ofctl is used with the right OF protocol version: the
highest of all versions configured with use_at_least_protocol().
This use_at_least_protocol() method keeps track of the highest
version requested, and also calls add_protocols to ensure that
this version is actually available on the bridge.
This change allows to avoid a wrapping/decorator in networking-sfc
(see I25fb8f35f8236c59a7dca9685a47de0ae77846bc).
For this to be possible another change is needed: if the OF version
that ends up being used is >1.0 then the strip_vlan actions can't
be used without having matched on a vlan_id ; this is achieved
in I76ee34a614237bbc99989ce9c1b96a30456be282 of which this change
is a follow-up.
Change-Id: I16a35b5d6c54901899d24fc94bd3438c1f1be05e
Needed-By: I25fb8f35f8236c59a7dca9685a47de0ae77846bc
Since Pike log messages should not be translated.
This patch removes calls to i18n _LC, _LI, _LE, _LW from
logging logic throughout the code. Translators definition
from neutron._i18n is removed as well.
This patch also removes log translation verification from
ignore directive in tox.ini.
Change-Id: If9aa76fcf121c0e61a7c08088006c5873faee56e
Add support for QoS ingress bandwidth limiting in
openvswitch agent.
It uses default ovs QoS policies on bandwidth limiting
mechanism.
DocImpact: Ingress bandwidth limit in QoS supported by
Openvswitch agent
Change-Id: I9d94e27db5d574b61061689dc99f12f095625ca0
Partial-Bug: #1560961
In some cases we would want to refrain from cleaning up specific
openvswitch ports.
In Octavia, the health manager service is using a predefined[1]
openvswitch port which will gets nuked by the ovs_cleanup script in the
boot process.
That port is created by the operating system NIC configuration file
(by using OVS_EXTRA[2]), but due to the order of actions in the boot
process, the ovs_cleanup script gets invoked by systemd only at a later
stage. As a result the port will be deleted each time and the Octavia
health manager service will fail to bind.
This patch takes advantage of the 'external_ids' column that already
exists for ovs ports, in order to filter out ports we would like to
skip. We filter those ports by adding 'skip_cleanup' to the
'external_ids' column.
It is important to note that this will work if we append the following
to the port: -- set Interface o-hm0 external_ids:skip_cleanup=true"
Related-Bug: #1685223
[1] http://git.openstack.org/cgit/openstack/octavia/tree/devstack/plugin.sh?h=stable/ocata#n190
[2] https://github.com/osrg/openvswitch/blob/master/rhel/README.RHEL#L102
Change-Id: If483d0ee027596999370ab0d21b1743d4ef16acb
n8g-sfc currently has its own variant of OVSBridge to allow the use
of priority in a delete_flows call
This change is meant to make this available outside n8g-sfc and
simplify n8g-sfc code.
This change adds a 'strict' boolean parameter to mod_flow and delete_flows
that results in ovs-ofctl to be run with --strict for del-flows and
mod-flows actions. When strict is set, the use of priority is allowed
and hence not rejected anymore.
Note that for batched actions in a deffered bridge, we disallow mixing
calls with strict and without strict, which can't be translated in one CLI
call.
Needed-By: I3bf939590dd43bff685f133bff86eb7e9068de91
Change-Id: I289d546780f10dc1002ab6bc2e1b38c9ef2d728f
This patch uses the ovsdbapp Python library, which is the new
project based on the Neutron OVSDB API.
The CLI implementation of the OVSDB API remains in the Neutron
tree.
Neutron continues providing the (deprecated) ability to allow
the OVSDB API to be imported from Neutron.
The deleted tests exist in the ovsdbapp project. More will be
moved later, but many of the tests in the Neutron tree use
ovs_lib, which doesn't exist in ovsdbapp so those tests will
probably stay in the Neutron tree.
Closes-Bug: #1684277
Depends-On: I3d3535b1d6fe37c78a9399903b65bbd688b1c4b9
Change-Id: Ic8c7db0e80d0ad104242322d3f1f70cab8caab92
according to https://wiki.openstack.org/wiki/Python3, now we should avoid
using six.iteritems and replace it with dict.items.
Change-Id: I58a399baa2275f280acc0e6d649f81838648ce5c
Closes-Bug: #1680761
If no bridge datapath_id was returned for some
reason (like broken deployment), _get_dpid()
would process further and raise TypeError while
trying to use int conversion on an empty list.
This patch addresses the problem by raising a
RuntimeError if no datapath was found for a
bridge.
Closes-Bug: #1615690
Change-Id: Ie97540793e5d2b14120d3f1bafbf659427c44117
When neutron is deployed with hypervisor is XenServer, current
implementation will grab port's iface-id via xapi, but this isn't
the proper way:
Port's iface-id is already set when creating VM or hot plugging
VIFs in nova project, so there is no need to grab it via xapi
Change-Id: Ie07527cc89ac81ff1e3519db66925cee482f77a4
Closes-Bug: #1649747
Follow up to a comment by kevinbenton on
Idd0531cedda87224531cb8fb6a912ccd0f1554d5 .
The rationale is that one should never call delete a flow
with cookie=ANY_COOKIE and give a cookie_mask at the same time.
Change-Id: I20a03cb04f1bd3eb7a851e5458e2c662cfa3b132
With this change delete_flows will only remove flows matching the default
cookie of the bridge.
The uninstall_flows implementation in the native bridge is also modified
to touch only the flows with the bridge cookie.
To still allow deletion of all cookies, cookie=COOKIE_ANY is introduced
as a special value, and used in the agent code in the places where the
intent is indeed to clean all flows whatever their cookie is.
Partial-Bug: #1557620
Change-Id: Idd0531cedda87224531cb8fb6a912ccd0f1554d5
The OpenFlow spec forbids use of -1 as a flow cookie,
although it is very unlikely that a 64-bit random number equals -1.
Change-Id: I5dcf9709ffcaa5771bb5d9b17efe7d2a42bbe61f
If the vsctl_timeout > OVS's inactivity probe interval and a
transaction execution time exceeds the probe interval, OVS will
disconnect and the transaction will return TRY_AGAIN and most
likely repeat failing until the vsctl_timeout is reached. This
change ensures that the "failsafe" creation of the manager also
sets the inactivity probe to the vsctl_timeout value.
Currently the patch doesn't override the probe_interval on an
existing Manager since it is possible that connection is used by
outside applications and it theoretically should be handled at
deployment.
Related-Bug: #1627106
Change-Id: I76fa0a0cf04a166edf062086fceb2fd90960ad6b
With this change calling delete_flows with no kwargs will (instead
of resulting in calling "ovs-ofctl <action> <bridge> -", which does
nothing with no flow spec given on stdin) result in calling
"ovs-ofctl <action> <bridge>", which will delete all flows.
This aligns the behavior of delete_flows with the behavior currently seen by
all callers for the same method shadowed by the implementations in
OpenFlowSwitchMixin classes.
Change-Id: Ic0449acb3a0d4915ce025300d6f3c507a3cd8e48
Closes-Bug: 1658019
Zuul