DCCOR 350-601 v1.2 — Final Exam Study Guide

120 minutes · Implementing Cisco Data Center Core Technologies · CCNP & CCIE Data Center · All 5 blueprint domains covered, sourced from official Cisco documentation

1.0 Network 25% 2.0 Compute 25% 3.0 Storage Network 20% 4.0 Automation & AI 15% 5.0 Security 15%

Domain 1.0 — Network

25%
1.1

Apply Routing Protocols — OSPFv2/v3, MP-BGP, PIM, FHRP

▶

OSPFv2 / OSPFv3

  • OSPFv2 = IPv4 only; OSPFv3 = IPv6 (and IPv4 via address-family, RFC 5838)
  • LSA types: 1-Router, 2-Network, 3-Summary, 4-ASBR-Summary, 5-External, 7-NSSA
  • Area types: Standard, Stub, Totally Stub, NSSA, Totally NSSA
  • DR/BDR elected on broadcast/NBMA; priority 0 = never DR
  • NX-OS default reference-bandwidth 40000 Mbps (auto-cost)
  • ip ospf network point-to-point common on DC point-to-point links to skip DR election

MP-BGP

  • Multiprotocol BGP carries AFI/SAFI beyond unicast IPv4 — VPNv4, L2VPN EVPN
  • DC underlay: eBGP between spine/leaf (RFC 7938 "BGP in the DC")
  • DC overlay: iBGP or eBGP EVPN address-family (L2VPN EVPN) distributes MAC/IP + VNI info
  • Route-reflector (spine) avoids full-mesh iBGP among leafs
  • Key attributes: AS-PATH, LOCAL_PREF (iBGP), MED, weight (Cisco-local), next-hop-self

PIM

  • PIM-SM (Sparse Mode) is standard in DC fabrics — explicit join via RP
  • Rendezvous Point (RP): static, Auto-RP, or BSR; Anycast-RP (MSDP or PIM Anycast) for redundancy
  • Shared Tree (*,G) rooted at RP → SPT switchover to Source Tree (S,G)
  • In VXLAN EVPN, PIM-BiDir/PIM-SM builds the underlay multicast tree for BUM traffic replication (or ingress-replication as an alternative)

FHRP

  • HSRP (Cisco), VRRP (standard), GLBP (Cisco, active load balancing across up to 4 gateways)
  • ACI/VXLAN EVPN fabrics replace classic FHRP with a distributed anycast gateway — same gateway IP/MAC active on every leaf, no FHRP protocol needed
  • HSRP versions: v1 (multicast 224.0.0.2, UDP 1985) vs v2 (224.0.0.102, supports IPv6, >255 groups)
Scenario Table
ScenarioAnswer
Underlay routing in a VXLAN EVPN Nexus 9000 fabric (leaf/spine)eBGP with unique AS per leaf, or OSPF, is the underlay; MP-BGP EVPN AFI is the overlay control plane
Need a single, always-active default-gateway MAC/IP on every leafDistributed Anycast Gateway (VXLAN EVPN) — replaces HSRP/VRRP inside the fabric
BUM traffic replication without PIM in the underlayIngress (head-end) replication
OSPF area that blocks external routes but keeps summary LSAsNSSA (Type-7→5 translation at ABR) vs Stub (blocks Type-5 only)
! NX-OS OSPF point-to-point + BFD example interface Ethernet1/1 ip address 10.0.0.1/31 ip router ospf UNDERLAY area 0.0.0.0 ip ospf network point-to-point ip ospf bfd
Sources: Cisco NX-OS Unicast Routing Config Guide · RFC 7938 (BGP in the DC) · Cisco VXLAN Network with MP-BGP EVPN Control Plane White Paper
1.2

Apply Switching Protocols — RSTP+, LACP, vPC

▶

Rapid PVST+ (RSTP+)

  • Cisco's per-VLAN instance of RSTP (802.1w) — one spanning tree per VLAN
  • Port roles: Root, Designated, Alternate, Backup; states: Discarding, Learning, Forwarding
  • Edge ports (PortFast) + BPDU Guard recommended on host-facing ports
  • MST (802.1s) groups VLANs into instances for scale — alternative to Rapid PVST+

LACP (802.3ad)

  • Modes: active (initiates), passive (responds only — needs one active side), on (static, no negotiation)
  • System ID = LACP system priority + system MAC; Port priority selects active/standby links beyond max bundle
  • NX-OS max 16 links/port-channel (8 active + 8 hot-standby with some platforms)

vPC (Virtual Port Channel)

  • Allows a downstream device to port-channel across two independent Nexus switches — looks like one logical switch
  • Key components: peer-link (carries CFS, BPDU/ARP sync, orphan traffic), peer-keepalive (out-of-band heartbeat over mgmt0/L3), vPC domain, role priority (lower = primary)
  • Consistency checks: Type-1 (must match, e.g. STP mode) vs Type-2 (warn only)
  • vPC peer-switch: both peers appear as same STP root bridge id
  • vPC peer-gateway: locally routes packets destined to the peer's gateway MAC (avoids extra peer-link hop)
  • Orphan ports: single-homed devices on a vPC-enabled switch — peer-gateway + ip arp synchronize minimize disruption
