CCDE study materials
CCDE study resources

CCDE cheat sheet

CCDE · Keep the key ideas within reach.

Quick reference

Network Design Fundamentals and Business Alignment

  • Design drivers hierarchy: business objectives → technical requirements → design decisions; every design element must trace to a stated requirement or it is a candidate for removal.

  • Requirement categories to capture explicitly: functional (what must work), non-functional (availability, scalability, performance, compliance), and constraints (budget, legacy, regulatory, timeline).

  • Availability math: serial availability = A1 × A2 × …; parallel (redundant) availability = 1 − (1−A1)(1−A2). Two 99.9% paths in parallel yield 99.9999%.

  • MTBF/MTTR relationship: availability = MTBF / (MTBF + MTTR); reducing MTTR (faster convergence, better ops) is usually cheaper than raising MTBF.

  • Five-nines (99.999%) allows ~5.26 minutes downtime per year; four-nines (99.99%) allows ~52.6 minutes. Use this to sanity-check SLA claims.

  • Modular design: core, distribution, access, WAN edge, and services blocks with defined boundaries; module boundaries are where policy, summarization, and failure domains should change.

  • Risk register technique: rank each design risk by likelihood × impact; mitigation is either redundancy, monitoring, or documented acceptance - unmitigated risks must be visible to the business.

  • Capacity planning: model peak utilization at 2x–3x current demand for a 3–5 year horizon; link sizing should target <50–70% sustained utilization to absorb bursts and failures.

  • Operational cost dominates lifecycle TCO; a design that is simpler to operate often beats a marginally more optimal but complex design.

Quick reference

Enterprise LAN and Campus Design

  • L2 failure domain rule: one VLAN = one spanning-tree domain = one broadcast domain; keep access VLANs local to a wiring-closet switch pair and route between them at the distribution block.

  • Spanning tree: RSTP/MSTP convergence is seconds; use MSTP with explicit instances mapped to VLAN groups, and align the root bridge with the L3 gateway (HSRP/VRRP) owner to avoid asymmetric paths.

  • First-hop redundancy: HSRP/VRRP/GLBP virtual MAC and IP; sub-second failover requires BFD or tuned timers; prefer L3-routed access with ECMP where the platform supports it.

  • Port-channel hashing is per-flow, not per-packet; a single flow never exceeds one member link, so size bundles for flow diversity, not just aggregate bandwidth.

  • Campus hierarchy: access (port density, PoE, security edge), distribution (policy, summarization, FHRP), core (high-speed transport, minimal policy). Collapsed core is valid for small sites.

  • PoE budgeting: 802.3af = 15.4 W at PSE, 802.3at = 30 W, 802.3bt = 60/90 W; size UPS and switch power supplies against worst-case simultaneous draw.

  • Wireless design inputs: client density per AP, throughput per client, channel width, and coverage overlap of 15–20% for roaming; 5 GHz and 6 GHz planning is separate from 2.4 GHz.

  • Campus segmentation: use VRFs or macro-segmentation at distribution for IoT, guest, and corporate; enforce with ACLs or a group-based policy fabric rather than relying on VLAN sprawl.

Quick reference

Enterprise WAN and Service Provider Edge Design

  • WAN technology selection: MPLS L3VPN for any-to-any with SLA and traffic engineering; Internet + overlay (IPsec/DMVPN/SD-WAN) for cost and agility; leased line for deterministic latency.

  • Underlay/overlay split: the underlay provides reachability (Internet, MPLS, LTE/5G); the overlay provides policy, encryption, and topology (hub-spoke, full mesh, partial mesh).

  • SD-WAN design rules: application-aware path selection, per-path SLA probes (loss/latency/jitter), local Internet breakout for SaaS, and centralized policy with distributed enforcement.

  • BGP at the SP edge: eBGP for CE-PE or PE-CE, iBGP with route reflectors inside the provider; use MED for inbound influence and local-preference/AS-path prepending for outbound.

  • Provider independence: dual-homing to two PEs in the same provider protects link/PE failure but not provider failure; true diversity needs two providers and physically diverse last-mile.

  • MTU discipline: overlay encapsulation (IPsec, VXLAN, GRE) consumes bytes; set underlay MTU to accommodate the largest encapsulation plus headers, and test with DF-bit probes.

  • Traffic engineering: MPLS TE or SR-TE for explicit paths; for Internet WAN, steer by application class rather than attempting per-flow TE across uncontrolled paths.

  • Edge redundancy patterns: active/active with ECMP and BFD, or active/standby with fast failover; document asymmetric routing behavior for stateful devices in the path.

