From owner-freebsd-net Sun Mar 18 8:58:43 2001 Delivered-To: freebsd-net@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id BF4C437B718 for ; Sun, 18 Mar 2001 08:58:34 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [127.0.0.1] (helo=softweyr.com ident=b752d65721b16f1667199e233e54025c) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 14egVY-00009r-00; Sun, 18 Mar 2001 09:58:20 -0700 Message-ID: <3AB4E92C.7F668DD9@softweyr.com> Date: Sun, 18 Mar 2001 09:58:20 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Nick Rogness Cc: freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai Subject: Re: same interface Route Cache References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick Rogness wrote: > > On Sat, 17 Mar 2001, Wes Peters wrote: > > > > > > > > > > > > > Packet 1 comes in through ISP #2 network. It comes into your > > > > internal network to machine 1. Machine 1 replies to the > > > > packet...but where does it go? It will exit through interface > > > > to ISP #1 because of the default gateway. It came in ISP #2 and > > > > left out ISP #1. There is your problem. > > > > > > 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. > > > > Why would the physical media have anything to do with routing protocols? > > Just TRY to ask your cable or DSL provider to do BGP or any > routing...it aint going to happen. Watch them laugh in your face. Oh, just about any of the DSL providers that sell "small business" services will provide at least RIPv1 routing info. They charge more, but then again you're getting more from them, so that makes sense. Cable Modems are toys, because they rely on cable tv operators for networking expertise, and as far as I've seen, they don't have any. I'm willing to be proven wrong here. > The point here is getting way out of hand. Of course a routing > daemon would work. That has been said by myself throughout this > thread. That's not the point. Sure you can run a routing > daemon...it won't do any good if it is not recieving any routes > from your upstreams because they won't peer with you because you > only pay $40 a month for the service. Not everyone can afford a > damn T1 to an ISP, get IP space and setup BGP. Those same people > most often look for a UNIX box of some sort to do what they want. > > Yes, there is a time and place for policy routing. Any Network > engineer that has been actually supporting large networks can tell > you why you would use it, and there ARE very good reason to do it. See comments about "network engineer" below. Unless you have a CS degree and experience working with routing protocols or at least a CCIE, calling yourself a network engineer is exactly analagous to the garbage collector calling himself a sanitation engineer. > The fact is, many FreeBSD machines are running this type of > setup. Wouldn't it be nice to say "yeh we can do > that"? No, it would be nice to say "yeah we can do that WELL." We know we can't, so why implement some half-assed non-solution. Now you can see why Linux has this and we don't; Linux is the domain of the half-assed non-solution. > Unfortunetly, that does not appear to be the case because > adding flexibility seems to cause problems in the traditional ways > of the BSD folk...which is understandable...because you would be > breaking the rules. I understand. It's not just a matter of breaking the rules; nothing about the little Linux route-table manipulator is breaking any rules of IP routing, they're just basing routing decisions on very questionable data. If you wanted to port their little hack to FreeBSD and put it in ports, I don't think anyone would stop you, but nobody wants to waste their time on such a hack when they could be adding useful, working features. > PS: > This is not a hack for me, Wes, I suggested it after working with > several people having this same problem. There is a workaround > that is pretty ugly so I was looking for a cleaner > solution...that's all! There is a cleaner solution, it's called BGP4. This is simply a case of "you get what you pay for." IP routing is a complex nightmare, and CIDR didn't make it any easier. Trying to implement routing with anything less than support for routing to CIDR blocks and understanding the importance of intermediate routers is doomed to failure; your route table will grow to encompass all available kernel memory. I am *far* more familiar than you can imagine with this situation; questions like this and the ugly hacks (read this as "policy routing") put in place to answer the resulting customer demands are one of the reasons I avoid the "enterprise networking" marketplace. This is yet another proof of the old saw "a little knowlege is a dangerous thing", and 99% of "network engineers" (and all other IT staff) are possesors of "a little knowlege." Very little knowlege, unfortunately. It struck me last night that if you want to load-balance between two ISPs, you could simply pick a bit in the address and use it to select one or the other. If you pick your bit appropriately -- I'd go for something in the second byte -- you might luck out and get a nearly 50/50 spread. That would be no less hackish and a lot easier to maintain. -- "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