Floating Static Routes

Floating static routes are a useful and simple measure to provide backup routes via another hop or link. However, a floating static route just "lurks" there and does not provide load balancing! This can be as simple as two default routes that just differ in terms of metric or cost. As long as the preferred route with the better metric is available, the floating static route with the less attractive metric floats unused but suddenly takes over if the preferred route disappears. A requirement is an operating system that supports metrics for static routes. Lab 8-1 shows an example of this setup.

Classification of Dynamic Routing Protocols

Dynamic routing protocols are based on an algorithm, such as Bellman-Ford-Fulkerson, Dijkstra SPF (Shortest Path First), or the Enhanced Interior Gateway Routing Protocol (EIGRP) DUAL (Diffuse Update Algorithm). Based on these algorithms, dynamic IGPs can be classified in link-state and distance-vector protocols.

NOTE

The Border Gateway Protocol (BGP) discussed in the next chapter represents a path-vector protocol essentially based on a distance-vector approach as well.



The main task of these protocols is path determination and calculation. With multiple paths to a destination prefix, the protocol makes intrinsic decisions based on metrics/cost/preference assigned to routes. Such a label is a measure of preference within a particular routing protocol. It can be simple, such as hop count for RIP, or a composite metric such as with EIGRP based on load, reliability, delay, and bandwidth, or cost based in a generic way such as with OSPF.

Link-State Protocols
Link-state protocols such as OSPF are cost-based, and the cost is usually derived from the link bandwidth. When a protocol has a stable view of the topology, it is referred to as having converged or achieved equilibrium. Do not confuse this view with the notion of converged networks meaning voice, video, data, and storage over one consolidated IP infrastructure.

The task of computing shortest paths in a network is a mathematical problem tackled with graph theory. You will read more about that in the section "Introduction to Link-State Routing Protocols" later in this chapter. Nevertheless, one cannot argue that link-state protocols are superior in every aspect per se.

Distance-Vector Protocols
Distance-vector protocols usually broadcast full table updates. Deviation from this case is referred to as an asynchronous, triggered, flash, or incremental update.

Note the following:

The name distance vector is derived from the fact that routes are advertised as vectors of (distance, direction), where distance is defined in terms of a metric and direction is defined in terms of the next-hop router.[1]

For loop prevention, simple split horizon or split horizon with poisoned reverse is used in distance-vector protocols. A thorough discussion of loop detection, prevention, and termination goes beyond the scope of this book. I recommend Jeff Doyle's two volumes of Routing TCP/IP (Cisco Press; 1998 and 2001, respectively) for further information.

Introduction to Link-State Routing Protocols

Link-state routing protocols are based on Edsger W. Dijkstra's Shortest Path First (SPF) algorithm, a result of applied graph theory. Link-state protocols establish and maintain adjacencies via hello packets (connection-oriented) with their neighbors (peers), speaking the same routing protocol. The name link-state stems from the underlying concept that every participant distributes (floods) all the information states and conditions of its directly attached links.

The routers communicate via link-state advertisements (LSAs) with all their established neighbors. This behavior is referred to as flooding. The receiving routers never alter the LSA information, but add a copy to their link-state databases. After some convergence time, all the participants have a full, identical, and complete view (graph) of the area topology stored in their topology databases. Every router now calculates its own best paths (SPF) for all prefixes from its individual point of view and position in this topology. Hellos are also used as a keepalive mechanism between adjacent neighbors.

NOTE

A new approach referred to as incremental SPF (iSPF) or incremental Dijkstra allows SPF protocols to converge faster under certain conditions by recomputing only the part of the shortest path tree (SPT) that has changed. This calculation is considerably faster only under special circumstances. For more information, search Cisco.com for "incremental SPF" or "incremental Dijkstra." At the time of this writing, the implementation solely is a proprietary vendor playground.



The following discussion introduces two fundamental concepts of organizing routing realms: areas and autonomous systems.

Area Concepts
Areas are smaller realms (subsets) of a routing domain (autonomous system). It became obvious during the design of link-state protocols that the intrinsic mechanisms become problematic in large flat topologies with several hundreds to thousands of nodes. This involved convergence time, link bandwidth, node memory, and CPU consumption. The designers' response was a subdivision-area concept and, recently, incremental approaches to SPF.

Area separation in terms of a contiguous backbone area and attached leaf areas via area border routers (ABRs) considerably improved the matter by restricting LSA flooding to the area boundaries. This resulted in smaller topology databases, faster SPF computation with less memory/CPU consumption, and ultimately improved convergence behavior.

ABRs maintain several databases and need to be consulted for interarea routing. In general, ABRs inject default routes into the leaf area. OSPF has a "rich" repertoire of leaf-area flavors: stub areas, total stub areas, not so stubby areas (NSSAs), and NSSA total stub. For a concise discussion of the differences, see the "Recommended Reading" section at the end of this chapter.