Quick reference

Data Center and Cloud Connectivity Design

  • Spine-leaf: every leaf connects to every spine, no leaf-to-leaf links; ECMP across spines provides equal-cost multipath; overlay (VXLAN) carries tenant L2 over an L3 underlay.

  • VXLAN facts: 24-bit VNI (~16 million segments), 50-byte overhead, UDP destination port 4789; MTU on underlay must be at least 1600 bytes, commonly 9000 with jumbo frames.

  • EVPN control plane replaces flood-and-learn: BGP EVPN route types 2 (MAC/IP), 3 (IMET), 5 (IP prefix); enables multihoming via ESI and anycast VTEP.

  • Cloud connectivity options: Internet VPN (fast, cheap, variable), dedicated interconnect (private, predictable, higher cost), and SD-WAN-to-cloud gateways; choose per workload sensitivity.

  • Hybrid routing: extend BGP from on-prem to cloud VPC/VNet with route summarization and explicit prefix filters; avoid overlapping RFC1918 space by allocating an IP plan before migration.

  • Failure domains in DC: rack-level (ToR pair), pod-level (spine pair), and site-level; dual-homed servers with LACP or EVPN multihoming remove single-NIC and single-ToR risk.

  • Storage and compute traffic separation: use distinct VLANs/VRFs and QoS classes for storage (lossless, PFC/ECN for RoCE) vs. general IP traffic.

  • Cloud egress cost and latency are design constraints: keep chatty tiers co-located and place latency-sensitive services near users; measure with real RTT, not assumptions.

Quick reference

Routing Protocol Design and Policy

  • IGP vs EGP roles: IGP (OSPF/IS-IS) for fast, loop-free intra-domain reachability; BGP for policy, multihoming, and inter-domain scale. Do not run BGP where a simple IGP suffices.

  • OSPF area rules: all areas must touch area 0 (or use virtual links); inter-area routes are summarized at ABRs; external routes are injected at ASBRs and can be summarized only at ASBRs.

  • IS-IS scaling: single-level design for most enterprises, L1/L2 only for very large domains; TLVs allow flexible extension; IS-IS is transport-agnostic and common in SP cores.

  • BGP best-path order (abbreviated): highest weight → highest local preference → locally originated → shortest AS-path → lowest origin → lowest MED → eBGP over iBGP → lowest IGP metric to next hop → oldest route → lowest router ID.

  • Route filtering: inbound prefix filters (bogon and RPKI-invalid rejection), outbound filters to prevent transit leaks, and max-prefix limits on eBGP sessions.

  • Summarization trade-off: aggregation shrinks tables and stabilizes topology but blackholes traffic when a component prefix fails unless a more specific route or discard route is present.

  • Convergence tuning: BFD for sub-second failure detection, tuned IGP hello/dead timers, and fast external failover with BGP next-hop tracking; avoid aggressive timers without testing CPU impact.

  • Policy placement: apply policy at the edge (between domains) and keep the core policy-light; redistribution points must be few, documented, and filtered with tags or route maps.

Quick reference

