Lesson 7 -- Dynamic Routing with OSPF

Your boss was reading a trade magazine over the weekend, and on Monday morning, mentions to you that she had read an article about another routing protocol known as OSPF. She says that the article claimed that OSPF was a much better protocol than RIP, since it uses some more efficient metrics to calculate routes and is less "chatty" than RIP. You agree that these statements are probably true, but state that, on a network the size of the one you maintain, the differences between RIP and OSPF are probably irrelevant. Nevertheless, your boss strongly suggests that you should (no pun intended) rip RIP out of the configs and replace it with OSPF. You shrug, and agree to make the change. First, you log into the remote router, remove RIP, and configure OSPF:

lab3640rtr# conf t
lab3640rtr(config)# router ospf 2112
lab3640rtr(config-router)# router-id 192.168.3.6
lab3640rtr(config-router)# network 192.168.3.4 255.255.255.0 area 0
lab3640rtr(config-router)# redistribute connected
lab3640rtr(config-router)# exit
lab3640rtr(config)# exit
lab3640rtr#


...and on the main office router:

lab2651rtr(config)#no router rip
lab2651rtr(config)#router ospf 2112
lab2651rtr(config-router)#router-id 192.168.3.5
lab2651rtr(config-router)#network 192.168.3.4 255.255.255.0 area 0
lab2651rtr(config-router)#redistribute connected
lab2651rtr(config-router)#redistribute static
lab2651rtr(config-router)#exit
lab2651rtr(config)#exit
lab2651rtr#


Here's what we did:
* Tell the router to stop the RIP routing process.
* Tell the router to start the OSPF routing process. It is possible to run multiple OSPF processes on a single router, so when starting an OSPF process, you must supply it with a process ID. The process ID is entirely arbitrary -- it contains no particular significance, except that it must be unique for every instance of OSPF running on any given router.
* The OSPF routing process must be able to identify itself with other OSPF-enabled routers, so you must give it a router ID, in the format of an IP address. Again, this is somewhat arbitrary, but it must be unique on the OSPF area, so common practice is to assign one of the IP address on the router itself as the router ID, as it is unlikely that another router in the same OSPF area will have the same IP address (barring interconnected routers NAT'ing RFC-1918 LANs and using the same private IP address for each LAN, in which case, you should use one of the routed IP addresses on the router). The rest of the config is very similar to the RIP configuration, except that the "network..." statements are a little more complex. OSPF is a classless protocol, so you need to provide the subnet mask as well as the network of the address through which OSPF will be sending routing advertisements. Also, there's the "area 0" clause at the end of the network statement. To greatly oversimplify, keep the OSPF areas consistent between routers that should be sharing routes. For a more detailed explanation of OSPF areas, follow the Cisco.com link above.

Once again, test connectivity between hosts on the branch office network and the main office network. If things aren't working, start troubleshooting with the "sho ip route" command, and double-check the config statements in your running configuration. Another valuable tool is the "show ip ospf neighbor" command. When two routers share routes through OSPF, they create what is called a "neighbor" relationship. If you don't see the "neighbor" router in the output of the "sho ip ospf neighbor" command, then you have some troubleshooting to do. Make sure you are advertising OSPF out the correct interface(s). Make sure the OSPF areas are configured consistently. Make sure that the link between the two routers is up. Also, be patient. If you dig into more advanced OSPF configuration, you will see a number of timers that control how often OSPF sends updates to neighbor routers. It can take a minute or two for OSPF to converge, so if you don't see the neighbor relationship right away, wait a minute or two, then check again.