From owner-freebsd-bugs Fri Apr 30 12:10: 4 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 40A1E15490 for ; Fri, 30 Apr 1999 12:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA79540; Fri, 30 Apr 1999 12:10:02 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Fri, 30 Apr 1999 12:10:02 -0700 (PDT) Message-Id: <199904301910.MAA79540@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bill Fenner Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes Reply-To: Bill Fenner Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/10778; it has been noted by GNATS. From: Bill Fenner To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/10778: "ipforward_rt" is not cleared when routing table changes Date: Fri, 30 Apr 1999 12:09:47 -0700 I agree with Archie, although it's more like all cached routes should be cleared when the routing table changes in a way that affects the cached route. Scenario: - default route exists. Start TCP connection, which caches the default route. - add a host route for the endpoint of the TCP connection pointing out a different interface (perhaps a secure VPN interface as Archie mentioned). - TCP continues to use the default route. The only way to get TCP to stop using the default route is to delete the default route and then re-add it, which is a little too disruptive. (I first saw this problem occur in earnest when I added route caching to the kernel multicast tunnel code -- multicast tunnels are pretty long-lived) Unfortunately, the current route cache architecture has no facility to deal with this problem. There is no list of cached routes, and there is no way to notify cached routes that a change has occurred. If anyone cares to work on this, I'd imagine storing the destination of each cached route in a patricia tree would make it easy to determine the subset of cached routes that need to be invalidated when a given new route is added. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message