Network Security Design

  • Defense in depth: edge (firewall/IPS), internal segmentation (VRF/ACL/security groups), endpoint, and identity layers; no single control is assumed to be sufficient.

  • Zone-and-conduit model: define security zones (user, server, DMZ, management, guest, IoT) and permit only explicit conduits between them; default deny both directions.

  • Stateful firewall placement: at trust boundaries and before shared services; asymmetric routing breaks stateful inspection, so design symmetric paths or use stateless ACLs where asymmetry is unavoidable.

  • IPsec design: IKEv2 preferred, AES-GCM for ESP, PFS with a defined DH group, and rekey timers aligned to peer; avoid overlapping interesting traffic on the same peer.

  • Zero-trust principles: authenticate and authorize per request, least privilege, microsegmentation, and continuous verification; identity becomes the primary perimeter.

  • Management plane hardening: out-of-band management network, AAA (TACACS+/RADIUS) with command accounting, SSH only, and no management reachability from user or guest zones.

  • DDoS and edge protection: anycast scrubbing, rate limiting at the edge, uRPF for spoofing, and control-plane policing (CoPP) to protect routing protocols from CPU exhaustion.

  • Compliance mapping: PCI DSS, HIPAA, and GDPR impose segmentation, logging retention, and encryption requirements that must be captured as design constraints, not afterthoughts.

Quick reference

Network Services, QoS, and Multicast Design

  • QoS model choice: DiffServ (classification and marking at edge, per-hop behavior in core) scales better than IntServ/RSVP for enterprise and SP networks.

  • Standard DSCP classes: EF (46) for voice, AF41 (34) for interactive video, AF31 (26) for streaming, AF21 (18) for transactional data, AF11 (10) for bulk, CS1 (8) for scavenger, default (0).

  • Queueing rules: priority queue for EF with policer to prevent starvation, bandwidth guarantees for AF classes via CBWFQ/LLQ, and WRED/ECN for TCP-friendly drop management.

  • Trust boundary: classify and mark as close to the source as possible; re-mark at trust boundaries; never trust markings from untrusted endpoints.

  • Multicast addressing: 224.0.0.0/4 IPv4 multicast; 232.0.0.0/8 SSM; 239.0.0.0/8 admin-scoped; link-local 224.0.0.0/24 is never forwarded.

  • PIM modes: PIM-SM uses RP and shared tree then switches to SPT; PIM-SSM requires no RP and uses (S,G) channels directly - preferred for one-to-many with known sources.

  • Multicast design: RP placement (anycast RP/MSDP), multicast boundaries at domain edges, IGMP snooping on L2 to prevent flooding, and PIM register/SPT-switch tuning for latency.

  • Service placement: DHCP relay, DNS anycast, NTP hierarchy (stratum), and AAA redundancy are services that need their own availability design - treat them as first-class.

  • QoS verification: measure per-class loss, latency, and jitter end to end; a QoS design that is not measured is a hypothesis, not a guarantee.

Quick reference

Network Automation, Programmability, and Operability

  • Data models: YANG defines schema; NETCONF/RESTCONF carry it; OpenConfig provides vendor-neutral models; gNMI adds streaming telemetry over the same model.

  • Configuration workflow: intent → template (Jinja2) → render → validate (syntax, schema, dry-run) → deploy (NETCONF/CLI) → verify (state and telemetry) → rollback on failure.

  • Idempotency and source of truth: automation must converge to a declared state; the inventory/IPAM and Git repository are authoritative, not device configs.

  • CI/CD for network: version control, peer review, automated tests (lint, unit, lab), staged rollout (canary device/region), and automated rollback gates.

  • Telemetry vs polling: SNMP polling is minute-granularity and CPU-heavy; model-driven streaming telemetry (gNMI, 10s or sub-second) is preferred for intent verification and SLA monitoring.

  • Observability triad: metrics (time series), logs (events), and traces (request paths); correlate by device, interface, and flow to shorten mean time to repair.

  • Operability design rules: consistent naming, standard interface descriptions, documented IP plan, golden configs, and runbooks for every failure mode identified in the risk register.

  • API security: authenticate automation with short-lived credentials, scope RBAC to least privilege, and log every change with who/what/when for audit and rollback.

  • Change safety: out-of-band access, commit-confirm timers, and config backups before change are design requirements, not operational nice-to-haves.

