MultiLane, a multi-redundant internet thingie+service

September 23, 2008

Surely this exists already, but I can’t figure out how to even search for it.  Eric was right about my Google-fu being weak.

It’s just a thingie+service that lets me pretend that my internet connection is in a data center somewhere.  The trick is that it can use (“load-share”) multiple internet connections (DSL, cable and wireless, for example) while doing this, and is ready for any one or two of them to break and still do its thing.

(As for what’s going on between the thingie and the data center along the colored lines in the video, I have no idea.  Maybe it’s iptables wizardry, or maybe it’s something else entirely that’s IP-based but weird and proprietary.)

So really, this is my naive best guess at how an ideal load-sharing redundant interent connection scheme would work for small-timers such as myself.  ‘Sure seems obvious enough from here.

11 Responses to “MultiLane, a multi-redundant internet thingie+service”

  1. ekpaulson Says:

    I have no idea what to search for either.

    However, one thing you could play with is installing an alternate, more powerful firmware, such as DD-WRT on your local router. I just did this at work to set up a wireless bridge as a network connection (i.e. router A connects as a client to router B wirelessly). (If you’re wondering why — my office is located in a building slated to be torn down, so no effort is being spent on the building’s network infrastructure).

    In DD-WRT there is an option — STP — which apparently stands for Spanning Tree Protocol:

    So, optimistically, you could install DD-WRT on your local router, enable STP, and hook up multiple outgoing connections. Maybe it would work.

    Another possibility might be to mess around with Amazon’s Elastic Compute Cloud:

    Set up your website as a linux image that outputs its collected data to Amazon’s Simple Storage Service:

    Then you can just download the data to your local computer whenever you want it.

    In this way your web server(s) would be “out there” in the “cloud” and hopefully will have Amazon making sure that it always has a connection, somehow. But it will cost you at least $0.10 per hour ($75/month) to have an “instance” running all the time. But you might save some of that on your power bill.

  2. craigrmeyer Says:

    See what I’m saying? You’re being as helpful and expository as you possibly can, which I really do appreciate, and look how many words it took!

    What the heck! I’m burning with indignation that a redundant internet connection for both incoming AND outgoing connections is such a big complicated deal! Are we not the ten millionth people to want/need this?

    (Or have I just had too much coffee today? 😉

  3. Patrick Says:

    Use GRE tunnels to your linux box in the data center:

    Use zebra to implement OSPF to load-balance the flows across the GRE links:

  4. craigrmeyer Says:

    Okie dokie!

    After a nice Saturday conversation with my network administrator buddies Really Nice John and Handsome Patrick, I’ve learned some things:

    What this box/service does can be effected with a bunch of smartly-configured and -monitored Linux-based network-stack acronyms. (Even using all the connections to speed up a SINGLE scp or rsync is doable without inventing TOO much.) BUT, it’s still too complicated for non-techies to find the time to jump into and set up.

    Single-board computers with ~8 ethernet ports and specially-compiled embedded Linux distributions are around $100. One of these could easily house the required acronyms and be plenty reliable.

    (Which is nice, because it suggests that the service could be prototyped on a junk linux box and an account on a “data center” computer… in a friend’s closet. As long as we can get a static IP to dedicate to the experiment then whammo.)

    I propose a custom plastic enclosure, though, in order to effect a bunch of packaging tricks that would make a big difference in making the device/service useable:

    1: Knobs or a thumbwheels for setting the unit’s IP address 192.168.0.___.

    2: Super-clear labeling of the one ethernet port that points to the office, and then “http://192.168.0.___/port1” (or whatever) to access the various modems (DSL, cable, wireless, ____) that will hang off each of the outward-facing ports.

    3: Hand-switches for obviously indicating which ethernet ports are being used, so that the firmware can tell when a connection dies and act accordingly.

    4: Emails to notify of connection death are smart but require configuration. OTOH, interrupting web page loads (like at the coffee shop before you get your password code from the cashier) is sure to get the word out.

    Also, it’s smart to recommend the use of a battery UPS for this unit and the various modems. Then, those computers with UPSes can still access the internet when the power goes out. Same for IP telephones if the phones hang off the UPS too.

    That’s all I got so far. Questions remain:

    Q1: The service running on the box at the data center: How can this be done redundantly so that if the data center box dies, the customer doesn’t lose his internet? (I’m okay with trusting the data center, but not the single box IN the data center. Besides, we’d hope to scale beyond a single box at some point.)

    Q2: How to collect money? So much a month plus so much a gigabyte sounds fair.

    Q3: In a super-saturated world, how on earth would such a thing be marketed? First it has to be genuinely useful, of course, but what THEN?

  5. craigrmeyer Says:

    Oh yeah, and green/red LEDS near the modem-facing ethernet ports to show which ones are up/down as well.

  6. craigrmeyer Says:

    Further, Really Nice John pointed out that some IP packets are signed as being from protocols (like ssh) that really benefit from low latency. Ergo, the box could figure out which connects are less latent than others, and then favor such traffic to them.

    (Meanwhile, high-latency-okay connections like scp or whatever can be favored toward the higher-latency connections.)

  7. craigrmeyer Says:

    And how could one work an overpriced “enterprise” version?

  8. craigrmeyer Says:

    (WOW. The demand for this service really looks to be quite high. I do a Google searches for “redundant internet router” and “redundant internet connections” and get a metric CRAPLOAD of complicated-looking gobbledeegook.)

    (I’ll bet anyone twenty tacos that whoever–like maybe us–who gets this product really together and working will be bought out by Netgear or Barracuda in a year.)

  9. craigrmeyer Says:

    Okay, here’s where this is now.

    I’ve learned that the Achilles Heel of this service, as I understand it:
    o Use all internet links full-bore at the same time on a single FTP.
    o Incoming connections possible via a static IP
    o Readiness for any single internet link to break.
    …and that to do these three things, it has to operated out of a data center, where the 2+ internet streams are bundled back into a single IP address.

    So what sucks about that is that the static IP address can’t be transferred to a different data center if the data center blows up. Outgoing DHCP-style traffic CAN be re-routed elsewhere by the MultiLane modem thingie, but not stuff coming/going through the static IP at the data center.

    Okay. So. If the data center dies, what’s the best that can happen?
    o IP connections coming/going through the static IP are cut off.
    o Outgoing DHCP-able stuff (web loads, skype calls) are re-routed.

    So life goes on inside the customer’s office, but anyone trying to SSH into it is cut off until the data center comes back up.

    I have to sit down, ponder this for a few days, and see what I think about this. Maybe there’s still an honest service to be offered to people, or maybe not.

  10. craigrmeyer Says:

    (Is the Real World complicated or what?)

  11. craigrmeyer Says:

    Well, here’s where I am now:

    I’ve learned that a real-deal 24-7 redundant internet connection is possible through the “multilane” model, but not if the customer needs a static IP, and it’s the static IP that makes this interesting.

    No data center is perfect, and when the data center that owns the static IP dies, that’s it. Outgoing connections right from the on-site router are still certainly possible, but incoming connections to the static IP address (like ssh) will be cut off until the data center comes back.

    And it’s the offer of constant incoming access, independent of the individual internet links (DSL, cable, wireless, etc), to a single incoming static IP that really makes this interesting. Simple “failover” from one static IP (like on the DSL) to another (like on the cable) is already a complicated but pretty-much-solved problem.

    But the good news is that the static IP can be at a tier-1 or tier-2 data center. Just a single 1U server there can probably host many gigabits of incoming and outgoing connections, and thus a great number of connections. (Or at least that’s what I’m telling myself.) This way, the customer’s static IP address (at the data center) is significantly more reliable than the one on his DSL or cable connection.

    But it’s not quite as elegant as I was hoping. I’m still interested, though.

Leave a Reply to craigrmeyer Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: