Cisco Expert

350-601

Implementing and Operating Cisco Data Center Core Technologies

The Cisco 350-601 DCCOR (Implementing and Operating Cisco Data Center Core Technologies) exam is the core requirement for the CCNP Data Center certification. This expert-level exam validates comprehensive knowledge and skills required to implement and operate Cisco data center infrastructure including network, compute, storage networking, automation, and security technologies.

The exam covers five comprehensive domains: Network (25%), Compute (25%), Storage Network (20%), Automation (15%), and Security (15%). Candidates must demonstrate proficiency with Cisco Nexus switches, Cisco UCS (Unified Computing System), Cisco MDS storage switches, Cisco ACI (Application Centric Infrastructure), network automation tools, and data center security best practices.

Key skills tested include configuring VLANs, spanning tree, and routing protocols in data center networks, implementing vPC and FabricPath for high availability, deploying and managing Cisco UCS blade and rack servers, configuring storage area networks (SAN) with Fibre Channel and FCoE, implementing Cisco ACI fabric and policy model, automating data center operations using Python, Ansible, and REST APIs, and securing data center infrastructure with microsegmentation and network security policies. This certification is essential for network and infrastructure engineers responsible for modern data center operations.

Updated 2024 Networking

90

Questions

6

Practice Tests

83%

Pass Score

34

Views

0

Total Attempts

0%

Avg. Score

0%

Pass Rate

0

Discussions

Practice Tests Flash Cards Exam Topics Cheat Sheet

€5.00

DCCOR Practice Exam 1

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

€5.00

DCCOR Practice Exam 2

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

€5.00

DCCOR Practice Exam 3

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

€5.00

DCCOR Practice Exam 4

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

€5.00

DCCOR Practice Exam 5

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

€5.00

DCCOR Practice Exam 6

Comprehensive 50-question practice exam covering networking, compute, storage networking, automation, and security for the Cisco DCCOR Data Center Core certification.

50 Q 90 minutes 70%

Test Drive

Unlock All Content for 350-601

6 Practice Test(s) + Flash Cards — 3 months access

€39.99 €26.99 Save 30%

or included with Monthly subscription / Content Bundle

350-601 Cheat Sheet

Quick reference guide - 6 sections

Free Access

DCCOR 350-601 Exam Details

Detail	Value
Exam Code	350-601 DCCOR
Full Name	Implementing and Operating Cisco Data Center Core Technologies
Duration	120 minutes
Number of Questions	55-65 questions
Passing Score	~825 / 1000
Question Format	Multiple choice, multiple response, drag-and-drop
Exam Fee	$400 USD
Certification Level	Professional (CCNP Data Center core exam)

Domain Weight Breakdown

Domain	Weight
1.0 Networking	25%
2.0 Compute	25%
3.0 Storage Networking	20%
4.0 Automation	15%
5.0 Security	15%

Certification Path & Prerequisites

The 350-601 DCCOR is the core exam required for the CCNP Data Center certification. Candidates must also pass one concentration exam (such as 300-610 DCID, 300-615 DCIT, 300-620 DCACI, 300-625 DCSAN, or 300-635 DCAUTO) to earn the full CCNP Data Center credential. Passing DCCOR alone also earns the Cisco Certified Specialist - Data Center Core designation.

The exam covers five major data center technology domains: networking protocols and fabric architectures, compute platforms (Cisco UCS), storage networking (Fibre Channel, FCoE, iSCSI), automation and orchestration, and data center security. Candidates should have three to five years of experience implementing and operating data center technologies before attempting this exam.

Tip: The Networking and Compute domains together account for 50% of the exam. Focus heavily on VXLAN/EVPN overlays and UCS architecture for the best score impact.

VXLAN (Virtual Extensible LAN)

VXLAN is the primary overlay encapsulation technology in modern data center fabrics. It extends Layer 2 segments over a Layer 3 underlay network, enabling scalable multi-tenancy beyond the 4094 VLAN limit.

Property	Details
Encapsulation	Original L2 frame wrapped in UDP (dest port 4789) with outer IP/MAC headers
VNI (VXLAN Network Identifier)	24-bit identifier = up to 16 million logical segments
VTEP (VXLAN Tunnel Endpoint)	Encapsulates/decapsulates VXLAN traffic; identified by its IP address
Overhead	50 bytes added (outer Ethernet 14 + outer IP 20 + UDP 8 + VXLAN header 8)
MTU Requirement	Minimum 1550 bytes on underlay (9000+ recommended for jumbo frames)

Tip: VXLAN uses a MAC-in-UDP encapsulation model. The 24-bit VNI maps to VLANs locally on each VTEP, enabling L2 extension across L3 boundaries.

VXLAN with BGP EVPN Control Plane

BGP EVPN (Ethernet VPN, address family L2VPN EVPN) replaces flood-and-learn with a standards-based control plane for VXLAN. It distributes MAC and IP reachability information via MP-BGP, enabling efficient forwarding without data-plane flooding.

Route Type 2 (MAC/IP Advertisement): Distributes host MAC and IP bindings learned on local VTEPs to all remote VTEPs. Enables silent host detection and ARP suppression.
Route Type 3 (Inclusive Multicast Ethernet Tag): Autodiscovers VTEPs participating in a given VNI and builds the ingress replication list for BUM (Broadcast, Unknown unicast, Multicast) traffic.
Route Type 5 (IP Prefix Route): Advertises IP prefixes for inter-VNI (inter-subnet) routing across the fabric, enabling distributed anycast gateway routing.
ARP Suppression: The VTEP answers ARP requests locally using the EVPN MAC/IP binding table, reducing broadcast flooding across the fabric.
Distributed Anycast Gateway: All leaf switches share the same gateway IP and virtual MAC (e.g., via fabric forwarding anycast-gateway-mac), providing optimal first-hop routing regardless of which leaf the host is connected to.

OTV (Overlay Transport Virtualization)

OTV extends Layer 2 domains across geographically separated data centers over a Layer 3 transport network without the risks of traditional L2 DCI (no STP propagation).

Edge Device: Performs OTV encapsulation/decapsulation. Has a join interface (facing the transport) and internal interfaces (facing the local site).
MAC-in-IP Encapsulation: OTV wraps original L2 frames in an IP/GRE header for transport across the WAN.
STP Isolation: OTV does NOT forward BPDUs between sites, preventing STP loops across the DCI link.
AED (Authoritative Edge Device): For each VLAN, one OTV edge device per site is elected as the AED to forward traffic, preventing duplicate frames.
Use Case: Data center interconnect (DCI) for VM mobility, disaster recovery, and workload migration without merging STP domains.

LISP (Locator/Identifier Separation Protocol)

LISP separates endpoint identity (EID) from network location (RLOC), enabling host mobility and multi-homing without renumbering. Used in Cisco SD-Access as the control plane protocol.

Component	Role
EID (Endpoint Identifier)	The IP address of the host (identity, does not change on movement)
RLOC (Routing Locator)	The IP address of the router (location in the network topology)
Map Server (MS)	Accepts EID-to-RLOC registrations from ETRs and stores the mapping database
Map Resolver (MR)	Receives map-requests from ITRs and resolves them against the mapping database
ITR (Ingress Tunnel Router)	Encapsulates traffic toward the destination RLOC
ETR (Egress Tunnel Router)	Decapsulates traffic and delivers to the local EID

Data Center Routing Protocols

Protocol	Role in Data Center	Key Characteristics
IS-IS	VXLAN/EVPN underlay IGP	Link-state, fast convergence, used in ACI fabric underlay. Uses NET addresses, protocol-independent (runs directly on L2).
OSPF	Underlay routing alternative	Link-state, area-based hierarchy. Common in NX-OS-based fabrics. Uses Area 0 backbone with multi-area designs for large-scale DC.
BGP (eBGP)	Underlay + overlay control plane	Preferred underlay in spine-leaf designs (RFC 7938). Each switch has unique ASN. Also carries EVPN address family for overlay.
MP-BGP (iBGP)	EVPN overlay control plane	Carries L2VPN EVPN routes between VTEPs. Spine switches act as route reflectors to reduce full-mesh iBGP peering.

Tip: In a modern VXLAN/EVPN fabric, eBGP is used for underlay reachability (advertising loopback/VTEP IPs) and iBGP with EVPN address family is used for overlay MAC/IP advertisement. Spine switches serve as iBGP route reflectors.

vPC (Virtual Port Channel)

