OSPF Multi-Area Design and Troubleshooting for CCIE Enterprise

Introduction

Imagine you are managing a large enterprise network spanning dozens of sites, hundreds of routers, and thousands of subnets. A single OSPF area would buckle under the weight of its own link-state database, flooding every topology change to every router in the domain. This is precisely why OSPF multi-area design exists — and why mastering it is non-negotiable for anyone pursuing the CCIE Enterprise Infrastructure certification.

OSPF multi-area architecture is one of the most heavily tested topics on the CCIE Enterprise lab exam. It demands not just theoretical knowledge, but the ability to configure, verify, and troubleshoot complex topologies that include stub areas, not-so-stubby areas (NSSA), virtual links, inter-area route summarization, external route summarization, LSA filtering, and redistribution. Each of these features interacts with the others in ways that can surprise even experienced engineers.

In this article, we will walk through every major aspect of OSPF multi-area design and troubleshooting. You will see real configuration examples drawn from lab environments, learn how each area type controls LSA propagation, understand when and how to deploy virtual links, and discover the techniques used to filter and summarize routes at area boundaries. Whether you are building your first multi-area topology or refining your skills for the CCIE lab, this guide will give you the depth you need.

If you are looking to build a strong OSPF foundation before diving into multi-area concepts, consider starting with the OSPF Single-Area Lab Course on NHPREP.

What Is OSPF Multi-Area Design and Why Does It Matter?

OSPF was designed from the ground up to support hierarchical routing through the use of areas. A single-area OSPF deployment works well for small networks, but as the number of routers and prefixes grows, the link-state database (LSDB) becomes large, SPF calculations become expensive, and every topology change triggers flooding across the entire domain.

OSPF multi-area design solves these problems by partitioning the network into logical areas. Each area maintains its own LSDB, and Area Border Routers (ABRs) sit at the boundary between areas, controlling which routing information crosses from one area to another. This hierarchy delivers three critical benefits:

1. Reduced SPF computation — topology changes within one area do not trigger SPF recalculation in other areas.
2. Smaller link-state databases — each router only needs to store the full topology of its own area, plus summary information from other areas.
3. Controlled route propagation — ABRs can summarize, filter, and manipulate routes as they cross area boundaries.

At the center of every OSPF multi-area design sits Area 0, the backbone area. Every other area must have a logical connection to Area 0, either through a direct physical connection or through a virtual link. This backbone-centric design is fundamental to how OSPF prevents routing loops in a multi-area environment.

A typical CCIE-level OSPF topology might include:

Component	Role
Area 0	Backbone area connecting all other areas
Area 10, 20, 30	Non-backbone areas for different network segments
ABRs (e.g., R2, R4)	Routers connecting two or more areas
ASBRs (e.g., R9)	Routers redistributing external routes into OSPF
Virtual Links	Logical tunnels through transit areas to reach Area 0

Understanding each of these components and how they interact is the foundation of OSPF multi-area troubleshooting.

How to Configure a Multi-Area OSPF Topology

Building a multi-area OSPF topology starts with careful planning of area assignments, router IDs, and network statements. Let us walk through the configuration of a multi-area topology with Area 0, Area 10, Area 20, and Area 30.

Configuring Area 0 — The Backbone

Area 0 is the backbone and must be configured first. In this example, R1 and R2 are both in Area 0, with their loopback interfaces and the physical link between them enabled for OSPF. Notice the use of hard-coded router IDs — this is a best practice that prevents unexpected DR/BDR elections and makes troubleshooting much easier.

! R1 Configuration
router ospf 1
 router-id 0.0.0.1
 network 1.0.0.0 0.255.255.255 area 0
 network 192.1.12.0 0.0.0.255 area 0
!
interface Loopback0
 ip ospf network point-to-point

! R2 Configuration
router ospf 1
 router-id 0.0.0.2
 network 2.0.0.0 0.255.255.255 area 0
 network 192.1.12.0 0.0.0.255 area 0