Gotcha: vPC peer-link MUST be a trunk port-channel with dedicated 10G+ links; losing peer-keepalive alone does not trigger dual-active recovery — only losing BOTH peer-link and keepalive triggers the secondary to suspend/shutdown vPCs (dual-active detection).
! NX-OS vPC domain config vpc domain 10 peer-switch role priority 100 peer-keepalive destination 10.1.1.2 source 10.1.1.1 peer-gateway ip arp synchronize auto-recovery interface port-channel10 vpc peer-link
Sources: Cisco Nexus 9000 vPC Configuration Guide · Cisco Nexus 9000 Interfaces Config Guide (LACP)
1.3

Apply Overlay Protocols — VXLAN EVPN

▶

Data Plane

  • VXLAN (RFC 7348): MAC-in-UDP encapsulation, VNI = 24-bit (16.7M segments) vs 4096 VLAN limit
  • UDP dest port 4789; VTEP = VXLAN Tunnel Endpoint (source/dest of encap)
  • Adds ~50 bytes overhead → bump MTU to 9216 (jumbo) on fabric-facing interfaces

Control Plane — MP-BGP EVPN

  • L2VPN EVPN address-family distributes MAC (Type-2), MAC+IP (Type-2), IMET/BUM (Type-3), Route-Type-5 (IP-Prefix, for external/L3 routes)
  • Replaces flood-and-learn — VTEPs learn remote MAC/IP via BGP updates, not data-plane flooding
  • Route-Distinguisher (RD) + Route-Target (RT, import/export) per VRF/L2VNI, similar to MPLS L3VPN

Roles

  • Leaf = VTEP, terminates VXLAN, hosts anycast gateway (SVI)
  • Spine = pure IP underlay forwarder (usually not a VTEP) in standard CLOS; can be a Rendezvous Point for BUM
  • Border Leaf = handoff to external L3 (VRF-lite, MPLS L3VPN) — carries Type-5 routes

BUM Handling

  • Ingress replication (head-end replication, unicast copies) — simpler, no underlay multicast needed
  • Multicast underlay (PIM-BiDir) — more efficient at scale, requires PIM in underlay
! NX-OS EVPN leaf: NVE interface + BGP EVPN AF feature nv overlay feature vn-segment-vlan-based feature bgp interface nve1 no shutdown source-interface loopback1 host-reachability protocol bgp member vni 30001 ingress-replication protocol bgp router bgp 65001 address-family l2vpn evpn retain route-target all neighbor 10.0.0.1 address-family l2vpn evpn send-community extended
Sources: RFC 7348 (VXLAN) · RFC 8365 (EVPN NVO) · Cisco VXLAN EVPN white paper · Cisco Nexus 9000 VXLAN Config Guide
1.4

Apply ACI Concepts — Fabric Setup, Access Policies, VMM

▶

Fabric Setup

  • APIC (controller, cluster of 3/5/7) discovers spine/leaf via LLDP + fabric discovery, assigns Node IDs/TEP addresses
  • Underlay: IS-IS between leaf/spine, VXLAN overlay automatically built by APIC
  • Policy model: Tenant → VRF (Context) → Bridge Domain (BD) → EPG; Application Profile groups EPGs
  • Fabric-wide pools: TEP pool, VLAN pool, VXLAN VNID pool managed by APIC

Access Policies

  • Bind physical/virtual connectivity to logical EPGs: Switch Profile → Interface Profile → Interface Policy Group → AAEP (Attachable Access Entity Profile) → Domain (Physical/VMM/L3out) → VLAN pool
  • Interface Policy Group = CDP/LLDP, LACP/port-channel, STP, storm-control policies bundled per port
  • vPC in ACI = "Explicit vPC Protection Group" between two leaf nodes

VMM Domain

  • Integrates APIC with VMware vCenter/Hyper-V/OpenStack/Kubernetes — APIC pushes port-groups/DVS automatically per EPG
  • Uses OpFlex or API-based push; dynamic VLAN/VXLAN assignment from the domain's encap pool
  • Enables micro-segmentation via EPGs mapped to VM attributes (uSeg EPGs)

Core Constructs

  • EPG (Endpoint Group) = security zone; Contract = whitelist policy between EPGs (default deny between EPGs in different BDs unless contract exists)
  • BD = L2 flood domain / broadcast boundary, ties to one VRF; can enable/disable IP/ARP flooding, unicast routing
  • L3Out = external routing connectivity (OSPF/BGP/EIGRP/static) via border leaf
Exam tip: ACI default within-EPG traffic = always permitted; between-EPG traffic = denied unless a contract (provider/consumer relationship) is applied. This is the opposite of traditional VLAN/subnet-based access control.
Sources: Cisco APIC Basic Configuration Guide · Cisco ACI Fundamentals Guide · Cisco ACI Virtualization Guide
1.5

Analyze Packet Flow — Unicast, Multicast, Broadcast

▶

Unicast (VXLAN EVPN)

  • Known unicast: ingress leaf does local L2/L3 lookup → VXLAN encap to destination VTEP (learned via BGP EVPN Type-2) → egress leaf decaps, forwards to host
  • Unknown unicast (silent host): flooded as BUM unless ARP suppression / silent-host detection resolves it first

Broadcast

  • ARP requests are the dominant broadcast traffic; VXLAN EVPN fabrics implement ARP suppression at the ingress leaf (reply from local BGP EVPN MAC/IP table) to avoid flooding across the whole fabric
  • Otherwise broadcast = BUM traffic, replicated via ingress-replication or multicast underlay to every VTEP with that VNI/BD

Multicast

  • Underlay multicast tree (PIM) replicates BUM frames fabric-wide when multicast-mode underlay is used
  • Overlay (tenant) multicast requires PIM-enabled anycast gateway SVIs + underlay multicast group per VNI (in ACI: GIPo — Group IP outer address, one per BD)

