The tunneling bridge uses different openflow rules depending if the
agent is running in DVR mode or not. With DVR enabled initial rule was
installed that caused traffic coming from the integration bridge to be
flooded to all tunnels. After a few miliseconds this flow was replaced
by a DVR specific flow, correctly dropping the traffic. This small time
window caused a network loop on the compute node with restarted agent.
This patch skips installing the non-dvr specific flow in case OVS agent
is working in DVR mode. Hence the traffic is never flooded to the
tunnels.
Closes-bug: #2028795
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Change-Id: I3ce026054286c8e28ec1500f1a4aa607fe73f337
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
the ones in neutron/plugins.
Trivialfix
Change-Id: Id9138652f5f07ef12fa682e182fe210019e8f975
Invalid OFPORT (-1) causes ofctl errors and timeouts if set
it as output in a flow rule.
Closes-Bug: #1938685
Change-Id: Ib8be66c3068309832e08066af4e0b75c30e8163a
In some scenario, dvr router interface will try to ARP some device
which is not hosted in the same host. When the ARP request send
out, the ethernet source MAC will be changed to dvr_host_mac. Then
thoses devices will reply ARP with the dvr_host_mac in ethernet dest
MAC. So finally the dvr router interface will drop this, and the ARP
get failed.
This patch adds one flow for this, it will match the dest MAC, ARP
op-code=2 and arp_tha address, then change the dest MAC to the right
router interface's MAC address.
Closes-Bug: #1913646
Related-Bug: #1859638
Change-Id: Ibc7f01450a3da026ca5c4fb667dada912cf472e3
Removal of non-gateway port on DVR router deletes all the DVR to
SRC mac flows for the instances of same subnet on that compute node.
The instances are not reachable from any other network.
This patch checks if the DVR router port is gateway for the subnet
or not. And deletes the DVR-SRC mac flows only if it is gateway port.
The DVR-SRC mac flows are deleted if the gateway is not set for the subnet.
Change-Id: Iadc1671c862f8c01e5761e92b82a04849d4bb411
Closes-Bug: #1892405
This change removes the "_check_ofport" function and its use form
the ovs_lib.py file.
By skipping ports without a unique ofport in the "get_vifs_by_ids"
and "get_vifs_by_id" functions, the OVS agent incorrectly treated
newly added port with an ofport of -1 as removed ports in the
"treat_devices_added_or_updated" function.
Co-Authored-By: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I79158baafbb99bee99a1d687039313eb454d3a9b
Partial-Bug: #1734320
Partial-Bug: #1815989
Currently codes only support assocate tunnel network and vlan network
to DVR router. This patch add codes that make the flat network assocate
to DVR router and make it work fine.
The patch also remove two unused constant entries: 'FLAT_VLAN_ID' and
'LOCAL_VLAN_ID'
Change-Id: I7d792ce288d96548298f169748565266a130bd86
Closes-Bug: #1876092
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
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
Jakub Libosvar