!
interface Loopback0
 ip ospf network point-to-point

Pro Tip: Always configure loopback interfaces with ip ospf network point-to-point. By default, OSPF treats loopbacks as stub host routes (/32). Changing the network type to point-to-point ensures the loopback is advertised with its configured subnet mask, which is essential for accurate routing in a lab or production environment.

Configuring Area 10

Area 10 connects R2, R3, and R4. R2 serves as the ABR between Area 0 and Area 10. Each router gets a hard-coded router ID, and loopback interfaces are enabled with the point-to-point network type.

! R2 (ABR) — Adding Area 10
router ospf 1
 network 192.1.23.0 0.0.0.255 area 10

! R3 Configuration
router ospf 1
 router-id 0.0.0.3
 network 3.0.0.0 0.255.255.255 area 10
 network 192.1.23.0 0.0.0.255 area 10
 network 192.1.34.0 0.0.0.255 area 10
!
interface Loopback0
 ip ospf network point-to-point

! R4 Configuration
router ospf 1
 router-id 0.0.0.4
 network 192.1.34.0 0.0.0.255 area 10
!
interface Loopback0
 ip ospf network point-to-point

Configuring Area 20

Area 20 connects R4 and R5. Here, R4 acts as an ABR between Area 10 and Area 20. Note that R4's loopback is placed in Area 20, and both R4 and R5 have their loopbacks advertised with the interface mask.

! R4 (ABR) — Adding Area 20
router ospf 1
 network 192.1.45.0 0.0.0.255 area 20
 network 4.0.0.0 0.255.255.255 area 20
!
interface Loopback0
 ip ospf network point-to-point

! R5 Configuration
router ospf 1
 router-id 0.0.0.5
 network 5.0.0.0 0.255.255.255 area 20
 network 192.1.45.0 0.0.0.255 area 20
!
interface Loopback0
 ip ospf network point-to-point

Configuring Area 30

Area 30 extends the topology further with R5 and R6. R5 has a second loopback (Loopback 1 with address 55.55.55.55) placed in Area 30.

! R5 — Adding Area 30
router ospf 1
 network 192.1.56.0 0.0.0.255 area 30
 network 55.0.0.0 0.255.255.255 area 30
!
interface Loopback1
 ip ospf network point-to-point

! R6 Configuration
router ospf 1
 router-id 0.0.0.6
 network 6.0.0.0 0.255.255.255 area 30
 network 192.1.56.0 0.0.0.255 area 30
!
interface Loopback0
 ip ospf network point-to-point

This topology now has four areas (0, 10, 20, 30), but Area 20 and Area 30 are not directly connected to the backbone. This is where virtual links become essential.

OSPF Virtual Links: Connecting Disconnected Areas to the Backbone

Every non-backbone area in OSPF must have a connection to Area 0. When an area cannot be physically connected to the backbone — for example, when it sits behind another non-backbone area — a virtual link provides a logical tunnel through a transit area to reach Area 0.

When Are Virtual Links Needed?

In our topology, Area 20 is connected to Area 10 through R4, but Area 20 has no direct connection to Area 0. Similarly, Area 30 connects through Area 20 and is even further removed from the backbone. Without virtual links, routers in Area 20 and Area 30 would be unable to exchange routes with the rest of the OSPF domain.

Configuring a Virtual Link Through Area 10

To connect Area 20 to the backbone, a virtual link must be established through Area 10 between R2 (which is already in Area 0) and R4 (which bridges Area 10 and Area 20). The virtual link uses the router IDs of the endpoints.

! R2 — Virtual Link through Area 10
router ospf 1
 area 10 virtual-link 0.0.0.4

! R4 — Virtual Link through Area 10
router ospf 1
 area 10 virtual-link 0.0.0.2

Once this virtual link is established, R4 becomes a virtual ABR with a logical connection to Area 0. Routes from Area 20 can now reach the backbone.

Configuring a Virtual Link Through Area 20

