A core switch connects the parts of a network that need a shared backbone. Choosing one requires more than comparing port counts or the largest throughput number on a specification sheet. Start with the topology, traffic paths, routing requirements, and service expectations. Then check whether the proposed hardware, software, and support arrangement meet those requirements together.
This guide follows that selection process and uses the Cisco Catalyst C9500-48Y4C-A as a campus example. It separates device specifications from network guarantees, explains a simple capacity calculation, and gives procurement teams a checklist they can use when requesting a quote.
What a core switch does in a campus network
In a traditional layered campus, the core provides transit between distribution blocks and other connected network areas. The distribution layer brings together access networks and applies functions chosen by the design. Access switches connect endpoints such as computers, phones, cameras, and wireless access points.
Traffic does not automatically pass through a core switch simply because it belongs to an enterprise. Its path depends on where the source and destination sit, where routing occurs, and how the network is connected. Traffic within one local segment can take a different path from traffic moving between buildings or toward an external service.
| Network role | Selection question | Information needed |
|---|---|---|
| Access | Which endpoints must connect? | Port count, endpoint speeds, PoE, and monitoring |
| Distribution | How are access networks joined and controlled? | Aggregation links, routing boundaries, and policy requirements |
| Core | How are network blocks interconnected? | Transit capacity, routing scale, resilience, and growth |
| Collapsed core | Can core and distribution functions be combined? | Site layout, failure domains, operational needs, and expansion |
Treat these as design roles rather than fixed product labels. A platform can serve different roles in different networks. Document the intended core switch role before asking a supplier for a model recommendation.
For endpoint requirements, use the separate business access-switch guide. This keeps access power and port planning distinct from backbone selection.
Decide between a collapsed core and separate layers
A smaller campus may combine distribution and core functions. A network with several distribution blocks may require a separate backbone. Size alone is not the only consideration: cable routes, maintenance boundaries, failure impact, and future buildings can change the decision.
Juniper’s campus topology guide distinguishes collapsed-core, traditional three-stage, and campus fabric approaches. Use that architectural distinction when discussing your own network, without assuming that one vendor’s implementation applies unchanged to another.
Illustrative scenario: A business has two buildings and expects to add a third. Before selecting a core switch, its engineer maps the available fiber routes and the access networks in each building. The team compares a combined core/distribution design with a separate backbone, including maintenance and growth needs. This is a hypothetical planning example, not a customer deployment or measured result.
How to size a core switch for normal and failure conditions
Create a traffic map before adding interface rates. Identify the sources, destinations, direction, and timing of important flows. A network serving office applications may have a different traffic pattern from one carrying storage transfers or large data movements.
Separate interface capacity, switching capacity, and forwarding rate. Interface rates describe individual connections. A switching-capacity figure describes a device specification under its stated measurement convention. Forwarding rate describes packet processing and needs its own conditions. None of these numbers alone proves that a complete network will never drop packets.
Calculate the traffic crossing each boundary
Consider a hypothetical interface arrangement with 48 links at 25 Gbps and four links at 100 Gbps. If every 25G link simultaneously sends traffic toward those four 100G links, the offered traffic is 1,200 Gbps and the nominal outgoing capacity is 400 Gbps. The ratio is 3:1.
That calculation describes one direction and one traffic assumption. It does not prove that every deployment has the same contention. Traffic may stay within the device, use other paths, or occur at different times. Conversely, correlated transfers can create more pressure than an average utilization figure suggests.
A core switch can therefore have a large published switching-capacity number while a particular outgoing path remains constrained. Do not use a full-duplex device total as if it were the capacity of one uplink group.
| Planning case | What to calculate | What to document |
|---|---|---|
| Normal operation | Traffic expected across each link group | Direction, concurrent flows, and time window |
| Growth | Additional endpoints and application demand | Assumptions and expansion constraints |
| Link failure | Demand on remaining paths | Traffic redistribution and remaining capacity |
| Device maintenance | Traffic while one device is unavailable | Surviving topology and operational procedure |
Measure current peak traffic where possible. If reliable measurements are unavailable, make assumptions explicit and plan how to validate them. A model cannot replace missing information with a guarantee.
Check the reduced-capacity case
For a resilient core switch design, evaluate the paths available during a fault or maintenance event. Ask which links remain, which traffic moves, and whether the remaining capacity meets the agreed service requirement.
Illustrative scenario: A team plans four 100G connections. It also examines a case where only two are available, giving 200 Gbps of nominal link capacity for the assumed direction. It compares that figure with expected concurrent traffic and defines an acceptance test. These are illustrative interface calculations, not a forecast of application performance.
The 25GbE and 100GbE planning article provides a separate discussion of those rates. If you have a traffic map, request a configuration review through the product catalog and include both the normal and reduced-capacity requirements.
Routing, software, and operating requirements
Define the routing work before selecting the core switch. Record which boundaries need routing, which protocols the existing design uses, and which segmentation requirements must be maintained. Ask whether the proposal changes any of those decisions.
For a core switch, a feature checklist should identify the required function, the reason it is needed, and the evidence that the proposed configuration supports it. Avoid broad requests such as “full Layer 3” when the project actually needs a defined set of functions.
Verify scale and feature combinations
Review the relevant limits for the proposed device and release. These can include routing entries, host entries, access-control rules, or other resources used by the design. Do not combine different table types into one unexplained route total.
Ask whether resource allocation or a platform template changes the usable limits. Check the proposed feature combination rather than reading each headline value independently. A useful supplier response points to the model-specific documentation and explains how it applies to your configuration.
The core switch requirements should also cover management. Specify monitoring, configuration backup, authentication, time synchronization, logging, and software maintenance expectations. Name the team responsible for these tasks so the chosen platform matches the way the network will be operated.
Separate licenses from support and management services
A complete quote should distinguish hardware, base entitlements, subscriptions, management services, and support. State the required functions and ask the supplier to map each one to the relevant entitlement and software release.
For an existing Cisco platform, check the current Cisco licensing guidance and the applicable ordering documents. Purchase requirements and the behavior of a device after a subscription expires are different questions. Neither should be reduced to a general statement that every subscription is optional.
When reviewing a core switch offer, record what is included, what expires, what can be renewed, and what requires a customer account or activation step. Do not assume the hardware suffix alone explains the complete commercial arrangement.
Resilience: specify the behavior you need to test
Two devices, two power supplies, or several links can be parts of a resilient design. Their presence does not prove that the entire system meets a recovery target. Shared dependencies and the selected operating design still matter.
For the core switch layer, document the failure conditions the business cares about. Include a failed link, an unavailable device, a power event, and a planned software change where relevant. Define the service observation and acceptance criterion for each test.
Check StackWise Virtual against the selected release
Cisco’s IOS XE 17.15 StackWise Virtual guide documents a version-specific design for supported Catalyst platforms. Check the model, software, link arrangement, and dual-active detection requirements against the configuration being proposed.
Do not promise uninterrupted service or a fixed recovery time without the relevant conditions and test evidence. Similarly, treating two physical devices as one logical system does not establish that every Layer 2 loop concern elsewhere in the network disappears.
A core switch acceptance plan should cover the real traffic and applications being protected. Device indicators alone may not show the interruption experienced by users. Plan observation points, test duration, rollback, and maintenance responsibilities before deployment.
Illustrative scenario: An IT team receives a proposal for a two-device core. It asks for a topology drawing and a documented test of a failed inter-device connection. The team specifies what traffic will be observed and how the test will be reversed. This scenario demonstrates a review process; it does not claim a particular recovery result.
Cisco Catalyst C9500-48Y4C-A as a campus example
Cisco positions Catalyst 9500 platforms within its campus core and distribution portfolio. That makes the C9500-48Y4C-A a relevant example for a campus core switch discussion, while a data center fabric remains a separate selection problem.
The Catalyst 9500 data sheet, updated October 6, 2026, provides the model-specific starting point:
| Item | Published model information | Review before ordering |
|---|---|---|
| Interfaces | 48 ports supporting 1/10/25G; four supporting 40/100G | Supported modules, cables, port use, and software |
| Switching capacity | Up to 3.2 Tbps | Measurement convention and traffic-path limits |
| Forwarding rate | Up to 1 Bpps | Packet-processing requirements and documented conditions |
| ASIC | UADP 3.0 | Required feature combination and scale |
| Product identity | C9500-48Y4C-A includes Network Advantage identity | Complete entitlements, subscriptions, and support offer |
These are specifications, not a promise of congestion-free operation. Use the earlier traffic and failure calculations to decide whether the core switch configuration fits your requirements. Read the current document’s notes and associated release guidance rather than applying series-wide maximums to one model.
Browse the C9500-48Y4C-A product page for the listed equipment. Keep this buying guide focused on the selection process, while the product page identifies the particular item being considered.
For leaf-and-spine deployments, refer to the data center switch guide. A familiar campus platform should not become the default choice for every network architecture.
Optics, accessories, and the complete bill of materials
Supporting a port speed does not establish that every existing transceiver works. Record the exact module or cable part number, interface, distance, and software release. Check the combination using the manufacturer’s compatibility information, such as Cisco’s optics interoperability tool.
For a core switch, confirm physical installation details as carefully as logical features. Verify power supplies, power input, airflow, rack mounting, and environmental requirements against the exact proposed equipment. Do not turn one example accessory list into a universal configuration rule.
Use a bill of materials with enough detail to compare offers:
- Exact hardware part numbers, quantity, and condition.
- Required software releases, features, and entitlements.
- Optical modules, cables, distances, and compatibility references.
- Power supplies, mounting parts, and airflow requirements.
- Management and support services with their terms.
- Delivery conditions, warranty responsibilities, and acceptance documents.
An offer for a core switch is incomplete if important accessories or services remain unspecified. Identify unknowns explicitly rather than treating them as included. Before committing, send your bill of materials for review and ask for written clarification of the proposed configuration.
Compare ownership cost on the same basis
Use the same service period and included scope for every proposal. Compare purchase price, renewals, installation, operations, spare equipment, and migration work where relevant. State the assumptions instead of applying an unsupported saving percentage or refresh-cycle prediction.
A core switch with a lower initial price may require additional equipment or services for the intended design. A higher-priced proposal may also contain items the project does not need. The comparison should show those differences as line items that the team can challenge.
Make the handover usable by the operations team
Include an agreed configuration record in the core switch handover. It should identify the installed equipment, software, licenses, management access, interface assignments, and the documents used to validate the design. Record any assumptions that changed during procurement so the operations team does not inherit an outdated plan.
Before acceptance, walk through a routine maintenance task and a recovery procedure with the people responsible for the network. Confirm where backups, support details, and compatibility records will be kept. Assign responsibility for reviewing software and service renewals. This turns the core switch purchase into a maintainable configuration rather than a collection of boxes and separate documents.
CREA DAS TECH supplies network communication equipment across several brands. A configuration request should describe your actual network and service needs. Availability, source documentation, warranty coverage, and delivery terms must be confirmed for the specific offer.
Questions to resolve before selecting the platform
Do we need a separate core switch?
Not every campus needs a dedicated core layer. Compare a collapsed-core design with separate core and distribution roles using the site’s topology, traffic, failure impact, and growth plan. The decision should follow the design requirements rather than a fixed endpoint-count rule.
Does non-blocking capacity mean there will be no packet loss?
No device capacity number can guarantee an entire network’s behavior. A constrained outgoing link, correlated traffic, a failure, or other configuration conditions can affect service. Evaluate the core switch against documented traffic assumptions and acceptance tests.
Can we reuse our existing optical modules?
Possibly, but reuse must be verified. Check exact part numbers, speed, distance, platform support, and software conditions. A port’s support for 1G or 10G is not blanket approval of every older optical module.
Is Network Advantage the complete purchase specification?
No. It identifies an entitlement aspect of the offer, but the buyer must still confirm the required features, release, subscriptions, management, and support arrangement. Ask for the complete configuration and current ordering terms.
What should we send when requesting a quote?
Provide a topology, traffic and growth assumptions, required interfaces, routing and management functions, failure requirements, optics, accessories, services, and delivery location. If a choice is unresolved, include it as a question for review.
The right core switch is the one whose documented configuration fits the network’s role, traffic, and operating requirements. Start with the design, verify the evidence behind the offer, and test the behavior that matters to your business.
