Abstract
Internet access for organizations today is no longer about connectivity for email and web browsing. A stable Internet connection is a vital component in the chain of IT systems required to conduct business. Typically, in the past, the focus around Internet connectivity has been on cost, with vendors providing solutions allowing organizations to spread their traffic across consumer and enterprise products. This approach is right and can save significantly, mainly when employee traffic is directed over low-cost consumer products such as ADSL. However, resilience becomes a major concern when conducting B2B business through front-end servers hosted in your DMZ. In this scenario, a dead Internet link can mean a loss of revenue and even, potentially more serious, brand damage. In this paper, we discuss several methods that can be used to improve the resilience of an Internet link. While this sounds like it should be a simple case of connecting to multiple Internet Service Providers, the devil, as they say, is in the detail.
Mission-critical Internet
Business networks have been mission-critical for some time now, and the focus on resilience and business continuity has always been top of any CIO’s mind. However, this focus’s general areas of interest were restricted to internal networks and systems. With more and more business being conducted directly via the web or B2B over Internet links to systems hosted in DMZs, it is simply no longer permissible for an Internet link to be down. Loss of access to the Internet can directly impact revenue generation, especially today as the business operating models begin shifting towards offsite cloud computing and software as a service.
A solution to the problem
Multihoming is a method whereby a company can connect to multiple ISP simultaneously. The Multihoming concept was born out of the need to protect Internet access in either an ISP link failure or an ISP internal failure by the protocol. In the earlier days of Internet access, most traffic was outbound except email. An Internet link failure left internal users with no browsing capability and email backing up on inbound ISP mail gateways. Once the link was restored, so was browsing and email delivery. The direct impact on the business was relatively small and mostly not revenue-affecting. Early solutions to this problem were to connect multiple links to the same ISP, but while this offered some level of link resilience, it could provide no safeguards against an internal ISP failure.
RELATED ARTICLES :
- Laos Adventure Travel – And What an Adventure
- Evaluate Verizon Samsung Galaxy Nexus This is What Android Became Supposed To Be
- Flattening The American Internet Community
- Activity Internet Online Marketing Information, Computer, Fraud Tips
- Smart Android Phone Purchaser’s Guide
Today, however, most organizations deploy on-site Internet-accessible services such as VPNs, voice services, webmail, and secure internal system access while using business-critical offsite services such as software as a service (SaaS) and other cloud-based solutions. Furthermore, while corporate front-end websites are traditionally hosted offsite with web hosting firms, the real-time information on the corporate websites and B2B sites is provided by back-end systems based in the corporate data center or DMZ. Without a good quality Internet connection, these vital links would be severed.
Varied requirements and complexity
The multihoming requirement varies and could range from the simple need for geographic link diversity (single ISP) to full link and ISP resilience, where separate links are run from independent data centers to different ISPs. While the complexity varies for each option, the latter form the most complex deployment option but affords the highest availability. The former provides some degree of protection but does require a higher grade of ISP.
A major component of the complexity comes in around IP addressing. The Internet IP addressing system works because each ISP applies for a range of addresses from the central Internet registrar in their region. They would then allocate a range of IP addresses, called an address space, to their customers from this pool. No two ISPs can issue the same address space to a customer.
Why would this be a problem? Simply put, it’s all about routing. Routing is the process whereby the Internet finds out how to get traffic to your particular server. It’s a bit like the Google map for the Internet. For somebody to find your server, a “route” or path needs to exist to your server’s IP address. Since you are getting your Internet service, and hence your IP address space, from your ISP, they are responsible for publishing the route to your server across the entire Internet.
They are virtually the source of your way, and nobody else can do that for your particular address space. You can see how things can go wrong if the ISP suffers an internal failure. If your specific route disappeared, your server would vanish from the Internet, even if your link ran. This is the kind of issue multihoming tries to solve, but we will start with the simpler options and work our way up for completeness.
Single Link, Single ISP, Multiple address spaces
While not a multi-homing solution in the strictest sense, the single link, multiple address option can be useful for small sites. In this scenario, the publicly accessible host is assigned two IP addresses from two different address spaces. You would, of course, need two address spaces from your ISP for this to work. Thus, theoretically, if a routing issue impacts one of the address spaces, the other may still be available. Of course, the single physical ISP link is a single point of failure, and this option would seem to offer little in the form of real resilience.
Multiple links, Single ISP, Single address spaces per link
This scenario, generally called multi-attached, is a variation of the above. The site now connects through multiple links, each with a different IP address space, but still via a single ISP. If one of the links fails, its IP addresses will become unreachable. However, the other IP address on the remaining link will remain available, and your server will always be reachable. Internet Service Providers use a control protocol to manage their IP routes called Border Gateway Protocol or BGP. This protocol is used to drive the traffic re-routing over the live link. BGP can be complicated and demands a lot from the equipment it runs on. Of course, with complexity comes a cost; however, this scenario’s BGP deployment is not as demanding as a fully multi-homed site and should not attract too much attention from the CFO. While the deployment is a simpler version of full multihoming, it does restrict the corporate to a single ISP, which may not be part of the business’s strategic intent.
Multiple Links, Multiple ISP, Single address space
This scenario is what is generally meant when discussing multihoming. The BGP protocol is used to manage the single address space’s visibility across the multiple links and ISPs and, thus, maintain the routes. The BGP protocol communicates between the corporate routers and those of the two ISPs with the protocol to detect a link failure and divert traffic to the functioning link, even if this is via a different ISP network.
What’s the catch?
There is always a catch, and in this case, several of them exist. To run true dual ISP multihoming and BGP as a corporate, you would need your own Provider Independent (PI) IP address space, and you would need to apply for a unique BGP Autonomous System Number (ASN). The AS Number is used to identify your site as a valid Internet location in the eyes of BGP. While applying for an ASN is not arduous, it places some significant responsibility squarely with Wonyou instead of the ISP. Deploying BGP effectively brings your organization closer to the Internet by making you responsible for advertising your public IP address spaces and, thus, your routes. It also means that any operational mistakes you make will ripple through the entire Internet.
Address space considerations
Most large organizations that operate true multihoming already have their own Provider Independent address space. They requested This address space directly from the local Internet registrar some time ago before IP version 4 (IPv4) addresses started running out. Today it is virtually impossible to be allocated a PI address space from the IPv4 pool. It is possible to run a multihomed scenario using ISP-provided IP address spaces. Still, the network configurations become considerably more complex and start defeating the goal of increasing resilience. In the real world, increased complexity seldom equates to improved stability.
Scaling
A valid BGP-enabled multihoming deployment (often known as running defaults) will require hardware capable of storing IP routing tables of Internet-scale. This is desirable as it protects the organization from an internal ISP failure; however, it requires the routers on-site to be of a “carrier-grade,” in other words, big and beefy. The Internet routing tables are the massive and vast amount of processing power and memory required to run defaults. It is possible to run in a reduced route mode where only local prefixes are stored on the routers. Still, given the effort and expense of deploying a full multihomed solution, compromise should not be part of the conversation.
Summary
While there are definite advantages to full multihoming, there are also some significant caveats. Complexity and scaling aside the real reasons and costs for considering multihoming should be carefully considered. That said, for a highly Internet-dependent organization, there is no better way to ensure high availability and performance than through true multihoming. A Provider Independent IP address space will be required, and carrier-grade routers will be configured in a geographically diverse manner and supported by suitably qualified support staff. The benefits can outweigh the costs when direct revenue is generated through the Internet, and multihoming can be seen as a strategic business initiative and something that can help CCIOssleep well at night.
