Use of OVN Networking¶
OVN is largely considered an evolution of OVS. While it is recommended that operators continue to utilize OVS with Ironic, OVN has an attractive a superset of capabilities and shifts some of the configuration of networking away from configuration files, towards a service modeled at serving a more scalable software defined networking experience. However, as with all newer technologies, there are caveats and issues. The purpose of this documentation is to help convey OVN’s state, capabilities, and provide operators with the context required to navigate their path forward.
OVN is under quite a bit of active development, and this information may grow out of date quickly. We’ve provided links to help spread the information and enable operators to learn the current status.
Historically, while OVN has included a DHCP server, this DHCP server has not had the capability to handle clients needing custom attributes such as those used by PXE and iPXE to enable network boot operations.
Typically, this has resulted in operators who use OVN with Bare Metal to
continue to operate the
neutron-dhcp-agent service, along with setting
OVN configuration appropriate to disable OVN from responding to DHCP requests
for baremetal ports. Please see
for more information on this setting.
As of the 2023.2 Release of Ironic, The Ironic project can confirm that OVN’s DHCP server does work for PXE and iPXE operations when using IPv4, OVS version 3.11, and OVN version 23.06.0.
Support for IPv6 is presently pending changes to Neutron, as IPv6 requires
additional configuration options and a different pattern of behavior, and
thus has not been tested. Your advised to continue to us the
neutron-dhcp-agent if you need IPv6 at this time. Currently this support
is being worked in Neutron
change 890683 and
Use of OVN with HTTPBoot interfaces has not been explicitly tested by the Ironic project, and is unlikely to take place until after integrated IPv6 support with Neutron is ready for use. The project does not expect any specific issues, but the OVN DHCP server is an entirely different server than the interfaces were tested upon.
Maxmium Transmission Units¶
OVN’s handling of MTUs has been identified by OVN as being incomplete. The reality is that it assumes the MTU is not further constained beyond the gateway, which sort of works in some caess for virtual machines, but might not be applicable with baremetal because your traffic may pass through lower, or higher MTUs.
Ideally, your environment should have consistent MTUs. If you cannot have consistent MTUs, we recommend clamping the MTU and Maximum Segment Size (MSS) using your front end router to ensure igress traffic is sized and fragmented appropriately. Egress traffic should inherent it’s MTU size based upon the DHCP service configuration.
A items you can keep track of regarding MTU handling:
To clamp the MTU and MSS on a linux based router, you can utilize the following command:
ip route add $network via $OVN_ROUTER advmss $MAX_SEGMENT_SIZE mtu lock $MTU
NAT of TFTP¶
Because the NAT and Connection Tracking layer gets applied differently with OVN, as the router doesn’t appear as a namespace or to the local OS kernel, you will not be able to enable NAT translation for Bare Metal Networks under the direct management of OVN, that is if you don’t have a separate TFTP service running from with-in that network.
This is a result of the kernel of the OVN gateway being unable to associate
and handle return packet directly as part of the connection tracking layer.
No direct work around for this is known, but generally Ironic encourages the
use of Virtual Media where possible to sidestep this sort of issue and ensure
a higher operational security posture for the deployment. Users of the
redfish hardware type can learn about
Virtual media boot in our Redfish documentation.
Creation of FIPs, such as those which may be used grant SSH access to a internal node on a network, for example which may be used by Tempest, establishes a 1:1 NAT rule. When this is the case, TFTP packets cannot transit OVN and network boot operations will fail.
Due to the aformentioned NAT issues, we know Rescue operations may not work.
This is being tracked as bug 2033083.
PXE boot of GRUB¶
Initial testing has revelaed that EFI booting Grub2 via OVN does not appear to work with OVN. For some reason, Grub2 believes the network mask is incorrect based upon the DHCP interaction, and results in a belief that the TFTP server is locally attached.
For example, if a client is assigned
10.1.0.13/28, with a default
10.1.0.1, and a tftp-sever of
then grub2 believes it’s default route is 10.0.0.0/8.
This is being tracked as bug 2033430 until we’re better able to understand the root cause and file a bug with the appropriate project.
OVN is designed to provide packet handling in a distributed fashion for a each compute hypervisor in a cloud of virtual machines. However with Bare Metal instances, you will likely need to have a pool of dedicated “network nodes” to handle OVN traffic.
Chassis as Gateway¶
The networking node chassis must be configured to operate as a gateway.
This can be configured manually, but should (as far as Ironic is aware) be configured by Neutron and set on interfaces matching the bridge mappings. At least, it works that way in Devstack.
trunk ml2 plugins as supplied with Neutron
must be enabled.
If you need to attach to the network…¶
For example if you need to bind something into a network for baremetal,
above and beyond a dedicated interface, you will need to make the attachment
br-ex integration bridge, as opposed to
br-int as one would
have done with OVS.
VTEP Switch Support¶
Alpha-quality support was added to Ironic for OVN VTEP switches in API version
1.90. When the keys
port_id are set in
port.local_link_connection, Ironic will pass them on
to Neutron to be included in the binding profile to enable OVN support.
There are reports of this approach working, but Ironic developers do not have access to physical hardware to fully test this feature. If you have any feedback for this feature, please reach out to the Ironic community.
It is presently unknown if it is possible for OVN to perform and enable VXLAN
attachments to physical ports on integrated devices, thus operators are advised
to continue to use
vlan networking with their hosts with existing ML2