From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=mur.at Authentication-Results: passt.top; dkim=pass (3072-bit key; unprotected) header.d=mur.at header.i=@mur.at header.a=rsa-sha256 header.s=dkim2 header.b=t8hO/zGs; dkim-atps=neutral Received: from efeu.mur.at (efeu.mur.at [89.106.208.42]) by passt.top (Postfix) with ESMTPS id 18DBB5A026E for ; Mon, 21 Sep 2026 11:34:53 +0200 (CEST) Received: from [192.168.4.117] (lan1.raspi.ma39.ffgraz.net [10.12.1.243]) by efeu.mur.at (Postfix) with ESMTPSA id 27FE640660; Mon, 21 Sep 2026 11:34:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mur.at; s=dkim2; t=1789983291; bh=mX/aJrFtIJj3DD7Hl4hzBwQFOpOaGoMLNvAPdQ0ztus=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=t8hO/zGseZwdtgc21vNd8je4X3gJuTiq7YCVpbcPvdJxVouktlahJIgBWaVoDHWao 6CPEkMFkJUH662afQ4ctxUmY/9qPJKBpnAxAs1mKurG9RtfdoCjas2s5BcVjhEgQBM j/2+f/v0DZJRcfbe2vTgVhmFy3BA51G+ZCDuvwpMpGCNvWHwavsQUtm1T2Ril+6xS2 IopAs3aVLQEoOc/SO3NWTUYBigwQ3+ynEJhn3ioF80wZTr3s0rdrgIVYWDvpBvGYm9 sUVbs7sehrRynJEIJbSPndRSDZOlRL7XYv5LW6UZ5yXxyBilbYAcy+fiozKB1pkZD9 2svTiFRuCm2bx4o/XSPojN5fqf8ahG+Ee3/0KsClS0Xq/NZEOLzA/3iueEjXIWQtlB s02acde0FRbFWBbpqeFxq3YYoJdO7MkFtJ/8k3Aoqo1uAN+Lj6ragBLhSofmuCDsnt NosIXud5bMCW1NRTBzptmAe3+EeaRXNOBow5nLal3fLRaHrrv5y Message-ID: Date: Mon, 21 Sep 2026 11:34:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Martin Schitter Subject: Re: [PATCH v2 3/3] Optimize route dependency solver. To: Stefano Brivio References: <20260908181631.537802-1-ms+git@mur.at> <20260908181631.537802-4-ms+git@mur.at> <20260917210822.681fa49a@elisabeth> <8ce40343-41fa-4195-87da-de425b56f5ea@mur.at> <20260919150739.5d1f34ca@elisabeth> Content-Language: de-DE, en-US In-Reply-To: <20260919150739.5d1f34ca@elisabeth> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-MailFrom: ms+git@mur.at X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: HDEQIQXNEUOT43W3Q2QVPW2HS4N6OIKX X-Message-ID-Hash: HDEQIQXNEUOT43W3Q2QVPW2HS4N6OIKX X-Mailman-Approved-At: Mon, 21 Sep 2026 14:07:15 +0200 CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 9/19/26 15:07, Stefano Brivio wrote: > Just a quick comment before you risk losing a lot of time (I'm really > not sure though): there*might* be interdependencies between routes in > 1. and between routes in 2., especially with 'nexthop' objects. And > IPv6 has several scopes. Maybe it all works thought, I haven't checked > your iproute reference yet. This alternative approach is looking for route table entries in exactly the same tables and scopes. There is no difference in this regard. It's just using a more rational strategy to minimize dependency errors. The most common cause for EHOSTUNREACH and ENETUNREACH errors are related to attempts adding a route without having defined the local exit capabilities first. There are still a few other possible reasons causing these particular errors (policy routing, disabled interfaces, etc.), but those cases are also not solved by any of our previous solutions! The errors just got ignored after many useless loops and costly operations. You can iterate as often as you like over this list of route entries and try to add them, but the amount of dependency errors will stay the same after just a few attempts (those, which define the elementary local host and network route connectivity information). We don't have to solve a complex network of transitive dependency relations, but only respect the much simpler order of dependency relations between very few different classes of entries. Well, that's at least my current understanding of this issue. But I still have to further think about it and test it in practice...