Hands-On Lab: Configuring OSPF Type 3 LSA Filtering

This hands-on lab configures Type 3 LSA filtering at an ABR to selectively block specific inter-area routes from propagating into a neighboring area, achieving more granular control than the all-or-nothing summarization or stub area behaviors covered earlier in this series.

OSPF Type 3 LSA FilteringABR Area FilterSelective Inter-Area Route Control

~4 min read · Updated Sep 27, 2026

Lab Objective

Configure an OSPF ABR to filter a specific Type 3 LSA from propagating into a neighboring area while allowing other inter-area routes through normally, verifying selective route control at a granularity neither full summarization nor stub area configuration can achieve.

Lab Purpose

Area summarization, covered earlier in this series, aggregates multiple routes into one, and stub areas block entire categories of LSAs wholesale. Neither mechanism allows blocking one specific inter-area route while permitting others through unchanged — Type 3 LSA filtering fills this gap, offering ACL-like precision at the area boundary itself.

Lab Topology

R1 (Area 1) ---- R2 (ABR) ---- R3 (Area 0)

R1 has two LANs in Area 1:
192.168.70.0/24 (should reach Area 0 normally)
192.168.71.0/24 (should be BLOCKED from
                  reaching Area 0)

Task 1: Verify Both Routes Currently Reach Area 0

Confirm R3 in Area 0 currently sees both of R1's LANs as Type 3 inter-area routes.

Task 2: Configure a Prefix List Matching the Route to Block

Create a prefix list specifically matching 192.168.71.0/24.

Task 3: Apply Type 3 LSA Filtering on the ABR

Apply the prefix list as an outbound Type 3 LSA filter on R2 toward Area 0.

Task 4: Verify the Filtered Route No Longer Reaches Area 0

Confirm R3 no longer sees 192.168.71.0/24, while 192.168.70.0/24 continues appearing normally.

Task 5: Verify R1's LAN Remains Reachable Locally Within Area 1

Confirm devices within Area 1 itself can still reach 192.168.71.0/24, since the filter only affects propagation into Area 0.

Solution and Verification

R3# show ip route ospf

O IA  192.168.70.0/24 [110/65] via 10.2.2.1
O IA  192.168.71.0/24 [110/65] via 10.2.2.1
-- Both routes currently reach Area 0 as
-- standard inter-area entries

R2(config)# ip prefix-list BLOCK-71 seq 5 permit 192.168.71.0/24
R2(config)# ip prefix-list BLOCK-71 seq 10 deny 0.0.0.0/0 le 32

-- Only the specific /24 is permitted here
-- for filtering purposes -- this prefix
-- list is inverted in usage compared to a
-- typical "permit what should pass" list,
-- since area filter-list's own permit/deny
-- keyword determines the actual action

R2(config)# router ospf 1
R2(config-router)# area 1 filter-list prefix BLOCK-71 out

-- "out" direction filters LSAs leaving
-- Area 1 toward other areas -- the prefix
-- list identifies which specific routes
-- this filter-list statement matches, and
-- since the filter-list is a "deny"-style
-- mechanism by nature, matched routes
-- (192.168.71.0/24) are blocked from
-- propagating

R3# show ip route ospf

O IA  192.168.70.0/24 [110/65] via 10.2.2.1
-- 192.168.71.0/24 has disappeared entirely
-- from Area 0's routing table, while
-- 192.168.70.0/24 continues propagating
-- completely unaffected

R1# ping 192.168.71.1

!!!!!
Success rate is 100 percent (5/5)
-- (pinged from another device within
--  Area 1 itself)
-- Local reachability within Area 1 is
-- completely unaffected -- the filter
-- only blocks the route's Type 3 LSA
-- specifically at the Area 1-to-Area 0
-- boundary, not the network's actual
-- existence or accessibility within its
-- own area

Key Takeaway

Type 3 LSA filtering with area filter-list operates with prefix-list precision at exactly the area boundary, blocking selected inter-area routes individually while leaving every other route through that same ABR completely unaffected — a level of granularity neither area range summarization nor the stub area family covered earlier in this series was designed to provide, making it the correct tool whenever specific routes need to be selectively withheld from a neighboring area for policy reasons rather than aggregated or blocked wholesale.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

Continue

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

Continue

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

Continue

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

Continue

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

Continue

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

Continue