vPC allows two Nexus switches to appear as a single logical switch to downstream devices, providing active-active redundancy without STP blocking. Critical for data center access and aggregation layer designs.

Component	Description
vPC Peer Link	10G/40G/100G port channel between two vPC peers. Carries BPDUs, HSRP, and orphan traffic. Must be at least a 2-member port channel.
vPC Peer Keepalive	Heartbeat link (mgmt0 or dedicated L3 link) to detect peer failures. Uses UDP port 3200.
vPC Domain	Logical grouping of the two peer switches. Must use matching domain ID on both peers.
vPC Member Port	Port channel on each peer that connects to the downstream device, sharing the same vPC ID number.
Orphan Port	A single-attached device connected to only one vPC peer. Traffic uses the peer link if destination is on the other peer.

Consistency Checks: Type 1 (strict) parameters must match exactly or the vPC will not come up (e.g., STP mode, VLAN membership, MTU). Type 2 (graceful) parameters should match but will only generate warnings (e.g., STP port priority, storm control).

FEX (Fabric Extender)

Cisco Nexus Fabric Extenders (e.g., Nexus 2000 series) act as remote line cards of a parent Nexus switch. The FEX itself has no local control plane; all forwarding decisions are made by the parent switch. FEX connects to the parent via FEX fabric interfaces (typically 10G or 40G uplinks) and presents host-facing ports (1G or 10G) to servers.

Straight-through FEX: FEX connected to a single parent switch.
Active-Active FEX (dual-homed): FEX uplinks to two parent switches in a vPC pair, providing redundancy.
Benefits: Simplified management (single point of configuration), reduced switch count in ToR deployments, centralized policy enforcement.

Spine-Leaf Architecture

The spine-leaf (Clos) topology is the standard data center fabric design. Every leaf switch connects to every spine switch, providing consistent low-latency paths and predictable bandwidth scaling.

Leaf Switches: Top-of-rack (ToR) switches connecting servers, storage, and firewalls. Act as VTEPs in VXLAN fabrics.
Spine Switches: Interconnect all leaf switches. Provide only transit/forwarding; no host connections. Serve as BGP route reflectors in EVPN designs.
Border Leaf: Connects the fabric to external networks (WAN, internet, other DCs). Handles inter-fabric and north-south traffic.
Equal-Cost Multi-Path (ECMP): All paths from any leaf to any other leaf traverse exactly one spine hop, enabling full ECMP utilization.

Cisco UCS Architecture Overview

Cisco Unified Computing System (UCS) integrates compute, networking, storage access, and virtualization into a single cohesive system managed by a central controller. UCS eliminates the traditional silos between server, network, and storage teams.

Component	Description
UCS Fabric Interconnect (FI)	Central management and network connectivity point. Typically deployed in pairs (A/B) for redundancy. Provides LAN, SAN, and management connectivity.
UCS B-Series (Blade)	Half-width and full-width blade servers housed in UCS 5108 chassis. Connected to FIs via I/O Modules (IOMs). Best for high-density deployments.
UCS C-Series (Rack)	Standalone rack-mount servers (1U/2U/4U). Can be managed standalone via CIMC or integrated into UCS domain via FIs.
UCS X-Series	Next-generation modular platform using X9508 chassis and X210c compute nodes. Managed via Cisco Intersight (cloud-based). Future-ready with midplane flexibility.
IOM (I/O Module)	Installed in the chassis, connects blade servers to the Fabric Interconnects. Acts as a distributed line card (no local switching intelligence).
UCS VIC (Virtual Interface Card)	Converged network adapter in each server. Creates virtual NICs (vNICs) and virtual HBAs (vHBAs) via hardware-based SR-IOV, eliminating the need for separate LAN and SAN adapters.

Service Profiles & Service Profile Templates

The service profile is the foundational concept in UCS management. It is a software definition of a server that encapsulates the complete identity and configuration of a physical server, including its BIOS settings, firmware policy, boot policy, network identity (MAC, WWNN, WWPN), and storage connectivity.

Service Profile: Defines UUID, MAC addresses, WWNs, VLAN/VSAN membership, boot order, BIOS policy, firmware packages, QoS policies, and server pool assignment. Associating a service profile to a blade or rack server provisions it completely.
Initial Template: Creates service profiles that are independent copies. Changes to the template do NOT propagate to already-created profiles. Use when individual customization is needed.
Updating Template: Created service profiles remain bound to the template. Changes to the template automatically propagate to all associated profiles. Ideal for consistent fleet management.
Server Mobility: If a blade fails, the service profile (identity) can be migrated to a spare blade. The replacement server boots with the same UUID, MAC, and WWN, so the SAN and network see it as the same server — zero reconfiguration on storage or network side.

Tip: Updating templates are the recommended best practice. They ensure consistency across all servers derived from the same template and simplify firmware and policy rollouts at scale.

UCS Manager vs. Cisco Intersight

Feature	UCS Manager (UCSM)	Cisco Intersight
Deployment Model	On-premises, embedded in Fabric Interconnects	Cloud-based SaaS platform (or Connected Virtual Appliance for air-gapped)
UCS Platforms	B-Series blades, C-Series (integrated mode)	B-Series, C-Series, X-Series, HyperFlex, and third-party servers
Configuration Model	Service profiles & templates (per domain)	Server profiles & policies (global, cross-domain)
Multi-Site Management	Per-domain only (one UCSM per FI pair)	Single pane of glass across all sites and domains worldwide
API	XML API	RESTful API with OpenAPI specification
Firmware Management	Host firmware packages per domain	Centralized firmware policies with HCL (Hardware Compatibility List) validation

Server Provisioning & Firmware Management

Boot Policy: Defines the boot order — local disk, SAN boot (from specific WWPN target/LUN), iSCSI boot, PXE, or virtual media. SAN boot is the preferred method in enterprise DCs for stateless computing.
Host Firmware Package: Bundles blade BIOS, adapter firmware, board controller, and storage controller firmware into a single manageable unit. Apply to service profiles for consistent firmware across the fleet.
Maintenance Policy: Controls when firmware changes take effect — immediate, user-ack (admin approves reboot), or scheduled timer window. Prevents unplanned downtime during firmware updates.
Server Pools: Group servers by characteristics (e.g., blade type, location). Service profiles use pool-based assignment so that any qualifying server can receive the identity. Enables rapid failover and scaling.
Management IP Pool: Assigns out-of-band management IPs (KVM) to each server from a defined CIMC address pool.

Blade Servers vs. Rack Servers

Factor	B-Series (Blade)	C-Series (Rack)
Form Factor	Half-width / full-width blade in UCS 5108 chassis	1U, 2U, or 4U standalone rack server
Density	Up to 8 half-width blades per 6U chassis	Lower density but more flexibility per server
Networking	Through IOM to Fabric Interconnects (shared backplane)	Direct cabling to FIs or standalone via CIMC
PCIe Expansion	Limited (mezzanine cards, VIC only)	Full PCIe slots for GPUs, NVMe, specialized adapters
Storage	Limited local disk (2-4 drives); typically SAN boot	More local storage capacity (up to 26+ drives in 2U/4U)
Best For	Virtualization, uniform workloads, high-density environments	GPU workloads, big data, applications needing local storage or special PCIe cards

Fibre Channel (FC) Fundamentals

Fibre Channel is a lossless, high-performance storage networking protocol designed for block-level storage access. It provides dedicated, deterministic bandwidth for storage traffic with guaranteed in-order delivery.

Concept	Description
WWNN (World Wide Node Name)	Unique identifier for a Fibre Channel node (server HBA or storage controller). Format: 20:00:00:25:B5:xx:xx:xx
WWPN (World Wide Port Name)	Unique identifier for a specific port on an FC node. Used for zoning and LUN masking. Format: 50:00:00:25:B5:xx:xx:xx
FLOGI (Fabric Login)	First step: HBA logs into the FC switch fabric and receives an FCID (FC address). Analogous to DHCP in IP networking.
PLOGI (Port Login)	Second step: Node-to-node login between initiator (server) and target (storage port) to establish a session.
PRLI (Process Login)	Third step: Establishes the upper-layer protocol (SCSI FCP) session parameters between initiator and target.
FCID	24-bit address assigned to a port after FLOGI (format: Domain.Area.Port, e.g., 0x010200). Domain ID identifies the switch.
FC Speeds	8G, 16G, 32G, 64G Fibre Channel. Auto-negotiation supported; both ends must match speed capabilities.

