From owner-freebsd-net@FreeBSD.ORG Thu Mar 7 14:03:47 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A8E1DE9 for ; Thu, 7 Mar 2013 14:03:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C63D8BF7 for ; Thu, 7 Mar 2013 14:03:46 +0000 (UTC) Received: (qmail 98964 invoked from network); 7 Mar 2013 15:17:08 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 7 Mar 2013 15:17:08 -0000 Message-ID: <51389E36.3020104@freebsd.org> Date: Thu, 07 Mar 2013 15:03:34 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Alexander V. Chernikov" Subject: Re: [patch] interface routes References: <513834E4.7050203@FreeBSD.org> <51384443.5070209@freebsd.org> <51387D4A.9030408@FreeBSD.org> <51388046.7040408@freebsd.org> <51389C29.8000407@FreeBSD.org> In-Reply-To: <51389C29.8000407@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 14:03:47 -0000 On 07.03.2013 14:54, Alexander V. Chernikov wrote: > On 07.03.2013 15:55, Andre Oppermann wrote: >> On 07.03.2013 12:43, Alexander V. Chernikov wrote: >>> On 07.03.2013 11:39, Andre Oppermann wrote: >>>> This brings up a long standing sore point of our routing code >>>> which this patch makes more pronounced. When an interface link >>>> state is down I don't want the route to it to persist but to >>>> become inactive so another path can be chosen. This the very >>>> point of running a routing daemon. So on the link-down event >>>> the installed interface routes should be removed from the routing >>>> table. The configured addresses though should persist and the >>>> interface routes re-installed on a link-up event. What's your >>>> opinion on it? >>> >>> This is exactly what is done in current code for IPv4: >>> if_down calls if_unroute(), it cals prctlinput() for every interface >>> address, and domain-dependent function like rip_ctlinput calls >>> in_ifscrub() cleaning given interface route. >>> However, address route (/32) still remains (but route daemons, at least >>> bird, tends to ignore it since it is not listed as valid interface >>> address/mask). >> >> IF_DOWN and link state down are not the same thing. When the cable >> is unplugged the link state goes down but not the interface. > > Ups. I've missed 'link' keyword. > Imho 'operational down' should behave exactly the same as 'admin down' > e.g. delete interface routes from route table. > It should be not very hard to do. Are you to implement it after the pinning patch? ;-) -- Andre