diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/source/admin/config-dhcp-ha.rst | 32 | ||||
| -rw-r--r-- | doc/source/admin/config-qos.rst | 9 | ||||
| -rw-r--r-- | doc/source/admin/ovn/troubleshooting.rst | 79 | ||||
| -rw-r--r-- | doc/source/contributor/testing/ci_scenario_jobs.rst | 5 |
4 files changed, 116 insertions, 9 deletions
diff --git a/doc/source/admin/config-dhcp-ha.rst b/doc/source/admin/config-dhcp-ha.rst index 82780551b7..fcfbc87d40 100644 --- a/doc/source/admin/config-dhcp-ha.rst +++ b/doc/source/admin/config-dhcp-ha.rst @@ -441,6 +441,38 @@ To test the HA of DHCP agent: #. Start DHCP agent on HostB. The VM gets the wanted IP again. +No HA for metadata service on isolated networks +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All Neutron backends using the DHCP agent can also provide `metadata service +<https://docs.openstack.org/nova/latest/user/metadata.html>`_ in isolated +networks (i.e. networks without a router). In this case the DHCP agent manages +the metadata service (see config option `enable_isolated_metadata +<https://docs.openstack.org/neutron/latest/configuration/dhcp-agent.html#DEFAULT.enable_isolated_metadata>`_). + +Note however that the metadata service is only redundant for IPv4, and not +IPv6, even when the DHCP service is configured to be highly available +(config option `dhcp_agents_per_network +<https://docs.openstack.org/neutron/latest/configuration/neutron.html#DEFAULT.dhcp_agents_per_network>`_ +> 1). This is because the DHCP agent will insert a route to the well known +metadata IPv4 address (`169.254.169.254`) via its own IP address, so it will +be reachable as long as the DHCP service is available at that IP address. +This also means that recovery after a failure is tied to the renewal of the +DHCP lease, since that route will only change if the DHCP server for a VM +changes. + +With IPv6, the well known metadata IPv6 address (`fe80::a9fe:a9fe`) is used, +but directly configured in the DHCP agent network namespace. +Due to the enforcement of duplicate address detection (DAD), this address +can only be configured in at most one DHCP network namespaces at any time. +See `RFC 4862 <https://www.rfc-editor.org/rfc/rfc4862#section-5.4>`_ for +details on the DAD process. + +For this reason, even when you have multiple DHCP agents, an arbitrary one +(where the metadata IPv6 address is not in `dadfailed` state) will serve all +metadata requests over IPv6. When that metadata service instance becomes +unreachable there is no failover and the service will become unreachable. + Disabling and removing an agent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/source/admin/config-qos.rst b/doc/source/admin/config-qos.rst index b5713dba79..b46273fc97 100644 --- a/doc/source/admin/config-qos.rst +++ b/doc/source/admin/config-qos.rst @@ -126,10 +126,11 @@ updated: Valid DSCP Marks ---------------- -Valid DSCP mark values are even numbers between 0 and 56, except 2-6, 42, 44, -and 50-54. The full list of valid DSCP marks is: +Valid DSCP mark values are even numbers between 0 and 56, except 2-6, 42, and +50-54. The full list of valid DSCP marks is: -0, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 46, 48, 56 +0, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 44, 46, +48, 56 L3 QoS support @@ -165,7 +166,7 @@ traffic directions (from the VM point of view) for **bandwidth limiting**. Rule \\ L3 service L3 router OVN L3 ==================== =================== =================== Floating IP Egress \\ Ingress Egress \\ Ingress - Gateway IP Egress \\ Ingress - + Gateway IP Egress \\ Ingress Egress \\ Ingress ==================== =================== =================== diff --git a/doc/source/admin/ovn/troubleshooting.rst b/doc/source/admin/ovn/troubleshooting.rst index 646a05648c..29b10dcc16 100644 --- a/doc/source/admin/ovn/troubleshooting.rst +++ b/doc/source/admin/ovn/troubleshooting.rst @@ -43,3 +43,82 @@ This problem is not unique to OVN but is amplified due to the possible larger size of geneve header compared to other common tunneling protocols (VXLAN). If you are using VM's as compute nodes make sure that you either lower the MTU size on the virtual interface or enable fragmentation on it. + +Duplicated or deleted OVN agents +-------------------------------- + +The "ovn-controller" process is the local controller daemon for OVN. It runs +in every host belonging to the OVN network and is in charge of registering +the host to the OVN database by creating the corresponding "Chassis" and +"Chassis_Private" registers in the Southbound database. At the same time, +when the process is gracefully stopped, it deletes both registers. These +registers are used by Neutron to control the OVN agents. + + .. code-block:: console + + $ openstack network agent list -c ID -c "Agent Type" -c Host -c Alive -c State + +--------------------------------------+------------------------------+--------+-------+-------+ + | ID | Agent Type | Host | Alive | State | + +--------------------------------------+------------------------------+--------+-------+-------+ + | a55c8d85-2071-4452-92cb-95d15c29bde7 | OVN Controller Gateway agent | u20ovn | :-) | UP | + | 62e29a01-a0ac-55c9-b4ec-e223d5c90853 | OVN Metadata agent | u20ovn | :-) | UP | + | ce9a1471-79c1-4472-adfc-9e5ce86eba07 | OVN Controller Gateway agent | u20ovn | XXX | DOWN | + | 3755938f-9aac-4f08-a1ab-32fcff56d1ce | OVN Metadata agent | u20ovn | XXX | DOWN | + +--------------------------------------+------------------------------+--------+-------+-------+ + + +If during a system upgrade the OVS "system-id" changes, the "Chassis" and +"Chassis_Private" registers will be created again but with a different UUID. +If the previous registers are not deleted (that should happen if the +"ovn-controller" process is gracefully stopped), Neutron will show duplicated +agents from the same host. In this case, only one agent will be alive and +the other one will be down because the "Chassis_Private.nb_cfg_timestamp" +is not updated. In this case, the administrator should manually delete from +the OVN Southbound database the stale registers. For example: + + * List the "Chassis" registers, filtering by hostname and name (OVS + "system-id"): + + .. code-block:: console + + $ sudo ovn-sbctl list Chassis | grep name + hostname : u20ovn + name : "a55c8d85-2071-4452-92cb-95d15c29bde7" + hostname : u20ovn + name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07" + + + * Delete the stale "Chassis" register: + + .. code-block:: console + + $ sudo ovn-sbctl destroy Chassis ce9a1471-79c1-4472-adfc-9e5ce86eba07 + + + * List the "Chassis_Private" registers, filtering by name: + + .. code-block:: console + + $ sudo ovn-sbctl list Chassis_Private | grep name + name : "a55c8d85-2071-4452-92cb-95d15c29bde7" + name : "ce9a1471-79c1-4472-adfc-9e5ce86eba07" + + + * Delete the stale "Chassis_Private" register: + + .. code-block:: console + + $ sudo ovn-sbctl destroy Chassis_Private ce9a1471-79c1-4472-adfc-9e5ce86eba07 + + +If the host name is also updated during the system upgrade, the Neutron +agent list could present entries from different host names, but the older +ones will be down too. The procedure is the same. + +It could also happen that during a node decommission, the "Chassis" register +is deleted but not the "Chassis_Private" one. In that case, the OVN agent +list will present the corresponding agents with the following message: +"('Chassis' register deleted)". Again, the procedure is the same: the +administrator should manually delete the orphaned OVN Southbound database +register. Neutron will receive this event and will delete the associated +OVN agents. diff --git a/doc/source/contributor/testing/ci_scenario_jobs.rst b/doc/source/contributor/testing/ci_scenario_jobs.rst index af81cef608..6d0e030374 100644 --- a/doc/source/contributor/testing/ci_scenario_jobs.rst +++ b/doc/source/contributor/testing/ci_scenario_jobs.rst @@ -139,11 +139,6 @@ Currently we have in that queue jobs like listed below. | |(only tests related to | | | | | | | | | | | |Neutron and Nova) | | | | | | | | | | +----------------------------------------------+----------------------------------+-------+------------------+-------------+-----------------+----------+-------+--------+------------+-------------+ - |neutron-tempest-with-uwsgi-loki |tempest.api (without slow tests) | 1 | Ubuntu Jammy | openvswitch | openvswitch | legacy | False | False | True | No | - |(non-voting) |tempest.scenario | | | | | | | | | | - | |(only tests related to | | | | | | | | | | - | |Neutron and Nova) | | | | | | | | | | - +----------------------------------------------+----------------------------------+-------+------------------+-------------+-----------------+----------+-------+--------+------------+-------------+ |neutron-ovn-tempest-ipv6-only-ovs-master |tempest.api (without slow tests) | 1 | Ubuntu Jammy | ovn | ovn | --- | False | False | True | Yes | | |(only tests related to | | | | | | | | | | | |Neutron and Nova) | | | | | | | | | | |