Introduction

For me studying for a certification is not simply about passing the exam. Passing is obviously important, however the more important aspect is what you are able to retain after the exam has been completed.

There is a steep decline in retained knowledge after passing a certification. I have experienced this myself many times. You study intensely, you pass the exam, and then slowly the information starts to fade away.

This is why for DCCOR I wanted to approach the exam differently. I did not want to simply pass the exam. I wanted to understand the core data center technologies in a way that I could retain and apply in real environments.

DCCOR is a very interesting exam because it is not purely a networking exam. It is a data center exam. That means you need to understand network, compute, storage network, automation, AI related infrastructure concepts, and security.

In my personal opinion, the best way to study for DCCOR is to follow the blueprint very closely and then lab as much of the blueprint as possible.

The blueprint tells you what to study.
The lab teaches you how the technology actually behaves.

For this exam I used a mixture of physical and virtual lab environments. I used EVE-NG for NX-OS topics, physical Cisco UCS for compute, physical Nexus 5K for Fibre Channel, FCoE and storage networking topics, and ACI/Nexus environments to understand the wider data center architecture.

This made a huge difference because the exam topics stopped becoming isolated theory. They became connected parts of a real data center.

My Study Method

My study method was very similar to how I usually approach certifications.

Stage 1: Study the theory
Stage 2: Implement the technology in a lab
Stage 3: Teach, explain, or blog the learned topic

The theory is important because you need to understand the purpose of the technology. However theory alone is not enough.

For example, reading about vPC is useful. However configuring vPC, breaking the peer-link, checking the consistency parameters, and understanding the traffic flow is a completely different level of learning.

The same applies to UCS. Reading about service profiles, vNICs, vHBAs, pools, and policies gives you the concept. However building a UCS domain and associating a service profile to a physical server makes the topic far easier to retain.

DCCOR rewards this type of understanding.

It is not just asking you what a feature is. It expects you to understand where that feature sits in the overall data center architecture.

1.0 Network

The network section is one of the largest parts of the DCCOR blueprint. This section covers the traditional data center network technologies, but also modern overlay and ACI concepts luckily I have extensive experience with ACI.

This includes topics such as OSPF, MP-BGP, PIM, FHRP, RSTP, LACP, vPC, VXLAN EVPN, ACI fabric setup, access policies, VMM integration, packet flow, software updates, configuration management, monitoring, streaming telemetry and Nexus Dashboard.

For this section, EVE-NG was extremely useful.

I used EVE-NG to lab NX-OS and build different topologies. This allowed me to practice vPC, routing protocols, overlays and failure scenarios without constantly rebuilding physical hardware.

Some of the key areas I focused on were:

• vPC domain configuration
• Peer-keepalive
• Peer-link
• vPC member ports
• LACP port-channels
• RSTP behaviour
• OSPF underlay
• MP-BGP concepts
• VXLAN EVPN control plane
• Anycast gateway concepts
• Packet flow
• Failure scenarios

The most important thing for me was not simply typing the commands. It was understanding why each component exists.

For example, vPC is not just two Nexus switches with a port-channel. It is a mechanism that allows a downstream device to see two physical switches as one logical port-channel endpoint.

Once you understand that, the other concepts become easier. The peer-link, peer-keepalive, role priority, consistency checks, orphan ports, peer-gateway and failure behaviour all start to make sense.

VXLAN EVPN was another important area. It is easy to memorise that VXLAN uses a VNI and EVPN uses BGP. However the real understanding comes when you map the underlay, overlay, VTEPs, VNIs, BGP EVPN routes, distributed anycast gateways and endpoint mobility into one mental model.

ACI also falls under the network section. For ACI, the challenge is changing your mindset from traditional networking to policy-based networking.

In traditional networking, we often think in VLANs, SVIs, ACLs and routing tables.

In ACI, you need to understand tenants, VRFs, bridge domains, EPGs, contracts, filters, application profiles, domains, AEPs, VLAN pools, VMM integration and L3Outs.

Data center networking is no longer just VLANs and trunks.
It is underlay, overlay, policy, telemetry, and operational assurance. Modern DC also incorporate AI infrastructure.

A bridge domain is not simply a VLAN.
An EPG is not simply a VLAN.
A contract is not simply an ACL.

They may have similarities, but ACI is designed around policy and endpoint groups.

The lab helped me massively here because it allowed me to see how endpoints are learned, how EPGs are mapped, how contracts control communication and how external connectivity works through L3Outs.

2.0 Compute

The compute section is equally important in DCCOR. This is where Cisco UCS becomes a major topic.

This section covers UCS rack servers, blade chassis, Fabric Interconnects, server policies, templates, pools, firmware, monitoring, Intersight and the operational aspects of compute infrastructure.