Area 30 also needs a path to the backbone. A second virtual link is configured through Area 20 between R4 and R5.

! R4 — Virtual Link through Area 20
router ospf 1
 area 20 virtual-link 0.0.0.5

! R5 — Virtual Link through Area 20
router ospf 1
 area 20 virtual-link 0.0.0.4

Pro Tip: Virtual links are configured using the router ID of the far-end router, not its IP address. If you are troubleshooting a virtual link that will not come up, the first thing to verify is that the router IDs match on both sides. Use show ip ospf virtual-links to check the state.

OSPF Multi-Area Virtual Link Troubleshooting Checklist

Issue	What to Check
Virtual link stays down	Verify router IDs match on both endpoints
Transit area mismatch	Ensure both routers reference the same transit area
No OSPF adjacency in transit area	Check that OSPF is fully converged in the transit area
Stub area used as transit	Virtual links cannot traverse stub or NSSA areas

That last point is critical: virtual links cannot pass through stub areas or NSSA areas. The transit area must be a standard OSPF area. This constraint frequently appears in CCIE lab scenarios designed to test your understanding of area type interactions.

OSPF Stub Area Types: Controlling LSA Propagation in Multi-Area Designs

One of the most powerful features of OSPF multi-area design is the ability to control which types of LSAs are allowed into an area. OSPF defines several special area types — stub, totally stubby, NSSA, and NSSA totally stubby — each of which restricts LSA propagation in a different way.

Understanding these area types is essential for both OSPF design and OSPF troubleshooting at the CCIE level.

Stub Area

A stub area blocks all Type 5 LSAs (external routes) from entering the area. The ABR instead injects a default route so that internal routers can still reach external destinations. All routers within the area must agree on the stub configuration.

! R2 (ABR) — Configure Area 10 as Stub
router ospf 1
 area 10 stub

! R4 — Must also be configured as Stub
router ospf 1
 area 10 stub

! R10 — Internal router in Area 10
router ospf 1
 area 10 stub

! R11 — Internal router in Area 10
router ospf 1
 area 10 stub

The ABR (R2) blocks external routes — such as those redistributed from EIGRP 111 and EIGRP 222 — from reaching Area 10's internal routers. Instead, R2 injects a default route into the area. You can verify this on R4, R10, and R11 by checking the routing table with show ip route.

Totally Stubby Area

A totally stubby area takes the stub concept one step further. In addition to blocking Type 5 LSAs (external routes), it also blocks Type 3 LSAs (inter-area routes). The only route injected into the area by the ABR is a single default route. This dramatically reduces the size of the routing table for internal routers.

The no-summary keyword is only configured on the ABR:

! R2 (ABR) — Configure Area 10 as Totally Stubby
router ospf 1
 area 10 stub no-summary

The internal routers (R4, R10, R11) retain the basic area 10 stub configuration. The no-summary keyword on the ABR blocks inter-area routes from propagating into Area 10, and R2 injects a default route instead.

Pro Tip: In a totally stubby area, internal routers only see their own intra-area routes and a default route. This is ideal for spoke sites in a hub-and-spoke topology where all traffic exits through a single ABR.

NSSA (Not-So-Stubby Area)

An NSSA is designed for areas that need to block external routes from the backbone but still need to originate their own external routes locally. External routes generated within the NSSA are carried as Type 7 LSAs (N routes), which the ABR converts to Type 5 LSAs (E routes) when propagating them into the backbone.

! R3 (ABR) — Configure Area 20 as NSSA
router ospf 1
 area 20 nssa

! R5 — Internal router in Area 20
router ospf 1
 area 20 nssa

! R6 — Internal router in Area 20
router ospf 1
 area 20 nssa

With this configuration, external routes from the backbone (such as those from EIGRP redistributed elsewhere) are blocked from entering Area 20. However, external routes originating within Area 20 — for example, from EIGRP 222 redistributed on R6 — continue to be received as N routes. The ABR (R3) converts these N routes to E routes as it propagates them into the backbone.

Important: In a basic NSSA configuration, the ABR does not inject a default route. This means routers inside Area 20 will lose reachability to the backbone's external routes. This is a common troubleshooting trap in the CCIE lab.

NSSA with Default Route Injection

To restore reachability to external routes from the backbone, configure the ABR to inject a default route into the NSSA using the default-information-originate keyword:

! R3 (ABR) — NSSA with Default Route
router ospf 1
 area 20 nssa default-information-originate

This builds on the NSSA configuration by having the ABR inject a default route into Area 20, restoring reachability to the backbone's external routes while still blocking Type 5 LSAs from entering the area.

NSSA Totally Stubby Area

The most restrictive NSSA variant blocks both external routes from the backbone and inter-area routes. Only intra-area routes and locally originated Type 7 LSAs remain, along with a default route from the ABR.

! R3 (ABR) — NSSA Totally Stubby
router ospf 1
 area 20 nssa no-summary

OSPF Area Types Comparison Table

Area Type	Type 3 LSAs (Inter-Area)	Type 5 LSAs (External)	Type 7 LSAs (NSSA External)	Default Route
Standard	Allowed	Allowed	N/A	Not automatic
Stub	Allowed	Blocked	Not allowed	Injected by ABR
Totally Stubby	Blocked	Blocked	Not allowed	Injected by ABR
NSSA	Allowed	Blocked	Allowed (local)	Not automatic
NSSA + default-information-originate	Allowed	Blocked	Allowed (local)	Injected by ABR
NSSA Totally Stubby	Blocked	Blocked	Allowed (local)	Injected by ABR

This table is one of the most important references for OSPF multi-area troubleshooting. When routes are missing from a routing table, the first question should always be: "What area type is this router in, and which LSA types are being filtered?"

For hands-on practice with these area types, the Multi-Area OSPF Lab Course on NHPREP provides step-by-step lab exercises.

OSPF Route Redistribution and ASBR Configuration

In enterprise networks, OSPF rarely runs in isolation. It must coexist with other routing protocols such as EIGRP and BGP. The router that performs redistribution between OSPF and another protocol is called an Autonomous System Boundary Router (ASBR).

Configuring Mutual Redistribution Between OSPF and EIGRP

In this example, R9 sits at the boundary between OSPF and EIGRP AS 111. EIGRP is configured between R9 and R10, while OSPF runs on R9's other interfaces.

First, configure EIGRP between R9 and R10:

! R9 — EIGRP Configuration
router eigrp 111
 network 192.1.90.0
 network 9.0.0.0

! R10 — EIGRP Configuration
router eigrp 111
 network 192.1.90.0
 network 10.0.0.0

Then configure mutual redistribution on R9:

! R9 — Mutual Redistribution
router eigrp 111
 redistribute ospf 1 metric 10 10 10 10 10
!
router ospf 1
 redistribute eigrp 111 subnets

When redistributing into OSPF, the subnets keyword is critical. Without it, only classful networks are redistributed, which almost never produces the desired result. When redistributing into EIGRP, you must provide seed metrics (bandwidth, delay, reliability, load, and MTU) — here all set to 10 as a baseline.

After redistribution, verify the OSPF database to ensure the appropriate LSAs have been generated. External routes redistributed into OSPF appear as Type 5 LSAs in the OSPF database and show up as O E1 or O E2 routes in the routing table.

Pro Tip: After configuring redistribution, always verify the OSPF database on key routers using show ip ospf database. Look for Type 5 LSAs (AS External) on routers in standard areas, and Type 7 LSAs on routers in NSSA areas. If expected LSAs are missing, check area type restrictions and redistribution configuration.

OSPF Multi-Area Inter-Area Route Summarization

Route summarization at area boundaries is one of the most effective techniques for reducing routing table size and improving OSPF convergence. In OSPF, inter-area summarization is performed on ABRs using the area range command.

Summarizing Loopback Networks at the ABR

