Selection & Interfaces

Chapter 5 — Core Switch Security Hardening Design Guide


Selecting the right core switch platform is a foundational decision that determines which security features are available, how they can be configured, and what limitations must be worked around. Not all enterprise-grade core switches support the full spectrum of hardening controls described in this guide. Platform selection must therefore be driven not only by performance and port density requirements, but also by the security feature set, software quality, and vendor security posture.

This chapter presents the core product categories, their typical security feature capabilities, and the interface and port logic that governs how security zones are physically and logically implemented. The interface logic diagram provides a visual reference for understanding how port groups map to security zones and which security policies apply to each port type.

5.1 Core Product Introduction

Core switches for security-hardened deployments fall into three primary categories based on chassis architecture and port density. Each category has distinct security feature capabilities, scalability characteristics, and operational considerations. The following figure illustrates representative products from each category.

Core Switch Product Categories — Modular Chassis, Fixed High-Density, and Spine Switch
Figure 5.1: Core Switch Product Categories — Left: 400G Modular Chassis Core Switch (10U, multi-line-card); Center: 25G/100G Fixed-Configuration Leaf/Aggregation Switch (2U); Right: 100G Fixed-Configuration Spine Switch (2U, 64-port)

Core Product Feature Comparison Table

The following table provides a comprehensive comparison of security-relevant features across the three core switch product categories. Features marked as "Full" are natively supported with hardware acceleration. "Partial" indicates software-only support or limited scale. "N/A" indicates the feature is not available on that platform category.

Security Feature Modular Chassis Core Fixed High-Density Spine Switch Notes
Management Plane
Dedicated OOB Management PortFullFullFullStandard on all enterprise platforms
Management VRF IsolationFullFullFullVerify VRF-aware management services
SSHv2 with Public Key AuthFullFullFullDisable SSHv1; enforce key-only auth
TACACS+ / RADIUS AAAFullFullFullTACACS+ preferred for command authorization
Role-Based Access Control (RBAC)FullFullPartialSpine switches may have limited role granularity
Session Timeout & Idle DisconnectFullFullFullConfigure 10-minute idle timeout minimum
HTTPS REST API with TLS 1.2+FullFullFullDisable HTTP; enforce TLS 1.2 minimum
gRPC/gNMI Streaming TelemetryFullFullFullPreferred over SNMP for modern deployments
SNMPv3 (AuthPriv)FullFullFullDisable SNMPv1/v2c; use SNMPv3 AuthPriv only
Control Plane
Control Plane Policing (CoPP)Full (HW)Full (HW)Full (HW)Hardware-enforced CoPP on all platforms
BGP MD5/SHA AuthenticationFullFullFullMandatory for all BGP sessions
OSPF MD5/SHA AuthenticationFullFullFullMandatory for all OSPF areas
BGP RPKI Route Origin ValidationFullFullFullRequires RTR server; verify TCAM capacity
GTSM (Generalized TTL Security)FullFullFullApply to all eBGP and OSPF sessions
BFD (Bidirectional Forwarding Detection)Full (HW)Full (HW)Full (HW)Hardware BFD for sub-second failure detection
Data Plane / L2 Security
DHCP SnoopingFull (HW)Full (HW)N/ASpine switches typically L3-only; no L2 security needed
Dynamic ARP Inspection (DAI)Full (HW)Full (HW)N/AHardware-enforced on all downlink ports
IP Source Guard (IPSG)Full (HW)Full (HW)N/AVerify TCAM capacity before enabling
802.1X Port AuthenticationFullFullN/ATypically not required on core-to-distribution links
BPDU Guard / Root GuardFullFullN/AApply to all downlink ports facing distribution
Storm ControlFull (HW)Full (HW)N/AHardware-enforced rate limiting per port
MACsec (802.1AE) EncryptionFull (HW)Full (HW)Full (HW)Verify line card/ASIC support; performance impact
High Availability
Dual Supervisor / NSF/NSRFullN/AN/AModular chassis only; hitless failover
MLAG / Multi-Chassis LAGFullFullFullVerify security policy sync between peers
VSS / VSF StackingPartialFullPartialPlatform-specific; verify security feature support
Dual Power Supply (Hot-Swap)FullFullFullMandatory for all core switch deployments
Dual Fan Tray (Hot-Swap)FullFullFullMandatory; verify fan failure alerting

