In this post, I will go through the OSPF filter-lists (in & out) and explain how they are working. I’ll start of with easy scenario’s, then gradually make them more complex to understand. The thing to remember is that you can only filter type 3 LSA’s on ABRs. When filtering in or out of an area, you are actually filtering the LSA 3 in or out of the specified area. The topology I will use is shown below.

Scenario 1 – Applying filter-lists inbound on a non-transit area (i.e. non-backbone area)
This is the easiest scenario to understand. When applying a filter-list inbound to a particular non-transit area, it literally is used to stop that area receiving the prefix. In the topology above, I’ll apply an inbound filter to Area 3 in order to stop it receiving R1’s loopback. First off let’s check R2’s LSDB for summary LSA’s for 150.1.1.1.

R2#sh ip ospf da | i Summary|150.1.1.1
Summary Net Link States (Area 3)
150.1.1.1 3.3.3.3 1898 0x80000016 0x00522E
As you can see it is learning the LSA 3 from R3, as we would expect. Now let’s make the modification.

R3(config)#ip prefix-list R1_LOOPBACK deny 150.1.1.1/32
R3(config)#ip prefix-list R1_LOOPBACK permit 0.0.0.0/0 le 32
R3(config)#
R3(config)#router ospf 1
R3(config-router)#area 3 filter-list prefix R1_LOOPBACK in
Now if we check R2’s LSDB for the same prefix.

R2#sh ip ospf da | i Summary|150.1.1.1
Summary Net Link States (Area 3)
R2#
As you can see the LSA 3 for 150.1.1.1 has been removed. Very straight forward. The way to read the syntax of the filter-list command is simply, for Area X deny prefixes Y inbound specifically & only for Area X. The key point to remember about this is that only the ABR(‘s) generating the summary LSA into area X can perform the filtering.

Scenario 2 – Applying a filter-list outbound of a non-transit area (i.e. a non-backbone area)
NOTE: All filter-lists from previous scenarios have been removed.

When applying a filter-list outbound of a particular area it stops all other areas that the ABR is connected to receiving the prefix. So for example, in the topology above we could use a filter-list out of area 1 to block R6’s loopback (150.1.6.6) getting into area 2 and area 3. The question is, where do we apply it. Do you apply it on R3, R7 or both?

If you apply the filter-list on just R7, the impact would be this. R7 would not advertise a type 3 LSA for 150.1.6.6 into area 0 or area 2. However area 3 would still get the prefix. The reason why, is because R3 is also an ABR in this area. Since R3 is not filtering any prefixs out of area 1, R3 is still allowed to create a type 3 LSA for 150.1.6.6 and send it into area 0 and area 3. So let’s do the config and see the result.

Here is the LSDB, displaying just the summary for 150.1.6.6 on R7, R3, R9, and R2 prior to the change.

—————————————————————
R7#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
150.1.6.6 3.3.3.3 288 0x80000001 0x001D6D
150.1.6.6 7.7.7.7 356 0x80000016 0x0070F5
Summary Net Link States (Area 1)
Summary Net Link States (Area 2)
150.1.6.6 7.7.7.7 361 0x80000001 0x009AE0
—————————————————————
R3#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
150.1.6.6 3.3.3.3 343 0x80000001 0x001D6D
150.1.6.6 7.7.7.7 413 0x80000016 0x0070F5
Summary Net Link States (Area 1)
Summary Net Link States (Area 3)
150.1.6.6 3.3.3.3 343 0x80000001 0x001D6D
—————————————————————
R9#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 2)
150.1.6.6 7.7.7.7 403 0x80000001 0x009AE0
—————————————————————
R2#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 3)
150.1.6.6 3.3.3.3 363 0x80000001 0x001D6D
—————————————————————
Now to do the change, starting with just R7.

R7(config)#ip prefix-list R6_LOOPBACK deny 150.1.6.6/32
R7(config)#ip prefix-list R6_LOOPBACK permit 0.0.0.0/0 le 32
R7(config)#
R7(config)#router ospf 1
R7(config-router)#area 1 filter-list prefix R6_LOOPBACK out
The result.

