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

From: Cayle Spandon (no email)
Date: Thu Sep 18 2008 - 09:51:55 EDT

  • Next message: Cayle Spandon: "Re: Mechanisms for a multi-homed host to pick the best router"

    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 <> wrote:

    > ("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
    >
    >


  • Next message: Cayle Spandon: "Re: Mechanisms for a multi-homed host to pick the best router"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD