Introduction to the Catalyst 8000 Edge Platform Family
Learning Objectives
Describe the role of the Catalyst 8000 Edge family within Cisco's enterprise WAN and SASE strategy
Distinguish the Catalyst 8200, 8300, 8500, and 8000V from each other and from legacy ISR/ASR platforms
Explain the convergence of routing, SD-WAN, and security in a single edge platform
Pre-Quiz: The Modern Network Edge
A retail chain moves its core applications to Microsoft 365 and Salesforce. Under the old backhaul model, what problem does this specifically create for branch users?
Branch routers can no longer establish encrypted tunnels to the data center
Traffic destined for cloud apps is hauled to a central data center and back, adding latency and wasting bandwidth
The branch loses the ability to reach the corporate data center entirely
MPLS circuits stop functioning because cloud apps require broadband
In the postal-system analogy, the WAN aggregation edge is compared to a "regional sorting facility." Which real-world function does this best capture?
A single branch connecting local users to the internet
A virtual router running inside a public cloud region
A central device that terminates and consolidates the encrypted tunnels arriving from many branches
A security service delivered from the cloud to inspect traffic
What is the defining characteristic that separates the "cloud edge" role from the branch and aggregation roles?
It is a software router running on a VM inside a public cloud rather than a physical box
It is the only role that uses encrypted tunnels
It runs a different operating system from the physical platforms
It cannot be managed by vManage
SD-WAN improves on a single statically pinned MPLS circuit primarily because it can:
Eliminate the need for any encryption between sites
Build an intelligent overlay across any transport and steer each application down the best path in real time
Replace IOS XE with a cloud-only operating system
Guarantee that all traffic always uses the MPLS circuit for reliability
How does SASE relate to SD-WAN in Cisco's architecture?
SASE replaces SD-WAN entirely with on-premises firewalls
SASE and SD-WAN are unrelated competing products
Cisco positions Catalyst SD-WAN as the foundation for SASE, with the edge router acting as an on-ramp into cloud-delivered security
SASE is the hardware and SD-WAN is the cloud service that controls it
The Modern Network Edge
Key Points
The modern edge serves three distinct roles: the branch edge, the WAN aggregation edge, and the cloud edge.
Three industry shifts reshaped the edge: cloud adoption, SD-WAN, and SASE.
Cisco's SD-WAN fabric has three logical planes: a data plane (cEdge routers), a control plane (vSmart), and a management plane (vManage).
SASE converges networking and security into a cloud-delivered service, with the edge router as the on-ramp to Umbrella / Secure Access.
The Catalyst 8000 runs IOS XE and can operate in classic routing mode or as an SD-WAN cEdge on the same hardware.
For most of networking history, the "edge" of an enterprise network was a quiet place. A branch office had a single router whose job was to push packets toward headquarters over a leased line or an MPLS circuit. The internet, when it was used at all, was reached by backhauling traffic all the way to a central data center, inspecting it there, and sending it back out. That model worked when applications lived in the corporate data center. It breaks down badly when the applications live in the cloud.
Branch, WAN aggregation, and cloud edge use cases
The modern enterprise edge has to serve three distinct roles, and the Catalyst 8000 family is built to cover all three:
The branch edge. This is the router sitting in a retail store, a regional office, or a clinic. It connects local users and devices to the rest of the organization and, increasingly, directly to the internet and cloud services. A coffee-shop chain with 800 locations has 800 branch edges.
The WAN aggregation edge. This is the large device at a central site or colocation facility that terminates the connections coming in from all those branches. If each branch is a spoke, the aggregation router is the hub. It must handle thousands of encrypted tunnels at once.
The cloud edge. As workloads move into AWS, Azure, and Google Cloud, organizations need a router inside the cloud to extend their private network into those environments and to apply consistent policy. This is a software router running on a virtual machine rather than a physical box.
Think of these three edges like a postal system. The branch edge is your neighborhood post office, the aggregation edge is the regional sorting facility that consolidates mail from many neighborhoods, and the cloud edge is a satellite sorting office that opened up wherever a major new customer base appeared. Historically Cisco sold a different product line for each of these roles. The Catalyst 8000 family was designed to provide one consistent platform and one operating system across all of them.
Figure 1.1: The three edge roles and how branch traffic flows to aggregation and cloud
Three industry shifts pushed Cisco to rethink the edge.
The first is cloud adoption. When the applications a business depends on (Microsoft 365, Salesforce, Workday) live on the public internet, backhauling all traffic to a central data center for inspection adds latency and wastes bandwidth. Branches need to break out to the internet locally while still being protected.
The second is SD-WAN (Software-Defined Wide Area Network). Rather than statically pinning traffic to a single expensive MPLS circuit, SD-WAN builds an intelligent overlay across any available transport, including broadband, MPLS, and cellular, and steers each application down the best path in real time. Cisco's SD-WAN fabric (originally the Viptela platform, now branded Cisco Catalyst SD-WAN) has three logical planes: a data plane of edge routers, a control plane of vSmart controllers, and a management plane called vManage, now also branded Catalyst SD-WAN Manager.
Animation: the SD-WAN fabric builds top-down — vManage (management) provisions vSmart (control), which programs the cEdge routers (data) that then form encrypted overlay tunnels.
The third is SASE (Secure Access Service Edge), pronounced "sassy." SASE is the convergence of networking and security into a single, cloud-delivered service. Instead of shipping a firewall appliance to every branch, an organization steers traffic from the edge router up to cloud-based security services. Cisco explicitly calls Catalyst SD-WAN "the foundation for a SASE-enabled architecture," with the edge router acting as the on-ramp into cloud security products such as Cisco Umbrella and Cisco Secure Access.
Figure 1.2: The three logical planes of the Cisco Catalyst SD-WAN fabric
The Catalyst 8000 Edge Platforms are Cisco's current-generation enterprise WAN edge routers. They run Cisco IOS XE (the same modern, modular operating system used across Cisco's enterprise routing and switching portfolio) and are positioned as the gateway to hybrid and multicloud applications, emphasizing application performance, visibility, and security at the WAN edge.
Crucially, a single Catalyst 8000 device can operate in either of two modes: traditional IOS XE routing (CLI-driven, sometimes called SD-Routing or "classic" mode) or as an SD-WAN cEdge router controlled centrally by vManage. The same physical box can therefore start life as a conventional router and later be converted into an SD-WAN node without a hardware swap. In short, Catalyst 8000 is the modern WAN router family that combines what Cisco's older ISR and ASR routers did, but with SD-WAN and cloud-edge capabilities built in from the start.
Key Takeaway: The network edge has grown from a single backhaul router into three distinct roles (branch, aggregation, and cloud), driven by cloud adoption, SD-WAN, and SASE. The Catalyst 8000 family is Cisco's IOS XE-based answer that covers all three roles and can run in either classic routing or SD-WAN mode on the same hardware.
Post-Quiz: The Modern Network Edge
A retail chain moves its core applications to Microsoft 365 and Salesforce. Under the old backhaul model, what problem does this specifically create for branch users?
Branch routers can no longer establish encrypted tunnels to the data center
Traffic destined for cloud apps is hauled to a central data center and back, adding latency and wasting bandwidth
The branch loses the ability to reach the corporate data center entirely
MPLS circuits stop functioning because cloud apps require broadband
In the postal-system analogy, the WAN aggregation edge is compared to a "regional sorting facility." Which real-world function does this best capture?
A single branch connecting local users to the internet
A virtual router running inside a public cloud region
A central device that terminates and consolidates the encrypted tunnels arriving from many branches
A security service delivered from the cloud to inspect traffic
What is the defining characteristic that separates the "cloud edge" role from the branch and aggregation roles?
It is a software router running on a VM inside a public cloud rather than a physical box
It is the only role that uses encrypted tunnels
It runs a different operating system from the physical platforms
It cannot be managed by vManage
SD-WAN improves on a single statically pinned MPLS circuit primarily because it can:
Eliminate the need for any encryption between sites
Build an intelligent overlay across any transport and steer each application down the best path in real time
Replace IOS XE with a cloud-only operating system
Guarantee that all traffic always uses the MPLS circuit for reliability
How does SASE relate to SD-WAN in Cisco's architecture?
SASE replaces SD-WAN entirely with on-premises firewalls
SASE and SD-WAN are unrelated competing products
Cisco positions Catalyst SD-WAN as the foundation for SASE, with the edge router acting as an on-ramp into cloud-delivered security
SASE is the hardware and SD-WAN is the cloud service that controls it
Pre-Quiz: Platform Family Overview
What single design decision is most responsible for making the Catalyst 8000 lineup feel like one coherent "family" rather than four unrelated products?
They all use the identical chassis and form factor
They all share IOS XE and the same SD-WAN feature set
They all deliver the same throughput
They are all software-only virtual routers
A branch gets all of its security from cloud services (a SASE model) and never needs to run containerized apps locally. Which 8200 variant is the better fit, and why?
C8200-1N-4T, because it has more cores for the cloud security workload
C8200L-1N-4T, because its lean 4-core design drops on-box compute the site does not need
C8200-1N-4T, because only it supports SD-WAN
Neither; a SASE branch requires a Catalyst 8500
A regional office needs modular T1/E1 and high-density Ethernet interfaces plus 5G readiness and roughly 8 Gbps of IPsec. Which member is purpose-built for this?
Catalyst 8200
Catalyst 8300
Catalyst 8500
Catalyst 8000V
A colocation hub must terminate the encrypted tunnels arriving from thousands of branches at 100+ Gbps. Why is the Catalyst 8500 the right choice over the 8300?
The 8500 is fixed, high-density with 10/40/100G ports built for large-scale aggregation, not branch-style modular slots
The 8500 is the only model that runs IOS XE
The 8300 cannot run SD-WAN at a hub
The 8500 is a virtual router and therefore scales infinitely
Why does the Catalyst 8000V have "no fixed maximum throughput"?
Because it disables encryption to run faster
Because it is software-only, so performance scales with the licensed throughput tier and allocated vCPUs
Because it uses the same fixed silicon as the 8500
Because cloud providers remove all bandwidth limits
Platform Family Overview
Key Points
The family is three physical hardware lines plus one virtual router, each tuned to a different point on the size/throughput spectrum.
8200: fixed 1RU for small/medium branches; the "lean" 8200L drops on-box compute for SASE sites.
8300: the modular workhorse for large branches/regional hubs — 5G-ready, 70+ modules, up to 18.8 Gbps forwarding / 8.6 Gbps IPsec.
8500 / 8500L: fixed high-density aggregation headend at tens to 100+ Gbps; no branch NIM/SM slots.
8000V: software-only virtual router; performance scales by license tier and vCPU count.
The Catalyst 8000 family is not a single product. It is three physical hardware lines plus one virtual router, each tuned for a different point on the size-and-throughput spectrum. They all share IOS XE and the same SD-WAN feature set, which is what makes the family coherent. The table below previews the lineup before we examine each member.
Figure 1.3: The Catalyst 8000 platform family tree
graph TD
Family["Catalyst 8000 Edge Platform Family (shared IOS XE & SD-WAN feature set)"]
Family --> C8200["Catalyst 8200 Small / medium branch Fixed 1RU"]
Family --> C8300["Catalyst 8300 Large branch / regional headend Modular 1RU or 2RU"]
Family --> C8500["Catalyst 8500 / 8500L Core / aggregation headend Fixed high-density"]
Family --> C8000V["Catalyst 8000V Cloud / virtual edge Software only (VM)"]
C8200 --> C8200a["C8200-1N-4T (8-core, app hosting)"]
C8200 --> C8200b["C8200L-1N-4T (lean, 4-core)"]
Animation: the family tree reveals the root, then staggers in the 8200, 8300, 8500/8500L, and 8000V — small branch through cloud edge.
Member
Role
Form factor
Headline performance
Catalyst 8200
Small / medium branch
Fixed, 1RU
Up to ~3.8 Gbps forwarding
Catalyst 8300
Medium / large branch, regional headend
Modular, 1RU or 2RU
Up to 18.8 Gbps forwarding; 8.6 Gbps IPsec
Catalyst 8500 / 8500L
Core / aggregation / data-center headend
Fixed, high-density
Tens to 100+ Gbps
Catalyst 8000V
Cloud / virtual edge
Software only (VM)
License- and vCPU-dependent
Catalyst 8200 Series
The Catalyst 8200 Series targets small and medium branches that still need enterprise-grade routing and SD-WAN, but in a compact, cost-effective chassis. These are fixed-configuration platforms with integrated WAN interfaces rather than large modular bays, optimized for secure SD-WAN and branch connectivity with integrated services such as IPsec, firewalling, and cloud onramp.
There are two main models, and the difference between them is instructive. Both are 1RU boxes with four 1-Gigabit WAN ports (two SFP plus two RJ-45) and one NIM slot plus one PIM slot:
C8200-1N-4T has an 8-core CPU and 8 GB of DRAM (upgradeable), and it supports application hosting / edge compute, meaning you can run containerized applications directly on the router.
C8200L-1N-4T is the "lean" variant with a 4-core CPU and 4 GB of DRAM, and it does not support on-box containers. It is aimed at branches that get their security from the cloud (a SASE model) and therefore do not need local compute.
Both deliver up to roughly 3.8 Gbps of unencrypted forwarding (Cisco Express Forwarding, or CEF) and on the order of 500 Mbps to 1 Gbps of IPsec throughput once security services are running.
Worked example. A small branch that previously ran an ISR 4321 or 4331 for a 100–200 Mbps internet/MPLS connection can move to a Catalyst 8200 to gain SD-WAN, much higher crypto throughput, and direct cloud access, all without stepping up to a larger modular chassis.
Catalyst 8300 Series
The Catalyst 8300 Series is the workhorse of the family, built for medium-to-large branches and regional offices that need modular interfaces, higher throughput, and strong SD-WAN performance.
Where the 8200 is fixed, the 8300 is modular. It comes in 1RU and 2RU variants with six built-in WAN ports and slots for one or two Network Interface Modules (NIMs), one or two Service Modules (SMs), and a dedicated PIM slot. More than 70 modules are supported, giving rich connectivity options including multiple WAN types, high-density Ethernet, and 5G. Models whose names end in "4T2X" include 10G SFP+ ports; "6T" models are all 1G. Representative SKUs include the C8300-2N2S-6T, C8300-2N2S-4T2X, and C8300-1N1S-4T2X (the "2N2S" prefix indicates two NIM and two SM slots).
Under the hood is an x86 system-on-chip with 8 or 12 cores, delivering up to 18.8 Gbps of CEF forwarding and up to 8.6 Gbps of hardware-accelerated IPsec, roughly five times the 8200's ceiling. The 8300 is also explicitly 5G-ready.
Worked example. A large regional office running an ISR 4451 with several T1/E1 and Ethernet modules can move to a Catalyst 8300, keep its modular connectivity, and scale to much higher encrypted throughput while deploying SD-WAN overlays.
Catalyst 8500 Series
The Catalyst 8500 (and its smaller sibling, the 8500L) is not a branch device at all. It is a high-performance aggregation and data-center platform, the kind of box that sits at a colocation facility or central hub and terminates the encrypted tunnels arriving from hundreds or thousands of branches.
These are fixed, high-density platforms with multiple 10/40/100-Gigabit ports, with no branch-style NIM or SM slots, aimed at large-scale WAN aggregation and SD-WAN hubs. Throughput runs from tens of gigabits per second into the 100+ Gbps range, depending on the SKU (examples include the C8500-12X and C8500-12X4QC, and the lighter C8500L-8S4X).
Worked example. A central site using an ASR 1001-HX or 1002-HX as its internet and SD-WAN hub can migrate to a Catalyst 8500 to gain tighter SD-WAN integration, more efficient hardware for encrypted traffic, and cloud-centric features such as Cloud OnRamp.
Catalyst 8000V virtual router
The Catalyst 8000V is the family member with no front panel. It is a software-only virtual router that runs as a virtual machine or cloud instance across hypervisors and public clouds (VMware, KVM, AWS, Azure, GCP) and provides the same IOS XE feature set as its physical siblings.
Because it has no fixed silicon, the 8000V has no fixed maximum throughput. Performance scales with the licensed throughput tier and the number of vCPUs you allocate, ranging from a few hundred Mbps to multiple Gbps. Its typical jobs are virtual customer premises equipment (vCPE), a virtual SD-WAN edge inside a cloud region, or cloud transit and aggregation. Deployed in AWS or Azure and onboarded into vManage, it becomes the cloud edge described earlier, mapping branch VPNs to cloud VPCs/VNETs so that the same segmentation and security policy follows workloads into the cloud.
Key Takeaway: The family scales from the fixed, compact 8200 for small branches, through the modular 8300 workhorse for large branches and regional hubs, up to the fixed high-density 8500 for aggregation, plus the software-only 8000V for cloud. They differ in form factor and throughput but share IOS XE and one SD-WAN feature set, which is what makes managing them as a single fabric possible.
Post-Quiz: Platform Family Overview
What single design decision is most responsible for making the Catalyst 8000 lineup feel like one coherent "family" rather than four unrelated products?
They all use the identical chassis and form factor
They all share IOS XE and the same SD-WAN feature set
They all deliver the same throughput
They are all software-only virtual routers
A branch gets all of its security from cloud services (a SASE model) and never needs to run containerized apps locally. Which 8200 variant is the better fit, and why?
C8200-1N-4T, because it has more cores for the cloud security workload
C8200L-1N-4T, because its lean 4-core design drops on-box compute the site does not need
C8200-1N-4T, because only it supports SD-WAN
Neither; a SASE branch requires a Catalyst 8500
A regional office needs modular T1/E1 and high-density Ethernet interfaces plus 5G readiness and roughly 8 Gbps of IPsec. Which member is purpose-built for this?
Catalyst 8200
Catalyst 8300
Catalyst 8500
Catalyst 8000V
A colocation hub must terminate the encrypted tunnels arriving from thousands of branches at 100+ Gbps. Why is the Catalyst 8500 the right choice over the 8300?
The 8500 is fixed, high-density with 10/40/100G ports built for large-scale aggregation, not branch-style modular slots
The 8500 is the only model that runs IOS XE
The 8300 cannot run SD-WAN at a hub
The 8500 is a virtual router and therefore scales infinitely
Why does the Catalyst 8000V have "no fixed maximum throughput"?
Because it disables encryption to run faster
Because it is software-only, so performance scales with the licensed throughput tier and allocated vCPUs
Because it uses the same fixed silicon as the 8500
Because cloud providers remove all bandwidth limits
Pre-Quiz: Migration from Legacy Platforms
Cisco maps the new family onto the old one. A site running an ASR 1002-HX as its SD-WAN/internet hub should migrate to which Catalyst 8000 member?
Catalyst 8200
Catalyst 8300
Catalyst 8500
Catalyst 8000V
What is described as the single biggest technical distinction between the legacy ISR/ASR generation and the Catalyst 8000?
The Catalyst 8000 cannot run classic CLI-driven routing
On the legacy boxes SD-WAN was a bolt-on; on the Catalyst 8000 SD-WAN is a primary design target with crypto-optimized hardware
Only the legacy platforms support encryption
The Catalyst 8000 drops IOS XE in favor of a cloud-only OS
Using the "consolidating three engine families onto one modular platform" analogy, what is the main operational benefit Cisco is claiming from convergence?
Every device now has identical throughput
One OS and one management fabric span branch, hub, and cloud, so skills and tooling transfer across all of them
Hardware becomes free because only software is licensed
Legacy ISR/ASR platforms are immediately end-of-life
Why might an organization keep some ISR 4000 / ASR 1000 devices in service even after adopting the Catalyst 8000?
Because Catalyst 8000 devices cannot route at all
Because the legacy lines remain supported and still serve niche roles such as TDM voice that the new ecosystem may not yet match
Because the Catalyst 8000 cannot be managed by vManage
Because licensing forbids running both families on one network
Because a Catalyst 8000 runs both classic and SD-WAN modes, how can a team "protect their investment" during migration?
By deploying SD-WAN first and only buying hardware afterward
By separating the hardware swap from the mode switch — deploy in classic mode first, then convert to SD-WAN later without a hardware change
By avoiding IOS XE entirely
By converting all boxes to SD-WAN before the controllers are ready
Migration from Legacy Platforms
Key Points
Catalyst 8000 succeeds two legacy lines: the ISR 4000 branch routers and the ASR 1000 aggregation routers (plus CSR1000v → 8000V).
The biggest technical shift: SD-WAN was a bolt-on on legacy gear but a primary design target (crypto-optimized, 5G-ready) on the Catalyst 8000.
Convergence onto one IOS XE family means one OS and one vManage fabric across branch, hub, and cloud.
Because each box runs both modes, the hardware swap and the mode switch can be staged as separate projects.
The major commercial change is the shift to subscription-based Cisco DNA licensing; verify feature/module parity before migrating.
The Catalyst 8000 family did not appear in a vacuum. It is the strategic successor to two earlier, separate Cisco product lines, and understanding that lineage is essential to understanding why the family is shaped the way it is.
ISR 4000 and ASR 1000 comparison
Two legacy families dominated the enterprise edge for the previous decade:
The ISR 4000 (Integrated Services Router) series was the branch router. The ISR 4321 and 4331 served small sites; the 4451 and 4461 served larger ones. These were general-purpose multi-service routers handling routing, voice, and security at the branch.
The ASR 1000 (Aggregation Services Router) series was the high-performance aggregation and WAN-edge platform. Models such as the ASR 1001-HX and 1002-HX commonly served as internet edges and SD-WAN or DMVPN hubs at central sites.
Cisco maps the new family onto the old one quite explicitly. The Catalyst 8300 is described as "an upgrade to the 4400 Integrated Services Router," and the Catalyst 8500 is described as "an update to the 1001-HX and 1002-HX" ASR models. The 8200 and 8300 together take over the ISR 4000 branch roles, while the 8500 inherits the ASR 1000 aggregation role. The mapping is summarized below.
Figure 1.5: Migration mapping from legacy ISR/ASR platforms to the Catalyst 8000 family
Animation: legacy boxes appear, migration arrows flow left-to-right one by one, and each Catalyst 8000 successor lights up — ISR4000→8200/8300, ASR1000→8500, CSR1000v→8000V.
Legacy platform
Legacy role
Catalyst 8000 successor
ISR 4321 / 4331
Small / medium branch
Catalyst 8200
ISR 4451 / 4461
Large branch
Catalyst 8300
ASR 1001-HX / 1002-HX
Aggregation / WAN hub
Catalyst 8500
(virtual CSR1000v / virtual ISR)
Cloud / NFV router
Catalyst 8000V
The single biggest technical distinction between old and new is where SD-WAN lives. On the ISR 4000 and ASR 1000, SD-WAN was effectively a bolt-on capability. On the Catalyst 8000, SD-WAN is a primary design target: the hardware is crypto-optimized to sustain high IPsec throughput, the family is 5G-ready, and the same operating system family spans branch through aggregation, simplifying lifecycle and configuration management.
Why Cisco converged the portfolio
Maintaining two distinct hardware lines, each with its own modules, software images, and support processes, is expensive for Cisco and confusing for customers. Convergence onto one IOS XE-based family yields several concrete benefits. A single operating system spans the entire edge, so an engineer who knows one box knows them all. The same SD-WAN fabric and the same vManage console manage branch, hub, and cloud devices together. And the hardware is purpose-built for the encrypted, cloud-bound traffic that dominates modern networks, rather than for the legacy WAN technologies (such as TDM serial circuits) that older platforms were designed around.
The analogy is a manufacturer consolidating three separate engine families onto one modular platform. The small car, the SUV, and the truck now share a common engine architecture and diagnostic system; only the displacement and tuning differ. A mechanic trained on one can service all three, and the factory builds one line instead of three.
That said, convergence is a direction, not an overnight event. The ISR 4000 and ASR 1000 remain supported and still appear in Cisco's routing portfolio, especially for niche unified-communications and TDM voice roles that the Catalyst 8000 ecosystem may not yet fully match. A staged migration is the norm: new and refreshed sites deploy Catalyst 8000, while legacy sites with special feature dependencies stay on ISR/ASR until their hardware refresh windows align.
Investment protection and licensing transition
Because a Catalyst 8000 can run in either classic IOS XE mode or SD-WAN mode, organizations can protect their investment by separating two changes that older migrations forced together. The hardware swap (replacing aging ISR/ASR boxes with Catalyst 8000) and the mode switch (moving from classic routing to a vManage-controlled SD-WAN fabric) are distinct projects. A common approach is to deploy Catalyst 8000 in classic mode first, keeping the existing routing design and operational model intact, then convert the same boxes to SD-WAN later once the controllers and policy design are ready.
Figure 1.4: Dual-mode operation of a single Catalyst 8000 device
The most significant commercial change is licensing. Where the older ISR/ASR generation leaned on perpetual licenses, Catalyst 8000 platforms use Cisco DNA subscriptions and IOS XE software licensing, particularly for SD-WAN and advanced security services. This is a subscription-heavy model. The practical implication is that budgeting must account for recurring per-router subscription cost, not just the one-time hardware purchase. Migration planners should also inventory existing features (MPLS, advanced QoS, TDM voice, DMVPN) and confirm each is supported on the planned IOS XE release and in the intended mode, since some legacy WAN protocols available in classic mode are not available in SD-WAN mode. Module reuse deserves the same scrutiny: the compatibility of existing ISR 4000 cards with the Catalyst 8300 varies by module type and must be checked against official support before a swap.
Key Takeaway: Catalyst 8000 succeeds the ISR 4000 (branch) and ASR 1000 (aggregation) lines, converging two product families onto one IOS XE platform built for SD-WAN and encrypted cloud traffic. Because a single box runs both classic and SD-WAN modes, hardware refresh and SD-WAN adoption can be staged separately, but planners must budget for the shift to subscription-based DNA licensing and verify feature and module support before migrating.
Post-Quiz: Migration from Legacy Platforms
Cisco maps the new family onto the old one. A site running an ASR 1002-HX as its SD-WAN/internet hub should migrate to which Catalyst 8000 member?
Catalyst 8200
Catalyst 8300
Catalyst 8500
Catalyst 8000V
What is described as the single biggest technical distinction between the legacy ISR/ASR generation and the Catalyst 8000?
The Catalyst 8000 cannot run classic CLI-driven routing
On the legacy boxes SD-WAN was a bolt-on; on the Catalyst 8000 SD-WAN is a primary design target with crypto-optimized hardware
Only the legacy platforms support encryption
The Catalyst 8000 drops IOS XE in favor of a cloud-only OS
Using the "consolidating three engine families onto one modular platform" analogy, what is the main operational benefit Cisco is claiming from convergence?
Every device now has identical throughput
One OS and one management fabric span branch, hub, and cloud, so skills and tooling transfer across all of them
Hardware becomes free because only software is licensed
Legacy ISR/ASR platforms are immediately end-of-life
Why might an organization keep some ISR 4000 / ASR 1000 devices in service even after adopting the Catalyst 8000?
Because Catalyst 8000 devices cannot route at all
Because the legacy lines remain supported and still serve niche roles such as TDM voice that the new ecosystem may not yet match
Because the Catalyst 8000 cannot be managed by vManage
Because licensing forbids running both families on one network
Because a Catalyst 8000 runs both classic and SD-WAN modes, how can a team "protect their investment" during migration?
By deploying SD-WAN first and only buying hardware afterward
By separating the hardware swap from the mode switch — deploy in classic mode first, then convert to SD-WAN later without a hardware change
By avoiding IOS XE entirely
By converting all boxes to SD-WAN before the controllers are ready