IPv4 Dynamic Routing
Now that you have seen how to configure simple routing on both the Linux and Cisco platforms, consider how to automate some of the routing structure itself.
In most networks today, especially corporate and ISP internal networks, there are more than a few physical and logical networks. These networks also tend to change both through additions and deletions as well as simple reconfiguration. Tracking and updating all of the routers within such a network is painful enough when you consider just a handful of networks and routers, but it becomes an absolutely daunting task when the networks and routers exceed the fingers on one hand, especially when the network spans locations and topologies.
Another problem often seen in larger routed networks is maintaining a list of networks that are non-operational. In such a case, the reachability of the network becomes a prime concern. When a network is unreachable, packets sent to it are just discarded and the emphasis is placed on the ICMP error messages providing the routers with this information. In an automated, or dynamic, routing environment the routing protocol itself can often fulfill this notification function in a more consistent manner.
The early answer to this was the original Routing Information Protocol, RIP. Version 1 of this protocol, as defined in RFC-1058, under IPv4 provided an automated means for routers and systems to transfer knowledge of the routing structure of the network between the devices. For serious study and details, see Stevens and RFC-1058. Note that RIPv1 has been declared historic (see RFC-1923), which means that it is good for study only. This is due to its classfull nature. Because the RFCs define in many cases the actual protocol specifications and implementations for many facets of networking, you might want to know where to obtain and read them. A good place to start is the official core repository located at http://www.rfc-editor.org.
RIP/Distance Vector
RIPv1, and the next generation RIPv2 as defined in RFCs 1387–1389 (which I will generally refer to simply as RIP), is the primary dynamic routing protocol considered on IPv4 networks. RIP is based on the Bellman-Ford (or distance vector) algorithm. The Bellman-Ford algorithm has been used for routing computations in computer networks since the early days of the ARPAnet. RIP is most useful as, and is usually seen as, an "interior gateway protocol." This concept refers to the dynamic routing methods used within a single network structure such as a corporate network.
Under RIP the concept of passing a packet through a router is considered as a discrete action. This action is referred to as a hop, and the number of times a packet passes through routers from source to destination is the hop count. Routers that participate in the RIP routing structure will pass information to each of the local directly connected networks about all of the routes it has and the associated hop count for each route listed. This information is presented on the directly connected network using a broadcast. Usually there is one router that has a defined default route that it also provides through RIP.
By configuring RIP on a router you can remove the need to define static default and additional routes on each system. You need only ensure that the router knows about its own directly connected networks and how to talk with other RIP-enabled routers. Then the various routers talk among themselves and provide routing information to each other.
One of the few drawbacks to RIP is that routes with a hop count greater than the network defined radius of 15 will be ignored by the receiving router. Also, RIP does not provide a method of having more than one route between any two networks. These and other limitations are discussed in Chapter 2, "Policy Routing Theory" and Chapter 7, "Dynamic Routing Interactions."
The basic problem with using RIP in a large-scale network lies in the core algorithm. The Bellman-Ford distance vector concept refers to a partial routing state within the scope of the locally connected networks. In other words, none of the routers participating in RIP can know the full extent and state of the network. All they know is the local routers within their directly connected networks and the routes that are known to those routers. This is often referred to as "routing by rumor." Since the routers cannot know the full routing state of the network, all they know is what they obtain by gossiping with their neighbors.
OSPF/Link State
This gossiping limitation leads into the higher stage of interior gateway protocols, where each router has full knowledge of the entire network scope. This type of dynamic routing protocol refers to the link-state of the network. A link-state encompasses the current status of an individual connection between two routers on a common network. This includes allowing for the relative speeds, types, and uses of the intermediary network and routers. Since each router participating in a link-state routing structure has knowledge of all other connections within the network scope, you can have multiple connections between networks and multiple definitions of the logical networks themselves.
The defining protocol for link-state is Open Shortest Path First, referred to as OSPF. The OSPF protocol was first defined in RFC-1131 and has been updated to version 2 and a forthcoming version 3 also known as OSPF for IPv6. OSPFv2 is the preferred protocol for use within a single structure network due to the ability to correctly handle large IP-based networks with multiple connections.
As detailed in RFC-1245, OSPF routers exchange link-states through link-state advertisements (LSAs) that describe pieces of the OSPF routing domain. These LSAs are flooded throughout the routing domain, with each router aggregating these LSAs to form the link-state database. Thus each router has an identical link-state database. Synchronization of link-state databases is maintained via a reliable flooding algorithm, which is based on multicast capabilities with fallback to directed broadcast or single programmed connections. From this link-state database, each router builds a routing table by calculating a shortest-path tree, with the root of the tree being the calculating router itself. This calculation is commonly referred to as the Dijkstra procedure.
OSPF brings several levels of security and robustness to the dynamic routing structure. For more details please see RFC-1245 (http://www.ietf.org/rfc/rfc1245.txt), which discusses the OSPFv2 protocol technical details. For this book's purposes I will treat OSPF as the preferred dynamic routing structure and will detail how it can interoperate with the Policy Routing structures in Chapter 7.
Dynamic Routing Tradition
At this stage you are probably wondering why I am talking about all of these routing protocols. They sound as if they take care of a lot of problems with an IP-routed network. They do. But they still adhere to and promote the fundamental thought of traditional IPv4 routing: All routing is a destination-driven process. Dynamic routing protocols merely make it easier to spread the destination-driven routing information around the network. When you begin to consider Policy Routing structures and the needs that drove their creation (discussed in Chapter 2), this dissemination of information becomes a hindrance. Chapter 7 will take up the question of how to strike the best balance between the ease of dissemination provided by dynamic routing and the needs for structure in the Policy Routing world.