2024.1 Series Release Notes

24.0.1-32

Security Issues

  • A ML2/SR-IOV port with status=DOWN will always set the VF link state to “disable”, regardless of the propagate_uplink_status port field value. The port disabling, to stop any transmission, has precedence over the link state “auto” value.

Bug Fixes

  • Fixes an issue when associating floating IPs to OVN load balancers. See LP#2068644 for more details.

24.0.1

Other Notes

  • Enhance error handling in the Neutron metadata service for cases when the Nova metadata service is unavailable, ensuring correct HTTP status codes are returned.

24.0.0

Prelude

The OVN changed support for NAT rules including a new column and auto-discovery logic to know about logical router gateway ports for NAT on a Logical Router.

The ML2/OVS and ML2/OVN drivers had inconsistencies on how IGMP was configured. Prior to this patch Neutron only exposed a single IGMP configuration option (igmp_snooping_enabled) and other features such as flooding IGMP packets, flooding reports and flooding to unregistered ports were hard coded differently in each driver. This patch introduces Neutron configuration options for those listed IGMP features. As part of this work, default values in the IGMP snooping configuration had to be changed for the ML2/OVS backend. Please check in the following sections for more details.

New Features

  • Support for new service role is added to the Neutron API policies as part of the Secure-RBAC initiative. This new role is designed to be used for the service-to-service communication.

  • A new OVN driver Northbound DB column has been added to allow configuring gateway port for NAT rule. If the OVN backend supports the gateway_port column in the Northbound DB NAT table, the gateway port uuid will be configured to any floating IP to prevent North/South traffic issues. Previously created FIP rules will be updated only once during the maintenance task to include the gateway_port reference (if OVN backend supports it). In case all FIP entries are already configured no maintenance action will be performed.

  • Neutron allows users to create routers with flavors with the L3 OVN plugin. This new feature can be configured in the neutron.conf file. Please see the “Creating a L3 OVN router with a user defined flavor” section under Neutron configuration in the documentation for more details. This document also describes the steps users have to take to create a router with a flavor assigned to it.

  • A new policy rule check rule_default_sg has been added. This rule allows to check if a security group rule belongs or not to the project default security group. The administrator can override the rule creation and rule deletion, disallowing a non-privileged user from these actions.

  • Add enable_default_route_bfd and enable_default_route_ecmp configuration options which control default behavior for enabling BFD and ECMP on default routes for newly created routers. Both configuration options have a default value of ‘False’ and are only supported with the OVN driver.

  • A new config option enable_signals has been added to neutron.conf to control whether neutron-server registers signal handlers or not (like SIGTERM, etc). The default value for this new option is True to mimic the original behavior of registering signal handlers. The recommendation is to set this option to False when neutron-server is running behind a WSGI server, because in that situation the signals are taken over by the WSGI server and neutron will print a stack trace letting us know that signals cannot be registered.

  • A new ovn-cms-options option called enable-chassis-as-extport-host is now recognized by ML2/OVN and is used to identify nodes that are eligible for scheduling OVN’s external ports. This feature is backward compatible and if no nodes contain this new option the external ports will continue to be scheduled using the enable-chassis-as-gw option as before. This change also introduces a limit to the number of members for each HA Chassis Group to 5, matching the limit of gateway router port replicas. This is because OVN uses BFD to monitor the connectivity of each member and having an unlimited number of members could potentially put a lot of stress in OVN.

  • New configuration options for IGMP were added in the [OVS] section: igmp_flood, igmp_flood_reports and igmp_flood_unregistered. This gives operators full control on how IGMP should be configured for their deployments.

  • Remote address group support was added to the iptables-based firewall drivers (IptablesFirewallDriver and OVSHybridIptablesFirewallDriver), Previously it was only available in the OVSFirewallDriver. For more information, see bug 2058138.

  • Support for PXE baremetal provisioning using OVN’s built-in DHCP server has been added for IPv6.

  • Added support for the external-gateway-multihoming API extension. The L3 service plugins supporting it can now create multiple gateway ports per router. At the time of writing this is limited to the OVN L3 plugin.

  • Enabled the ha API extension for OVN routers. Now the high availability flag ha can be set and read for OVN routers. NOTE: currently OVN routers are always HA; the flag is mandatory and cannot be unset (but now can be read).

  • IPv6 Metadata support was added to the ML2/OVN driver. The agent now provisions the fe80::a9fe:a9fe/128 address to the OVN metadata namespace and makes haproxy listen on it to serve metadata requests to instances over IPv6.

  • OVN routers now expose the “distributed” flag depending on the configuration option enable_distributed_floating_ip. Because this is a common configuration option, all routers will expose the same value. This value can flap if the Neutron API is restarted and the configuration option changes. NOTE: Once the RFE that allows us to define the distributed flag per floating IP address is implemented in ML2/OVN, this flag will be useless (no Launchpad bug has been created yet for this RFE, that is only a proposed idea during several PTGs).

  • Removed support for OVN versions under 20.09. The “Chassis_Private” OVN Southbound table is expected in the database definition.

  • Introduce the attribute hardware_offload_type to ports, that specifies the hardware offload type this port will request when attached to the network backend.

    Operators can turn on this feature via the configuration option:

    [ml2]