ACI-Specific

  • Every BD gets a fabric-wide multicast group (GIPo) used to replicate BUM inside iVXLAN regardless of tenant multicast config
  • Spine-Proxy: leaf queries spine's global "COOP" endpoint DB when destination MAC/IP unknown, instead of flooding
Sources: Cisco VXLAN EVPN white paper · Cisco ACI Fabric Forwarding Guide
1.6

Cloud Service & Deployment Models — NIST SP 800-145

▶

5 Essential Characteristics

  • On-demand self-service
  • Broad network access
  • Resource pooling (multi-tenant)
  • Rapid elasticity
  • Measured service (metering/billing)

3 Service Models

  • IaaS — compute/storage/network primitives (consumer manages OS up)
  • PaaS — runtime/platform (consumer manages app + data only)
  • SaaS — full application (consumer manages nothing but usage/config)

4 Deployment Models

  • Private — single organization, on-/off-prem
  • Community — shared by orgs with common concerns
  • Public — open to general public, owned by provider
  • Hybrid — composition of 2+ models bound by data/app portability
Sources: NIST Special Publication 800-145, "The NIST Definition of Cloud Computing"
1.7

Software Updates & Impacts — Disruptive/Nondisruptive, EPLD, Patches

▶

ISSU (In-Service Software Upgrade)

  • NX-OS ISSU can be nondisruptive when: dual supervisors present, compatible image, no line-card/EPLD change required, stateful restarts supported for running features
  • Becomes disruptive when: single-sup chassis, incompatible feature set, ACL/TCAM layout changes, or an EPLD upgrade is bundled in
  • show install all impact predicts disruptive vs nondisruptive before committing

EPLD

  • Electronic Programmable Logic Device — FPGA/CPLD firmware controlling low-level hardware (fabric, power, ASIC glue logic)
  • EPLD upgrades are almost always disruptive — require a reload of the module/switch
  • Only needed if release notes flag a required EPLD version bump for that NX-OS image

Patches (SMUs)

  • Software Maintenance Updates fix a specific defect between maintenance releases
  • Can be reload-based or non-reload (some are hitless) — check the SMU's own disruption metadata
! NX-OS install workflow show install all impact kickstart bootflash:nxos.image install all nxos bootflash:nxos.image show incompatibility system bootflash:nxos.image show install active
Sources: Cisco Nexus 9000 Software Upgrade/Downgrade Guide · Cisco NX-OS EPLD Upgrade/Downgrade Release Notes
1.8

Implement Network Configuration Management

▶

NX-OS Native

  • checkpoint / rollback — snapshot running-config, revert on failure
  • configure session — atomic config with auto-commit or auto-abort verification
  • copy running-config startup-config; copy run tftp: for offbox backup

Fabric-Wide

  • Nexus Dashboard Fabric Controller / Insights: template-based config compliance, drift detection, golden-config baselines
  • APIC: config exported as JSON/XML snapshot; Config Zones stage changes per pod before fabric-wide rollout
! Checkpoint / rollback example checkpoint my-checkpoint-1 configure terminal interface Eth1/1 shutdown rollback running-config checkpoint my-checkpoint-1
Sources: Cisco NX-OS Fundamentals Config Guide (Checkpoint/Rollback) · Cisco Nexus Dashboard Fabric Controller Config Guide
1.9

Infrastructure Monitoring — NetFlow, SPAN, Nexus Dashboard

▶

NetFlow

  • Flow = 5/7-tuple (src/dst IP, src/dst port, protocol [+ ToS/interface])
  • NX-OS supports NetFlow / sFlow on Nexus 9000 (hardware-accelerated flow-table export)
  • Export to a collector via UDP for capacity planning, security, top-talkers

SPAN / ERSPAN

  • SPAN mirrors local traffic to a local destination port; RSPAN mirrors across switches over a VLAN; ERSPAN encapsulates in GRE to route mirrored traffic across L3 to a remote analyzer
  • Types: ingress, egress, or both; can span physical, port-channel, VLAN, or FEX interfaces

Cisco Nexus Dashboard

  • Unified platform (physical or virtual cluster) hosting multiple services: Nexus Dashboard Insights, Fabric Controller (NDFC), Orchestrator (NDO), Data Broker
  • AI/ML-driven analytics — anomaly detection, advisories, capacity/latency trending, and pre-change/post-change validation
! ERSPAN destination session example monitor session 1 type erspan-source source interface Eth1/2 both destination ip 10.10.10.5 erspan-id 100 vrf default no shut
Sources: Cisco Nexus 9000 System Management Config Guide (SPAN/NetFlow) · Cisco Nexus Dashboard Data Sheet
1.10

Network Assurance Concepts — Streaming Telemetry

▶

Model-Driven Telemetry (MDT)

  • Devices push structured YANG-modeled data continuously (vs. legacy SNMP polling pull model) — lower overhead, near-real-time
  • Transport: gRPC or gRPC-dial-out/dial-in, encoded in GPB (Google Protocol Buffers) or JSON
  • Subscriptions defined by sensor-path (YANG path) + sample-interval

Assurance Value

  • Proactive detection of drops, buffer/queue congestion, CRC errors, TCAM utilization before they cause outages
  • Feeds analytics engines (Nexus Dashboard Insights) for anomaly baselining and root-cause correlation
  • ACI "Health Score" is a form of continuous assurance built from telemetry + faults
Sources: Cisco Programmability Configuration Guide — Model-Driven Telemetry · Cisco Nexus Dashboard Insights Data Sheet
1.11