Consider a scenario where R10 has four loopback interfaces (Loopbacks 11-14) in Area 10, and you want to summarize them as they are advertised into Area 0. The summarization is configured on the ABR (R2):

! R2 (ABR) — Summarize R10 Loopbacks
router ospf 1
 area 10 range 100.0.0.0 252.0.0.0

Similarly, to summarize R4's four loopback interfaces (Loopbacks 11-14):

! R2 (ABR) — Summarize R4 Loopbacks
router ospf 1
 area 10 range 105.1.4.0 255.255.252.0

The area range command tells the ABR to advertise a single summary route for all the component routes that fall within the specified range, instead of advertising each individual prefix. This reduces the number of Type 3 LSAs that the ABR generates and sends into Area 0.

Key Points for OSPF Multi-Area Route Summarization

• The area range command is configured on the ABR, not on internal routers.
• The area number in the command refers to the source area — the area where the component routes originate.
• The ABR creates a summary route and suppresses the individual component routes.
• If any component route within the range exists in the routing table, the summary is advertised.
• Proper subnet mask calculation is essential. An incorrect mask will either summarize too many prefixes (causing reachability issues) or too few (defeating the purpose).

Summarization Type	Command	Where Configured
Inter-area (Type 3)	area [area-id] range [network] [mask]	ABR
External (Type 5/7)	summary-address [network] [mask]	ASBR

OSPF LSA Type 3 Filtering for Multi-Area Route Control

Beyond summarization, OSPF provides the ability to filter specific routes from being advertised across area boundaries. This is done using prefix lists combined with the area filter-list command on the ABR.

Filtering a Specific Network from Leaving an Area

Suppose you want to prevent the network 4.0.0.0/8 from being advertised out of Area 10. This is accomplished with an LSA Type 3 filter on the ABR (R2):

! R2 (ABR) — LSA Type 3 Filtering
ip prefix-list FILTER1 deny 4.0.0.0/8
ip prefix-list FILTER1 permit 0.0.0.0/0 le 32
!
router ospf 1
 area 10 filter-list prefix FILTER1 out

The prefix list FILTER1 explicitly denies the 4.0.0.0/8 network and permits all other prefixes. The area 10 filter-list prefix FILTER1 out command applies this filter to Type 3 LSAs leaving Area 10.

Filter Direction Matters

The filter-list command supports two directions:

• out — filters routes as they leave the specified area (prevents the ABR from generating Type 3 LSAs for matched routes into other areas)
• in — filters routes as they enter the specified area (prevents the ABR from installing Type 3 LSAs into the specified area)

This distinction is important in topologies with multiple ABRs, where you may need to control route propagation in a specific direction.

Pro Tip: LSA Type 3 filtering is one of the most commonly tested OSPF troubleshooting topics on the CCIE lab. If a route is missing from a remote area's routing table, check for filter lists on all ABRs in the path. Use show ip ospf database summary on the ABR to see if the Type 3 LSA is being generated.

OSPF Multi-Area Troubleshooting: A Systematic Approach

Troubleshooting OSPF multi-area networks requires a methodical approach. Problems can originate from misconfigured area types, missing virtual links, incorrect summarization, or filtering issues. Here is a systematic framework for OSPF troubleshooting at the CCIE level.

Step 1: Verify OSPF Adjacencies

Before looking at routes, confirm that all OSPF neighbor adjacencies are in the FULL state. In multi-access networks, adjacencies should be FULL with the DR and BDR, and 2WAY with other routers.

show ip ospf neighbor

Step 2: Check Area Assignments

A common misconfiguration is placing an interface in the wrong area. Verify that each interface is assigned to the correct area:

show ip ospf interface brief

Step 3: Examine the OSPF Database

The link-state database is the single source of truth for OSPF. Check it on key routers to understand what LSAs are present:

show ip ospf database

Look for:

