nanog mailing list archives
Re: Mechanisms for a multi-homed host to pick the best router
From: "Cayle Spandon" <cayle.spandon () gmail com>
Date: Thu, 18 Sep 2008 09:51:55 -0400
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 <vixie () isc org> wrote:
cayle.spandon () 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 discussedbelow).Also, for the sake of simplicity in this discussion, let's say thisserveronly receives inbound TCP connections; it never initiates outbound TCP connections. Finally, this server has a loopback address L. All traffic destined totheserver 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, butIcannot 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 overthatsame 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 foroutboundTCP connections. For outbound TCP connections we would not know whichrouterto 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-homedhost)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
Current thread:
- Mechanisms for a multi-homed host to pick the best router Cayle Spandon (Sep 17)
- Re: Mechanisms for a multi-homed host to pick the best router Laurence F. Sheldon, Jr. (Sep 17)
- Re: Mechanisms for a multi-homed host to pick the best router Cayle Spandon (Sep 18)
- Re: Mechanisms for a multi-homed host to pick the best router Paul Vixie (Sep 17)
- Re: Mechanisms for a multi-homed host to pick the best router Cayle Spandon (Sep 18)
- Re: Mechanisms for a multi-homed host to pick the best router Valdis . Kletnieks (Sep 18)
- <Possible follow-ups>
- Re: Mechanisms for a multi-homed host to pick the best router Brighten Godfrey (Sep 18)
- Re: Mechanisms for a multi-homed host to pick the best router Laurence F. Sheldon, Jr. (Sep 17)