Loading...
Loading

Using Multi-homing ISP Failover for Increased Internet Bandwidth and Reliability

2009-07-27by

Organizations that depend on web-based applications eventually find they need more bandwidth and reliability. Relying on a single Internet service provider (ISP) to deliver business-critical applications over the Internet is a risking proposition for any business. All ISPs are subject to network congestion and other performance problems, and most suffer service outages (even 99.5 percent reliability means 43 hours of downtime per year!). To ensure that these inherent problems don't cause operational disruptions and financial losses, businesses are using a technique called multi-homing to connect with multiple ISPs into a single virtual connection. Bandwidth aggregation and link load balancing techniques allow businesses to utilize the total bandwidth available from these ISPs, while Quality of Service (QoS) rules can be used to allocate bandwidth availability to specific applications. An essential component of multi-homing is ISP failover, or the ability to automatically redirect both outgoing and incoming Internet traffic from failed ISP links to functioning connections.

ISP failover can be achieved in two ways. One approach is to use an ISP-level technique based on the Border Gateway Protocol (BGP), a routing protocol that uses certain attributes to determine traffic routing. This approach requires a high degree of cooperation among multiple ISPs, along with the installation and maintenance of expensive and specialized routers at both ends of a link. Another drawback of BGP is the time it requires to reroute Internet traffic, which can result in costly time lost to Internet delays.  BGP has been used for multi-homing, but its cost and complexity make it impractical for most SMBs.

Another approach to ISP failover is a far more economical and reliable business-based solution. This approach uses specialized WAN link optimization appliances that provide link aggregation, load balancing and failover. These devices are located between ordinary routers on a business LAN and the WAN port of the firewall. Each device has two or more ports to connect to multiple ISPs, and requires no special configuration in the ISPs' routers. When a session is generated from the LAN, the device computes which ISP link has the most available bandwidth and routes the session accordingly. If a link becomes congested, the device automatically reduces traffic going to that link and redirects traffic to links with more available bandwidth. If a link fails, the device automatically stops traffic to that link and directs traffic to functioning links.

 

This diagram shows a WAN link controller automatically managing three separate WAN connections to ensure uptime and optimize performance.

Inbound ISP failover is achieved by designating the device as the primary and secondary authoritative DNS server for all the domains being hosted. If an ISP link fails, the device stops advertising that link's IP address to DNS caching servers, which in turn drop that address from their records and redirect traffic to active links. By setting the host name record "Time to Live" to a few seconds, the failed link is quickly removed and reinstated automatically when link connectivity is restored.  In the meantime, traffic is rerouted to another link.

This diagram shows a WAN link controller as the authoritative DNS server to ensure WAN uptime.

The same technique can be used to provide site failover for business continuity and disaster recovery when the WAN link controller is installed at a backup site. In this approach, the WAN link optimization device at the backup site continually tests DNS resolution to the WAN link optimization device at the primary site. If the device at the primary site does not respond, the device at the backup site immediately initiates the inbound ISP failover procedure described above. Inbound user traffic is then immediately redirected to the backup site, and Internet-based business operations continue as normal.

 

news Buffer

Leave a Comment