Capabilities & Features of Cisco Nexus Dashboard

▶

Platform

  • Common infrastructure (K8s-based cluster) hosting multiple "services" with shared UI, RBAC, and API
  • Deployable as physical appliance, VM (ESXi/KVM), cloud (AWS/Azure), or Cisco Nexus Dashboard on top of existing UCS/AppServer

Key Services

  • Nexus Dashboard Insights — telemetry-based assurance, anomaly detection, pre-/post-change analysis
  • Nexus Dashboard Orchestrator (NDO) — multi-site/multi-fabric ACI & NDFC policy orchestration
  • Nexus Dashboard Fabric Controller (NDFC) — LAN/VXLAN EVPN fabric automation (successor to DCNM) + SAN management
  • Data Broker — centralizes SPAN/tap aggregation across the fabric
Sources: Cisco Nexus Dashboard User Guide · Cisco Nexus Dashboard Deployment Guide

Domain 2.0 — Compute

25%
2.1

Implement Cisco UCS Rack Servers

▶

Standalone Mode

  • Managed individually via CIMC (Cisco Integrated Management Controller) — embedded BMC with own GUI/CLI/XML API on a dedicated management port
  • KVM, vMedia, IPMI, SNMP, Redfish all exposed via CIMC
  • Common lines: C220/C240 (1U/2U general purpose), C480 (4-socket), C125 (density)

UCS-Managed (Rack-Mount Integration)

  • C-Series can be integrated into UCS Manager domain via Fabric Extenders (Nexus 2232) or direct-connect to Fabric Interconnects, converting CIMC to "N10" managed mode
  • Once integrated: inherits Service Profiles, pools, and templates just like blade servers

Intersight-Managed

  • Rack servers can also be claimed directly into Cisco Intersight (SaaS or on-prem Private Virtual Appliance) for cloud-based lifecycle management without UCS Manager
Sources: Cisco UCS C-Series Rack Server CIMC Configuration Guide · Cisco UCS C-Series Integration with UCS Manager Guide
2.2

Implement Cisco UCS Blade Chassis (Setup, Infra, Network, Storage, Server Mgmt)

▶
2.2.a Initial Setup

Bring-Up

  • Fabric Interconnects (FI-A/FI-B) run initial setup wizard → cluster IP + per-FI mgmt IPs, then form an HA cluster
  • 5108 chassis discovered automatically once FEX/IOM (2204/2208/2408) links to FI are up and chassis discovery policy is satisfied
  • Chassis/FEX discovery policy: link-grouping preference + minimum-links determine when a chassis is marked "discovered"
2.2.b Infrastructure Management

Building Blocks

  • Fabric Interconnect = unified L2 switch + management plane (runs UCS Manager)
  • IOM/FEX (I/O Module) in chassis = extends FI ports into the chassis backplane, no local switching (all forwarding at parent FI)
  • End-Host Mode (default) vs Switch Mode for uplinks — EHM avoids STP loops toward upstream by pinning server vNICs to specific uplinks
2.2.c Network Management

VLANs / Pools / Policies / Templates / QoS

  • VLANs defined globally on FI, tagged to vNIC templates; native VLAN per uplink/vNIC
  • MAC address pools assign unique MACs to vNICs automatically per Service Profile
  • vNIC templates standardize MTU, VLANs, fabric failover, QoS policy, pin group across many profiles
  • QoS System Class: Platinum/Gold/Silver/Bronze/Best-Effort/FC classes with CoS + weight + MTU per class; Fibre Channel class always no-drop
2.2.d Storage Management

SAN / FC Zoning / VSANs / WWN

  • vHBAs assigned WWPN from WWN pools; VSANs map to specific FC uplinks on each fabric (A/B)
  • UCS supports local zoning (UCSM manages FC zoning directly) or upstream NPV mode to an external MDS/Nexus SAN switch handling zoning
  • SAN connectivity policies + storage connection policies template vHBA-to-target mappings
2.2.e Server Management

Server Pools / Boot Policies

  • Server pools + pool policies + qualification policies auto-assign physical blades that meet HW criteria to a Service Profile
  • Boot policy defines ordered boot devices (Local disk, SAN, vNIC/PXE, vMedia/CIMC-mapped, UEFI/Legacy) — decoupled from hardware so profiles are hardware-agnostic
  • Service Profile = the full identity abstraction (UUID, MACs, WWNs, boot order, firmware, BIOS policy) that can move between blades = true stateless computing
Sources: Cisco UCS Manager GUI Configuration Guide (Network, Storage, Server Management chapters) · Cisco UCS Manager Infrastructure Management Guide
2.3

UCS-X in Intersight Managed Mode (IMM)

▶

UCS-X Platform

  • UCS X9508 chassis with X-Fabric architecture — modular compute nodes (X210c) + future-ready PCIe resource nodes (GPU) without a forklift
  • Uses Fabric Interconnects (6400/6500 series) as the fabric, but the management plane can be UCS Manager or Intersight Managed Mode

Intersight Managed Mode (IMM)

  • Fabric Interconnects register directly to Cisco Intersight (cloud-based SaaS management) — no local UCS Manager GUI on the FI
  • Replaces Service Profiles with Server Profiles built from reusable Policies (BIOS, boot, network, storage, etc.) and Profile Templates
  • Enables cross-domain, multi-site management, HCL compliance checks, and API-first automation (Terraform/Ansible/Python SDK) from a single pane
