The ML2 and OVN metadata agents have almost identical
code, as the former was copied to the latter and modified.
Instead, combine all the common parts and just have
each do any driver-specific operations separately.
Change-Id: Iff8bc8de16a8afc7c0195bf301d1b0643e17d7c6
Format correctly (dialect=mac_unix_expanded) the MAC addresses in
``DHCPAgentOVSTestFramework``. Before this patch, this is the leases
file the DHCP server was using:
Done building initial lease file
/tmp/tmp3_m7_fqk/tmpiadm5q0e/9afb0444-e28e-4582-abb0-031d6ed500e4/leases
with contents:
1676775199 24:77:3:7d:0:4c 192.168.10.11 * *
1676775199 24:77:3:7d:0:3a 192.168.10.1 * *
Related-Bug: #2007992
Change-Id: Ie903fd3f645f7428854cf6b2fe48a1edf342cc32
Let's see how many times the test asks for IP addr list
during 10 sec timeout pediod. Probably sporadic failures
are caused by waiting for GIL for too long.
Related-Bug: #1966035
Change-Id: I41679cd7e39b0f7d64f99f509605ac9bc760ac5d
With [1] gateway is no longer set for subnet created
with prefix delegation, but when adding the subnet
to the router it fails as it expects gateway to be
set.
This patch ensures gateway is set temporary to the first IP
of the subnet as it used to be just like the temporary CIDR.
Also need to ensure dhcp configuration is skipped to avoid the
original issue[2].
[1] https://review.opendev.org/c/openstack/neutron/+/699465
[2] https://bugs.launchpad.net/neutron/+bug/1856675
Closes-Bug: #1962306
Related-Bug: #1856675
Change-Id: I512f7d98ac99bb0ef06fd2acba09482e3436d18d
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
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
In dhcp agent functional tests
test_force_metadata_for_subnet_create_delete and
test_enable_isolated_metadata_for_subnet_create_delete it may happen
that it will hit xlock error from iptables-restore command.
Normally it is handled properly and DeviceManager.setup() method is then
called again.
But in those functional tests there was no mock of the create_dhcp_port
but there was mock for get_dhcp_port and update_dhcp_port instead.
Because of that when during first call of setup() method iptables
exception was raised, during the second call of the setup() method wrong
object was put in the network.ports and test was failing due to that.
Workflow of that test is like below:
1. Call DeviceManager.setup() method
2. This method as one of the first steps will call _update_dhcp_port
which will replace dhcp port prepared for test with some other mock,
3. During first run "port" variable in DeviceManager.setup() method is
correct so all will work fine but if we hit iptables xlock error,
setup() method will be called again and
4. Now "port" local variable is already update by _update_dhcp_port
method thus test setup() method will fail as interface_name is now
wrong.
To avoid such issue this patch changed dhcp_port_mock to be "proper"
DictModel() object instead of mock.Mock() and ensures that this will be
set in network.ports even after "create_dhcp_port" will be called.
Closes-Bug: #1922684
Change-Id: I3f7dfdcbb3a54252bb1b3d2fa50eebcac3d00cba
Implement the "kill" method (send a signal to a process) using the
Python native library "os".
In functional tests, "RootHelperProcess.kill" method should not fail if
the process does not exist.
Closes-Bug: #1843446
Closes-Bug: #1843418
Change-Id: Iee97a83779dd3e20eb3a223fb8557a94b8f15dc0
Replace rootwrap execution with privsep context execution.
This series of patches will progressively replace any
rootwrap call.
Change-Id: Id3db4fbba44dd5644563481b6767ad0acbdcfb3e
Story: #2007686
Task: #41558
Send IPv6 metadata traffic (dst=fe80::a9fe:a9fe) to the metadata-agent.
When running on IPv6 enabled system bind haproxy (i.e. the
metadata-proxy) to 169.254.169.254 and to fe80::a9fe:a9fe also.
We do not introduce new config options. The usual config options
(enable_isolated_metadata, force_metadata, enable_metadata_proxy)
now control the metadata service over both IPv4 and IPv6.
This change series only affects the guests' access to the metadata
service (over tenant networks). They change nothing about how the
metadata-agent talks to Nova's metadata service.
Metadata access over IPv6 is supposed to work both on dual-stack and
v6-only networks.
In order to enable the metadata service on pre-existing isolated
networks during an upgrade, this change makes each dhcp-agent restart
trigger a quick restart of dhcp-agent-controlled metadata-proxies,
so they can pick up their new config making them also bind to
fe80::a9fe:a9fe.
Change-Id: If35f00d1fc9e4ab7e232660362410ce7320c45ba
Partial-Bug: #1460177
Now that we are python3 only, we should move to using the built
in version of mock that supports all of our testing needs and
remove the dependency on the "mock" package.
This completes removal of all references to "import mock",
changing to "from unittest import mock" in fullstack and
functional tests.
Added a hacking check to enforce it in future patches.
Change-Id: Ifcaf1c21bea0ec3c35278e49cecc90a101a82113
Remove this duplicated option and rely only in OVS.integration_bridge.
NOTE: other projects are still using it; first we need to deprecate it
in those projects.
Change-Id: I4e826c8b9fa764b1820adacc3427934dc393c0bc
Related-Bug: #1856152
This patch adds possibility to configure kill hooks used to kill
external processes, like dnsmasq or keepalived.
Change-Id: I29dfbedfb7167982323dcff1c4554ee780cc48db
Closes-Bug: #1825943
As done for the l3-agent in 837c9283ab,
dynamically resize the DHCP process queue green pool.
This patch adds a new measurement based on the network quantity to
indicate the DHCP process queue green pool size. The pool size
will be limited from 8 (original value) to 32, because we do not want
to increase the DHCP agent processing cost on the node.
Change-Id: Ic0e7bc15f138273c7a6ad41f228c9f315e6c7a91
Related-Bug: #1813787
Change network namespace add/delete/list code to use
pyroute2 library instead of calling /sbin/ip.
Also changed all in-tree callers to use the new calls.
Closes-bug: #1717582
Related-bug: #1492714
Change-Id: Id802e77543177fbb95ff15c2c7361172e8824633
In order to allow the DHCP agent to service other subnets on the
network in other segments via DHCP relay, we need to use the
'non_local_subnets' network attribute returned by rpc to set up dhcp
for off-link subnets.
Change-Id: I88e1c574bc429dc599ad7c956c03fa0688338186
Closes-Bug: 1692486
The DHCP namespace used to always have its IPv6 default
route configured from a received Router Advertisement (RA).
A recent change [1] disabled receipt of RAs, instead
relying on the network topology to configure the namespace.
Unfortunately the code only added an IPv4 default route,
which caused a regression with DNS resolution in some
circumstances where IPv6 was being used.
A default route is now added for both IP versions.
[1] https://review.openstack.org/#/c/386687/
Change-Id: I7c388f64c0aa9feb002f7a2faf76e7ccca30a3e7
Closes-bug: 1684682
Refactoring Neutron configuration options for agent common config to be
in neutron/conf/agent/common. This will allow centralization of all
configuration options and provide an easy way to import.
Partial-Bug: #1563069
Change-Id: Iebac0cdd3bcfd0135349128921b7ad7a1a939ab8
Needed-By: Ib676003bbe909b5a9013a3178b12dbe291d936af
Dnsmasq can't handle these in IPv6 so we need to skip them to avoid
a whole bunch of log noise caused by continual retrying of issues.
Closes-Bug: #1645616
Change-Id: I36d167506cc45731e3f500a0c59b70b1bc27590f
Currently the DHCP agent relies on the acceptance of an
RA to configure its IPv6 address with SLAAC or DHCPv6-stateless
network modes. It should explicitly assign addresses to the
agent based on the data model instead.
In order to do this we must disable RAs in the namespace so
that a static assignment doesn't conflict with a previously
created dynamically-generated address.
Change-Id: I1b38d131249d59fa486a07024d4b1ec61e693d59
Related-bug: #1627902
With current code, if first subnet of the network is an ipv6 subnet,
the metadata proxy will not be spawned. If user then adds ipv4 subnet
with dhcp enabled, the metadata proxy will still not be spawned. As a
result, the metadata service will not be available for the network.
This patch will kill/spawn metadata proxy, when subnet add/delete.
So, even if the first subnet of the network is not an ipv4 subnet with
dhcp enabled, the metadata proxy can still be spawned if network has
subnets need metadata proxy.
Closes-bug: #1556991
Change-Id: I0b45af8f2b756732f45c13d7e2dbcd30653cc026
Remove deprecation warnings for various constants
and exceptions that have moved to neutron_lib.
Fix miscellaneous other deprecations.
Uses constants instead of l3_constants when importing
neutron-lib constants.
Co-Authored By: Henry Gessau <gessau@gmail.com>
Co-Authored By: Gary Kotton <gkotton@vmware.com>
Change-Id: Ib0e8ff5c3e23677c1009241a1818cbc8a3430c38
We need to be able to re-use wait_until_true in tempest scenario tests.
There is tempest bug https://bugs.launchpad.net/tempest/+bug/1592345
that prevents us to do so.
Also wait_until_true is not linux specific so it makes more sense to
have it in common package.
Change-Id: Ib8b0e51dbd9edaa58391774d428a737836dfdf77
There is a bug in pep8, when 'select' used, it omits all default checks
and runs only those specified by 'select'. We got hit by this issue
since I2d26534230ffe5d01aa0aab6ec902f81cfba774d was merged which lead to
almost no static checks in pep8 job.
Also note that off_by_default decorator has no effect for now because
factory in hacking is triggered after ignored checks are collected.
There will be a follow-up patch for that in order to make pep8 doing
its job quickly.
[1] https://github.com/PyCQA/pycodestyle/issues/390
Related-Bug: 1594756
Change-Id: I8e27f40908e1bb4307cc7c893169a9d99f3433c4
When subnet is created and network is scheduled to dhcp agent, the
dhcp agent will request neutron server to create dhcp port.
Neutron server will create and mark port as BUILD and wait for the
ready signal from dhcp agent.
dhcp agent will create 'real' dhcp port after getting response from
neutron server. But after that, dhcp agent will not tell neutron server
that the dhcp port is ready. So, the reported bug can be observed.
If ports are created before dhcp is enabled for network, dhcp agent will
not mark ports as 'ready' as there is no network cache. This patch also
marks all ports in network as ready, in case that happens.
Change-Id: I363d8727f7ef6e6e08be4b0022c6464d51692b85
Closes-bug: #1588906
This changes the 'plug' and 'plug_new' interfaces of the
LinuxInterfaceDriver to accept an MTU argument. It then
updates the dhcp agent and l3 agent to pass the MTU that
is set on the network that the port belongs to. This allows
it to take into account the overhead calculations that are
done for encapsulation types.
It's necessary for the L3 agent to have the MTU because it
must recognize when fragmentation is needed so it can fragment
or generate an ICMP error.
It's necessary for the DHCP agent to have the MTU so it doesn't
interfere when it plugs into a bridge with a larger than 1500
MTU (the bridge would reduce its MTU to match the agent).
If an operator sets 'network_device_mtu', the value of that
will be used instead to preserve previous behavior.
Closes-Bug: #1549470
Closes-Bug: #1542108
Closes-Bug: #1542475
DocImpact: Neutron agents now support arbitrary MTU
configurations on each network (including
jumbo frames). This is accomplished by checking
the MTU value defined for each network on which
it is wiring VIFs.
Co-Authored-By: Matt Kassawara <mkassawara@gmail.com>
Change-Id: Ic091fa78dfd133179c71cbc847bf955a06cb248a
Currently, once the metadata_process is created for the network,
it will never be eliminated unless the network is deleted. Even if
user disable the metadata for network and restart dhcp agent, the
metdata proxy for network will still be there. This will waste the
resource of neutron host. This patch will let the dhcp-agent
delete useless metadata_proxy at startup.
Additional functional tests are added to for related scenario.
Change-Id: Id867b211fe7c01a11ba73a5ebc275c595933becf
Closes-Bug: #1507950
The use_namespaces option has been defined as a workaround to kernels
not properly supporting namespaces. This limitation is behind us, it's
time to remove use_namespaces after its deprecation in Kilo in order to
simplify code and remove a poorly tested case (use_namespaces=False).
This change prepares for removal pullup_route method[1] which was only
used when use_namespaces=False.
[1] neutron.agent.linux.ip_lib
DocImpact
UpgradeImpact
Closes-Bug: #1508188
Related-Bug: #1435382
Depends-On: I303038eec560a6d99421140c2822aed8b518470b
Depends-On: I4feb2a15c7e1e4bfdbed2531b18b8e7d798ab3cc
Change-Id: I2fbf65df1250d9f9f1656b3964ee3b6de1ef1118
Adds some utility methods and a couple of base test cases that
can be added to. These first tests exercise the ovs driver (dnsmasq)
and so the code is organised accordingly - OVS specific test cases
are defined in a DHCPAgentOVSTestFramework
Partial-Bug: #1469065
Co-Authored-By: Cedric Brandily <zzelle@gmail.com>
Co-Authored-By: Sergey Belous <sbelous@mirantis.com>
Change-Id: Ic9d5a2f2b8014e4d81f5e5f6fa58b119a86de075
Brian Haley
yatinkarel