Bug 2044150

Summary:	[RFE] Raise proper exception for MTU
Product:	Red Hat Enterprise Linux 9	Reporter:	Gris Ge <fge>
Component:	nmstate	Assignee:	Gris Ge <fge>
Status:	CLOSED ERRATA	QA Contact:	Mingyu Shi <mshi>
Severity:	medium	Docs Contact:	Mayur Patil <maypatil>
Priority:	medium
Version:	9.1	CC:	ferferna, jiji, jishi, maypatil, mshi, network-qe, pasik, phoracek, sfaye, till, ysegev
Target Milestone:	rc	Keywords:	FutureFeature, Triaged
Target Release:	9.2	Flags:	pm-rhel: mirror+
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	.The `min-mtu` and `max-mtu` properties added to MTU on all interfaces Previously, an exception message was not clear enough to understand the supported MTU ranges. This update introduces the `min-mtu` and `max-mtu` properties to all interfaces. As a result, `nmstate` will indicate the supported MTU range when the desired MTU is out of range.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-09 07:30:59 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:
Bug Depends On:
Bug Blocks:	1876539, 2137267

Description Gris Ge 2022-01-24 06:30:35 UTC

Description of problem:

CNV team would like to see different error/exception when MTU value is invalid.

The kernel has error message:
mtu greater than device maximum

Need to provide better exception:

This helps for developers debugging this, but from OpenShift UX perspective it is not much better than the previous state. Ff this message won't appear in nmstatectl output (ideally as **the** reason), the user would need to log into the node and dive into NetworkManager logs. That's not something we would expect anybody to do.

Are there any plans to improve nmstate error handling so a user interfacing with nmstatectl (or nmstate library) would be able to deduce what is wrong in their configuration from nmstate's output, without diving into logs of underlying components?




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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 Gris Ge 2022-01-24 06:34:31 UTC

Possible fix:

The kernel has IFLA_MIN_MTU and IFLA_MAX_MTU which could be used to determine
the valid MTU range.

Before we applied the desire state to backend, we can raise ValueError if MTU
not fit into that range.

Hi Petr,

Is this meet your expectation?

Comment 3 Petr Horáček 2022-02-10 12:01:26 UTC

If the ValueError then explains that "The desired state cannot be applied, MTU ... is out of range ...", then it's perfect for me.

Comment 4 Gris Ge 2022-02-14 08:10:53 UTC

*** Bug 1812559 has been marked as a duplicate of this bug. ***

Comment 5 Gris Ge 2022-08-03 06:50:04 UTC

Patch sent to upstream: https://github.com/nmstate/nmstate/pull/1994


Introduce new property `min-mtu` and `max-mtu` to all interface:

```yaml
interfaces:
  - name: ens3
    type: ethernet
    state: up
    mtu: 1500
    min-mtu: 68
    max-mtu: 65535
```

A pre-apply failure/error will be raised if desired MTU not in the supported range.

Also changing this feature request to RHEL 9.2.

Comment 11 Mingyu Shi 2022-10-24 09:38:48 UTC

Verified with:
nmstate-2.2.0-0.alpha.20221014.el9.x86_64
NetworkManager-1.40.0-1.el9.x86_64

Given an interface, `nmstatectl show` shows its min-mtu and max-mtu.
When the mtu in desired state is out of the range, it raises:
NmstateError: InvalidArgument: Desired MTU 67 for interface veth0 is smaller than minimum allowed MTU 68
or
NmstateError: InvalidArgument: Desired MTU 65536 for interface veth0 is bigger than maximum allowed MTU 65535

But when ipv6 is enabled, allowed minimum mtu is 1280, which nmstate cannot friendly prompts and it raises the error at verification:
NmstateError: VerificationError: Verification failure: veth0.interface.mtu desire '1200', current '1280'

Comment 18 errata-xmlrpc 2023-05-09 07:30:59 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 (nmstate 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-2023:2190