From owner-freebsd-net@FreeBSD.ORG Wed Mar 14 20:07:47 2007 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F00416A404; Wed, 14 Mar 2007 20:07:47 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail.classis.ru (classis.ru [213.248.60.120]) by mx1.freebsd.org (Postfix) with ESMTP id 17DAB13C489; Wed, 14 Mar 2007 20:07:47 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from citrin (unknown [81.19.65.167]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: citrin.citrin.ru) by mail.classis.ru (Postfix) with ESMTP id 9CCAF12279E2; Wed, 14 Mar 2007 23:07:45 +0300 (MSK) Date: Wed, 14 Mar 2007 23:06:52 +0300 From: Anton Yuzhaninov X-Mailer: The Bat! (v3.62.14) Professional Organization: Rambler X-Priority: 3 (Normal) Message-ID: <6110191101.20070314230652@citrin.ru> To: "Bruce M. Simpson" In-Reply-To: <45F81C0D.2000608@FreeBSD.org> References: <20070314115916.GB2713@cell.sick.ru> <45F81C0D.2000608@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re[2]: kern/106722: [net] [patch] ifconfig may not connect an interface to known network X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2007 20:07:47 -0000 Wednesday, March 14, 2007, 7:00:13 PM, Bruce M. Simpson wrote: BMS> Gleb Smirnoff wrote: >> AFAIK, the problem needs a more generic approach. I see two approaches. >> >> 1) Introduce RTM_CHANGEADD, a command that will forcibly add route, >> deleting all conflicting ones. Use this command in in_addprefix(). >> >> 2) In rt_flags field we still have several extra bits. We can use >> them to specify route source - RTS_CONNECTED, RTS_STATIC, RTS_XXX, >> where XXX is a routing protocol. When issuing RTM_ADD a route with >> a preferred source (e.g. CONNECTED vs STATIC) will override the old >> one. >> BMS> I understand that they are being proposed to address problems we BMS> currently have in the stack, i.e. that we do not support multipathing, BMS> though it is more than likely they will be blown away in future when the BMS> architecture changes (and it has to change). IMHO question is not related to multipathing. Kernel routes now don't contain administrative distance and it root of this problem. RTS_CONNECTED, RTS_STATIC is a hack adding some fixed AD values without increasing route size in memory. -- WBR, Anton Yuzhaninov