Tip: The FC login sequence is always FLOGI (fabric) → PLOGI (port-to-port) → PRLI (process). Remember this order for exam questions about FC initialization.

FC Zoning

Zoning is the FC equivalent of access control. It restricts which initiators can communicate with which targets within the SAN fabric, providing security and reducing unnecessary RSCN (Registered State Change Notification) traffic.

Zoning Type	Method	Characteristics
WWPN Zoning (Soft Zoning)	Uses WWPN of initiator and target	Most common and recommended. Device can move to any port without re-zoning. Enforced by the name server (software).
Port Zoning (Hard Zoning)	Uses switch port (domain, port index)	Enforced in hardware. More secure but inflexible — device must stay on the same port. Used in high-security environments.
Device Alias Zoning	Friendly names mapped to WWPNs	Simplifies management by using human-readable names (e.g., "server01_hba0" instead of raw WWPN). Recommended with WWPN zoning.
Smart Zoning	Automatic initiator/target role detection	Only creates active zone pairs between initiators and targets (not target-to-target). Reduces zone database size in large SANs.

Best Practice — Single-Initiator, Single-Target Zoning: Each zone should contain one server HBA (initiator) and one storage port (target). This minimizes RSCN disruption and simplifies troubleshooting. A zoneset is a collection of zones; only one zoneset can be active per VSAN at a time.

VSANs (Virtual SANs)

VSANs segment a physical SAN fabric into independent virtual fabrics, similar to VLANs in Ethernet. Each VSAN has its own name server, zone database, and fabric services. Traffic between VSANs requires an inter-VSAN routing (IVR) device.

VSAN 1: Default VSAN. All FC ports are initially in VSAN 1. Best practice is to create custom VSANs and move ports out of VSAN 1.
VSAN 4079: Isolated VSAN. Ports assigned here cannot communicate with any other VSAN. Used as a parking VSAN for unused ports.
VSAN 4094: Isolated VSAN (another reserved). Both 4079 and 4094 are reserved for isolation purposes.
VSAN Trunking: ISL (Inter-Switch Link) ports can carry multiple VSANs using VSAN trunking (E_port becomes TE_port). Only allowed VSANs are carried across the trunk.

FCoE (Fibre Channel over Ethernet)

FCoE encapsulates Fibre Channel frames within Ethernet frames, allowing FC and Ethernet traffic to share the same physical infrastructure. This enables I/O consolidation — a single Converged Network Adapter (CNA) replaces separate NICs and HBAs.

Concept	Details
EtherType	0x8906 for FCoE frames; 0x8914 for FIP (FCoE Initialization Protocol)
DCB (Data Center Bridging)	Required for lossless Ethernet: PFC (Priority Flow Control, 802.1Qbb), ETS (Enhanced Transmission Selection, 802.1Qaz), DCBX (Data Center Bridging Exchange)
FIP (FCoE Initialization Protocol)	Discovers FCoE capable switches (FCFs) and establishes virtual links before FCoE communication begins
FCF (FCoE Forwarder)	Switch that bridges FCoE traffic between Ethernet and native FC fabric (e.g., Nexus with FC modules)
VN-Port	Virtual N_Port on the CNA that represents the FC endpoint over Ethernet

Tip: FCoE requires lossless Ethernet (PFC must be enabled on the storage CoS class). FC is inherently lossless with credit-based flow control; FCoE must emulate this via PFC on the Ethernet side.

iSCSI (Internet Small Computer Systems Interface)

iSCSI transports SCSI commands over standard TCP/IP networks, enabling block-level storage access without dedicated FC infrastructure. Uses TCP port 3260.

Initiator: The client (server) that sends SCSI commands. Can be software-based (OS driver) or hardware-based (iSCSI HBA/TOE card).
Target: The storage system presenting LUNs via iSCSI. Identified by an iSCSI Qualified Name (IQN), e.g., iqn.2024-01.com.storage:array01.
CHAP Authentication: Challenge-Handshake Authentication Protocol secures initiator-target connections. Can be unidirectional (target verifies initiator) or mutual/bidirectional.
MPIO (Multipath I/O): Multiple iSCSI sessions across different network paths for redundancy and load balancing.
Advantages: Uses existing Ethernet infrastructure, lower cost than FC, easier to manage. Suitable for SMB and non-latency-critical workloads.