Quick reference

Network Design Fundamentals and Business Alignment

  • Design drivers hierarchy: business objectives → technical requirements → design decisions; every design element must trace to a stated requirement or it is a candidate for removal.

  • Requirement categories to capture explicitly: functional (what must work), non-functional (availability, scalability, performance, compliance), and constraints (budget, legacy, regulatory, timeline).

  • Availability math: serial availability = A1 × A2 × …; parallel (redundant) availability = 1 − (1−A1)(1−A2). Two 99.9% paths in parallel yield 99.9999%.

  • MTBF/MTTR relationship: availability = MTBF / (MTBF + MTTR); reducing MTTR (faster convergence, better ops) is usually cheaper than raising MTBF.

  • Five-nines (99.999%) allows ~5.26 minutes downtime per year; four-nines (99.99%) allows ~52.6 minutes. Use this to sanity-check SLA claims.

  • Modular design: core, distribution, access, WAN edge, and services blocks with defined boundaries; module boundaries are where policy, summarization, and failure domains should change.

  • Risk register technique: rank each design risk by likelihood × impact; mitigation is either redundancy, monitoring, or documented acceptance - unmitigated risks must be visible to the business.

  • Capacity planning: model peak utilization at 2x–3x current demand for a 3–5 year horizon; link sizing should target <50–70% sustained utilization to absorb bursts and failures.

  • Operational cost dominates lifecycle TCO; a design that is simpler to operate often beats a marginally more optimal but complex design.

Quick reference

Enterprise LAN and Campus Design

  • L2 failure domain rule: one VLAN = one spanning-tree domain = one broadcast domain; keep access VLANs local to a wiring-closet switch pair and route between them at the distribution block.

  • Spanning tree: RSTP/MSTP convergence is seconds; use MSTP with explicit instances mapped to VLAN groups, and align the root bridge with the L3 gateway (HSRP/VRRP) owner to avoid asymmetric paths.

  • First-hop redundancy: HSRP/VRRP/GLBP virtual MAC and IP; sub-second failover requires BFD or tuned timers; prefer L3-routed access with ECMP where the platform supports it.

  • Port-channel hashing is per-flow, not per-packet; a single flow never exceeds one member link, so size bundles for flow diversity, not just aggregate bandwidth.

  • Campus hierarchy: access (port density, PoE, security edge), distribution (policy, summarization, FHRP), core (high-speed transport, minimal policy). Collapsed core is valid for small sites.

  • PoE budgeting: 802.3af = 15.4 W at PSE, 802.3at = 30 W, 802.3bt = 60/90 W; size UPS and switch power supplies against worst-case simultaneous draw.

  • Wireless design inputs: client density per AP, throughput per client, channel width, and coverage overlap of 15–20% for roaming; 5 GHz and 6 GHz planning is separate from 2.4 GHz.

  • Campus segmentation: use VRFs or macro-segmentation at distribution for IoT, guest, and corporate; enforce with ACLs or a group-based policy fabric rather than relying on VLAN sprawl.

Quick reference

Enterprise WAN and Service Provider Edge Design

  • WAN technology selection: MPLS L3VPN for any-to-any with SLA and traffic engineering; Internet + overlay (IPsec/DMVPN/SD-WAN) for cost and agility; leased line for deterministic latency.

  • Underlay/overlay split: the underlay provides reachability (Internet, MPLS, LTE/5G); the overlay provides policy, encryption, and topology (hub-spoke, full mesh, partial mesh).

  • SD-WAN design rules: application-aware path selection, per-path SLA probes (loss/latency/jitter), local Internet breakout for SaaS, and centralized policy with distributed enforcement.

  • BGP at the SP edge: eBGP for CE-PE or PE-CE, iBGP with route reflectors inside the provider; use MED for inbound influence and local-preference/AS-path prepending for outbound.

  • Provider independence: dual-homing to two PEs in the same provider protects link/PE failure but not provider failure; true diversity needs two providers and physically diverse last-mile.

  • MTU discipline: overlay encapsulation (IPsec, VXLAN, GRE) consumes bytes; set underlay MTU to accommodate the largest encapsulation plus headers, and test with DF-bit probes.

  • Traffic engineering: MPLS TE or SR-TE for explicit paths; for Internet WAN, steer by application class rather than attempting per-flow TE across uncontrolled paths.

  • Edge redundancy patterns: active/active with ECMP and BFD, or active/standby with fast failover; document asymmetric routing behavior for stateful devices in the path.

