You want to run OSPF on a simple network.

You can enable OSPF on a router by defining an OSPF process and assigning an address range to an area as follows:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#router ospf 87
Router5(config-router)#network 0.0.0.0 255.255.255.255 area 0
Router5(config-router)#end
Router5#

The first line in this configuration example defines the OSPF process:

Router5(config)#router ospf 87

The OSPF process number (87) doesn’t propagate outside of the area, so you can actually use any value here. In fact, the OSPF process number doesn’t even propagate outside of the router; you can use a different value for every router in an AS. Note that this is different from EIGRP, where every router in the AS must have the same process number. The process number can take any value between 1 and 65,535.

The network statement in this example takes the simplest possible approach to defining areas by putting every interface on the router into Area 0:

Router5(config-router)#network 0.0.0.0 255.255.255.255 area 0

The first two arguments of the network statement are an IP address and a corresponding set of wildcard bits. In this case, 0.0.0.0 255.255.255.255 matches every possible IP address, so every interface on this router is assigned to Area 0.

In this example, we have defined the area using a single number. You can define area numbers to be anything between 0 and 4,294,967,295. You can also use dotted decimal notation for areas, in which case you would write Area 0 as 0.0.0.0.

OSPF treats the area number internally as a 32-bit field regardless of whether you choose to represent it as a single number or by using dotted decimals. You could mix and match if you wanted to, but we recommend picking whichever approach better suits your network and sticking to it. It is far too easy to get confused when translating between the two formats.

For small networks it is generally easier to remember single numbers. But for larger networks it is often easier to work with dotted decimal notation, perhaps developing some locally meaningful mnemonic to help give the area numbers significance. For example, in an international WAN, you might want to make the first octet stand for the country, the second for state or province, the third for city, and the fourth for the actual area. Or you might want to make the area numbers the same as the summary IP addresses for each area. The only special area number is Area 0, which is the routing backbone of the network and must connect to all other areas directly, as we discussed in the introduction to this chapter.

If you have more than one network statement, the order becomes important. In the following example, the last line matches all IP addresses and assigns them to Area 0. But, because this line comes last, it only picks up any addresses that are not captured by either of the lines above it. However, if we had written this line first, then all of the interfaces would wind up in Area 0:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#network 10.0.0.0 0.255.255.255 area 2
Router1(config-router)#network 172.20.0.0 0.0.255.255 area 100
Router1(config-router)#network 0.0.0.0 255.255.255.255 area 0
Router1(config-router)#end
Router1#

The show ip protocols command lists useful information about the OSPF configuration:

Router1#show ip protocols
Routing Protocol is "ospf 55"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.25.25.1
  It is an area border and autonomous system boundary router
  Redistributing External Routes from,
  Number of areas in this router is 3. 3 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.0.0.0 0.255.255.255 area 2
    172.20.0.0 0.0.255.255 area 100
    0.0.0.0 255.255.255.255 area 0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.30.1         110      00:01:30
    172.25.25.6          110      16:44:07
    172.25.25.1          110      00:01:30
    172.25.25.2          110      00:01:30
    172.25.1.7           110      00:01:30
    172.25.1.1           110      16:56:15
  Distance: (default is 110)
Router1#

If you want more control, you can specify individual interface IP addresses with a wildcard mask of 0.0.0.0 to match only one address at a time:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#router ospf 87
Router5(config-router)#network 172.25.1.7 0.0.0.0 area 101
Router5(config-router)#network 172.25.25.6 0.0.0.0 area 102
Router5(config-router)#end
Router5#

This can be useful when your addresses don’t summarize well, which can be the case when you are changing your network architecture or merging two networks.

You want to apply a filter so that OSPF populates only certain routes into the routing table.

You can filter inbound routes to prevent the router from putting them in its routing table:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#access-list 1 deny 172.20.10.0
Router5(config)#access-list 1 permit any
Router5(config)#router ospf 87
Router5(config-router)#distribute-list 1 in Ethernet0
Router5(config-router)#end
Router5#

The OSPF algorithm requires that every router in an area receive all of the LSAs for that area, so you cannot filter outbound routing information:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#router ospf 87
Router5(config-router)#distribute-list 1 out Ethernet0
% Interface not allowed with OUT for OSPF
Router5(config-router)#end
Router5#

It’s important to remember that, unlike EIGRP and RIP, OSPF uses a link state rather than a distance vector algorithm. One place where this difference becomes clear is in route filtering. At a minimum, every router in an area must see the LSAs for every other router in the same area. Depending on the type of area, it may also see summary LSAs representing routing information from other areas or ASes. These LSA packets are flooded throughout the area, with each router forwarding LSA information on to any downstream devices. Every router then separately computes the best routing table based on this link state information.

If you prevented a router from forwarding some of the LSA information, its downstream routers would not have a full link-state database, and consequently wouldn’t be able to generate an accurate routing table.

Therefore, it is not possible to do the kind of route filtering that we discussed for RIP and EIGRP in Chapters Chapter 6 and Chapter 7. The only filtering we can do is to prevent a router from installing a route learned via OSPF into its routing table. This way, the link state database remains intact on every router in the area. If you really want to break up the forwarding of LSA information, subdivide the area.

You can see the effect of the inbound filter by looking at the routing table both before and after applying the filter. Before the inbound filter is enabled, you can see that the route is there:

Router5#show ip route 172.20.10.0
Routing entry for 172.20.10.0/24
  Known via "ospf 87", distance 110, metric 84, type inter area
  Redistributing via ospf 87
  Last update from 172.25.1.5 on Ethernet0, 00:00:07 ago
  Routing Descriptor Blocks:
  * 172.25.1.5, from 172.25.25.1, 00:00:07 ago, via Ethernet0
      Route metric is 84, traffic share count is 1
Router5#

Then, after we apply the filter, the route is gone:

Router5#show ip route 172.20.10.0
% Subnet not in table
Router5#

Chapter 6; Chapter 7

You want to change the OSPF link costs.

The auto-cost reference-bandwidth command allows you to change the reference bandwidth that OSPF uses to calculate its metrics:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#router ospf 87
Router5(config-router)#auto-cost reference-bandwidth 1000
Router5(config-router)#end
Router5#

You can also adjust the OSPF cost of a single interface with the ip ospf cost configuration command:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#interface Ethernet0
Router5(config-if)#ip ospf cost 31
Router5(config-if)#end
Router5#

The custom in OSPF networks is to make the link cost inversely proportional to the bandwidth of a link. This isn’t required, but it is common, and it is the default behavior for Cisco routers. The reference bandwidth defines the link speed that has an OSPF cost of 1. By default, the reference bandwidth is 100Mbps.

However, if you have faster links in your network (such as gigabit Ethernet or even OC-3 connections), OSPF can’t give these links a better cost than 1. So you should set the reference bandwidth to at least as high as the fastest link in your network. In fact, you may want to set this value higher than the bandwidth of your fastest link to ensure that you don’t have to reconfigure your whole network when you eventually upgrade some of your core links.

It is important to set the same reference bandwidth on all routers in an area, and preferably throughout the entire network. Recall that OSPF allows every router to calculate its own routing table based on the LSAs that they receive. So, they must all agree on the relationship between costs and bandwidth. Suppose you set the reference bandwidth differently on two routers, causing them to advertise different link costs for their Ethernet interfaces. This could cause seriously strange routing patterns as OSPF will try to avoid using the higher-cost links. It may decide, for example, that a FastEthernet interface on one router is faster than a Gigabit Ethernet interface on the other router.

But there is another interesting problem with the way OSPF calculates its metrics. Suppose your network includes one or more Gigabit Ethernet links in the core and a WAN that provides 9.6Kbps dial backup for the most remote branches. This means that the fastest link is over 100,000 times as fast as the slowest. When this happens, the router will simply apply the maximum link cost of 65,535.

The problem is that the OSPF metric is only 16 bits long, giving it a maximum per-link cost value of 65,535. So, if your fastest link used the emerging 10Gbps Ethernet standard, and you set the cost of this link to 1, then a relatively common 56Kbps serial link would need to have a cost of 178,571. Since this is not possible, OSPF would have to use the maximum link cost of 65,535. This in itself is not a problem. The problem is that your 128Kbps circuits would also need to have the same cost. This could cause some very poor routing patterns.