This was one of my favourite sections because I had access to a real UCS domain.

In my lab I used physical Cisco UCS equipment to understand:

• Fabric Interconnects
• UCS Manager
• UCS C-Series rack servers
• VIC adapters
• Server discovery
• Service profiles
• Service profile templates
• vNICs
• vHBAs
• MAC pools
• WWPN and WWNN pools
• VLANs
• VSANs
• Boot policies
• Firmware policies
• Server association

The key point with UCS is abstraction.

A physical server is no longer just a standalone server. In UCS, the server identity can be defined through policy.

The MAC address, WWPN, WWNN, boot order, firmware policy, LAN connectivity, SAN connectivity and operational identity can all be defined centrally.

That is extremely powerful.

UCS turns compute into policy-driven infrastructure.

Once I started building service profiles, associating them with servers, creating vNICs and vHBAs, and understanding how the Fabric Interconnect sits between compute, LAN and SAN, the compute section became far easier.

The theory made sense because I had physically implemented it.

This is where many people struggle with DCCOR. They may be strong network engineers, but they underestimate the compute section. DCCOR is not just Nexus switching. You need to understand UCS properly.

You need to understand how a server is discovered, how identity is applied, how it connects northbound, how it consumes VLANs and VSANs, and how UCS Manager or Intersight fits into the operational model.

3.0 Storage Network

The storage network section is another area that should not be underestimated.

This section covers Fibre Channel, FCoE, VSANs, zoning, device aliases, FCNS, NPV, NPIV, port-channels, storage protocols, software upgrades and storage monitoring concepts.

For this section I used a physical Cisco Nexus 5K device to practice Fibre Channel, FCoE and storage-related topics.

This was very important because storage networking is one of those areas where reading alone can become confusing.

Fibre Channel has its own terminology and behaviour. You need to understand the difference between Ethernet networking and storage networking.

Some of the key concepts I focused on were:

• Fibre Channel fabric behaviour
• VSANs
• FC interfaces
• FC port roles
• FCoE concepts
• NPV
• NPIV
• WWPNs
• WWNNs
• Device aliases
• Zoning
• FCNS database
• SAN connectivity from UCS
• vHBA to SAN fabric relationship
• Boot-from-SAN concepts

The Nexus 5K was useful because it allowed me to see how Fibre Channel and FCoE fit into a real Cisco data center environment.

This helped connect the storage section back to the compute section.

For example, a UCS service profile may contain vHBAs. Those vHBAs use WWPNs. The WWPNs need to be recognised in the SAN fabric. They may need zoning. The storage array presents LUNs. The server boot policy may then use those SAN targets to boot an operating system.

Once you connect all those pieces together, storage networking becomes far easier to understand.

Storage networking is not a separate world.
It is part of the complete data center system.

This is why the physical Nexus 5K lab was valuable. It allowed me to move beyond just theory and understand how LAN, SAN, UCS and storage concepts connect together.

4.0 Automation and Artificial Intelligence

The automation and AI section is becoming increasingly important.

Modern data centers are not operated manually at scale. Automation, programmability, APIs, telemetry and infrastructure-as-code are becoming core operational skills.

The DCCOR blueprint covers topics such as EEM, Scheduler, Bash Shell, Guest Shell, NX-API, JSON, XML, Python, Ansible, POAP, Nexus Dashboard, PowerShell, Terraform, Intersight, and AI infrastructure related networking concepts.

For this section my focus was understanding where each tool fits.

EEM is useful for local event-based automation.
Scheduler can run tasks at specific times.
Bash Shell and Guest Shell allow deeper on-box programmability.
NX-API allows NX-OS to be interacted with programmatically.
JSON and XML are data formats used by APIs.
Python allows custom automation.
Ansible allows repeatable configuration and operational workflows.
Terraform introduces infrastructure-as-code thinking.
Intersight provides cloud-based management and lifecycle operations for compute.
Nexus Dashboard provides visibility, assurance and operational tools.

For me, automation was not just a small section to memorise. It is directly connected to how modern data centers are operated.

I have always been passionate about network automation, so this section was very natural for me. However I still made sure I understood the specific data center tools and use cases.

The AI-related part is also important. Modern AI infrastructure places huge demands on compute, network and storage. Data center engineers need to understand that AI is not simply about GPUs.

AI infrastructure requires high performance networking, storage, automation, telemetry, visibility and operational discipline.

This is why DCCOR is still highly relevant. It teaches the foundation needed to understand modern data center infrastructure.

Automation is not there to replace understanding.
Automation is there to scale understanding.

If you automate something you do not understand, you simply scale confusion. The lab gives you the understanding first. Automation then helps you repeat and scale the correct operational model.

5.0 Security

The security section covers security across the data center stack.