Quick reference

Data Center and Cloud Connectivity Design

  • Spine-leaf: every leaf connects to every spine, no leaf-to-leaf links; ECMP across spines provides equal-cost multipath; overlay (VXLAN) carries tenant L2 over an L3 underlay.

  • VXLAN facts: 24-bit VNI (~16 million segments), 50-byte overhead, UDP destination port 4789; MTU on underlay must be at least 1600 bytes, commonly 9000 with jumbo frames.

  • EVPN control plane replaces flood-and-learn: BGP EVPN route types 2 (MAC/IP), 3 (IMET), 5 (IP prefix); enables multihoming via ESI and anycast VTEP.

  • Cloud connectivity options: Internet VPN (fast, cheap, variable), dedicated interconnect (private, predictable, higher cost), and SD-WAN-to-cloud gateways; choose per workload sensitivity.

  • Hybrid routing: extend BGP from on-prem to cloud VPC/VNet with route summarization and explicit prefix filters; avoid overlapping RFC1918 space by allocating an IP plan before migration.

  • Failure domains in DC: rack-level (ToR pair), pod-level (spine pair), and site-level; dual-homed servers with LACP or EVPN multihoming remove single-NIC and single-ToR risk.

  • Storage and compute traffic separation: use distinct VLANs/VRFs and QoS classes for storage (lossless, PFC/ECN for RoCE) vs. general IP traffic.

  • Cloud egress cost and latency are design constraints: keep chatty tiers co-located and place latency-sensitive services near users; measure with real RTT, not assumptions.

Quick reference

Routing Protocol Design and Policy

  • IGP vs EGP roles: IGP (OSPF/IS-IS) for fast, loop-free intra-domain reachability; BGP for policy, multihoming, and inter-domain scale. Do not run BGP where a simple IGP suffices.

  • OSPF area rules: all areas must touch area 0 (or use virtual links); inter-area routes are summarized at ABRs; external routes are injected at ASBRs and can be summarized only at ASBRs.

  • IS-IS scaling: single-level design for most enterprises, L1/L2 only for very large domains; TLVs allow flexible extension; IS-IS is transport-agnostic and common in SP cores.

  • BGP best-path order (abbreviated): highest weight → highest local preference → locally originated → shortest AS-path → lowest origin → lowest MED → eBGP over iBGP → lowest IGP metric to next hop → oldest route → lowest router ID.

  • Route filtering: inbound prefix filters (bogon and RPKI-invalid rejection), outbound filters to prevent transit leaks, and max-prefix limits on eBGP sessions.

  • Summarization trade-off: aggregation shrinks tables and stabilizes topology but blackholes traffic when a component prefix fails unless a more specific route or discard route is present.

  • Convergence tuning: BFD for sub-second failure detection, tuned IGP hello/dead timers, and fast external failover with BGP next-hop tracking; avoid aggressive timers without testing CPU impact.

  • Policy placement: apply policy at the edge (between domains) and keep the core policy-light; redistribution points must be few, documented, and filtered with tags or route maps.

Quick reference

