Configuring OSPF on Cisco Routers

Although there is no shortage of contenders in the market, Cisco routers are arguably the most common business and carrier-class routers in use on the Internet today. As a result, anyone who aspires to be a network administrator would be well advised to learn how to configure, troubleshoot and administer Cisco's products. Even if you don't use Cisco equipment, many other makers of networking hardware and software emulate the look and feel of Cisco's command line interface to varying degrees in their products: Dell/SMC managed switches, Foundry switches, the open source "Quagga" routing daemon -- all of these products bear a distinct resemblance to Cisco's IOS.

Just as ubiquitous as Cisco equipment on the Internet, OSPF is one of the most important routing protocols used today. OSPF is used within a company or service provider's domain (called an "Autonomous System" or AS) to distribute information about how to reach the various networks encompassed by that AS. Fortunately, OSPF is very easy to configure on Cisco or Cisco-like equipment.

Let us consider a simple three-node network: router A, with a small LAN connected to FE0 and a T1 trunk from Serial 1/0; router B, with two T1 trunks, one from Serial 1/0 to router A and one from Serial 2/0 to router C; and router C, essentially a mirror image of router A. This network might conceptually look something like this:

As you can see, we have four networks in this simple example: 192.168.1.0/24, 10.0.0.0/30; 10.0.1.0/30 and 192.168.2.0/24. We want to use OSPF to distribute routes between these three routers. Here's how we make it work:

        $ssh root@routera
        routera# config t
        routera(config)# router ospf
        routera(config-router)# ospf router-id 10.0.0.2
        routera(config-router)# network 10.0.0.0/30 area 0.0.0.0
        routera(config-router)# exit
        routera(config)# exit
        routera# write mem
        routera# exit
        $
        $ssh root@routerb
        routerb# config t
        routerb(config)# router ospf
        routerb(config-router)# ospf router-id 10.0.0.1
        routerb(config-router)# network 10.0.0.0/30 area 0.0.0.0
        routerb(config-router)# network 10.0.1.0/30 area 0.0.0.0
        routerb(config-router)# exit
        routerb(config)# exit
        routerb# write mem
        routerb# exit
        $   
        $ssh root@routerc
        routerc# config t
        routerc(config)# router ospf
        routerc(config-router)# ospf router-id 10.0.1.2
        routerc(config-router)# network 10.0.1.0/30 area 0.0.0.0
        routerc(config-router)# exit
        routerc(config)# exit
        routerc# write mem
        routerc# exit
        $
      

There are a few things to notice in this example. First, OSPF must be configured in the router configuration mode, entered by typing...:

        router# config t
        router(config)# router ospf
      

If you have any experience working with Cisco equipment, this will seem very logical and straightforward to you.

Next, notice the first real configuration command you are giving:

        ospf router-id 
      

The RFC's defining OSPF require each router running OSPF have a (locally) unique, 32-bit router ID. Since IP addresses are also unique, 32-bit entities, common practice is to use an IP address on the router as the router ID.

Warning: Older versions of IOS require the router ID to be the highest numbered interface on the router, and require that this be a *stable* IP address to keep the OSPF process "happy". On older routers, you may need to use an IP address on a loopback interface to keep your OSPF network stable.

The "network w.x.y.z/a area 0.0.0.0" command basically "brings a network into" OSPF -- that is, it tells the OSPF process on the router to advertise routes to and from that network. In the diagram above, for example, Router A is advertising the 10.0.0.0/30 network out Serial1/0. Notice that the router is not advertising the 192.168.1.0/24 network via OSPF. Frequently, a stub network as shown in the example is using RFC-1918 (private IP address space) IP addresses behind a router providing Network Address Translation. Since RFC-1918 addresses are not publicly routable, you don't want OSPF to advertise these routes.

However, you also don't typically use OSPF to broadcast routes to the Internet; that is what BGP is for. And while a stub network using RFC-1918 address space is typically behind a NAT router connected to the Internet, there are definitely cases where you would use RFC-1918 IP space on an internetwork (NOT the Internet) that uses OSPF to distribute routes. Suppose, for example, that Router A and Router B are routers at a branch offices of some company with multiple locations, and that Router C is the router at the central office of the company. If this company is using some kind of leased private line (like a T1 or ISDN -- does anyone still use ISDN???) to link their locations, then they could have an entire internetwork using private IP addresses that uses OSPF to route from one branch office to the other. In this case, you would use the command "redistribute connected" to tell OSPF to advertise your stub networks as well as the networks that are advertising OSPF routes. You can also use the "redistribute connected" command to redistribute via OSPF routes learned from other routing protocols like RIP or IGRP.

So, why wouldn't you use the "network 192.168.1.0/24 area 0.0.0.0" command on Router A and the "network 192.168.2.0/24 area 0.0.0.0" command on Router B? Why use a second command ("redistribute connected") to include the stub network in the OSPF routes if you could just use the "network a.b.c.d..." command instead? In a nutshell, while using the "network..." command has the effect of including the speficied network in the OSPF routing table, it's real purpose is to tell OSPF to advertise routes to the specified network. There is no reason to advertise routes to a stub network, since by definition, there is only one egress path from a stub network. Every host on Router A's 192.168.1.0/24 network will be configured to use Router A as a default router, so there is no reason to use up the bandwidth on your network advertising OSPF routes there. The "redistribute connected" command is therefore a more efficient way of including your stub network in the OSPF routing table.

Here is what your OSPF config would look like if you wanted to advertise the stub networks in the diagram above, but didn't want to broadcast OSPF routes to the stub networks:

        $ssh root@routera
        routera# config t
        routera(config)# router ospf
        routera(config-router)# ospf router-id 10.0.0.2
        routera(config-router)# redistribute connected
        routera(config-router)# network 10.0.0.0/30 area 0.0.0.0
        routera(config-router)# exit
        routera(config)# exit
        routera# write mem
        routera# exit
        $
        $ssh root@routerb
        routerb# config t
        routerb(config)# router ospf
        routerb(config-router)# ospf router-id 10.0.0.1
        routerb(config-router)# redistribute connected
        routerb(config-router)# network 10.0.0.0/30 area 0.0.0.0
        routerb(config-router)# network 10.0.1.0/30 area 0.0.0.0
        routerb(config-router)# exit
        routerb(config)# exit
        routerb# write mem
        routerb# exit
        $   
        $ssh root@routerc
        routerc# config t
        routerc(config)# router ospf
        routerc(config-router)# ospf router-id 10.0.1.2
        routerc(config-router)# network 10.0.1.0/30 area 0.0.0.0
        routerc(config-router)# exit
        router(config)# exit
        routerc# write mem
        routerc# exit
        $