extension_drivers = port_hardware_offload_type

  • Added the tags policies for the following resources: network, subnet, port, router, floating IP, network segment, network segment range, security group and security group rule. The policies control the creation, the update and the deletion of the resource tags.

  • In OVN 22.09 the option localnet_learn_fdb was added, enabling localnet ports to learn MAC addresses and store them at the FDB table. There was no aging mechanism for those MACs until OVN 23.06, where the configuration option fdb_age_threshold was added. This enables to set the maximum time the learned MACs will stay in the FDB table (in seconds). When the localnet_learn_fdb configuration option is enabled, the proper value for fdb_age_threshold should also be set, to avoid performance/scalability issues due to the table growing too much – especially when provider networks are large. In addition the configuration option fdb_removal_limit was also added to avoid removing a large number of entries at once.

  • MAC address aging in the OVN ML2 mech driver is now supported and can be configured globally with the new [ovn] mac_binding_age_threshold and [ovn_nb_global] mac_binding_removal_limit configuration options. Setting the value per-router is not currently supported. This feature is available in OVN versions >= 22.09.0+. Previous versions will ignore the new options.

  • Neutron now sets different process titles for RPC workers (‘rpc worker’) and RPC reports worker (‘rpc reports worker’) so that these two types of workers can be distinguished.

Known Issues

  • The fix of bug 2048785 only fixes newly created trunk parent ports. If the fix of already existing trunks is needed, then either delete and re-create the affected trunks or set tpt ports’ vlan_mode and tag manually: ovs-vsctl set Port tpt-... vlan_mode=access tag=0

Upgrade Notes

  • Starting with OVN version v21.12.0, OVN replies to ARP requests for ports that are in a DOWN status. It does not reply in versions older than v21.12.0. In order to keep the same behavior in Neutron, the default OVN behavior is overridden by Neutron and Neutron ports will no longer reply to ARP packets if the ports are in a DOWN state. If it is required to reply to ARP for such ports, the config option ignore_lsp_down from [ovn_nb_global] section can be set to True in the Neutron config. It is set to False by default.

  • Now setting [DEFAULT] rpc_workers = 0 completely disables rpc workers. In a deployment with additional agents, like the dhcp-agent, this option should be set to a positive value. Note that all notifications from neutron-server to agents were disabled when [DEFAULT] rpc_workers = 0 is set in 22.0.0 release, so this was the requiremenet actually added in that release.

  • In order to make IGMP configuration consistent across drivers some defaults had to be changed for ML2/OVS. This change did not affect the defaults in the ML2/OVN driver.

    If ML2/OVS is used and igmp_snooping_enable is enabled, in order to make the IGMP related traffic run as before please ensure that the following configuration options are enabled after the upgrade.

    [OVS]/igmp_flood_unregistered = True [OVS]/igmp_flood = True [OVS]/igmp_flood_reports = True

  • The [DEFAULT] api_workers option no longer accepts 0 or negative values. Previously 0 or a negative value was translated to 1 and neutron-server launched 1 api worker.

  • The [DEFAULT] rpc_workers option and the [DEFAULT] rpc_state_report_workers option no longer accept negative values. To disable these workers, set these options to 0.

  • Any “Logical_Router_Port” with a gateway chassis named “neutron-ovn-invalid-chassis” will be updated and this chassis will be deleted. An unhosted (unbound) “Logical_Router_Port” will have no gateway assigned.

  • The [agent] veth_mtu parameter of ML2 OVS mechanism driver configuration has been removed. This parameter has had no effect since the Wallaby release.

  • The following parameters in the designate section have been removed.

    • admin_username

    • admin_password

    • admin_tenant_id

    • admin_tenant_name

    • admin_auth_url

  • Remove [DEFAULT] ovs_integration_bridge configuration option, which was deprecated in the ‘Ussuri’ release, as it was a duplicate of [OVS] integration_bridge.

  • The [DEFAULT] segment_mtu configuration option has been removed. It was replaced by the [DEFAULT] global_physnet_mtu option in the Mitaka release.

  • The process title for RPC reports worker has been changed from ‘rpc worker’ to ‘rpc reports worker’. Please update any external scripts or services which look up the process title accordingly.

