Summarizing Routes in OSPF
Problem
You want to reduce the size of your routing tables without losing any connectivity within your network.
Solution
Using the area x range configuration command on your ABRs allows you 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)#exit Router1(config)#end Router1#
Discussion
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 route with 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#
Then, after enabling summarization, you can see that all of the individual routes in each of these ranges have been replaced with a single route for the entire range. Notice also 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. And 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, then 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, where 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 to cause 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. So 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.
You also have to remember that 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 them 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, such as:
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, you can use the no discard-route command as follows:
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. And, 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.
See Also
RFC 1583; RFC 2328