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
- 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
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
As a failsave the migration code can create a backup of
the controllers to use in case that the migration fails
and leaves the environment on a unusable state.
The revert plan has two stages:
1- Backup stage: included on the current ovn-migration.yml.
Can be configured using the env variable CREATE_BACKUP
(True by default). This stage will run the new ansible
role, recovery-backup.
It will store the backup on `/ctl_plane_backup` on the host
where the BACKUP_MIGRATION_IP belongs to (can be modified by
modifing the env var).
In order to restore the controllers, boot them using the iso created
by ReaR (stored in /ctl_plane_backup) and perform `automatic recover`
2- Revert stage: this stage has its own ansible playbook (revert.yml)
This playbook will clean the environment from all the OVN ressources
that could had been created (breaking the data plane connectivity)
to leave the environment in a stage where an overcloud deploy with
the OVS templates can be run.
Note: If the user creates new resources after running the backup stage
and then performs the recovery of the controllers, those resources will
be lost.
Change-Id: I7093f6a5f282b06fb2267cf2c88c533c1eae685d
Updated documentation about minimum guaranteed bandwidth support
for OVN backend. This mech driver is capable of informing the
Placement API about the bandwidth resources of each chassis and
schedule a port depending on the minimum bandwidth rules applied.
This patch also updates the document pointing to the new
``resource_requeste`` blob passed to Nova with the information of
the requested resources of each port.
Related-Bug: #1578989
Change-Id: I75401fa64e1ccd814aa485a74b38092849ff2a18
The doc build needs WebTest, which used to be imported as a transitive
requirement via pecan, but the latest release of pecan dropped this
dependency. So make this requirement explicit.
Change-Id: Ib3f3318440c79909090616b9d480b8dbf55e7b81
https://docs.openstack.org/nova/latest/admin/aggregates.html link failure,
From openstack U version, this link is not in the user directory. Currently, only the latest version has been changed.
You are advised to change all the links
Change-Id: Ic3b5a0ac7d832b162848b363396264ed0bfc4a25
During the Zed PTG it was decided to handle unsupported features in
Neutron as experimental. See section titled "When we say something is
not supported?", day 2 in [1]. The agreement was:
"We keep existing jobs for linuxbridge driver for example, but when the
tests start to fail we skip them and finally we stop the job also.
To make it clear for operators we add warning logs highlighting that the
given feature/driver is experimental, and introduce cfg option to enable
such features explicitly."
This commit implements this agreement, initially with Linuxbridge
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/845646
[1] https://lists.openstack.org/pipermail/openstack-discuss/2022-April/028164.html
Change-Id: Ib18efa3f472736b58c8967847b1061da0e3897d7
Original url leads user to a markdown file, I think it's better to
use official html document rather than a markdown file.
Change-Id: Ib3ee4c6bccbb98a6469e2d7e9cde652288bbb163
This patch adds documentation for baremetal provisioning with ML2/OVN.
This patch also splits the section about external ports to a different
document so it can be shared between baremetal and SR-IOV as both
features uses the same feature from core OVN.
Change-Id: I48cbd73c3c0fcf0393e31356c081ab1561eecc79
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch adds support for deploying baremetal nodes with OVN's
built-in DHCP server for IPv4.
Since Neutron API's for setting DHCP options is mostly a pass-thru,
Ironic uses a dnsmasq syntax for setting the baremetal options [0].
Since this syntax is unlikely to change and it's only a tiny subset of
what dnsmasq can offer this patch does translate that syntax used by
Ironic and convert it to OVN's equivalent options. In this way we do not
need to re-design Neutron's DHCP options API nor change Ironic to use it
with ML2/OVN.
This option also adds a new configuration option called
"disable_ovn_dhcp_for_baremetal_ports". PXE booting nodes can be very
sensitive and operators may prefer to use a fully-fledged DHCP server to
do it (even Ironic makes DHCP pluggable). So if operators wish to
disable OVN's built-in DHCP server for baremetal provisioning they can
do so by setting this new option to True. It defaults to False.
This change has been tested with real hardware and it does work. That
said, we found a problem in core OVN itself [1] while testing it that
can affect PXE from reaching the TFTP server, we already communicated
this with the core OVN folks and we hope it can be fixed soon. The
change in core OVN should not affect the Neutron change tho.
Not that the "server-ip-address" DHCP Option now points to the
"next_server" option in OVN instead of the "tftp_server_address". The
previous behavior was wrong, the "server-ip-address" should set the
"siaddr" in the DHCP header and this has been introduced in OVN [2] as
an option called "next_server".
[0]
49113385e8/ironic/common/pxe_utils.py (L523-L538)
[1]
https://mail.openvswitch.org/pipermail/ovs-discuss/2022-May/051821.html
[2]
https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/
Partial-Bug: #1971431
Change-Id: Ia041f640293ba26abf9f70af915817e9861e8ffc
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Recently we closed some of the gaps between ML2/OVS and ML2/OVN,
like for example:
* Support for the QoS DSCP,
* Support for the Layer 3 IPs QoS,
* Fix bugs [1] and [2] related to the OVN DNS resolution.
This patch updates documented gaps by removing those points from the
gaps list.
It also adds some links to the WIP patches for other of the gaps on that
list.
[1] https://bugs.launchpad.net/neutron/+bug/1951816
[2] https://bugs.launchpad.net/neutron/+bug/1950686
Change-Id: I0e670ef0a87300182ba83f350a84d28bf8d31eb9
This reverts commit bce27811dfea634118fdb609289ac70c8d4a6854.
Reason for revert: neutron-fwaas has maintainers so the documentation should be available.
Due to changes since the original deletion commit the following changes
were added:
* Add note that OVN is not yet supported
* Remove note that Horizon support is not available
Change-Id: I1a739ee045b49e9b44283c28f95b1accc8a1e37f
Added "Open Flow processing considerations" in the OVS firewall
driver page. This section describes the [OVS] configuration option
"openflow_processed_per_port". A script to meassure the Open Flow
rule processing time is provided.
Related-Bug: #1934917
Change-Id: Id4936b6d36abb6edc250aaf1cbc7e9af3fd0fae5
The existing example had an implicit overlap between the host network
and some tenant network, use a different network for the host.
Peering network resized to /24 because usually we would have several
network nodes on it instead of creating each their own transfer/peering
network.
Diagrams adjusted accordingly with omnigraffle.
PNGs reexported with 160% size to approximate the previous ones.
Router IPs in Diagrams adjusted to reflect documentation.
Peering Network IPs added to Peering Session Box.
Change-Id: I8778df02330196a8999afd3bbf9a3b87f0e14f7b
While the focus of the routed provider networks documentation
is on the Neutron side of things, this document provides a useful
location to point at relevant Nova configuration.
This reference relates to the Nova scheduler and ensuring that
instance move operations don't result in instances being scheduled
to hosts which do not have access to the required network(s).
Change-Id: Idd7382bd38d70383107d2997205ff880bede8d96
It has been suggested in the Neutron CI meeting to include a section in
the documentation advicing against blind rechecks. It turns out that
such section already exists. What this change does is to move the
section to the first level of the contributors guide, to make it more
visible. This change also improves some wording and adds some examples
of proper recheck comments.
Change-Id: Ib0a00d13a28f98b0a0f26c7233365d04453db4e0