Deprecation Notes

  • Old role advsvc used in the Neutron API policies is now deprecated. New service role should be used for service-to-service communication.

Bug Fixes

  • Fixes L3 OVN schedulers (chance, leastloaded) to distribute Logical Router Port (LRP) gateways among all eligible AZs (if any). For more information, see bug 2030741

  • [bug 2052484] Now setting [DEFAULT] rpc_workers = 0 completely disables rpc workers. Previously one rpc worker was launched even though 0 is specifically requested.

  • Fixed the scenario where the DHCP agent is deployed in conjunction with the OVN metadata agent in order to serve metadata for baremetal nodes. In this scenario, the DHCP agent would not set the route needed for the OVN metadata agent service resulting in baremetal nodes not being able to query the metadata service. For more information see bug 1982569.

  • [bug 2036423] Now it is not possible to delete a subnet gateway IP if that subnet has a router interface; the subnet gateway IP modification was already forbidden.

  • The Neutron API has been changed to validate network MTU minimums. A network’s MTU is now only valid if it is the minimum value allowed based on the IP version of the associated subnets, 68 for IPv4 and 1280 for IPv6.

    This minimum is now enforced in the following ways:

    • When a subnet is associated with a network, validate the MTU is large enough for the IP version. Not only would the subnet be unusable if it was allowed, but the Linux kernel can fail adding addresses and configuring network settings like the MTU.

    • When a network MTU is changed, validate the MTU is large enough for any currently associated subnets. Allowing a smaller MTU would render any existing subnets unusable.

    See bug 1988069 for more information.

  • When synchronizing the OVN databases, either when running the migration command or during startup, the code responsible for synchronization will only clean up segment-to-host mappings for hosts with agent_type OVN Controller agent. Before, the synchronization would clean up (delete) segment-to-host mappings for non-OVN hosts. Fixes bug: 2040172.

  • [bug 2045889] The ports bound to ML2/OVN now contain the OVS bridge name and datapath type in the VIF details dictionary. NOTE: in the ML2/OVS to ML2/OVN migration, the local host OVN bridge (integration bridge) per port is not known; “br-int” will be used by default (that value is rarely changed).

  • During the port bulk creation, if an IPAM allocation fails (for example, if the IP address is outside of the subnet CIDR), the other IPAM allocations already created are deleted before raising the exception. Fixes bug 2039550.

  • [bug 2036705] The Neutron port.status field (“ACTIVE”, “DOWN”) is now set based on the ML2/OVN Logical Switch Port up and enabled flags. The user can now set the port.admin_state_up, that is replicated in the lsp.enabled flag, to enable or disable the port. If the port is disabled, the traffic is stopped and the port.status is set to “DOWN”.

  • In previous versions, an administrator was allowed to update a port binding:vnic_type attribute even if it was bound. This is now blocked and the update operation of the attribute returns the Conflict (409) response code.

Other Notes

  • When the following configuration is enabled at the same time:

    • OVN L3 service plugin (ovn-router)

    • Port forwarding service plugin (port_forwarding)

    • “vlan” or “flat” network types configured in the ML2 configuration variable tenant_network_types

    • The OVN floating IP traffic is distributed (enable_distributed_floating_ip = True)

    the Neutron server will report a warning during plugin initialization because this is an invalid configuration matrix. Floating IPs need to always be centralized in such a case. For more details see bug report.

  • The new value for ‘device_owner’ for OVN loadbalancer health monitor ports (ovn-lb-hm:distributed) is now supported by Neutron, providing a LOCALPORT behavior to these ports. The responsibility to define these ports with the new value instead of the old one (network:distributed) is under the OVN-Octavia Provider driver, which will take care of database conversion for these ports.

  • Added extension subnetpool-prefix-ops to the ML2/OVN mechanism driver.

  • The artifact of creating a gateway chassis called “neutron-ovn-invalid-chassis” when a “Logical_Router_Port” cannot be assigned to any chassis is removed. Now no gateway chassis is created and the “Logical_Router_Port” field will be empty.

  • The OVN L3 scheduler will now update lower priorities of exising LRPs in case of a chassis change. This can create increased load on OVN during chassis shutdown, but improves the load distribution of LRPs.