In this section, we are going to learn about the OSPF metric and how it is calculated. We will also learn about inter-area and intra-area routes and how OSPF routers select the best route to the destination network. And finally, this section will be concluded by looking at the ways in which metric calculation can be influenced and the effects of such configurations.
Calculating the OSPF Metric
The OSPF metric is commonly referred to as the cost. The cost is derived from the bandwidth of a link using the formula 108/bandwidth (in bps). This means that different links are assigned different cost values depending on their bandwidth. Using this formula, the OSPF cost of a 10Mbps Ethernet interface would be calculated as follows:
- Cost = 108/bandwidth (bps)
- Cost = 100 000 000/10 000 000
- Cost = 10
Using the same formula, the OSPF cost of a T1 link would be calculated as follows:
- Cost = 108/bandwidth (bps)
- Cost = 100 000 000/1 544 000
- Cost = 64.77
NOTE: When calculating the OSPF metric, point math is not used. Therefore, any such values are always rounded down to the nearest integer. Regarding the previous example, the actual cost for a T1 link would be rounded down to 64.
The OSPF cost of an interface can be viewed using the show ip ospf interface [name] command as was illustrated in the previous section. The default reference bandwidth used in metric calculation can be viewed in the output of the show ip protocols command as is illustrated in the following output:
| R4#show ip protocols Routing Protocol is “ospf 4” Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Router ID 4.4.4.4 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 0.0.0.0 255.255.255.255 area 2 Reference bandwidth unit is 100 mbps Routing Information Sources: Gateway Distance Last Update 3.3.3.3 110 00:00:03 Distance: (default is 110) |
The default reference bandwidth used in OSPF cost calculation can be adjusted using the auto-cost reference-bandwidth <1-4294967> router configuration command and specifying the reference bandwidth value in Mbps. This is particularly important in networks that have links that have a bandwidth value over 100Mbps; for example, GigabitEthernet links. In such networks, the default value assigned to the GigabitEthernet link would be the same as that of a FastEthernet link. In most cases, this is certainly not desirable, especially is OSPF attempts to load-balance across both links.
To prevent this skewed calculation of cost value, the auto-cost reference-bandwidth 1000router configuration command should be issued on the router. This results in a recalculation of cost values on the router using the new reference bandwidth value. For example, following this configuration, the cost of a T1 link would be recalculated as follows:
- Cost = 109/bandwidth (bps)
- Cost = 1 000 000 000/1 544 000
- Cost = 647.66
NOTE: Again, because the OSPF metric does not support point values, this would be rounded down to a metric value of simply 647 as illustrated in the following output:
| R4#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.0.2.4/24, Area 2 Process ID 4, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 647 Transmit Delay is 1 sec, State POINT_TO_POINT Timer intervals configured, Hello 10, Dead 60, Wait 60, Retransmit 5 oob-resync timeout 60 Hello due in 00:00:01 Supports Link-local Signaling (LLS) Index 2/2, 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 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) |
When the auto-cost reference-bandwidth 1000router configuration command is issued, Cisco IOS software prints the following message indicating that this same value should be applied to all routers within the OSPF domain:
| R4(config)#router ospf 4 R4(config-router)#auto-cost reference-bandwidth 1000 % OSPF: Reference bandwidth is changed. Please ensure reference bandwidth is consistent across all routers. |
While this may seem like an important warning, keep in mind that the use of this command simply affects the local router. It is not mandatory to configure it on all routers; however, for exam purposes, ensure that a consistent configuration is implemented on all routers.
Intra-Area Route Metric Calculation
Intra-area routes (Type 1 and Type 2 LSAs) are routes within a single OSPF area. In Cisco IOS software, these routes are preceded by an O in the output of the show ip route command. This is illustrated in the following output:
| R2#show ip route ospf 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/65] via 10.0.0.1, 02:34:40, Serial0/0 3.0.0.0/32 is subnetted, 1 subnets O 3.3.3.3 [110/2] via 10.0.1.3, 02:34:40, FastEthernet0/0 4.0.0.0/32 is subnetted, 1 subnets |
The metric for intra-area routes is calculated by adding the cumulative cost of all links from the router to the destination network or link. To better understand this concept, refer to the network topology illustrated in Figure 3-21:
Fig. 3-21. Calculating Intra-Area Route Metrics
Referencing Figure 3-21, R1, R2 and R3 are all backbone routers, and reside in area 0. R1 and R2 are connected via a T1 Serial link (default cost = 64) while R2 and R3 are connected via a FastEthernet link (default cost = 1). To calculate the cost of the intra-area route from R1 to the Loopback interface of R3 (default cost = 1), you would simply add up the cumulative cost values as follows:
- Route Metric = [cost of R1-R2 link + cost of R2-R3 link + cost of Loopback interface]
- Route Metric = [64 + 1 + 1]
- Route Metric = 66
If you did not know the cost of the Loopback interface, or any of the links between R1 and R3, you could derive this value using one of two methods:
- Using the show ip ospf interface [name] command
- Adding up the metric (cost) values in the LSAs
The show ip ospf interface [name] command includes the OSPF cost for a particular link or interface. Once derived, this would then be added to the cost values of all other transit links between the router and the destination network or link to derive the route metric. The following shows the output printed by this command for a Loopback interface:
| R3#show ip ospf interface loopback 0 Loopback0 is up, line protocol is up Internet Address 3.3.3.3/32, Area 0 Process ID 3, Router ID 3.3.3.3, Network Type LOOPBACK, Cost: 1 Loopback interface is treated as a stub Host |
The second method involves a little more work and requires a greater understanding of both the overall network topology and LSDB. While there is no single standard method of using this method, as an example, we could first look at the Type 1 LSAs advertised by R2. This will provide us with all links on this router, which includes the P2P connection between R1 and R2 and the LAN (transit) link between R2 and R3. Both are highlighted below:
| R1#show ip ospf database router adv-router 2.2.2.2OSPF Router with ID (1.1.1.1) (Process ID 1)Router Link States (Area 0)
LS age: 1209 Link connected to: another Router (point-to-point) Link connected to: a Stub Network Link connected to: a Stub Network Link connected to: a Transit Network |
Noting the metric value of 64 for the P2P link between R1 and R2, and the metric value of 1 for the LAN (transit) link between R2 and R3, next, we can use the same command to view the metric (cost) for the Loopback interface on R3 as follows:
| R1#show ip ospf database router 3.3.3.3OSPF Router with ID (1.1.1.1) (Process ID 1)Router Link States (Area 0)
Routing Bit Set on this LSA Link connected to: a Stub Network Link connected to: a Transit Network |
If we add up the metrics in the LSAs, we would get 64 + 1 + 1 = 66. This is just an alternate, and longer method, of arriving at the metric derived using the simple addition in the first method. However, the plus side with the second method is that the more you look at the LSDB, the more familiar you become with output and the information contained, as well as the different commands that you can use to look up different things. Regardless of the method used, the route metric calculated is printed in the output of the show ip route command as follows:
| R1#show ip route 3.3.3.3 255.255.255.255 Routing entry for 3.3.3.3/32 Known via “ospf 1”, distance 110, metric 66, type intra area Last update from 10.0.0.2 on Serial0/0, 00:08:15 ago Routing Descriptor Blocks: * 10.0.0.2, from 3.3.3.3, 00:08:15 ago, via Serial0/0 Route metric is 66, traffic share count is 1 |
Inter-Area Route Metric Calculation
Inter-area routes (Type 3 LSAs) are for routes outside of the local area but within the routing domain. Inter-area routes are preceded by an O IA in the output of the show ip route command as illustrated in the following output:
| R1#show ip route ospf O IA 4.4.4.4 [110/130] via 10.0.0.2, 00:18:56, Serial0/0 172.16.0.0/24 is subnetted, 2 subnets O IA 172.16.4.0 [110/130] via 10.0.0.2, 00:18:56, Serial0/0 144.144.0.0/32 is subnetted, 1 subnets O IA 144.144.144.4 [110/130] via 10.0.0.2, 00:18:56, Serial0/0 10.0.0.0/24 is subnetted, 3 subnets O IA 10.0.2.0 [110/129] via 10.0.0.2, 00:18:56, Serial0/0 |
The same basic calculation used in the first method in intra-area route metric calculation can be used to calculate the inter-area cost. However, because Type 3 LSAs provide only a summary of the information contained in other areas, routers cannot use this same basic method. Instead, routers calculate the cost of inter-area routes by adding the cost (metric) included in the Type 3 LSA to the cost of reaching the ABR that originated the LSA. The route metric included in the Type 3 LSA is the ABRs best (lowest) metric to the destination network or host.
Referencing the topology illustrated in Figure 3-21, R1 would calculate the route metric for the 4.4.4.4/32 route on R4 by adding the metric in the Type 3 LSA to the cost of reaching R3 (ABR) from R1. The metric in the Type 3 LSA can be viewed using the show ip ospf database summary adv-router 3.3.3.3 or show ip ospf database summary 4.4.4.4 commands on R1. The output printed by the latter of the two commands is illustrated below:
| R1#show ip ospf database summary 4.4.4.4OSPF Router with ID (1.1.1.1) (Process ID 1)Summary Net Link States (Area 0)
Routing Bit Set on this LSA |
In the output above, the LSA is originated by R3, which is listed as the Advertising Router. The metric of 65 is R3s metric to this address. This is derived simply by adding the cost of the connected link (default cost for the Loopback = 1) to the cost of the P2P connection between R3 and R4 (default cost for T1 Serial interface = 64): therefore, 64 + 1 = 65.
Using this information, R1 calculates the route to the same network by adding 65 to the cost of getting from itself to the ABR (R3). Using basic math, we can add the cost of the T1 Serial link between R1 and R2 to the cost of the FastEthernet link between R2 and R3 to 65 and calculate the metric for the 4.4.4.4/32 route on R1 as follows:
- Route Metric = [ABR cost + cost of reaching the ABR]
- Route Metric = [ABR cost + cost of R1-R2 link + cost of R2-R3 link]
- Route Metric = [65 + 64 + 1]
- Route Metric = 130
NOTE: The default cost of a FastEthernet link is 1, and is 64 for a T1 Serial link
We can validate our calculation by looking at the route metric for this route as printed in the output of the show ip route command on R1:
| R1#show ip route 4.4.4.4 255.255.255.255 Routing entry for 4.4.4.4/32 Known via “ospf 1”, distance 110, metric 130, type inter area Last update from 10.0.0.2 on Serial0/0, 00:08:42 ago Routing Descriptor Blocks: * 10.0.0.2, from 3.3.3.3, 00:08:42 ago, via Serial0/0 Route metric is 130, traffic share count is 1 |
The same logic would also be applicable to the calculation of the 172.16.1.0/24 network that is connected to the Ethernet0/0 interface of R1 from R4. First, R4 would look at the cost to this destination network as advertised by the ABR (R3):
| R4#show ip ospf database summary 172.16.1.0OSPF Router with ID (4.4.4.4) (Process ID 4)Summary Net Link States (Area 2)
Routing Bit Set on this LSA |
The metric included in the LSA is the ABRs (R3s) metric to this destination network. R4 would calculate its route metric to the same network by adding that metric to the cost of getting from R1 to R3. This calculation is performed as follows:
- Route Metric = [ABR cost + cost of reaching the ABR]
- Route Metric = [ABR cost + cost of R4-R3 link]
- Route Metric = [75 + 64]
- Route Metric = 139
Again, we can validate our calculation by looking at the route metric for this route as printed in the output of theshow ip route command on R4:
| R4#show ip route 172.16.1.0 255.255.255.0 Routing entry for 172.16.1.0/24 Known via “ospf 4”, distance 110, metric 139, type inter area Last update from 10.0.2.3 on Serial0/0, 00:16:52 ago Routing Descriptor Blocks: * 10.0.2.3, from 3.3.3.3, 00:16:52 ago, via Serial0/0 Route metric is 139, traffic share count is 1 |
Selecting the Best Routes
When determining the best route, the route with the best metric to the destination network will be selected. However, there is an important exception to this rule that it is important you remember. By default, ABRs will always select intra-area routes over inter-area routes regardless of the metric of the intra-area route. To better understand this concept, consider the network topology illustrated in Figure 3-22:
Fig. 3-22. Selecting the Best Route
Figure 3-22 shows a basic OSPF network with two ABRs. Both ABRs generate a Type 3 LSA for the 172.16.0.0/24 subnet in the backbone and flood it into area 1. R3 receives both LSAs and based on the route metric calculation, if both paths are equal, load balances across them both.
Invariably, R1 and R2 also receive the Type 3 LSAs advertised by the opposite ABR. In addition to not flooding inter-area routes into the backbone as was described earlier in this chapter, ABRs will not consider these routes in their own route calculation if they have an intra-area route to the same destination. This happens regardless of the metric of the inter-area route.
Influencing OSPF Metric Calculation
The calculation of the OSPF metric can be directly influenced by performing the following:
- Adjusting the interface bandwidth using the bandwidth command
- Manually specifying a cost using the ip ospf cost command
The use of the bandwidth command was described in the previous chapter when we discussed EIGRP metric calculation. As stated earlier, the default OSPF cost is calculated by dividing the link bandwidth by a reference bandwidth of 108 or 100 Mbps. Either incrementing or decrementing the link bandwidth directly affects the OSPF cost for the particular link. This is typically a path control mechanism used to ensure that one path is preferred over another.
However, as was described in the previous chapter, the bandwidth command affects more than just the routing protocol. It is for this reason that the second method, manually specifying a cost value is the recommended method for influencing OSPF metric calculation.
The ip ospf cost <1-65535> interface configuration command is used to manually specify the cost of a link. The lower the value, the greater the probability that the link will be preferred over other links to the same destination network but with higher cost values. The following example illustrates how to configure an OSPF cost of 5 for a Serial (T1) link:
| R1(config)#interface serial 0/0 R1(config-if)#ip ospf cost 5 R1(config-if)#exit |
This configuration can be validated using the show ip ospf interface [name] command as illustrated in the following output:
| R1#show ip ospf interface serial 0/0 Serial0/0 is up, line protocol is up Internet Address 10.0.0.1/24, Area 0 Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 5 Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:04 Index 2/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 4 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 2.2.2.2 Suppress hello for 0 neighbor(s) |
While manually adjusting the link cost using the ip ospf cost command is a straightforward process, it is very important to understand the underlying operations that are affected by this configuration change. This is described in the following section.
As you may recall, in chapter 1 we learned that the SPF algorithm creates a shortest-path tree to all hosts in an area or in the network backbone, with the router that is performing the calculation at the root of that tree. As the router goes through the SPF calculation, the node in the TENT set or list that is closest to the root is moved to the PATH or PATHS list or set. This process is repeated until all nodes are in the PATH set and the shortest-path tree is built. Once the tree has been completely built, routes are then derived from the tree.
The router calculates the cost to each node in the tree. This is performed by adding the cost to the PATH node and the cost from the PATH node to the TENT node. When the ip ospf cost command is issued, the change in the cost value requires that the router run the SPF algorithm again to determine the cost to all other nodes in that area.
The show ip ospf process [process ID] command can be used to view the number of times the SPF Algorithm has been run on a per-area basis as is illustrated below:
| R4#show ip ospf 4 Routing Process “ospf 4” with ID 4.4.4.4[Truncated Output]Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 Area 2 Number of interfaces in this area is 4 (2 loopback) Area has no authentication SPF algorithm last executed 00:05:40.838 ago SPF algorithm executed 7 times Area ranges are Number of LSA 8. Checksum Sum 0x089833 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 |
In the output above, the SPF algorithm has been run 7 times for area 1 and it was last run almost 6 minutes ago. If we changed the cost of a link in area 1 using the ip ospf cost interface configuration command, SPF would have to run again to recalculate the Type 1 and Type 2 LSAs because of the configuration change. As an example, the link cost for Serial0/0 is adjusted using the ip ospf cost interface configuration command as follows:
| R4(config)#interface serial 0/0 R4(config-if)#ip ospf cost 4 R4(config-if)#exit |
Based on this change, the output of the show ip ospf [process ID] command shows that the SPF algorithm has been run again in area 1:
| R4#show ip ospf 4 Routing Process “ospf 4” with ID 4.4.4.4[Truncated Output]Number of areas in this router is 1. 1 normal 0 stub 0 nssa Number of areas transit capable is 0 External flood list length 0 Area 2 Number of interfaces in this area is 4 (2 loopback) Area has no authentication SPF algorithm last executed 00:00:30.843 ago SPF algorithm executed 8 times Area ranges are Number of LSA 8. Checksum Sum 0x08F5D2 Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 |
In addition to running on the local router, the SPF algorithm also runs for all other routers in the same area. Depending on the size of the network, the router resource utilization and other conditions, this can have an adverse impact on the forwarding of traffic in production networks. Ensure that you understand the network topology and potential impact before implementing this configuration command on a network-wide basis.
The show ip ospf statistics [detail] command can be used to view SPF calculation statistics on the local router. When used without the [detail] keyword, the command prints a summary of SPF calculations and the events that triggered the calculations. The information printed by this command is shown in the following output:
| R4#show ip ospf statisticsOSPF Router with ID (4.4.4.4) (Process ID 4)Area 2: SPF algorithm executed 4 times
Summary OSPF SPF statistic SPF calculation time RIB manipulation time during SPF (in msec): |
While going into the detail of all fields included in the output above, the reason field lists the reason the SPF calculation was performed. The different values that may be found in this field are listed and described in Table 3-3 below:
| Reason Code | Description |
|---|---|
| R | A change in a Router LSA (Type 1) has occurred |
| N | A change in a Network LSA (Type 2) has occurred |
| SN | A change in a Summary Network LSA (Type 3) has occurred |
| SA | A change in a Summary ASBR LSA (Type 4) has occurred |
| X | A change in an External Type-7 (NSSA) LSA has occurred |
Tab. 3-3. SPF Calculation Reason Codes
In-depth information on SPF calculation can be viewed by appending the [detail] keyword to the end of the show ip ospf statistics command as illustrated below:
| R4#show ip ospf statistics detailOSPF Router with ID (4.4.4.4) (Process ID 4)Area 2: SPF algorithm executed 4 times
SPF 1 executed 02:25:42 ago, SPF type Full SPF 2 executed 02:25:32 ago, SPF type Full SPF 3 executed 00:14:42 ago, SPF type Full |
Keep in mind that this is not the TSHOOT exam. You are not expected to demonstrate advanced OSPF troubleshooting skills in the ROUTE exam.