From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resdmta-h1p-028482.sys.comcast.net (resdmta-h1p-028482.sys.comcast.net [IPv6:2001:558:fd02:2446::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3507B3CB37 for ; Fri, 3 Feb 2023 18:20:43 -0500 (EST) Received: from resomta-h1p-027916.sys.comcast.net ([96.102.179.203]) by resdmta-h1p-028482.sys.comcast.net with ESMTP id O1NUpkJDt9T0yO5MHpHO41; Fri, 03 Feb 2023 23:20:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1675466441; bh=/d71UVQule8OoPa2gIniwU2HomMhrTspmgBA28kns4w=; h=Received:Received:Received:Message-ID:Date:MIME-Version:Subject: To:From:Content-Type:Xfinity-Spam-Result; b=nagZv6i3va/z5oluKERyCrUZoof3aBh8Enm27ktIGfzW0115EO1wgKGlqKCrafEcg kBk/uePiLkvaTkc7aQMx2VqUi8AmXus5kru/Vc22zbaro0Nrn9QPxlYSzI0X8/uuBd CD/6VkwjryxvWMQJH3SwA4odNduhwrZsdLSTd81K0TvyVAh4aGMTCXuDB8EMBkI7Mj uSWYnBLX5NB08LS3MRZYGy0yQOk4k+KH2QDN8prcNO9QRIVwgcyZf/RrQkMkTOLS5u Ygp123Zm1k/5BUhnVYr4zAsvmMSP8KVxUTIajQkCQNAUDssv8d/fiGrDvYZM/S/vH9 nFB0RvYLXwQFw== Received: from home.sewingwitch.com ([98.35.153.117]) by resomta-h1p-027916.sys.comcast.net with ESMTPA id O5Ltp8TJDNcJ7O5LvpGT4J; Fri, 03 Feb 2023 23:20:20 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvhedrudeguddgtdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefmvghnnhgvthhhucfrohhrthgvrhcuoehshhhivhgrsehsvgifihhnghifihhttghhrdgtohhmqeenucggtffrrghtthgvrhhnpeeilefffefftdehgefghfeikeevteelfeefieduieehkedvudfgteffjeejleevleenucffohhmrghinheprhgvughhrghtrdgtohhmnecukfhppeelkedrfeehrdduheefrdduudejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohephhhomhgvrdhsvgifihhnghifihhttghhrdgtohhmpdhinhgvthepleekrdefhedrudehfedruddujedpmhgrihhlfhhrohhmpehshhhivhgrsehsvgifihhnghifihhttghhrdgtohhmpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghlohgrtheslhhishhtshdrsghufhhfvghrsghlohgrthdrnhgvth X-Xfinity-VMeta: sc=0.00;st=legit Received: from [10.96.7.39] ([10.96.7.39]) (authenticated bits=0) by home.sewingwitch.com (8.14.7/8.14.7) with ESMTP id 313NKEgf024365 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 3 Feb 2023 15:20:14 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 home.sewingwitch.com 313NKEgf024365 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sewingwitch.com; s=default; t=1675466414; bh=/d71UVQule8OoPa2gIniwU2HomMhrTspmgBA28kns4w=; h=Date:Subject:To:References:From:In-Reply-To:From; b=j7mRoMLDTQ6ckiHYneYzbwdimkYpeTxgO2WH7FYDBRxiLI+IvIdVUJ8w0ts2fvP6q zkmizgYCQ9zOzVyZXmEhILeM/hnoeCDZrIzkpUwdtWM9drNfbsyYyUYaB8UzVKYm+z iO4cC5oY9gkMTmA3VBqeT7ix4HJWu0bHgpbuSGsM= Message-ID: <9c72e26c-4791-fc87-de07-d422852aee39@sewingwitch.com> Date: Fri, 3 Feb 2023 15:20:13 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: bloat@lists.bufferbloat.net References: <2DD7056F81C7C7313FBA93EA@[10.96.7.39]> <2027204.1675428884@dyas> Content-Language: en-US From: Kenneth Porter In-Reply-To: <2027204.1675428884@dyas> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 3.2 on 10.96.0.132 Subject: Re: [Bloat] speedtest-cli on multihomed gateway X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2023 23:20:43 -0000 On 2/3/2023 4:54 AM, Michael Richardson via Bloat wrote: > A new network namespace would certainly work, but it may be unmanageable > overkill. > > What you probably need are policy-based routes, which you can establish > statically and then --source ought to work. That's exactly what turned out to be the issue. I'd already planned to implement it to make some clients use the alternate ISP, but didn't realize it applies to packets with source address set to that interface. I'd read through a few tutorials and tested that and it worked! > I put these into "up" statements into my /etc/network/interfaes, but you say > you are running RHEL... I'm sure that there is a netplan way. > This also means that if you have a monitoring system elsewhere (smokeping or > something), and you ping each interface, then it will reply on that > interface. That turned out to be harder to figure out. RHEL 8 is a transition from traditional network scripts in /etc/sysconfig/network-scripts to NetworkManager connections. So the RH NM has to be able to understand the old files. I'm used to editing files with a text editor to make changes, but the RHEL docs don't expose the NM files and require one to use a manager program (nmcli) to make changes. I have no idea where my rules went when I changed them with nmcli. I do see the new per-interface route tables in the old scripts location. RHEL 9 moves over completely to NM, so I'll need to figure out how to migrate the config when I upgrade. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-policy-based-routing-to-define-alternative-routes_configuring-and-managing-networking BTW, I noticed that the numeric routing table IDs are 32-bit, but the reserved IDs are from 0-255. Some online tutorials specify that custom tables need to be in the 8-bit range. I suspect that the earliest implementation used a single byte for the table ID and it widened in later kernels. The example number used in the above documentation is 5000. So I'm using 2000 and 4000 for eno2 and eno4. (eno3 is the default link and eno1 is the LAN with an explicit global rule.)