Can you please install the latest NM RPM (1.10.2-14) and check if the issue still happens?

If so, please provide NM logs at trace level (set level=TRACE in the [logging] section of /etc/NetworkManager/NetworkManager.conf, reboot the system and attach the output of 'journalctl -u NetworkManager -b').

Thanks.

I found logs for the same (?) issue at:

 https://bugzilla.redhat.com/show_bug.cgi?id=1540901#c4

but they are for an older version of NM, so the needinfo from comment 2 is still valid.

Hello,

Thanks for your reply.

I have upgraded my system to below but I still see the same behaviour.

kernel-3.10.0-862.3.2.el7.x86_64
NetworkManager-1.10.2-14.el7_5.x86_64


I tried to setup same

  NIC  -->  TEAM  --> VLAN --> Bridge 

# nmcli connection add type team con-name team0 ifname team0 ipv4.method disabled ipv6.method ignore mtu 9000 config '{ "runner": {"name":"lacp", "fast_rate":true }}'
# nmcli connection add type team-slave con-name team0-ens3 ifname ens3 mtu 9000 master team0
# nmcli connection add type vlan con-name team0.10 ifname team0.10 id 10 dev team0 ipv4.method disabled ipv6.method ignore connection.master team0-bridge connection.slave-type bridge
# nmcli connection add type bridge con-name team0-bridge ifname team0-bridge ipv4.method manual ipv6.method ignore ipv4.addresses "11.0.0.1/24"

# ip a |grep -i team
3: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master team0 state UP group default qlen 1000
9: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
10: team0.10@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue master team0-bridge state UP group default qlen 1000
11: team0-bridge: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc noqueue state DOWN group default qlen 1000
    inet 11.0.0.1/24 brd 11.0.0.255 scope global noprefixroute team0-bridge

# reboot

# ip a| grep -i team
3: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master team0 state UP group default qlen 1000
4: team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
5: team0.10@team0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master team0-bridge state UP group default qlen 1000
6: team0-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 11.0.0.1/24 brd 11.0.0.255 scope global noprefixroute team0-bridge

I have uploaded trace logs as suggested. Please have a look and suggest.

Created attachment 1449385 [details]
NetworkManager trace logs for mtu issue