We suggest using an alternate costing strategy to avoid this problem. The idea is that the cost of a link doesn’t actually have to be 10 times as high just because the link is 1/10 as fast. In fact, this default behavior implies that it is better to go through a succession of 10 FastEthernet links rather than use a single Ethernet, which is probably not true in most cases. So a useful alternative strategy is to use the square root of the bandwidth instead of the bandwidth when calculating the link cost. The result of this strategy is shown in Table 8-2.

As you can see in Table 8-2, if you use the default costs, then the three fastest links all wind up with a cost of 1. Changing the reference bandwidth to 10Gbps, however, produces impossibly large metrics for the three slowest links (the router will assign them all a link cost of 65,535). So, no matter what reference bandwidth you use, if you retain the default 1/bandwidth cost mode, you will need to manually adjust either the fastest or slowest several link costs.

The second example shows how to change the OSPF cost for a single interface:

Router5(config)#interface Ethernet0
Router5(config-if)#ip ospf cost 31

If you change the OSPF cost of a link like this, make sure that all of the other routers that connect to this same network segment use the same cost, or strange routing will result. Further, it is usually a good practice to ensure that all of the links of a particular type have the same cost throughout the network, or at least throughout the area. So, if we set the OSPF cost for 10Mbps Ethernet to 31 on this router, we should do the same on the other routers as well.

There are times when you will want to make sure that one particular link is favored, regardless of its actual bandwidth. In this case, you can give this link a special OSPF cost value. However, you will generally want to be careful that all of the devices on this link agree on the cost.

You could also achieve a similar effect by just adjusting the bandwidth statements on each interface, but this will have other consequences as well. It will affect any other routing protocols that you might also be running. It also means that an SNMP query of the interface speed will give an incorrect value, which could confuse network management software. We recommend the direct approach of manually setting the OSPF cost because it is more clear what you are doing and why. This becomes most important when somebody else comes along and wants to change the router configuration. If your cost scheme is not clear, you could cause serious support problems for your successor.

You want to propagate a default route within an OSPF network.

To propagate a default route with OSPF, use the default-information originate configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.25.1.1
Router1(config)#router ospf 55
Router1(config-router)#default-information originate metric 30 metric-type 1
Router1(config-router)#end
Router1#

Unlike RIP and EIGRP, you cannot create a default route in OSPF by simply redistributing a static route. Even if there is a default route in the routing table, Cisco’s OSPF implementation will not forward it to the rest of the network by default. This is because OSPF uses a link state algorithm that keeps track of links rather than routes. So summary routes are very special elements in OSPF, and it’s important to be careful when distributing them. The default route, 0.0.0.0/0, is the ultimate summary of summaries, and it has the potential to cause serious confusion if it isn’t handled properly.

Cisco forces you to be sure that you really want to source a default route into OSPF by requiring you to specifically enable it with the default-information originate command. This command also allows you to specify precisely the metric of this default route and, since a default route is implicitly external to the AS, the type of external route. This has the added advantage of giving finer granularity of control over default route propagation.

You can look at the external routes in the OSPF database with the following command:

Router1#show ip ospf database external

            OSPF Router with ID (172.25.25.1) (Process ID 55)

                Type-5 AS External Link States

  LS age: 163
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 0.0.0.0 (External Network Number)
  Advertising Router: 172.25.25.1
  LS Seq Number: 80000002
  Checksum: 0x18E6
  Length: 36
  Network Mask: /0
        Metric Type: 1 (Comparable directly to link state metric)
        TOS: 0
        Metric: 30
        Forward Address: 0.0.0.0
        External Route Tag: 55

Router1#

In this example, you can see that the default route is advertised by the 172.25.25.1 router with a metric of 30 and a metric type of 1. The metric type in this case refers to whether this route is considered by OSPF to be a Type 1 or 2 external route. It is a Type 1 route—we configured it this way with the default-information command:

Router1(config-router)#default-information originate metric 30 metric-type 1

As we mentioned in the introduction to this chapter, the cost of a Type 1 external route is the cost shown by the external metric (which is 30 in this case), plus the internal cost to reach the router that advertises the external route.

Then, on another router in the same area, you can see that the default route’s cost is 40, because the cost to reach the ASBR is 10. All of the internal routers can see that this is a Type 1 external route, as well as other important attributes such as the administrative distance and the ASBR that originated this route:

Router5#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
  Known via "ospf 87", distance 110, metric 40, candidate default path
  Tag 55, type extern 1
  Redistributing via ospf 87
  Last update from 172.25.1.5 on Ethernet0, 00:01:24 ago
  Routing Descriptor Blocks:
  * 172.25.1.5, from 172.25.25.1, 00:01:24 ago, via Ethernet0
      Route metric is 40, traffic share count is 1

Router5#

With default routes in particular, you sometimes want to ensure that the original ASBR continues to advertise the external route even if it disappears from its routing table. You can do this by adding the keyword always to the default-information command as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 0.0.0.0 0.0.0.0 172.25.1.1
Router1(config)#router ospf 55
Router1(config-router)#default-information always metric-type 1
Router1(config-router)#end
Router1#

You can also create a default route using a stub area. In this case you can configure your ABR routers to advertise only a simple default route into the area. We discuss stub areas in Recipe 8.10.

Recipe 8.5; Recipe 8.10

You want OSPF to propagate one or more static routes.

To redistribute static routes into an OSPF process, use the redistribute static configuration command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#ip route 192.168.10.0 255.255.255.0 172.22.1.4
Router1(config)#ip route 172.24.1.0 255.255.255.0 172.22.1.4
Router1(config)#ip route 10.100.1.0 255.255.255.0 172.22.1.4
Router1(config)#router ospf 55
Router1(config-router)#redistribute static
% Only classful networks will be redistributed
Router1(config-router)#end
Router1#

As the warning message indicates, OSPF will redistribute only classful network routes by default. In the example we included three static routes. Of these routes, only 192.168.10.0/24 is classful. If we look at the routing table on a different router, we can see that the other two routes are not present:

Router5#show ip route ospf
O E2 192.168.10.0/24 [110/20] via 172.25.1.5, 00:02:49, Ethernet0
     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.2.0 [110/20] via 172.25.1.5, 00:02:49, Ethernet0
     172.20.0.0/16 is variably subnetted, 3 subnets, 3 masks
O IA    172.20.10.0/24 [110/1582] via 172.25.1.5, 00:02:49, Ethernet0
O IA    172.20.1.0/30 [110/1572] via 172.25.1.5, 00:02:49, Ethernet0
O IA    172.20.100.1/32 [110/1573] via 172.25.1.5, 00:02:49, Ethernet0
     172.22.0.0/24 is subnetted, 1 subnets
O       172.22.1.0 [110/20] via 172.25.1.5, 00:02:49, Ethernet0
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O       172.25.25.1/32 [110/11] via 172.25.1.5, 00:02:49, Ethernet0
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    10.2.2.2/32 [110/1573] via 172.25.1.5, 00:02:49, Ethernet0
O IA    10.1.1.0/30 [110/1572] via 172.25.1.5, 00:02:49, Ethernet0
Router5#

You can ensure that all routes are redistributed, classful or not, by including the subnets keyword:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#redistribute static subnets
Router1(config-router)#end
Router1#

As you can see, all three static routes are now advertised:

Router5#show ip route ospf
O E2 192.168.10.0/24 [110/20] via 172.25.1.5, 00:04:23, Ethernet0
     172.16.0.0/24 is subnetted, 1 subnets
O       172.16.2.0 [110/20] via 172.25.1.5, 00:04:23, Ethernet0
     172.20.0.0/16 is variably subnetted, 3 subnets, 3 masks
O IA    172.20.10.0/24 [110/1582] via 172.25.1.5, 00:04:23, Ethernet0
O IA    172.20.1.0/30 [110/1572] via 172.25.1.5, 00:04:23, Ethernet0
O IA    172.20.100.1/32 [110/1573] via 172.25.1.5, 00:04:23, Ethernet0
     172.22.0.0/24 is subnetted, 1 subnets
O       172.22.1.0 [110/20] via 172.25.1.5, 00:04:23, Ethernet0
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O       172.25.25.1/32 [110/11] via 172.25.1.5, 00:04:23, Ethernet0
     172.24.0.0/24 is subnetted, 1 subnets