• Type 1 (Router LSAs) — should exist for every router in the area
• Type 2 (Network LSAs) — generated by the DR on multi-access segments
• Type 3 (Summary LSAs) — generated by ABRs, should exist for inter-area routes
• Type 5 (AS External LSAs) — generated by ASBRs, present in all standard areas
• Type 7 (NSSA External LSAs) — present only in NSSA areas

Step 4: Verify Area Type Configuration

If expected routes are missing, check the area type on the local router and the ABR:

show ip ospf

This shows whether the area is configured as standard, stub, totally stubby, or NSSA. Remember:

• Stub areas block Type 5 LSAs
• Totally stubby areas block Type 3 and Type 5 LSAs
• NSSA areas block Type 5 LSAs but allow Type 7
• All routers in the area must agree on the area type

Step 5: Check Virtual Links

If an area is not directly connected to Area 0, verify the virtual link status:

show ip ospf virtual-links

The virtual link should show as up with a FULL adjacency. If it is down, verify:

• Both endpoints reference the correct transit area
• Both endpoints use the correct router ID of the remote end
• The transit area is not a stub or NSSA area
• OSPF is fully converged in the transit area

Step 6: Look for Route Summarization and Filtering

If a specific route is missing but others from the same area are present, check for:

• area range commands that may be suppressing individual routes
• area filter-list commands that may be blocking specific prefixes
• Prefix lists applied to the OSPF process

Common OSPF Multi-Area Troubleshooting Scenarios

Symptom	Likely Cause	Verification Command
No routes from remote area	Virtual link down or missing	show ip ospf virtual-links
No external routes	Area configured as stub/NSSA	show ip ospf
No inter-area routes	Area configured as totally stubby	show ip ospf database summary
Specific route missing	LSA filtering on ABR	Check prefix lists and filter-list config
Suboptimal routing	Missing or incorrect summarization	show ip route ospf
Neighbor stuck in INIT	MTU mismatch or area type mismatch	show ip ospf interface

OSPF Multi-Area Design Best Practices for CCIE

Designing a robust OSPF multi-area network requires balancing scalability, convergence speed, and operational simplicity. Here are the best practices drawn from real-world CCIE-level topologies.

Hard-Code Router IDs

Always configure router IDs explicitly using the router-id command. This prevents router ID changes when interfaces go up or down, and it makes virtual link configuration and troubleshooting predictable.

router ospf 1
 router-id 0.0.0.1

Use Point-to-Point Network Type on Loopbacks

Configure all loopback interfaces with ip ospf network point-to-point to ensure they are advertised with their configured subnet mask rather than as /32 host routes.

interface Loopback0
 ip ospf network point-to-point

Summarize at Every ABR

Use area range commands on ABRs to summarize routes from each area. Proper summarization reduces the number of Type 3 LSAs, shrinks routing tables in remote areas, and limits the blast radius of topology changes.

Choose Area Types Deliberately

Select the appropriate area type based on each area's requirements:

• Use stub areas for areas that do not need external route details but need inter-area routes.
• Use totally stubby areas for spoke sites where a default route to the ABR is sufficient.
• Use NSSA areas where local redistribution is needed but backbone external routes should be blocked.
• Use NSSA with default-information-originate when NSSA routers also need reachability to backbone external routes.
• Use NSSA totally stubby for maximum route reduction while still allowing local redistribution.

Plan Virtual Links Carefully

Virtual links should be treated as a temporary or architectural necessity, not a design preference. When possible, restructure the physical topology so that every area has a direct connection to Area 0. If virtual links are required, document them thoroughly and remember that they cannot traverse stub or NSSA areas.

Frequently Asked Questions

What is the difference between a stub area and a totally stubby area in OSPF?

A stub area blocks Type 5 LSAs (external routes) from entering the area, but it still allows Type 3 LSAs (inter-area routes). The ABR injects a default route so internal routers can reach external destinations. A totally stubby area goes further by also blocking Type 3 LSAs. The ABR injects only a single default route, so internal routers see only their own intra-area routes and the default. Totally stubby areas are configured by adding no-summary to the area stub command on the ABR, while internal routers keep the basic area stub configuration.