Key distinction: UCSM Mode = local FI-hosted management, classic Service Profiles. IMM = cloud-hosted (Intersight) management, Server Profiles built from modular policies — required for newest UCS-X compute nodes' full feature set.
Sources: Cisco Intersight Managed Mode Configuration Guide · Cisco UCS X-Series data sheet
2.4

Firmware & Software Updates — Impacts on Blade and Rack Servers

▶

UCS Manager Domain

  • Infrastructure Firmware (FI, IOM) upgraded via Auto Install / Firmware Auto Sync — FI upgrade is disruptive to that fabric side (do A then B, staggered, since vNIC/vHBA failover keeps hosts up)
  • Host Firmware Packages (HFP) bundle BIOS/CIMC/adapter/RAID controller versions applied via Service Profile — server reboot required (disruptive to that server only)
  • Maintenance Policies (immediate / user-ack / timer-automatic) control WHEN a disruptive change actually applies

Intersight / Standalone

  • Intersight Firmware Upgrade uses HUU (Host Upgrade Utility) bundles — orchestrated, one server (or group) at a time to limit blast radius
  • CIMC-only updates on standalone C-Series can often be nondisruptive to the OS if applied without a reboot flag, but BIOS/RAID firmware always require a reboot
Sources: Cisco UCS Firmware Management Guide · Cisco Intersight Infrastructure Service documentation
2.5

Compute Configuration Management — Backup & Restore

▶

UCS Manager Backup Types

  • Full state — binary snapshot, used to fully restore/rebuild a UCSM cluster (same version required)
  • All configuration — XML, logical + physical config, portable across versions, not a full disaster-recovery image
  • System configuration — logical only (pools, policies, service profiles)
  • Logical configuration — pools/policies/profiles only, no physical inventory

Scheduling & Restore

  • Backups can be scheduled (full-state / all-config) to a remote SCP/FTP/TFTP/SFTP server
  • Restore of "Full State" requires booting a fresh/erased FI pair into the same UCSM version, then importing the backup
  • Intersight offers cloud-based configuration backup/export of Server/Policy definitions as part of its SaaS model
Sources: Cisco UCS Manager Administration Management Guide — Backup and Import chapter
2.6

Infrastructure Monitoring — SPAN and Cisco Intersight

▶

SPAN in UCS

  • UCS Manager supports SPAN sourced from server vNIC/vHBA or uplink border ports to a local or remote (ERSPAN) destination — useful for VM/traffic troubleshooting through the fabric

Cisco Intersight

  • SaaS telemetry: hardware health, HCL compliance, capacity, advisories (PSIRT/Field Notices) proactively surfaced
  • Intersight Workload Optimizer (add-on) correlates compute/storage/app performance for capacity planning
  • Supports webhook/API export of telemetry to external monitoring (Splunk, syslog, SNMP trap forwarding)
Sources: Cisco UCS Manager Network Management Guide (SPAN) · Cisco Intersight Help Center

Domain 3.0 — Storage Network

20%
3.1

Implement Fibre Channel — Fabric Init, Port-Channel, FCID, CFS, Zoning, FCNS, Device-Alias, NPV/NPIV, VSAN

▶

3.1.a Switch Fabric Initialization

  • Principal switch election via Domain_ID negotiation (Build Fabric / BF, Reconfigure Fabric / RCF) — lowest priority + WWN wins principal role
  • FLOGI (Fabric Login) — N-port logs into the fabric, gets FCID; FDISC for additional NPIV logins; PLOGI = N-port to N-port login

3.1.b Port-Channels

  • FC port-channel bundles multiple ISLs into one logical link — load balances (src-id/dst-id/OX-ID) and survives single-link failure without FSPF re-route/fabric disruption
  • Modes: active (PCP protocol negotiates) or on (static)

3.1.c FCID

  • 24-bit Fibre Channel ID = Domain(8) . Area(8) . Port(8) — assigned at FLOGI, analogous to an IP address for FC

3.1.d CFS

  • Cisco Fabric Services — distributes/synchronizes configuration (zoning, device-alias, NTP, etc.) fabric-wide without manual per-switch config; uses a lock/commit/distribute model

3.1.e Zoning

  • Restricts which N-ports can communicate — WWPN-based (most common), FCID-based, or device-alias-based; enforced at hardware (hard) or soft (advisory) level
  • Active vs Full zoneset: only the active zoneset enforces traffic; changes require zoneset activate
  • Smart-zoning reduces TCAM entries by only programming needed initiator↔target pairs within a zone containing many members

3.1.f FCNS

  • Fibre Channel Name Server — per-VSAN distributed database of all logged-in N-ports (WWPN, FCID, FC4 type, symbolic name) — the FC equivalent of DNS/ARP combined

3.1.g Device Alias

  • Maps a friendly name to a WWPN, fabric-wide via CFS distribution — used directly in zoning ("device-alias mode enhanced" allows using aliases like real zone members without pWWN duplication)

3.1.h NPV / NPIV

  • NPIV (N-Port ID Virtualization) — a single physical HBA/uplink port logs in multiple virtual N-ports (multiple FCIDs), used for VM/blade/UCS virtualization
  • NPV (N-Port Virtualizer) — an edge switch (e.g., MDS 9148 in NPV mode, or UCS FI) doesn't join the fabric as a domain; it proxies FLOGIs upstream to conserve Domain IDs at scale
  • NPV switch requires NPIV enabled on the upstream core/edge switch it connects to