O E2    172.24.1.0 [110/20] via 172.25.1.5, 00:00:24, Ethernet0
     10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
O IA    10.2.2.2/32 [110/1573] via 172.25.1.5, 00:04:23, Ethernet0
O IA    10.1.1.0/30 [110/1572] via 172.25.1.5, 00:04:23, Ethernet0
O E2    10.100.1.0/24 [110/20] via 172.25.1.5, 00:00:24, Ethernet0
Router5#

Another useful thing to notice about this output is the fact that all of these external static routes are marked as type E2, meaning that they are external routes of Type 2. As we discussed in the introduction to this chapter, any time you distribute a foreign route into OSPF, it is always considered external. This allows OSPF to ensure that it doesn’t create any loops through an external network when there are multiple connection points.

When OSPF distributes Type 2 external routes, it doesn’t add the internal link cost to the net route cost. OSPF always prefers Type 1 to Type 2 external routes because Type 1 routes do include the internal path cost in the metric. If you want to distribute static routes as Type 1 instead of the default Type 2, you need to include the metric-type keyword in the redistribute static command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#redistribute static subnets metric 40 metric-type 1
Router1(config-router)#end
Router1#

In this example, we have also set the default metric for these static routes to a value of 40. The next-hop router shows the total cost of the path as 60 because it now includes the internal cost of 20 to reach the ASBR sourcing the external static route:

Router5#show ip route 192.168.10.0
Routing entry for 192.168.10.0/24
  Known via "ospf 87", distance 110, metric 60, type extern 1
  Redistributing via ospf 87
  Last update from 172.25.1.5 on Ethernet0, 00:01:20 ago
  Routing Descriptor Blocks:
  * 172.25.1.5, from 172.25.25.1, 00:01:20 ago, via Ethernet0
      Route metric is 60, traffic share count is 1
Router5#

You want OSPF to distribute routes from another routing protocol.

The redistribute configuration command allows you to redistribute routes from another dynamic routing protocol into an OSPF process:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#redistribute eigrp 11 subnets
Router1(config-router)#end
Router1#

Redistributing external routes from another routing protocol is similar to redistributing static routes, as we did in Recipe 8.5. In the above example, all of the routes that this router learns through EIGRP process number 11 will be propagated into OSPF as Type 2 external routes. Also, as shown in the following output from the show ip protocols command, every route will be redistributed because we also included the subnets keyword. If we had not included this keyword, OSPF would only redistribute classful summary routes from EIGRP:

Router1#show ip protocols
Routing Protocol is "ospf 55"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.25.25.1
  It is an area border and autonomous system boundary router
  Redistributing External Routes from,
    static with metric mapped to 40, includes subnets in redistribution
    eigrp 11, includes subnets in redistribution
  Number of areas in this router is 3. 3 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.0.0.0 0.255.255.255 area 2
    172.20.0.0 0.0.255.255 area 100
    0.0.0.0 255.255.255.255 area 0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.25.1.7           110      00:06:24
    172.25.1.1           110      1d15h
    172.25.1.3           110      00:06:24
  Distance: (default is 110)
Router1#

If you prefer, you can redistribute routes from the foreign routing protocol as Type 1 external routes. To do this, you need to specify the metric-type keyword in the redistribute command:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#redistribute eigrp 11 subnets metric 35 metric-type 1
Router1(config-router)#end
Router1#

You can also do some rather interesting things when redistributing OSPF routes into another protocol. For example, you might choose to only redistribute internal routes to the foreign routing protocol:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router eigrp 11
Router1(config-router)#redistribute ospf 55 match internal
Router1(config-router)#end
Router1#

There are several other options for this match keyword. You could just as easily choose to match only external Type 1 routes as follows:

Router1(config-router)#redistribute ospf 55 match external type 1

You can also combine types to allow you to redistribute both internal and external Type 1 routes, but not external Type 2:

Router1(config-router)#redistribute ospf 55 match internal match external type 1

This match option on the redistribute command is much easier than configuring a route map. But, if you require still greater control and flexibility, route maps are the best choice. This is particularly true if you want to handle routing tags in a special way. For a discussion of using route maps while redistributing routes between protocols, please refer to Recipe 8.13 on OSPF route tagging.

Recipe 8.5; Recipe 8.13

You want to manipulate the Designated Router (DR) selection process on a particular subnet.

The ip ospf priority configuration command allows you to weight the DR selection process on a network segment. The following configuration examples are for three different routers that all share the same Ethernet segment. Router5 has the highest OSPF priority, so it will become the DR. Router1 has the second highest priority because we want it to be the Backup Designated Router (BDR).

Router1 is connected to this network segment through a VLAN trunk:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface FastEthernet0/0.1
Router1(config-subif)#ip ospf priority 2
Router1(config-subif)#end
Router1#

We will configure Router3 with a priority of 0. The default priority is 1. A router with priority 0 will never become the DR or BDR:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#interface FastEthernet0/0.1
Router3(config-subif)#ip ospf priority 0
Router3(config-subif)#end
Router3#

Router5 has the highest priority, so it will become the DR for the segment:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#interface Ethernet 0
Router5(config-if)#ip ospf priority 10
Router5(config-if)#end
Router5#

There are several reasons for rigging the DR election process, as we have done in this recipe. The most common reason is simply to ensure that the router closest to the network core is responsible for distributing routing information. This is actually a somewhat aesthetic requirement, because all of the routers in an area see all of the LSAs for that area. Nobody’s routing table is more accurate than anybody else’s, but making the router closest to the core be the DR can result in faster convergence for some network configurations.

There are two times when it is critical to force a particular router to become the DR. The first is when you are using MOSPF to handle multicast routing. MOSPF uses the same DR as regular OSPF. So, if you have a mix of MOSPF and regular OSPF on the same segment, it is critical that an MOSPF router be the DR, or no multicast routes will be distributed. Since Cisco routers do not support MOSPF, this means that you must set the priority to 0 for all Cisco routers on such a segment.

The second place where DR selection is critical is in Non-Broadcast Multiple Access (NBMA) networks. A typical example of this would be a Frame Relay WAN that uses multipoint subinterfaces, as described in Recipe 10.4. In this case, all of the routers are members of the same subnet, but only the central hub router can talk directly to the branch devices. A branch router should never act as DR because it can’t talk directly to any of the other branches. The central router is the only device that can be the DR, or the routing updates will not work.

If you don’t adjust the priorities to help force a particular winner to the DR election, the DR will be the router with the highest Router ID (RID) value. Please see Recipe 8.8 for a discussion of RID values.

It is important to note that setting a higher priority can help to rig the DR election process, but it doesn’t guarantee that another lower priority router device won’t become DR if it happens to be there first. If a higher priority router comes up on a segment that already has a DR, it will not preempt either the DR or the BDR. If the higher priority router isn’t available when a lower priority router joins the segment, then the lower priority router will become DR. Once a router is DR, it will remain DR until you either manually reset the neighbor relationships or until there is a network failure on the segment that forces the change.

The exception to this rule is when you configure a router with a priority of 0. In this case, the router will never become DR, even if it is the only router on the segment.

You can see the state of all of the neighboring routers on a segment with the show ip ospf neighbor command:

Router5#show ip ospf neighbor Ethernet0

Neighbor ID     Pri   State           Dead Time   Address         Interface
Router1           2   FULL/BDR        00:00:31    172.25.1.5      Ethernet0
Router3           0   FULL/DROTHER    00:00:31    172.25.1.3      Ethernet0
Router4           1   FULL/DROTHER    00:00:39    172.25.1.1      Ethernet0
Router5#

In this output, we have asked the router to only show the neighbors on the Ethernet0 interface. You can see that Router1 is the BDR, and the other two routers on the segment have a state of “DROTHER.” This means that they are neither DR nor BDR, but that they are neighbors. Notice that none of the routers listed is the DR. This is because the router we typed this command on was the DR itself.

You can verify that this router is the DR, and that it has a priority of 10 with the show ip ospf interface command:

Router5#show ip ospf interface
Ethernet0 is up, line protocol is up
  Internet Address 172.25.1.7/24, Area 0
  Process ID 87, Router ID 172.25.1.7, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State DR, Priority 10
  Designated Router (ID) 172.25.25.6, Interface address 172.25.1.7
  Backup Designated router (ID) Router1, Interface address 172.25.1.3
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:03
  Neighbor Count is 3, Adjacent neighbor count is 3
    Adjacent with neighbor Router3
    Adjacent with neighbor Router1  (Backup Designated Router)
    Adjacent with neighbor Router4
  Suppress hello for 0 neighbor(s)
