Date: Sat, 17 Mar 2001 11:55:09 -0600 (CST) From: Nick Rogness <nick@rogness.net> To: Alex Pilosov <alex@acecape.com> Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Subject: Re: same interface Route Cache Message-ID: <Pine.BSF.4.21.0103171139120.16998-100000@cody.jharris.com> In-Reply-To: <Pine.BSO.4.10.10103171216120.8329-100000@spider.pilosoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Mar 2001, Alex Pilosov wrote: > On Sat, 17 Mar 2001, Nick Rogness wrote: > > > There is no way to tell your packet to go back out to ISP #2. That is the > > point I'm trying to get across. Unless your running a routing > > daemon. But is that really practical with cable modems, dsl, etc?...I > > don't think so. > <flame> > Is the clue really gone from this list? > </flame> WHat is your problem? Are these comments really necessary? > > Now, correcting glaring mistakes of the above two posters: > > a) Multihomed means having two connections to public Internet > I mentioned that in my post if you would have read it. Multihomed can be multiple connections connections to the internet, not just 2. Dual-Homed is the proper terminology for 2 public connections. > 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. > 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 > > 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. Nick Rogness <nick@rogness.net> - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0103171139120.16998-100000>