From owner-freebsd-net Sat Mar 17 10:36:23 2001 Delivered-To: freebsd-net@freebsd.org Received: from spider.pilosoft.com (p55-222.acedsl.com [160.79.55.222]) by hub.freebsd.org (Postfix) with ESMTP id DA83137B718 for ; Sat, 17 Mar 2001 10:36:16 -0800 (PST) (envelope-from alex@acecape.com) Received: from localhost (alexmail@localhost) by spider.pilosoft.com (8.9.3/8.9.3) with ESMTP id NAA31298; Sat, 17 Mar 2001 13:41:18 -0500 (EST) X-Authentication-Warning: spider.pilosoft.com: alexmail owned process doing -bs Date: Sat, 17 Mar 2001 13:41:18 -0500 (EST) From: Alex Pilosov X-Sender: alexmail@spider.pilosoft.com To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 17 Mar 2001, Nick Rogness wrote: > > b) route-cache means fast lookup of destination gateway. Lookup of > > destination gateway may be slow (see d), and it makes sense to keep track > > of a TCP connection and 'fast-switch' (cisco lingo) the following packets, > > caching the following data (destination, ACL list) from the first packet. > > Usually route-cache is implemented in hardware in ASICs, but sometimes it > > may make sense to implement it in software (when overhead of connection > > tracking is less than overhead of route/acl lookup). > > > > Route-cache has nothing to do with policy routing (d) > > Who said anything about policy routing....where are you going with > this. Cisco's ip route-cache same-interface has nothing to do > with policy routing...and policy routing is not mentioned here. Policy routing is what you need to route packets based on their source address to properly do multihoming. You keep on using word 'route caching' while this whole thing has _nothing_ to do with route caching. ip route-cache same-interface makes _no actual changes to routing_. The only thing it does is allows "same-interface" flows (that arrive on one interface and leave on same interface) to be cached. Without ip route-cache same-interface, they'll still behave identically, only slower. It is not recommended in certain cases because fast-switching code is known to behave sometimes incorrectly. > > c) Running routing daemons has, once again, nothing to do with policy > > routing. It only means you are consensually exchanging routes with your > > neighbours. IF you are big enough to run BGP4 to your upstreams, you need > > to run routing daemon (gated/zebra/etc), and you are not likely to have > > need for policy routing, because your IPs are all equal: all networks you > > have can(will?) be delivered (and can be sent over) over any interface > > that you have. > > > > I didn't say anything about policy routing.... In the example I > gave, routing daemons could be used to get a routing table from > each upstream via BGP or whatever. Hence some routes would go out > ISP#1 and some would go out ISP#2. > > > > d) Policy routing is a generic term for any sort of routing (i.e. choosing > > of destination gateway for a packet) that is not exclusively based on > > destination IP address. It may be based on src/dest port, TOS field, > > source IP address, etc. FreeBSD has no support of that, to my knowledge. > > Linux has something called 'iproute2' which does support it, by having > > multiple routing tables, and a ruleset that decides which routing table to > > use based on packet details. > > > FreeBSD does implement *some* form of polciy routing. man ipfw Sorry. I was mistaken: indeed, you should be able to use 'ipfw fwd' to accomplish what you need. > > With policy routing, you indeed will be able to multihome, without any > > cooperation of your upstream (assuming strict filters on their ingress > > interfaces) and have things work. > > > Not dynamically you can't. Because you would have to know every > source IP and which interface it came in on, to send it back out > the same interface to get the packet back. You don't need to know the interface. You must route based on the source IP. I.E: ISP A ISP B \ / ra rb \ / your router | | | (local) (ra and rb are respectively edge routers on ISP A and B's end connected to you). Note: On local network, you'll be essentially having two logical networks (different IPs, subnet, etc) on the same wire. Its not clean, but its perfectly supported. Now, assume you have IPs 11.1.1.* from ISP B, and 11.1.2.* from ISP B. You configure both IPs to machines on your 'local' network, and have something like this on the router: ipfw from 11.1.1.0 fwd ra ipfw from 11.1.2.0 fwd rb If this is not what you wanted to accomplish, please correct me. -- -- Alex Pilosov | http://www.acecape.com/dsl CTO - Acecape, Inc. | AceDSL:The best ADSL in Bell Atlantic area 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :) New York, NY 10018 | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message