Carrying on with our discussion of multi-area OSPF, refer to the example topology shown in Figure 1:
Recall that we’ve allocated the IP address space as follows:
- Area 0: 10.0.0.0/24 through 10.0.255.0/24 (256 subnets)
- Area 1: 10.1.0.0/24 through 10.1.255.0/24 (256 subnets)
- Area 2: 10.2.0.0/24 through 10.2.255.0/24 (256 subnets)
By default, all routers will know about the existence of all 768 subnets, but we can configure the ABRs to advertise summary routes between areas with the OSPF “area range” command. Assuming that R2 is running OSPF process ID 1, we’d tell R2 to summarize the “/16” block of routes within Area 1 into Area 0 like this:
- R2(config)#router ospf 1
- R2(config-router)# area 1 range 10.1.0.0 255.255.0.0
Likewise, we tell R2 to summarize the “/16” block of routes that lies within Area 0 into Area 1:
- R2(config-router)# area 0 range 10.0.0.0 255.255.0.0
Note that in each case the area number specified is that of the area which contains the routes, not the area into which the summary block is being advertised. Similarly, we can configure route summarization on R4 between Area 2 and Area 0:
- R4(config-router)# area 2 range 10.2.0.0 255.255.0.0
- R4(config-router)# area 0 range 10.0.0.0 255.255.0.0
That’s it! We’ve just dramatically reduced the sizes of the routing tables on all routers in the OSPF autonomous system.
Now, let’s say that for fault-tolerance, there are two ABRs joining a pair of areas. Refer to Figure 2, in which R6, an additional ABR between Area 1 and Area 0, has been added:
What happens if we configure R2 to summarize the routes from Area 1 into Area 0, but we don’t configure R6 to do the same? Since R6 is advertising the individual subnets, the routers within Area 0 will know them, as well as the summary route they learn from R2. Since a router prefers the longest match to a particular destination, the traffic bound from Area 0 into Area 1 will flow via R6 (a “/24” beats a “/16”). Thus, to minimize the size of the routing tables in the adjacent areas, we should configure the same summarizations on both R2 and R6. This will also facilitate load-sharing between the ABRs for traffic traveling between the areas.
What about connections to the outside world? Refer to Figure 3, in which R5 has been made an ASBR (Autonomous System Boundary Router), connecting the OSPF autonomous system to a RIP routing domain:
To make R5 an ASBR, we would need to configure “route redistribution” from RIP into OSPF (redistribution is a CCNP topic). Once that’s done, R5 will advertise the individual prefixes it learns via RIP into OSPF, and they will be passed throughout Area 2, into Area 0, and also into Area 1. If we like, we can also configure route summarization on the ASBR. Assuming that the RIP cloud contains subnets that fall within the address block of 172.16.0.0/16, we would configure the OSPF summary route like this:
- R5(config-router)#summary-address 172.16.0.0 255.255.0.0
The result would be that R5 will advertise the summary block 172.16.0.0.16 into Area 2, where it will be learned by R4, which will advertise it into Area 0. The advertisement will flood across Area 0 and be learned by R2 and R6, which will both advertise the summary route into Area 1. The result is that R5 (the ASBR) will know all of the individual routes it learned via RIP, and all of the other routers in the OSPF autonomous system will know the summary route for the external routing domain.
Next time, we’ll discuss some additional OSPF scalability features.
Author: Al Friebe