OSPF Filtering: area range vs filter-list vs distribute-list vs summary-address

OSPF gives you four different ways to stop a prefix from getting somewhere, and they are not interchangeable. Two of them remove the LSA from the link-state database. One leaves the LSA in place and only touches the local routing table. One only works on external routes. Pick the wrong one and you either fail to achieve what you wanted, or you break something two areas away.

The distinction that separates people who know OSPF from people who have memorised OSPF commands is this: which of these changes the LSDB, and which only changes the RIB? This article answers that with side-by-side lab output for all four mechanisms applied to the same route set. For the fundamentals, start at the complete OSPF guide.

Why OSPF is hard to filter at all

OSPF is a link-state protocol. Every router in an area must have an identical LSDB, or SPF produces different answers on different routers and you get routing loops. This is not a policy preference, it is a correctness requirement.

So OSPF fundamentally cannot filter LSAs inside an area. There is no such thing as "do not flood this Type-1 LSA to that neighbour". If you want to stop a prefix from reaching a router in the same area, your only option is to stop that router from installing it - the LSA still arrives, still floods, still consumes memory.

That is why the two mechanisms that genuinely remove an LSA both operate at an area boundary, where a new LSA type is being generated and the ABR gets to decide what goes in it. And it is why the mechanism that works anywhere only touches the local RIB.

The four mechanisms

Two sentences to memorise: area range and summary-address summarise, and are the only tools for their LSA type. filter-list filters at the area boundary. distribute-list is local-only and does not touch the database.

The lab

R2 is an ABR between area 0 and area 1. R1 sits in area 0 and is our observation point. Area 1 contributes several prefixes, which arrive at R1 as Type-3 summary LSAs:

R1#show ip ospf database summary | include Link State ID|Advertising Router
  Link State ID: 3.3.3.3        Advertising Router: 2.2.2.2
  Link State ID: 5.5.5.5        Advertising Router: 4.4.4.4
  Link State ID: 10.0.23.0      Advertising Router: 2.2.2.2
  Link State ID: 10.0.45.0      Advertising Router: 4.4.4.4
  Link State ID: 10.0.234.0     Advertising Router: 2.2.2.2
  Link State ID: 172.16.99.0    Advertising Router: 2.2.2.2

1. area range not-advertise - kills the LSA

R2(config-router)#area 1 range 10.0.234.0 255.255.255.0 not-advertise

R1#show ip ospf database summary | include Link State ID
  Link State ID: 3.3.3.3
  Link State ID: 5.5.5.5
  Link State ID: 10.0.23.0
  Link State ID: 10.0.45.0
  Link State ID: 172.16.99.0        <-- 10.0.234.0 gone from the LSDB

R1#show ip route ospf | include 10.0.234
                                    <-- and gone from the RIB

The Type-3 was never generated. Every router in area 0 loses it. This is a real, database-level removal.

The Null0 discard route

When area range is used to summarise (rather than suppress), the ABR installs a discard route for the summary. From the lab, with a deliberately over-broad range:

R2(config-router)#area 1 range 10.0.224.0 255.255.224.0

R2#show ip route 10.0.224.0 255.255.224.0
Routing entry for 10.0.224.0/19
  Known via "ospf 1", distance 110, metric 10, type intra area
  Routing Descriptor Blocks:
  * directly connected, via Null0

This is deliberate anti-loop behaviour. The ABR is advertising a /19 to the rest of the network, so it will attract traffic for the entire /19 - including addresses inside it that do not exist. Without the Null0 route, that traffic would follow the ABR's default route back out and loop. The discard route drops it instead.

The operational consequence is important and easy to miss. Traffic to a non-existent host inside the summary is now pulled all the way to the ABR before being dropped:

R1#ping 10.0.230.5 source Loopback0 repeat 2
U.
Success rate is 0 percent (0/2)

The U is an ICMP unreachable from R2. Your summary range must be tight. A sloppy range does not just advertise the wrong thing, it black-holes real address space.

2. area filter-list - also kills the LSA

ip prefix-list NO-AREA1-TRANSIT seq 5 deny 10.0.23.0/30
ip prefix-list NO-AREA1-TRANSIT seq 10 permit 0.0.0.0/0 le 32

router ospf 1
 area 1 filter-list prefix NO-AREA1-TRANSIT out

R1#show ip ospf database summary | include Link State ID
  Link State ID: 3.3.3.3
  Link State ID: 5.5.5.5
  Link State ID: 10.0.45.0
  Link State ID: 10.0.234.0
  Link State ID: 172.16.99.0        <-- 10.0.23.0 gone from the LSDB

Same result, different tool. So why have both?

• area range can only act on a contiguous block that you can express as one prefix and mask. It is a summarisation tool that happens to be able to suppress.
• area filter-list takes a prefix-list, so it can express arbitrary rules - deny 10.0.23.0/30, permit 10.0.0.0/8 ge 24 le 26, whatever. It is a filtering tool and does not summarise at all.

