Bug 166926 - dhcp ignores "option interface-mtu 9000;" in dhcpd.conf
Summary: dhcp ignores "option interface-mtu 9000;" in dhcpd.conf
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
(Show other bugs)
Version: 4
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jason Vas Dias
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-28 01:37 UTC by Larry Dillon
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version: 3.0.2-20
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 06:10:11 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Larry Dillon 2005-08-28 01:37:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6

Description of problem:
In /etc/dhcpd.conf, option interface-mtu 9000; is ignored by either the client or the server, not sure how to know which.

Non-standard MTU's (eg., not 1500) have not worked in Linux DHCP in the two years I've been trying.

MTU's > 1500 (aka "Jumbo Frames") are only supported on gigabit NIC's AFAIK.

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

How reproducible:

Steps to Reproduce:
1.given a working DHCP client and server with gigabit NIC's and jumbo frame clean switch,
2. add the line "option interface-mtu 9000;" to /etc/dhcpd.conf
3. client fails to obtain specified MTU.

Actual Results:  /sbin/ifconfig shows:

Expected Results:  /sbin/ifconfig should show:

Additional info:

if, on the client, one does "/sbin/ifconfig eth0 mtu 9000" , the client accepts the MTU value.

The work-around is putting the above line in /etc/rc.local, but this fails to work on a network restart.

Comment 1 Jason Vas Dias 2005-08-29 23:45:15 UTC
This is now fixed with: 
{dhcp,dhclient}-3.0.2-20_FC4 (submitted to FC4 HEAD revision and to fc4-updates) 
{dhcp,dhclient}-3.0.3-4 (Rawhide) and
{dhcp,dhclient}-3.0.3-4_FC4 (DHCP 3.0.3 compiled for FC4, available at: 
                             http://people.redhat.com/~jvdias/dhcp/FC4 ) .

The dhcpd and dhclient binaries always handled the interface-mtu option fine:
o On the server, dhcpd.conf contains an interface-mtu setting, eg.
' subnet ... { ... interface-mtu 9000; ... } '

o On the client, the generic /etc/dhclient.conf file or the per-interface ($IF)
  specific /etc/dhclient-${IF}.conf file MUST contain a 'request' option
  containing 'interface-mtu'; ie, if you want dhclient to request all the 
  default options AND interface-mtu, /etc/dhclient{,$IF}.conf must contain :
  'request subnet-mask,  broadcast-address,  time-offset,  routers,
           domain-name,  domain-name-servers, host-name,  nis-domain,
           nis-servers,  ntp-servers, interface-mtu;

Then the dhcpd server sends the interface-mtu option and the dhclient 
receives it.

But the dhclient-script was taking no account of any ${new_interface_mtu} 
option that may have been placed in its environment by dhclient.

The new dhclient-script does make the MTU setting if an interface-mtu option
is set :
    if [ -n ${new_interface_mtu} ]; then
       /sbin/ip link set $interface mtu $new_interface_mtu ;

To enable handling of other site-specific (non-default) DHCP options,
I've added support for interface UP/DOWN hooks to dhclient script; when
an interface $IF is being brought up with a new address / routes, then
  if the /etc/dhclient-${IF}-up-hooks script exists, it is sourced immediately
    after the interface named $IF has been brought up.
  if the /etc/dhclient-up-hooks script exists, it is sourced immediately
    after any interface has been brought up .
When an interface $IF is being brought down:
  if the /etc/dhclient-${IF}-down-hooks script exists, it is sourced 
    immediately before the interface named $IF is to be brought down.
  if the /etc/dhclient-down-hooks script exists, it is sourced 
    immediately before any interface is to be brought down .

In addition, if the default option 'time-offset' is specified, dhclient-script
now handles it.

Note You need to log in before you can comment on or make changes to this bug.