This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 566873

Summary: DHCP Client does not request interface-mtu by default
Product: [Fedora] Fedora Reporter: Derek Atkins <warlord>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: jpopelka, mbreuer, rnichols42
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dhcp-4.1.1-9.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 571719 (view as bug list) Environment:
Last Closed: 2010-03-08 22:38:03 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 571719, 694264    

Description Derek Atkins 2010-02-20 00:10:53 EST
Description of problem:

Client does not request the interface-mtu by default.  My network configuration recently changed and I need to reset the MTU on all my hosts.  I thought I could just do this by setting interface-mtu in my dhcp server, but alas that is not sufficient as the dhcp clients don't request the interface-mtu by default.

Right now I need to go through every client manually and either set the MTU by hand or do:

  echo "request interface-mtu;" > /etc/dhclient.conf

This is annoying, and sort of defeats the purpose of centralizing the management of this kind of configuration.

Version-Release number of selected component (if applicable):

dhclient-4.1.1-5.fc12.x86_64

How reproducible:

100%

Steps to Reproduce:
1. set the interface-mtu option in your dhcp server
2. obtain a lease
3. notice that the client doesn't honor the MTU.
  
Actual results:

MTU was still 1500

Expected results:

MTU should match what the dhcp server has configured..  And it shouldn't require me to touch every machine to specifically tell it to request the information -- what happens when I need to make the NEXT change to my network config?

Additional info:

Handling the interface-mtu was fixed in FC4.  But requesting it was never done.
Comment 1 Jiri Popelka 2010-02-22 05:43:31 EST
(In reply to comment #0)
> Client does not request the interface-mtu by default.
By default, the ISC DHCP client requests the subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, name-servers, domain-search, nis-domain, nis-servers, and ntp-servers options.
 
> Right now I need to go through every client manually and either set the MTU by
> hand or do:
> 
>   echo "request interface-mtu;" > /etc/dhclient.conf
> 
Note that if you enter a ’request’ statement, you over-ride the default requested options and these options will not be requested.
In this case, it is best to ’also request’ the additional options:
   echo "also request interface-mtu;" > /etc/dhclient.conf

> MTU should match what the dhcp server has configured..  And it shouldn't
> require me to touch every machine to specifically tell it to request the
> information -- what happens when I need to make the NEXT change to my network
> config?
This should help you:
https://lists.isc.org/mailman/htdig/dhcp-users/2007-December/005153.html

So in your case
add this line to your dhcpd.conf:
  option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 23, 24, 40, 41, 42, 26;
This force the server to send all above mentioned options plus interface-mtu (code 26). See RFC 2132 for these option codes.

I'll ask upstream if there's no problem with adding interface-mtu to the default requested options list. And if they answer ;-) I'll fix it in Fedora.
Comment 2 Fedora Update System 2010-02-22 11:26:17 EST
dhcp-4.1.1-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/dhcp-4.1.1-8.fc12
Comment 3 Jiri Popelka 2010-02-22 12:39:12 EST
(In reply to comment #1)
> (In reply to comment #0)
> > Client does not request the interface-mtu by default.
> By default, the ISC DHCP client requests the subnet-mask, broadcast-address,
> time-offset, routers, domain-name, domain-name-servers, host-name,
> name-servers, domain-search, nis-domain, nis-servers, and ntp-servers options.
I was wrong.
name-servers and domain-search are not requested by default by dhcpv4 client.
These are default for dhcpv6 client.

> So in your case
> add this line to your dhcpd.conf:
>   option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 23, 24, 40, 41,
> 42, 26;
Correct is:
    option dhcp-parameter-request-list 1, 28, 2, 3, 15, 6, 12, 40, 41, 42, 26;
Comment 4 Fedora Update System 2010-02-24 01:14:06 EST
dhcp-4.1.1-8.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763
Comment 5 Jiri Popelka 2010-02-24 11:39:41 EST
Derek,

can you test the dhclient from updates-testing (see above comment) to see if it correctly requests interface-mtu option ?       Thanks
Comment 6 Fedora Update System 2010-02-25 12:29:18 EST
dhcp-4.1.1-9.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763
Comment 7 Fedora Update System 2010-02-26 22:32:50 EST
dhcp-4.1.1-9.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dhcp'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-2763
Comment 8 Fedora Update System 2010-03-08 22:37:54 EST
dhcp-4.1.1-9.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Michael Breuer 2010-03-16 14:22:02 EDT
grrrr... I think this should have been optional behavior. Just spent a bit of time trying to figure out why my MTU went to 576 over the weekend. Thought it was a kernel upgrade (2.6.34-rc1) ... nope. Blamed Cablevision... that was a fun call... nope... searched and found this!

Broke quite a lot... dns for one isn't fragmenting properly (edns udp).

So yes, it works. But the fix should have included a default dhcp client conf file to disable until explicitly turned on by the user.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 10 Jiri Popelka 2010-03-17 07:17:51 EDT
So if I understand it right the DHCP server is sending you interface-mtu option (with value 576), but you don't want your dhclient to use it, because it breaks you your configuration ?

Whose is the server ? Your ISP (Cablevision) ?
I don't understand why is the server sending interface-mtu option with value which breaks quite a lot.
Comment 11 Michael Breuer 2010-03-17 10:43:15 EDT
The server supplying mtu of 576 is Cablevision (Optimumonline). With MTU=576, I'm getting sky2 rx length errors on EDNS udp packet activity where the dns response is not being fragmented properly upstream. I'm assuming that pmtu upstream is larger than 576 and discovery through the cable modem isn't correct. 

The issue I've got isn't that CV has bad configuration, it's that a change to the dhcp client was pushed out that changed system default behaviour without sufficient warning.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 12 Jiri Popelka 2010-03-18 09:03:37 EDT
Michael,
there's separate Bug #574629 for this problem.
Comment 13 Michael Breuer 2010-03-18 12:27:44 EDT
Actually, that issue and mine is the result of the implementation of this fix.

My issue is that the default client behaviour changed from NOT requesting MTU to requesting and setting MTU. The change is correct, no argument there... it's the potential impact of manifesting problems due to incorrect dhcp server settings that is at issue - i.e., bug fixes that potentially cause manifestation of other issues needs to be dealt with more carefully.

Bug #574629 is what happened to me (and to others) as a direct consequence of the update made to fix this problem. The real issue (probably best moved to mailing lists) is policy for distributing fixes that can reasonable be anticipated to result in significant changes to systems beyond fixing the reported issue.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 14 Robert Nichols 2010-03-18 17:16:31 EDT
(In reply to comment #10)
> So if I understand it right the DHCP server is sending you interface-mtu option
> (with value 576), but you don't want your dhclient to use it, because it breaks
> you your configuration ?
> 
> Whose is the server ? Your ISP (Cablevision) ?
> I don't understand why is the server sending interface-mtu option with value
> which breaks quite a lot.    

Same problem here with Comcast, at least for some DHCP servers.  Until I found this bug report I couldn't figure out why my interface kept coming up with MTU=576 on one machine while another got MTU=1500 (both FC-12, both connected directly to the cable modem).