Hi Paul,
Thank you very much for the confirmation that the idea is sane and for the
pointers to the additional information.
-- Cayle
On Wed, Sep 17, 2008 at 11:49 PM, Paul Vixie <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] ("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
>
>