This includes topics such as AAA, RBAC, keychain authentication, MACsec, ACI contracts, microsegmentation, first-hop security, storage security, port security and fabric binding.

The key point here is that data center security is not just a firewall.

Security exists at different layers.

At the network layer, you have AAA, RBAC, secure management, routing protocol authentication, first-hop security and control-plane protection.

At the ACI layer, you have contracts, filters, EPG relationships and microsegmentation.

At the compute layer, you have UCS roles, policies, access control, server identity and operational boundaries.

At the storage layer, you have zoning, fabric security, port security and control over which initiators can communicate with which targets.

This is why DCCOR security should be studied as part of the whole architecture, not as a separate isolated topic.

For example, an ACI contract controls communication between EPGs. That is security through policy.

A SAN zone controls which initiator can communicate with which target. That is security in the storage fabric.

RBAC in UCS controls who can perform specific administrative tasks. That is security in compute operations.

The concepts are different, but the principle is the same.

Control access.
Reduce unnecessary communication.
Apply policy.
Validate behaviour.
Monitor the environment.

Why The Lab Was The Difference

The biggest reason I was able to retain the DCCOR topics was the lab.

I used the lab to turn the blueprint into real technology.

EVE-NG allowed me to practice NX-OS, routing, switching, vPC and overlay topics.

Physical UCS allowed me to practice compute, service profiles, vNICs, vHBAs, pools, policies and server identity abstraction.

Physical Nexus 5K allowed me to practice Fibre Channel, FCoE and storage networking topics.

ACI allowed me to understand policy-based networking, endpoint groups, bridge domains, contracts, VMM integration and fabric behaviour.

Automation practice allowed me to connect APIs, Python, JSON, NX-API, Ansible and operational tooling back to real data center use cases.

This is the difference between passing and understanding.

You can read about a technology and recognise the correct answer. However when you configure it, troubleshoot it and explain it, the knowledge becomes much stronger.

The lab exposes the gaps that theory hides.

This happened many times during my study. I would think I understood a topic, then I would try to implement it and realise there were gaps in my understanding.

That is a good thing.

The lab is supposed to expose gaps. Once those gaps are exposed, you can go back to the theory, correct the misunderstanding and then implement it again.

That cycle is where real learning happens.

Blueprint-Based Study

The best advice I can give anyone studying DCCOR is to use the blueprint as the main structure.

Do not randomly study topics.
Do not only watch videos.
Do not only read a book.
Do not ignore the lab.

Take each blueprint domain and ask yourself:

Can I explain this?
Can I configure this?
Can I troubleshoot this?
Can I explain where it fits in the data center?
Can I connect it to the other domains?

For example, do not study UCS in isolation. Connect it to networking and storage.

A UCS server needs LAN connectivity.
It may need SAN connectivity.
It may boot from local disk or SAN.
It may use vNICs and vHBAs.
It may be managed by UCS Manager or Intersight.
It may connect northbound to Nexus switches.
It may require monitoring, firmware management and secure access.

That is DCCOR.

It is the full data center picture.

Teach or Blog The Topic

The final stage for me is always teaching or blogging.

Once I study something and implement it, I try to explain it in simple terms.

This is very powerful because it quickly exposes whether I actually understand the topic.

If I cannot explain vPC simply, I need to go back and study vPC again.

If I cannot explain the difference between NPV and NPIV, I need to go back and lab it again.

If I cannot explain why UCS service profiles are powerful, I need to go back and rebuild the concept in my own mind.

Teaching forces clarity.

Blogging also helps cement the knowledge. Once I write a topic in my own words, it becomes much easier to retain.

This is one of the reasons I continue to blog. It is not just to share knowledge with others. It also helps me retain the knowledge myself.

You don’t have to publish the blog or article. Simply write it as part of your note taking process.

Conclusion

Fortunately having extensive experience with ACI I able to pass the Cisco DCACI concentration earlier in the year.

Passing DCCOR and attaining the CCNP Datacenter was a very rewarding experience.

However the real value was not just passing the exam. The real value was the process of studying the full data center stack and understanding how each component fits together.

DCCOR forces you to think beyond traditional networking.

You need to understand Nexus switching, vPC, routing, VXLAN EVPN, ACI, UCS, storage networking, Fibre Channel, FCoE, automation, telemetry, Intersight, Nexus Dashboard and security.

This is why the lab is so important.

The lab turns the blueprint into real understanding.

For me, using EVE-NG for NX-OS, physical UCS for compute, physical Nexus 5K for FC/FCoE and storage topics, and ACI for policy-based networking made a huge difference.

It helped me retain the material, not just pass the exam.

The key lesson is simple.

Do not just study to pass.
Study to retain.
Lab to understand.
Teach to cement the knowledge.

That is how I approached DCCOR, and that is why the lab made the difference.