Router5#

In the following example, we have increased the priority of Router4 to 10 as well. However, as you can see, not only does it not preempt the DR, it doesn’t even preempt the BDR:

Router5#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
Router4          10   FULL/DROTHER    00:00:30    172.25.1.5      Ethernet0
Router1           2   FULL/BDR        00:00:38    172.25.1.3      Ethernet0
Router3           0   FULL/DROTHER    00:00:30    172.25.1.1      Ethernet0
Router5#

Because higher priority routers will not preempt existing DR and BDR routers, if there are routers that should not become DR for any reason, you should be careful to set their priorities to 0. Otherwise, you may find that the DR is simply the router that has been active for the longest time, instead of the one that you actually wanted.

Recipe 8.8; Recipe 10.4; Recipe 23.7

You want to set the OSPF Router ID (RID) of a particular router.

There are several ways to set the OSPF RID. The easiest is to create and configure a loopback interface:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#interface Loopback0
Router5(config-if)#ip address 172.25.25.6 255.255.255.255
Router5(config-if)#end
Router5#

If you don’t want to use a Loopback interface, you can still force the router ID to use a particular IP address with the router-id configuration command:

Router5#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router5(config)#router ospf 87
Router5(config-router)#router-id 172.25.1.7
Router5(config-router)#end
Router5#

If you don’t use either of these methods, the router will select the highest IP address from its interfaces and use this as the OSPF RID. The trouble with doing this is that you might add a new IP address to the router at some point. If this new address is higher than the previous RID, the router will change its RID the next time OSPF restarts. This could have strange consequences because, if the interface priorities are the same, OSPF uses the highest RID to select the DR. Please refer to Recipe 8.7 for more information on DR selection.

We recommend using the loopback interface method. Loopback interfaces also ensure that there is a single unique IP address for every router in the network, which is extremely useful for network management. Further, it is common to configure your loopback addresses in DNS, but not to necessarily include all of your interfaces. This is useful if you enable domain name lookups on your router, as discussed in Recipe 8.16.

In IOS Version 12.0, Cisco introduced a new way to select the RID using the router-id command. This command allows you to set the RID to any IP address. You can even set the RID to be an address that is not configured on any of the router’s interfaces or even in any routing tables. However, this is not a very wise thing to do because it makes troubleshooting much more difficult.

In some cases, you might have both a router-id and a loopback address set. The rule is that OSPF will use the router-id command first, if one exists. If there is no router-id command, then it uses the highest IP address on any of the loopback interfaces. Bear in mind that you can configure as many loopback interfaces as you like (although this is somewhat unusual in production networks, there are special situations where additional loopback interfaces can be useful). Finally, if there is no router-id command and no loopback interface, the OSPF process will use the highest IP address on the router for the RID.

You can see what the RID for your router is with the following command:

Router5#show ip ospf
 Routing Process "ospf 87" with ID 172.25.1.7
 Supports only single TOS(TOS0) routes
 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
 Number of external LSA 5. Checksum Sum 0x28868
 Number of DCbitless external LSA 0
 Number of DoNotAge external LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
    Area BACKBONE(0)
        Number of interfaces in this area is 2
        Area has no authentication
        SPF algorithm executed 47 times
        Area ranges are
        Number of LSA 36. Checksum Sum 0xEEAA1
        Number of DCbitless LSA 9
        Number of indication LSA 0
        Number of DoNotAge LSA 0
Router5#

The router will continue to use the same RID address, even if you subsequently add a router-id command or a loopback interface. To force OSPF to update the RID, you can either reload the router or restart the OSPF process using the clear ip ospf process command:

Router5#clear ip ospf process
Reset ALL OSPF processes? [no]: yes
Router5#

Recipe 8.7; Recipe 8.16

You want to authenticate your OSPF neighbor relationships to ensure that no unauthorized equipment is allowed to affect routing.

To enable OSPF MD5 authentication, you need to define the encryption key, which is essentially just a password on an interface. You must also enable authentication for the entire area. For the first router, you could do this as follows:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/1
Router1(config-if)#ip ospf message-digest-key 1 md5 oreilly
Router1(config-if)#exit
Router1(config)#router ospf 55
Router1(config-router)#area 2 authentication message-digest
Router1(config-router)#end
Router1#

Similarly, you must enable OSPF authentication on other routers in the area, making sure that the authentication keys match on all interfaces that share the same network segment:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf message-digest-key 1 md5 oreilly
Router2(config-if)#exit
Router2(config)#router ospf 12
Router2(config-router)#area 2 authentication message-digest
Router2(config-router)#end
Router2#

RFC 2328, which defines OSPF Version 2, includes three different types of authentication for OSPF: null authentication, simple password authentication, and cryptographic authentication. Null authentication simply means that there is no authentication, which is the default on Cisco routers. In the simple password method of authentication, passwords are exchanged in clear-text on the network. Even the RFC that specifies this method points out that it is easily compromised. Anybody who wants to deliberately corrupt your routing tables needs to have direct access to your network to do so anyway. Having that access means that it is relatively easy to capture these passwords. We recommend that you use the cryptographic authentication method if you require authentication with OSPF.

The cryptographic method uses the open standard Message Digest Type 5 (MD5) encryption standard. MD5 is a one-way irreversible cipher. Two devices exchange only the MD5 encrypted versions of the password. Both devices know the same password, and each router is able to verify that the encrypted password that it receives is correct by using the same algorithm to encrypt the password that it already knows. To make sure that nobody can just intercept and use the encrypted version of the password directly, a time value that the receiving router also knows is added to the password before encrypting. Anybody else listening on the network is only able to see the encrypted version of the password, but they cannot deduce the original password.

Unfortunately, the RFC is not completely clear on how this time value should be added to the original pass phrase, nor does it mandate MD5 encryption. So there is a good chance that cryptographic authentication will not work well between routers from different vendors.

If you use authentication in an OSPF area, you must configure all of the routers in the area to support authentication. Every interface on a router doesn’t have to be configured with authentication. But if you require authentication in any part of an area, you must include authentication support throughout the area. In the above example, this is done for Area 2 with the following command:

Router2(config-router)#area 2 authentication message-digest

The show ip ospf interface command shows that we have configured authentication on this interface:

Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 2
  Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 172.25.25.1
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 1
Router2#

Note that we are using “Message digest authentication,” (meaning MD5) and that key number 1 is currently active.

You can use a different key on each of a router’s interfaces, or a single password throughout the entire network. All that matters is that all of the routers on a single network segment use the same OSPF key for the interfaces that share this segment. The problem with using too many different keys is that it can become rather difficult to manage.

You can also configure several keys on a single interface. We recommend using this as a transition method while changing keys, and the old keys should be removed quickly to prevent anybody from gaining access using an old key:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf message-digest-key 1 md5 oreilly
Router2(config-if)#ip ospf message-digest-key 2 md5 cookbook
Router2(config-if)#end
Router2#

In this case we have defined two keys, which have key numbers 1 and 2, respectively:

Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 2
  Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:03
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 172.25.25.1
  Suppress hello for 0 neighbor(s)
  Message digest authentication enabled
    Youngest key id is 2
    Rollover in progress, 1 neighbor(s) using the old key(s):
      key id 1
Router2#

This display indicates that key number 2 is the newest, and that one neighbor is still using the old key. This command is useful when you want to see if it is safe to remove the old key yet.

Looking at the router’s configuration file, you can see that these keys are stored in plain-text by default:

interface Serial0/0
 ip address 10.1.1.1 255.255.255.252
 ip ospf message-digest-key 1 md5 oreilly
 ip ospf message-digest-key 2 md5 cookbook

If you define the password encryption service on the router, it will store these keys using the weak Cisco type 7 encryption method:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#service password-encryption
Router2(config)#end

As we discussed in Chapter 2, this causes the router to store passwords in an encrypted form when you view the configuration file. However, this encryption method can easily be broken if somebody gains access to the router. It is still useful, though, to prevent somebody from getting the passwords by looking over your shoulder.

