This article covers Summarisation and Filtering of OSPF Routes on Cisco IOS Devices:
Why Summarise Routes?
Summarising routes in OSPF allows routers to reduce the size of their routing table. A summary route can be used where a router has the same egress path to similar contiguous networks that subsequently can be expressed as one route. This also allows the OSPF link state database size to be reduced in size where summarisation is possible.
Why Filter Routes?
OSPF Route Filtering involves filtering / modifying the information used to generate OSPF LSAs. LSAs (Link State Advertisements) are the building blocks of OSPF routing information, LSAs themselves can not be filtered directly, however the process in which Routing Information is used to generate LSAs can be.
In a multi-area OSPF design, you may wish hide parts of the overall topology from specific areas. You may also wish to hide certain prefixes within in an area from entering the routing table of a particular router. Another potential use case would be to filter out specific prefixes that have been learned externally.
LSA Types
One or multiple OSPF LSAs are propagated depending on their scope via LSU (Link State Update) packets, for the sake of completeness I have included the main LSA types below, these are NOT all the OSPF LSA Types. For more in-depth specifics relating to the below and other LSA types, another article would be required:
Summaries & Filtering
Refer to the above topology for the later Filtering examples performed at both an ABR (Area Border Router) and a ASBR (Autonomous System Border Router).
Area 33 and 51 are standard OSPF areas where no external routes are being injected. Area 12 is a NSSA (Not So Stubby Area), external routes are originated here by R6 and redistributed into OSPF by R5.
A point to note here is that those external routes will only exist in Area 12 as Type 7 (NSSA External) LSAs, these will be translated into standard Type 5 (External) LSAs by R4. Type 5 LSAs are eligible for flooding out all of R4’s interfaces that aren’t Virtual Links or attached to a stub area.
As a starting point for this article, I have included the routing tables of both ABRs (R1 & R4) and the ASBR (R5) above.
Summarisation:
Summarisation of routes in OSPF can only be performed at an ABR or ASBR, this is as summarisation needs to be done at the boundary of areas to which ABRs / ASBRs connect to.
ABR
Use the #area area-id range ip-address mask [advertise | not-advertise] [cost cost] command to summarise at an ABR. This will generate a summary route to ‘null0’ on the router generating the summary. Null0 is used so that if this router receives a packet for a IP within that summary but doesn’t have a specific route for it, it then doesn’t route it via its default route. Simply, the router itself is relying on its more specific interfaces / ranges.
It’s worth noting that only Intra-Area routes can be summarised, not Inter-Area routes.
Intra-Area routes are evaluated and if at least one more specific route in the configured summary range exists, then the ABR will advertise a summary route, otherwise not. The ABR which would usually originate multiple Type 3 (Summary) LSAs now only originates a single LSA for the summary route so it can be propagated into other attached areas.
The cost / metric of this summary is taken as the lowest metric of the most specific component route, alternatively it can be specified in the above command. The ‘not-advertise’ switch on the ‘area range’ command can be used to filter out Intra-Area routes, this will be discussed later.
We will summarise the 4 individual routes advertised at R3 (OSPF Area 51) into 2 summaries (10.200.100.0/23 & 10.150.0.0/15) at R1 (ABR) and verify at R1 and R2. Commands are entered under the OSPF process:
R1#
router ospf 1
area 51 range 10.200.100.0 255.255.254.0
area 51 range 10.150.0.0 255.254.0.0
Verify R1 is creating summaries:
As you can see above the wider network no longer sees the specific routes but the summary routes instead.
ASBR
How about applying this concept to the EIGRP routes learnt from R6 by R5 as OSPF Type 7 LSAs (NSSA External) and advertised through R4 and the rest of the OSPF domain as Type 5 LSAs (AS External)?
Above, we can use the #summary-address {{ip-address mask} | {prefix mask}} [not-advertise] command to summarise externally learnt OSPF routes. Similarly to filtering at an ABR, the external routes will have to summarised at our ASBR (R5) which has a view of the external routes and is redistributing them into OSPF.
External routes summarised at an ASBR can not have their cost manually specified, instead the summary route will take the metric / cost of a more specific route with the lowest cost.
The 2 external routes (172.16.16.0/24 & 172.16.17.0/24) Injected into OSPF at R5 can be summarised to 172.16.16.0/23:
#R5
router ospf 1
summary-address 172.16.16.0 255.255.254.0
Verify a summary is being injected into OSPF at R5, we can also verify the LSA being generated – note R5 is a NSSA ASBR:
Route Filtering:
We’ll now cover the different methods you can filter out routes in OSPF, to keep things flowing we’ll look to filter out our 2 newly created internal summaries (10.150.0.0/15 & 10.200.100.0/23) and external summary (172.16.16.0/23). Once filtered, we’ll verify as above on R2 & R5 for internal routes filtered and R2 & R3 for external routes.
Route Calculation & LSA Generation:
To understand how to influence the generation of Type 3 (summary) LSAs, a high level diagram of the process of OSPF adjacency formation and LSA generation is shown above.
The OSPF process on a ABR (Area Border Router) examines the Routing Table (RIB) and generates / floods T3 LSAs from these intra-area routes. An ABR also examines T3 LSAs it receives that’s originated by other ABRs, these are considered inter-area routes and will only be accepted from Area 0 (backbone area) – this is a loop prevention mechanism. Once an ABR has received inter-area routes in the form of T3 LSAs, it will then flood them to its attached non backbone area(s) to propagate this information.
In terms of filtering external routes, this is mainly down by filtering out routes from one routing process to another during redistribution. There will be some examples of this a little later on.
Depending on the method used to filter OSPF routes, the actual method may either suppress the information used to generate a T3 LSA or it may just prevent that information from entering a process or routing table. This will be explained in slightly more detail alongside each filtering method.
Filtering at an ABR
filter-list – This method filters all types of OSPF routes (Intra Area, Inter Area and Summary)
# area area-id filter-list prefix prefix-list-name {in| out}
This command is to be applied on our ABR – R1 in our case, note the option to specify a direction in the above command. In this case filtering prefixes into a non backbone area attached to the ABR (such as 33 or 51) will result in prefixes being filtered out in only that area.
To filter prefixes from one area to other backbone attached areas, prefixes inbound to area 0 need to be filtered out, preventing them from being propagated to other attached areas.
Currently, using the ‘show ip ospf database self-originate‘ command on R1, we can see of the summary LSAs originated into Area 33 by R1, we have 10.150.0.0 & 10.200.100.0 which represent the previously created summary routes.
Below an example of filtering out both of our summary routes 10.150.0.0/15 & 10.200.100.0/23 both into Area 33 and also into Area 0 is shown:
#R1
ip prefix-list R3-> seq 2 deny 10.200.100.0/23
ip prefix-list R3-> seq 3 deny 10.150.0.0/15
ip prefix-list R3-> seq 4 permit 0.0.0.0/0 le 32
router ospf 1
area 33 filter-list prefix R3-> in
As you can see above, after applying the ‘filter-list’ R1 no longer generates summary LSAs for 10.150.0.0/15 & 10.200.100.0/23 into area 33 and as such. This results in R2 in Area 33 no longer seeing either of those routes.
area range (not-advertise) – Since OSPF summarisation occurs before LSA generation, we can use this method to summarise routes but prevent respective LSAs from being generated. This is similar to applying the ‘filter-list’ command in the outbound direction, this will mean that routes from an area are suppressed when summarised and subsequently prevented from being propagated to other areas.
#area area-id range ip-address mask [advertise | not-advertise] [cost cost}
Following on from our previous example, we will look to prevent the 10.200.100.0/23 summary from being propagated out of Area 51 (notice that we are already summarising at R1 for this range – as per earlier example) :
#R1
router ospf 1
area 51 range 10.200.100.0 255.255.254.0 not-advertise
distribute-list (inbound) – Since OSPF Summary LSAs are generated based on inter-area routes learned from Area 0, we can prevent certain LSAs from being generated by applying a distribute list inbound – preventing certain inter-area routes from having LSAs generated or propagated into an area.
The example below involves both R4 (ABR) and R5 (Area 12 – NSSA)
As you can see R4 in Area 12 is learning of the 10.201.1.0 LSA via Area 0, installing a route for it and then generating a summary LSA into Area 12. Routers in Area 12 (R5 in this case) will then install this route from that LSA.
In our example below (after removing both ‘area range’ and ‘filter list’ commands on R1), we will look to prevent R5 learning about the ‘10.201.1.0/24’ route. We will achieve this by applying a distribute list inbound on R4 to prevent it from learning about this prefix and subsequently generating a Summary LSA for it:
#R4
ip prefix-list R4<-IN seq 5 deny 10.201.1.0/24
ip prefix-list R4<-IN seq 6 permit 0.0.0.0/0 le 32
router ospf 1
distribute-list prefix R4<-IN in
Once applied R4 no longer generates a summary LSA into Area 12. Subsequently R5 will no longer receive a summary LSA and install this route.
Filtering at an ASBR
Following on from a earlier example (with the 172.16.16.0/23 summary configured on R5), we can see the external OSPF routes currently learnt in Area 33 and Area 51 as below:
Specifically, we will be looking at filtering out the 203.0.113.0/24 route using one of the below methods. To recap, these external routes are redistributed from EIGRP into OSPF at R5 in a NSSA area. These external routes exist as type 7 LSAs in Area 12, until they are converted to Type 5 LSAs at R4 and propagated throughout the rest of the OSPF domain.
R5 will be the best place to filter out these external routes as it’s as close to the source of origination as possible. We could filter on R4 if we wanted just area 12 to know about this route. You can see the Type 7 LSA for 203.0.113.0/24 below:
area range (not-advertise) – Similar to when we summarised a set of external OSPF routes, we can use the same #summary-address {{ip-address mask} | {prefix mask}} [not-advertise] command to create a summary (of the same route) and not advertise it.
#R5
router ospf 1
summary-address 203.0.113.0 255.255.255.0 not-advertise
As above R2 or R3 no longer see this external route and R5 is no longer generating a type 7 LSA for it.
route map (redistribution) – After removing our ‘area range’ command above, we can achieve the same by using a route-map during redistribution on R5 as below:
#R5
ip prefix-list EIGRP–>OSPF seq 5 deny 6.6.6.6/32
ip prefix-list EIGRP–>OSPF seq 6 deny 203.0.113.0/24
ip prefix-list EIGRP–>OSPF seq 7 permit 0.0.0.0 le 32
route-map EIGRP-External permit 2
match ip address prefix-list EIGRP–>OSPF
router ospf 1
redistribute eigrp 10 subnets route-map EIGRP-External
Very thorough, and very well done! I’ll be bookmarking this one for later!