NVMe over Fabrics (NVMe-oF)

NVMe-oF extends NVMe (Non-Volatile Memory Express) across a network fabric, providing ultra-low-latency access to remote flash storage. Transport options include NVMe/FC (over Fibre Channel), NVMe/RoCE (RDMA over Converged Ethernet), and NVMe/TCP.

NVMe/FC: Runs NVMe commands natively over Fibre Channel. Leverages existing 32G/64G FC infrastructure. Supported on MDS 9000 series switches.
NVMe/TCP: Runs over standard TCP/IP; no RDMA or FC required. Easiest to deploy on existing Ethernet infrastructure.
Key Advantage: NVMe supports 64K queues with 64K commands per queue (vs. SCSI single queue of 32 commands), delivering massive parallelism and lower latency for modern flash storage.

Storage Policies in UCS

vHBA (Virtual HBA): Defined in the service profile. Specifies WWPN, VSAN assignment, and QoS for FC/FCoE connectivity from the server to the SAN fabric.
SAN Boot Policy: Configures the server to boot from a specific SAN target by defining primary and secondary boot paths (WWPN of the storage target + LUN ID).
WWNN/WWPN Pools: Pools of World Wide Names assigned to service profiles. Ensures consistent identity even when physical servers are replaced.
Storage Connection Policy (Intersight): Defines FC or iSCSI connectivity parameters, including VSAN/VLAN, target information, and authentication settings.

Cisco ACI (Application Centric Infrastructure)

ACI is Cisco's SDN solution for data centers. It uses a centralized controller (APIC) to manage a spine-leaf fabric built on Nexus 9000 switches running in ACI mode. ACI shifts from traditional CLI-based per-device configuration to a declarative policy model.

Component	Description
APIC (Application Policy Infrastructure Controller)	Centralized management cluster (typically 3 APICs for HA). Pushes policy to leaf and spine switches. Does NOT sit in the data path.
Spine Switches	Nexus 9500/9300 in ACI mode. Provide COOP (Council of Oracles Protocol) database for endpoint mapping and IS-IS for infrastructure routing.
Leaf Switches	Nexus 9300 in ACI mode. Connect to all endpoints (servers, storage, firewalls, WAN routers). Enforce policy locally.

ACI Policy Model (Logical Constructs)

ACI uses a hierarchical object model where all configuration is defined as managed objects in a tree structure (MIT — Management Information Tree). The key logical constructs are:

Construct	Description
Tenant	Top-level container for policies. Provides administrative isolation (e.g., per business unit, customer, or environment). Contains VRFs, BDs, APs, and EPGs.
VRF (Context)	Layer 3 forwarding domain (routing table). Each tenant can have multiple VRFs. Defines the IP address space and routing context.
Bridge Domain (BD)	Layer 2 forwarding domain associated with a VRF. Contains subnets (gateways). Equivalent to a VLAN + SVI in traditional networking. Controls L2 flooding behavior.
Application Profile (AP)	Logical container grouping EPGs that belong to the same application (e.g., "Web-App" containing Web, App, and DB tiers).
EPG (Endpoint Group)	Collection of endpoints with the same security policy. Endpoints are classified into EPGs based on port, VLAN, IP, or VM attributes. EPGs are the fundamental unit of policy enforcement.
Contract	Defines permitted communication between EPGs. Contains subjects (which reference filters with L4 rules). Without a contract, inter-EPG traffic is denied by default (whitelist model).

Tip: ACI follows a whitelist security model — all traffic between EPGs is denied unless explicitly permitted by a contract. Traffic within the same EPG is allowed by default. This is the opposite of traditional networking where all traffic is allowed unless blocked by an ACL.

Contracts, Subjects, and Filters

Contract: Applied between a provider EPG (offers a service) and a consumer EPG (consumes the service). Contracts are directional but can be bidirectional.
Subject: A grouping within a contract that references one or more filters. Subjects can also apply service graphs (L4-L7 devices like firewalls or load balancers).
Filter: Defines Layer 3/4 match criteria (IP protocol, ports). Example: TCP port 443 (HTTPS), TCP port 3306 (MySQL). Filters are reusable across multiple contracts.
vzAny: A shortcut to apply a contract to all EPGs in a VRF simultaneously. Useful for shared services (DNS, NTP, monitoring).
Preferred Group: EPGs within a preferred group can communicate freely without contracts. Only traffic to/from non-preferred-group EPGs requires explicit contracts.