If you want to use authentication, but the neighboring devices don’t support MD5, use clear-text authentication:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/1
Router1(config-if)#ip ospf authentication-key oreilly
Router1(config-if)#exit
Router1(config)#router ospf 55
Router1(config-router)#area 2 authentication
Router1(config-router)#end
Router1#

As with MD5 authentication, if you configure clear-text authentication on an interface, you must configure the same authentication method and the same key on all other routers that share this segment:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf authentication-key oreilly
Router2(config-if)#exit
Router2(config)#router ospf 12
Router2(config-router)#area 2 authentication
Router2(config-router)#end
Router2#

The output of the show ip ospf interface command now indicates the alternative authentication method:

Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 2
  Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:07
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 172.25.25.1
  Suppress hello for 0 neighbor(s)
  Simple password authentication enabled
Router2#

Chapter 2

You want to limit the number of routes and entries in the Link State database to conserve router resources and ensure good convergence properties.

In the introduction to this chapter, we talked about the various types of OSPF areas. You can configure these different types areas using the appropriate keywords on the area command.

For a stubby area, use the stub keyword:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#area 100 stub
Router1(config-router)#end
Router1#

To configure a totally stubby area, combine the stub and no-summary keywords on the ABR router:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#area 100 stub no-summary
Router1(config-router)#end
Router1#

The other routers in a totally stubby area need only be configured using the stub keyword, as in the previous example.

For not so stubby areas (NSSA), you need to specify the nssa keyword. In this case we have also included the default-information-originate option so that the router can summarize external routes to a single default route:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#area 100 nssa default-information-originate
Router1(config-router)#end
Router1#

In the introduction, we also discussed an interesting variant called the totally stubby not so stubby area. You can configure this as follows on the ABR:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#area 100 nssa no-summary
Router1(config-router)#end
Router1#

Once again, you can simply configure the other routers in this area with the nssa keyword.

In all of the configuration examples, we showed the configuration for just one router. It is important to remember that the routers in an area have to agree on the area type. However, it is mostly the ABR that cares about the area type, because it has to decide what kinds of information to forward from other parts of the network. Every router in a stub area must be configured as stub, although only the ABR needs to worry about the difference between stub and totally stub. Every router in an NSSA area must be configured to support NSSA Type 7 LSA messages. But, once again, only the ABR cares about the difference between NSSA and totally stub NSSA.

Figure 8-1 shows the network diagram for all of these examples. Note that the diagram includes detailed information for everything inside of Area 100, but only summary information for everything in other areas and other networks. This is how OSPF views the world.

If you have any ASBR devices in this area that inject routes from other Autonomous Systems, then they also need to use the area type information. The other routers are only really concerned with forwarding the LSAs around the area.

When you look at the routing table, you can see that there are several kinds of routes:

Router3#sh ip route ospf
O E1 192.168.10.0/24 [110/3611] via 172.20.1.1, 00:00:20, Serial0.1
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.2.0 [110/3581] via 172.20.1.1, 00:00:20, Serial0.1
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:00:20, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:00:20, Ethernet0
     172.22.0.0/24 is subnetted, 1 subnets
O IA    172.22.1.0 [110/3581] via 172.20.1.1, 00:00:20, Serial0.1
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA    172.25.25.6/32 [110/3582] via 172.20.1.1, 00:00:20, Serial0.1
O IA    172.25.25.1/32 [110/3572] via 172.20.1.1, 00:00:20, Serial0.1
O IA    172.25.1.0/24 [110/3581] via 172.20.1.1, 00:00:20, Serial0.1
     172.24.0.0/24 is subnetted, 1 subnets
O E1    172.24.1.0 [110/3611] via 172.20.1.1, 00:00:20, Serial0.1
     10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
O IA    10.2.2.2/32 [110/5134] via 172.20.1.1, 00:00:20, Serial0.1
O E1    10.2.2.0/30 [110/3606] via 172.20.1.1, 00:00:20, Serial0.1
O IA    10.1.1.0/30 [110/5133] via 172.20.1.1, 00:00:20, Serial0.1
O E1    10.100.1.0/24 [110/3611] via 172.20.1.1, 00:00:20, Serial0.1
O E2 192.168.50.0/24 [110/20] via 172.20.1.1, 00:00:20, Serial0.1
Router3#

Figure 8-1. Example network for area type examples

This output shows only routes that were learned via OSPF, which is indicated by the O at the start of each line. In this routing table there are several external routes. Most of these are Type 1 externals, which are labeled E1. There is also one Type 2 external route, which is labeled E2 in the output. Some of the other routes have IA beside them, which indicates that they are inter-area routes, meaning that they did not originate in this area. The remaining routes, such as 172.20.220.1/32, represent networks in this area.

This routing table shows no summarization. It’s also useful to look at the OSPF database on this router to see how different routes are categorized:

Router3#show ip ospf database

            OSPF Router with ID (172.25.25.2) (Process ID 44)

                Router Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.20.220.1    172.20.220.1    47          0x80000004 0xB352   3
172.25.25.1     172.25.25.1     89          0x80000067 0xE771   2
172.25.25.2     172.25.25.2     47          0x80000065 0x4C66   4

                Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.20.10.1     172.25.25.2     42          0x80000002 0xF11B

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.1.0        172.25.25.1     173         0x80000002 0x86AC
10.2.2.2        172.25.25.1     173         0x80000002 0x77B3
172.16.2.0      172.25.25.1     173         0x80000002 0xBFD3
172.22.1.0      172.25.25.1     173         0x80000002 0x820C
172.25.1.0      172.25.25.1     173         0x80000002 0x5E2D
172.25.25.1     172.25.25.1     173         0x80000002 0xF08A
172.25.25.6     172.25.25.1     173         0x80000002 0x2349

                Summary ASB Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.25.1.7      172.25.25.1     173         0x80000001 0xC78
172.25.25.1     172.25.25.1     173         0x80000001 0xBCDF

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.2.2.0        172.25.25.1     1138        0x8000000A 0x9588   0
10.100.1.0      172.25.25.1     1138        0x80000009 0x4A6B   0
172.24.1.0      172.25.25.1     1138        0x80000009 0x9BC3   0
192.168.10.0    172.25.25.1     1138        0x80000009 0x6C45   0
192.168.50.0    172.25.1.7      428         0x80000002 0xFF36   0
Router3#

This represents a relatively small OSPF network, but it’s a useful example because there are some instances of each type of route.

When we configure this area to be a stubby area, the ABR prevents external routes from being propagated into the area and replaces them with a default route. ASBRs are not permitted in stubby areas:

Router3#show ip route ospf
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.2.0 [110/3581] via 172.20.1.1, 00:00:07, Serial0.1
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:00:20, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:00:20, Ethernet0
     172.22.0.0/24 is subnetted, 1 subnets
O IA    172.22.1.0 [110/3581] via 172.20.1.1, 00:00:07, Serial0.1
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA    172.25.25.6/32 [110/3582] via 172.20.1.1, 00:00:07, Serial0.1
O IA    172.25.25.1/32 [110/3572] via 172.20.1.1, 00:00:07, Serial0.1
O IA    172.25.1.0/24 [110/3581] via 172.20.1.1, 00:00:07, Serial0.1
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    10.2.2.2/32 [110/5134] via 172.20.1.1, 00:00:07, Serial0.1
O IA    10.1.1.0/30 [110/5133] via 172.20.1.1, 00:00:07, Serial0.1
O*IA 0.0.0.0/0 [110/3572] via 172.20.1.1, 00:00:07, Serial0.1
Router3#

As you can see, all of the external routes are gone, but the inter-area routes remain. Looking at the OSPF database, you can see that there is considerably less information for the router to keep track of:

Router3#show ip ospf database

            OSPF Router with ID (172.25.25.2) (Process ID 44)

                Router Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.20.220.1    172.20.220.1    22          0x80000006 0xCD38   3
172.25.25.1     172.25.25.1     86          0x80000069 0xFB5F   2
172.25.25.2     172.25.25.2     22          0x80000068 0x644D   4

                Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.20.10.1     172.25.25.2     17          0x80000003 0xEFF

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         172.25.25.1     92          0x80000001 0x213D
10.1.1.0        172.25.25.1     92          0x80000003 0xA291
10.2.2.2        172.25.25.1     92          0x80000003 0x9398
172.16.2.0      172.25.25.1     92          0x80000003 0xDBB8
172.22.1.0      172.25.25.1     92          0x80000003 0x9EF0
172.25.1.0      172.25.25.1     92          0x80000003 0x7A12
172.25.25.1     172.25.25.1     92          0x80000003 0xD6F
172.25.25.6     172.25.25.1     92          0x80000003 0x3F2E
Router3#

