Inbound Load Balancing and Failover (Multihoming)
Multihoming
Multihoming is a technique when external users request any server’s IP address; Multihoming promptly returns DNS response according to the link quality. This provides unmatched availability of bandwidth and load-balances incoming traffic across the multiple ISP lines.
Simultaneously using multiple IP address provided by the ISP connections can result in problems with inbound traffic. For example, if the network is currently using an IP provided by ISP1, and a problem occurs with this ISP, then the inbound query will not be received because the external traffic only knows the IP address provided by ISP1. Also, by using the IP provided ISP1, ISP2 cannot manage the inbound traffic of ISP1. Therefore the concern with multiple ISP links is how to effectively display IP address to the external environment.
Multihoming uses DNS fault-tolerance technique to resolve this problems with the simultaneous use of multiple ISP connections. For example, if the web server for external traffic uses a single ISP connection, then any problems with that connection will affect the network. However, if the DNS periodically assigns different IP addresses provided by different ISP connections, then the external traffic will always have a valid IP to connect to. The actual implementation is assigning a name of different IP, and any query to this name will receive an IP address. As a result, different users can access the web server through different IPs, which is the purpose of Multihoming.
Assuming, there are three WAN links (therefore three different IPs) for the web site of www.example.com, the DNS record has three entries:
www IN A 211.21.10.3 www IN A 63.98.110.123 www IN A 192.136.1.243
All DNS requests to www.example.com will be sent to FortiWAN. Multihoming will constantly measure the health conditions as well as the state of each WAN link and compute the optimal return answer to the DNS queries, defined as the SwiftDNS technology. The SwiftDNS technology will not only ensure fault tolerance for inbound traffic, it also supports powerful and flexible load balancing algorithms as in the Auto Routing mechanism to enable users with heavy web presence to maximize the reliability and efficiency of their web services.
The SwiftDNS Multihoming mechanism requires network administrators to understand the details of the system behavior. The fundamental concept of the DNS mechanism is shown in the next section. A step by step deployment tutorial will also be provided.
Introduction to DNS
DNS server differs from the host file based on name resolution. Host file contains information of IP address mapping information. It is only useful for intranet where the information of host machines is relatively static. Name resolution by DNS server is dynamic because it can adapt to changes easily. The way it works is based on DNS server hierarchy on the Internet. If a DNS server cannot resolve a name (the information is not in its cache), it will ask other DNS servers. There is a protocol on how and where to ask other DNS servers.
A name resolution request may go through a number of DNS servers. When an answer is found, it will be saved in cache so that the same request can be answered immediately without asking other DNS servers again. Each name resolution result saved in cache has a TTL (Time To Live). After the period of TTL, it will be discarded in order to avoid stale information.
The whole internet has a large DNS hierarchy. The top of the hierarchy is called Root. It consists of a set of Root DNS servers coordinated by ICANN. The next level below Root is Top Level Domain (TLD). TLD registration database contains information about top level domains such as CA, COM, EDU, GOV, NET, etc. The next level below TLD is Second Level Domain (such as whitehouse.gov, Microsoft.com, inforamp.net, etc.) followed by Third Level Domain, and so on.
You can apply for domains for your organization. First, go to the Internet’s Network Information Center (InterNIC) to find out if the domain has been registered already. You can also consult the ICANN-accredited registrar database. Second, register the domain with a registrar. You have to provide at least two DNS servers to serve DNS requests. If your registration has been approved, then any DNS request to your domain will be forwarded to the DNS servers you are registered with. For example, xtera.com is registered and InterNIC has put the name “xtera” into the COM DNS servers.
Once the domain is registered, sub-domains can be created. Example: a part or the network can be named “sales.xtera.com”. InterNIC’s approval is not required for creating sub-domains. However, it is important to put DNS information about sales.xtera.com into the DNS servers of xtera.com.
Here is an example of how DNS hierarchy works. A user at a university sees a link to sales.xtera.com on a web page and clicks it. The browser will ask the local DNS server dns.utexas.edu about sales.xtera.com. Suppose it is not in the cache of dns.utexas.edu. The DNS server goes to a Root DNS server to find the DNS server for COM TLD. The DNS server for COM TLD tells dns.utexas.edu to go to dns1.xtera.com. Finally dns.utexas.edu is given the IP address of sales.xtera.com by dns1.xtera.com.
SwiftDNS
One of the problems with traditional DNS servers are facing is TTL. A long TTL means a long update time when IPs have been changed. Before the update time is up (i.e. TTL is expired), DNS requests may be answered with incorrect information. FortiWAN employs SwiftDNS for multihoming based on the health state of the link and a traffic re-directing algorithm. SwiftDNS dynamically answers DNS requests to prevent broken or congested links. In order to solve the TTL issue stated above, SwiftDNS maintains a very short TTL and actively sends out updates to internal DNS in case of link status changes.
How does SwiftDNS work?
Here is an example to illustrate how SwiftDNS works. When Multihoming is enabled, SwiftDNS becomes active. In this case, the upper level DNS server for example.com has two NS records and they are for Primary DNS server at 210.58.100.1 and Secondary DNS server at 210.59.100.1. Both of them are pointing to FortiWAN.
In this case, a web site at 192.168.100.1 in LAN is exposed to these two IPs. When both ISP links are working properly, FortiWAN replies to DNS requests for www.example.com with 210.58.100.1 and 215.59.100.1 at ratio of 1:2 (weight ratio).
Assuming ISP1 is down and a DNS request for www.example.com comes in, it would not be able to go through 210.58.100.1 but it will be able to reach 215.59.100.1. Multihoming detects the link status of WAN1 and answer the request with 215.59.100.1.
Prerequisites for Multihoming
In order to multihome properly, review the requirements below.
Prerequisites for Multihoming:
- Multiple WAN links (minimum of 2).
- Registered domain names for public servers. Please make sure DNS requests for the domains can be delivered to FortiWAN. l Public servers must be configured as virtual servers, or have public IPs
Besides, Multihoming is a non-recursive name server which is an authoritative DNS service that allows others to find your domain only. Multihoming does not answer for unknown domains.