3.1.i VSAN

  • Virtual SAN — logically partitions one physical fabric into multiple isolated fabrics (own zoning DB, FCNS, services, even own Domain_ID space), similar to VLANs for FC
  • Trunking (E_port → TE_port) carries multiple VSANs over one ISL, tagged like 802.1Q but FC-specific (EISL)
! MDS zoning + device-alias example device-alias database device-alias name Host1 pwwn 20:00:00:25:b5:00:00:01 device-alias commit vsan database vsan 10 name PROD_SAN_A zone name Z_Host1_ArrayA vsan 10 member device-alias Host1 member device-alias ArrayA_P0 zoneset name ZS_PROD vsan 10 member Z_Host1_ArrayA zoneset activate name ZS_PROD vsan 10
Sources: Cisco MDS 9000 Fabric Configuration Guide (Fabric Init, Zoning, FCNS) · Cisco MDS 9000 NPV/NPIV Configuration Guide
3.2

Network Storage Systems & Concepts — NFS and iSCSI

▶

NFS

  • File-level (not block) network storage protocol — server exports a directory, client mounts it over the IP network
  • NFSv3 stateless (uses separate MOUNT/lock/NLM protocols); NFSv4 stateful, integrated locking, built-in Kerberos (RPCSEC_GSS) security, single TCP port 2049

iSCSI

  • Block-level SCSI commands encapsulated in TCP/IP (RFC 7143) — lets an IP network carry SAN traffic without dedicated FC hardware
  • Initiator (host) ↔ Target (array) identified by IQN (iSCSI Qualified Name); discovery via SendTargets or iSNS
  • Best practice: dedicated VLAN/subnet, jumbo frames, and multi-pathing (MPIO) for resiliency; can be secured with CHAP authentication
AttributeNFSiSCSI
Access levelFileBlock
TransportTCP/UDP (v3), TCP (v4)TCP (port 3260)
Typical useNAS shares, VM datastores (NFS export)SAN LUN presentation over Ethernet
Sources: RFC 7530 (NFSv4) · RFC 7143 (iSCSI) · Cisco Nexus/MDS IP Storage Networking documentation
3.3

Software Updates & Impacts — Disruptive/Nondisruptive and EPLD (SAN)

▶

MDS / SAN NX-OS ISSU

  • Dual-supervisor MDS directors support nondisruptive ISSU — active/standby sup switchover keeps FC fabric services up while linecards are upgraded in sequence
  • Fixed-config Fabric Switches (single sup) — ISSU still often nondisruptive to attached hosts due to NPV/port-channel resiliency, but the switch's own control-plane briefly restarts

EPLD (SAN context)

  • Same concept as Nexus LAN switches — programmable hardware logic on line cards/supervisors; EPLD upgrade requires a module reload and is disruptive to ports on that module
  • Always check the EPLD compatibility matrix in release notes before an NX-OS upgrade on MDS platforms
Sources: Cisco MDS 9000 NX-OS Software Upgrade and Downgrade Guide · Cisco MDS 9000 EPLD Release Notes
3.4

Infrastructure Monitoring — SPAN and Cisco Nexus Dashboard (SAN)

▶

SPAN on MDS

  • SD-Port (SPAN Destination port) mirrors FC traffic from a source port/VSAN to an attached analyzer (e.g., Cisco NGA / Nexus Dashboard Insights probe)
  • Remote SPAN over FC (FC-RSPAN not standard like Ethernet RSPAN) — typically local SD-port per switch or Fabric Analytics telemetry export instead

Cisco Nexus Dashboard (SAN Insights)

  • Nexus Dashboard Fabric Controller (NDFC) — SAN mode replaces legacy DCNM SAN — fabric-wide topology, zoning management, and health
  • SAN Insights streams MDS analytics (via SAN Telemetry Streaming, STS) for IOPS, latency (ECT/read-write), and link utilization down to the flow level
Sources: Cisco MDS 9000 System Management Guide (SPAN) · Cisco Nexus Dashboard Fabric Controller — SAN Insights Guide

Domain 4.0 — Automation and Artificial Intelligence

15%
4.1

Automation & Scripting Tools — EEM, Scheduler, Bash/Guest Shell, REST API, On-Box Python

▶

EEM (Embedded Event Manager)

  • Event detectors (syslog, CLI, SNMP, track, interface, timer) trigger an Applet (simple actions) or a Policy (Tcl script) — enables self-healing/local automation without an external controller
  • Common exam pattern: match a syslog pattern → run action to shut/no-shut an interface or send an email/syslog

Scheduler

  • NX-OS native cron-like job scheduler — runs CLI command scripts at a defined time or interval (schedule job + job name)
  • Common for scheduled backups (copy run to TFTP), periodic show tech collection

Bash Shell / Guest Shell (NX-OS)

  • Bash-shell = direct native Linux shell in the NX-OS underlying OS (feature bash-shell) — full root-level access, use with care
  • Guest Shell = isolated, resource-limited Linux container (CentOS-based) running alongside NX-OS — safer sandbox for scripts, has its own package manager (yum/pip) and network namespace

REST API (NX-API)

  • NX-API CLI — wraps normal CLI show/config commands in a REST/HTTPS call, JSON or XML encoded request/response
  • NX-API REST (on Nexus 9000 in ACI or NX-OS mode) — object-model based CRUD against the device MIT (Management Information Tree)
  • Enable with feature nxapi; sandbox tool at https://<switch>/ins.html aids request-building

On-Box Python

  • Native Python interpreter embedded in NX-OS (feature python, then python at CLI or scripts under bootflash) — direct access to CLI + internal APIs via the cli module
  • Great for local scripted validation/remediation without needing an external automation server
