2023.1 Series Release Notes

2023.1-eom

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.

22.2.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.

New Features

• 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.

• 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.

• 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.

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

• In ML2/OVN, any new router gateway port (OVN logical router port) will be scheduled only on those chassis configured as gateway. Any existing router gateway port will preserve the current chassis assignation.

Bug Fixes

• The config option agent_down_time is now limited to a maximum value of 2147483, as neutron-server will fail to start if it is configured higher. See bug 2028724 for more information.

• [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.

• 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).

• [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”.

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.

22.1.0

Known Issues

• When using ML2/OVN, during an upgrade procedure, the OVS system-id stored value can be changed. The ovn-controller service will create the “Chassis” and “Chassis_Private” registers based on this OVS system-id. If the ovn-controller process is not gracefully stopped, that could lead to the existence of duplicated “Chassis” and “Chassis_Private” registers in the OVN Southbound database.

Bug Fixes

• [bug 2022914] Neutron-API supports using relays as the southbound connection in a ML2/OVN setup. Before the maintenance worker of the API required a leader_only connection, which was removed.

• 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.

• For OVN versions v22.09.0 and above, the mcast_flood_reports option is now set to false on all ports except “localnet” types. In the past, this option was set to true as a workaround for a bug in core OVN multicast implementation.

• 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.

• A new OVN maintenance method remove_duplicated_chassis_registers is added. This method will periodically check the OVN Southbound “Chassis” and “Chassis_Private” tables looking for duplicated registers. The older ones (based on the “Chassis_Private.nb_cfg_timestamp” value) will be removed when more than one register has the same hostname, that should be unique.

Other Notes

• The external_mac entry in the NAT table is used to distribute/centralize the traffic to the FIPs. When there is an external_mac set the traffic is distributed (DVR). When it is empty it is centralized through the gateway port (no DVR). Upon port status transition to down, the external_mac was removed regardless of DVR being enabled or not, leading to centralize the FIP traffic for DVR – though it was for down ports that won’t accept traffic anyway.

• Adds a maintenance task that runs once a day and is responsible for cleaning up Hash Ring nodes that haven’t been updated in 5 days or more. See LP #2033281 for more information.

• Added the missing extension uplink-status-propagation to the ML2/OVN mechanism driver. This extension is used by the ML2/SR-IOV mechanism driver, that could be loaded with ML2/OVN. Now it is possible to create ports with the “uplink-status-propagation” flag defined.

• A ML2/OVN virtual port cannot be bound to a virtual machine. If a port IP address is assigned as an allowed address pair into another port, the first one is considered a virtual port. If the second port (non-virtual) is bound to ML2/OVN, the virtual port cannot be bound to a virtual machine; a virtual port is created only to reserve a set of IP addresses to be used by other ports. The OVN mechanism driver prevents that a virtual port has a device ID; a device ID is provided when the port is being bound.

22.0.1

Known Issues

• The high availability of metadata service on isolated networks is limited or non-existent. IPv4 metadata is redundant when the DHCP agent managing it is redundant, but recovery is tied to the renewal of the DHCP lease, making most recoveries very slow. IPv6 metadata is not redundant at all as the IPv6 metadata address can only be configured in a single place at a time as it is link-local. Multiple agents trying to configure it will generate an IPv6 duplicate address detection failure.

  Administrators may observe the IPv6 metadata address in “dadfailed” state in the DHCP namespace for this reason, which is only an indication it is not highly available. Until a redesign is made to the isolated metadata service there is not a better deployment option. See bug 1953165 for information.

• The redirect-type=bridged option is only used if all the tenant networks connected to the router are of type VLAN or FLAT. In this case their traffic will be distributed. However, if there is a mix of VLAN/FLAT and geneve networks connected to the same router, the redirect-type option is not set, and therefore the traffic for the VLAN/FLAT networks will also be centralized but not tunneled.

Bug Fixes

• 1986003 Fixed an issue with concurrent requests to activate the same port binding where one of the requests returned a 500 Internal Server Error. With the fix one request will return successfully and the other will return a 409 Conflict (Binding already active). This fixes errors in nova live-migrations where those concurrent requests might be sent. Nova handles the 409/Conflict response gracefully.

• Fix an issue in the OVN driver where network metadata could become unavailable if the metadata port was ever deleted, even if accidental. To re-create the port, a user can now disable, then enable, DHCP for one of the subnets associated with the network using the Neutron API. This will try and create the port, similar to what happens in the DHCP agent for ML2/OVS. For more information, see bug 2015377.

• [bug 2003455] As part of a previous commit (https://review.opendev.org/c/openstack/neutron/+/875644) the redirect-type=bridged option was set in all the router gateway ports (cr-lrp ovn ports). However this was breaking the N/S traffic for geneve tenant networks connected to the provider networks through those routers with the redirect-type option enabled. To fix this we ensure that the redirect-type option is only set if all the networks connected to the router are of VLAN or FLAT type, otherwise we fall back to the default option. This also means that if there is a mix of VLAN and geneve tenant networks connected to the same router, the VLAN traffic will be centralized (but not tunneled). If the traffic for the VLAN/FLAT needs to be distributed, then it should use a different router.

23.0.0.0b1

New Features

• Address scope is now added to all OVN LSP port registers in the northbound. Northd then writes the address scope from the northbound to the southbound so it can be used there by the ovn-bgp-agent.

• Manila owned ports can now have multiple port bindings associated in order to support nondisruptive Manila share server migration across physical networks.

• Extend routed provider networks to allow provisioning more than one segment per physical network.

• Introducing clean_devices, a new DHCP driver’s API that can be called to clean stale devices.

• Added a new agent: the OVN Agent. This new agent will run on a compute or a controller node using OVN as network backend, similar to other ML2 mechanism drivers as ML2/OVS or ML2/SRIOV. This new agent will perform those actions that the ovn-controller service cannot execute. The agent functionality will be plugable and added via configuration knob.

• Added a new OVN Neutron Agent extension: QoS for hardware offloaded ports. This extension will enforce the minimum and maximum bandwidth egress QoS rules for ports with hardware offload (DevLink ports). This extension uses the “ip-link” commands to set the “ceil” and “rate” parameters on the corresponding virtual functions.

• ML2/OVS and ML2/OVN now support modelling tunnelled networks in the Placement API. The “tunnelled_network_rp_name” configuration option defines the resource provider name used to represent all tunnelled networks in a compute node (by default “rp_tunnelled”). If this string is present in the “resource_provider_bandwidths” dictionary, the corresponding mechanism driver will create a resource provider for the overlay traffic.

• Neutron now supports API policies with the new default roles project_member and project_reader. Role admin is working in the same way as with old policies.

Known Issues

• Until the OVN bug (https://bugzilla.redhat.com/show_bug.cgi?id=2162756) is fixed, setting the “reside-on-redirect-chassis” to true for the logical router port associated to vlan provider network is needed. This workaround makes the traffic centrallized, but not tunneled, through the node with the gateway port, thus avoiding MTU issues.

Upgrade Notes

• The default value for the metadata_workers configuration option has changed to 0 for the ML2/OVN driver. Since [OVN] Allow to execute “MetadataProxyHandler” in a local thread, the OVN metadata proxy handler can be spawned in the same process of the OVN metadata agent, in a local thread. That reduces the number of OVN SB database connections to one.

• The deprecated config option keepalived_use_no_track is removed.

• New default API policies are not enabled by default. A cloud operator can enable them by setting oslo_policy/enforce_new_defaults to true in the Neutron config file. It is also possible to switch the oslo_policy/enforce_scope config option to true but currently Neutron does not support any system scope APIs. All Neutron API policies are currently project scoped so setting oslo_policy/enforce_scope to true will cause Forbidden responses to any API calls made with the system scope token.

Deprecation Notes

• Config option allow_stateless_action_supported is deprecated to removal and will be removed in 2023.2 (Bobcat) release. This option will not be needed anymore as Neutron will not be supported to be run with OVN < 21.06.

Bug Fixes

• 1996677 When the fixed_ips of metadata port is modified, the ip address of tap device in metadata agent is modified.

• [bug 2003455] It is added an extra checking to ensure the “reside-on-redirect-chassis” is set to true for the logical router port associated to vlan provider network despite having the “ovn_distributed_floating_ip” enabled or not. This is needed as there is an OVN bug (https://bugzilla.redhat.com/show_bug.cgi?id=2162756) making it not work as expected. Until that is fixed, we need these workaround that makes the traffic centrallized, but not tunneled, through the node with the gateway port, thus avoiding MTU issues.

• Normalise OVN agent heartbeat timestamp format to match other agent types. This fixes parsing of GET /v2.0/agents for some clients, such as gophercloud.

• Neutron can record full connection using log-related feature introduced in OVN 21.12. For more info see bug LP#<https://bugs.launchpad.net/neutron/+bug/2003706>

Other Notes

• Since OVN 20.06, the “Chassis” register configuration is stored in the “other_config” field and replicated into “external_ids”. This replication is stopped in OVN 22.09. The ML2/OVN plugin tries to retrieve the “Chassis” configuration from the “other_config” field first; if this field does not exist (in OVN versions before 20.06), the plugin will use “external_ids” field instead. Neutron will be compatible with the different OVN versions (with and without “other_config” field).

• OVN mechanism driver has now got config option allow_stateless_action_supported which allows manually disable stateful-security-group API extension in case when OVN older than 21.06 is used because support for allow-stateful action in OVN’s ACL was added in OVN 21.06. By default this option is set to True so stateful-security-group API extension is enabled. If this option is set to True and OVN < 21.06 is used, Neutron will fallback to the statefull ACLs even if SG is set to be stateless in Neutron database.

• The ProcessManager class will now, by default, add an environment variable when starting a new process. This default tag is named “PROCESS_TAG” and will contain a unique identifier for this specific process. It could be used, for example, by TripleO to univocally tag any new container spawned and find it using the same tag.

21.0.0.0rc1

Prelude

Introduce the experimental features framework.

New Features

• Some Neutron features are not supported due to lack of resources or technical expertise to maintain them. As they arise, those features will be marked as experimental by the Neutron core team. Deployers will be able to continue using experimental features by explicitly enabling them in the ‘experimental’ section of neutron.conf. The ML2 linuxbridge driver is the first feature to be marked as experimental. To continue using it, deployers have to set to True the ‘linuxbridge’ option in the ‘experimental’ section of neutron.conf.

• Add support for port ranges in the port forwarding rules. The supported ranges are N:M with N <= M. Also, the ranges of internal and external ports relation must be: internal range = external range or internal range = 1.

• After the port is considered as provisioned, the Nova port binding update could have not been received, leaving the port as not bound. Now the port provisioning method has an active wait that will retry several times, waiting for the port binding update. If received, the port status will be set as active if the admin state flag is set.

• Support for IPv6 NDP proxy has been added. Read the related specification for more details.

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

• Added support for QoS minimum bandwidth rules (egress only) in ML2/OVN. OVN supports setting these rule types in the logical switch ports since release 22.06.0.

• OVN mechanism driver refuses to bind a port to a dead agent.

• Core OVN now can set the destination host on the logical switch port during a live migration. That allows to prepare the destination host earlier, achieving a quicker live migration and a lower downtime during the switch between hosts. Neutron includes this information in the port options.

• Added support for router gateway IP QoS in OVN backend. The L3 OVN router plugin now can apply router QoS policy rules on the router gateway port.

• Ovn configuration items “ovn_nb_connection” and “ovn_sb_connection” can set multiple addresses separated by commas. Setting NB/SB “connection” inactivity probe can also work well, if multiple connection be specified.

• Added a new configuration variable, in [OVS] section, to control the OVS OpenFlow rule processing operations when using the OVS native firewall driver (securitygroup.firewall_driver=openvswitch):

  • openflow_processed_per_port: by default “False”. If enabled, all OpenFlow rules associated to a port will be processed at once, in a single transaction. If disabled, the flows will be processed in batches of “AGENT_RES_PROCESSING_STEP=100” number of OpenFlow rules.

• If uplink-status-propagation extension is enabled, all existing ports before enabling it will have the flag “propagate_uplink_status” enabled by default. This is aligned with the aim of an administrator that enables this extension. Now only new ports can be created with this flag disabled.

• Gateway IP QoS network inheritance is now available for OVN L3 plugin QoS extension. If the router external network (gateway network) has a QoS policy associated, the gateway IP port will inherit the network QoS policy.

• QoS rule type list accepts two filter flags:

  • all_supported: if True, the listing call will print all QoS rule types supported by at least one loaded mechanism driver.

  • all_rules: if True, the listing call will print all QoS rule types supported by the Neutron server.

  Both filter flags are exclusive and not required.

• Enabled DbQuotaDriverNull as production ready database quota driver. This driver does not have access to the database and will return empty values to the request queries. This driver can be used to override the Neutron quota engine.

• 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. It is important to remark that this script should not be executed during any live migration process.

• Add use_random_fully setting to allow an operator to disable the iptables random-fully property on an iptable rules.

Known Issues

• If the use_random_fully setting is disabled, it will prevent random fully from being used and if there’re 2 guests in different networks using the same source_ip and source_port and they try to reach the same dest_ip and dest_port, packets might be dropped in the kernel do to the racy tuple generation . Disabling this setting should only be done if source_port is really important such as in network firewall ACLs and that the source_ip are never repeating within the platform.

Upgrade Notes

• Previously deprecated configuration option allow_overlapping_ips is now removed.

• Python 3.6 & 3.7 support has been dropped. The minimum version of Python now supported is Python 3.8.

• A new configuration option called [ovn]/disable_ovn_dhcp_for_baremetal_ports has been added to ML2/OVN for IPv4. Since PXE booting nodes can be very sensitive depending on the hardware and some operators may prefer to use a fully-fledged DHCP server instead of OVN’s DHCP server this option allows for disabling OVN’s built-in DHCP server for baremetal ports (vnic type “baremetal”) when set to True. It defaults to False.

• The live_migration_events configuration option is removed. Now Neutron assumes this flag is always set. This configuration option depended on the Nova patch only wait for plugtime events in pre-live-migration.

Deprecation Notes

• The ML2 linuxbridge agent has been marked as experimental due to lack of resources to maintain it. To continue using it, deployers have to set to True the ‘linuxbridge’ option in the ‘experimental’ section of neutron.conf

Bug Fixes

• 1942329 Port binding logic for direct-physical ports has been extended to allow providing the MAC address of the physical device via the binding profile. If it is provided then Neutron overwrites the value of the device_mac_address field of the port object in the database with the value from the active binding profile. If there are ports bound before the nova side of this fix is depolyed then the VM using the port needs to be moved or the port needs to be detached and re-attached to force nova to provide the MAC address of the direct-physical port in the port binding.

• Forbid the creation of a duplicate NDP proxy entry on the same router, since the IP address of a router is unique and an IPv6 address only needs one NDP proxy.

• Fixes an issue in the ML2/OVN driver where the network segment tag was not being updated in the OVN Northbound database. For more information, see bug 1944708.

Other Notes

• The OVN migration performs validation by default. This validation means an instance is spawned and is tested by simple ping after the migration is finished. Also it tries to create new workload post migration. This is useful for very simple scenarios when migration is tested but is not really useful in production since likely the production envrionments already have running workloads. It makes more sense to require the validation explicitly rather than implicitly run it as the migration is mostly intended for production. The VALIDATE_MIGRATION now defaults to False and needs to be changed to True if validation upon request.

• From now on, gateway interface will be kept up on all nodes where HA router is hosted, regardless of their state (active or standby). For more information see bug 1952907.

• OVN driver reverted to using stateful NAT for floating IP implementation. The previous switch to stateless didn’t materialize the expected performance benefits and instead introduced problems with potential hardware offloading.

20.0.0.0rc1

New Features

• Add the shared field to security group API responses and support using shared as a query filter. For more information see bug 1942615.

• Neutron now supports the placement enforcement for the guaranteed minimum bandwidth QoS rule type with direct-phyisical vnic_type as well. The data plane enforcement of such rule and vnic_type combination is still not supported.

• Add request_body field to router callback event payloads. The field record the origin request body from user.

• Add BEFORE_UPDATE callback event for router gateway.

• Local IP - a virtual IP that can be shared across multiple ports/VMs (similar to anycast IP) and is guaranteed to only be reachable within the same physical server/node boundaries. The feature is primarily focused on high efficiency and performance of the networking data plane for very large scale clouds and/or clouds with high network throughput demands.

• Added two new API methods to QuotaDriverAPI class. get_resource_usage returns the current resource usage. quota_limit_check checks the current resource usage of several resources against a set of deltas (a dictionary of resource names and resource counters).

• Add support for VNIC type remote-managed in OVN. The OVN driver can now bind remote managed ports to SmartNIC DPUs. SmartNIC DPU portbinding requires OVN version 21.12 or above, compiled with OVN VIF version 21.12 or above.

• Since this version, the support for stateless security groups is mandatory. The minimum OVN NB schema version must be 5.17.

• Virtual ports are supported in OVN since version 2.12. Since Yoga, this support is mandatory. The minimum OVN SB schema version must be 2.5.

• Report packet processing capacity on the OVS agent resource provider as the new NET_PACKET_RATE_KILOPACKET_PER_SEC, NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC or NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC resource inventory. This is similar to how the bandwidth resource is reported today. The former is used for non-hardware-offloaded OVS deployments, where packets processed from both ingress and egress directions are handled by the same set of CPU cores. Remaining inventories are used for hardware-offloaded OVS, where the incoming and outgoing packets are handled by independent hardware resources.

• Added port-resource-request-groups API extension, that provides support for the new format of port’s resource_request and binding:profile.allocation attributes. The new format allows to request multiple groups of resources and traits from the same RP subtree.

  Assigning a new QoS policy with minimum_packet_rate rule to an already bound port updates the allocation in Placement. NOTE: Placement allocation update is not supported if original QoS policy had no minimum_packet_rate rule. Changing from direction-less minimum_packet_rate rule to a direction-oriented minimum_packet_rate rule is not supported.

• New configuration options for neutron-ovs-agent under section [ovs]: resource_provider_packet_processing_without_direction, resource_provider_packet_processing_with_direction and resource_provider_packet_processing_inventory_defaults. resource_provider_packet_processing_without_direction controls the minimum packet rate the OVS backend can guarantee in kilo (1000) packet per second. resource_provider_packet_processing_with_direction is similar to the first option, but used in case the OVS backend has hardware offload capabilities. The last option can be used to tune the other fields (allocation_ratio, min_unit, max_unit, reserved, step_size) of resource provider inventories.

• Floating IP QoS network inheritance is now available for OVN L3 plugin QoS extension. If a network, hosting a floating IP, has a QoS associated, the floating IP addresses will inherit the network QoS policy and will apply on the OVN backend.

• Added qos-pps-minimum-rule-alias API extension to enable GET, PUT and DELETE operations on QoS minimum packet rate rule without specifying policy ID.

• Enabled placement enforcement for QoS minimum packet rate rule in OVS backend.

• Added new API extension to QoS service plugin to support CRUD operations for minimum packet rate rule in Neutron server.

• Added a check to verify if all rows of ml2_port_bindings table in the DB are using the new format for profile column. This check is part of upgrade check, that can be executed with neutron-status upgrade check command. If some rows are using obsolete format, they can be sanitized with a script that can be executed with neutron-sanitize-port-binding-profile-allocation command.

Upgrade Notes

• A unique constraint for (network_id, network_type, physical_network) is added to the networksegments table. This was done to prevent race conditions on dynamic segment allocation. Operators having networks with multiple segments (e.g. when using hierarchical portbinding) should check that this constraint is not violated with the included upgrade-check.

Deprecation Notes

• Config option allow_overlapping_ips is deprecated for removal now. Default value for that option is now changed to the True in the default IPAM module of Neutron, as the only reason it was defaulting to False was to keep compatibility with Nova security group code that was removed already. The config option itself will removed in the Z release.

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

Bug Fixes

• Changes the API behaviour while using OVN driver to enforce that it’s not possible to delete all the IPs from a router port. For more info see bug LP#1948457

• Support for the extensions dns_domain_ports and subnet_dns_publish_fixed_ip belonging to the DNS integration is now properly announced by the OVN driver. See bug 1947127

• For IPv4 subnets when dns_nameservers is not set in the subnet, servers defined in ‘ovn/dns_servers’ config option or system’s resolv.conf are used, but for IPv6 subnets these are not used. The same will now be used for IPv6 subnets too. Additionally dns servers added in ‘ovn/dns_servers’ config option or system’s resolv.conf will be filtered as per the subnet’s IP version. For more info see the bug report 1951816.

• Fixes bug 1943724.

• The agent reporting state to the server now uses a RPC timeout set to the report_interval configuration option value. See 1948676.

Other Notes

• Abstract method plug_new from the neutron.agent.linux.interface.LinuxInterfaceDriver now has additional positional argument link_up. Usage of this method without link_up is now not possible. Third-party drivers which inherit from this base class now have to update the implementation of their plug_new method.

• Class “PortBindingMixin” is removed. Last time this class was used in-tree was in Kilo release, in “N1kvNeutronPluginV2” and “SdnvePluginV2” classes. No active project is using it anymore. Table “portbindingports” is dropped from the database; it was used only in “PortBindingMixin”.

• Any L3 agent extension must inherit from neutron_lib.agent.l3_extension.L3AgentExtension. The L3AgentExtensionsManager makes this check during the initial loading. A L3ExtensionException will be raised if the condition is not met.

• New service plugin and openvswitch agent extension could be configured in order to enable Local IP feature: local_ip

• OVN mechanism driver allows only to have one physical network per bridge.

• It is assumed now that OVN supports Northbound table Port_Group by default. This table was added in the DB schema version 5.11. A sanity check is included if OVN is defined in ml2.mechanism_drivers configuration option.

• OVN driver now uses stateless NAT for floating IP implementation. This allows to avoid hitting conntrack, potentially improving performance and also allowing to offload NAT rules to hardware.

19.0.0.0rc1

New Features

• When noauth auth_strategy is used, neutron no longer requires a resource creation request to include a dummy ‘project_id’ in request body. A default project_id fake_project_id would be populated automatically in that case and would make the use of noauth usage simpler.

• Neutron supports creating IPv4 subnet with prefixlen /31 and /32, via disabling dhcp on a subnet. For more information, see bug 1580927.

• Added a new OVS agent extension dhcp to support distributed DHCP for VMs in compute nodes directly. To enable this just set extensions=dhcp to OVS agent config file under [agent] section. We also add a new config section [dhcp] which has options enable_ipv6 = True/False for indicating whether enable the DHCPv6 for VM ports.

• Special keywords <project_id>, <project_name>, <user_name> and <user_id> can be used in the network’s, port’s and floating IP’s dns_domain attribute. Those special keywords will be replaced by the corresponding data from the request context. With that cloud admin can define dns_domain for shared network and ports which belongs to the other projects in the way that each project can use separate DNS zones which needs to be pre-created by users. To enable this feature dns_domain_keywords ML2 plugin extension has to be enabled in the Neutron config. Enabling multiple dns_integration extensions at the same time leads to an error.

• Neutron supports ECMP routes now, with this change, neutron will consolidate multiple routes with the same destination address into a single ECMP route. For more information see bug 1880532.

• A new quota driver is added: DbQuotaNoLockDriver. This driver, unlike DbQuotaDriver, does not create a unique lock per (resource, project_id). That may lead to a database deadlock state if the number of server requests exceeds the number of resolved resource creations, as described in LP#1926787. This driver relays on the database transactionality isolation and counts the number of used and reserved resources and, if available, creates the new resource reservations in one single database transaction.

• Adds support for Network Availability Zones to the OVN driver. When Network AZ is used, OVN’s “external” ports will now be scheduled onto nodes belonging to the AZs specified in the network that the port belongs to. This feature also removes the limitation where all “external” ports were part of to a single HA Chassis Group (meaning they would all be bond to a single host) now the “external” ports will be better distributed across different hosts.

• Support stateless security groups with the latest OVN 21.06+. The stateful=False security groups are mapped to the new “allow-stateless” OVN ACL verb.

• Added new API extension to QoS service plugin to support CRUD actions for packet rate limit (packet per second) rule in Neutron server side.

• The port.mac_address field is sanitized to have a common format “xx:xx:xx:xx:xx:xx”. The values stored in the database can be sanitized executing the new script provided neutron-sanitize-port-mac-addresses. This script will read all port registers and fix, if needed, the stored MAC address format. The port API is also modified to sanitize the user input. This change was added to neutron-lib 2.12.0 in 788300.

• SR-IOV agent now can handle ports from different networks with the same MAC addresses. This feature implies an upgrade in the agent and the server RPC version (see neutron.plugins.ml2.rpc.RpcCallbacks version 1.9). Some agent RPC methods have been updated to pass not only the device MAC address but the PCI slot too. In case of having more than one port with the same MAC address, the PCI slot will discriminate the requested port.

• Reject any router route or gateway update if not all route nexthops have connectivity with any gateway subnets CIDRs; in other words, all route nexthops IP addresses should belong to one gateway subnet CIDR.

Known Issues

• When using the minimim-bandwidth QoS feature due to bug https://launchpad.net/bugs/1921150 physical NIC resource providers were for some time created with the wrong parent (i.e. the hypervisor RP). This is now partially fixed and new resource providers are created now with the expected parent (i.e. the agent RP). However Placement does not allow re-parenting an already existing resource provider, therefore the following Placement DB update may be needed after the fix for bug 1921150 is applied: neutron/tools/bug-1921150-re-parent-device-rps.sql Until all resource providers have the proper parent, neutron-server will retry the re-parenting update, which will be rejected every time, therefore expect polluted logs and some wasted load on Placement. However please note that the bandwidth-aware scheduling is supposed to work even with the wrongly parented resource providers.

• When using Linux Bridge mechanism driver in newer operating systems that use nftables by default, it is needed to switch back to the legacy tool, as documented in the admin documentation for Linux bridge mechanism driver.

Upgrade Notes

• The way the ML2 plugin filters out API extensions which are not supported by loaded mechanism drivers has changed. Before, the API extension was on the list if at least one of the mechanism drivers supported it, but now the extension needs to be supported by all the mechanism drivers. If at least one of them filters it out, it will be removed from the final list of enabled API extensions. Currently, only the OVN mechanism driver is filtering out some of the ML2 API extensions, thus if that mechanism driver is loaded in Neutron with any other mechanism driver, the list of the enabled API extensions may be smaller than it was before.

• The configuration options for XenAPI support has been removed, because these options were already ineffective.

• Both the server and the agent RPC versions have been bumped to 1.9; to provide a smooth upgrade transition, the Upgrade Procedure should be followed, upgrading first the servers and then the agents. The agent RPC methods returned values are not modified to keep compatibility with other agents (Linux Bridge, Open vSwitch). The RPC server side is capable of attending calls from agent API < 1.9, in order to provide backwards compatibility. If the device PCI slot is not provided, the behavior will be the previous one.

Deprecation Notes

• The following parameters in the designate section have been deprecated and will be removed in a future release. The [designate] auth_type parameter and required keystoneauth parameters should be used instead.

  • admin_username

  • admin_password

  • admin_tenant_id

  • admin_tenant_name

  • admin_auth_url

Security Issues

• Fix bug 1939733 by dropping from the dhcp extra option values everything what is after first newline (\n) character before passing them to the dnsmasq.

Bug Fixes

• Report external dns service OverQuota exception as new neutron ConflictException (409) i.e. ExternalDNSOverQuota. Report the failure as “External DNS Quota exceeded for resources: recordset”.

• Ensures that OVN’s mechanism driver does not start when [ml2_type_geneve]/max_header_size is set below the required 38. LP#1868137

• 1926693 The logic to detect the hypervisor hostname, which was introduced by change 69660, has been fixed and now returns the result consistent with libvirt.

• Introduced config option for RPC agent step size customization: rpc_resources_processing_step - Number of resources for neutron to divide the large RPC call data sets. It can be reduced if RPC timeout occurred. Default value equals 20. The best value can be determined empirically in your environment.

• The new resource_provider_defualt_hypervisor option has been added, to replace the default hypervisor name to locates the root resource provider without giving a complete list of interfaces or bridges in the resource_provider_hypervisors option. This option is located in the [ovs] ini-section for ovs-agent and [sriov_nic] ini-section for sriov-agent.

Other Notes

• Neutron resource tags can now be 255 characters long, previously resource tags was limited to 60 characters.

18.0.0.0rc1

New Features

• Security group rule has now new, read only attribute normalized_cidr which contains network address from the CIDR provided in the remote_ip_prefix attribute. This new attribute shows actual CIDR used by backend firewall drivers.

• Support for network logging based on security groups added to OVN backend. For more information see bug 1914757.

• Now it is possible to define a gateway IP when creating a subnet using a subnet pool. If the gateway IP can be allocated in one of the subnet pool available subnets, this subnet is created; otherwise a Conflict exception is raised.

• A new subnet of type network:routed has been added. If such a subnet is used, the IPs of that subnet will be advertized with BGP over a provider network, which itself can use segments. This basically achieves a BGP-to-the-rack feature, where the L2 connectivity can be confined to a rack only, and all external routing is done by the switches, using BGP. In this mode, it is still possible to use VXLAN connectivity between the compute nodes, and only floating IPs and router gateways are using BGP routing.

• Added support for the vlan-transparent in the OVN mechanism driver.

• Introduce the attribute port_device_profile to ports that specifies the device profile needed per port. This parameter is a string. This parameter is passed to Nova and Nova retrieves the requested profile from Cyborg: Device profiles.

  Operators can turn on this feature via the configuration option:

  [ml2]
  extension_drivers = port_device_profile
  

• Neutron now experimentally supports new API policies with the system scope and the default roles (member, reader, admin).

• Added support in SR-IOV agent for accelerator-direct VNIC type. This type represents a port that supports any kind of hardware acceleration and is provided by Cyborg (https://wiki.openstack.org/wiki/Cyborg). RFE: 1909100. accelerator-direct-physical is still not supported.

• A new API resource address group and its CRUD operations are introduced to represent a group of IPv4 and IPv6 address blocks. A new option --remote-address-group is added to the security group rule create command to allow network connectivity with a group of address blocks. And the backend support is added to the openvswitch firewall. When IP addresses are updated in the address groups, changes will also be reflected in the firewall rules of the associated security group rules. For more information, see RFE: 1592028

• Add support for deleting ML2/OVN agents. Previously, deleting an agent would return a Bad Request error. In addition to deleting the agent, this change also drastically improves the scalability of the ML2/OVN agent handling code.

• Update of an already bound port with a QoS minimum_bandwidth rule with a new QoS policy with a minimum_bandwidth rule now changes the allocations in placement as well.

  Note

  Updating the minimum_bandwidth rule of a QoS policy that is attached to a port which is bound to a VM is still not possible.

• A new vnic type vdpa has been added to allow requesting port that utilize a vHost-vDPA offload. The ML2/OVS and ML2/OVN mech drivers now have support for the vHost-vDPA vnic type. vHost-vDPA is similar to vHost-user or kernel vhost offload but utilizes the newly added vDPA bus introduced in the Linux 5.7 kernel. vDPA interface can be implemented in software or hardware, when implemented in hardware they provide equivalent performance to SR-IOV or hardware offloaded OVS while providing two main advantages over both SR-IOV and hardware offloaded OVS. Unlike the alternatives, vHost-vDPA enables live migration of instance transparently and provides a standard virtio-net interface to the guest avoiding the need to install vendor specific drivers in the guest.

• OVN driver now supports VXLAN type for networks. This requires OVN version to be 20.09 or newer.

Known Issues

• Even with the “igmp_snooping_enable” configuration option stating that traffic would not be flooded to unregistered VMs when this option was enabled, the ML2/OVN driver didn’t follow that behavior. This has now been fixed and ML2/OVN will no longer flood traffic to unregistered VMs when this configuration option is set to True.

• Support for new policies and system scope context is experimentatal in Neutron. When config option enforce_new_defaults is enabled in Neutron, new default rules will be enforced and things may not work properly in some cases.

Upgrade Notes

• Address group now has standard attributes. In the alembic migration, the original description column of address_groups is dropped after data migrated to the standardattributes table. The description field is also removed from the address group object and DB model. This change requires a restart of neutron-server service after the DB migration otherwise users will get server errors when making calls to address group APIs.

• The default value of [oslo_policy] policy_file config option has been changed from policy.json to policy.yaml. Operators who are utilizing customized or previously generated static policy JSON files (which are not needed by default), should generate new policy files or convert them in YAML format. Use the oslopolicy-convert-json-to-yaml tool to convert a JSON to YAML formatted policy file in backward compatible way.

Deprecation Notes

• Use of JSON policy files was deprecated by the oslo.policy library during the Victoria development cycle. As a result, this deprecation is being noted in the Wallaby cycle with an anticipated future removal of support by oslo.policy. As such operators will need to convert to YAML policy files. Please see the upgrade notes for details on migration of any custom policy files.

• Deprecate keepalived_use_no_track config option, as keepalived version check is a safe source to decide if no_track can be used in keepalived configuration file.

• Removed XenAPI support in Neutron. This driver is no longer supported in Nova and Neutron. The configuration options have been marked as “deprecated for removal” and will be removed in X release.

• Old API policies are deprecated now. They will be removed in future.

Bug Fixes

• Stop sending agent heartbeat from ovs agent when it detects OVS is dead. This helps to alarm cloud operators that there is something wrong on the given node.

• Fixed a MAC learning issue when OVS offload is enabled. The OVS firewall reduces the usage of normal actions to reduce CPU utilization. This causes insertion of a flood rule because there is no MAC learning on ingress traffic. While this is okay for the non-offload case, when using OVS offload the flood rule is not being offloaded. This fixes the MAC learning in the offload case, so we avoid the flood rule. For more information, see bug 1897637.

• Fixes a configuration problem in the OVN driver that prevented external IGMP queries from reaching the Virtual Machines. See bug 1918108 for details.

Other Notes

• Added a new config option enable_traditional_dhcp for neutron server, if it is set to False, neutron server will disable DHCP provisioning block, DHCP scheduler API extension, network scheduling mechanism and DHCP RPC/notification. This option can be used with the dhcp extension of the OVS agent to enable distributed DHCP, or for a deployment which needs to disable the DHCP agent related functions permanently.

• To improve performance of the DHCP agent, it will no longer configure the DHCP server for every port type created in Neutron. For example, for floating IP or router HA interfaces there is no need since a client will not make a DHCP request for them

• The OVN Metadata Agent now creates the network namespaces including the Neutron network UUID in its name. Previously, the OVN datapath UUID was used and it was not obvious for operators and during debugging to figure out which namespace corresponded to what Neutron network.

• As defined in Migrate from oslo.rootwrap to oslo.privsep, all OpenStack proyects should migrate from oslo.rootwrap to oslo.privsep because “oslo.privsep offers a superior security model, faster and more secure”. This migration will end with the deprecation and removal of oslo.rootwrap from Neutron. To ensure the quality of the Neutron code, this migration will be done sequentially in several patches, checking none of them breaks the current functionality. In order to easily migrate to execute all external commands inside a privsep context, a new input variable “privsep_exec”, that defaults to “False”, is added to neutron.agent.linux.utils.execute. That will divert the code to a privsep decorated executor. Once the migration finishes, this new input parameter will be removed.

• When new default values for API policies are enabled, some API requests may not be available for project admin users anymore as they are possible only for system scope users. Please note that system scope tokens don’t have project_id included so for example creation of the provider network, with specified physical network details will now require from system scope admin user to explicitly set project_id.

17.0.0.0rc1

Prelude

Added support for floating IPs port forwarding in OVN.

New Features

• A new configuration option http_retries was added. This option allows configuring the number of times the nova or ironic client should retry on a failed HTTP call.

• New config option keepalived_use_no_track was added. If keepalived version used on the deployment does not support no_track flag in its config file (e.g. keepalived 1.x), this option should be set to False. Default value of this option is True.

• DVR routers now support flat networks.

• The dns-assignment will reflect the dns-domain defined in the network or sent by user when creating the port using –dns-domain rather than just take the dns-domain defined in the neutron configuration

• Support for floating IPs port forwarding has been added to OVN backend.

• Make the metadata service available over the IPv6 link-local address fe80::a9fe:a9fe. Metadata over IPv6 works on both isolated networks and networks with an IPv6 subnet connected to a Neutron router as well as on dual-stack and on IPv6-only networks. There are no 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 only affects the guests’ access to the metadata service over tenant networks. This feature changes nothing about how the metadata-agent talks to Nova’s metadata service. The guest OS is expected to pick up routes from Router Advertisements for this feature to work on networks connected to a router. At least the following IPv6 subnet modes work:

  • --ipv6-ra-mode slaac --ipv6-address-mode slaac

  • --ipv6-ra-mode dhcpv6-stateless --ipv6-address-mode dhcpv6-stateless

  • --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode dhcpv6-stateful

  Please note that the metadata IPv6 address (being link-local) is not complete without a zone identifier (in a Linux guest that is usually the interface name concatenated after a percent sign). Please also note that in URLs you should URL-encode the percent sign itself. For example, assuming that the primary network interface in the guest is eth0 the base metadata URL is http://[fe80::a9fe:a9fe%25eth0]:80/.

• Added support for router availability zones in OVN. The OVN driver can now read from the router’s availability_zone_hints field and schedule router ports accordingly with the given availability zones.

• A previous change to set neutron-server child process names also modified neutron agent ones. This can impact monitoring systems relying on /proc/PID/environ formatting or ps -e output. Now neutron agents all have process names formatted this way (showing both an old style process name and full process name visible in recent releases) neutron-agent-name (original process name including interpreter)

  See bug 1881297 for more details.

Upgrade Notes

• The configuration option firewall_driver is no longer used by neutron-server, it only applies to the L2 agent. This was required for backward-compatibility for hybrid plugging, but since the Newton release the L2 agent has been able to report hybrid plugging is needed in it’s report message back to the server.

• Limit the ML2 VLAN allocations to [1, 4094] values in the database engine. This constraint, enforced in the database engine, could not be supported yet. In this case, it will be ignored. For more information, see the note in neutron.db.migration.alembic_migrations.versions.victoria.expand.dfe425060830_limit_vlan_allocation_id_values.py.

• The metadata over IPv6 feature 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. These restarts make the metadata service transiently unavailable. This is done in order to enable the metadata service on pre-existing isolated networks during an upgrade. Please also note that pre-existing instances may need to re-acquire all information acquired over Router Discovery and/or DHCP for this feature to start working.

• The default value for the metadata_workers configuration option has changed to 2 for the ML2/OVN driver. For ML2/OVS the default value remains the same. Each driver has different approaches when serving metadata to the instances and the previous default value of “<number of CPUs> / 2” did not make sense for ML2/OVN as the OVN metadata agents are distributed running on Compute nodes instead of Controller nodes. In fact, the previous default value could cause scalability issues with ML2/OVN and was overwritten by the deployment tools to avoid problems.

• Monitoring tools relying on exact process names should be checked after upgrade, and modified if needed.

Deprecation Notes

• Abstract method plug_new from the neutron.agent.linux.interface.LinuxInterfaceDriver class now accepts an optional parameter link_up. Usage of this method, which takes from 5 to 9 positional arguments, without link_up is now deprecated and will not be possible starting in the W release. Third-party drivers which inherit from this base class should update the implementation of their plug_new method.

• Deprecate the use of remote_ip_prefix in metering label rules, and it will be removed in future releases. One should use instead the source_ip_prefix and/or destination_ip_prefix parameters. For more details, please refer to the spec: https://review.opendev.org/#/c/744702/.

• Terminology such as master and slave have been replaced with more inclusive words, such as primary and backup wherever possible.

  The configuration option vnic_type_blacklist has been deprecated for both the OpenvSwitch and SRIOV mechanism drivers, and replaced with vnic_type_prohibit_list. They will be removed in a future release.

Bug Fixes

• 1671448 Access for Neutron quotas now governed using standard configurable RBAC policies: ‘get_quota’, ‘update_quota’, ‘delete_quota’

• 1875981 Neutron now correctly removes associated DNS records when an admin deletes ports, servers or floation IPs.

• Fixed bug 1876092 which caused DUP ICMP replies on the flat networks used with DVR routers.

• Fixed an issue where the client on a dual-stack (IPv4 + IPv6) network failed to get configuration from the dnsmasq DHCP server. See bug: 1876094.

Other Notes

• When uplink-status-propagation extension is enabled, new ports created will default the value of propagate_uplink_status to True.

16.0.0.0rc1

Prelude

Added support to create stateless security groups.

New Features

• Address scope is now supported via the network RBAC mechanism. Please refer to the admin guide for further details.

• Subnetpool is now supported via the network RBAC mechanism. Please refer to the admin guide for further details.

• Adds support for configuring a list of IPv6 addresses for a dhcp-host entry in the dnsmasq DHCP agent driver. For a port with multiple IPv6 fixed-ips in the same subnet a single dhcp-host entry including all the addresses are written to the dnsmasq dhcp-hostsfile.

  Reserving multiple addresses for a host eases problems related to network and chain-booting where each step in the boot process requests an address using different DUID/IAID combinations. With a single address, only one gets the “static” address and the boot process will fail on the following steps. By reserving enough addresses for all the stages of the boot process this problem is resolved. (See bug: #1861032)

  Note

  This requires dnsmasq version 2.81 or later. Some distributions may backport this feauture to earlier dnsmasq version as part of the packaging, check the distributions releasenotes.

  Since the new configuration format is invalid in previous versions of dnsmasq this feauture is disabled by default. To enable the feature set the option dnsmasq_enable_addr6_list in DHCP agent configuration to True.

• The OVN driver now makes uses of the “external” ports concept that was introduced by Core OVN. For example, with this work a VM with a SR-IOV port attached (VNIC type “direct” and no “switchdev” capability) will now be translated into an “external” port which is able reply to packets (e.g DHCP) from another host that were bypassed in the hypervisor before. Note that, for this first interaction all external ports will belong to the same HA group and will be scheduled onto the same node.

• Adds support for IGMP snooping (Multicast) in the OVN driver. Defaults to False. IGMP snooping requires OVN version 2.12 or above.

• Added support for a new stateful-security-group api extension that implements stateless security groups for the iptables drivers.

Upgrade Notes

• Currently existing security groups will all be set to stateful during the alembic migration.

Security Issues

• A change was made to the metadata proxy to not allow a user to override header values, it will now always insert the correct information and remove unnecessary fields before sending requests to the metadata agent. For more information, see bug 1865036.

• The stateless security group feature does not work with OVS nor OVN driver as the driver is not aware of the stateful attribute in the security group. If stateful attribute is provided with a False value then the attribute value is ignored and the security group would behave as stateful.

Bug Fixes

• Fixed an issue where IP allocation for IPv6 stateless subnets would allocate on invalid subnets when segments are used. Auto-addressing now filters on segment ids when allocating IP addresses. See bugs: #1864225, #1864333, #1865138.

16.0.0.0b1

New Features

• Add a new field description to the PortForwarding resource.

• Add new configuration option igmp_snooping_enable. New option is in OVS config section and is used by openvswitch agent. This option is used to enable support for Internet Group Management Protocol (IGMP) in integration bridge.

• By default the dnsmasq agent is restarted for every port created, deleted or updated. When there are many port changes on the same network it can and will take a very long time for all of the port changes to be realised. This enhancement adds in a new configuration variable that will enable bulk updates. This means that the dnsmasq will only be restarted once in a period and not N times. The new option ‘bulk_reload_interval’ indicates how often the agent should be reloaded. The default value is 0 which means that the original functionality is the default.

• A new configuration option, cleanup_on_shutdown, was added to the L3 agent. If set to True the L3 agent will explicitly delete all routers on shutdown. For L3 HA routers it includes a graceful shutdown of keepalived and the state change monitor, which will allow a faster failover in certain conditions. The default value of cleanup_on_shutdown is False to maintain backward compatibility. Setting to True could affect the data plane when stopping or restarting the L3 agent.

• The subnet-dns-publish-fixed-ip extension adds a new attribute to the definition of the subnet resource. When set to true it will allow publishing DNS records for fixed IPs from that subnet independent of the restrictions described in the DNS integration with an external service documentation.

• The tag_ports_during_bulk_creation ML2 plugin extension has been implemented to support tagging ports during bulk creation. As a side effect, this extension also allows tagging ports during non-bulk creation.

Upgrade Notes

• Python 2.7 support has been dropped. The minimum version of Python now supported by Neutron is Python 3.6.

• For users affected by bug 1853840 the hypervisor name now can be set per physical network device in config option resource_provider_hypervisors which is located in the [ovs] ini-section for ovs-agent and [sriov_nic] ini-section for sriov-agent. Hypervisor names default to socket.gethostname() which works out of the box with libvirt even when the DEFAULT.host config option is set to a non-default value.

• The network mtu attribute is set to be non-nullable. If the mtu is empty(create before Pike version), it is set to the default value of 1500.

• Config option agent_type, which has been deprecated since Mitaka, is now removed. Agents should now use hardcoded values for agent type.

• A security group rule added for the entire port range, for example, TCP ports 1-65535, is not optimal for backends that implement the rule. Rules like this will now automatically be converted to apply to the procotol itself, in other words, all TCP - the port ranges will be ignored. See bug 1848213 for more details.

• SR-IOV agent code no longer supports old kernels (<3.13) for MacVtap ports. This change is not expected to affect existing deployments since most OS distributions already have the relevant kernel patches. In addition, latest major release of all Supported distributions already have a newer kernel.

Deprecation Notes

• Deprecate ovs_integration_bridge. This configuration option is a duplicate of OVS:integration_bridge. Currently both options must be the same to avoid configuration clashes. Previously used in the DHCP agent. It will be removed in next releases.

• Function neutron.plugins.ml2.db.get_binding_levels was deprecated in favor of neutron.plugins.ml2.db.get_binding_level_objs and now is removed.

Bug Fixes

• Bug https://bugs.launchpad.net/neutron/+bug/1732067 described a flooding issue on the neutron-ovs-agent integration bridge. And bug https://bugs.launchpad.net/neutron/+bug/1841622 proposed a solution for it. The accepted egress packets will be taken care in the final egress tables (61 when openflow firewall is not enabled, table 94 otherwise) with direct output flows for unicast traffic with a minimum influence on the existing cloud networking. A new config option explicitly_egress_direct, with default value False, was added for the aim of distinguishing clouds which are running the network node mixed with compute services, upstream neutron CI should be an example. In such situation, this explicitly_egress_direct should be set to False, because there are numerous cases from HA routers which can not be covered, particularly when you have centralized floating IPs running in such mixed hosts. Otherwise, set explicitly_egress_direct to True to avoid the flooding. One more note is if your network nodes are for networing services only, we recommand you disable all the security_group to get a higher performance.

• When listing ports using the openstack port list --mac-address A:B:C:D:E:F command we might not return any result when trying to list ports by MAC address if the cases differ. This fix makes the search based on MAC address case insensitive. For more information see bug 1843428.

• Fixes an issue that the OVS firewall driver does not configure security group rules using remote group properly when a corresponding remote group has no port on a local hypervisor. For more information see bugs: 1862703 and 1854131.

• When updating the fixed-ips of a port residing on a routed provider network the port update would always fail if host was not set. See bug: 1844124.

• Neutron now locates the root resource provider of the resource provider tree it creates by using the hypervisor name instead of the hostname. These are different in rare cases only. The hypervisor name can be set per physical network device in config option resource_provider_hypervisors which is located in the [ovs] ini-section for ovs-agent and [sriov_nic] ini-section for sriov-agent. Hypervisor names default to socket.gethostname() which works out of the box with libvirt even when the DEFAULT.host config option is set to a non-default value. We believe this change fixes bug 1853840.

• Neutron currently does not fully respect the network-auto-schedule configuration option. If the network-auto-schedule option is set to False, the network - a) Is still scheduled on the DHCP agent when it is created b) Is scheduled on a new DHCP agent if the old DHCP mapping is removed by the user/admin. It is especially necessary where the Network Backends provide DHCP directly. This has been fixed now and if the network-auto-schedule is set to False in the config file, networks would not be automatically scheduled to the DHCP Agents. If mapping/scheduling is required, it can be done manually or by setting the network-auto-schedule to True.

• Owners of security groups now see all security group rules which belong to the security group, even if the rule was created by the admin user. Fixes bug 1824248.

Other Notes

• Added QoS support for direct ports in neutron. The support requires Open vSwitch 2.11.0 or newer and is based on Linux kernel 5.4.0 or newer. [bug 1843165].

• When the enable_distributed_routing (DVR) configuration option is set to True and tunneling is enabled, the arp_responder option will be forced to True since it is now required in order for ARP to work properly. For more information, see bug 1774459.

• A new config option, radvd_user, was added to l3_agent.ini for the L3 agent. This option defines the username passed to radvd, used to drop “root” privileges and change user ID to username and group ID to the primary group of the user. If no user specified (by default), the user executing the L3 agent will be passed. If “root” specified, because radvd is spawned as root, no “username” parameter will be passed. (For more information see bug 1844688.)

15.0.0.0rc1

New Features

• The new API extension extraroute-atomic introduces two new member actions on routers to add/remove routes atomically on the server side. The use of these new member actions (PUT /v2.0/routers/ROUTER-ID/add_extraroutes and PUT /v2.0/routers/ROUTER-ID/remove_extraroutes) is always preferred to the old way (PUT /v2.0/routers/ROUTER-ID) when multiple clients edit the extra routes of a router since the old way is prone to race conditions between concurrent clients and therefore to possible lost updates.

Deprecation Notes

• Neutron LBaaS has now been retired. References to neutron-lbaas have been removed from neutron. For more information see https://wiki.openstack.org/wiki/Neutron/LBaaS/Deprecation

15.0.0.0b1

New Features

• Added support for custom scripts used to kill external processes managed by neutron agents, such as dnsmasq or keepalived. Such custom scripts, if defined, will be used instead default kill command to kill such external processes.

• Add Support for Smart NIC in ML2/OVS mechanism driver, by extending the Neutron OVS mechanism driver and Neutron OVS Agent to bind the Neutron port for the baremetal host with Smart NIC.

• The segmentation ID of a provider network can be now modified, even with OVS ports bound. Note that, during this process, the traffic of the bound ports tagged with the former segmentation ID (external VLAN) will be mapped to the new one. This can provoke a traffic disruption while the external network VLAN is migrated to the new tag.

• A new parameter router_factory has been added to neutron.agent.l3.L3AgentExtensionAPI. Developers can register neutron.agent.l3.agent.RouterInfo class and delegate it for RouterInfo creation.

  Extensions can extend RouterInfo itself which correspond to each features (ha, distribtued, ha + distributed).

• Support for L3 conntrack helpers has been added.

  Users can now configure conntrack helper target rules to be set for a Router. This is accomplished by associating a conntrack_helper sub-resource to a router. To create a conntrack_helper, the user specifies: a router ID, the protocol (TCP or UDP, for example), the port number and the conntrack helper module alias (tftp or ftp, for example). CRUD operations for conntrack_helpers are implemented by a Neutron API extension and a service plugin. Please refer to the Neutron API reference documentation for details. A router can have multiple conntack_helpers.

  The new configuration option [l3-conntrack-helpers]/allowed_conntrack_helpers allow the operator to configure allowed helpers, and the helper protocol constraints.

• A notifier for the Openstack Baremetal service (ironic) is introduced. When enabled notifications are sent to the Baremetal service on relevant resource events/changes. By default notifications to the Baremetal service is disabled. To enable notifications to the Baremetal service set [ironic]/enable_notifications to True in the Networking service configuration (neutron.conf).

• Adds support for OVS DPDK port representors, a direct port on a netdev datapath is considered a DPDK representor port.

• When different subnet pools participate in the same address scope, the constraints disallowing subnets to be allocated from different pools on the same network have been relaxed. As long as subnet pools participate in the same address scope, subnets can now be created from different subnet pools when multiple subnets are created on a network. When address scopes are not used, subnets with the same ip_version on the same network must still be allocated from the same subnet pool. For more information, see bug 1830240.

Upgrade Notes

• The first address in an IPv6 network is now a valid, usable IP for routers. It had previously been reserved, but now can be assigned to a router so that an IPv6 address ending in “::” could be a valid default route.

• The gateway_external_network_id config option has been removed. Systems where this option was set will now be able to support multiple external networks for routers.

• The deprecated L2 population agent_boot_time config option was removed and is no longer needed as of the Stein release.

• The deprecated of_interface option is removed. Neutron will always use the native driver, which has been the default since Pike (11.0). If old driver ovs-ofctl was used before upgrade, automatically done change to native driver will cause short break of data plane connectivity during neutron-ovs-agent upgrade.

• Existing IPv6 ICMP security group rules created by using legacy protocol names icmpv6 and icmp will now be returned as ipv6-icmp in an API GET call.

Security Issues

• The OVS Firewall blocks traffic that does not have either the IPv4 or IPv6 ethertypes at present. This is a behavior change compared to the iptables_hybrid firewall, which only operates on IP packets and thus does not address other ethertypes. There is now a configuration option in the neutron openvswitch agent configuration file for permitted ethertypes and then ensures that the requested ethertypes are permitted on initialization.

Bug Fixes

• Leverage the coordination lock to the resource processing and notification thread functions to minimize the lock granularity.

• Add sort-keys validation logic to method get_sorts in neutron.api.api_common. See the link below for more: https://bugs.launchpad.net/neutron/+bug/1659175

• [bug 1811166] Changes the API behavior to enforce that a router’s administrative state must be down (router.admin_state_up==False ) before modifying its distributed attribute. If the router admin_state_up==True when trying to change the distributed attribute, a BadRequest exception will be thrown.

• A previous bug fix changed the behaviour of the DHCP agent to use a network’s dns_domain as the search path provided to instances overriding the dns_domain configuration option used by both the DHCP agent and the main server process when generate port DNS assignments. This broke the original design intent of the dns_domain attribute of a network which was for integration with external DNS systems such as Designate rather than for use in Neutron’s internal DNS support. This incorrect change in behaviour has now been reverted - the DHCP agent will only ever use the dns_domain configuration option.

• Fixes an issue where deletion of a provider network could result in ML2 mechanism drivers not being passed information about the network’s provider fields. The consequences of this depend on the mechanism driver in use, but could result in the event being ignored, leading to an incorrectly configured network. See bug 1841967 for details.

• Security group rule code has been changed to better detect duplicate rules by standardizing on ipv6-icmp as the protocol field value for IPv6 ICMP rules. The legacy names icmpv6 and icmp can still be used in API POST calls, but API GET calls will return ipv6-icmp. Partial fix for bug 1582500.

• Add a new match rule based on physical VLAN tag for OpenFlow firewall traffic identifying mechanism to the TRANSIENT table. This fixes the distributed router east-west traffic between VLAN type networks. For more information, see bug 1831534.

Other Notes

• Add log file for neutron-keepalived-state-change daemon.

• In order to improve heavy load ovs agent restart success rate, instead a retry or fullsync, the native driver of_connect_timeout and of_request_timeout are now set to 300s. The value does not have side effect for the regular pressure ovs agent.

• A new config option, host_dvr_for_dhcp, was added to neutron.conf for DVR to determine whether to host the DVR local router to the scheduled DHCP node(s).

• Add a generic coordination lock mechanism for various scenarios. This decorator allows flexible lock name with parameters and names of underlying functions. And in order to achive backward compatibility with python2.7 several functions was copied from the old version of python inspect. Once python2.7 is retired, we can drop such duplication.

• A new option [ovs] of_inactivity_probe has been added to allow changing the inactivity probe interval when using the OVS ML2 agent with the native OpenFlow driver. Operators can increase this if they are experiencing OpenFlow timeouts. The default value is 10 seconds.

14.0.0

Prelude

Add new tool neutron-status upgrade check.

Added support for network segment range management. This introduces the ability for administrators to control the segment ranges globally or on a per-tenant basis via the Neutron API.

Support alias end points for rules in QoS API.

Existing subnets that were created outside of a subnet pool can know be moved, or “onboarded” into an existing subnet pool. This provides a way for subnets to be brought under the management of a subnet pool and begin participating in an address scope. By enabling onboarding, existing subnets can be used with features that build on subnet pools and address scopes. Subnet onboarding is subject to all the same restrictions as and guarantees currently enforced by subnet pools and address scopes.

New Features

• New framework for neutron-status upgrade check command is added. This framework allows adding various checks which can be run before a Neutron upgrade to ensure if the upgrade can be performed safely. Stadium and 3rd party projects can register their own checks to this new neutron-status CLI tool using entrypoints in neutron.status.upgrade.checks namespace.

• Add support for listing floating ip pools (subnets) in L3 plugin. A new API resource floatingip-pools is introduced. This API endpoint can return a list of floating ip pools which are essentially mappings between network UUIDs and subnet CIDRs. Users can use this API to find out the pool to create the floating IPs.

• Before Stein, network segment ranges were configured as an entry in ML2 config file /etc/neutron/plugins/ml2/ml2_conf.ini that was statically defined for tenant network allocation and therefore had to be managed as part of the host deployment and management. The new network-segment-range API extension has been introduced, which exposes the network segment ranges to be administered via API. This allows users with admin privileges to be able to dynamically manage the shared and/or tenant specific network segment ranges. Standard attributes with tagging support are introduced to the new resource. The feature is controlled by the newly-added service plugin network_segment_range. A set of default network segment ranges will be created out of the ranges that are defined in the host ML2 config file /etc/neutron/plugins/ml2/ml2_conf.ini, such as network_vlan_ranges, vni_ranges for ml2_type_vxlan, tunnel_id_ranges for ml2_type_gre and vni_ranges for ml2_type_geneve.

• L3 agent supports QoS bandwidth limit functionality for port forwarding floating IPs now. If floating IP has binding QoS policy (with bandwidth limit rules), the traffic bandwidth will be limited.

• Introduce the attribute propagate_uplink_status to ports. Right now, the SRIOV mechanism driver leverages this attribute to decide if the VF link should follow the state of the PF. For example, if the PF is down, the VF link state is automatically set to down as well. Operators can turn on this feature via the configuration option:

  [ml2]
  extension_drivers = uplink_status_propagation
  

  The API extension uplink_status_propagation is introduced to indicate if this feature is turned on.

• Add config option rpc_response_max_timeout to configure the maximum time waiting for an RPC response.

• Security groups are now supported via the network RBAC mechanism. Please refer to the admin guide for further details.

• New configuration options for neutron-ovs-agent under section [ovs]: resource_provider_bandwidths and resource_provider_inventory_defaults. The former controls the total (available bandwidth) field of the physical network interface resource provider inventories. It defaults to not creating resource providers in Placement. The latter can be used to tune the other fields (allocation_ratio, min_unit, max_unit, reserved, step_size) of resource provider inventories.

• New configuration options for neutron-sriov-agent under section [sriov_nic]: resource_provider_bandwidths and resource_provider_inventory_defaults. The former controls the total (available bandwidth) field of the physical network interface resource provider inventories. It defaults to not creating resource providers in Placement. The latter can be used to tune the other fields (allocation_ratio, min_unit, max_unit, reserved, step_size) of resource provider inventories.

• A new config option resync_throttle has been added for Neutron DHCP agent. This new option allows to throttle the number of resync state events between the local DHCP state and Neutron to only once per resync_throttle seconds. Default value for this new option is set to 1 and it should be configured per a user’s specific scenario, i.e. how responsive the user would like his/her system to be for those DHCP resync state events. The option is introduced together with the event driven periodic task for DHCP agents. This enhances the agent with a faster reaction on the resync request but ensuring a minimum interval taken between them to avoid too frequent resyncing. For more information see bug 1780370.

• The Neutron L3 and DHCP agents now dynamically tune the number of processing greenthreads they run based on the number of objects they are managing, with the current values for this range being between eight and thirty-two threads, which is an increase over the previous static value of eight threads. This should help address some of the scaling problems in the agents. For more information see bug 1813787.

• A new attribute qos_policy_id is added to the L3 router gateway.

  • It enables users to associate QoS policies to L3 router gateways to control the rate of transmission of the associated SNAT traffic.

  • At the moment, only bandwidth limit rules are supported in the QoS polices.

  • To enable this feature, the qos service plugin has to be configured in the Neutron server and the gateway_ip_qos extension has to be configured in the L3 agents. Please refer to the QoS section of the OpenStack Networking Guide for more specific details.

• Add get_standard_device_mappings to SriovNicSwitchMechanismDriver and OpenvswitchMechanismDriver so they can return the interface or bridge mappings in a standard way. The common format is a dict like: {‘physnet_name’: [‘device_or_bridge_1’, ‘device_or_bridge_2’]}.

• The qos-rules-alias API extension was implemented to enable users to perform GET, PUT and DELETE operations on QoS rules as though they are first level resources. In other words, the user doesn’t have to specify the QoS policy ID.

• Neutron child processes now set their process titles to match their roles (‘api worker’, ‘rpc worker’, ‘periodic worker’, ‘services worker’, or any other defined by workers from out-of-tree plugins.) This behavior can be disabled by setting the setproctitle config option in the [default] section in neutron.conf to off. The original process string is also appended to the end, to help with scripting that is looking for the old strings. There is also an option called brief, which results in much shorter and easier to read process names. The default setting for this option is on, for a combination of backwards compatibility and identifying different processes easily. The recommended setting is brief, once the deployer has verified that none of their tooling depends on the older strings.

• Existing subnets can now be moved into a subnet pool, and by extension can be moved into address scopes they were not initially participating in.

Upgrade Notes

• Operator can now use new CLI tool neutron-status upgrade check to check if Neutron deployment can be safely upgraded from N-1 to N release.

• Adds Floating IP port forwarding table column protocol to the uniq constraints. In one expand script, we drop the original uniq constraints first, then create the new uniq constraints with column protocol.

• The external_network_bridge config option has been removed. Existing users of this option will now have their router’s gateway interface created in the integration bridge and it will be wired by the L2 agent.

• The number of api and rpc workers may change on upgrade. It is strongly recommended that all deployers set these values in their neutron configurations, rather than using the defaults.

• The deprecated ovsdb_interface configuration option has been removed, the default native driver is now always used. In addition, the deprecated ovs_vsctl_timeout option, which was renamed to ovsdb_timeout in Queens, has also been removed.

• During the dependency resolution procedure, the code that loads service plugins was refactored to not raise an exception if one plugin is configured multiple times, with the last one taking effect. This is a change from the previous behavior.

• The change to the process title happens by default with the new setproctitle config option. The old string is still part of the new process title, but any scripts looking for exact string matches of the old string may need to be modified.

• The Neutron API now enforces that ports are a valid option for security group rules based on the protocol given, instead of relying on the backend firewall driver to do this enforcement, typically silently ignoring the port option in the rule. The valid set of allowed protocols that support ports are TCP, UDP, UDPLITE, SCTP and DCCP. Ports used with other protocols will now generate an HTTP 400 error. For more information, see bug 1818385.

Deprecation Notes

• The signature of notifications for resource agent for events after_create and after_update was extended. A new keyword argument was added: status. This is to make the same status information available to notification consumers as it was available already where the notification is sent in class AgentDbMixin. Valid status values are defined in neutron_lib.agent.constants. Consuming notifications by the old signature is deprecated. Unless processing arguments as **kwargs, out-of-tree notification consumers need to adapt.

• Function get_binding_levels from neutron.plugins.ml2.db module is deprecated and will be removed in the future. New function get_binding_levels_objs should be used instead. This new function returns PortBindingLevel OVO objects.

• The L2 population agent_boot_time config option is deprecated in favor of the direct RPC agent restart state transfer. It will be removed in the Train release.

Critical Issues

• The neutron-openvswitch-agent can sometimes spend too much time handling a large number of ports, exceeding its timeout value, agent_boot_time, for L2 population. Because of this, some flow update operations will not be triggerred, resulting in lost flows during agent restart, especially for host-to-host vxlan tunnel flows, causing the original tunnel flows to be treated as stale due to the different cookie IDs. The agent’s first RPC loop will also do a stale flow clean-up procedure and delete them, leading to a loss of connectivity. Please ensure that all neutron-server and neutron-openvswitch-agent binaries are upgraded for the changes to take effect, after which the L2 population agent_boot_time config option will no longer be used.

Bug Fixes

• Floating IP port forwardings with different protocols could not have the same internal or external port number to the same VM port. After this fix we will allow creating port forwardings with same internal or external port number in different protocols.

• Fixes bug 1501206. This ensures that DHCP agent instances running dnsmasq as a DNS server can no longer be exploited as DNS amplifiers when the tenant network is using publicly routed IP addresses by adding an option that will allow them to only serve DNS requests from local networks.

• Add resource_type into log object query to distinguish between security group and firewall group log objects. For more information see bug 1787119.

• Fixes an issue causing IP allocation on port update to fail when the initial IP allocation was deferred due to lack of binding info. If both the port mac_address and binding info (binding_host_id) were updated in the same request, the fixed_ips field was added to the request internally. The code to complete the deferred allocation failed to execute in that case. (For more information see bug 1811905.)

• Neutron API workers default to the number of CPU cores. This can lead to high cpu/low memory boxes getting into trouble. The defaults have been tweaked to attempt to put an upper bound on the default of either the number of cores, or half of system memory, whichever is lower. In addition, the default number of RPC workers has been changed from a value of 1, to a value of half the number of API workers.

• The neutron-openvswitch-agent was changed to notify the neutron-server in its first RPC loop that it has restarted. This signals neutron-server to provide updated L2 population information to correctly program FDB entries, ensuring connectivity to instances is not interrupted. This fixes the following bugs: 1794991, 1799178, 1813703, 1813714, 1813715.

• Reject QoS minimum bandwidth rule operations on ports, networks without physnet, see bug 1819029.

• Adds the router service plugin to the port_forwarding service plugin required list. For more info see https://bugs.launchpad.net/neutron/+bug/1809238

Other Notes

• Support fetching specific db column in OVO. A new method get_values is added to neutron object classes. This method can be leveraged to fetch specific field of the object.

• If an instance port is under a dvr router, and the port already has binding port forwarding(s). Neutron will no longer allow binding a floating IP to that port again, because dvr floating IP traffic rules will break the existing port forwarding functionality.

• Add new configuration group ovs_driver and new configuration option under it vnic_type_prohibit_list, to make the previously hardcoded supported_vnic_types parameter of the OpenvswitchMechanismDriver configurable. The vnic_types listed in the prohibit list will be removed from the supported_vnic_types list.

• Add new configuration group sriov_driver and new configuration option under it vnic_type_prohibit_list, to make the previously hardcoded supported_vnic_types parameter of the SriovNicSwitchMechanismDriver configurable. The vnic_types listed in the prohibit list will be removed from the supported_vnic_types list.

• The metering agent iptables driver can now load its interface driver by using a stevedore alias in the metering_agent.ini file. For example, interface_driver = openvswitch instead of interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

• Neutron server now rejects (as NotImplementedError) updates of minimum_bandwidth QoS rules if the rule is already in effect on bound ports. Implementing updates will require updates to Placement allocations and possibly migrating servers where the new minimum_bandwidth can be satisifed.

• Neutron now supports having service plugins require other plugin(s) as dependencies. For example, the port_forwarding service plugin requires the router service plugin to achieve full functionality. A new list, required_service_plugins, was added to each service plugin so the required dependencies of each service plugin can be initialized. If one service plugin requires another, but the requirement is not set in the config file, neutron will now initialize it to the plugin directory.

• Use publish for AGENT's AFTER_CREATE and AFTER_UPDATE events with DBEventPayload instead of the deprecated notify callback.

13.0.0.0rc1

Prelude

Added support for floating IPs port forwarding.

New Features

• Introduces extension parent resources owner check in neutron.policy.OwnerCheck. It can be used by registering an extension parent resource and service plugin which introduced the corresponding parent resource into EXT_PARENT_RESOURCE_MAPPING located in neutron.common.constants. And introduces a new policy role admin_or_ext_parent_owner into policy.json for this function.

• Support for floating IPs port forwarding has been added.

  • Users can now forward the traffic from a TCP/UDP/other protocol port of a floating IP address to a TCP/UDP/other protocol port associated to one of the fixed IP addresses of a Neutron port.

  • This is accomplished by associating port_forwarding sub-resources to floating IPs.

  • To create a port_forwarding, the user specifies: a floating IP ID, the floating IP’s external_port number, the Neutron port ID internal_port_id, an internal_ip_address (one of the Neutron port’s fixed IPs), the internal_port number and the protocol to be used (TCP or UDP for example).

  • CRUD operations for port_forwardings are implemented by a Neutron API extension and a service plugin. Please refer to the Neutron API reference documentation for details.

  • A user cannot create port_forwardings for a floating IP that is already associated with a Neutron port.

  • A floating IP can have many port_forwardings.

  • Port forwardings can only be created for floating IPs that are managed by centralized routers in the network node: legacy, HA, DVR+HA.

13.0.0.0b3

Prelude

Support multiple bindings for compute owned ports.

Perform validation on filter parameters on listing resources.

New Features

• In order to better support instance migration, multiple port bindings can be associated to compute owned ports.

  • Create, update, list, show and activate operations are supported for port bindings by the ReST API.

  • A compute owned port can have one active binding and many inactive bindings.

  • There can be only one binding (active or inactive) per compute host.

  • When the activate operation is executed, a previously inactive binding is made active. The previously active binding becomes inactive.

  • As a consequence of the multiple port bindings implementation, the port_binding relationship in the SQLAlchemy Port object has been renamed port_bindings. Similarly, the binding attribute of the Port OVO has been renamed bindings.

• A new config option bridge_mac_table_size has been added for Neutron OVS agent. This value will be set on every Open vSwitch bridge managed by the openvswitch-neutron-agent in other_config:mac-table-size column in ovsdb. Default value for this new option is set to 50000 and it should be enough for most systems. More details about this option can be found in Open vSwitch documentation For more information see bug 1775797.

• Adds api extenstion port-mac-address-regenerate. When passing 'null' (None) as the mac_address on port update a converter will generate a new mac address that will be assigned to the port. RFE: #1768690.

• Adds host routes for subnets on the same network when using routed networks. Static routes will be configured for subnets associated with other segments on the same network. This ensures that traffic within an L3 routed network stays within the network even when the default route is on a different interface.

• Starting from this release, neutron server will perform validation on filter parameters on list requests. Neutron will return a 400 response if the request contains invalid filter parameters. The list of valid parameters is documented in the neutron API reference.

  Add an API extension filter-validation to indicate this new API behavior. This extension can be disabled by operators via a config option.

Upgrade Notes

• Prior to the upgrade, if a request contains an unknown or unsupported parameter, the server will silently ignore the invalid input. After the upgrade, the server will return a 400 Bad Request response instead.

  API users might observe that requests that received a successful response now receive a failure response. If they encounter such experience, they are suggested to confirm if the API extension filter-validation is present and validate filter parameters in their requests.

  Operators can disable this feature if they want to maintain backward-compatibility. If they choose to do that, the API extension filter-validation will not be present and the API behavior is unchanged.

Other Notes

• Each plugin can decide if it wants to support filter validation by setting __filter_validation_support to True or False. If this field is not set, the default value is False. Right now, the ML2 plugin and all the in-tree service plugins support filter validation. Out-of-tree plugins will have filter validation disabled by default but they can turn it on if they choose to. For filter validation to be supported, the core plugin and all the services plugins in a deployment must support it.

13.0.0.0b2

New Features

• Add attribute port_details to floating IP. The value of this attribute contains information of the associated port.

• Add support for setting the segment_id for an existing subnet. This enables users to convert a non-routed network with no subnet/segment association to a routed one. It is only possible to do this migration if both of the following conditions are met - the current segment_id is None and the network contains a single segment and subnet.

• Add support for filtering attributes with value as empty string. A shim extension is added to indicate if this feature is supported.

Bug Fixes

• For Infiniband support, Ironic needs to send the ‘client-id’ DHCP option as a number in order for IP address assignment to work. This is now supported in Neutron, and can be specified as option number 61 as defined in RFC 4776. For more information see bug 1770932

Other Notes

• The deprecated IVSInterfaceDriver class has been removed from the code base. This means neither the ivs nor the neutron.agent.linux.interface.IVSInterfaceDriver can any longer be used as a value for the interface_driver config option in neutron.conf.

13.0.0.0b1

Prelude

In order to reduce the time spent processing security group updates in the L2 agent, conntrack deletion is now performed in a set of worker threads instead of the main agent thread, so it can return to processing other events quickly.

New Features

• Added new unknown state for HA routers. Sometimes l3 agents may not be able to update health status to Neutron server due to communication issues. During that time the server may not know whether HA routers hosted by that agent are active or standby.

• Support port filtering on security group IDs. The feature can be used if ‘port-security-group-filtering’ extension is available.

Known Issues

• In the case when the number of ports to clean up in a single bridge is larger than about 10000, it might require an increase in the ovsdb_timeout config option to some value higher than 600 seconds.

Upgrade Notes

• On an upgrade, conntrack entries will now be cleaned-up in a worker thread, instead of in the calling thread.

Bug Fixes

• Fixes bug 1745468.

• Fixes bug 1682145.

• Fix an issue that standard attributes, such as created_at, updated_at and revision_number, are not rendered in the response of segment resource.

• Fixes bug 1763604. Override default value of ovsdb_timeout config option in neutron-ovs-cleanup script. The default value is 10 seconds, but that is not enough for the neutron-ovs-cleanup script when there are many ports to remove from a single bridge, for example, 5000. Because of that, we now override the default value for the config option to be 600 seconds (10 minutes).

12.0.0.0rc1

New Features

• Neutron agents now support SSL connections to OVSDB server. To enable an SSL based connection, use an ssl prefixed URI for the ovsdb_connection setting. When using SSL it is also required to set new ovs group options which include ssl_key_file, ssl_cert_file, and ssl_ca_cert_file.

12.0.0.0b3

New Features

• The DSCP value for outer headers in openvswitch overlay tunnel ports can now be set through a configuration option dscp for both OVS and linuxbridge agents.

• DSCP can also be inherited from the inner header through a new boolean configuration option dscp_inherit for both openvswitch and linuxbridge. If this option is set to true, then the value of dscp will be ignored.

• Tenants who can access shared networks, can now create/update ports on a specified subnet instead of the default subnet. This is now the default behavior and can be changed by modifying policy.json file.

• L2 agents based on ML2 _common_agent have now the L2 extension API available. This API can be used by L2 extension drivers to request resources from the L2 agent. It is used, for example, to pass an instance of the IptablesManager to the Linuxbridge L2 agent QoS extension driver.

• Support substring matching when filtering ports by IP address.

Deprecation Notes

• the tos configuration option in VXLAN group for linuxbridge is deprecated and replaced with the more precise option dscp. The TOS value is made of DSCP and ECN bits. It is not possible to set the ECN value through the TOS value, and ECN is always inherited from the inner in case of tunnelling.

Bug Fixes

• Fixes bug 1736674, security group rules are now properly applied by Linuxbridge L2 agent with QoS extension driver enabled.

12.0.0.0b2

New Features

• Implementation of floating IP QoS. A new parameter qos_policy_id was added to floating IP related API.

• A new method get_router_info has been added to L3AgentExtensionAPI.

Deprecation Notes

• The ovs_vsctl_timeout option is renamed into ovsdb_timeout to reflect that it’s not specific to vsctl implementation of ovsdb_interface. It is also moved under [OVS] section.

Bug Fixes

• The Openvswitch agent has an extension called fdb that uses the Linux bridge command. The bridge command has been added to the rootwrap openvswitch-plugin.filters file. For more information, see bug: 1730407

• Adding security group rules by protocol number is documented, but somehow was broken without being noticed in one of the last couple of releases. This is now fixed. For more information see bug 1716045.

12.0.0.0b1

Prelude

DNS server assignment can now be disabled in replies sent from the DHCP agent.

A new agent_mode(dvr_no_external) for DVR routers has been added to allow the server to configure Floating IPs associated with DVR at the centralized node.

New Features

• Ports have now a dns_domain attribute. A port’s dns_domain attribute has precedence over the network’s dns_domain from the point of view of publishing it to the external DNS service.

• Allow configuration of DHCP renewal (T1) and rebinding (T2) timers in neutron-dhcp-agent. By allowing these timers to be set (options 58 and 59 as per RFC2132) in dnsmasq it allows users to change other parameters, like MTU, on instances without having to wait for the lease time to expire. The advantage of changing T1 over the lease time is that if the DHCP server becomes unreachable within the lease time, instances will not drop their IP addresses and it will not cause a dataplane disruption.

• It is now possible to instruct the DHCP agent not to supply any DNS server address to their clients by setting the dns_nameservers attribute for the corresponding subnet to 0.0.0.0 or ::, for IPv4 or IPv6 subnets (respectively).

• A new DVR agent type dvr_no_external has been introduced with this release. This agent type allows the Floating IPs (DNAT/North-South routing) to be centralized while the East/West routing is still distributed.

• A new method ha_state_change has been added to L3AgentExtensionsManager.

Known Issues

• There can be a mixture of dvr agents and dvr_no_external agents. But please avoid any VM with Floating IP migration between a dvr agent and a dvr_no_external agent. All VM ports with Floating IPs should be migrated to same agent_mode. This would be one of the restrictions.

Upgrade Notes

• The functionality when a subnet has its DNS server set to 0.0.0.0 or :: has been changed with this release. The old behaviour was that each DHCP agent would supply only its own IP address as the DNS server to its clients. The new behaviour is that the DHCP agent will not supply any DNS server IP address at all.

• A new DVR agent mode of dvr_no_external was added. Changing between this mode and dvr is a disruptive operation to the dataplane.

• The web_framework option has been removed. This should have no impact on operators/users since it was just an option used for development of the new web framework.

Deprecation Notes

• The ivs interface driver is deprecated in Queens and will be removed in Rocky.

• The ovsdb_interface configuration option is now deprecated. In future releases, the value of the option will be ignored. The native driver will then be used.

• The api-paste entrypoint neutron.api.versions:Versions.factory has been deprecated and will be removed in the Rocky release. Please update your api-paste.ini file to use the one that ships with Queens or update any references to the Versions factory to point to neutron.pecan_wsgi.app:versions_factory instead.

Bug Fixes

• In security group rules API, API level validation for port_range values has been performed only against TCP and UDP. Now it is performed against DCCP, SCTP and UDP-Lite, too.

11.0.0.0rc1

New Features

• The new net-mtu-writable extension API definition has been added. The new extension indicates that the network mtu attribute is writeable. Plugins supporting the new extension are expected to also support net-mtu. The first plugin that gets support for the new extension is ml2.

• Floating IPs associated with an unbound port with DVR routers will not be distributed, but will be centralized and implemented in the SNAT namespace of the Network node or dvr_snat node. Floating IPs associated with allowed_address_pair port IP and are bound to multiple active VMs with DVR routers will be implemented in the SNAT namespace in the Network node or dvr_snat node. This will address VRRP use cases. More information about this is captured in bug 1583694.

Known Issues

• While the bound port Floating IPs are distributed, the unbound port Floating IPs are centralized.

Upgrade Notes

• The max_fixed_ips_per_port configuration option was deprecated in the Newton cycle and removed in Pike.

Deprecation Notes

• The web_framework option has been deprecated and will be removed during Queens. This option was just added to make the transition to pecan easier so there is no reason operators should be using the non-default option anyway.

Bug Fixes

• Allows the unbound port Floating IPs to be configured properly with DVR routers irrespective of its device_owner.

Other Notes

• Changing MTU configuration options (global_physnet_mtu, physical_network_mtus, and path_mtu) and restarting neutron-server no longer affects existing networks’ MTUs. Nevertheless, new networks will use new option values for MTU calculation. To reflect configuration changes for existing networks, one may use the new net-mtu-writable API extension to update mtu attribute for those networks.

11.0.0.0b3

New Features

• The openvswitch L2 agent now supports bi-directional bandwidth limiting.

• The resource tag mechanism is refactored so that the tag support for new resources can be supported easily. The resources with tag support are network, subnet, port, subnetpool, trunk, floatingip, policy, security_group, and router.

• Some scenario tests require advanced Glance images (for example, Ubuntu or CentOS) in order to pass. They are now skipped by default. If you need to execute those tests, please configure tempest.conf to use an advanced image, and set image_is_advanced in neutron_plugin_options section of tempest.conf file to True. The first scenario test case that requires the new option set to execute is test_trunk.

• The Neutron API now supports conditional updates to resources with the ‘revision_number’ attribute by setting the desired revision number in an HTTP If-Match header. This allows clients to ensure that a resource hasn’t been modified since it was retrieved by the client. Support for conditional updates on the server can be checked for by looking for the ‘revision-if-match’ extension in the supported extensions.

• Implements a new extension, quota_details which extends existing quota API to show detailed information for a specified tenant. The new API shows details such as limits, used, reserved.

• Linuxbridge L2 agent supports ingress bandwidth limit. The linuxbridge L2 agent now supports bi-directional bandwidth limiting.

• UDP ports used by VXLAN in the LinuxBridge agent can be configured now with the VXLAN.udp_srcport_min, VXLAN.udp_srcport_max and VXLAN.udp_dstport config options. To use the IANA assigned port number, set VXLAN.udp_dstport to 4789. The default is not changed from the Linux kernel default 8472.

• The openvswitch mechanism driver now supports hardware offload via SR-IOV. It allows binding direct (SR-IOV) ports. Using openvswitch 2.8.0 and ‘Linux Kernel’ 4.8 allows to control the SR-IOV VF via OpenFlow control plane and gain accelerated ‘Open vSwitch’.

• New API to get details of supported rule types. The QoS service plugin can now expose details about supported QoS rule types in Neutron deployment. The new API call is allowed only for users with admin priviliges.

Upgrade Notes

• The deprecated prevent_arp_spoofing option has been removed and the default behavior is to always prevent ARP spoofing unless port security is disabled on the port (or network).

Deprecation Notes

• Users can use ‘tagging’ extension instead of the ‘tag’ extension and ‘tag-ext’ extension. Those extensions are now deprecated and will be removed in the Queens release.

11.0.0.0b2

New Features

• The QoS service plugin now supports new attribute in qos_bandwidth_limit_rule. This new parameter is called direction and allows to specify direction of traffic for which the limit should be applied.

• Allow to configure router service plugin without dvr API extension loaded and exposed. To achieve that, set the new enable_dvr option to False in neutron.conf file.

• Add data_plane_status attribute to port resources to represent the status of the underlying data plane. This attribute is to be managed by entities outside of the Networking service, while the status attribute is managed by the Networking service. Both status attributes are independent from one another. Third parties can report via Neutron API issues in the underlying data plane affecting connectivity from/to Neutron ports. Attribute can take values None (default), ACTIVE or DOWN, and is readable by users and writable by admins and users granted the data-plane-integrator role. Append data_plane_status to [ml2] extension_drivers config option to load the extension driver.

• Neutron API can now be managed by a mod_wsgi compatible web server (e.g. apache2 (httpd), nginx, etc.)

• Add ‘default’ behaviour to QoS policies Neutron now supports having a default QoS policy in a project, assigned automatically to all new networks created.

• Proactively create DVR floating IP namespace on all compute nodes when a gateway is configured.

• A new network_link_prefix configuration option is introduced that allows to alter the domain returned in the URLs included in the API responses. It behaves the same way as the compute_link_prefix and glance_link_prefix options do for Nova and Glance.

• Enable creation of VXLANs with different multicast addresses in linuxbridge agent allocated by VNI-address mappings. A new config option multicast_ranges was introduced.

Known Issues

• Creating DVR floating IP namespace on all nodes proactively might consume public IP Address, but by using subnet service-types as explained in the networking guide consumers can use the private IPs for floating IP agent gateway ports and need not consume any public IP addresses.

Upgrade Notes

• Consider setting enable_dvr to False in neutron.conf file if your setup doesn’t support DVR. This will make Neutron stop advertising support for the dvr API extension via its /v2.0/extensions API endpoint.

• Previously, neutron-server was using configuration values for oslo.db that were different from library defaults. Specifically, it used the following values when they were not overridden in configuration files: max_pool_size = 10, max_overflow = 20, pool_timeout = 10. In this release, neutron-server instead relies on default values defined by the library itself. If you rely on old default values, you may need to adjust your configuration files to explicitly set the new values.

• The send_arp_for_ha configuration option is removed. Neutron now always sends three gratuitous ARP requests on address assigned to a port.

Other Notes

• Example configuration of multicast_ranges in ml2_conf.ini under the [vxlan] config. section multicast_ranges = 224.0.0.10:10:90,225.0.0.15:100:900. For VNI between 10 and 90, the multicast address 224.0.0.0.10 will be used, and for 100 through 900 225.0.0.15 will be used. Other VNI values will get standard vxlan_group address. For more info see RFE https://bugs.launchpad.net/neutron/+bug/1579068

11.0.0.0b1

New Features

• Resource tag mechanism now supports subnet, port, subnetpool and router resources.

• The metering agent driver can now be specified with a stevedore alias in the metering_agent.ini file. For example, driver = iptables instead of driver = neutron.services.metering.iptables.iptables_driver:IptablesMeteringDriver.

• Network QoS policies are now supported for network:router_gateway ports. Neutron QoS policies set on an external network now apply to external router ports (DVR or not).

• In order to reduce metadata proxy memory footprint, haproxy is now used as a replacement for neutron-ns-metadata-proxy Python implementation.

• Subport segmentation details can now accept inherit as segmentation type during a trunk creation/update request. The trunk plugin will determine the segmentation type and ID and replace them with those of the network to which the port is connected. Only single-segment VLAN networks are set to have expected and correct results at this point.

Upgrade Notes

• Default quotas were bumped for the following resources: networks (from 10 to 100), subnets (from 10 to 100), ports (from 50 to 500). If you want to stick to old values, consider explicitly setting them in the neutron.conf file.

• Since haproxy was not used before by neutron-l3-agent and neutron-dhcp-agent, rootwrap filters for both agents have to be copied over when upgrading.

• To upgrade to the haproxy based metadata proxy, neutron-l3-agent and neutron-dhcp-agent have to be restarted. On startup, old proxy processes will be detected and replaced with haproxy.

• After upgrade, a macvtap agent without physical_interface_mappings configured can not be started. Specify a valid mapping to be able to start and use the macvtap agent.

Deprecation Notes

• The gateway_external_network_id L3 agent option is deprecated and will be removed in next releases, with external_network_bridge that it depends on.

• Now that rootwrap daemon mode is supported for XenServer, the neutron-rootwrap-xen-dom0 script is deprecated and will be removed in a next release.

• The of_interface Open vSwitch agent configuration option is deprecated and will be removed in the future. After option removal, the current default driver (native) will be the only supported of_interface driver.

• The nova_metadata_ip option is deprecated and will be removed in Queens. It is deprecated in favor of the new nova_metadata_host option because it reflects better that the option accepts an IP address and also a DNS name.

10.0.0.0rc1

New Features

• Keepalived VRRP health check functionality to enable verification of connectivity from the “primary” router to all gateways. Activation of this feature enables gateway connectivity validation and rescheduling of the “primary” router to another node when connectivity is lost. If all routers lose connectivity to the gateways, the election process will be repeated round-robin until one of the routers restores its gateway connection. In the mean time, all of the routers will be reported as “primary”.

• The QoS driver architecture has been refactored to overcome several previous limitations, the main one was the coupling of QoS details into the mechanism drivers, and the next one was the need of configuration knobs to enable each specific notification driver, that will be handled automatically from now on.

• vhost-user reconnect is a mechanism which allows a vhost-user frontend to reconnect to a vhost-user backend in the event the backend terminates either as a result of a graceful shutdown or a crash. This allows a VM utilising a vhost-user interface to reconnect automatically to the backend e.g. Open vSwitch without requiring the VM to reboot. In this release, support was added to the neutron Open vSwitch agent and ml2 driver for vhost-user reconnect.

Deprecation Notes

• notification_drivers from [qos] section has been deprecated. It will be removed in a future release.

Other Notes

• vhost-user reconnect requires dpdk 16.07 and QEMU 2.7 and Open vSwitch 2.6 to function. if an older QEMU is used, reconnect will not be available but vhost-user will still function.

10.0.0.0b3

New Features

• Add a new configuration section, [placement], with two new options that allow to make segments plugin to use the Compute placement ReST API. This API allows to influence node placement of instances based on availability of IPv4 addresses in routed networks. The first option, region_name, indicates the placement region to use. This option is useful if keystone manages more than one region. The second option, endpoint_type, determines the type of a placement endpoint to use. This endpoint will be looked up in the keystone catalog and should be one of public, internal or admin.

• Designate driver can now use Keystone v3 authentication options. “The [designate] section now accepts the auth_type option, as well as other keystoneauth options (e.g. auth_url, username, user_domain_name, password, project_name, project_domain_name).”

• A new mechanism has been added to the neutron-netns-cleanup tool that allows to kill processes listening on any Unix or network socket within a namespace. The new mechanism will try to kill those processes gracefully using the SIGTERM signal and, if they refuse to die, then the SIGKILL signal will be sent to each remaining process to ensure a proper cleanup.

• Initial support for oslo.privsep has been added. Most external commands are still executed using oslo.rootwrap.

Upgrade Notes

• The dhcp_domain DHCP agent configuration option was deprecated in Liberty cycle, and now is no longer used. The dns_domain option should be used instead.

• The advertise_mtu option is removed. Now Neutron always uses all available means to advertise MTUs to instances (including DHCPv4 and IPv6 RA).

• The min_l3_agents_per_router configuration option was deprecated in Newton cycle and removed in Ocata. HA routers no longer require a minimal number of L3 agents to be created, although obviously they require at least two L3 agents to provide HA guarantees. The rationale for the removal of the option is the case a router was created just when an agent was not operational. The creation of the router will now succeed, and when a second agent resumes operation the router will be scheduled to it providing HA.

10.0.0.0b2

New Features

• The Linux Bridge agent now supports QoS DSCP marking rules.

Upgrade Notes

• On upgrade, IPv6 addresses in DHCP namespaces that have been created dynamically via SLAAC will be removed, and static IPv6 addresses will be added instead.

• Obsolete oslo.messaging.notify.drivers entrypoints that were left in tree for backwards compatibility with pre-Icehouse releases have been removed. Those are neutron.openstack.common.notifier.log_notifier, neutron.openstack.common.notifier.no_op_notifier, neutron.openstack.common.notifier.test_notifier, neutron.openstack.common.notifier.rpc_notifier2, neutron.openstack.common.notifier.rpc_notifier. Use values provided by oslo.messaging library to configure notification drivers.

Bug Fixes

• There is a race condition when adding ports in DHCP namespaces where an IPv6 address could be dynamically created via SLAAC from a Router Advertisement sent from the L3 agent, leading to a failure to start the DHCP agent. This bug has been fixed, but care must be taken on an upgrade dealing with any potentially stale dynamic addresses. For more information, see bug 1627902.

Other Notes

• Due to changes in internal L3 logic, a server crash/backend failure during FIP creation may leave dangling ports attached on external networks. These ports can be identified by a PENDING device_id parameter. While those ports can also be removed by admins, the neutron-server service will now also trigger periodic (approximately once in 10 minutes) cleanup to address the issue.

• The allow_pagination and allow_sorting configuration options are now removed. Now, sorting and pagination are always enabled for plugins that support the features.

10.0.0.0b1

Prelude

Hyper-V Neutron Agent has been fully decomposed from Neutron. Therefore, the neutron.plugins.hyperv.agent.security_groups_driver.HyperVSecurityGroupsDriver firewall driver has been deleted. Update the neutron_hyperv_agent.conf / neutron_ovs_agent.conf files on the Hyper-V nodes to use hyperv.neutron.security_groups_driver.HyperVSecurityGroupsDriver, which is the networking_hyperv security groups driver.

New Features

• Middleware was added to parse the X-Forwarded-Proto HTTP header or the Proxy protocol in order to help Neutron respond with the correct URL references when it’s put behind a TLS proxy such as haproxy. This adds http_proxy_to_wsgi middleware to the pipeline. This middleware is disabled by default, but can be enabled via a configuration option in the [oslo_middleware] group.

• The created_at and updated_at resource fields now include a timezone indicator at the end. Because this is a change in field format, the old timestamp_core extension has been removed and replaced with a standard-attr-timestamp extension.

Known Issues

• In kernels < 3.19 net.ipv4.ip_nonlocal_bind sysctl option was not isolated to network namespace scope. L3 HA sets this option to zero to avoid sending gratuitous ARPs for IP addresses that were removed while processing. If this happens, then gratuitous ARPs will be sent. It may populate ARP cache tables of peer machines with wrong MAC addresses.

Upgrade Notes

• The api-paste.ini configuration file for the paste pipeline was updated to add the http_proxy_to_wsgi middleware.

• Update the neutron_hyperv_agent.conf / neutron_ovs_agent.conf files on the Hyper-V nodes to use hyperv.neutron.security_groups_driver.HyperVSecurityGroupsDriver, which is the networking_hyperv security groups driver.

• A new option ha_keepalived_state_change_server_threads has been added to configure the number of concurrent threads spawned for keepalived server connection requests. Higher values increase the CPU load on the agent nodes. The default value is half of the number of CPUs present on the node. This allows operators to tune the number of threads to suit their environment. With more threads, simultaneous requests for multiple HA routers state change can be handled faster.

• The timestamp_core extension has been removed and replaced with the standard-attr-timestamp extension. Resources will still have timestamps in the created_at and updated_at fields, but timestamps will have time zone info appended to the end to be consistent with other OpenStack projects.

Deprecation Notes

• The L3 agent send_arp_for_ha configuration option is deprecated and will be removed in Pike. The functionality will remain, and the agent will send three gratuitious ARPs whenever a new floating IP is configured.

• The iptables firewall driver will no longer enable bridge firewalling in next versions of Neutron. If your distribution overrides the default value for any of relevant sysctl settings (net.bridge.bridge-nf-call-arptables, net.bridge.bridge-nf-call-ip6tables, and net.bridge.bridge-nf-call-iptables) then make sure you set them back to upstream kernel default (1) using /etc/sysctl.conf or /etc/sysctl.d/* configuration files.

Bug Fixes

• Versions of keepalived < 1.2.20 don’t send gratuitous ARPs when keepalived process receives a SIGHUP signal. These versions are not packaged in some Linux distributions like Red Hat Enterprise Linux 7, CentOS 7, or Ubuntu Xenial. Not sending gratuitous ARPs may lead to peer ARP cache tables containing wrong entries about floating IP addresses until those entries are invalidated. To fix that scenario, Neutron now sends gratuitous ARPs for all new IP addresses that appear on non-HA interfaces in router namespaces. This behavior simulates behavior of new versions of keepalived.

9.0.0.0rc1

Prelude

Add ip_allocation attribute to port resources

The “vlan-aware-vms” feature allows Nova users to launch VMs on a single port (trunk parent port) that connects multiple Neutron logical networks together.

New Features

• The port resource now has an ip_allocation attribute. The value of this attribute will be set to ‘immediate’, ‘deferred’, or ‘none’ at the time the port is created. It will not be changed when the port is updated. ‘immediate’ means that the port is expected to have an IP address and Neutron attempted IP allocation on port creation. ‘deferred’ means that the port is expected to have an IP address but Neutron deferred IP allocation until a port update provides the host to which the port will be bound. ‘none’ means that the port was created explicitly with no addresses by passing [] in fixed_ips when creating it.

• The Networking API now supports the ‘project_id’ field in requests and responses, for compatibility with the Identity (Keystone) API V3. A new API extension, ‘project-id’, has been added to allow API users to detect if the ‘project_id’ field is supported. Note that the ‘tenant_id’ field is still supported, and the two fields are functionally equivalent.

• The feature “vlan-aware-vms” is available. To enable it, a service plugin named ‘trunk’ must be added to the option service_plugins in your neutron.conf. The plugin exposes two new extensions trunk and trunk_details. The plugin can work with multiple backends and in particular Neutron has support for ML2/openvswitch and ML2/linuxbridge. Even though Neutron API compatibility should be preserved for ports associated to trunks, since this is the first release where the feature is available, it is reasonable to expect possible functionality gaps for one or both drivers. These will be filled over time as being reported. The CLI is available via openstackclient, and python-neutronclient 5.1.0 or above. For more details, please check the networking guide.

Upgrade Notes

• All existing ports are considered to have ‘immediate’ IP allocation. Any ports that do not have this attribute should also be considered to have immediate IP allocation.

• The configuration option dhcp_lease_time was deprecated in the Havana cycle. This option is no longer supported. The option was replaced by dhcp_lease_duration.

Security Issues

• When working with the ML2/openvswitch driver, the “vlan-aware-vms” feature has the following limitations:

  • security groups do not work in conjunction with the iptables-based firewall driver.

  • if security groups are desired, the use of the stateful OVS firewall is required, however, that prevents the use of the DPDK datapath for OVS versions 2.5 or lower.

9.0.0.0b3

Prelude

• Call dhcp_release6 command line utility when releasing unused IPv6 leases for DHCPv6 stateful subnets. dhcp_release6 first appeared in dnsmasq 2.76

The default value for ‘external_network_bridge’ in the L3 agent is now ‘’.

The internal pluggable IPAM implementation – added in the Liberty release – is now the default for both old and new deployments. Old deployments are unconditionally switched to pluggable IPAM during upgrade. Old non-pluggable IPAM is deprecated and removed from code base.

New Features

• SR-IOV now supports egress minimum bandwidth configuration.

• Subnets now have a new property ‘service_types’. This is a list of port device owners, such that only ports with a matching device owner will be given an IP from this subnet. If no matching service subnet exists for the given device owner, or no service subnets have been defined on the network, the port will be assigned an IP from a subnet with no service-types. This preserves backwards compatibility with older deployments.

• net-mtu extension now recalculates network MTU on each network access, not just on creation. It now allows operators to tweak MTU related configuration options and see them applied to all network resources right after controller restart, both old and new.

• The new l2_adjacency extension adds an l2_adjacency field to the network, to indicate whether or not there is guaranteed L2 adjacency between the ports on that Network. Routed network implementations would typically set l2_adjacency to False.

• The neutron L3 agent now has the ability to load agent extensions, which allows other services to integrate without additional agent changes. An API for exposing the l3 agent’s router info data to the extensions is also provided so that extensions can remain consistent with router state.

• Users can now apply a QoS rule to a port or network to setup the minimum egress bandwidth per queue and port. The minimum egress bandwidth rule is applied to each port individually.

• New API extensions, ‘sorting’ and ‘pagination’, have been added to allow API users to detect if sorting and pagination features are enabled. These features are controlled by allow_sorting and allow_pagination configuration options.

Known Issues

• Absence of dhcp_release6 when DHCPv6 stateful addressing is in use may lead to bug 1521666. Neutron supports dhcp_release6 now, but if the tool is not available this leads to increased log warnings. Read bug report 1622002 for more details.

Upgrade Notes

• A version of dnsmasq that includes dhcp_release6 should be installed on systems running the DHCP agent. Failure to do this could cause DHCPv6 stateful addressing to not function properly.

• The rootwrap filters file dhcp.filters must be updated to include dhcp_release6, otherwise trying to run the utility will result in a NoFilterMatched exception.

• A new table ‘subnet_service_types’ has been added to cater for this feature. It uses the ID field from the ‘subnets’ table as a foreign key.

• The default value for ‘external_network_bridge’ has been changed to ‘’ since that is the preferred way to configure the L3 agent and will be the only way in future releases. If you have not explicitly set this value and you use the L3 agent, you will need to set this value to ‘br-ex’ to match the old default. If you are using ‘br-ex’, you should switch to ‘’, ensure your external network has a flat segment and ensure your L2 agent has a bridge_mapping entry between the external network’s flat segment physnet and ‘br-ex’ to get the same connectivity. If the external network did not already have the flat segment, you will need to detach all routers from the external networks, delete the incorrect segment type, add the flat segment, and re-attach the routers.

• API sorting and pagination features are now enabled by default.

• Existing networks with MTU values that don’t reflect configuration will receive new MTU values after controller upgrade. Note that to propagate new correct MTU values to your backend, you may need to resync all agents that set up ports, as well as re-attach VIFs to affected instances.

• During upgrade ‘internal’ ipam driver becomes default for ‘ipam_driver’ config option and data is migrated to new tables using alembic migration.

• The network_device_mtu option is removed. Existing users of the option are advised to adopt new configuration options to accommodate for their underlying physical infrastructure. The relevant options are global_physnet_mtu for all plugins, and also path_mtu and physical_network_mtus for ML2.

• The configuration options for default_ipv4_subnet_pool and default_ipv6_subnet_pool have been removed. Please use the is_default option of the create/update subnetpool API instead.

• tenant_id column has been renamed to project_id. This database migration is required to be applied as offline migration.

Deprecation Notes

• The allow_sorting and allow_pagination configuration options are deprecated and will be removed in a future release.

• Neutron controller service currently allows to load service_providers options from some files that are not passed to it via –config-dir or –config-file CLI options. This behaviour is now deprecated and will be disabled in Ocata. Current users are advised to switch to aforementioned CLI options.

• The ‘supported_pci_vendor_devs’ option is deprecated in Newton and will be removed in Ocata. The validation of supported pci vendors is done in nova-scheduler through the pci_passthrough_whitelist option when it selects a suitable hypervisor, hence the option is considered redundant.

• The non-pluggable ipam implementatios is deprecated and will be removed in Newton release cycle.

Bug Fixes

• Allow SR-IOV agent to run with 0 vfs

Other Notes

• In order to use QoS egress minimum bandwidth limit feature, ‘ip-link’ must support the extended VF management parameter min_tx_rate. Minimum version of ip-link supporting this parameter is iproute2-ss140804, git tag v3.16.0.

• At the time of writing, Neutron bandwidth booking is not integrated with Compute scheduler, which means that minimal bandwidth is not guaranteed but provided as best effort.

9.0.0.0b2

Prelude

Add options to designate external dns driver of neutron for SSL based connections. This makes it possible to use neutron with designate in scenario where endpoints are SSL based. Users can specify to skip cert validation or specify path to a valid cert in [designate] section of neutron.conf file.

Prior to Newton, the neutron-openvswitch-agent used ‘ovs-ofctl’ of_interface driver by default. In Newton, ‘of_interface’ defaults to ‘native’. This mostly eliminates spawning ovs-ofctl and improves performance a little.

Properly calculate overlay (tunnel) protocol overhead for environments using IPv4 or IPv6 endpoints. The ML2 plug-in configuration file contains a new configuration option, ‘overlay_ip_version’, in the ‘[ml2]’ section that indicates the IP version of all overlay network endpoints. Use ‘4’ for IPv4 and ‘6’ for IPv6. Defaults to ‘4’. Additionally, all layer-2 agents must use the same IP version for endpoints.

Prior to Newton, the default option for ‘ovsdb_interface’ was ‘vsctl’. In Newton ‘ovsdb_interface’ defaults to ‘native’. This change switches the way of communication with OVSDB from the ovs-vsctl tool to Open vSwitch python api to improve out-of-the-box performance for typical deployments.

Remove ‘quota_items’ configuration option from neutron.conf file. This option was deprecated since Liberty release and has no effect now.

Remove ‘router_id’ configuration option from the l3_agent.ini file. ‘router_id’ option has been defined in order to associate an l3-agent to a specific router when use_namespaces=False. It was deprecated after use_namespaces was removed in Mitaka release.

New Features

• Two new options are added to [designate] section to support SSL.

• First option insecure allows to skip SSL validation when creating a keystone session to initate a designate client. Default value is False, which means to always verify connection.

• Second option ca_cert allows setting path to a valid cert file. Default is None.

• Neutron switched to using oslo.cache library to cache port state in metadata agent. With it, more caching backends are now available, including Memcached and Mongo. More details in oslo.cache documentation.

Upgrade Notes

• The configuration option dnsmasq_dns_server was deprecated in the kilo cycle. This value is no longer supported.

• To retain the old default for neutron-openvswitch-agent, use ‘of_interface = ovs-ofctl’ in the ‘[ovs]’ section of your openvswitch agent configuration file.

• By default, the native interface will have the Ryu controller listen on 127.0.0.1:6633. The listen address can be configured with of_listen_address and of_listen_port options. Ensure that the controller has permission to listen at the configured address.

• Define the ‘overlay_ip_version’ option and value appropriate for the environment. Only required if not using the Default of ‘4’.

• To keep the old default value use ‘ovsdb_interface = vsctl’ in ‘[ovs]’ section of openvswitch_agent.ini (common path ‘/etc/neutron/plugins/ml2/openvswitch_agent.ini’) if there is a separate openvswitch agent configuration file; otherwise apply changes mentioned above to ml2_conf.ini (common path ‘/etc/neutron/plugins/ml2/ml2_conf.ini’).

• The native interface configures ovsdb-server to listen for connections on 127.0.0.1:6640 by default. The address can be configured with the ovsdb_connection config option. Ensure that ovsdb-server has permissions to listen on the configured address.

• Remove ‘quota_items’ configuration option from neutron.conf file.

• Remove ‘router_id’ configuration option from the l3_agent.ini file.

Deprecation Notes

• The option min_l3_agents_per_router is deprecated and will be removed for the Ocata release where the scheduling of new HA routers will always be allowed.

• The cache_url configuration option is deprecated as of Newton, and will be removed in Ocata. Please configure metadata cache using [cache] group, setting enable = True and configuring your backend.

Bug Fixes

• In order to fix the communication issues between SR-IOV instances and regular instances the FDB population extension is added to the OVS or linuxbridge agent. the cause was that messages from SR-IOV direct port instance to normal port instances located on the same hypervisor were sent directly to the wire because the FDB table was not yet updated. FDB population extension tracks instances boot/delete operations using the handle_port delete_port extension interface messages and update the hypervisor’s FDB table accordingly. Please note this L2 agent extension doesn’t support allowed address pairs extension.

Other Notes

• The value of the ‘overlay_ip_version’ option adds either 20 bytes for IPv4 or 40 bytes for IPv6 to determine the total tunnel overhead amount.

9.0.0.0b1

Prelude

Support configuration of greenthreads pool for WSGI.

A new rule has been added to the API that allows for tagging traffic with DSCP values. This is currently supported by the Open vSwitch QoS driver.

The Neutron server no longer needs to be configured with a firewall driver and it can support mixed environments of hybrid iptables firewalls and the pure OVS firewall.

Support for IPv6 addresses as tunnel endpoints in OVS.

Schedule networks on dhcp-agents with access to network

OFAgent has been removed in the Newton cycle.

By default, the QoS driver for the Open vSwitch and Linuxbridge agents calculates the burst value as 80% of the available bandwidth.

Several NICs per physical network can be used with SR-IOV.

New Features

• Return code for quota delete for a tenant whose quota has not been previously defined has been changed from 204 to 404.

• Neutron can apply a QoS rule to ports that mark outgoing traffic’s type of service packet header field.

• The Open vSwitch Neutron agent has been extended to mark the Type of Service IP header field of packets egressing from the VM when the QoS rule has been applied.

• The Neutron server now learns the appropriate firewall wiring behavior from each OVS agent so it no longer needs to be configured with the firewall_driver. This means it also supports multiple agents with different types of firewalls.

• The local_ip value in ml2_conf.ini can now be set to an IPv6 address configured on the system.

• DHCP schedulers use “filter_host_with_network_access” plugin method to filter hosts with access to dhcp network. Plugins can overload it to define their own filtering logic. In particular, ML2 plugin delegates the filtering to mechanism drivers.

Upgrade Notes

• OSprofiler support was introduced. To allow its usage the api-paste.ini file needs to be modified to contain osprofiler middleware. Also [profiler] section needs to be added to the neutron.conf file with enabled, hmac_keys and trace_sqlalchemy flags defined.

• In case you rely on the default ML2 path_mtu value of 1500 to cap MTU used for new network resources, please set it explicitly in your ml2_conf.ini file.

Deprecation Notes

• The ‘advertise_mtu’ option is deprecated and will be removed in Ocata. There should be no use case to disable the feature, hence the option is considered redundant. DHCP and L3 agents will continue advertising MTU values to instances. Other plugins not using those agents are also encouraged to advertise MTU to instances. The actual implementation of MTU advertisement depends on the plugin in use, but it’s assumed that at least DHCP option for IPv4 clients and Router Advertisements for IPv6 clients is supported.

• The tool neutron-debug is now deprecated, to be replaced with a new set of troubleshooting and diagnostic tools. There is no plan for removal in the immediate term, and not until comparable tools will be adequate enough to supplant neutron-debug altogether. For more information, please see https://blueprints.launchpad.net/neutron/+spec/troubleshooting

• The option [AGENT] prevent_arp_spoofing has been deprecated and will be removed in Ocata release. ARP spoofing protection should always be enabled unless its explicitly disabled via the port security extension via the API. The primary reason it was a config option was because it was merged at the end of Kilo development cycle so it was not considered stable. It has been enabled by default since Liberty and is considered stable and there is no reason to keep this configurable.

Security Issues

• OSprofiler support requires passing of trace information between various OpenStack services. This information is securely signed by one of HMAC keys, defined in neutron.conf configuration file. To allow cross-project tracing user should use the key, that is common among all OpenStack services he or she wants to trace.

Bug Fixes

• Missing OSprofiler support was added. This cross-project profiling library allows to trace various OpenStack requests through all OpenStack services that support it. To initiate OpenStack request tracing –profile <HMAC_KEY> option needs to be added to the CLI command. This key needs to present one of the secret keys defined in neutron.conf configuration file with hmac_keys option under the [profiler] configuration section. To enable or disable Neutron profiling the appropriate enabled option under the same section needs to be set either to True or False. By default Neutron will trace all API and RPC requests, but there is an opportunity to trace DB requests as well. For this purpose trace_sqlalchemy option needs to be set to True. As a prerequisite OSprofiler library and its storage backend needs to be installed to the environment. If so (and if profiling is enabled in neutron.conf) the trace can be generated via command - $ neutron –profile SECRET_KEY <subcommand>. At the end of output there will be message with <trace_id>, and to plot nice HTML graphs the following command should be used - $ osprofiler trace show <trace_id> –html –out result.html

• The default value for ML2 path_mtu option is changed from 1500 to 0, effectively disabling its participation in network MTU calculation unless it’s overridden in the ml2_conf.ini configuration file.

• Fixes Bug 1548193, removing ‘force_gateway_on_subnet’ configuration option. This will always allow adding gateway outside the subnet, and gateway cannot be forced onto the subnet range.

• Fixes bug 1572670

• The ‘physical_device_mappings’ of sriov_nic configuration now can accept more than one NIC per physical network. For example, if ‘physnet2’ is connected to enp1s0f0 and enp1s0f1, ‘physnet2:enp1s0f0,physnet2:enp1s0f1’ will be a valid option.

Other Notes

• Operators may want to tune the max_overflow and wsgi_default_pool_size configuration options according to the investigations outlined in this mailing list post. The default value of wsgi_default_pool_size inherits from that of oslo.config, which is currently 100. This is a change in default from the previous Neutron-specific value of 1000.

• Requires OVS 2.5+ version or higher with linux kernel 4.3 or higher. More info at OVS github page.

• The Openflow Agent(OFAgent) mechanism driver and its agent have been removed in favor of OpenvSwitch mechanism driver with “native” of_interface in the Newton cycle.

• The configuration option ‘force_gateway_on_subnet’ is removed. This will always allow adding gateway outside the subnet, and gateway cannot be forced onto the subnet range.