Ansible for Data Center Automation

Ansible is the most widely used automation tool for Cisco data center environments due to its agentless architecture and extensive module library for NX-OS, ACI, UCS, and Intersight.

Module Collection	Use Case	Example Modules
cisco.nxos	NX-OS switch configuration	nxos_vxlan_vtep, nxos_bgp, nxos_vlan, nxos_interfaces, nxos_vpc
cisco.aci	ACI fabric policy management	aci_tenant, aci_bd, aci_epg, aci_contract, aci_filter
cisco.ucs	UCS Manager configuration	ucs_service_profile, ucs_vnic, ucs_vhba, ucs_lan_connectivity
cisco.intersight	Intersight server management	intersight_server_profile, intersight_boot_policy

NX-OS Programmability & REST APIs

NX-API REST: RESTful API on Nexus switches. Accepts JSON/XML payloads over HTTPS. Enabled with feature nxapi. Accessible via https://<switch-ip>/ins for NX-API CLI or /api for NX-API REST.
NX-API CLI: Sends CLI commands via HTTP POST (JSON-RPC). Useful for migration from CLI scripts to API-based automation. Returns structured JSON output.
NETCONF/YANG: Model-driven programmability using YANG data models over NETCONF (SSH, port 830). Supports candidate configuration, commit/rollback, and granular configuration retrieval.
gRPC/gNMI: High-performance streaming telemetry protocol. Supports dial-in and dial-out telemetry subscriptions for real-time monitoring of interface stats, BGP state, etc.
Python on NX-OS: Nexus switches include an embedded Python interpreter and the NX-OS SDK (cisco.nxos). Scripts can be run directly on the switch via python or scheduled as EEM (Embedded Event Manager) actions.
ACI REST API: APIC exposes its entire object model via REST API at https://<apic>/api. All GUI and CLI operations can be replicated via API. Uses token-based authentication (POST to /api/aaaLogin.json).

Data Center Security

Security Feature	Description
CoPP (Control Plane Policing)	Protects the switch CPU from control plane DoS attacks by rate-limiting traffic destined to the supervisor. Classes include management, routing, monitoring, and undesirable traffic. Applied on NX-OS via `copp profile strict`.
ACLs (Access Control Lists)	Port ACLs (PACL), VLAN ACLs (VACL), and router ACLs (RACL) on Nexus switches. TCAM-based hardware enforcement for line-rate filtering.
AAA (Authentication, Authorization, Accounting)	Centralized access control using RADIUS or TACACS+ for device administration. NX-OS: `aaa group server tacacs+` with server definitions and authentication method lists.
RBAC (Role-Based Access Control)	NX-OS user roles restrict CLI commands per user. ACI uses RBAC domains, roles, and privileges mapped to APIC users/groups. UCS has user roles (admin, read-only, server-compute, etc.).
First-Hop Security	DHCP snooping, Dynamic ARP Inspection (DAI), and IP Source Guard on Nexus access layers. Prevents spoofing and rogue DHCP attacks.
MACsec (802.1AE)	Layer 2 hop-by-hop encryption on Nexus 9000 inter-switch links. Provides data confidentiality and integrity for fabric traffic. Uses MKA (MACsec Key Agreement) protocol.
Microsegmentation (ACI)	EPG-based security with contracts enforcing whitelist policy. Intra-EPG isolation can be enabled to block communication even within the same EPG (e.g., isolating VMs on the same subnet).

VXLAN vs. VLAN

Feature	VLAN (802.1Q)	VXLAN
Segment Limit	4094 VLANs (12-bit VLAN ID)	16 million VNIs (24-bit VNI)
Encapsulation	802.1Q tag (4 bytes) in Ethernet header	MAC-in-UDP (50-byte overhead)
Transport	Layer 2 only (bounded by STP domain)	Over Layer 3 IP underlay (spans L3 boundaries)
Loop Prevention	STP (blocks redundant links)	IP routing (ECMP, no STP needed in underlay)
Multi-Tenancy	Limited by 4094 VLAN ceiling	Massive scale multi-tenancy
Host Mobility	Limited to same L2 domain	Seamless across L3 boundaries via VTEP re-mapping