! EEM applet example event manager applet SHUT_ON_ERR event syslog pattern "ERR_DISABLE" action 1.0 cli command "interface e1/1" action 2.0 cli command "shutdown" action 3.0 syslog msg "Interface shut due to err-disable event"
Sources: Cisco NX-OS System Management Config Guide (EEM, Scheduler) · Cisco NX-OS Programmability Guide (Bash/Guest Shell, NX-API, Python)
4.2

Automation & Orchestration Technologies — Ansible, Python, POAP, Nexus Dashboard, PowerShell, Terraform CLI, Intersight

▶

Ansible

  • Agentless, SSH/NX-API push, idempotent YAML playbooks; cisco.nxos collection modules (nxos_vlans, nxos_facts, nxos_config, etc.) mirror the IOS resource-module pattern

Python

  • Off-box automation typically uses NX-API (via requests) or SDKs (e.g., ncclient for NETCONF, Cisco's aci-cobra/acicobra SDK for ACI) to drive config at scale

POAP

  • PowerOn Auto Provisioning — a factory-default Nexus switch DHCP-discovers a bootstrap script + config/image from a server, fully automating zero-touch provisioning at initial deployment

Cisco Nexus Dashboard

  • NDO/NDFC provide template + intent-based orchestration across multiple ACI/VXLAN fabrics — push consistent policy from a single source of truth

PowerShell

  • Cisco provides PowerShell modules/cmdlets for UCS (Cisco PowerTool) and Intersight for Windows-centric automation teams

Terraform CLI

  • Declarative, state-file-based IaC; Cisco publishes providers for ACI, Intersight, and Nexus Dashboard/NDFC — terraform plan/apply/destroy workflow manages fabric objects as HCL resources

Intersight

  • Cloud-native SaaS orchestration hub — REST API + Python/PowerShell/Go/Terraform SDKs, plus native Workflow Designer (Intersight Cloud Orchestrator) for low-code automation across UCS/HyperFlex/third-party
Sources: Cisco DevNet — NX-OS/ACI/Intersight Automation documentation · Cisco Nexus 9000 POAP Config Guide · Terraform Registry — Cisco ACI/Intersight providers
4.3

High-Performance Networking to Enable AI in the Data Center

▶

Why AI/ML Changes the Fabric

  • GPU-to-GPU training traffic is extremely bursty and latency/loss sensitive — a single dropped flow can stall an entire distributed training job (all-reduce collective operations)
  • Requires lossless, low-latency, high-bandwidth non-blocking CLOS fabrics ("AI/ML fabric")

Cisco Building Blocks

  • Nexus 9000 for AI/ML — deep-buffer, high-radix 400G/800G leaf-spine designs tuned for RoCEv2 (RDMA over Converged Ethernet)
  • Congestion control: ECN (Explicit Congestion Notification), PFC (Priority Flow Control, 802.1Qbb) for lossless RoCE; DCQCN as the end-to-end congestion algorithm
  • Cisco Silicon One ASIC — dynamic load balancing / adaptive routing across the fabric to avoid ECMP hashing hot-spots common with elephant AI flows

Alternatives

  • InfiniBand remains a competing fabric for HPC/AI clusters; Cisco's Ethernet-based approach targets equivalent performance with standards-based Ethernet/RoCEv2 to ease operations and multi-vendor interop
Sources: Cisco Data Center Networking Blueprint for AI/ML white paper · Cisco Nexus 9000 RoCEv2/PFC/ECN Configuration Guide

Domain 5.0 — Security

15%
5.1

Apply Network Security — AAA/RBAC, ACI Contracts, FHS, Keychain, MACsec

▶

AAA / RBAC

  • TACACS+ (per-command authorization, encrypts full payload) vs RADIUS (UDP, encrypts only password, better for network access/VPN) as centralized AAA backends
  • NX-OS RBAC = user Roles with rule-based command/feature permissions; default roles: network-admin, network-operator; custom roles scoped to specific VDCs/features

ACI Contracts & Microsegmentation

  • Contract = Subject(s) containing Filters (protocol/port rules) + action (permit/deny/log) applied between Provider and Consumer EPGs
  • vzAny simplifies contracts applying to all EPGs in a VRF
  • uSeg EPGs apply security policy per-VM attribute (name, MAC, IP, VNIC) rather than by subnet — true microsegmentation independent of L2/L3 topology
  • Intra-EPG isolation blocks even same-EPG endpoint-to-endpoint traffic when required

First-Hop Security (FHS)

  • DHCP Snooping — builds a trusted binding table (IP-MAC-VLAN-port), drops rogue DHCP server replies on untrusted ports
  • Dynamic ARP Inspection (DAI) — validates ARP against the DHCP snooping binding table, defeats ARP spoofing/MITM
  • IP Source Guard — filters traffic on a port to only the source IP/MAC seen in the DHCP snooping table
  • RA Guard / ND Inspection — IPv6 equivalents blocking rogue Router Advertisements and validating Neighbor Discovery

Keychain Authentication

  • A "keychain" holds multiple keys each with its own send/accept lifetime — allows scheduled, hitless key rollover for routing-protocol authentication (OSPF, EIGRP, BGP MD5/keychain, HSRP)
  • Prevents a single static shared-secret from being the sole protection indefinitely; supports crypto algorithm upgrades (e.g., MD5 → HMAC-SHA)

MACsec

  • IEEE 802.1AE — line-rate, hop-by-hop L2 encryption/integrity on switch-to-switch or switch-to-host links
  • Key exchange via MKA (MACsec Key Agreement, 802.1X-2010) using a Connectivity Association Key (CAK)
  • Nexus platforms support MACsec on fabric/uplink ports for encrypting DC interconnect (DCI) traffic in flight, including line-rate MACsec on 100G+ links
! NX-OS keychain example key chain OSPF_KEYS key 1 key-string 7 accept-lifetime 00:00:00 Jan 1 2024 00:00:00 Jul 1 2024 send-lifetime 00:00:00 Jan 1 2024 00:00:00 Jul 1 2024
Sources: Cisco NX-OS Security Configuration Guide (AAA, RBAC, FHS, MACsec, Keychain) · Cisco APIC Security Configuration Guide (Contracts, Microsegmentation)
5.2

Apply Compute Security — AAA and RBAC (UCS/Intersight)

▶

UCS Manager

  • Locales + Org-permissions scope which sub-organizations/pods an admin can manage (multi-tenant RBAC)
  • Built-in roles: admin, aaa, operations, read-only, server-compute, storage, network, etc. — combine roles + locales for fine-grained delegated admin
  • Supports LDAP/RADIUS/TACACS+ remote authentication with role/locale mapped via LDAP group attributes

Intersight

  • Account-based RBAC with built-in roles (Account Administrator, Read-Only, Device Technician, etc.) applied per Organization/Resource Group for multi-tenant SaaS delegation
  • API keys (with optional OAuth2) provide programmatic auth separate from interactive SSO/user login
Sources: Cisco UCS Manager Administration Guide (RBAC) · Cisco Intersight Access & Permissions documentation
5.3

Apply Storage Security — AAA/RBAC, Port Security, Fabric Binding

▶

AAA / RBAC (MDS)

  • Same TACACS+/RADIUS AAA model as NX-OS LAN switches; MDS role-based CLI restricts config/show access per VSAN scope, useful for multi-tenant SAN admin delegation

Port Security (FC)

  • Locks down which pWWN/sWWN may log into a specific switch port — prevents unauthorized device or rogue switch connection to the fabric
  • Activated per-VSAN; auto-learn mode can build the initial allowed list before locking it down

Fabric Binding

  • Restricts which switches (by WWN) are allowed to form ISLs into the fabric — protects against unauthorized/rogue switch merges corrupting zoning/domain IDs
  • Complements port security (host-level) by securing switch-to-switch (E-port/ISL-level) trust
Sources: Cisco MDS 9000 Security Configuration Guide (Port Security, Fabric Binding, AAA/RBAC)

Reference

R.1

Quick-Reference Numbers

▶
VXLAN UDP port4789
VXLAN VNI bits24 (16.7M)
VLAN ID range1–4094
VSAN ID range1–4093
FCID bits24 (Dom.Area.Port)
iSCSI TCP port3260
NFSv4 TCP port2049
HSRP v1 multicast224.0.0.2 / UDP 1985
HSRP v2 multicast224.0.0.102
VRRP multicast224.0.0.18
Recommended jumbo MTU (VXLAN)9216
Max NX-OS LACP links16 (8 active+8 standby)
MACsec standardIEEE 802.1AE
LACP standardIEEE 802.3ad
RSTP standardIEEE 802.1w
MST standardIEEE 802.1s
R.2

CLI Cheat Sheet — Show Commands by Domain

▶
CommandPurpose
show vpc briefvPC role, peer status, consistency checks
show nve peers / show nve vniVXLAN VTEP peers and VNI state
show bgp l2vpn evpnEVPN Type-2/3/5 routes
show ip ospf neighborOSPF adjacency state
show install all impactPredict disruptive vs nondisruptive upgrade
show flogi databaseFC N-ports logged into the fabric + FCID
show fcns databaseFC Name Server entries per VSAN
show zoneset activeCurrently enforced FC zoning
show port-securityFC port security bindings
show fabric-binding databaseAllowed switch WWNs in fabric
show feature | include nxapiConfirm NX-API is enabled
show telemetry data collector detailsMDT streaming session status
R.3

Primary Sources Used for This Guide

▶

Official Cisco & Standards Documentation

  • Cisco 350-601 DCCOR v1.2 Exam Topics (official blueprint, 2024)
  • Cisco Nexus 9000 Series NX-OS Configuration Guides — Unicast Routing, Interfaces, VXLAN, System Management, Security, Programmability
  • Cisco MDS 9000 Series NX-OS Configuration Guides — Fabric, Security, System Management, Software Upgrade
  • Cisco APIC / ACI Fundamentals, Basic Configuration, Virtualization, and Security Guides
  • Cisco UCS Manager GUI Configuration & Administration Guides; Cisco Intersight / Intersight Managed Mode documentation
  • Cisco Nexus Dashboard, Nexus Dashboard Insights, Orchestrator, and Fabric Controller (NDFC) User Guides
  • RFC 7348 (VXLAN), RFC 8365 (EVPN NVO), RFC 7938 (BGP in the DC), RFC 7143 (iSCSI), RFC 7530 (NFSv4)
  • NIST Special Publication 800-145 — The NIST Definition of Cloud Computing
  • IEEE 802.1AE (MACsec), 802.3ad (LACP), 802.1w (RSTP), 802.1s (MST)
Note: This guide is an independent study aid summarizing publicly available Cisco documentation and industry standards for exam preparation. It is not an official Cisco publication. Always cross-reference the current official exam topics and Cisco documentation, since content/versions change over time.