From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id ED2521FF13C for ; Thu, 02 Apr 2026 17:05:32 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 8E01D1DC81; Thu, 2 Apr 2026 17:06:02 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=tuX1hh+ekk4lUbKRySsxnJwozpUApTgJCXP/r8EuDFaRNxxj0/z9WVGn26rvrm9QhiBIBuQoeUcmUm3Vxc/yQhNsr06YYLVJ65KRRhyNGdDgV3rJJ6lDZMthB7cPjbRgSaRYLjKP9V+E0i6pF5H2/Hk/UuhP9mSxsOkxqEBWxD0LMFoh4DjEzPICtr2jMf1SzSRhWKqT3etd5mtVsVpLX4Wu0icJeIz5YV5kEHe+qE4l0mwyLugy7F1JRHR8hSv0c/2MfwaI66zONvisaPJDZ/VoRsysbIZQWFx9Qjtw+r6LmcU/YUH10VgBQSJe7YB6l1VQpzxjeY0HbuiM3coYMw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=aeEJ00dbdY8iLh4mR7Y/YlIvNXT9b4Q7PmOby7J0jtw=; b=bOB5Lly7sG6wihl8kp05KCXCmgLo/47frj+mLXRuHGEFFPJufawkhfxpTr+K8e46DULy6ElKetDrdNCw7mqcxAg1h5RpeUhQthFys/9kBKr+g9LKE6Ipgl/Q0R82e6twCXZbwn4RQWCVs2E46psPsz0X/ViCrx9JPXyNu1RHEjXwjdxdCR4VC+SeX15GhdKY6t5yj1WkMxNGv4FyEvRdjS7gY8AijEKHHNy6jvCTx6222rqAT9J5zcm+uwtJpj4lGKUSwQ3xRBRuIRygy+0fy/Z7cA+palRhYDuIIU7ODhHCsl/ZtKNZ+CLEscB4L/KMu6bVE+g+jLPCFX76yIlz2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 20.79.222.204) smtp.rcpttodomain=proxmox.com smtp.mailfrom=partimus.com; dmarc=bestguesspass action=none header.from=partimus.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primeLine.onmicrosoft.com; s=selector1-primeLine-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aeEJ00dbdY8iLh4mR7Y/YlIvNXT9b4Q7PmOby7J0jtw=; b=igLdv7CuJSfVTkKLBC3oQfWSKbpRfA5nkDufW8+4c567J111fScnE9W4mavQUIpYZX9LM621O5tqC7Sd6DWCx/f+ia6QRFMs4wiNncvBuz/1T1pW6vTxwUIq1d/NqjzNNg5Lu7/tqgJr7yfemEj7UrpoEB0mtI7lZPpNTYink1Q= X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 20.79.222.204) smtp.mailfrom=partimus.com; dkim=none (message not signed) header.d=none;dmarc=bestguesspass action=none header.from=partimus.com; Received-SPF: Pass (protection.outlook.com: domain of partimus.com designates 20.79.222.204 as permitted sender) receiver=protection.outlook.com; client-ip=20.79.222.204; helo=de2-emailsignatures-cloud.codetwo.com; pr=C Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=partimus.com; Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Thu, 2 Apr 2026 17:05:12 +0200 Message-ID: Subject: Re: ifupdown2: Severe race conditions and architectural issues due to async usage of netlink From: Robin Christ To: "Stefan Hanreich" , , "Christoph Heiss" X-Mailer: aerc 0.20.1-270-g2fb08ac189a1 References: In-Reply-To: X-ClientProxiedBy: FR0P281CA0268.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:b5::12) To DBBP194MB1164.EURP194.PROD.OUTLOOK.COM (2603:10a6:10:1e3::13) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: DBBP194MB1164:EE_|VE1P194MB0829:EE_|DB5PEPF00014B8F:EE_|VI6PPF1BEED0A34:EE_ X-MS-Office365-Filtering-Correlation-Id: ea931306-9c7f-4c10-e8bd-08de90c93fd3 X-MS-Exchange-AtpMessageProperties: SA X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|376014|10070799003|366016|1800799024|18002099003|56012099003|22082099003|55112099003; X-Microsoft-Antispam-Message-Info-Original: pItr1A0oAi5ql+qmhQzSI6xlMA5oasH+03XTNCSZs43uw/JRPJZ4St9Ic9eemAwfRHzIN9J8IS3R/3wi6l4lTLfW/0+WRCaPvgzins9UHdx38U1dmbpkcBENjd2PJEMy6hqKYdxzb4PUjdrQL+QQ2JwjuZuJSUZWNMUC6qXvwR0ByY+Ghu/G9h2bixeG3A6gnzhMAOQ+zy/6JwuPHI/1D0IMru9NtJfhEFLI1BxHJZxHWB0VBGT7A0DN0g944okSGznO0EteD3fdVrSCyC/jI/CtCrRQcf6qxvqkL+emEqaC+ua7kIfOBmRc7tofd7myHMVPhll9rEdMLF180T6WBxSQa15tScGSsXeQALFsuLDLCX9nwjWrfaIpY2ORGb6bjxac4YyvMk0ARP4k1G1883pmZF7eYc0zXfnmDBc5cETmrsEGKjJfyJ1csm1aZt13xAB+yzUwZd/VKxhsRQhfVOlPffrKtbOm6vT+2mLtIo3nBqGWfBZ/6BgOZ+6sLQWt22nTGGEZtzdrzuYeU4BlqxV4mrVZN1IxjFsORH0J3nwl0jHLiwGa1GpTtVJLydde8DmuYgIpg9bGGXmx9NRusXnCki8Rl23/4PgVv3ebjk4OaxHscaWKIjqstysJTqkk+/6IPXPFstVnq7sK/aQIV46E8cfC4cP2wD8EF2JulaW9ja3lot7pxsPo4InepFmR X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DBBP194MB1164.EURP194.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(10070799003)(366016)(1800799024)(18002099003)(56012099003)(22082099003)(55112099003);DIR:OUT;SFP:1102; X-Exchange-RoutingPolicyChecked: JlQW4Ay/EpuvTBy0FOtNZ7kI3gRqy8QGPRR4okK2yp/66iCRN6pHQRIoqlttiC4OlvGKE+EMpo0Dh+LOx1EVyolplgxF1Qp+4w/660agJ/057mqQFDAp31BpPwE/Dc481FRmwLLAHjygM3hHgQcfer/F9gLn8QLCPsHKusdAzlEzNI2Yzn3k5gtQdPI9tbapqy9IDF1tktic7r5AQZHyvIWSlajoZN9Rcquf22gLsTGpySlTZVy8robcaVzXy4TkzyaoVf+ov5SdXV47d04sqLkHM9Q7JHQfU6UmWq+eBlBKfosPY6HyezfDSuGhpZdVJKcU+YXLMp0elQCirUIMKg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1P194MB0829 X-CodeTwo-MessageID: 08946c42-1606-4cb9-9171-478e0a189a62.20260402150515@de2-emailsignatures-cloud.codetwo.com X-CodeTwoProcessed: true X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5PEPF00014B8F.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 2215eb7e-ab34-4160-32ed-08de90c93dab X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|36860700016|14060799003|376014|35042699022|82310400026|55112099003|56012099003|22082099003|18002099003; X-Microsoft-Antispam-Message-Info: 8Z9Yo/8QjkJoum5zuvZhpABlQSMpTHsA3N6LkT777fWBdmSozESy+O1Jf8j2ZBB7X1CRrAjNuE9C9W/9UxBILqOuV5V7sX1aFJSW5GnNZmovrbwsXDf35Qp+KN2nxevdiAZSnkptXc6z4lqTIgVL78GK9jl+9B0zP3jBDdpcQJPQNZZNwEGvzawCRsiI2TOEX6PDgnm7caVGPjP0wHdvRucA649IDtIHmIsWGnyR/7vtok26TtFqe2HmnmJYX1GiMcnyb/4Cx0VFhjHiGlv995sW183u24N+QQ/0NqH47kM9438b9X5K74CX/ophishCQYb5Jf7BECPCHZRyoytPd4sVNZ01aDaFd5Ym6n+a8JhRyT0hdGui2Vgimhf0GLVMh13/PKuKhGci4CFWNUOShLTDfVTXGbbmbz1VydcZh9G3/TryvVpuMXPav5TXt5cV9P36J+wtSH6be1wEePdl+wGXZSFkle0B9N7St58hfdQ5SUiuScf7Nl7aKL92twGBX4nCWBRg9BaJTTrXIWPerpzEWWYRU6mXf/qyDq02quhUvi8HvoLV+EBfC/gffPtTGcZQG9r3zUHu7AbfavW4veGxmbThn/ZsC4ItRxbei0fhS9KVHxTk9pgoOV23jZk4eme8WgwECqS0dIVobWuiSdzwJSygZ1iD1Y4+i5iwjlBd03DSSsrBrgS443H4PcsGHV74y7SQ1ClzUSpKOoeXmwDMNNiiBAinLgdm97ufd58= X-Forefront-Antispam-Report: CIP:20.79.222.204;CTRY:DE;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:de2-emailsignatures-cloud.codetwo.com;PTR:de2-emailsignatures-cloud.codetwo.com;CAT:NONE;SFS:(13230040)(1800799024)(36860700016)(14060799003)(376014)(35042699022)(82310400026)(55112099003)(56012099003)(22082099003)(18002099003);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: CwdWUv96KafzBQGWIWDSSrBzOG+gNK7qNaebnk1zGCRikT+osYZ3FzvO2sNs9CuUeFQ16CwYO+WERbVQUybgXjCWTsG7KW36EBwOkPHNhHEAsFPVOH6jtjCyFtFdVj8SIDzMZT3bAiXDwVi+CPP64h8FlVvIEE048QOlAnjfmrIKCamsUHa1njeknbKDd46rbs7QajByIoJ2Dy2S7ewT0KQMH1JAbfeWJEbBAMPaaXSAptB3tlxqJR7/KaVf6khXcNts1qt7iRUl46zWapP5iiuw+H+OkLMDLUArNkOF8uBEPX8/1A59FnvvpjMkRVqaRKtuelxqZKtAdA/2xi2+LEjsn0m3d85qc6bsHwtreJfbxAzBi4ieLibDNsIGVX3qB2+vvTACEm+ID2b/t8buK+8BoMbTurTAZOJ6YxaaLxZ8SVpHRC/y+gYkmDLgNZSK X-OriginatorOrg: partimus.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2026 15:05:16.5816 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ea931306-9c7f-4c10-e8bd-08de90c93fd3 X-MS-Exchange-CrossTenant-Id: c3afe0eb-a678-40d5-81aa-2389bbd04944 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c3afe0eb-a678-40d5-81aa-2389bbd04944;Ip=[20.79.222.204];Helo=[de2-emailsignatures-cloud.codetwo.com] X-MS-Exchange-CrossTenant-AuthSource: DB5PEPF00014B8F.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI6PPF1BEED0A34 X-SPAM-LEVEL: Spam detection results: 0 BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DMARC_MISSING 0.1 Missing DMARC policy SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: IIDG6TB67PNPRI5UQWN5Y3AS3PXDLPEL X-Message-ID-Hash: IIDG6TB67PNPRI5UQWN5Y3AS3PXDLPEL X-MailFrom: r.christ@partimus.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: >> 5. At some point, receive RTM_NEWNETCONF >> >> This will update the cache, and now the MTU is correct. >> [snip] > > :/ - maybe @Christoph can take a look as well? > I have to stand corrected though: Step 5 is not RTM_NEWNETCONF (this one wi= ll probably be received too, but it's not really used as it seems) Step 5 is triggered upon receiving RTM_NEWLINK (you receive a RTM_NEWLINK a= fter every configuration change), but the conclusion remains the same: You may (or rather: will) end up with periods where stale config is in the = cache > yeah, that should probably be fixed - or at least the warning removed, > because that is *not* the case - the MTU gets set and it's explicitly > logged. I did fix the warning in my patches, which I'm attaching for reference. > Unless I'm misremembering, only the MTU of the destination port should > matter in the forwarding decision. That's what I was trying to say. I doesn't matter for the bridged traffic i= tself while it's in the bridge, but the MTU of the interfaces in the bridge= matters. There may still be some weird side effects, check Ivan's blog post [1] for = some inspiration.. >> Wouldn't it make sense to set the bridge MTU, unless overridden manually= , to the lowest MTU of any enslaved interface that is **specified in the if= updown2 config** (to avoid issues with VM interfaces, that have a lower MTU= , lowering the overall bridge MTU)? > > Is this really the case - do you have a reproducer? Couldn't get the > bridge MTU to get lowered when plugging a tap interface. [...] Sorry, I should've been clearer: I was not referring to the bridge MTU gett= ing lowered automatically, e.g. by the Linux kernel. What I meant was: IF automatic bridge MTU is implemented in ifupdown2, it s= hould NOT simply fetch the enslaved interfaces and=20 iterate through them. This is because if you do ifreload and already have V= Ms running, ifupdown could fetch VM interfaces with a lower MTU and thus ac= cidently lower the bridge mtu. Therefore, IF automatic bridge MTU is implemented in ifupdown2, it should o= nly iterate through the slave interfaces that are configured in the ifupdow= n2 config. > In any case, the MTU should just be set everywhere explicitly in the > configuration to avoid this altogether... This is the best case, but I think sane default behaviour for users who do = not do this would make sense. >> Given the overall bad shape of ifupdown2 - What is the way forward? Will= ifupdown2 be replaced in the not-so-distant future? > > We've been discussing this internally and we're also watching the > discussion upstream on what network manager will be used for forky. But > aside from that, I cannot give you any concrete plans atm. > Alright, thanks for the info! I am attaching my patches from yesterday as a basis for discussion, please = let me know what you think! But those are not exactly in a shape where I'd consider sending them to the= mailing list as a pull request... [1] https://blog.ipspace.net/2025/03/linux-bridge-mtu-hell/ Patches: Patch 1/2: 0020-netlink-implement-dirty-workaround-for-mtu-cache-architectu= re.patch From: Robin Christ Date: Wed, 1 Apr 2026 14:07:30 +0200 Subject: netlink: Implement dirty workaround for MTU cache architectural issue --- ifupdown2/lib/iproute2.py | 3 +++ ifupdown2/lib/nlcache.py | 40 +++++++++++++++++++++++++++++++++++++++- 2 files changed, 42 insertions(+), 1 deletion(-) diff --git a/ifupdown2/lib/iproute2.py b/ifupdown2/lib/iproute2.py index 894afd3..8760d3f 100644 --- a/ifupdown2/lib/iproute2.py +++ b/ifupdown2/lib/iproute2.py @@ -550,6 +550,9 @@ class IPRoute2(Cache, Requirements): if is_link_up: self.link_down_force(ifname) =20 + # iproute2 should use netlink in the background - so this SHOULD W= ORK even + # when the RTM_NEWLINK notifying a potential change in MTU earlier + # has not arrived yet self.__execute_or_batch( utils.ip_cmd, "link set dev %s addrgenmode %s" % (ifname, Link.ifla_inet6_ad= dr_gen_mode_dict.get(addrgen)) diff --git a/ifupdown2/lib/nlcache.py b/ifupdown2/lib/nlcache.py index 2d37443..a8e11ff 100644 --- a/ifupdown2/lib/nlcache.py +++ b/ifupdown2/lib/nlcache.py @@ -405,7 +405,21 @@ class _NetlinkCache: """ try: with self._cache_lock: - self._link_cache[ifname].attributes[Link.IFLA_MTU].value = =3D mtu + # This function has an issue: + # Sometimes when it's used, we only have a barebones versi= on of the link in the cache + # because the netlink notification with all the attributes= , aka RTM_NEWLINK, + # has not been received yet + # This barebones version of the link in the cache + # does not have the Link.IFLA_MTU attribute, hence setting= this value will fail + #=20 + # this is a deeper architectural issue with how the netlin= k cache is used. + + # Dirty workaround for deeper architectural issues.. + if Link.IFLA_MTU not in self._link_cache[ifname].attribute= s: + self._link_cache[ifname].add_attribute(Link.IFLA_MTU, = mtu) + self._link_cache[ifname].attributes[Link.IFLA_MTU].is_= override_value =3D True + else: + self._link_cache[ifname].attributes[Link.IFLA_MTU].val= ue =3D mtu except Exception: pass =20 @@ -1355,6 +1369,30 @@ class _NetlinkCache: # here just in case? pass =20 + # Dirty Workaround: Merge the MTU + # if there is already a MTU value with is_override_value set, + # this means override_link_mtu was called for this link and we= should keep + # the override value instead of the new one coming from the ke= rnel, which will be stale + try: + cached_mtu =3D self._link_cache[ifname].attributes.get(Lin= k.IFLA_MTU) + + if cached_mtu and ("is_override_value" in cached_mtu.__dic= t__) and cached_mtu.is_override_value: + mtu_from_packet =3D None + if link.attributes.get(Link.IFLA_MTU): + mtu_from_packet =3D link.attributes[Link.IFLA_MTU]= .value + + if mtu_from_packet !=3D cached_mtu.value: + log.debug(f'_NetlinkCache add_link: Cached MTU for= {ifname} is an override value, keeping cached value instead of new value, = cached mtu: {cached_mtu.value}, new value in packet: {mtu_from_packet}') + link.attributes[Link.IFLA_MTU] =3D cached_mtu + else: + log.debug(f'_NetlinkCache add_link: Cached MTU for= {ifname} is an override value but new value in packet is the same as cache= d value, using value from packet to remove override status, cached / new mt= u: {cached_mtu.value}') + + except KeyError: + # link is not present in the cache + pass + except AttributeError: + pass + self._link_cache[ifname] =3D link =20 # For each altname, also cache the reference to the `Link` obj= ect Patch 2/2: 0021-bridge-fix-broken-mtu-warning.patch From: Robin Christ Date: Wed, 1 Apr 2026 14:39:47 +0200 Subject: bridge: Fix broken MTU warning Bridge would complain if you specify an MTU... Although it's quite the oppo= site: It should inform you that if you don't set an MTU, ifupdown2 will do stupid= things (those stupid things are so deeply rooted that we don't bother to fix them = right now...) --- ifupdown2/addons/address.py | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/ifupdown2/addons/address.py b/ifupdown2/addons/address.py index 46226a9..e739af7 100644 --- a/ifupdown2/addons/address.py +++ b/ifupdown2/addons/address.py @@ -431,7 +431,8 @@ class address(AddonWithIpBlackList, moduleBase): self.logger.warning("%s: invalid mtu %s: %s" % (ifaceobj.n= ame, mtu_str, str(e))) return False return self._check_mtu_config(ifaceobj, mtu_int, ifaceobj_getf= unc, syntaxcheck=3DTrue) - return True + else: + return self._check_mtu_config_none(ifaceobj, ifaceobj_getfunc,= syntaxcheck=3DTrue) =20 def syntax_check_addr_allowed_on(self, ifaceobj, syntax_check=3DFalse)= : if ifaceobj.get_attr_value('address'): @@ -801,13 +802,7 @@ class address(AddonWithIpBlackList, moduleBase): """ =20 retval =3D True - if (ifaceobj.link_kind & ifaceLinkKind.BRIDGE): - if syntaxcheck: - self.logger.warning('%s: bridge inherits mtu from its port= s. There is no need to assign mtu on a bridge' %ifaceobj.name) - retval =3D False - else: - self.logger.info('%s: bridge inherits mtu from its ports. = There is no need to assign mtu on a bridge' %ifaceobj.name) - elif ifaceobj_getfunc: + if ifaceobj_getfunc: if ((ifaceobj.link_privflags & ifaceLinkPrivFlags.BOND_SLAVE) = and ifaceobj.upperifaces): masterobj =3D ifaceobj_getfunc(ifaceobj.upperifaces[0]) @@ -847,6 +842,17 @@ class address(AddonWithIpBlackList, moduleBase): retval =3D False return retval =20 + + def _check_mtu_config_none(self, ifaceobj, ifaceobj_getfunc, syntaxche= ck=3DFalse): + retval =3D True + if (ifaceobj.link_kind & ifaceLinkKind.BRIDGE): + if syntaxcheck: + self.logger.info(f'bridge {ifaceobj.name} does not have mt= u assigned, will be set to default mtu from config, NO MTU INHERITANCE FROM= ITS PORTS!!') + else: + self.logger.info(f'bridge {ifaceobj.name} does not have mt= u assigned, will be set to default mtu from config, NO MTU INHERITANCE FROM= ITS PORTS!!') + + return retval + def _propagate_mtu_to_upper_devs(self, ifaceobj, mtu, ifaceobj_getfunc= ): """ :param ifaceobj: @@ -893,11 +899,14 @@ class address(AddonWithIpBlackList, moduleBase): self._propagate_mtu_to_upper_devs(ifaceobj, mtu, ifaceobj_= getfunc) return =20 - def _process_mtu_config_mtu_none(self, ifaceobj): + def _process_mtu_config_mtu_none(self, ifaceobj, ifaceobj_getfunc): =20 if (ifaceobj.link_privflags & ifaceLinkPrivFlags.MGMT_INTF): return =20 + if not self._check_mtu_config_none(ifaceobj, ifaceobj_getfunc): + return + cached_link_mtu =3D self.cache.get_link_mtu(ifaceobj.name) =20 if ifaceobj.link_kind: @@ -1126,7 +1135,7 @@ class address(AddonWithIpBlackList, moduleBase): =20 self._process_mtu_config_mtu_valid(ifaceobj, ifaceobj_getfunc,= mtu_int) else: - self._process_mtu_config_mtu_none(ifaceobj) + self._process_mtu_config_mtu_none(ifaceobj, ifaceobj_getfunc) =20 def up_ipv6_addrgen(self, ifaceobj): user_configured_ipv6_addrgen =3D ifaceobj.get_attr_value_first('ip= v6-addrgen')