Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 18 Mar 2001 09:58:20 -0700
From:      Wes Peters <wes@softweyr.com>
To:        Nick Rogness <nick@rogness.net>
Cc:        freebsd-net@FreeBSD.ORG, Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>
Subject:   Re: same interface Route Cache
Message-ID:  <3AB4E92C.7F668DD9@softweyr.com>
References:  <Pine.BSF.4.21.0103172322030.18063-100000@cody.jharris.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AB4E92C.7F668DD9>