—————————————————————
R7#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
150.1.6.6 3.3.3.3 442 0x80000001 0x001D6D
Summary Net Link States (Area 1)
Summary Net Link States (Area 2)
—————————————————————
R3#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
150.1.6.6 3.3.3.3 454 0x80000001 0x001D6D
Summary Net Link States (Area 1)
Summary Net Link States (Area 3)
150.1.6.6 3.3.3.3 454 0x80000001 0x001D6D
—————————————————————
R9#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 2)
R9#
—————————————————————
R2#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 3)
150.1.6.6 3.3.3.3 488 0x80000001 0x001D6D
As you can see, R7 has stopped advertising the LSA3 out of all it’s other connected areas (including area 0). Only R3 is advertising the type 3 LSA now, which means that R2 (area3) can still get to 150.1.6.6. If we do want to stop area 3 getting the prefix, we would also need to apply the filter-list outbound on R3. So let’s finish the scenario by implementing that on R3.

R3(config)#ip prefix-list R6_LOOPBACK seq 5 deny 150.1.6.6/32
R3(config)#ip prefix-list R6_LOOPBACK seq 10 permit 0.0.0.0/0 le 32
!
R3(config)#router ospf 1
R3(config-router)#area 1 filter-list prefix R6_LOOPBACK out
And now the result is that nobody will generate a type 3 LSA for that link.

