From owner-svn-src-all@FreeBSD.ORG Thu Mar 11 21:32:37 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8A05106564A; Thu, 11 Mar 2010 21:32:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id C41838FC2B; Thu, 11 Mar 2010 21:32:37 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5113D46B35; Thu, 11 Mar 2010 16:32:37 -0500 (EST) Date: Thu, 11 Mar 2010 21:32:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Qing Li In-Reply-To: <201003111756.o2BHukJu042449@svn.freebsd.org> Message-ID: References: <201003111756.o2BHukJu042449@svn.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r205024 - head/sys/net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 21:32:38 -0000 On Thu, 11 Mar 2010, Qing Li wrote: > The if_tap interface is of IFT_ETHERNET type, but it > does not set or update the if_link_state variable. > As such RT_LINK_IS_UP() fails for the if_tap interface. > > Also, the RT_LINK_IS_UP() needs to bypass all loopback > interfaces because loopback interfaces are considered > up logically as long as the system is running. > > This patch fixes the above issues by setting and updating > the if_link_state variable when the tap interface is > opened or closed respectively. Similary approach is > already done in the if_tun device. A couple of questions: (1) It used to be the case that quite a few interface drivers and types didn't have a notion of "link up" -- especially older ethernet devices. Do those all have the same problem? It was probably a design oversight that devices don't declare an explicit capability for "can report link state". (2) While loopback interfaces don't really have a link state, they can be administratively down -- should/do you check that as well as link state? And more generally, even if link is up, administratively down should be obeyed? Finally, it would be neat if there were a way to have information beyond link state influence the choice to balance to a particular route/interface. For example, imagine if I have a router with ECMP, and on the other side on a single ethernet segment, I have two DSL modems. The ethernet link will remain up, but I may (via out-of-band mechanisms, such as SNMP or an active probe) be able to tell that one of the DSL lines is down. Is there a way to push that information into the kernel currently without deleting the routes, and instead say "yeah, but for ECMP purposes this is 'down'"? Robert