In case when physical bridge is removed and created again it
is initialized by neutron-ovs-agent.
But if agent has enabled distributed routing, dvr related
flows wasn't configured again and that lead to connectivity issues
in case of DVR routers.
This patch fixes it by adding configuration of dvr related flows
if distributed routing is enabled in agent's configuration.
It also adds reset list of phys_brs in dvr_agent. Without that there
were different objects used in ovs agent and dvr_agent classes thus
e.g. 2 various cookie ids were set on flows in physical bridge.
This was also the same issue in case when openvswitch was restarted and
all bridges were reconfigured.
Now in such case there is correctly new cookie_id configured for all
flows.
Change-Id: I710f00f0f542bcf7fa2fc60800797b90f9f77e14
Closes-Bug: #1864822
Do not flood the packets to bridge, since we have the
bridge port list, we can add a simple direct flow to
the right port only.
Closes-Bug: #1732067
Related-Bug: #1841622
Change-Id: I14fefe289a19b718b247bf0740ca9bc47f8903f4
It may happen that subnet is connected to dvr router using IP address
different than subnet's gateway_ip.
So in br-tun arp to dvr router's port should be dropped instead of
dropping arp to subnet's gateway_ip (or mac in case of IPv6).
Change-Id: Ida6b7ae53f3fc76f54e389c5f7131b5a66f533ce
Closes-bug: #1831575
DVR does the ARP table update through the control plane, and does not
allow any ARP requests to get out of the node.
In order to address the allowed address pair VRRP IP issue with DVR,
we need to add an ARP entry into the ARP Responder table for the
allowed address pair IP ( which is taken care by the patch in [1])
This patch adds a rule in the br-int to redirect the packet
destinated to the router to the actual router-port and also moves
the arp filtering rule to the tunnel or the physical port based on the
configuration.
By adding the above rule it allows the ARP requests to reach the
ARP Responder table and filters the ARP requests before it reaches
the physical network or the tunnel.
[1] https://review.opendev.org/#/c/601336/
Related-Bug: #1774459
Change-Id: I3905ea56ca0ff35bdd96c818719e6d63a3eb5a72
Reduces E128 warnings by ~260 to just ~900,
no way we're getting rid of all of them at once (or ever).
Files under neutron/tests still have a ton of E128 warnings.
Change-Id: I9137150ccf129bf443e33428267cd4bc9c323b54
Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change _bind_centralized_snat_port_on_dvr_subnet() to pull
the subnet uuid out of the fixed IP earlier, since that
is all it is passing in its remote RPC call.
Trivialfix
Change-Id: I9686fd619214a3c33af253af5ad69e9f406c7e18
This is a revise for I7b24a159962af7b58c096a1b2766e2169e9f8aed
Br-int's flow tables are already uninstalled in setup_integration_br.
And setup_integration_br will install some default flows. If we still
uninstall flow tables of br-int in setup_dvr_flows_on_integ_br, these
default flow tables will be missing.
Closes-Bug: #1775146
Change-Id: I71c1f9034dfc913b9e9ae17cc8f6bd084c9ee580
On hosts with dvr_snat agent mode, after restarting OVS agent,
sometimes the SNAT port is processed first instead of the distributed port.
The subnet_info is cached locally via get_subnet_for_dvr when either of these ports
are processed. However, it returns the MAC address of the port used to query
as the gateway for the subnet. Using the SNAT port, this puts the wrong
MAC as the gateway, causing some flows such as the DVR flows on br-int
for local src VMs to have the wrong MAC.
This patch fixes the get_subnet_for_dvr with fixed_ips as None for the csnat port,
as that causes the server side handler to fill in the subnet's actual gateway
rather than using the port's MAC.
Change-Id: If045851819fd53c3b9a1506cc52bc1757e6d6851
Closes-Bug: #1783470
Fix W503 (line break before binary operator) pep8 warnings
and no longer ignore new failures.
Trivialfix
Change-Id: I7539f3b7187f2ad40681781f74b6e05a01bac474
Add error handling for get_network_info_for_id rpc call in the
ovs_dvr_neutron_agent.
Closes-Bug: #1758093
Change-Id: I44a5911554c712c89cdc8901cbc7b844c4b0a363
Inter Tenant Traffic between two different networks that belong
to two different Tenants is not possible when connected through
a shared network that are internally connected through DVR
routers.
This issue can be seen in multinode environment where there
is network isolation.
The issue is, we have two different IP for the ports that are
connecting the two routers and DVR does not expose the router
interfaces outside a compute and is blocked by ovs tunnel bridge
rules.
This patch fixes the issue by not applying the DVR specific
rules in the tunnel-bridge to the shared network ports that
are connecting the routers.
Closes-Bug: #1751396
Change-Id: I0717f29209f1354605d2f4128949ddbaefd99629
If a user clears the gateway_ip of a subnet and the OVS
agent is re-started, it will throw an exception trying
to install the DVR IPv4 flow. Do not install the flow
in this case since it is not required.
Change-Id: I79aba63498aa9af1156e37530627fcaec853a740
Closes-bug: #1728665
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
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
DVR flows are not compatible with OVS firewall flows as firewall flows
have higher priority. As a consequence, rules for DVR were never match
as firewall uses output directly.
This patch replaces flows using normal or output actions and resends
packets to TRANSIENT table instead. This transient table then uses
either those normal or output action rules. With this split, we will be
able to match egress/ingress flows in TRANSIENT table instead of
LOCAL_SWITCHING putting DVR pipeline in front of OVS firewall pipeline.
Change-Id: I9f738047f131b42d11a90f539435006d16ea7883
Closes-bug: #1696983
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
With this change the delete_flow variant implementation
of OpenFlowSwitchMixin, which was overriding the parent implementation
from ovs_lib in an incompatible way using the native ryu implementation,
is renamed into uninstall_flows.
As discussed in bug 1628455, the approach consisting in
extending the _keyword dict to convert ovs-ofctl rules into ryu
parameters does not seem practical.
This change also updates calls to delete_flows so that, when
enabled, the native interface will be used. Similar calls outside neutron
repo need to be updated as well, which will be done in separate changes.
Change-Id: I90ff1055d367609694eef975c7d084e4cd7a2cf4
Closes-Bug: 1628455
Needed-By: Idd2315565cc9c88319984d83487148bf498e91ab
csnat_ofport is always OFPORT_INVALID on compute nodes
so the error was always wrong.
Not sure how it could mean duplicate dvr port even on controllers,
so the patch is just removing the condition and the log.
Closes-Bug: #1629816
Change-Id: Ifbb8128fbd932946dab84a73b780da495f2ea1af
String interpolation should be delayed to be handled
by the logging code, rather than being done
at the point of the logging call.
So add a hacking rule for it.
See the oslo i18n guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
Change-Id: I91e8d59d508c594256d5f74514e62f8f928d1df5
Closes-Bug: #1596829
Remove the extra checks in ovs_dvr_neutron_agent that can be done in
ovs_neutron_agent in one place.
Closes-bug: #1558888
Change-Id: I7192e1c0447ea35649672caa771e5a9c6aa2636b
* Add osprofiler wsgi middleware. This middleware is used for 2 things:
1) It checks that person who wants to trace is trusted and knows
secret HMAC key.
2) It starts tracing in case of proper trace headers
and adds first wsgi trace point, with info about HTTP request
* Add initialization of osprofiler at start of service
Currently that includes oslo.messaging notifer instance creation
to send Ceilometer backend notifications.
Neutron client change: Ic11796889075b2a0e589b70398fc4d4ed6f3ef7c
Co-authored-by: Ryan Moats <rmoats@us.ibm.com>
Depends-On: I5102eb46a7a377eca31375a0d64951ba1fdd035d
Closes-Bug: #1335640
DocImpact Add devref and operator documentation on how to use this
APIImpact
Change-Id: I7fa2ad57dc5763ce72cba6945ebcadef2188e8bd
When binding is called in DVR, check to see if the port was
previously wired under a different ofport. If it was, first
unbind the old port and then bind the new one.
Change-Id: I372158c4a6986295e396d849a2c9c5372b271e08
Closes-Bug: #1562467
(cherry picked from commit 4731dbbef1)
When binding is called in DVR, check to see if the port was
previously wired under a different ofport. If it was, first
unbind the old port and then bind the new one.
Change-Id: I372158c4a6986295e396d849a2c9c5372b271e08
Closes-Bug: #1562467
When subnet or gateway port has been deleted concurrently, rpc call
to get_subnet_for_dvr will return an empty dict without any value.
ovs_dvr_neutron_agent should be more gracefull and at least log
warning message in that situation.
Change the existing error log to warning, because it is not a server
error, but a fact that should be noticed.
Change-Id: Icb3a57553a8b0eb635c0d85e2c60e7ce519893f6
Closes-bug: #1454921
Currently agent will fall back to non-dvr mode in case it can't.
However neutron server does not check dvr mode of ovs agents when
scheduling routers. So in a DVR enabled cluster all ovs agents
should run in DVR mode. Otherwise it will lead to undefined
behavior which is hard to debug.
Closes-Bug: #1536110
Change-Id: I6c31aabf1852c688e9c27fc1859d3fdd830caa68
- This does NOT break other projects that rely on neutron.i18n,
as this change includes a debtcollector shim to maintain those
older entry points, until they can migrate.
- Also updates _i18n.py to the latest pattern defined by oslo_i18n
- Guidance and template are from the reference:
http://docs.openstack.org/developer/oslo.i18n/usage.html
Partially-Closes-Bug: #1519493
Change-Id: I1aa3a5fd837d9156da4643a367013c869ed8bf9d
Went through all of the docstrings in Neutron and did
some cleanup. I'm sure there are bunch more that I have missed.
Change-Id: Ib29d2de1c580880c89ed4fd069e1515d0977a3e7
The fix for https://review.openstack.org/#/c/218350/ has few
more occurrences. This patch addresses those and also changes
"local_port" from "port" in order not to confuse the parameter
with method argument.
Change-Id: I60bfeb9e33f0f69153afec083a2c05ee862fcee2
Graceful OVS restart that was intoduced in I95070d8218859d4fff1d572c1792cdf6019dd7ea
missed that flows are also dropped in setup_dvr_flows_on_integ_br.
Related-bug: #1383674
Change-Id: I7b24a159962af7b58c096a1b2766e2169e9f8aed
In DVR routers when a port is added to a router, then
the command succeeds but the l2 ovs agent raises an
error stating that it could not retrieve the gateway
port for the subnet.
The reason for this is there is mismatch in the
ip_address returned from the subnet for the gateway
port and the actual ip_address of the port that we
added to the router.
Since the subnet info was passed to "get_subnet_for_dvr"
this mismatch was seen.
Instead of passing the subnet we will be passing the
actual fixed_ips with all the details and the subnet
gateway port will be filtered based on the ip_address
in the fixed_ips passed.
Closes-Bug: #1404823
Change-Id: I87a3983951f814350e79f5e2274f4639bb6bc0f5
The new get_vifs_by_id function retrieves all of the VIFs
for a port iteration at once to eliminate unnecessary multiple
calls to OVSDB.
Change-Id: If18557faead836121bfa3b4e6efccd0318ce72d3
Related-Bug: #1460233
This commit moves the L2 agents (Linuxbridge and OVS) into the
ML2 directory, while at the same time also moving the ML2 server
bits into toplevel directories. It also moves the configuration
files and unit tests. We also move the l2pop RPC mixin while
here as well.
DocImpact
UpgradeImpact
Partially-Implements: blueprint reference-implementation-split
Partial-Bug: #1468433
Closes-Bug: #1427317
Change-Id: If6feca7b7a6bdd6c3c6feb929fa26fb4b1f72770
Signed-off-by: Kyle Mestery <mestery@mestery.com>
I was looking at the assumption around using fixed_ips[0] in a recent
patch [1]. I thought at the least, the usage of fixed_ips[0] should
be isolated with the comment explaining why it is okay.
I thought that we could also use this patch as an opportunity to vet
the validity of the claim made in the comment.
[1] If4a310da06f9b0076a9f62926a16b574a8c109ce
Change-Id: Iba5713dd7d852429997ff43d98266a9f022d5d86
This is a preparation to introduce another Ryu-based implementation.
The aim is to replace this with the new Ryu-based implementation
eventually.
Add a config option for OVS-agent which selects the implementation.
Currently, the only available choice is 'ovs-ofctl'.
Also, this commit simplifies DVR logics by reducing duplications
and makes some of DVR UTs actually check the flows rather than just
"add_flow is called".
Partially-Implements: blueprint ovs-ofctl-to-python
Change-Id: Ie1224f8a1c17268cd7d1c474ed82fdfb8852eaa8
Use a single LOG.error per message rather than per lines.
Also, print both of old and new subnets.
Change-Id: I162d3d178fec8b84b66fdfd5a037c2d858c47e30
Found via the pylint no-member check.
Co-authored-by: Kevin Benton <blak111@gmail.com>
Closes-Bug: #1423775
Change-Id: Id4104fa783aa8c34917df6d16ff1290882f93af5
DVRAgentRpcApiMixin should be and is currently used on plugin side,
no need to add it to OVSDVRNeutronAgent, it's confusing
Change-Id: If26e0326c22995ab7a1c653150496f54689d75fc
It's mostly a matter of changing imports to a new location.
Non-obvious changes needed:
* pass overwrite= argument to oslo_context since oslo.log reads context
from its thread local store and not local.store from incubator
* don't store context at local.store now that there is no code that
would consume it
* LOG.deprecated() -> versionutils.report_deprecated_feature()
* dropped LOG.audit check from hacking rule since now the method does
not exist
* WritableLogger is now located in oslo_log.loggers
Dropped log module from the tree. Also dropped local module that is now
of no use (and obsolete, as per oslo team).
Added versionutils back to openstack-common.conf since now we use the
module directly from neutron code and not just as a dependency of some
other oslo-incubator module.
Note: tempest tests are expected to be broken now, so instead of fixing
all the oslo.log related issues for the subtree in this patch, I only
added TODOs with directions for later fix.
Closes-Bug: #1425013
Change-Id: I310e059a815377579de6bb2aa204de168e72571e