OSPF and IS-IS both scale link-state routing by limiting how far topology information must be flooded and recalculated. OSPF uses areas; IS-IS uses Level 1 and Level 2 routing. The design question is not which protocol is “more scalable” in isolation, but how well the hierarchy, summarization points, failure domains, and operational practices match the network being built. The current 300-420 ENSLD v1.1 scope continues to test advanced routing design, and Cisco’s 2026 planning guidance still models OSPF areas and IS-IS levels as the primary hierarchy mechanisms.
Large link-state domains fail operationally before they fail mathematically. Excessive adjacencies, unstable links, poorly placed boundaries, and uncontrolled redistribution create churn that every router must process. Good scale design reduces the number of devices that need to react to any single change.
Use hierarchy to contain topology change
In a single OSPF area, participating routers share the area’s link-state database and run SPF when relevant topology changes. Dividing the network into areas lets area border routers summarize or abstract information between domains. Area 0 remains the backbone that connects other OSPF areas.
IS-IS creates a similar hierarchy with Level 1 routing inside an area and Level 2 routing between areas. Level 1/Level 2 routers connect those domains. The terminology differs, but the design purpose is recognizable: local changes should not force every router in the entire network to process the same detail.
Choose boundaries around real failure and administrative domains—campuses, regions, data-center pods, or transport zones—rather than arbitrary router counts. A boundary that cuts through a tightly coupled topology can increase complexity without meaningfully containing failure.
Summarize where the hierarchy naturally changes ownership
Summarization reduces routing-table entries and the amount of topology detail propagated across a boundary. OSPF interarea summaries are normally configured on ABRs. Cisco’s current OSPF scale guidance explicitly notes that interarea summarization can reduce LSA count and conserve network resources.
Summaries must reflect failure behavior. A summary that remains advertised while all component routes are gone can blackhole traffic unless the implementation ties summary generation to component reachability appropriately. Overly broad summaries can also hide the exact location of a failure from troubleshooting tools.
The same design discipline applies to IS-IS. Summarize at stable boundaries, preserve enough specificity for traffic engineering, and avoid producing overlapping aggregates whose longest-match behavior is difficult to predict. The approved discussion of OSPF summarization and filtering is useful because summary design is fundamentally about balancing scale with visibility.
Control adjacency scale and flooding scope
Link-state protocols need neighbor relationships, database synchronization, and flooding. A network with many broadcast segments can create unnecessary neighbor relationships and designated-router activity. Point-to-point links can simplify adjacency behavior where only two routing speakers exist.
IS-IS and OSPF both benefit from stable physical topology. Flapping links generate repeated control-plane work regardless of protocol. Use interface dampening or operational remediation where appropriate rather than trying to solve unstable infrastructure by increasing protocol timers until convergence becomes slow.
Measure the actual control plane: adjacency count, database size, SPF frequency, route count, CPU use, and convergence time. “The protocol supports many routes” does not mean a particular hardware platform should be designed at its maximum theoretical scale.
Design metrics for predictability before optimization
OSPF cost and IS-IS metrics influence shortest-path computation, but metric plans should remain understandable. If every link has a custom metric derived from several historical exceptions, future failure behavior becomes difficult to predict. Start with a simple bandwidth- or role-based convention, then introduce exceptions only for documented traffic-engineering requirements.
Equal-cost multipath can improve resiliency and use parallel links, but ECMP should reflect actual forwarding capability and application tolerance. If parallel paths traverse radically different latency or security domains, equal metrics may create an operational surprise.
Review reference-bandwidth assumptions in OSPF designs so modern high-speed links do not collapse into the same low cost unintentionally. In IS-IS, use a metric style and value range consistent with the platform and design. The objective is not merely reachability; it is deterministic path choice during both normal and failed conditions.
Contain redistribution and external-route churn
External routes can become a major source of scale and instability. OSPF ASBRs inject external LSAs; IS-IS can also carry redistributed prefixes. Keep redistribution points limited, filter what is exported, and summarize where policy allows.
A flapping external prefix should not cause unnecessary internal topology work. Separate internet, WAN, and service-route policy from the IGP whenever possible. The IGP’s primary job is usually to provide stable infrastructure reachability, not to carry every application or external destination directly.
When redistribution is required, use route tags and explicit filters so routes cannot feed back into their source domain. Scale problems and loop-prevention problems often appear together when multiple redistribution points are added for redundancy without a common policy.
Design convergence as a system, not a timer contest
Fast convergence depends on failure detection, SPF scheduling, route installation, and forwarding updates. Aggressively lowering hello/dead timers can increase control-plane load and create false failures on congested links. Technologies such as Bidirectional Forwarding Detection can provide faster failure detection while routing protocols consume the result.
Use fast-reroute capabilities where the platform and design justify them, but validate the backup path and resource cost. A precomputed backup that violates segmentation or oversubscribes a weak link is not a useful resilience mechanism.
Measure convergence from the application’s perspective. Protocol adjacency recovery can occur before the forwarding table, ARP/ND state, or dependent services are fully restored.
Choose OSPF area and IS-IS level patterns deliberately
OSPF offers area types such as stub and NSSA to control which external information appears inside an area. Those choices should reflect whether the area needs external routes, where redistribution occurs, and how default routing is provided. Do not choose an area type only to reduce the database without understanding what routes disappear.
IS-IS Level 1 routers normally rely on Level 1/Level 2 connectivity for destinations outside their area, while Level 2 provides inter-area reachability. Multi-level designs should place L1/L2 routers where they can provide resilient exits without creating unintended suboptimal paths.
In either protocol, the hierarchy should be visible in the physical and operational design. If engineers cannot tell which devices own a boundary or where summaries are generated, the network may be technically hierarchical but operationally flat.
Validate scale with failure tests and telemetry
Before declaring a design scalable, test a representative link failure, node failure, boundary failure, and burst of route changes. Observe adjacency recovery, SPF runs, CPU, route installation time, packet loss, and whether summaries continue to point toward reachable components.
Keep historical telemetry so the team can detect a rising control-plane baseline as the network grows. Database size and SPF frequency may increase gradually long before users report an outage. Capacity planning is easier when the team can see those trends.
OSPF and IS-IS are both mature protocols. Most scale failures come from topology and operations rather than an intrinsic inability of the protocol to route. A well-designed hierarchy makes local change stay local, gives every summary a clear purpose, and leaves enough operational visibility to explain what happens during failure.
Plan growth before the hierarchy reaches its limits
Scaling design should reserve room for new sites, links, and prefixes without forcing a disruptive renumbering or area redesign. Address blocks that align with planned OSPF areas or IS-IS regions make future summarization possible. If addresses are allocated randomly across sites, an engineer may understand the hierarchy perfectly and still be unable to summarize it without advertising huge overlapping ranges.
Growth planning also includes router resources. Track link-state database size, route count, adjacency count, and peak CPU during convergence on the actual platform. A network operating near a platform’s control-plane ceiling can appear healthy during steady state and fail dramatically when a widespread event causes many routes to change together.
Introduce new areas or levels before the existing domain becomes operationally fragile. Moving a boundary after hundreds of sites depend on old assumptions is harder than reserving the hierarchy during initial design. The same applies to authentication, metric conventions, and summarization policy: standards are easiest to enforce before exceptions proliferate.
Finally, document why each boundary exists. If a future team cannot tell whether an area was created for scale, security, geography, or historical convenience, it may remove the wrong boundary or add another one unnecessarily. Scalable routing is partly a protocol problem and partly a knowledge-management problem.
Authentication and control-plane security should scale with the hierarchy. OSPF and IS-IS authentication protect routing adjacencies from unauthorized updates, but key changes must be staged so adjacent routers continue to agree during rotation. A secure design that requires a disruptive all-at-once key change can become an availability problem.
Also decide where default routes belong. Stub-like areas or Level 1 domains can rely on a smaller set of exit information instead of carrying every external prefix. This can reduce state and make failure behavior clearer, provided the exits are redundant and the default does not hide reachability loss behind a black hole.
For designs spanning several vendors or software trains, validate protocol features rather than assuming identical defaults. Metric ranges, authentication options, overload behavior, and fast-reroute capabilities can differ. Interoperability testing should be part of the scale plan when hierarchy boundaries cross platform families.
Route leaking between hierarchy levels should be minimized and documented. A shortcut that bypasses an OSPF area design or an IS-IS level boundary can improve one path while defeating the intended failure containment. If a business requirement needs an exception, model what information will now cross the boundary and whether the same exception must exist redundantly on another router.
Operational simplicity should remain a design metric. Two technically equivalent hierarchies may differ greatly in how easy they are to explain at 3 a.m. Prefer the model that produces obvious ownership of summaries, exits, and redistribution points. Scalable protocols still depend on humans being able to identify where a route should appear and which device is responsible when it does not.
Service-provider designs encounter the same hierarchy and flooding principles in Cisco 350-501 SPCOR, although the scale, MPLS roles, and operational boundaries are different from an enterprise campus or WAN. That cross-track comparison is useful because it reinforces the design principle without implying that an enterprise should copy a provider topology merely because both use OSPF or IS-IS.