Dynamic Routing Protocols

Dynamic routing is the most flexible and effective approach to provide redundancy for alternative paths and the only way to detect network node, port, or link failures reliably. Routing and standby protocols rely on the simple principle that if a speaker hasn't heard from a neighbor in a certain time, something must be wrong. Load balancing over multiple links can be accomplished in several ways: BGP "pseudo" load balancing can be achieved in dual-homed Internet service provider (ISP) architectures, Multilink PPP, and link-state Equal-Cost Multi-Path (ECMP) for interior gateway protocol (IGP) paths. It is a good idea to fine-tune protocol parameters for fast-converging resilient architectures or deploy incremental SPF (iSPF). Routing provides the signaling protocols to detect and route around failures within highly meshed nondeterministic IP networks.
DNS Shuffle Records and Round-Robin (DNS RR)
DNS round-robin (DNS RR), as shown in Example 12-2, is the concept of entering multiple IP addresses for one fully qualified domain name (FQDN). It is qualitatively described in RFC 1794, "DNS Support for Load Balancing." When a DNS resolver (client) request reaches the server, it answers in an unweighted round-robin fashion. Although the server answers with the complete round-robin set, most clients consider only the first entry, which works as long as the server cycles the entries. This results in almost equal but crude and inefficient (unweighted) load distribution to resources of equal content or services. Nevertheless, this approach has several drawbacks, such as DNS caching problems and a considerable percentage of the requests directed lost when just one constituent of the DNS RR group becomes unavailable.

DNS RR essentially is deployed for migration scenarios, load balancing, and in poor-man redundancy architectures. For the Internet Systems Consortium's (ISC) point of view regarding the implications on Berkeley Internet Name Domain (BIND), read the excellent BIND load-balancing comment at http://www.isc.org/products/BIND/docs/bind-load-bal.html. For BIND-specific configuration options, consult the documentation that comes with your version of BIND.

Example 12-2. DNS RR Server Setup

www.iktech.net 300 IN A 192.168.1.1

www.iktech.net 300 IN A 192.168.2.1

www.iktech.net 300 IN A 192.168.3.1




To my knowledge, DNS servers support the following approaches to round-robin-like regimes:[1]

Shuffle— Only one address at any given time from a list of address candidates is presented to the resolver (not possible in BIND, but with commercial load balancers).

SRV records— An added weight integer specifically describes the ordering (weighted DNS RR). This requires application support, however.

Sortlists (Example 12-3)— This refers to sorting of all address pools according to the source address of the querying resolver. For a detailed discussion, consult the BIND documentation at http://www.isc.org/products/BIND/.

Example 12-3. BIND Sortlist

sortlist {

{ localhost;

{ localnets;

192.168.1/24;

{ 192,168.2/24; 192.168.3/24; }; }; };

{ 192.168.1/24;

{ 192.168.1/24;

{ 192.168.2/24; 192.168.3/24; }; }; };

};




Rrset order (Example 12-4)— When a DNS response contains multiple records, it might be useful to configure the order in which the records are placed into the response (shuffle, cyclic round-robin, user-defined).

Example 12-4. BIND Rrset Order

rrset-order {

class IN type A name "www.iktech.net" order random;

order cyclic;

};




An alternative to these server-side approaches is to put the intelligence into the resolver/client application. However, this is difficult to predict and to deploy because resolvers are often part of an application.

If you want to manipulate the amount of traffic a specific round-robin participant receives, you can add alias addresses to the server and add additional entries to the DNS configuration. That's pretty much all you can do to alter the unweighted behavior. Be aware of possible caching issues and nondeterministic behavior and have a client-side sniffer ready to debug the queries and responses.

In closing, note that going one step further to ensure that the receiving server is up and available requires commercial-grade load-balancing solutions such as the Cisco server load balancing (SLB) IOS feature or the Cisco Local Director. Consult Cisco.com for a feature overview.

NOTE

For a flexible load-balancing name server written in Perl, by Roland Schemers, see the resources at http://www.stanford.edu/~riepel/lbnamed/.