(In reply to Venkatesh Kavtikwar from comment #0)
> Where I tried to setup below with mtu 9000 but after reboot mtu is changing
> to 1500 for VLAN and bridge device
> 
>   NIC  -->  TEAM  --> VLAN --> Bridge 

Can you please try setting the MTU to 9000 also for the VLAN and bridge connections:
 
> # nmcli connection add type vlan con-name team0.10 ifname team0.10 id 10 dev
> team0 ipv4.method disabled ipv6.method ignore connection.master team0-bridge
> connection.slave-type bridge

Here, append 'mtu 9000' to the command.

> # nmcli connection add type bridge con-name team0-bridge ifname team0-bridge
> ipv4.method manual ipv6.method ignore ipv4.addresses "11.0.0.1/24"

and here too.

Otherwise, the MTU is inherited by the ethernet interface at the time the VLAN is created, which basically depends on timing. We probably could improve that.

Hello,

Thanks for your reply.

If I set "mtu" for Bridge and VLAN then it is applying "9000" mtu properly but as per the understanding virtual device should carry forward the "mtu" set on base device.

Instead of  below setup :

NIC  -->  TEAM  --> VLAN --> Bridge 


if I do below then I need not to set mtu (9000) on VLAN and Bridge interfaces.

NIC  --> VLAN --> Bridge 


#  nmcli con add type vlan ifname ens3.10 con-name ens3.10 id 10 dev ens3 ipv4.method disabled ipv6.method ignore connection.master ens3-bridge connection.slave-type bridge

# nmcli connection add type bridge con-name ens3-bridge ifname ens3-bridge ipv4.method manual ipv6.method ignore ipv4.addresses "10.0.0.1/24"

# nmcli con add type ethernet ifname ens3 con-name ens3 ipv4.method disabled ipv6.method ignore 802-3-ethernet.mtu 9000


# reboot

# ip a | grep -i ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
4: ens3.10@ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue master ens3-bridge state UP group default qlen 1000
5: ens3-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000
    inet 10.0.0.1/24 brd 10.0.0.255 scope global noprefixroute ens3-bridge

Pushed branch bg/mtu-rh1586191 for review.

+         g_object_get (setting, property_name, &mtu, NULL);

mtu should be type guint (altough, of course guint32 is a typedef for unsigned). But anyway, wouldn't it be simpler, to drop the "property_name" and "global_property_name" argument, and then:


  if (setting_type == NM_TYPE_SETTING_WIRED) {
      if (setting)
          mtu = nm_setting_wired_get_mtu (NM_SETTING_WIRED (setting));
      global_property_name = "ethernet.mtu";
  } else {
      ...


yes, it's less "generic", but actually clearer...




+         if (   config
+             && source < NM_DEVICE_MTU_SOURCE_IP_CONFIG
+              && nm_ip4_config_get_mtu (config)) {

indentation




+         if (   source > priv->mtu_source
+             || (priv->mtu_source == NM_DEVICE_MTU_SOURCE_PARENT && source == priv->mtu_source))
               mtu_desired = mtu;

it's probably the case, but it's not obvious that at this place @mtu != 0. Could you add a "&& mtu != 0" to the "if"?






+         if (   source > priv->mtu_source
+             || (priv->mtu_source == NM_DEVICE_MTU_SOURCE_PARENT && source == priv->mtu_source))
               mtu_desired = mtu;
          else {
-              if (config)
-                   mtu_desired = nm_ip4_config_get_mtu (config);
-              else
               mtu_desired = 0;
-              if (!mtu_desired && !priv->mtu_initialized) {
-                   /* there is no MTU specified, and this is the first commit of the MTU.
-                    * Reset a per-device MTU default, as returned from get_configured_mtu().
-                    *


in the else case, it's not obvious that mtu is zero (but probably true). Can you add an "nm_assert (mtu == 0)"?




+    if (success && source != NM_DEVICE_MTU_SOURCE_NONE)
+         priv->mtu_source = source;
+

I think this should move to where "priv->mtu_initialized = TRUE;" was previously. It doesn't matter whether we had success. At least, "!success" might indicate that nm_platform_link_set_mtu() or nm_device_ipv6_sysctl_set() failed. What would it mean, if only one of them fails, while the other succeeds? Why not remember the mtu_source, that we tried to configure?

(In reply to Thomas Haller from comment #9)
> +         g_object_get (setting, property_name, &mtu, NULL);
> 
> mtu should be type guint (altough, of course guint32 is a typedef for
> unsigned). But anyway, wouldn't it be simpler, to drop the "property_name"
> and "global_property_name" argument, and then:
> 
> 
>   if (setting_type == NM_TYPE_SETTING_WIRED) {
>       if (setting)
>           mtu = nm_setting_wired_get_mtu (NM_SETTING_WIRED (setting));
>       global_property_name = "ethernet.mtu";
>   } else {
>       ...
> 
> 
> yes, it's less "generic", but actually clearer...

I guess it's a matter of opinion, but I find it strange that we have a get_configured_mtu() class method that calls back to the device where the different devices are handled with a switch. But I can change it if you insist :)

> indentation

Fixed.

> +         if (   source > priv->mtu_source
> +             || (priv->mtu_source == NM_DEVICE_MTU_SOURCE_PARENT && source
> == priv->mtu_source))
>                mtu_desired = mtu;
> 
> it's probably the case, but it's not obvious that at this place @mtu != 0.
> Could you add a "&& mtu != 0" to the "if"?

Yes.

> 
> +         if (   source > priv->mtu_source
> +             || (priv->mtu_source == NM_DEVICE_MTU_SOURCE_PARENT && source
> == priv->mtu_source))
>                mtu_desired = mtu;
>           else {
> -              if (config)
> -                   mtu_desired = nm_ip4_config_get_mtu (config);
> -              else
>                mtu_desired = 0;
> -              if (!mtu_desired && !priv->mtu_initialized) {
> -                   /* there is no MTU specified, and this is the first
> commit of the MTU.
> -                    * Reset a per-device MTU default, as returned from
> get_configured_mtu().
> -                    *
> 
> 
> in the else case, it's not obvious that mtu is zero (but probably true). Can
> you add an "nm_assert (mtu == 0)"?

It's not always zero... it can just be that mtu != 0 and the source has the same or less priority than current one.


> +    if (success && source != NM_DEVICE_MTU_SOURCE_NONE)
> +         priv->mtu_source = source;
> +
> 
> I think this should move to where "priv->mtu_initialized = TRUE;" was
> previously. It doesn't matter whether we had success. At least, "!success"
> might indicate that nm_platform_link_set_mtu() or
> nm_device_ipv6_sysctl_set() failed. What would it mean, if only one of them
> fails, while the other succeeds? Why not remember the mtu_source, that we
> tried to configure?

Because of this:

> +         if (   source > priv->mtu_source
> +             || (priv->mtu_source == NM_DEVICE_MTU_SOURCE_PARENT && source == priv->mtu_source))

We try to set mtu from a source only once (except for PARENT, for which we always adjust the MTU). If we fail to change the mtu and store the source (for example CONNECTION), at the next call with source CONNECTION we won't try again to set it. This happens for example, if a slave's master isn't activated yet and we try to change its MTU to a value greater than master's.
In other words, priv->mtu_source is the source from which we successfully set the current mtu.

Merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=cbfe9a6e1621775609c63675beae051cc018dfed

and nm-1-12.

Note for QE: the issue was that at boot the VLAN MTU was inherited by the parent using the value at the time the VLAN was activated. Since the parent device could be still activating as well, the parent MTU could be the default one (not changed yet by NM).  Since this depends on timing, it's difficult to reproduce.  We already have a test (@vlan_mtu_from_parent) to check the VLAN MTU inheritance, but unless a specific course of events happens during NM start, it succeeds also without the fix.

Running well with 1.12.0-6 version.

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, 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-2018:3207