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