All leaf areas need to have at least one connection to the backbone area. If this is not possible because of migration constraints or topology limitations, OSPF virtual links are used to establish backbone connectivity via a transit area. This concept is not implemented (or necessary) in IS-IS. Both protocols use a contiguous backbone.

Table 9-1 shows the four different area specifiers used within Cisco IOS Software and their GateD and Zebra counterparts if applicable.

Table 9-1. OSPF Area Flavors Area Specifier
GateD Notation
Zebra Notation

Stub
Stub
Stub

Total stub
Stub + restrict clause
Stub, no summary

NSSA
Not implemented
NSSA

NSSA total stub
Not implemented
NSSA, no summary





NOTE

One short bit of advice: Do not expect OSPF to compensate for poorly designed topologies or address planning!



The Full Picture—Autonomous Systems and Areas
Figure 9-2 shows a complete view of the macroscopic world. Autonomous systems can be organized into areas—either a flat backbone area or a backbone area with multiple connected leaf areas. Autonomous systems are not isolated; they communicate via Exterior Gateway Protocols (EGPs) with other autonomous systems, upstream carriers, or public peering points. BGPv4 is the dominant EGP used in today's Internet.

Route Filtering and Redistribution

shows an example for the Zebra redistribution commands. They pretty much work as under Cisco IOS Software. Consult Cisco.com for further information. Note that GateD provides similar route-filter facilities.

Example 9-24. Zebra Redistribution Example

callisto-ospfd# show running-config



Current configuration:

!

hostname callisto-ospfd

password 8 m6eyKycFMHniQ

enable password 8 bjYlnA9YLBWyM

log file /var/log/ospfd.log

service advanced-vty

service password-encryption

!

!

!

interface lo

!

interface eth0

!

interface eth1

ip ospf message-digest-key 1 md5 zebra

!

interface ipsec0

!

interface ipsec1

!

interface ipsec2

!

interface ipsec3

!

interface eth1:1

ip ospf message-digest-key 1 md5 zebra

!

interface lo1

!

interface wp1chdlc

ip ospf network point-to-point

!

router ospf

ospf router-id 192.168.1.1

compatible rfc1583

redistribute connected

redistribute static

redistribute rip route-map REDIMAP

network 192.168.1.0/24 area 0

network 192.168.14.0/24 area 5

network 192.168.45.0/24 area 0

network 192.168.99.0/30 area 0

area 0.0.0.0 authentication message-digest

area 5 virtual-link 192.168.201.4

distribute-list DISTRIMAP out static

capability opaque

!

access-list 1 remark vty-protection

access-list 1 permit 127.0.0.1

access-list 1 permit 192.168.1.0 0.0.0.255

!

route-map DISTRIMAP permit 1

match ip address 1

set metric 10

!

route-map REDIMAP permit 1

match ip address 1

set metric-type type-1

!

line vty

access-class 1

exec-timeout 0 0

!

end

Dynamic Routing Protocols

Dynamic Routing Protocols over Point-to-Point Tunnels—Transparent Infrastructure VPN
In general, IPSec tunnel setups cannot transfer routing protocols such as OSPF. IPSec does not always support the notion of an interface on which a routing engine (such as ospfd) can rely. (Remember, IPSec deals with SAs.) This can be accomplished by deploying OSPF over IP-IP/GRE tunnels over IPSec or out-of-band routing signaling not taking the crypto path.

Given the caveat mentioned with regard to TTL (TTL=1 breaks tunnel and multicasting) and MTUs, dynamic routing protocols work over tunnels pretty much the same way as over regular point-to-point links, as long as the routing engine can recognize the special interfaces associated with tunnels. Zebra/Quagga can deal with most implementations thanks to sound interface abstraction. For example setups of GRE over IPSec, see http://www.freeswan.ca/docs/HA/HA_VPNS_With_FreeSWAN.html.

IPSec Development and Evolution
The current efforts focus on specification of IKEv2, NAT-Traversal and firewall traversal, opportunistic encryption, DHCP over IKE, tight AES integration, and IPSec domains of interpretation (DOIs) for secure group communication and final touches to the IPv6 architecture. Currently, there is a significant trend toward hardware crypto-accelerator cards and chipsets that relieve the CPU from performing 3DES/AES encryption (and, most recently, that perform hashing calculations in hardware).

AES has improved crypto efficiency greatly; however, sustainable gigabit crypto throughput is still a domain of expensive commercial firewalls. An interesting addition to IPSec is the keynote trust management system that remedies some of the disadvantages of PKIs (introduced in RFC 2704 and RFC 2796). Also visit http://www1.cs.columbia.edu/~angelos/keynote.html.

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/.