Totally stubby areas, like ordinary stub areas, also prevent external routes. But the ABRs for totally stubby areas also prevent inter-area routes from being propagated into the area, replacing them with a single default route instead. The default route is the only summary route allowed. ASBRs are not permitted in stubby or totally stubby areas:

Router3#show ip route ospf
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:00:15, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:00:15, Ethernet0
O*IA 0.0.0.0/0 [110/3572] via 172.20.1.1, 00:00:15, Serial0.1
Router3#

Clearly, the totally stubby area has radically reduced the size of the routing table, as well as the OSPF database:

Router3#show ip ospf database

            OSPF Router with ID (172.25.25.2) (Process ID 44)

                Router Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.20.220.1    172.20.220.1    104         0x80000006 0xCD38   3
172.25.25.1     172.25.25.1     22          0x8000006B 0xF761   2
172.25.25.2     172.25.25.2     104         0x80000068 0x644D   4

                Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.20.10.1     172.25.25.2     99          0x80000003 0xEFF

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         172.25.25.1     23          0x80000002 0x1F3E
Router3#

There are two main differences between stubby and NSSA areas. The first is that the NSSA prevents the ABR from propagating external routes throughout the area, but does not replace them with a single default route. The second is that the NSSA may contain ASBRs, which use Type 7 LSAs to carry information about external routes. These Type 7 LSAs are flooded throughout the NSSA area. When they reach the ABR, they are translated into Type 5 LSAs and forwarded to the rest of the OSPF network:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#ip route 192.168.88.0 255.255.255.0 172.20.10.2
Router3(config)#router ospf 44
Router3(config-router)#redistribute static subnet
Router3(config-router)#area 100 nssa default-information-originate
Router3(config-router)#end
Router3#

With the default-information-originate option, the ABR will forward a default route to summarize all external routes that originate outside of the area:

Router3#show ip route ospf
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.2.0 [110/3581] via 172.20.1.1, 00:07:43, Serial0.1
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:07:43, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:07:43, Ethernet0
     172.22.0.0/24 is subnetted, 1 subnets
O IA    172.22.1.0 [110/3581] via 172.20.1.1, 00:07:43, Serial0.1
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA    172.25.25.6/32 [110/3582] via 172.20.1.1, 00:07:43, Serial0.1
O IA    172.25.25.1/32 [110/3572] via 172.20.1.1, 00:07:43, Serial0.1
O IA    172.25.1.0/24 [110/3581] via 172.20.1.1, 00:07:43, Serial0.1
     10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O IA    10.2.2.2/32 [110/5134] via 172.20.1.1, 00:07:43, Serial0.1
O IA    10.1.1.0/30 [110/5133] via 172.20.1.1, 00:07:43, Serial0.1
O*N2 0.0.0.0/0 [110/1] via 172.20.1.1, 00:07:43, Serial0.1
Router3#

The OSPF database for an NSSA area includes information about Type 7 LSAs:

Router3#show ip ospf database

            OSPF Router with ID (172.25.25.2) (Process ID 44)

                Router Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.20.220.1    172.20.220.1    973         0x80000008 0x51AA   3
172.25.25.1     172.25.25.1     502         0x80000072 0x77D0   2
172.25.25.2     172.25.25.2     968         0x8000006E 0xE5BB   4

                Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.20.10.1     172.25.25.2     967         0x80000004 0x9371

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
10.1.1.0        172.25.25.1     1124        0x80000003 0x2A02
10.2.2.2        172.25.25.1     1124        0x80000003 0x1B09
172.16.2.0      172.25.25.1     1124        0x80000003 0x6329
172.22.1.0      172.25.25.1     1124        0x80000003 0x2661
172.25.1.0      172.25.25.1     1124        0x80000003 0x282
172.25.25.1     172.25.25.1     1124        0x80000003 0x94DF
172.25.25.6     172.25.25.1     1124        0x80000003 0xC69E

                Type-7 AS External Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         172.25.25.1     508         0x80000001 0xF31B   0
10.2.2.0        172.25.25.1     1123        0x80000001 0x2FE7   0
10.100.1.0      172.25.25.1     1123        0x80000001 0xE90B   0
172.24.1.0      172.25.25.1     1123        0x80000001 0x3B63   0
192.168.10.0    172.25.25.1     1123        0x80000001 0xCE4    0
192.168.88.0    172.25.25.2     974         0x80000001 0x3AEC   0
Router3#

It is also interesting to look at the routing table entry for one of these Type 7 routes on another router within the same area:

Router1#show ip route 192.168.88.0
Routing entry for 192.168.88.0/24
  Known via "ospf 55", metric 20, type NSSA extern 2, forward metric 1572
  Last update from 172.20.1.2 on Serial0/0.2, 00:08:56 ago
  Routing Descriptor Blocks:
  * 172.20.1.2, from 172.25.25.2, 00:08:56 ago, via Serial0/0.2
      Route metric is 20, traffic share count is 1
Router1#

The aptly named totally stubby not so stubby area is similar to an NSSA area, but it also acts like a totally stubby area by preventing the ABR from advertising inter-area routes and replaces them with a single summary route, the default route. The ABR for a totally stubby NSSA will create a default route by default:

Router3#show ip route ospf
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:00:47, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:00:47, Ethernet0
O*IA 0.0.0.0/0 [110/3572] via 172.20.1.1, 00:00:47, Serial0.1
Router3#

Despite the confusing name, this is an extremely useful type of area. In many large OSPF networks, most of the routes in the routing table are inter-area routes. But you can also put an ASBR in this type of area and use it as a transit area to connect to external networks:

Router3#show ip ospf database

            OSPF Router with ID (172.25.25.2) (Process ID 44)

                Router Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.20.220.1    172.20.220.1    1209        0x80000008 0x51AA   3
172.25.25.1     172.25.25.1     91          0x80000074 0x73D2   2
172.25.25.2     172.25.25.2     1204        0x8000006E 0xE5BB   4

                Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
172.20.10.1     172.25.25.2     1203        0x80000004 0x9371

                Summary Net Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum
0.0.0.0         172.25.25.1     92          0x80000001 0xA8AD

                Type-7 AS External Link States (Area 100)

Link ID         ADV Router      Age         Seq#       Checksum Tag
10.2.2.0        172.25.25.1     88          0x80000002 0x2DE8   0
10.100.1.0      172.25.25.1     82          0x80000003 0xE50D   0
172.24.1.0      172.25.25.1     88          0x80000002 0x3964   0
192.168.10.0    172.25.25.1     88          0x80000002 0xAE5    0
192.168.88.0    172.25.25.2     86          0x80000002 0x38ED   0
Router3#

Like an NSSA area, the ABR translates Type 7 to Type 5 LSAs:

Router1#show ip ospf
 Routing Process "ospf 55" with ID 172.25.25.1
  <lines removed for brevity>
    Area 100
        Number of interfaces in this area is 1
        It is a NSSA area
        Perform type-7/type-5 LSA translation
        Area has no authentication
        SPF algorithm executed 75 times
        Area ranges are
        Number of LSA 13. Checksum Sum 0x6B01B
        Number of opaque link LSA 0. Checksum Sum 0x0
        Number of DCbitless LSA 0
        Number of indication LSA 0
        Number of DoNotAge LSA 0
        Flood list length 0
Router1#

IP Routing, by Ravi Malhotra(O’Reilly)

You want to reduce the size of your routing tables without losing any connectivity within your network.

Using the area x range configuration command on your ABRs allows you to summarize routes between OSPF areas.

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#area 100 range 172.20.0.0 255.255.0.0
Router1(config-router)#area 0 range 172.25.0.0 255.255.0.0
Router1(config-router)#area 2 range 10.0.0.0 255.0.0.0
Router1(config-router)#end
Router1#

The easiest way to see the effect of summarization is to look at the routing table before and after it is enabled. Here is a sample routing table before summarization. The ranges that we will be summarizing are 172.20.0.0/16 and 172.25.0.0/16. We have highlighted the lowest metric in each of these ranges:

