Remove B324 (prohibit list calls: md5, sha1 for python>=3.9)
from bandit skip list, for this replace sha1 with blake2b.
Change-Id: Iafe571ad0de0408414ed321f4b9e9588916a873d
We recently met an issue during VM live migration:
1. nova starts live migration
2. plug ports on new host
3. neutron-ovs-agent starts to process the port,
but the port is in 'added' and 'updated' set
at the same time.
4. because nova still not activate the destination
port binding, so there is no local vlan for
this port.
Then, ovs-agent met errors:
Error while processing VIF ports: OVSFWTagNotFound:
Cannot get tag for port tap092f38ed-a7 from its other_config: {}
This fix is to remove ports of the
"binding_no_activated_devices" for ``setup_port_filters``.
Closes-Bug: #2048979
Change-Id: I0f1e6bf202ef08f75246d6e99b3774d0b6fc9e2b
Prior to this patch, ML2/OVS and ML2/OVN had inconsistent IGMP
configurations. Neutron only exposed one configuration option for IGMP:
igmp_snooping_enabled.
Other features such as IGMP flood, IGMP flood reports and IGMP flood
unregistered were hardcoded differently on each driver (see LP#2044272
for a more details).
These hardcoded values has led to many changes over the years tweaking
them to work on different scenarios but they were never final because
the fix for one case would break the other.
This patch introduces 3 new configuration options for these other IGMP
features that can be enabled or disabled on both backends. Operators
can now fine tune their deployments in the way that will work for them.
As a consequence of the hardcoded values for each driver we had to break
some defaults and, in the case of ML2/OVS, if operators want to keep
things as they were before this patch they will need to enable the new
mcast_flood and mcast_flood_unregistered configuration options.
That said, the for ML2/OVS there was also an inconsistency with the help
string of igmp_snooping_enabled configuration option as it mentioned
that enabling snooping would disable flooding to unregistered ports but
that was not true anymore after the fix [0].
[0] https://bugs.launchpad.net/neutron/+bug/1884723
Closes-Bug: #2044272
Change-Id: Ic4dde46aa0ea2b03362329c87341c83b24d32176
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
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
When neutron-server is down, ovs-agent waits for it to become available
during agent startup. When neutron-server is up, but it cannot reach the
DB, it can do nothing pretty much the same way. However ovs-agent
reacted differently to this failure. With this patch it reacts the same
way and delays its startup until neutron-server is up together with its
DB.
Change-Id: Ia55e82540aedc236e9b016bb58047d0b437eeb99
Closes-Bug: #2025341
After updating pylint, it started emitting additional "R"
warnings in some cases, fix some of them.
use-a-generator,
unnecessary-lambda-assignment,
consider-using-max-builtin,
consider-using-generator,
consider-using-in,
use-list-literal,
consider-using-from-import
Trivialfix
Change-Id: Ife6565cefcc30b4e8a0df9121c9454cf744225df
If openvswitch is restarted, try to notify neutron-server
that to refresh tunnel flows for every ports.
Closes-Bug: #2004041
Change-Id: Iba0ae947e3595674e63b998826daae2582bb7668
The metadata agent extension needs the patch ports informations
between br-int and br-meta to add direct flows.
Partially-Implements: blueprint distributed-metadata-datapath
Change-Id: I58f3813ed9a4c4006ebb62e613ef4dc07a17a23b
Bug introduced by Ic3c147136549b17aea0fe78e930a41a5b33ab9d8, when a
VLAN mapping is not registered during a call to
update_network_segement, the function should return None.
Closes-Bug: #2009215
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I91f8e8bd18d9956216e5715c658dfb408a2cbf07
This patch adds support for QoS minimum bandwidth rules in tunnelled
networks. Now the ML2/OVS and ML2/OVN mechanism drivers can represent
in the Placement API the available bandwidth of the tunnelled networks
in each compute host.
Both mechanism drivers represent the compute VTEP (VXLAN) or TEP
(Geneve) interface as an IP address. This new resource provider
(by default called "rp_tunnelled") represents the available bandwidth
of this interface. Any new port created in a compute node that belongs
to a tunnelled network, will request to the Placement API the
corresponding bandwidth from the resource provider inventory.
This patch does not provide backend enforcement support for minimum
bandwidth rules.
RFE spec: https://review.opendev.org/c/openstack/neutron-specs/+/860859
What is missing and will be added in next patches:
* Tempest tests, that will be pushed to the corresponding repository.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/863880
Partial-Bug: #1991965
Related-Bug: #1578989
Change-Id: I3bfc2c0f9566bcc6861ca91339e32257ea92c7e9
When libvirt (nova) detach a port on OVS bridge, two events are sent:
* one event with 2 actions "old" and "new": a change on ofport (from a
regular value to -1)
* a second event with action "delete"
If, for some reason, the second event is delayed, the rpc_loop iteration
will consider this port as "updated" instead of "deleted".
But, because ofport == -1, the port update will be discarded, and
finally removed from port_info["current"].
As a result, on next iteration, the deletion wont be performed.
Most of the time, we endup with some leftovers (like openflow rules,
etc.)
The purpose of this patch is very simple, when looping over ports in
_get_ofport_moves, we will discards the ports that have ofport == -1, so
the port will not be considered as updated and next iteration will be
able to delete it correctly.
Closes-Bug: #1992109
Change-Id: Ib4a7183867e1b21810b6915a475a234278bf884c
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
Running with a stricter .pylintrc generates a lot of
C0330 warnings (hanging/continued indentation). Fix
the ones in neutron/plugins.
Trivialfix
Change-Id: Id9138652f5f07ef12fa682e182fe210019e8f975
The log entry had %(tag)s but the dict has 'segmentation_id' as key,
so let's change tag to segmentation_id.
Change-Id: Ic6e82a31efe7798c9ec0c5e6bc743db4c280fd1a
Partial-Bug: #1956435
Partial-Bug: #1764738
As a followup from the previous commit we here now also cleanup the
SubPort an Trunk fanout queues.
Closes-Bug: #1586731
Change-Id: I047603b647dec7787c2471d9edb70fa4ec599a2a
Previously when a neutron-openvswitch-agent was stopped it left
behind the following fanout queues in rabbitmq:
neutron-vo-Network-1.0_fanout_someuuid
neutron-vo-Port-1.1_fanout_someuuid
neutron-vo-SecurityGroup-1.0_fanout_someuuid
neutron-vo-SecurityGroupRule-1.0_fanout_someuuid
neutron-vo-SubPort-1.0_fanout_someuuid
neutron-vo-Subnet-1.0_fanout_someuuid
neutron-vo-Trunk-1.1_fanout_someuuid
In this change we ensure that all but the SubPort and Trunk fanout
queues are correctly removed from rabbitmq by cleanly stopping the
RemoteResourceCache when the agent stops.
Partial-Bug: #1586731
Change-Id: I672f9414a1a8ed91e259e9379ca707a70f6b4467
This is using changes introduced before to support for a network more
than one vlan.
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ifd61e379c3cef3589803c96a276da9827051f660
This change is updating the vlanmanager data structure to handle for a
given network more than one vlan mapping. This is a prerequisite work
needed to progress on accepting several segments per network per
host.
The work done here is trying to avoid changing logic in the
current implementation. Unit test should not have value updated,
but probably signatures changed.
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic3c147136549b17aea0fe78e930a41a5b33ab9d8
Based on current alorithm it seems that vif_port may never be None.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I50f2b65f0bbefe8b7f7598876cd7804d17ccdb02
This switch the warning to error as we may be in a sitation of no
connectivity and this should never happen.
Also improves the condition for an ofport invalid.
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic6bd7bfadcba8deb132d8af3e295ec25a8d64b50
This is changing the datastructure that maintains the relationship
between ports and networks to also handle the segmenation ids related.
This will be necessary in future to support multiple segments per
networks on a same physical provider network.
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Iaf40ddc20692a3a51a8d5f5acfc2094b2d5c00c4
This reverts commit: b83fedbd78.
Since port is set to dead by default after the commits of:
7aae31c9f90ddca28454
And we add the local vlan tag to the port right after it is
bound to aviod trunk port flood issue:
c63ebef2d5
So that _add_port_tag_info function is not necessary anymore,
and we will save a large OVSDB read action which is dumping
the entire table of Port, for hosts with a huge number of
ports this is time-comsuming. So removed it.
Related-Bug: #1968896
Related-Bug: #1952567
Change-Id: Iefd765d497c7e2d4bb093052478185125b907025
Port admin state down will add 4095 tag to it while
it is adding a drop flow for this ofport.
When port is back UP again, remove the drop flow.
Closes-bug: #1968896
Change-Id: Ie8f67def69ae0e5d425d0e6fc43e35373a96bd88
Importing some modules lead to registering config options that may
collide with config options from a project that calls the import. This
patch wraps the side effect that registers config options into a
function that needs to be called in case the caller wants to register
the options.
This solution is also not perfect as it guards the common options to be
registered only once even if the function is called multiple times. This
is to solve problems in unittests, ideally we should always call the
function just once even in our testing suites.
Resolves-Bug: #1968606
Change-Id: Ic1532eb8de887ff1b1085206df11f53e22f7f524
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
During some ml2 ovs agent port processing performance test, we noticed
that some ports are missing tag before it really done processing. While
ovs treats those ports without tag as trunk port, so some packets will
be flooded to it. In large scale cloud, if too many port added to the
bridge, the ovs-vswitchd will consume a huge amount of CPU cores if
ports are not bound in a short time.
So, in the port_bound function of ovs-agent, we set the port tag to
it after a local_vlan id is allocated. Because after that, setup
security groups (setup_port_filters) and bind devices in DB
(update_device_list) are really time-consuming.
And also fix a potential bug, port is processed as created first,
but no tag in ovsdb, so openflow security group will not be processed
successfully [1]. It must be done in a update event during next loop,
after port bound and ovsdb set the required value.
This patch can also fix some upstream test failures of waiting too
long time to ping some cases.
[1] https://github.com/openstack/neutron/blob/master/neutron/agent/linux/openvswitch_firewall/firewall.py#L112
Closes-Bug: #1952567
Change-Id: I3533f0d416d32f8d0888ad58f975960d89a985d9
During e.g. rebuild of the server by Nova, ports plugged to such server
are quickly removed and added again into br-int. In such case, ports are
in the "re_added" ports set in the neutron-ovs-agent.
But it seems that in some cases it may happen that such port isn't
switched to be DOWN first and then, when neutron-ovs-agent treats port
as added/updated and reports to the server that port is UP, there is no
notification to nova-compute send (because port's status was UP and new
status is still UP in the Neutron DB).
As Nova waits for the notification from Neutron in such case server
could ends up in the ERROR state.
To avoid such issue, all ports which are treated as "re_added" by the
neutron-ovs-agent are now first switched to be DOWN on the server side.
That way, when those ports are treated as added/updated in the same
rpc_loop iteration, switching their status to UP will for sure trigger
notification to nova.
Closes-Bug: #1963899
Change-Id: I0df376a80140ead7ff1fbf7f5ffef08a999dbe0b
https://review.opendev.org/c/openstack/neutron/+/820897 added
a dead vlan flow that pushes the dead vlan tag onto frames
belonging to dead ports before these ports are reassigned to
their proper vlans. However add_flow and delete_flows race and
delete_flows may run before add_flow, in this case deleting 0 flows
but not giving us a chance to detect this: neither does it throw
an error nor does it return the number of deleted flows.
This leads to port staying inaccessible forever and hence
breaks corresponding DHCP or router.
Current patch suggests another approach to make sure no packets are
leaked from newly plugged ports: setting their "vlan_mode" attribute
to "trunk" and "trunks"=[4095] (along with assigning dead VLAN tag).
With this OVS normal pipeline will allow only packets tagged with 4095
from such ports [1], which normally not happens, but even if it does -
default rule in br-int will drop them anyway.
Thus untagged packets from such ports will also be dropped until
ovs agent sets proper VLAN tag and clears vlan_mode to default
("access").
This approach avoids the race between dhcp/l3 and ovs agents because
dhcp/l3 agents no longer modify flow table.
This partially reverts commit 7aae31c9f9
[1] https://docs.openvswitch.org/en/latest/ref/ovs-actions.7/?highlight=ovs-actions#the-ovs-normal-pipeline
Closes-Bug: #1930414
Closes-Bug: #1959564
Change-Id: I0391dd24224f8656a09ddb002e7dae8783ba37a4
The [agent] veth_mtu parameter has had unused since the [ovs]
use_veth_interconnection parameter was removed by [1] during Wallaby.
[1] https://review.opendev.org/c/openstack/neutron/+/759947
This change formally deprecate the parameter so that we can remove it
in a next cycle.
Change-Id: Ib85959fbc06928a49df7ea104eae3aca3f04e091
Closes-Bug: #1957180
All ports plugged into the dead vlan (DEAD_VLAN_TAG 4095 or 0xfff)
should not be able to send or receive traffic. We install a flow
to br-int to drop all traffic of the dead vlan [1]. However before
this patch the flow we install looks like:
priority=65535,vlan_tci=0x0fff/0x1fff actions=drop
Which is wrong and it usually does not match anything.
According to ovs-fields (7) section Open vSwitch Extension VLAN Field,
VLAN TCI Field [2] (see especially the usage example
vlan_tci=0x1123/0x1fff) we need to explicitly set the bit 0x1000
to match the presence of an 802.1Q header.
Setting that bit this flow becomes:
priority=65535,vlan_tci=0x1fff/0x1fff actions=drop
which is equivalent to:
priority=65535,dl_vlan=4095 actions=drop
which should match and drop dead vlan traffic.
However there's a second problem: ovs access ports were designed to
work together with the NORMAL action. The NORMAL action considers the
vlan of an access port, but the openflow pipeline does not. An openflow
rule does not see the vlan set for an access port, because that vlan
tag is only pushed to the frame if and when the frame leaves the switch
on a trunk port [3][4].
So we have to explicitly push the DEAD_VLAN_TAG if we want the dead
vlan's drop flow match anything.
That means we are adding a flow to push the dead vlan tag from
dhcp-agent/l3-agent but we are deleting that flow from ovs-agent right
after ovs-agent sets the vlan tag of the port to a non-dead vlan. Which
is ugly but we have to keep adding the flow as early as possible if we
want to minimize the window until frames can leak onto the dead vlan.
Even with this change there's a short time window in which the dead vlan
could theoretically leak.
[1] ecdc11a564/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/br_int.py (L60-L62)
[2] http://www.openvswitch.org/support/dist-docs/ovs-fields.7.html
[3] https://mail.openvswitch.org/pipermail/ovs-discuss/2021-December/051647.html
[4] https://docs.openvswitch.org/en/latest/faq/vlan/
see 'Q: My OpenFlow controller doesn’t see the VLANs that I expect.'
Change-Id: Ib6b70114efb140cf1393b57ebc350fea4b0a2443
Closes-Bug: #1930414
Use class variable instead of module constant to
allow modification of max_device_retries in classes inheriting
from OVSNeutronAgent.
Closes-Bug: #1952898
Change-Id: I952491ca89466540d39d78f963b581302c0d8a17
- setup local ARP responder
- setup local ip translation flows (nat via conntrack)
- setup local gARP blocker to prevent undesired Local IP ARP updates
from other nodes (including real IP address owner)
2 new OF tables added for br-int:
- LOCAL_EGRESS_TABLE - to save local ports vlans
- LOCAL_IP_TABLE - for local ip handling
Partial-Bug: #1930200
Change-Id: I49923958d1d602e3af4e02fadbec1b17798c49c8
elajkat