Mechanisms for a multi-homed host to pick the best router

Thu Sep 18 03:49:10 UTC 2008

cayle.spandon at gmail.com ("Cayle Spandon") writes:

> (My apologies, in advance, for the fact that this question is very long
> winded.)

np.

> I have a server which is multi-homed to N routers as shown below:
>
>      +---+
> R1---|   |
>      |   |
> R2---|   |
> ...  | S |
>      |   |
> Rn---|   |
>      +---+
>
> This server is a host; it is not a router in the sense that it will never
> forward any packets (but it might run routing protocols as discussed below).
>
> Also, for the sake of simplicity in this discussion, let's say this server
> only receives inbound TCP connections; it never initiates outbound TCP
> connections.
>
> Finally, this server has a loopback address L. All traffic destined to the
> server uses address L as the destination address. All N routers have a
> static route to L and inject that route into their routing protocol
> (possibly as part of an aggregate).
>
> Now, imagine the server receives an inbound connection from another host
> whose address is A. Thus, the TCP SYN packet which S receives has source
> address A and destination address L.
...
> For all these reasons, I don't want to run BGP on the server.

"too many moving parts."

> Someone suggested an idea to me which seems almost to simple to work, but I
> cannot find any good reason why it would not work.
>
> The idea is "the server simply sends all outbound traffic for the TCP
> connection out over the same interface over which the most recent TCP
> traffic for that connection was received".
>
> So, for example, if the server receives the SYN from router R3, it would
> send the SYN ACK and all subsequent packets for the TCP connection over that
> same interface R3.
> ...

right idea.  works great.  see the following:

http://www.academ.com/nanog/feb1997/multihoming.html
http://www.irbs.net/internet/nanog/9706/0232.html
http://gatekeeper.dec.com/pub/misc/vixie/ifdefault/

> ...
> I can think of the following problems with this approach:
>
> (Problem 1) It only works for inbound TCP connections and not for outbound
> TCP connections. For outbound TCP connections we would not know which router
> to send the first SYN packet to.

you said above you only needed inbound.  for outbound and udp: round robin.

> ...
> My question for the NANOG community are these:
>
> (Question 1) Can you think of any additional problems with this approach?
> Specifically, I am interested in persistent failures in the absence of
> topology changes.

topology change frequency is in a different order of magnitude than the
usual tcp session startup frequency, so unless you've got long running tcp
sessions which won't restart on a connection reset, you've got no problem,
and if you do have that kind of tcp session, you've already got problems.

> (Question 2) Is there another mechanism for the server (a multi-homed host)
> to pick a best router, short of running stub BGP? Are there any standards
> for this?

there are a bazillion patented and/or ubersecret ways to do this.  noone has
ever demonstrated anything that works better than an undercommitted network
with undercommitted connections to other undercommitted first-hop networks.

> (Question 3) If the answer to question 2 is "no", is there any interest
> in standardizing a protocol for a multi-homed host to pick a best
> next-hop router? One could think of this is a host-to-router routing
> protocol. One might call the existing routing protocols router-to-router
> protocols (because I think we are abusing them by running them on
> hosts). This is somewhat analogous to the multicast routing world where
> we use different protocols for router-to-router multicast (PIM) versus
> host-to-router (IGMP).

sadly, this has been tried, but it always runs into least-cost routing issues
whereby not only the predicted connection quality but also contract details
like whether this is over or under the per-period minima and how many quatloos
per kilosegment it will cost all have to get exchanged at high speed with low
latency and good accuracy.  been there, did that, got no useful t-shirt even.
-- 
Paul Vixie