Why does my OSPF virtual link not come up?

The most common reasons for a virtual link failure are: (1) the router IDs specified in the area virtual-link command do not match the actual router IDs of the endpoints; (2) the transit area number is incorrect or does not match on both sides; (3) the transit area is configured as a stub or NSSA area, which cannot support virtual links; or (4) OSPF adjacency within the transit area itself is not fully converged. Use show ip ospf virtual-links to check the current state and verify the configuration on both endpoints.

What is the difference between NSSA and a standard stub area?

A standard stub area blocks external routes (Type 5 LSAs) from the backbone and does not support any form of route redistribution within the area. An NSSA also blocks Type 5 LSAs from the backbone, but it allows routers within the area to perform local redistribution. These locally redistributed routes are carried as Type 7 LSAs within the NSSA, and the ABR converts them to Type 5 LSAs when propagating them into the backbone. Importantly, in a basic NSSA configuration, the ABR does not automatically inject a default route — you must add default-information-originate to the NSSA configuration on the ABR if internal routers need reachability to the backbone's external routes.

How does OSPF inter-area route summarization work?

Inter-area route summarization is configured on ABRs using the area range command. The command specifies a network address and mask that encompasses multiple component routes from a given area. When the ABR has any component route within the specified range in its routing table, it advertises a single summary Type 3 LSA instead of individual Type 3 LSAs for each component route. This reduces the size of the LSDB and routing tables in remote areas. The area number in the area range command refers to the source area where the component routes originate.

How do I filter a specific OSPF route from being advertised to another area?

You can filter specific routes from crossing area boundaries using the area filter-list command combined with a prefix list. Create a prefix list that denies the route you want to filter and permits all others (with permit 0.0.0.0/0 le 32). Then apply the filter list on the ABR with area [area-id] filter-list prefix [prefix-list-name] out to block the route from leaving the specified area, or use in to block it from entering the area. This filters Type 3 LSAs and is one of the most precise route control mechanisms available in OSPF.

Can I run OSPF and EIGRP on the same router?

Yes. A router that runs both OSPF and another routing protocol such as EIGRP is called an ASBR (Autonomous System Boundary Router). Mutual redistribution is configured by adding redistribute commands under each routing protocol process. When redistributing into OSPF, always include the subnets keyword to ensure subnetted routes are included. When redistributing into EIGRP, you must specify seed metrics (bandwidth, delay, reliability, load, and MTU). After configuring redistribution, verify the OSPF database for the appropriate external LSAs.

Conclusion

OSPF multi-area design is a cornerstone of enterprise networking and one of the most critical skills tested on the CCIE Enterprise Infrastructure exam. In this article, we covered the complete lifecycle of OSPF multi-area deployment: building the backbone in Area 0, extending the topology with non-backbone areas, bridging disconnected areas with virtual links, controlling LSA propagation with stub and NSSA area types, reducing routing table size with inter-area summarization, filtering specific routes with prefix lists, and performing mutual redistribution between OSPF and EIGRP.

The key takeaways are:

1. Every area must connect to Area 0 — directly or through a virtual link via a standard transit area.
2. Area types control LSA flooding — stub blocks Type 5, totally stubby blocks Types 3 and 5, NSSA allows local Type 7 while blocking Type 5 from the backbone.
3. Summarization and filtering on ABRs reduce routing table size and give you precise control over route propagation.
4. Hard-coded router IDs and point-to-point loopbacks are non-negotiable best practices.
5. Systematic troubleshooting starts with adjacencies, moves through area assignments and database verification, and checks for virtual links, summarization, and filtering.

To build hands-on proficiency with these concepts, start with the OSPF Single-Area Lab Course to solidify your foundation, then advance to the Multi-Area OSPF Lab Course for guided practice with the exact configurations and scenarios covered in this article. Consistent lab practice is the fastest path to mastering OSPF multi-area design and troubleshooting for the CCIE Enterprise exam.