Subject: Multiple TCP source addresses?

From: der Mouse <[email-masked]>
Date: Fri, 15 Dec 2000 09:20:24 -0500 (EST)

I've got a problem I'm trying to invent a solution to and I thought I'd
ask if there's any past work I should look at, or perhaps it's already
been solved and I just don't know it.

Most of the hosts on my home LAN are multihomed; I have address space
from two different places and I run both subnets over the same house
Ethernet.  (Network interfaces are configured to have both addresses.)
Sometimes one block of address space is reachable while the other one
isn't, and outgoing packets are routed to one of two tunnels (one to
each provider of address space) based on which subnet their source
addresses fall into.

This all works well in normal circumstances.  The problem is with
outgoing connections when one block of address space is unreachable for
some reason.  All the hosts have their default routes pointing to the
off-LAN gateway, but I had to pick one of its two addresses, and the
source address for the outgoing connection is always in the
corresponding subnet.  When that subnet is unreachable from the
destination host, outgoing connections fail even if I do have
connectivity to that host via the other subnet.

I could deal with the case where a subnet goes completely unreachable
with a routing protocol of some sort, perhaps.  But reachability is not
always all-or-nothing; depending on where the outage is, which hosts
can reach which subnet varies.

So I'd like to do something so that outgoing connections for which the
application has not specified a source address don't always try with
one source address and give up if that doesn't work; conceptually, I'd
like to try from all local addresses.  I was thinking of sending out
multiple SYNs, one for each local address; as soon as one gets
SYN-ACKed, that would commit the local address and SYN-ACKs for the
others would draw RSTs.  It does occur to me that I may want to do this
round-robin among the addresses, rather than in bursts, to avoid
creating unnecessary embryonic connections on the taget host in case
both addresses work.  (Of course, they would be torn down quickly in
response to the RST, but still.)

Comments?  Thoughts?  Prior art?

					der Mouse

			       [email-masked]
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Ruth Fax" <[email-masked]>
Date: Fri, 15 Dec 2000 08:02:20 -0800

The problem is what routing protocols were designed for.  When a destination
subnet is unreachable, packets will be routed to the second provider
(assuming that provider has a route to the destination and back to you).

Varying the source address, to force packets onto the second provider, is a
solution.  But it
doesn't scale and may not work.  If the problem is with the destination,
trying to get there via another provider won't work.  If the problem is with
the first provider, it will work, but so will routing.

I may have missed something in your solution, but I think you mean you'd
only try one source address from the second subnet.  i.e. multiple SYNs from
an address on each subnet.  Sending multiple SYNs from multiple addresses on
the same subnet won't help.

I'd like to know why the block of addresses goes unreachable before
proposing a solution.  Try some traceroutes from each subnet when this
happens.  It could be network congestion, route flaps, crashes, etc. I've
had providers mysteriously lose routes back to me at times.

--Ruth

-----Original Message-----
From: der Mouse [mailto:[email-masked]]
Sent: Friday, December 15, 2000 9:20 AM
To: [email-masked]
Subject: Multiple TCP source addresses?

					der Mouse

---

From: Richard Draves <[email-masked]>
Date: Fri, 15 Dec 2000 14:44:48 -0800

I'm cc'ing [email-masked], which was recently formed to discuss site
multihoming issues like this, albeit in the context of IPv6 instead of IPv4.
This is definitely an important problem to solve.

You're headed down the path to one possible solution, in which hosts have
multiple addresses and are smart enough to try different combinations of
src/dst address to find a working path.

There are other approaches that are more routing based. For example suppose
your house has one address prefix, which was allocated out of a block
assigned to your metro area/region. Your house network prefix is advertised
inside all ISP networks in your region, but not to other regions. Only the
shorter region prefix is advertised to other regions. Then routing protocols
take care of finding a working path inside the metro region.

Rich

> Sent: Friday, December 15, 2000 6:20 AM

---

From: der Mouse <[email-masked]>
Date: Mon, 18 Dec 2000 13:43:45 -0500 (EST)

>> How is a routing protocol supposed to deal with this?  Remember, my
>> house LAN doesn't have its own AS.

> If you run a dynamic routing protocol (even RIP will do with the
> right configuration files), then you can set the default route based
> on which gateway is up and/or primary.

Yes, if the failure were in my adjacent gateway or the link to it, this
would work.

But that wasn't the case.  I could reach my next-hop gateway just fine.
The point of lossage was a hop or two further away.

Also note that which route is correct depends on the host being
contacted; no single default route will do, and while I could perhaps
traceroute to each address from the other in order to determine where
the broken gateway is, I have no way of knowing enough topology to know
what hosts are on which side of it (and therefore can't install a bunch
of network routes for the smaller set of hosts).

					der Mouse