Network Security Design

  • Defense in depth: edge (firewall/IPS), internal segmentation (VRF/ACL/security groups), endpoint, and identity layers; no single control is assumed to be sufficient.

  • Zone-and-conduit model: define security zones (user, server, DMZ, management, guest, IoT) and permit only explicit conduits between them; default deny both directions.

  • Stateful firewall placement: at trust boundaries and before shared services; asymmetric routing breaks stateful inspection, so design symmetric paths or use stateless ACLs where asymmetry is unavoidable.

  • IPsec design: IKEv2 preferred, AES-GCM for ESP, PFS with a defined DH group, and rekey timers aligned to peer; avoid overlapping interesting traffic on the same peer.

  • Zero-trust principles: authenticate and authorize per request, least privilege, microsegmentation, and continuous verification; identity becomes the primary perimeter.

  • Management plane hardening: out-of-band management network, AAA (TACACS+/RADIUS) with command accounting, SSH only, and no management reachability from user or guest zones.

  • DDoS and edge protection: anycast scrubbing, rate limiting at the edge, uRPF for spoofing, and control-plane policing (CoPP) to protect routing protocols from CPU exhaustion.

  • Compliance mapping: PCI DSS, HIPAA, and GDPR impose segmentation, logging retention, and encryption requirements that must be captured as design constraints, not afterthoughts.

Quick reference

Network Services, QoS, and Multicast Design

  • QoS model choice: DiffServ (classification and marking at edge, per-hop behavior in core) scales better than IntServ/RSVP for enterprise and SP networks.

  • Standard DSCP classes: EF (46) for voice, AF41 (34) for interactive video, AF31 (26) for streaming, AF21 (18) for transactional data, AF11 (10) for bulk, CS1 (8) for scavenger, default (0).

  • Queueing rules: priority queue for EF with policer to prevent starvation, bandwidth guarantees for AF classes via CBWFQ/LLQ, and WRED/ECN for TCP-friendly drop management.

  • Trust boundary: classify and mark as close to the source as possible; re-mark at trust boundaries; never trust markings from untrusted endpoints.

  • Multicast addressing: 224.0.0.0/4 IPv4 multicast; 232.0.0.0/8 SSM; 239.0.0.0/8 admin-scoped; link-local 224.0.0.0/24 is never forwarded.

  • PIM modes: PIM-SM uses RP and shared tree then switches to SPT; PIM-SSM requires no RP and uses (S,G) channels directly - preferred for one-to-many with known sources.

  • Multicast design: RP placement (anycast RP/MSDP), multicast boundaries at domain edges, IGMP snooping on L2 to prevent flooding, and PIM register/SPT-switch tuning for latency.

  • Service placement: DHCP relay, DNS anycast, NTP hierarchy (stratum), and AAA redundancy are services that need their own availability design - treat them as first-class.

  • QoS verification: measure per-class loss, latency, and jitter end to end; a QoS design that is not measured is a hypothesis, not a guarantee.

Quick reference

Network Automation, Programmability, and Operability

  • Data models: YANG defines schema; NETCONF/RESTCONF carry it; OpenConfig provides vendor-neutral models; gNMI adds streaming telemetry over the same model.

  • Configuration workflow: intent → template (Jinja2) → render → validate (syntax, schema, dry-run) → deploy (NETCONF/CLI) → verify (state and telemetry) → rollback on failure.

  • Idempotency and source of truth: automation must converge to a declared state; the inventory/IPAM and Git repository are authoritative, not device configs.

  • CI/CD for network: version control, peer review, automated tests (lint, unit, lab), staged rollout (canary device/region), and automated rollback gates.

  • Telemetry vs polling: SNMP polling is minute-granularity and CPU-heavy; model-driven streaming telemetry (gNMI, 10s or sub-second) is preferred for intent verification and SLA monitoring.

  • Observability triad: metrics (time series), logs (events), and traces (request paths); correlate by device, interface, and flow to shorten mean time to repair.

  • Operability design rules: consistent naming, standard interface descriptions, documented IP plan, golden configs, and runbooks for every failure mode identified in the risk register.

  • API security: authenticate automation with short-lived credentials, scope RBAC to least privilege, and log every change with who/what/when for audit and rollback.

  • Change safety: out-of-band access, commit-confirm timers, and config backups before change are design requirements, not operational nice-to-haves.