Short answer: OSPF summarization replaces multiple reachable networks with a less-specific advertisement at a routing boundary. Use area range on an ABR for inter-area summaries and summary-address on an ASBR for redistributed external routes; neither command compresses an area's internal topology database.[3][4]
A summary is a reachability promise, not proof that every covered subnet exists. This guide uses an original two-ABR example to show how summarization can reduce routing detail while concealing a failure.[1]
ABR area range versus ASBR summary-address
An Area Border Router connects OSPF areas.[1] Its inter-area summaries are Type 3 LSAs: routers in another area learn a network and an advertised cost rather than the source area's full topology.[1] A router inside the source area still needs the area's Type 1 and Type 2 LSAs; configuring a range does not eliminate them.[1][3]
An Autonomous System Boundary Router introduces external routes into OSPF.[1] External summarization is a separate operation on the originating external advertisements, not an area range function.[3][4] FRRouting documents summary-address for originated Type 5 and Type 7 LSAs; NSSA translation and platform support require separate checking.[3][4]
Decision rule: summarizing native area networks at their boundary calls for an ABR range.[3][4] Summarizing routes redistributed from another routing domain calls for external summarization at the ASBR.[3][4] Do not enable redistribution merely to make native OSPF networks summarizable.[3][4]
Worked topology: four subnets behind two ABRs
Our proposed lab has a backbone router CORE and two border routers, ABR-A and ABR-B. Both ABRs attach to Area 0 and Area 10. Area 10 owns these application networks:
10.20.0.0/24
10.20.1.0/24
10.20.2.0/24
10.20.3.0/24
CORE -- Area 0 -- ABR-A -- Area 10 -- application networks
\-- ABR-B -- Area 10 -- same application networks
Planned summary: 10.20.0.0/22
This address plan is deliberately aligned: the /22 covers exactly those four /24 blocks. It does not cover 10.20.4.0/24. The accompanying local verification script checks coverage and the forwarding examples; it is a Python model, not a router lab.
Before summarization, record reachability to all four networks from each ABR. For the proposed design, both border routers must retain forwarding access to every live subnet they claim through the aggregate, including after the failures the design is meant to survive.
Cisco-style ABR configuration
The following proposed OSPFv2 configuration assumes working adjacencies and existing interface addressing. Interface names are placeholders. area 10 identifies the area whose networks are summarized, not the area receiving the summary; Cisco documents summarization at the area boundary.[2][4]
! ABR-A: existing Area 0 and Area 10 attachments
interface GigabitEthernet0/0
ip ospf 100 area 0
!
interface GigabitEthernet0/1
ip ospf 100 area 10
!
router ospf 100
router-id 192.0.2.10
area 10 range 10.20.0.0 255.255.252.0 cost 50
For the illustrative backup ABR, use the same range with an explicit higher advertised metric:
! ABR-B: its Area 0/10 interfaces are already configured
router ospf 100
router-id 192.0.2.20
area 10 range 10.20.0.0 255.255.252.0 cost 100
These are candidate configurations, not captured running configurations. Validate syntax and feature support against your exact IOS/IOS XE release before applying them. Explicit summary cost avoids relying on the default derived metric; the standard and FRRouting describe that default as the highest cost among the component networks.[1][3]
Do not confuse suppression with aggregation. The not-advertise option suppresses the matching networks' inter-area advertisement instead of publishing an ordinary reachable summary.[2][3] It is not a harmless synonym for hiding only the specifics.[2][3]
FRRouting equivalent
FRRouting 10.2 documents CIDR syntax for ABR ranges and supports an explicit summary cost. With Area 0 and Area 10 already enabled on the intended interfaces, the equivalent range configuration is:[3]
router ospf
ospf router-id 192.0.2.10
area 0.0.0.10 range 10.20.0.0/22 cost 50
Do not copy Cisco dotted-mask syntax into FRRouting. For redistributed external networks, FRRouting instead documents this separate command under the OSPF process:[3]
! Separate ASBR example, not an addition required on the ABRs above
router ospf
summary-address 198.51.100.0/24
That external example assumes eligible more-specific routes are already deliberately redistributed.[3] It does not originate the component routes by itself.[3] Keep redistribution tightly scoped and test route withdrawal separately from ABR summarization.[3]
Packet walkthrough and traffic-control limits
Assume CORE has an OSPF cost of 10 to ABR-A and 20 to ABR-B, and both summary advertisements are eligible inter-area candidates. Under those assumptions, the modeled totals are 60 through A and 120 through B. CORE selects A for a destination such as 10.20.2.42; A then uses its more-specific Area 10 route to reach the application network. OSPF inter-area calculation adds the cost to the advertising ABR to the summary metric.[1]
Inbound toward Area 10: changing the advertised summary costs can influence which ABR other areas use.[1] The result depends on each deciding router's cost to the ABRs and other eligible routes, not merely which ABR advertises the lower number.[1]
Outbound from Area 10: this range summarizes destinations inside Area 10.[1][3] It does not directly choose how an application router leaves Area 10 for a remote server.[1] That decision needs inspection of the routes and costs advertised toward the application side.[1] Reverse traffic can therefore follow a different path; do not infer symmetry from the forward-path result.[1]
What it cannot control: a summary is destination-based routing information, not application classification or per-flow policy.[1] A more-specific forwarding entry can override the aggregate through longest-prefix matching.[1] OSPF path-type preference also matters when comparing alternative routes to the same prefix, so a cheaper summary is not a universal override.[1]
Why a summary can blackhole traffic
A range becomes active when it includes at least one network reachable by an intra-area path.[1] It does not require every possible subnet in the block to be reachable.[1] RFC 2328 also specifies discard entries for active ranges so that traffic without a usable more-specific match is not blindly sent back toward the aggregate.[1]
Consider this modeled failure: ABR-A loses access to 10.20.2.0/24 but retains access to 10.20.0.0/24. ABR-B still reaches all four subnets. A can continue advertising the /22 because a component remains reachable. CORE can still prefer A's aggregate, and A may discard traffic to 10.20.2.42 even though B could deliver it.[1]
This failure case assumes A has no other usable route to the destination more specific than its discard entry. Check the actual routing table: an inter-area /24 through another ABR would change the outcome through longest-prefix matching. “One subnet failed” alone is not sufficient evidence of a blackhole.[1]
Cisco installs internal and external summary discard routes by default and provides discard-route controls.[2] Removing the discard route is not a general repair: it does not restore the missing route or make an inaccurate summary truthful. Preserve loop protection and fix topology reachability, address ownership, or the aggregation boundary.[2]
Verification commands and expected logic
On Cisco-style ABRs and CORE, inspect:
show ip ospf
show ip ospf neighbor
show ip ospf database summary
show ip route 10.20.0.0 255.255.252.0
show ip route 10.20.2.42
show ip route ospf
show ip cef 10.20.2.42
The first checks establish roles and adjacency health; the database, routing-table and forwarding-table checks answer different questions. Do not treat an LSA's presence as proof of successful packet delivery. Cisco documents routing-table inspection and its OSPF configuration guide covers monitoring commands.[2][4]
For FRRouting, use the documented OSPF inspection commands alongside route lookup:[3]
show ip ospf
show ip ospf neighbor
show ip ospf database summary
show ip route 10.20.2.42
Expected lab observations, not captured device output: CORE should see Type 3 information for the /22 from each participating ABR and normally prefer the modeled total of 60. The source area's topology detail remains present inside Area 10.[1][3] Each ABR should have usable specific routes for reachable destinations, plus the implementation's aggregate discard protection.[1][2][3]
Our proposed acceptance matrix is:
- Healthy topology: reach a known test host in each of the four /24s.
- Preferred ABR unavailable: confirm the alternate next hop and repeat the tests.
- One component isolated from A only: inspect whether A's aggregate persists and whether A can still deliver through another route.
- Every component withdrawn from one ABR: confirm that ABR withdraws its active range advertisement.
- Unallocated destination within the summary: confirm intentional discard rather than a forwarding loop.
- Return traffic: test separately using an appropriate source address and inspect stateful firewall behavior.
The component and withdrawal expectations follow the active-range rule; the matrix itself is a proposed operational test plan.[1]
Troubleshooting and rollback checklist
- Confirm this is an ABR range problem, not external redistribution or NSSA translation.[3][4]
- Verify the source area number, subnet mask alignment and at least one eligible intra-area component.[1][3]
- Compare advertisements from every ABR. A second border can continue originating specifics if it has no matching range configuration.[1]
- Check the source area's LSDB separately from the destination area's Type 3 LSAs; summarization does not remove source-area topology.[1][3]
- Inspect the exact destination lookup, including competing more-specific routes and discard entries.[1][2]
- Compare full inter-area costs, not advertised summary metrics alone.[1]
- If the change causes failures, remove the exact newly added range on the affected ABR, then verify component advertisements and end-to-end forwarding before proceeding. On the candidate Cisco configuration, the rollback is
no area 10 range 10.20.0.0 255.255.252.0.[2]
Take a pre-change configuration and route snapshot. Roll back one controlled step at a time; never remove the entire area configuration just to undo a range.
Modern use: routed campus, cloud edge and data-center boundaries
A practical design candidate is a routed campus or private-cloud boundary with contiguous application addressing and clear ownership of each aggregate. Summarization can reduce detail exchanged across OSPF areas, but it requires those area boundaries; adding a range inside a single-area underlay does not create aggregation there.[3][4]
For an EVPN/VXLAN deployment, treat an OSPF boundary review separately from overlay route-policy review. The commands in this article operate on OSPF information, not BGP attributes or EVPN route targets; do not present an OSPF summary as a replacement for that separate policy design.[3][4]
Interview answer
OSPF inter-area summarization runs on an ABR with area range; redistributed external-route summarization runs on an ASBR with summary-address.[3][4] Aggregation reduces detail outside the source boundary, not the area's internal topology.[1][3] A summary can remain advertised when only one component survives, so I verify per-subnet reachability, discard routes and partial-failure behavior before calling it safe.[1][3][4]
Summary
Use a summary only where the address plan and failure behavior justify the reachability promise. The reusable checks are simple: know the source area, validate both ABRs, inspect the exact forwarding lookup, test partial failures and preserve a precise rollback.
Related reading
- OSPF cost and reference bandwidth
- OSPF stub, totally stubby and NSSA areas
- OSPF network types
- Networking topic hub
Post a Comment