Skip to content
Closed
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions interface-definitions/include/dhcp/option-v4.xml.i
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,18 @@
</constraint>
</properties>
</leafNode>
<leafNode name="interface-mtu">
<properties>
<help>Interface MTU</help>
<valueHelp>
<format>u32:1-16</format>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why 1-16?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the RFC, it's a 16bit value. But looking at it now, I think I misread how the notation in that file works and it should probably just be u16?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as the values chosen for the bounds - I'm open to any ideas on the best values to use.

I admit they're somewhat arbitrary choices (though I'm sure you recognize the upper bound as Jumbo)

In terms of standards, we could use 576 for the minimum. It's unreasonably small, but mentioned in the IPv4 RFC (RFC 791 section 3.1):

All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.

The IPv6 RFC RFC 8200, section 5 requires a minimum MTU of 1280 - but this is DHCP IPv4, so I don't think we need to be troubled with that

I can't imagine 576 actually being used anywhere. At the same time, I've actually come close to needing to go below 1280 before on IPv4 interfaces (due to use of multiple layers of tunnels). So 576 seems reasonable.

<description>Client interface MTU</description>
</valueHelp>
<constraint>
<validator name="numeric" argument="--range 1200-9000"/>
</constraint>
</properties>
</leafNode>
<leafNode name="ip-forwarding">
<properties>
<help>Enable IP forwarding on client</help>
Expand Down
1 change: 1 addition & 0 deletions python/vyos/kea.py
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,7 @@
'ipv6_only_preferred': 'v6-only-preferred',
'captive_portal': 'v4-captive-portal',
'capwap_controller': 'capwap-ac-v4',
'interface_mtu': 'interface-mtu',
}

kea6_options = {
Expand Down
7 changes: 7 additions & 0 deletions smoketest/scripts/cli/test_service_dhcp-server.py
Original file line number Diff line number Diff line change
Expand Up @@ -225,6 +225,7 @@ def test_dhcp_single_pool_options(self):
server_identifier = bootfile_server
ipv6_only_preferred = '300'
capwap_access_controller = '192.168.2.125'
interface_mtu = '1420'

pool = base_path + ['shared-network-name', shared_net_name, 'subnet', subnet]
self.cli_set(pool + ['subnet-id', '1'])
Expand All @@ -233,6 +234,7 @@ def test_dhcp_single_pool_options(self):
self.cli_set(pool + ['option', 'name-server', dns_1])
self.cli_set(pool + ['option', 'name-server', dns_2])
self.cli_set(pool + ['option', 'domain-name', domain_name])
self.cli_set(pool + ['option', 'interface-mtu', interface_mtu])
self.cli_set(pool + ['option', 'ip-forwarding'])
self.cli_set(pool + ['option', 'smtp-server', smtp_server])
self.cli_set(pool + ['option', 'pop-server', smtp_server])
Expand Down Expand Up @@ -365,6 +367,11 @@ def test_dhcp_single_pool_options(self):
['Dhcp4', 'shared-networks', 0, 'subnet4', 0, 'option-data'],
{'name': 'ip-forwarding', 'data': 'true'},
)
self.verify_config_object(
obj,
['Dhcp4', 'shared-networks', 0, 'subnet4', 0, 'option-data'],
{'name': 'interface-mtu', 'data': interface_mtu},
)

# Time zone
self.verify_config_object(
Expand Down
Loading