Router2#show ip route ospf
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.2.0 [110/140] via 10.1.1.2, 00:05:06, Serial0/0
     172.20.0.0/16 is variably subnetted, 3 subnets, 3 masks
O IA    172.20.10.0/24 [110/1702] via 10.1.1.2, 00:05:06, Serial0/0
O IA    172.20.1.0/30 [110/1692] via 10.1.1.2, 00:05:06, Serial0/0
O IA    172.20.100.1/32 [110/1693] via 10.1.1.2, 00:05:06, Serial0/0
     172.25.0.0/16 is variably subnetted, 3 subnets, 2 masks
O IA    172.25.25.6/32 [110/141] via 10.1.1.2, 00:05:06, Serial0/0
O IA    172.25.25.1/32 [110/131] via 10.1.1.2, 00:05:06, Serial0/0
O IA    172.25.1.0/24 [110/140] via 10.1.1.2, 00:00:25, Serial0/0
Router2#

After enabling summarization, you can see that all of the individual routes in each of these ranges has been replaced with a single route for the entire range. Also note that the cost for the summary is equal to the lowest cost of the individual routes that this summary replaces. This is an extremely important point because it means that a summary route will be only as stable as the lowest cost route being replaced. The summary could replace a hundred routes that are all rock stable, but if the one with the lowest cost happens to bounce up and down frequently, the cost of the summary will have to fluctuate with it. This also means that it will have to be repeatedly distributed throughout the area, wasting bandwidth and using extra CPU cycles on all of the routers. Conversely, if the lowest cost route is stable, the summary will be completely stable as well—even if all of the other summarized routes are unstable.

Router2#show ip route ospf
     172.16.0.0/24 is subnetted, 1 subnets
O IA    172.16.2.0 [110/140] via 10.1.1.2, 00:09:28, Serial0/0
O IA 172.20.0.0/16 [110/1692] via 10.1.1.2, 00:00:42, Serial0/0
O IA 172.25.0.0/16 [110/131] via 10.1.1.2, 00:00:25, Serial0/0
Router2#

In fact, the situation we just described, in which the ABR adopts the lowest summarized cost for the summary route, is not the RFC standard method. This method was the standard in RFC 1583. But, when OSPF was updated in RFC 2178 (and subsequently updated again in RFC 2328), the rule changed. In these newer versions of the OSPF standard, the rule is that the summary route should have the same cost as the highest-cost summarized route.

Naturally, there is the potential for serious problems in OSPF networks if some routers use the RFC 1583 rule and others use the newer rule. So, when the new standard came out, Cisco kept the old rule as the default, but included a command to allow you to easily change to the new standard:

Router1(config)#router ospf 55
Router1(config-router)#no compatible rfc1583

This command is available in IOS level 12.0 and higher. We recommend using caution when migrating a network from the old system of summarization to the new one. It is relatively common in OSPF networks to have several ABR routers to connect an area to Area 0. If you changed one of these ABRs to use the new summarization method, it would automatically have a worse metric than any of the other ABRs. All of the routers in the area would stop using the summary route pointing to this new style ABR in favor of the routes distributed by the remaining RFC 1583 ABRs. This has the potential to be extremely disruptive to a network, so you have to migrate all of the ABRs for an area at the same time.

The issue we discussed earlier about the stability of the individual route with the best metric now switches to concern about the stability of the route with the worst metric.

It’s interesting to look at these summary routes on the ABR, which is responsible for doing all of the summarization. The ABR also includes the summary routes, but they aren’t real routes, so it simply points them to its Null0 interface. Cisco calls these discard routes. They help to prevent routing loops during summarization:

Router1#show ip route ospf
     172.20.0.0/16 is variably subnetted, 4 subnets, 4 masks
O       172.20.10.0/24 [110/1572] via 172.20.1.2, 00:07:42, Serial0/0.2
O       172.20.0.0/16 is a summary, 00:07:42, Null0
O       172.20.100.1/32 [110/1563] via 172.20.1.2, 00:07:42, Serial0/0.2
     172.25.0.0/16 is variably subnetted, 4 subnets, 3 masks
O       172.25.25.6/32 [110/11] via 172.25.1.7, 00:07:42, FastEthernet0/0.1
O       172.25.0.0/16 is a summary, 00:07:42, Null0
     10.0.0.0/8 is variably subnetted, 5 subnets, 4 masks
O       10.2.2.2/32 [110/1563] via 10.1.1.1, 00:07:42, Serial0/1
O       10.0.0.0/8 is a summary, 00:07:42, Null0
Router1#

Before IOS level 12.1(6), the only way to generate a discard route was to manually create a static route:

Router1(config)#ip route 172.20.0.0 255.255.0.0 null0

However, in IOS levels 12.1(6) and higher, this discard route is generated by default, and you don’t need to create it. If you want to disable creation of the discard route, use the no discard-route command:

Router1(config)#router ospf 55
Router1(config-router)#no discard-route internal
Router1(config-router)#no discard-route external

With the internal keyword, this command prevents the router from automatically generating discard routes for internal summary routes. Similarly, the external keyword is for external routes. However, we urge caution with this command because the absence of a discard route can cause loops.

RFC 1583, RFC 2328

You want to prevent some of a router’s interfaces from taking part in OSPF.

The passive-interface configuration command effectively disables OSPF on an interface by preventing it from forming OSPF adjacencies:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#router ospf 44
Router3(config-router)#network 0.0.0.0 255.255.255.255 area 100
Router3(config-router)#passive-interface Ethernet0
Router3(config-router)#end
Router3#

OSPF will not start to exchange any routing information until two routers on a segment have authenticated (if authentication is enabled) and agreed on the various area parameters. So simply preventing one router from taking part in this handshake is sufficient to prevent the exchange of OSPF information on the interface. Also, while you can use a passive-interface command as shown in the example, you can also prevent an interface from taking part in OSPF by just using more restrictive network commands. In the example, the network statement includes everything. But you could just as easily use a network statement that restricts OSPF to a list of specific interfaces as follows:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#router ospf 44
Router3(config-router)#network 172.20.1.2 0.0.0.0 area 100
Router3(config-router)#network 172.20.10.1 0.0.0.0 area 100
Router3(config-router)#end
Router3#

Any interfaces that aren’t explicitly included by a network statement will not take part in OSPF. On the other hand, sometimes a router can have a large number of interfaces, and you want all but one or two of them to take part in OSPF. In this case, it is more convenient to use passive interface commands.

To see the effect of this command, we’ll look at a network both with and without the passive interface configured. Here is the neighbor list before configuring any passive interfaces:

Router3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.20.220.1      1   FULL/BDR        00:00:39    172.20.10.2     Ethernet0
172.25.25.1       1   FULL/  -        00:00:37    172.20.1.1      Serial0.1
Router3#

Then, after making the Ethernet0 interface passive, the router drops all of the neighbor relationships on this interface. We are left with only one neighbor:

Router3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.25.25.1       1   FULL/  -        00:00:38    172.20.1.1      Serial0.1
Router3#

Of course, this also affects any routes that point to neighboring routers through this interface. This is the routing table before configuring Ethernet0 as passive:

Router3#show ip route ospf
     172.20.0.0/16 is variably subnetted, 5 subnets, 3 masks
O       172.20.220.1/32 [110/11] via 172.20.10.2, 00:00:02, Ethernet0
O       172.20.200.1/32 [110/11] via 172.20.10.2, 00:00:02, Ethernet0
O*IA 0.0.0.0/0 [110/3572] via 172.20.1.1, 00:00:02, Serial0.1
Router3#

With the passive interface configured, all of the corresponding routes are also gone:

Router3#show ip route ospf
O*IA 0.0.0.0/0 [110/3572] via 172.20.1.1, 00:01:53, Serial0.1
Router3#

You want to tag specific routes to prevent routing loops during mutual redistributing between routing protocols.

You can tag external routes in OSPF by using the redistribute command with the tag keyword:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router ospf 55
Router1(config-router)#redistribute eigrp 11 metric-type 1 subnets tag 67
Router1(config-router)#end
Router1#

Route tagging in OSPF is similar to route tagging in RIP Version 2 and EIGRP, which we discussed in Chapters Chapter 6 and Chapter 7. Just like those protocols, OSPF doesn’t directly use the route tags. But they are useful when distributing routes into foreign routing protocols.

