... > > dead. This is *very* cool on UDP, and will make UDP failover to another > > route fully transparent. However, it will not fix stateful protocols in > > which the server on the other side keeps state on the IP address it was > > talking to, such as SSH. Sending packets with the same source address out another link only helps UDP if it's not necessary to get replies, in which case I wouldn't call it a "connection". If you didn't need the replies then you could do the same thing for TCP. Note that this trick only works at all if your ISPs are not doing the ingress filtering they should - a safe assumption for now, but I hope not in the future. The problem is that you normally don't have any control over the routing between two places. Even though your ISPs will let you send out packets with the source addresses belonging to each other, the replies will be routed to the one that "should" have sent the packets, and if that one is down you can't get the replies. This problem could be fixed by extending TCP (and of course, changing the kernel) to support multiple IP addresses. I suggest a new option that says "here's another IP address for me" (or perhaps, here's an alternative IP/port). The kernel then has to merge these two input streams. On the output side (when you send to someone who has told you about alternative addresses) I can think of several ways to control which address you send to. I suppose the application should have some way to influence that, but as a first stab, I suggest that whenever tcp has to resend a packet, it should move to the next address. Anyone interested in trying to implement it? Put it on your queue and post to the list if you ever get to it. Also please post to the list any bugs (and fixes) you see in the proposal.
