The theft of network cards from a Verizon office last May caused many Manhattan businesses to lose Internet service for nearly a day. Outages such as this convey to all businesses—not just the affected ones—how dependent they have become on Internet access and how vulnerable they are to disruptions. A few hours of downtime—even outside normal business hours—could mean thousands of dollars in missed opportunities and lost customers. But how can you ensure you’ll have an unbroken connection?
A growing number of professionals, as well as companies of all sizes, are buying redundant connectivity: multiple paths to the Internet. If cable modem service, DSL, and/or wireless broadband are available in your area, you may want to subscribe to at least two of these services. (Few, if any, ISPs provide connections “for backup only.” While some will let you use a conventional modem if your connection fails, this is so slow that it is of limited use as a backup.)
But how do you configure your equipment to shift quickly and seamlessly to another connection? Most computers and SOHO routers cannot do this, so unless you have the right hardware or software, you have to reconfigure manually.
What’s more, if you’re paying for multiple connections, you should be able to use the extra bandwidth in nonemergency situations. You should be able to exploit all your links simultaneously (load sharing) to get more bandwidth than you could from any one of them. There should also be a way to shift loads when one of your connections is slowed through congestion. You may even want to steer users accessing your servers to the “closest” connection, Internet-wise, to them. But how do you do all this? You’re not likely to find any help in the documentation for your operating system or small router/firewall.
Unfortunately, it’s hard for a small company or an individual to exploit the protocols that implement load sharing and redundancy on the Internet. For example, the Border Gateway Protocol, or BGP (RFC 1771), lets a host or a network “advertise” to the Internet how it can be reached—and to change that information if a connection goes down. But because the BGP assumes you’re a large entity that has a big network and its own block of Internet addresses, using BGP to help with redundancy isn’t practical even for moderate-sized companies, let alone SOHO users.
The Open Shortest Path First, or OSPF (RFC 2328) protocol, is good at managing redundant connections inside a network that you control. But OSPF won’t help you manage multiple ISP connections unless they’re all to the same ISP, which has agreed to help you use OSPF for this. (Most ISPs won’t do that.)
If you’re a typical small-business user, you’ll need to find a way to get these features without the help of your ISP(s) or special protocols. Fortunately, engineers have begun to cook up hardware and software to let you do this.
The tricks used by these multihoming appliances can be divided into two categories: those for incoming connections (such as hits on your Web server) and those for outgoing traffic (your own browsing). The best-known are the ones that handle incoming traffic. Nearly all such products can create a server pool, which divides incoming requests among your servers and ensures that a client is matched to the same server throughout a Web transaction.
Most server appliances use domain name service (DNS) to route incoming traffic over a particular link. As most URLs include a domain name, it’s possible to control which link a client uses to reach your server by changing the IP address that’s returned when the client looks up a domain name.
These appliances have built-in DNS servers that respond to changing conditions. First, the appliance performs a periodic check on each Internet connection and stops furnishing IP addresses associated with a connection that goes down. (The standard protocols that domain name servers use already let them have multiple IP addresses, so a client automatically tries to reach the DNS server via a different link if one is down.)
If multiple links are up, the DNS server may choose the IP address to return to a particular client by considering the loading and capacity of each of your links. It may also try to do a proximity test to choose the link that leads most directly to the client. Since the appliance can’t know how much data each client will request, it can’t always balance loads optimally, but it should at least let you take some advantage of all of your working links. Once the traffic gets inside your network, the device may also use a specialized form of Network Address Translation (NAT)—sometimes called smart NAT—to pair each client with a particular server, dividing the load so that none of your servers is saturated.
Even if your office doesn’t host anything that you think of as a server—for example, your Web site—server redundancy features are still important in the event of an outage. Why? Because many of the applications you may use every day—VoIP, peer-to-peer, remote-control programs (like LapLink), VPN, file-sharing programs, and more—cause your system to accept data connections from the outside world and thus act like a server. If machines in the outside world can’t “find” you, you may lose functionality, so any solution that provides good redundancy must divert all incoming traffic (usually via DNS) to the connection(s) that are still working.
Load balancing and redundancy for clients connecting outward to the Internet are relatively new areas, for which far fewer products are available, and techniques vary widely. Some split up outgoing traffic packet by packet, feeding each to the least congested upstream link. This technique is especially useful because many Internet connections are asymmetrical—with less upstream bandwidth than downstream. Unfortunately, allocating bandwidth packet by packet between multiple connections doesn’t always work. To help thwart Internet worms, some ISPs use egress filtering: They won’t let you send packets with a return address that belongs to a different ISP. So, a load balancer that wants to spread a connection among multiple physical links needs to be able to sense—or be told—that a particular link can be used to send only packets with certain source addresses.
Other appliances pick one link to use exclusively for each session, or connection, with a remote server. However, the router may not always correctly determine the best link to use. (Some products try to start every outgoing connection on several links simultaneously; the one that responds first is used, even if a random delay skewed the outcome.) Also, not all products can correctly balance loads on an asymmetrical Internet connection, such as ADSL. Finally, the appliance must be able to check the health of each link.
Source: PCMAG.com
Comments are closed.
Copyright 2015 - Pulse Practice Solutions | 615.425.2719