Bug 1395512

Summary: [RFE] ipxe should obey DHCP option 26 for MTU
Product: Red Hat Enterprise Linux 7 Reporter: Dan Callaghan <dcallagh>
Component: ipxeAssignee: Neil Horman <nhorman>
ipxe sub component: ipxe-bootimgs QA Contact: Raviv Bar-Tal <rbartal>
Status: CLOSED DUPLICATE Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ailan, chayang, juzhang, kai, knoel
Version: 7.3Keywords: FutureFeature, Patch
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-17 13:38:14 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 Dan Callaghan 2016-11-16 04:49:38 UTC
Description of problem:
We are running ipxe in OpenStack instances, using a small disk image containing ipxe.lkrn, similar to the approach described here:
https://kimizhang.wordpress.com/2013/08/26/create-pxe-boot-image-for-openstack/

The instances are attached to Neutron virtual networks, which internally inside OpenStack are using some Ethernet encapsulation which means the network MTU visible to the OpenStack instances is less than the standard Ethernet 1500 bytes. The DHCP server provided by Neutron is correctly configured to serve up the smaller MTU in DHCP option 26 (in our case it is using 1400). There is a bit more background about OpenStack MTU issues here:
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html

ipxe ignores DHCP option 26 and assumes that an IPv4-on-Ethernet network interface supports the full 1500-byte MTU.

Actually in its sending path when calculating TCP transmit window, ipxe already assumes a very conservative MTU of 1280. The problem is it advertises its TCP MSS assuming the full 1500 MTU. As a result, if ipxe makes a TCP connection to a nearby host on a segment with 1500 MTU but no fragmenting router in between, the TCP MSS will be too large and packets sent by the other end will get dropped.

The end result is that the TCP connection will appear to stall with no data received, if the sender is transmitting large packets (for example fetching a kernel image over HTTP). Note that some very small HTTP responses will be unaffected, as will any TCP connections which pass over WAN links or anything else which happens to have a small enough MTU.

Version-Release number of selected component (if applicable):
ipxe-bootimgs-20160127-5.git6366fa7a.el7

How reproducible:
reliably, in this particular OpenStack instance

Steps to Reproduce:
1. Create and upload a disk image containing ipxe to Glance, using the technique described in the article above, or by using beaker-create-ipxe-image.
(We hit this problem while working on Beaker's OpenStack integration which uses ipxe disk images.)
2. Boot the image on an OpenStack instance in a Neutron virtual network with MTU less than 1500.
3. Use imgfetch or a similar command, to pull down a large kernel image from an HTTP server on a LAN segment with MTU 1500.

Actual results:
The imgfetch download stalls at 0% after receiving HTTP headers. Observe that the TCP MSS advertised by ipxe is 1460, which is larger than it can actually receive.

Expected results:
HTTP transfer should complete. TCP MSS should be based on the MTU supplied by DHCP option 26.

Additional info:
I wrote a patch for ipxe to obey DHCP option 26 and posted it upstream:
http://lists.ipxe.org/pipermail/ipxe-devel/2016-November/005261.html

Comment 3 Dan Callaghan 2017-04-11 23:10:52 UTC
FYI I think this is probably fixed by this upstream ipxe commit (though I haven't tested yet):

https://git.ipxe.org/ipxe.git/commit/16aed6e5ce808615df95c7767b4dd8793c398d93

Comment 4 Neil Horman 2018-08-17 13:38:14 UTC
I agree, it seems to be fixed by that commit, and we have an ipxe update scheduled for 7.7

*** This bug has been marked as a duplicate of bug 1597210 ***