Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 2083629

Summary: [Baremetal][PXE] Allow for setting the "next-server" field in the DHCPOFFER header
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Lucas Alvares Gomes <lmartins>
Component: ovn2.13Assignee: Lucas Alvares Gomes <lmartins>
Status: CLOSED CURRENTRELEASE QA Contact: Jianlin Shi <jishi>
Severity: high Docs Contact:
Priority: high    
Version: FDP 20.ICC: ctrautma, jiji, mmichels, ralongi
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-10-19 13:41:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
pcap captured when using the OVN DHCP server none

Description Lucas Alvares Gomes 2022-05-10 12:58:39 UTC
Created attachment 1878311 [details]
pcap captured when using the OVN DHCP server

During our tests PXE booting baremetal nodes using the OVN built-in DHCP server we found out that the PXE boot timed out when trying to reach the TFTP server that is responsible for the providing the iPXE image required for the PXE chainloading.

By comparing the DHCPOFFER packets (see attachments) sent by Dnsmasq and another one from the OVN DHCP server we noticed that the "next-server" field in the header was missing in OVN. We then did a test by hardcoding the IP of the TFTP server in the "next-server" field by changing the OVN code [0] and then we were able to deploy a baremetal node using PXE end-to-end.

The goal of this BZ is to find a way of setting that field in OVN. As a suggestion, I believe we could re-use the "tftp_server_address" DHCP config option (number 150) for this. When "tftp_server_address" is set, OVN should set it as a configuration option but also populate the "next-server" field in the DHCPOFFER header with the same IP value.

[0]
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index ae3da332c..6c2c75a64 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -2259,6 +2259,7 @@ pinctrl_handle_put_dhcp_opts(

     if (*in_dhcp_msg_type != OVN_DHCP_MSG_INFORM) {
         dhcp_data->yiaddr = (msg_type == DHCP_MSG_NAK) ? 0 : *offer_ip;
+        dhcp_data->siaddr = (ovs_be32) inet_addr("172.27.7.29");
     } else {
         dhcp_data->yiaddr = 0;
     }

Comment 3 Lucas Alvares Gomes 2022-05-11 12:06:53 UTC
I started coding this feature but then realized that "tftp_boot_address" is a Cisco proprietary option and it accepts multiple IPv4 address. So I think we will need a new configuration option this the next-server.

See: https://www.ovn.org/support/dist-docs/ovn-nb.5.html

options : tftp_server_address: optional string
          The DHCPv4 option code for this option is 150. The  option  con‐
          tains  one  or more IPv4 addresses that the client MAY use. This
          option is Cisco proprietary, the IEEE standard that matches with
          this requirement is option 66 (tftp_server).

Comment 4 Lucas Alvares Gomes 2022-05-19 13:05:08 UTC
First proposed version: https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/

Comment 5 Lucas Alvares Gomes 2022-06-03 13:49:37 UTC
The patch is now merged upstream: https://patchwork.ozlabs.org/project/ovn/patch/20220511142757.168196-1-lmartins@redhat.com/ 

Needs to be backported to whatever version is going to be used in OSP 17.1

Comment 6 OVN Bot 2022-09-29 04:05:15 UTC
ovn22.03 fast-datapath-rhel-8 clone created at https://bugzilla.redhat.com/show_bug.cgi?id=2130755
ovn22.03 fast-datapath-rhel-9 clone created at https://bugzilla.redhat.com/show_bug.cgi?id=2130756

Comment 7 Mark Michelson 2022-10-19 13:41:34 UTC
Marking this as "CLOSED CURRENTRELEASE". It appears that this issue was addressed by our bugzilla syncing tool during a period in late September and early October when there was a bug in the tool.