For any OSPF network engineer, and JNCIE candidates, it is crucial to understand the tools to improve the scalability and stability of the OSPF domain. As with any routing protocol the main instrument for this is some form of summarization and/or filtering. By limited sharing of details between different parts of the OSPF domain any instabilities can be hidden, resulting in less CPU and memory usage on the router RE's.
OSPF has a few restrictions on where you can summarize and/or filter routes in the network.Within an area summarization is not allowed as all routers need to share the same database in an area. A somewhat general rule is that OSPF only can summarize when route / LSA conversion is taking place. For internal routes this is done on the ABR when converting intra-area route information (type 1 and 2) into inter-area route information (type 3). For external routes this is done at redistribution ASBR's when non-OSPF route information is converted into External OSPF route information (type 5 or 7), as well as on nssa area ABR's when converting NSSA External route information (type 7) into External route information (type 5).
For OSPF with Junos the following options exist:
1. Inter-area internal LSA summarization and filtering on the ABR using area-range command
2. Inter-area internal LSA filtering on the ABR using the network-summary-import/export policies
3. External route summarization and filtering on the ASBR using aggregate routes and export policies
4. Inter-area NSSA external route summarization and filtering on the NSSA ABR using nssa area-range command.
5. Route-table filtering of external routes using import policies
For Stub and NSSA area's normally some form of default routes are also configured for reach-ability which is also a form of summarization. A 0/0 route is the ultimate form of summarization. The Stub and NSSA area intricacies will be part of different blog post in the future so this will not be covered here.
Lets start with the basic network diagram of the setup used to demonstrate the OSPF summarization tools. The focus is on the ABR router as this is the main box for controlling inter-area summarization and filtering. The ABR can also be used as an ASBR for the external route generation. 
In area 0 we will focus on the 172.16.128-135.0/24 prefixes, in area 1 on 192.168.0-7.0/24 prefixes. The 172.31.240-243.0/24 prefixes will be used for the route distribution summarization on JNCIE-R1. For the NSSA redistibution example the 10.200.96-99.0/24 prefixes on JNCIE-R3 will be used.
The base configuration of the ABR router is shown below for the network without any form of summarization or filtering. No redistribution is configured at this point.
The OSPF database of the ABR is shown below. Notice the amount of Summary LSA's in both area 0 and 1.In area 0 all the 8 192.168.0-7.0/24 specific summary LSA's are seen, similar in area 1 all the 172.16.128-135.0/24 specific summary LSA's are present.
1. Inter-area internal LSA summarization and filtering
The ABR basically only shares the prefix and cost information from the router LSA (type 1) and network LSA (type 2) from area X into the summary LSA (type 3) for Area Y (and vice versa of course). By default all internal prefixes from one area are shared with the other area's by the ABR.
To limit the amount of prefixes exchanged between area's summarization can be used to increase stability without a change in reachability . In OSPF the area X area-range command is used for this purpose, where X is the source area number of the more specific prefixes that are being summarized towards the other area's on the ABR.
Below is the configuration of the ABR and resulting the OSPF database, to highlight the effect of the area-range command for both area 0 and area 1. When compared to the base setup OSPF database notice that there are fewer Summary LSA's in both area's. In area 0 only 1 summarized prefix is seen of 192.168.0.0/21, and in area 1 only 1 summarized prefix of 172.16.128.0/21.
When using summarization in general the summary route will need to point to the bit bucket so that if a more specific prefix from the range is not present, packets will not take the default route as this can lead to potential loops. So if area-range commands are used the summary prefix will automatically be created with a next-hop of discard and a high metric, of course as long as at least one specific prefix is present.
A question I quite often get is what happens with overlapping summarizations from the same ABR. So lets have a look how this works as it results in some surprising database output. Both the /21 summary and 2 /22 summaries are configured. The database shows the 3 summaries with the odd 172.16.135.255 typically raising questions.
The problem with overlapping prefixes is that the ID for a prefix can only be used once as it is a unique identifier for a prefix from a specific ABR. The 172.16.128.0/22 and the 172.16.128.0/21 would try to generate the same ID. Whoever is created first wins, and the "loser" must choose an alternative ID, which typically is the last address from the summarization range, which is 172.16.135.255 in this example. Only combining the ID with the mask will tell us what the actual prefix is. To see this we need to look at the OSPF database summaries in more detail.
In this case the 172.16.128.0/22 was first created so the 172.16.128.0/21 has to choose a different ID, which is 172.16.135.255. In combination with the mask of 255.255.248.0 it is still clear that it is representing the 172.16.128.0/21 network.
When using the same area X area-range command with the restrict keyword the more specific prefixes will now no longer be sent to the other area's on the ABR. This means more stability but now with a change in reachability!
Below is the configuration and resulting OSPF database on the ABR. The 172.16.128.0/21 and 192.168.0.0/21 prefixes are no longer present as summary LSA's in the database.
2. Inter-area internal LSA filtering on the ABR
Another form of filtering internal LSAs on the ABR is using the area X network-summary-export and/or network-summary-import commands that refer to a configured route policy. The idea here is that you can control what you want to share from area X to all other area's on the ABR using the network-summary-export policy, so export here means what info do you want other area's to know about. And to control what information an area wants to learn from other area's you can use the network-summary-import policies.
Below is the configuration of the ABR that shows how to control what prefixes area 1 wants to share with any area on this ABR. When we look at the details of the OSPF database it shows that area 1 only allowed prefixes 192.168.4-7.0/24 to be shared with other area's.
The result is that only the 192.168.4-7.0/24 prefixes are shared from area 1 with area 0 in our example.
When changing the configuration for area 0 to limit what prefixes are accepted, the resulting database shows only the 192.168.6-7.0/24 subset of the prefixes shared by area 1 made it to area 0's database.
In OSPF3 for IPv6 this option is called inter-area-prefix-export and inter-area-prefix-import.
3. External route summarization and filtering on the ASBR
Redistribution of routes into any routing protocol on Junos is accomplished by using an export policy, therefore this also applies to OSPF. The redistribution router (ASBR) can choose to send more or less specific information by modifying the export policy. To create a summary route of the routes to be redistributed an aggregate or generate route is created manually. In the policy it is now possible to advertise only the summary or the summary in any combination with the specifics. Filtering of non-OSPF routes into OSPF is easily accomplished by not including the routes into the export policy.
Firstly shown is the base configuration for redistribution of routes into OSPF, and the existence of 4 specific External routes (LSA type 5) in the database.
Shown below is the export policy with only a summary route advertised. In the OSPF database only a single External route is seen, 172.31.240.0/22.
4. Inter-area NSSA external route summarization and filtering on the NSSA ABR
As previously discussed redistribution of routes into the OSPF domain requires the use of export policies. The same principles apply when redistributing non-OSPF routes into a NSSA area. The difference is that there is a second chance to apply summarization or filtering that is on the ABR connecting the NSSA area to the backbone. So a typical scenario is to redistribute the specifics into the NSSA area, while allowing only the summary route into the rest of the network using the area X nssa area-range command on the ABR.
First we see the default behavior without summarization of NSSA External routes (type 7). On JNCIE-R3 (3.3.3.3), part of the nssa area 1, four routes 10.200.96-99.0/24 are redistributed. The database output shows that all NSSA External routes are converted into External routes for area 0 and beyond by the ABR (1.1.1.1)
When the summarization is applied on the ABR the output below shows that there is only 1 External route created from all the NSSA External routes.
If the area nssa X area-range command with the restrict option is used it is even possible to filter the NSSA external routes from the rest of the network. Make sure no reachability to those networks is needed from other area's.
Note: For enhanced stability both the area X area-range and the area X nssa area-range command have the override-metric keyword to lock down the cost of the summary route. Otherwise the worst case scenario is that if one of the specific route flaps the cost of the summary might need to be updated which defeats the stability idea of a summary route.
5.Route-table filtering of external routes using import policies
OSPF supports the option to filter External / NSSA External routes from entering the routing table. Very important to understand that it does NOT prevent the routes from being exchanged with other neighbors as this is done from the LSA database where the import policy has no effect. The incorrect use of the import policy in the network will create a blackhole situation. So typical advise is to never use this tool, but if you have to use it in your design you must apply the import policy consistently in a upstream direction.
When we have a network like R1-R2-R3-R4-R5. So if you have route redistribution configured on R1 and you must filter the route from the route table on R3, you must also do it on R4 and R5. If you dont' then R4 and R5 learn the route from the database where the physical path would go through R3, which would drop the packet as the route is not installed in the route / forwarding table!
Lets see the import policy in action in our configuration and the result in the route table. From JNCIE-R3 we learn 4 External routes 10.200.96-99.0/24 (area 1 is a normal area in this example) as seen in the show ospf database external command. The import policy only allows 2 of the 4 routes into the route table. Only the 10.200.98.0/24 and 10.200.99.0/24 make it into the route table as seen in the output of the show route protocol ospf | match 150 command (150 is the route preference for External OSPF routes).
Summary
This post covered the different options on summarizing and filtering routes in an OSPF network. Both internal route summarization between area's, and External route summarization were discussed. OSPF uses a mix of summarization within the protocol (area-range) as well as the manual summarization using aggregate routes. Understanding which tools to use in specific situations is an essential skill for JNCIE candidates.
More information about advanced OSPF summarization scenarios can be found in iNET ZERO’s JNCIE workbooks.
Let us know what other topics you would like to have covered in these blog posts.
