Date: Sat, 17 Mar 2001 21:59:47 -0700 From: Wes Peters <wes@softweyr.com> To: Alex Pilosov <alex@acecape.com> Cc: Nick Rogness <nick@rogness.net>, freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Subject: Re: same interface Route Cache Message-ID: <3AB440C3.81EA95F2@softweyr.com> References: <Pine.BSO.4.10.10103171216120.8329-100000@spider.pilosoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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>
>
> Now, correcting glaring mistakes of the above two posters:
>
> a) Multihomed means having two connections to public Internet
Multihomed means having two network connections. Period.
> 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).
Like the fastpath routing code I used to write for Xylan/Alcatel? ;^)
Let's review: the route cache was implemented in pseudo-CAMS (content
addressable memory) that were part of an ASIC, in software running on
the processors embedded in the ASIC. Yup, looks like we're in agreement
on this one.
> Route-cache has nothing to do with policy routing (d)
Right. Nick keeps saying "route cache" when he means "route table".
> 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.
Right. When you have more than one "upstream" connection, a routing
deamon is a necessity.
> 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.
Right. Most of it is pure voodoo, and network administrators all over
the planet use it to regularly screw their networks into the ground, but
it's one of those features that routing switches have to have these days.
> FreeBSD has no support of that, to my knowledge.
No, and thank ${FREEBSD_DEITY} for that. The reason for this is because
FreeBSD is developed by people who understand how IP routing works, and
refuse to dork it up with idiocies like "policy routing".
> 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.
But it's just a gross hack. Flapping your default route between whichever
interface seems to be working best at the moment would be just as effective.
> 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.
You can do the same by picking one to be the default route and then
entering known-good routes via the other interface to destinations that
you think are "closer" or "faster" via that interface. If you think you
can actually better the performance of BGP4, prove it. The prize is
more money than you can possibly imagine, and I'll be glad to help you
spend it.
It would be possible to write a routing daemon that somehow snarfs each
of the addresses that hit the default route and play traceroute games to
determine which of your public addresses have a "better" path to it, but
what Nick really really needs to do is get a pair of ISPs that aren't
incompetent and that provide RIP to downstream customers.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
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?3AB440C3.81EA95F2>