And the direction keyword matters enormously:

The direction is from the perspective of the area named in the command, not the router. This trips up almost everybody the first time.

3. distribute-list in - the LSA survives

Now the one that behaves differently, and the reason this article exists.

ip prefix-list HIDE-234 seq 5 deny 10.0.234.0/24
ip prefix-list HIDE-234 seq 10 permit 0.0.0.0/0 le 32

router ospf 1
 distribute-list prefix HIDE-234 in

Applied on R1. And now look:

R1#show ip ospf database summary | include Link State ID
  Link State ID: 3.3.3.3
  Link State ID: 5.5.5.5
  Link State ID: 10.0.45.0
  Link State ID: 10.0.234.0        <-- STILL IN THE LSDB
  Link State ID: 172.16.99.0

R1#show ip route ospf | include 10.0.234
                                   <-- but NOT in R1's routing table

R4#show ip route ospf | include 10.0.234
O IA     10.0.234.0/24 [110/20] via 10.0.24.1, Ethernet0/2   <-- R4 is completely unaffected

That is the whole lesson in three commands. The LSA is still flooded, still in the database, still consuming memory, still contributing to SPF. R1 simply refuses to install the resulting route. Every other router in the area is oblivious.

Three consequences follow directly:

1. It saves no memory and no CPU. The LSA is still there. If your goal is to shrink the database, distribute-list does nothing for you.
2. It is per-router. You have to configure it on every router where you want the effect, and the moment someone adds a router without it, the behaviour is inconsistent.
3. It can create routing loops. If R1 has no route to a prefix but R4 does, and R1's default points at R4, traffic will go R1 → R4 → back toward R1 if R4's best path happens to be through R1. Link-state protocols rely on every router agreeing; distribute-list deliberately breaks that agreement.

There is exactly one place distribute-list is genuinely the right answer: you want a single router (or a small set) to not use a route, while everyone else does. A management router that should not learn a customer VRF's prefixes. A route that a specific box must reach via a static instead. That is it. If you find yourself deploying the same distribute-list on every router in an area, you wanted a filter-list at the ABR.

4. summary-address - for externals only

area range and filter-list only touch Type-3 LSAs. They can do nothing about Type-5 external routes, which flood through the whole OSPF domain untouched by area boundaries. For those, you go to the source: the ASBR.

In the lab, R3 (the ASBR) redistributes four /24 statics:

R1#show ip route ospf | include E2
O E2     172.20.20.0 [110/20] via 10.0.12.2, Ethernet0/1
O E2     172.20.21.0 [110/20] via 10.0.12.2, Ethernet0/1
O E2     172.20.22.0 [110/20] via 10.0.12.2, Ethernet0/1
O E2     172.20.23.0 [110/20] via 10.0.12.2, Ethernet0/1

R3(config-router)#summary-address 172.20.16.0 255.255.240.0

R1#show ip route ospf | include E2
O E2     172.20.16.0 [110/20] via 10.0.12.2, Ethernet0/1

R1#show ip ospf database external | include Link State ID
  Link State ID: 172.20.16.0 (External Network Number )      <-- one LSA, not four

And the same anti-loop discard route appears, on the ASBR this time - note the administrative distance of 254, which keeps it out of the way of any real route:

R3#show ip route 172.20.16.0 255.255.240.0
Routing entry for 172.20.16.0/20
  Known via "ospf 1", distance 254, metric 20, type intra area
  Routing Descriptor Blocks:
  * directly connected, via Null0

summary-address with not-advertise also works, and suppresses the externals entirely.

Choosing

The warning that ties it all together

Every one of these mechanisms can, without warning, break an external route that has a non-zero forwarding address. If the subnet the forwarding address lives on is summarised, suppressed or filtered away, the external route is silently discarded on every router that can no longer resolve it. We reproduced this in the lab with both prefix suppression and an area range not-advertise, right down to a failing ping.

Before you filter anything in a core:

show ip ospf database external | include Forward Address

Full details in the OSPF forwarding address.

Key takeaways

• area range and area filter-list run on an ABR and genuinely remove the Type-3 LSA. Everyone in the target area loses the route.
• distribute-list in runs on any router and only touches that router's RIB. The LSA stays in the database and every other router is unaffected. It saves no memory, and it can create loops.
• summary-address runs on an ASBR and is the only tool for Type-5 and Type-7 externals.
• Summarising with area range or summary-address installs a Null0 discard route. That is correct anti-loop behaviour, and it means a sloppy range black-holes real address space at the summarising router.
• area X filter-list ... out means "leaving area X", not "outbound from this router". The direction is relative to the area.
• Stub and NSSA area types are a cleaner way to keep externals out of an area than any filter.
• Check for non-zero forwarding addresses before you filter anything in a core, or you will silently kill external routes.

Next: OSPF path preference - O vs O IA vs E1 vs N1 vs E2 vs N2, with all six proven in sequence in the lab. The full cluster index lives on the OSPF pillar guide.