From owner-freebsd-net@FreeBSD.ORG Sat Mar 9 19:18:04 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 0AB9EE8B; Sat, 9 Mar 2013 19:18:04 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 2339D6E7; Sat, 9 Mar 2013 19:18:02 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id 12so824752wgh.3 for ; Sat, 09 Mar 2013 11:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=Vo2XatOVIi1H9+9J+ZkiPtFJDTs0Nf5R27czcbeFKvM=; b=c7QJCwLUWI+UDQFVBsk1cGZPxXWWVS3neWNsZExVlk2MvQmlfCglGa10tt8ePkU267 /TkdYldy4zj/YWyV0N7ljcqxJHXrCXmblXg+zd044YhiOJ0AlrzpTh1X2ilxrsWeJnIS sKI9hQq+RIlIvKa7oNUOAkpUuEWWFZTYgTqonoa6ZnowLM52J2MrUJn5tU7SWOTuWaVz ybiMUtJgtWZRvPR6518pgGSrVt0AwjYOXG9MVOh9RJD1LwGMEmG71jfrYmnIh9HBxlad SnZWePQPKp9OKmbh+CYH4gZlw1AEU+srkMb/cBGxsOBjmv5diQfbrfz+n5wQd5bM1fG1 BIzQ== X-Received: by 10.180.82.33 with SMTP id f1mr4727528wiy.13.1362856682282; Sat, 09 Mar 2013 11:18:02 -0800 (PST) Received: from [192.168.1.35] ([188.141.28.166]) by mx.google.com with ESMTPS id c15sm6550408wiw.3.2013.03.09.11.18.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 11:18:01 -0800 (PST) Subject: Re: [patch] interface routes Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20130307214205.GD50035@funkthat.com> Date: Sat, 9 Mar 2013 19:17:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5205A02F-E886-4B7E-8494-1D92F930933B@gmail.com> References: <513834E4.7050203@FreeBSD.org> <51384443.5070209@freebsd.org> <20130307214205.GD50035@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1499) Cc: "Alexander V. Chernikov" , Andre Oppermann , 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: Sat, 09 Mar 2013 19:18:04 -0000 On Mar 7, 2013, at 9:42 PM, John-Mark Gurney wrote: > Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 = +0100: >>> Adding interface address is handled via atomically deleting old = prefix and=20 >>> adding interface one. >>=20 >> 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? >>=20 >> Other than these points I think your code is fine and can go >> into the tree. >=20 > The issue that I see with this is that if you bump your cable, all > your connections will be dropped, because as soon as they try to send > something, they'll get a no route to host, and this will break the > TCP connection... If we keep the routes when the link goes down, > the packet will be queued or dropped (depending upon ethernet driver), > but the TCP connection will not break... >=20 > --=20 > John-Mark Gurney Voice: +1 415 225 5579 >=20 > "All that I will do, has been done, All that I have, has not." Maybe this can be made a option that can be turned on when needed. What you describe can be very undesirable for a workstation/laptop or a = server, but a router that itself does not have many connections originating or = terminating on it could actually benefit from this. The current state is actually much worse for routers. A link down does = not do anything, and while there may be a alternative route to be installed for example from = OSPF, the interface without link pertains its routes and effectively blackholes all traffic. -- Nikolay