From owner-cvs-all Mon Aug 12 5:40:30 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1F0537B400; Mon, 12 Aug 2002 05:40:22 -0700 (PDT) Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C42E43E3B; Mon, 12 Aug 2002 05:40:16 -0700 (PDT) (envelope-from ru@whale.sunbay.crimea.ua) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id g7CCdrF43129; Mon, 12 Aug 2002 15:39:53 +0300 (EEST) (envelope-from ru) Date: Mon, 12 Aug 2002 15:39:53 +0300 From: Ruslan Ermilov To: Luigi Rizzo Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet in_rmx.c ip_input.c ip_var.h Message-ID: <20020812123953.GB41233@sunbay.com> References: <200208091449.g79EnNRh005472@freefall.freebsd.org> <20020809080953.B62786@iguana.icir.org> <20020811105249.GB11677@sunbay.com> <20020811054337.B84502@iguana.icir.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20020811054337.B84502@iguana.icir.org> User-Agent: Mutt/1.3.99i Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 11, 2002 at 05:43:37AM -0700, Luigi Rizzo wrote: > On Sun, Aug 11, 2002 at 01:52:49PM +0300, Ruslan Ermilov wrote: > ... > > > this reminds me... what do we gain from having one route cached ? > > > Most if not all boxes talk to multiple destinations anyways, > > >=20 > > This works on assumption that two or more consecutive packets to > > be forwarded are for the same destination. > >=20 > > > so we should rather leverage on the cache in ip_flow.c than > > > use this trick. > > >=20 > > Fast forwarding is incompatible with many standard things, as hinted > > in the inet(4) manpage. >=20 > i know that part of the code :) > But the info in the ipflow cache is reliable, and kept updated. > The incompatibility only comes from the fact that some processing > (e.g. firewalling, ipsec) is skipped in the fastforwarding case. >=20 Hmm, I think ipflow is subject to the same problem. If you had the 10/8 route, and forwarded some packets to 10.0.0.1, ipflow caches this (network) route. If you then add the host route to 10.0.0.1, nothing in the ipflow code (at least I don't see it) updates the ipflow's idea of the "best match route", and ipflow continues to use the old 10/8 route. Am I mistaken? Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9V6yZUkv4P6juNwoRAjevAJ90qCMDaIQC4Ibf44W8Bi1B7IZ5twCfUD9p wk9XTOp0cejh7hQ9M6Om8IQ= =EydG -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message