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 1765506

Summary: [RFE] OVN: DHCP server support for chainloading iPXE
Product: Red Hat Enterprise Linux Fast Datapath Reporter: Lucas Alvares Gomes <lmartins>
Component: OVNAssignee: lorenzo bianconi <lorenzo.bianconi>
Status: CLOSED ERRATA QA Contact: ying xu <yinxu>
Severity: medium Docs Contact:
Priority: medium    
Version: RHEL 8.0CC: ctrautma, kfida, lorenzo.bianconi, rkhan, sthennak
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovn2.13-20.09.0-8.el8fdn Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-12-01 15:07:02 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:

Description Lucas Alvares Gomes 2019-10-25 09:42:49 UTC 
Description of problem:

In order to chainload an iPXE image from an standard PXE boot the OVN DHCP server should be able to send different DHCP options in the DHCP response based on certain options existing in the DHCP request. For example:

When iPXE is enabled, Ironic relies on a specific tag in Neutron called "ipxe" [0] [1] (if option 175 is present the tag is set, if not the tag is unset). With that, the DHCP server will check if the DHCP request packet is coming from a standard PXE image (which does not set that option 175) and it will tell the machine to boot an iPXE image by pointing to one in the "bootfile-name" DHCP option in the response (this image lives in a TFTP server, since HTTP is not supported by standard PXE).

The machine will then load this new image and send out another DHCP request (now from iPXE, with the option 175 set) and the DHCP server will now see it and return the actual image that needs to be booted (also via the "bootfile-name" DHCP option)

Currently, OVN lacks that logic. The DHCP server in OVN has a static set of options and it will just return those in the DHCP response. 


[0] https://review.opendev.org/#/c/172040/
[1] https://github.com/openstack/ironic/blob/2b14daeec26d79e8dacb045acff174ebda4321f2/ironic/common/pxe_utils.py#L455
Comment 3 ying xu 2020-11-16 03:32:07 UTC 
verified on version:
# rpm -qa|grep ovn
ovn2.13-20.09.0-10.el8fdp.x86_64
ovn2.13-central-20.09.0-10.el8fdp.x86_64
ovn2.13-host-20.09.0-10.el8fdp.x86_64

this feature is for iPXE, 
the server will have two parameters:bootfile_name and bootfile_name_alt
# ovn-nbctl list dhcp-options
_uuid               : d6282309-4058-4789-a63c-0adae23675b2
cidr                : "42.42.42.0/24"
external_ids        : {}
options             : {bootfile_name="\"bootfile_name\"", bootfile_name_alt="\"bootfile_name_alt\"", lease_time="3600", router="42.42.42.254", server_id="42.42.42.254", server_mac="00:de:ad:ff:01:02"}

when the client send dhcp request to the server,with option 175(Etherboot),server should reply with bootfile_name parameter.


22:26:45.300732 IP (tos 0x0, ttl 64, id 39771, offset 0, flags [DF], proto UDP (17), length 275)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:00:00:01, length 247, xid 0x84a7de7c, Flags [Broadcast]
	  Client-Ethernet-Address 00:00:00:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    T175 Option 175, length 1: 1                ------------------------------------------------request with option175
22:26:45.300876 IP (tos 0x0, ttl 64, id 39768, offset 0, flags [DF], proto UDP (17), length 319)
    42.42.42.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 291, xid 0x84a7de7c, Flags [Broadcast]
	  Your-IP 42.42.42.2
	  Client-Ethernet-Address 00:00:00:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    BF Option 67, length 13: "bootfile_name"  --------------------------------------------------reply with bootfile_name
	    Lease-Time Option 51, length 4: 3600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 42.42.42.254
	    Server-ID Option 54, length 4: 42.42.42.254

if client send dhcp request without option175, server should reply with bootfile_name_alt parameter.
# ip netns exec vm1 dhclient -i vm1
22:29:03.226533 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:00:00:00:00:01, length 300, xid 0xb7750879, Flags [none]
	  Client-Ethernet-Address 00:00:00:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Discover
	    Requested-IP Option 50, length 4: 42.42.42.2
	    Parameter-Request Option 55, length 13: 
	      Subnet-Mask, BR, Time-Zone, Classless-Static-Route
	      Domain-Name, Domain-Name-Server, Hostname, YD
	      YS, NTP, MTU, Option 119
	      Default-Gateway
	    Client-ID Option 61, length 7: ether 00:00:00:00:00:01
22:29:03.227550 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 323)
    42.42.42.254.67 > 42.42.42.2.68: BOOTP/DHCP, Reply, length 295, xid 0xb7750879, Flags [none]
	  Your-IP 42.42.42.2
	  Client-Ethernet-Address 00:00:00:00:00:01
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message Option 53, length 1: Offer
	    BF Option 67, length 17: "bootfile_name_alt"         -----------------------reply with bootfile_name_alt
	    Lease-Time Option 51, length 4: 3600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    Default-Gateway Option 3, length 4: 42.42.42.254
	    Server-ID Option 54, length 4: 42.42.42.254
Comment 5 errata-xmlrpc 2020-12-01 15:07:02 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (ovn2.13 bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:5308