Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Dual Home (?) ?



On Sat, Jan 18, 2003 at 03:14:09PM -0500, Kent Borg wrote:
> I don't know if "dual homing" is the accurate term here, but it's
> close enough for others to use it that way...

"dual home" can refer to a couple of different scenarios:

- a host on multiple ethernet networks -- such as any router

- an autonomous system (AS) connected to more than one other AS -- such
  as an ISP connected to UUnet and Sprint

> As those of you know who have been following my saga, I am in the
> midst of seeing if I can (and want) to switch my home DSL to Covad.
> And, I am learning more stuff.
> 
> Yesterday I got home and plugged in my new DSL modem/router, and after
> giving up on the web based wizard working with Mozilla, I figured out
> how to set up the PPPoE username and password via the router's telnet
> interface.  Cool!  I have a second internet line.  But I want to
> figure out how to do a smooth cutover, and the first step is to get my
> RH 7.0 server on both wires at the same time.

This is a blending of the two scenarios above. If you were an ISP or a
medium-sized company, you would be buying connectivity from two upstream
providers, and you would apply for your own AS and exchange BGP routes
with those upstreams.

However, neither Covad nor Galaxy are going to speak BGP to you.

Both of them are willing to act as a default route for you, and neither
is willing to carry traffic for an IP address that they don't own.

So, you have two potential exits from your system, and any packet
requested on exit A will be responded to on exit A, even when exit B is
completely empty.

> Here are some clues.  First, is this sensible for my server:
> 
>   [root at borg root]# route -n
>   Kernel IP routing table
>   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
>   192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth0
>   192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
>   127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
>   0.0.0.0         192.168.100.1   0.0.0.0         UG    0      0        0 eth0

0.0.0.0/0 is the default exit: any packet not handled by a more specific
route will go out eth0, to be handled by 192.168.100.1.

So, in order to get any packet out eth1, eth1 has to have an appropriate
route installed.

>   $ /usr/sbin/traceroute 64.105.205.123
>   traceroute to 64.105.205.123 (64.105.205.123), 30 hops max, 38 byte packets
>    1  192.168.1.1 (192.168.1.1)  1.387 ms  0.897 ms  0.781 ms
>    2  h-66-166-225-1.CMBRMAOR.covad.net (66.166.225.1)  12.701 ms  22.114 ms  11.313 ms
>    3  * * *
>    4  borg (208.218.135.231)  31.349 ms  29.858 ms  29.501 ms
> 
> Note that though I asked to trace to my new Covad static IP
> (64.105.205.123), the last line mentions my Galaxy DSL static IP
> (208.218.135.231)!  

That happens because the information in parentheses is the result of a
reverse-DNS lookup on the IP address that your machine responded with.

Incidentally, because your machine is set up this, way, the traceroute
is not correct. You have assymetrical routing of some packets.

Now, a naive method of handling this would be to split the internet into
two parts. Anything in the second half of the Internet would be handled
by the more specific route, and anything in the first half would be
handled by the default route.

Or, you could ping every destination on both networks, then pick the
faster connection. This would either take a very long time to compile an
out-of-date map, or impose an unacceptable round-trip-time delay on
every new connection.

Or, you could buy a Sockeye router assistant, which essentially does
that for you, except that it's quite expensive and wouldn't work very
well in this configuration.

Or, you could purchase commercial grade connections from 2 ISPs and set
up your own AS.

Or, you could pick the ISP with better customer support, and ditch the
other one.

Lots of choices.

-dsr-

-- 
Network engineer looking for work in Boston area.
Resume at http://tao.merseine.nu/~dsr/




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org