16.4 Open Shortest Path First (OSPF) OSPF was designed in the late 1980s to get around the limitations of distance-vector protocols such as RIP. At that time, the Internet was a fraction of its current size , but even then the idea of using a hop count to get around the Internet didn't seem to make sense. The result is OSPF (Open Shortest Path First). The Open comes from the fact that the protocol was developed in an Open fashion by the Internet Engineering Task Force (IETF). The SPF is the clever part. OSPF is a link-state protocol where an entire map of the entire network is maintained by every node (known as the Link State Database ). Updates to the map can occur on a regular basis when links fail and new links are established. Updates are coordinated through Designated and Backup Designated Routers . When routers join the network, they go through an election process to select the most suitable Designated Router based on how well connected a router is. The Shortest Path part of the equation comes from the ability of the protocol to support multiple metrics to calculate the cost of a particular link. These metrics can include delay time, throughput, monetary cost, and reliability. When a node needs to select a path through the network, it will consult the Link State Database . As you can start to appreciate, OSPF is taking us into rather deep and meaningful discussions. If you are interested in taking this discussion further, check out the excellent book Routing on the Internet by Christian Huitema, which goes into great detail about the protocols surrounding OSPF. 16.4.1 OSPF Areas and Autonomous Systems We mentioned that OSPF was designed to get around many of the limitations of RIP by allowing multiple metrics to designate the cost of a link as well as maintaining a Link State Database that is distributed to all nodes in the network. If we think of a network like the Internet, it becomes inconceivable to imagine a single Link State Database that covers the entire Internet. You are absolutely right that it would be like trying to maintain a paper-based record of all IP Address and hostnames on the Internet. The way around this is to divide a large network into Areas. The size of an Area is arbitrary, but a common analogy is to think of an area in the same context of a DNS domain. The Link State Database has a boundary that extends to the edge of the Area. The Link State Database contains records of every node in the Area. In this way, OSPF (like RIP) is known as an Interior Gateway Protocol. Areas are connected by the idea of a Backbone Area. Area-Border nodes are nodes that belong to more than one area (one lower-level Area and a Backbone Area) and maintain a Link State Database for both Areas. Once this concept of an Area grows beyond the bounds of a reasonably large network, we start getting into issues of physical connectivity of a router on the border of Areas. There is also the problem of the size of the Link State Database, and if a node is connected to multiple Areas, the memory requirements of such a node become significant. Then we throw into the mix several updates to the Link State Database including a software and hardware update for the router itself. As you can imagine, the concept of an Area has limits. The original designers of Arpanet realized the limitations of using a single-network concept. This led to the concept of Autonomous Systems . As the name suggests (to me anyway), an Autonomous Systems (AS) can operate quite happily on its own. An Autonomous System is made up of a collection of subnets of interconnected routers running IGP protocols to communicate with each other. In order to communicate with the AS, you need to have a router that understands how an AS is defined (it's got an address) and where it is located in relation to other nodes on the network (we need to know its IP address on our network). In essence, the AS router is our exit point from our AS to another AS. The difference here is that all we are maintaining is information on how to reach another AS, not the internal detail as we do with objects such as the Link State Database (hence, the Autonomous part of the name). Once we get inside the AS, we start communicating with internal routers using Interior Gateway Protocols. To glue all these large, interconnected networks together required a few interconnected routers running additional software allowing them to learn about their neighboring AS. The result was the Exterior Gateway Protocol (EGP). Put in its simplest form, EGP allows Autonomous Systems to discover neighboring Autonomous Systems . There have been subsequent protocols since EGP including BGP (Border Gateway Protocol) and IDRP (Inter-Domain Routing Protocol). The address of an AS is a 16-bit AS number. The allocation of these numbers is controlled by the same organizations that assigns IP addresses (http://www.iana.org). Figure 16-2. Autonomous Systems and Areas. 
16.4.2 OSPF example using a single Area We look at a simple configuration involving two nodes (one a router, one a client) within a single Area. Unfortunately, we don't have the time or space to discuss Exterior Gateway Protocols. Essentially, we need to decide on an area number, the behavior of some parameters that control how quickly OSPF responds to link failures, and the behavior of the HELLO protocol. Obviously, it can get much more involved than that. This is a simple example to prove what is possible in a short space of time. I hope it gives you the confidence to try this on your own network. Nodes/routers with multiple interfaces require a bigger, but no more complex, configuration. Choosing path costs and priorities are based on the capacity/reliability/cost of the link. Here's an example for our node hpeos003 :
root@hpeos003[] vi /etc/gated.conf # # This is an initial /etc/gated.conf file. # Note that this file should be modified according # to the routing topology. Refer to the sample # configuration files in the "/usr/examples/gated" directory. # See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; }; routerid 192.168.0.33; ospf yes { area 0.0.0.2 { authtype none ; interface lan0 cost 10 { enable; priority 10; hellointerval 10; transitdelay 10; retransmitinterval 10; routerdeadinterval 30; }; interface lan920 cost 5 { enable; priority 5; hellointerval 10; transitdelay 10; retransmitinterval 10; routerdeadinterval 30; }; }; }; root@hpeos003[] root@hpeos003[] gdc checkconf configuration file /etc/gated.conf checks out okay root@hpeos003[] root@hpeos003[] gdc stop gated signaled but still running, waiting 8 seconds more gated terminated root@hpeos003[] root@hpeos003[] gdc start gated started, pid 2273 root@hpeos003[]
Nodes with a single interface will have a slightly simpler configuration:
root@hpeos002[] # cat /etc/gated.conf # # This is an initial /etc/gated.conf file. # Note that this file should be modified according # to the routing topology. Refer to the sample # configuration files in the "/usr/examples/gated" directory. # See gated-config(4) for details. # @(#)B.11.11_LR # traceoptions "/var/adm/gated.trc" size 10M files 2 route; interfaces { interface all passive ; }; routerid 192.168.0.34; ospf yes { area 0.0.0.2 { authtype none ; interface lan0 cost 10 { enable; priority 10; hellointerval 10; transitdelay 10; retransmitinterval 10; routerdeadinterval 30; }; }; }; root@hpeos002[] # root@hpeos002[] # gdc checkconf configuration file /etc/gated.conf checks out okay root@hpeos002[] # gdc stop gated terminated root@hpeos002[] # root@hpeos002[] gdc start gated started, pid 3850 root@hpeos002[]
We should spend some time testing this configuration to ensure that it can sustain the loss of a link without too much interruption ( routerdeadinterval = 30 seconds). There is the interactive command ospf_monitor , which allows you to query OSPF statistics from remote machines. First, you create a database file of the machines you want to communicate with and then you run ospf_monitor :
root@hpeos002[] # cat /tmp/ospf 192.168.0.33 hpeos003 root@hpeos002[] # root@hpeos002[] # ospf_monitor /tmp/ospf task_get_proto: getprotobyname("ospf") failed, using proto 89 listening on 0.0.0.0.49670 [ 1 ] dest command params > @1 o remote-command <o> sent to 192.168.0.33 Source <<192.168.0.33 hpeos003>> AS Border Routes: Router Cost AdvRouter NextHop(s) ---------------------------------------------------- Area 0.0.0.2: Area Border Routes: Router Cost AdvRouter NextHop(s) ---------------------------------------------------- Area 0.0.0.2: Summary AS Border Routes: Router Cost AdvRouter NextHop(s) --------------------------------------------------- Networks: Destination Area Cost Type NextHop AdvRouter ---------------------------------------------------------------------------- 192.168.0.32/27 0.0.0.2 10 Net 192.168.0.33 192.168.0.34 192.168.0.64/27 0.0.0.2 20 Net 192.168.0.35 192.168.0.67 ASEs: Destination Cost E Tag NextHop AdvRotuer ----------------------------------------------------------------------------- Total nets: 2 Intra Area: 2 Inter Area: 0 ASE: 0 done [ 2 ] dest command params > [ 3 ] dest command params > @1 N remote-command <N> sent to 192.168.0.33 Source <<192.168.0.33 hpeos003>> Interface: 192.168.0.33 Area: 0.0.0.2 Router Id Nbr IP Addr State Mode Prio ------------------------------------------------------ 192.168.0.34 192.168.0.34 Full Slave 10 192.168.0.35 192.168.0.35 Full Slave 10 done [ 4 ] dest command params > [ 4 ] dest command params > ? Local commands: ?: help ?R: remote command information d: show configured destinations h: show history x: exit @ <remote command>: use last destination @<dest index> <remote command>: use configured destination F <filename>: write monitor information to filename S: write monitor information to stdout (defalut) [ 5 ] dest command params > quit root@hpeos002[] #
There are many other options to the command than the ones listed above. This is but a simple introduction. There is quite a good description of the commands you can use in the man page for ospf_monitor . OSPF is certainly the interior routing protocol of choice at the moment. It is so popular that it has even made it into the world of Fibre Channel. The protocol used in a switched fabric is known as FSPF (Fibre Shortest Path First) and is a subset of OSPF. Get to know it because it's here to stay for some time. | 