In neutron, user can create multiple ports with same IPv6 address if
the network has no IPv6 address scope. This maybe result in some
security issues.
This can be exploited by a malicious tenant via creating a subnet with
a prefix that covers an address that is already in use and take over
(part of) the traffic flowing towards that address. The success of the
attack depends on winning the race of who answers the NDP query first,
but still a 50% chance of capturing traffic seems dangerous. The attack
works not only against other addresses served by NDP proxy, but also
against other hosts that may exist, potentially even the gateway for
the external network.
So, we should use `IPv6 address scope` to ensure the IPv6 address is
unique when we want to use `ndp proxy` feature.
Depends-on: https://review.opendev.org/#/c/855997
Closes-Bug: #1987410
Change-Id: I0fa431a91a7679e409386a357a01c31ec5ad0cfd
This will be used in future when dhcp will handle different
segmentation ids.
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ie005285ed667041732950a6aa226b8151d608afe
When segment plugin is enabled, we should return segments details as
they are part of network.
Partial-Bug: #1956435
Partial-Bug: #1764738
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: I1dab155bc812f8764d22e78ebb7d80aaaad65515
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
When a new IP route is created, before passing the route protocol,
find if it is a string and if this string is on the pyroute2 defined
protocols. In this case, pass the protocol number.
In the same way, when the IP route is returned, if the protocol is a
number, convert it to the corresponding protocol string.
Closes-Bug: #1988037
Change-Id: I4ca66d86705a55b2b63083c229629c16b6136283
- Use only the documentation prefix in examples
- Update some formatting and wording
- Add a reference in the OVN gaps document
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I2acf762008ce44b6a792c615c153071e1c10e0b3
In some specific use case, the cloud operator expects the source port
of a packet to stay the same across all masquerading layer up to the
destination host. With the implementation of the random-fully code,
this behavior was changed as source_port is always rewritten no matter
which type of architecture / network CIDRs is being used in the backend.
This setting allows a user to fallback to the original behavior of the
masquerading process which is to keep the source_port consistent across
all layers. The initial random-fully fix prevents packet drops when
duplicate tuples are generated from two different namespace when the
source_ip:source_port goes toward the same destination so enabling this
setting would allow this issue to show again. Perhaps a right approach
here would be to fix this "racey" situation in the kernel by perhaps
using the mac address as a seed to the tuple ...
Change-Id: Idfe5e51007b9a3eaa48779cd01edbca2f586eee5
Closes-bug: #1987396
This will subnets from shared networks to be added on routers using:
$ openstack router add subnet router_id subnet_id
Without this, neutron user must use a multi-router solution, which is
not convenient at all.
Closes-Bug: #1975603
Related-Bug: #1757482
Signed-off-by: Arnaud Morin <arnaud.morin@ovhcloud.com>
Change-Id: I50f07d41428e57e6bed9be16980a6c605b7d130e
Since [1], when a segment is deleted because the network is before,
the segment event handler method ``_handle_segment_change`` does not
call ``_notify_mechanism_driver_for_segment_change`` and thus the
check performed in ``OVNMechanismDriver.update_network_postcommit``
is not needed anymore.
[1]https://review.opendev.org/c/openstack/neutron/+/786373
Closes-Bug: #1739798
Change-Id: I4bb22a0a0a233609a4d23af55a050356049eb214
There is a scenario where IP allocation pool is depleted but OVN
metadata port got removed its IP manually. The DB sync script will
attempt to allocate a new IP address if DHCP is enabled in the subnet.
Since the pool has no available IP addresses an exception is raised and
the whole db sync stops.
This patch simply catches the exception, logs and error and continues
syncing other resources.
Closes-bug: #1987135
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Change-Id: Iaa7b0d7ceb244a38fddd7676066683bf2ca72341
According to latest agreement about Secure RBAC [1] we are not using
PROJECT_ADMIN and SYSTEM_{ADMIN,MEMBER,READER} roles at all, at least
for now.
So there's no point to keep definitions of those roles in the code and
this patch removes them.
[1] https://review.opendev.org/c/openstack/governance/+/847418
Change-Id: I7ecfa39615375f71902d6fed4f3c82f9049c4c61
This change reflects latest agreement from [1] that instead of
ProjectAdmin role there will be "legacy" Admin role which behaves as
"old" Admin basically.
[1] https://review.opendev.org/c/openstack/governance/+/847418
Change-Id: I11fe3293aef95f0096935c98e05b40f8d912bc09
According to the new guidelines accepted in [1] for now there should be
only one ADMIN role and it should have access to everything (like ADMIN
in old rules).
This patch replaces usage of PROJECT_ADMIN to ADMIN and adjusts unit
tests to reflect that change as now ADMIN user have access to all
resources, no matter if it belongs to the own or other project.
[1] https://review.opendev.org/c/openstack/governance/+/847418
Change-Id: Ib88967b492af517931d42600da687d447bd55705
According to the new guidelines accepted in [1] for now all new default
API policy rules should have "project" scope only.
This patch adjusts neutron policies according to [1].
[1] https://review.opendev.org/c/openstack/governance/+/847418
Change-Id: I1e923cc268d80087120a9c4d8a7aa4f2780cd82f
A new script to remove the duplicated port bindings was added. This
script will list all ``ml2_port_bindings`` records in the database,
finding those ones with the same port ID. Then the script removes
those ones with status=INACTIVE. This script is useful to remove
those leftovers that remain in the database after a failed live
migration.
"dry_run" mode is possible if selected in "[cli_script] dry_run"
boolean config option. The duplicated port bindings are printed in
the shell but not deleted.
Related-Bug: #1979072
Change-Id: I0de5fbb70eb852f82bd311616557985d1ce89bbf
Patch [1] added getting ovn agents from the agents cache and check
if agent is alive to bound port to it.
Small issue with it was that it could check e.g. ovn metadata agent from
the host as it was only filtering agents by the host on which they are.
This patch adds filter on the agent_type so only ovn-controller agents
are taken from the cache.
[1] https://review.opendev.org/c/openstack/neutron/+/825428
Related-Bug: #1958501
Change-Id: If065204d7521c480656a22fb078bbe6273b5fc70