5.2 Interface and Port Logic Diagram

The interface and port logic diagram provides a comprehensive view of how physical ports are organized into security zones, what naming conventions apply, and which security policies are assigned to each port group. This diagram serves as the definitive reference for port configuration and security policy assignment during deployment.

Core Switch Interface and Port Logic Diagram — Front Panel, Security Zone Mapping, and Policy Assignment Matrix
Figure 5.2: Interface and Port Logic Diagram — Front Panel Port Groups (Uplink/Orange, Peer-Link/Red, Production/Blue, OOB/Green), Logical Security Zone Mapping, Interface Naming Convention, and Port Security Policy Assignment Matrix

Interface Security Policy Assignment

The following table defines the mandatory security policies for each interface type. These policies must be applied consistently across all core switches in the deployment. Deviations from this table require documented risk acceptance and compensating controls.

Interface Type Uplink (Orange) Peer-Link (Red) Production Downlink (Blue) OOB Management (Green)
VRF AssignmentUplink VRFPeer-Link VLAN (dedicated)Production VRFManagement VRF
Routing Protocol AuthBGP MD5/SHAN/A (L2 only)OSPF MD5/SHAStatic routes only
CoPP AppliedYes — strict uplink policyYes — peer-link policyYes — production policyYes — management policy
ACL (Inbound)Permit only required protocols; deny all elsePermit MLAG/LACP onlyExtended role-based ACLPermit only jump host IPs; SSH/HTTPS only
DHCP SnoopingN/AN/ATrusted (uplink) / Untrusted (downlink)N/A
DAIN/AN/AEnabledN/A
BPDU GuardN/AN/AEnabledEnabled
Storm ControlN/AEnabled (L2)EnabledEnabled
Port Security (MAC Limit)N/AN/AMax 2 (distribution uplinks)Max 1
MACsecRecommended for WAN linksRecommendedOptional (performance impact)Recommended
LoggingLink state; BGP events; ACL hitsPeer-link state; MLAG eventsLink state; routing events; ACL hitsAll access; all commands; config changes

5.3 TCAM Capacity Planning

TCAM (Ternary Content-Addressable Memory) is a finite hardware resource that stores ACL entries, routing table entries, ARP/MAC tables, and other forwarding state. Security hardening features such as extended ACLs, IP Source Guard, and RPKI route origin validation all consume TCAM entries. TCAM exhaustion causes security features to fail silently or fall back to software processing, which can dramatically impact performance and security posture. TCAM capacity planning must be performed before enabling security features in production.

TCAM ConsumerTypical Entries RequiredPriorityPlanning Notes
IPv4 Routing Table (FIB)50,000–1,000,000 routesCriticalFull Internet table requires 900K+ entries; verify TCAM bank allocation
IPv6 Routing Table (FIB)10,000–200,000 routesHighIPv6 entries typically consume 2x IPv4 TCAM space
ARP / MAC Table32,000–256,000 entriesCriticalScale with number of hosts; verify per-VLAN limits
ACL Entries (Inbound + Outbound)1,000–50,000 entriesHighEach ACE consumes 1–4 TCAM entries; count carefully
DHCP Snooping Bindings4,000–32,000 entriesMediumScale with number of DHCP clients
IP Source Guard (IPSG)4,000–32,000 entriesMediumConsumes same TCAM as DHCP snooping bindings
RPKI ROA Cache50,000–200,000 entriesMediumRequires dedicated TCAM bank on some platforms
QoS / CoPP Policies500–5,000 entriesHighCoPP entries consume TCAM; verify per-class entry count