From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 03:47:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D64D16A4CE for ; Tue, 18 Nov 2003 03:47:24 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9248A43FDD for ; Tue, 18 Nov 2003 03:47:23 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id C246565371; Tue, 18 Nov 2003 11:47:22 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45050-02; Tue, 18 Nov 2003 11:47:22 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [82.147.19.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 85A8765319; Tue, 18 Nov 2003 11:47:21 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 1A4235; Tue, 18 Nov 2003 11:47:09 +0000 (GMT) Date: Tue, 18 Nov 2003 11:47:09 +0000 From: Bruce M Simpson To: David Gilbert Message-ID: <20031118114709.GG87527@saboteur.dek.spc.org> Mail-Followup-To: David Gilbert , freebsd-net@freebsd.org References: <16312.61495.127407.633302@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16312.61495.127407.633302@canoe.dclg.ca> cc: freebsd-net@freebsd.org Subject: Re: Knowing a route multiply. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2003 11:47:24 -0000 On Mon, Nov 17, 2003 at 10:58:47AM -0500, David Gilbert wrote: > This works on Linux ... and fails miserably on FreeBSD. I would like > to change this behaviour to either a) replace the route with the > interface route or b) know two routes for a destination and choose > one. Have you tried filtering the route on Router B to ensure it doesn't get added in the first place as a workaround? Have you run 'route -nv monitor' during the process and observed what the sequence of events is as far as the routing socket is concerned? a) I'd be curious as to whether an RTM_ADD or an RTM_CHANGE is issued in this case. Strictly speaking, RTM_CHANGE shouldn't work, but it does... according to Keith Sklower's paper on the original 4.2BSD routing implementation, changing the destination/next-hop of a route isn't allowed. b) is the ideal behaviour but we can't implement until after 5.2-RELEASE is out the door. BMS