In the example configuration, Router1 is an ASBR that connects to a network that uses EIGRP process number 11. We have configured this router so that it redistributes these EIGRP routes into OSPF as external Type 1 routes with a tag value of 67:

Router5#show ip route 10.2.2.0
Routing entry for 10.2.2.0/30
  Known via "ospf 87", distance 110, metric 45
  Tag 67, type extern 1
  Redistributing via ospf 87
  Last update from 172.25.1.5 on Ethernet0, 00:07:14 ago
  Routing Descriptor Blocks:
  * 172.25.1.5, from 172.25.25.1, 00:07:14 ago, via Ethernet0
      Route metric is 45, traffic share count is 1
Router5#

The tags become useful when you redistribute the tagged routes into another network. For example, the following configuration shows how we might redistribute this group of external routes into RIP, but no internal OSPF routes. This sort of configuration is useful if you want to allow the RIP and EIGRP external networks to talk to one another through your OSPF network, but prevent them from seeing your own routing tables:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#router rip
Router1(config-router)#version 2
Router1(config-router)#redistribute ospf 87 route-map TAGGEDROUTES
Router1(config-router)#exit
Router1(config)#route-map TAGGEDROUTES permit 10
Router1(config-route-map)#match tag 67
Router1(config-route-map)#exit
Router1(config)#route-map TAGGEDROUTES deny 20
Router1(config-route-map)#end
Router1#

Chapter 6; Chapter 7

You want to monitor OSPF adjacency state changes to ensure network stability.

The log-adjacency-changes configuration command instructs the router to create a log message whenever two OSPF routers establish or break their adjacency relationship:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router ospf 12
Router2(config-router)#log-adjacency-changes
Router2(config-router)#end
Router2#

No routes are exchanged between routers if they lose their adjacency relationship. Every time this relationship is lost, the corresponding routes are removed and every router in the area must be updated with the new network topology. So it can be extremely useful to log these changes for troubleshooting, as well as for reconstructing serious problems that occurred in the past. We recommend using this option.

Here are some example log messages. The first message shows that the adjacency has been lost due to an expired timer. This means that this router has not heard its neighbor’s regularly scheduled “hello” messages recently, so it needs to delete its routes. A few minutes later, the neighbor has come back and reestablished its adjacency:

Oct 14 09:54:13: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from FULL
to DOWN, Neighbor Down: Dead timer expired
Oct 14 09:57:43: %OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 on Serial0/0 from
LOADING to FULL, Loading Done

Starting in 12.1, Cisco added the keyword detail:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#router ospf 12
Router2(config-router)#log-adjacency-changes detail
Router2(config-router)#end
Router2#

When you enable the detailed logging, you get considerably more information. It now shows all of the various stages that OSPF neighbors need to go through to establish their adjacencies:

%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from FULL to DOWN, Neighbor Down: Dead
timer expired
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from DOWN to INIT, Received Hello
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from INIT to 2WAY, 2-Way Received
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from 2WAY to EXSTART, AdjOK?
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXSTART to EXCHANGE, Negotiation
Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from EXCHANGE to LOADING, Exchange Done
%OSPF-5-ADJCHG: Process 12, Nbr 172.25.25.1 from LOADING to FULL, Loading Done

This level of detail is rarely required unless you suspect that there is a problem with the handshake process between two routers. In that case it might be more effective to use debugging (as discussed in Recipe 8.17). We wouldn’t normally recommend using the detail option in production networks because it just fills up the logs with extra messages.

Recipe 8.17

You want to change the default OSPF timers to improve stability or convergence behavior.

You can improve the convergence time of OSPF on a particular interface by reducing the hello and dead timers:

Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#interface Serial0/1
Router1(config-if)#ip ospf hello-interval 5
Router1(config-if)#ip ospf dead-interval 20
Router1(config-if)#end
Router1#

If you make this change on one router, you must make it on all of the other routers sharing the same network segment:

Router2#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router2(config)#interface Serial0/0
Router2(config-if)#ip ospf hello-interval 5
Router2(config-if)#ip ospf dead-interval 20
Router2(config-if)#end
Router2#

OSPF uses two timers. The hello timer controls how often the router sends routine messages to its neighbors simply indicating that it is still up. If the neighbors don’t hear any hello messages for the length of time defined by the dead-interval, they will assume that the router is no longer reachable and drop it from the adjacency table.

The default values are 10 seconds for the hello time, and 40 seconds for the dead time. The usual rule of thumb with OSPF is to keep the dead time value four times the hello interval. However, this is not a strict rule. EIGRP, for example, uses a dead time that is only three times its hello interval. So, if you wanted OSPF to have convergence times that more closely matched those of EIGRP, you could set the OSPF hello time to 5 seconds, and the dead interval to 15 seconds. Bear in mind that shortening the hello timer will increase the amount of traffic on the link. And shortening the dead interval increases the chances of losing adjacency because of network congestion or link errors.

It is important to adjust the timers on all of the routers on the network segment together. Unlike EIGRP, which allows every router to use a different set of timers, in OSPF the routers cannot establish adjacencies if their timers do not match exactly. But you can adjust the timers separately on different interfaces on a router. So you can use slower timers on low-bandwidth links, and faster timers on faster links. In general we don’t recommend increasing the timers from their default values, but it can be useful to decrease them to improve convergence on important high-speed segments.

You can see the new timers with the show ip ospf interface command:

Router2#show ip ospf interface Serial0/0
Serial0/0 is up, line protocol is up
  Internet Address 10.1.1.1/30, Area 2
  Process ID 12, Router ID 192.168.30.1, Network Type POINT_TO_POINT, Cost: 130
  Transmit Delay is 1 sec, State POINT_TO_POINT,
  Timer intervals configured, Hello 5, Dead 20, Wait 20, Retransmit 5
    Hello due in 00:00:04
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 172.25.25.1
  Suppress hello for 0 neighbor(s)
  Simple password authentication enabled
Router2#

Looking at the neighbor table, you can see that the dead time reflects the change. Note that the time indicated in this output is the actual time remaining before OSPF declares this neighbor invalid. So, if everything is working properly, this value should count down from the configured dead time value until the hello interval expires. Then another hello packet will be sent and the dead timer will start over at its maximum value:

Router2#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.25.25.1       1   FULL/  -        00:00:19    10.1.1.2        Serial0/0
Router2#

Chapter 7

You would prefer to view proper domain names in your OSPF show commands rather than the raw IP addresses.

You can configure OSPF to resolve IP addresses into router names with the following global configuration command:

Router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router3(config)#ip ospf name-lookup
Router3(config)#end
Router3#

When you configure OSPF name lookup, the router will use its locally configured host table, if it has one, or DNS to resolve the names. If both are present, the router will check the local host table first. You can enable DNS on a router with the ip domain-lookup and ip name-server commands, as discussed in Chapter 2.

Enabling name resolution can be useful when displaying information such as OSPF neighbor tables. For example, if we look at the neighbor table without name lookup enabled, we see IP addresses:

Router3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.20.220.1      1   FULL/DR         00:00:34    172.20.10.2     Ethernet0
172.25.25.1       1   FULL/  -        00:00:31    172.20.1.1      Serial0.1
Router3#

But, when name lookup is enabled, the router replaces the router IDs with names:

Router3#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
Router6           1   FULL/DR         00:00:37    172.20.10.2     Ethernet0
Router1           1   FULL/  -        00:00:36    172.20.1.1      Serial0.1
Router3#

Recipe 8.8; Chapter 2

OSPF is not behaving properly and you want to debug it to isolate and solve the problem.

There are several OSPF debugging options. The most common symptoms of OSPF problems are instabilities in the neighbor relationships. So the most useful debugging option traces the formation of adjacencies:

Router3#debug ip ospf adj
OSPF adjacency events debugging is on
Router3#

This particular debug output is especially useful because it helps to diagnose problems when routers refuse to form adjacencies with one another. For example, the following debug message indicates that there is an authentication problem. The neighbor router in this case is configured for MD5 authentication, while this router is configured for no authentication:

Dec 21 16:00:14.341: OSPF: Rcv pkt from 172.25.1.7, FastEthernet0/0.1 : Mismatch
Authentication type. Input packet specified type 2, we use type 0