—————————————————————
R7#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
Summary Net Link States (Area 1)
Summary Net Link States (Area 2)
—————————————————————
R3#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 0)
Summary Net Link States (Area 1)
Summary Net Link States (Area 3
—————————————————————
R9#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 2)
—————————————————————
R2#sh ip ospf database | i Summary|150.1.6.6
Summary Net Link States (Area 3)
In short, if you want to use a filter-list to block a prefix from going out of a particular non-transit area to all other areas, make sure all the ABR’s connecting to that area have the same filter-list applied.

Scenario 3 – Applying a filter-list inbound to area 0
NOTE: All filter-lists from previous scenarios have been removed.

When applying a filter inbound to area 0, it stops the type 3 LSA for the prefix from going into specifically area 0. In the topology above we will stop R9’s loopback (150.1.9.9) going into area 0 by using a prefix-list on R7 inbound to area 0. But first, just consider the following. If I confiure this using the syntax below, what would be the result (have a think what would happen)?

R7(config)#ip prefix-list R9_LOOPBACK deny 150.1.9.9/32
R7(config)#ip prefix-list R9_LOOPBACK permit 0.0.0.0/0 le 32
R7(config)#router ospf 1
R7(config-router)#area 0 filter-list prefix R9_LOOPBACK in
What should happen is that R7 will suppress the LSA 3 for 150.1.9.9 going to R3 (area0). However, area 1 should still get the prefix, because we are only blocking 150.1.9.9 into area 0. The result is below.

—————————————————————
R1#sh ip ospf database | i Summary|150.1.9.9
Summary Net Link States (Area 1)
150.1.9.9 7.7.7.7 1020 0x80000021 0x001B3A
—————————————————————
R3#sh ip ospf database | i Summary|150.1.9.9
Summary Net Link States (Area 0)
Summary Net Link States (Area 1)
150.1.9.9 7.7.7.7 1052 0x80000021 0x001B3A
Summary Net Link States (Area 3)
—————————————————————
R2#sh ip ospf database | i Summary|150.1.9.9
Summary Net Link States (Area 3)
—————————————————————
As you can see area 1 still gets the summary. R3 does still actually get the summary from R7, but via area 1 and not area 0. Finally, R2 does not get the summary at all. So the next question is, should R3 actually be able to reach it 150.1.9.9 via area 1? The answer is no. The reason why is because ABRs can only use LSA 3 summaries from the backbone area. If an ABR does actually learn an LSA3 from a non-backbone area, it will be installed into the OSPF database, but the routing bit will not be set & thus, it can never be installed into the RIB. This is a loop-prevention mechanism built into OSPF. And we validate this result by looking at the routing table on R3.

R3#sh ip route 150.1.9.9
% Subnet not in table

Now since R3 did not learn the LSA3 from the backbone, it also cannot forward the LSA 3 into area 3. This is why R2 does not get the LSA.

Scenario 4 – Applying a filter-list outbound of area 0
NOTE: All filter-lists from previous scenarios have been removed.

For this scenario, there are actually two use-cases that should be understood.

Use-Case 1
The first use case, is where we can use a filter-list outbound of area 0 specifically for prefixes owned inside of area 0. What I’ll do is filter 150.1.7.7/32 and 150.1.3.3/32 outbound of area 0. The filter will need to be applied on all ABR’s to take affect. i.e. If I placed the filter below just on R7, then area 1 and area 3 would still get the LSA 3’s for these prefixes from R3. Area 2 wouldn’t get the LSA though, because R7 is the sole ABR for that area.

R7(config)#ip prefix-list R7_AND_R3_LOOPBACK deny 150.1.7.7/32
R7(config)#ip prefix-list R7_AND_R3_LOOPBACK deny 150.1.3.3/32
R7(config)#ip prefix-list R7_AND_R3_LOOPBACK permit 0.0.0.0/0 le 32
R7(config)#!
R7(config)#router ospf 1
R7(config-router)#area 0 filter-list prefix R7_AND_R3_LOOPBACK out

R3(config)#ip prefix-list R7_AND_R3_LOOPBACK deny 150.1.7.7/32
R3(config)#ip prefix-list R7_AND_R3_LOOPBACK deny 150.1.3.3/32
R3(config)#ip prefix-list R7_AND_R3_LOOPBACK permit 0.0.0.0/0 le 32
R3(config)#!
R3(config)#router ospf 1
R3(config-router)#area 0 filter-list prefix R7_AND_R3_LOOPBACK out
So in summary, both R7 and R3’s loopbacks would be filtered out into area 1, 2, and 3 with this configuration. I’m not going to show the databases, because it’s very obvious what is happening here.

Use-Case 2
The second use case is where we can use an outbound filter-list for area 0, to filter non-backbone prefixes from leaving area 0. eg: We could stop prefixes inside area 2 from reaching all other areas except for area0.

In this example I’ll prevent R9’s loopback (150.1.9.9) from actually leaving area 0. This would be a similar affect to creating a filter-list on R7 for area 2 “outbound” for R9’s loopback. The configuration required to achieve this is provided below.

Note: The filter-list would be required on both R7 and R3. This is because R7 does not filter R9’s loopback INTO area 0. Meaning area 0 can still learn the prefix and route to it. It simply stops this prefix from leaving area 0.

R7(config)#ip prefix-list R9_LOOPBACK seq 5 deny 150.1.9.9/32
R7(config)#ip prefix-list R9_LOOPBACK seq 10 permit 0.0.0.0/0 le 32
R7(config)#!
R7(config)#router ospf 1
R7(config-router)#area 0 filter-list prefix R9_LOOPBACK out
R3(config)#ip prefix-list R9_LOOPBACK seq 5 deny 150.1.9.9/32
R3(config)#ip prefix-list R9_LOOPBACK seq 10 permit 0.0.0.0/0 le 32
R3(config)#!
R3(config-router)#area 0 filter-list prefix R9_LOOPBACK out

Result:

—————————————————————
R1#sh ip ospf da | i Summ|150.1.9
Summary Net Link States (Area 1)
—————————————————————
R2#sh ip ospf da | i Summ|150.1.9
Summary Net Link States (Area 3)
—————————————————————
R3#sh ip ospf da | i Summ|150.1.9
Summary Net Link States (Area 0)
150.1.9.9 7.7.7.7 412 0x80000001 0x005B1A
Summary Net Link States (Area 1)
Summary Net Link States (Area 3)

R3#ping 150.1.9.9
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.9.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/84/116 ms