vPC vs. Traditional Port Channel

Feature	Traditional Port Channel	vPC (Virtual Port Channel)
Switches Involved	Single switch only	Two peer switches acting as one logical switch
Redundancy Model	Link redundancy only (one switch = SPOF)	Link + switch redundancy (active-active)
STP Behavior	STP may block redundant uplinks	All links forwarding (no STP blocking for vPC members)
Bandwidth	Aggregated links on one switch	Aggregated links across two switches (double effective bandwidth)
Failure Domain	Entire port channel lost if switch fails	Only half the bandwidth lost; remaining peer continues forwarding
Additional Requirements	Standard LACP/static configuration	Peer link, peer keepalive, matching vPC domain ID, consistency checks

FC vs. FCoE vs. iSCSI

Feature	Fibre Channel	FCoE	iSCSI
Transport	Native FC fabric	Lossless Ethernet (DCB)	Standard TCP/IP Ethernet
Protocol	FC-4 (SCSI FCP)	FC frames in Ethernet	SCSI over TCP
Adapter	HBA	CNA (Converged)	NIC or iSCSI HBA
Flow Control	BB credit-based (lossless)	PFC / 802.1Qbb (lossless)	TCP windowing (lossy, retransmits)
Addressing	WWPN / FCID	WWPN / FCID (mapped to MAC)	IQN / IP address
Performance	Highest (dedicated, lossless)	Near-FC (shared lossless Ethernet)	Lower (TCP overhead, potential retransmits)
Cost	Highest (separate infrastructure)	Medium (shared Ethernet, needs DCB switches)	Lowest (uses existing Ethernet)
Best For	Mission-critical, latency-sensitive workloads	I/O consolidation, reducing cables/adapters	SMB, remote/branch offices, non-critical storage

UCS Service Profile: Initial vs. Updating Template

Feature	Initial Template	Updating Template
Binding	Service profiles are independent copies after creation	Service profiles remain bound to the template
Change Propagation	Template changes do NOT affect existing profiles	Template changes automatically propagate to all bound profiles
Individual Customization	Full freedom to modify each profile independently	Limited — profiles inherit template settings; only pooled values differ
Firmware Rollout	Must update each profile individually	Update template once — all bound profiles receive the change
Best For	Unique, one-off server configurations	Large-scale fleets requiring consistency (recommended best practice)

ACI Mode vs. NX-OS Standalone Mode (Nexus 9000)

Feature	NX-OS Standalone Mode	ACI Mode
Management	Per-switch CLI, NX-API, Ansible	Centralized via APIC cluster (GUI, API, Ansible)
Configuration Model	Traditional CLI (interfaces, VLANs, VRFs, routing)	Policy-based (tenants, EPGs, contracts, bridge domains)
Overlay	Manual VXLAN/EVPN configuration per switch	Automatic VXLAN overlay managed by APIC
Security Model	Blacklist (permit all, deny by ACL)	Whitelist (deny all, permit by contract)
Protocols	Standard OSPF, BGP, IS-IS, STP, vPC	IS-IS (underlay), COOP (endpoint directory), OpFlex (policy distribution)
Conversion	Can be re-imaged to ACI mode	Can be re-imaged to NX-OS mode (requires full wipe)

OTV vs. VXLAN for Data Center Interconnect (DCI)

Feature	OTV	VXLAN/EVPN Multi-Site
Purpose	L2 extension over L3 WAN (legacy DCI)	Modern multi-site fabric interconnect
Encapsulation	MAC-in-IP/GRE	VXLAN (MAC-in-UDP)
Control Plane	IS-IS-based adjacency + AED election	BGP EVPN (Type-2 and Type-5 routes across sites)
STP Isolation	Yes (does not forward BPDUs)	Yes (L3 underlay inherently isolates STP)
Scalability	Limited (per-VLAN AED election)	Highly scalable (EVPN route aggregation at border gateways)
Recommendation	Legacy deployments, non-EVPN fabrics	Preferred for new deployments with VXLAN/EVPN or ACI Multi-Site

Tip: For new data center builds, VXLAN/EVPN with Multi-Site is the recommended DCI approach. OTV is primarily relevant for legacy or non-EVPN environments. Know both technologies for the exam, but understand that VXLAN/EVPN is the strategic direction.