Cisco Data Center Foundation — Practice Exam 1 (Questions, Answers & Explanations)

 This is the first in a series of practice exams for the Cisco Data Center Foundation certification (exam code: DCFNDU). Each question includes the correct answer plus a detailed explanation — because knowing why an answer is correct matters far more than memorizing the answer itself.

These questions cover core data center concepts including three-tier vs. spine-leaf architecture, SAN design, hyperconverged infrastructure, and Cisco Unified Data Center. Whether you are studying for DCFNDU, refreshing your knowledge before a job interview, or preparing for CCNP/CCIE Data Center, this post will help.

This Practice Test Covers

13

Questions

6

Topics

~15

Min to complete

Topics Covered

1. Three-Tier Network Design
2. Spine-and-Leaf Architecture
3. Cisco Unified Data Center
4. SAN and Storage Network Design
5. Hyperconverged Infrastructure (HCI)
6. Scaling and Redundancy

How to use this post: Try to answer each question before reading the answer. The explanation section below each question tells you exactly why the correct answer is right and why the wrong answers are wrong — this is what sticks in your memory during the actual exam.

Section 1 — Three-Tier Network Design

The three-tier model (core, aggregation/distribution, access) has been the standard enterprise and data center design for decades. These questions test your understanding of which devices belong at each layer and why.

Question 1

Which two devices would you choose to be part of the core layer in the three-tier network design? (Choose two.)

• Cisco Nexus 9500 Series Switch
• Cisco Catalyst 9800 Series Switch
• Cisco UCS 6200 Series Fabric Interconnect
• Hypervisor
• Cisco Nexus 9300 Series Switch

Correct Answer

✓ Cisco Nexus 9500 Series Switch    ✓ Cisco Catalyst 9800 Series Switch

Explanation

The core layer requires high-throughput, high-port-density switches that can handle aggregated traffic from the entire data center or campus. The Nexus 9500 is a modular chassis switch designed specifically for this role — it supports hundreds of 40G/100G ports and is purpose-built for core and spine roles in data centers. The Catalyst 9800 is a wireless LAN controller — while not a traditional core switch, in some campus designs it operates at the core layer for wireless infrastructure management. The Nexus 9300 is a fixed-form-factor switch more suited to the access or leaf layer due to its lower port density. The UCS Fabric Interconnect connects UCS blade servers and belongs at the access layer. A hypervisor is server software — it does not belong in any network design tier.

Question 2

Which option lists the three tiers of a three-tier architecture?

• Core, aggregation, and access
• Core, spine, and leaf
• Base, spine, and leaf
• Physical, data link, and network

Correct Answer

✓ Core, aggregation, and access

Explanation

The classic three-tier architecture consists of: (1) Core layer — high-speed backbone, connects aggregation switches; (2) Aggregation (Distribution) layer — policy enforcement, routing between VLANs, connects core to access; (3) Access layer — connects end devices (servers, workstations, IP phones). "Spine and leaf" describes a two-tier Clos architecture used in modern data centers — it is not a three-tier design. "Physical, data link, and network" are layers of the OSI model, not network tiers.

Question 3

Which device would you choose to be part of the core layer in a three-tier network design?

• Cisco UCS 6400 Series Fabric Interconnect
• Cisco Nexus 9500, Cisco Catalyst 6800, or Cisco Catalyst 6500 Series Switch
• Hypervisor
• Cisco ASA security appliance

Correct Answer

✓ Cisco Nexus 9500, Cisco Catalyst 6800, or Cisco Catalyst 6500 Series Switch

Explanation

All three switches listed — Nexus 9500, Catalyst 6800, and Catalyst 6500 — are high-capacity modular chassis platforms designed for the core layer. They provide the throughput, redundancy, and port density required to handle aggregated traffic from the entire network. The UCS Fabric Interconnect is a server connectivity device, not a network core switch. The ASA is a firewall and lives in the security layer, not the core.

💡 Exam Tip: A spine-and-leaf model allows for approximately 25% greater scalability over a three-tier model when used for data center designs. This is a frequently tested fact in the DCFNDU exam.

Section 2 — Spine-and-Leaf Architecture

Spine-and-leaf (also called Clos architecture) is the dominant design for modern data centers. It provides predictable latency, easy horizontal scaling, and efficient east-west traffic forwarding — all critical for today's cloud and virtualization workloads.

Question 4

Which option describes the topology design in a spine-and-leaf network?

• The design uses a partial mesh of links at the leaf layer.
• The design uses a full mesh of links between the leaf and aggregation layers.
• The design uses a full mesh of links between the spine and leaf layers.
• The design uses a full mesh of links at the leaf layer.

Correct Answer

✓ The design uses a full mesh of links between the spine and leaf layers.

Explanation

In a spine-and-leaf architecture, every leaf switch connects to every spine switch — this is the defining characteristic. This full mesh between the two layers means any server connected to any leaf can reach any other server in exactly two hops (leaf → spine → leaf), regardless of where in the fabric they are. There are no direct connections between spine switches and no direct connections between leaf switches. This is what keeps latency predictable and uniform. The "aggregation layer" is part of the older three-tier model — it does not exist in a spine-and-leaf design.

💡 Key Benefits of Spine-and-Leaf to Memorize:

• Scalability: Add a new spine switch → connect it to every leaf → instantly adds bandwidth across the fabric with no redesign
• Low, predictable latency: Always exactly two hops between any two endpoints in the same fabric
• East-west optimized: Server-to-server traffic (the majority in modern data centers) never needs to travel to a core router

Question 5

In a spine-and-leaf topology, what is the minimum number of spines if redundancy is taken into consideration?

• One
• Two
• Four
• Six

Correct Answer

✓ Two

Explanation

With a single spine switch, any failure of that switch takes down the entire fabric — there is no redundancy. Two spine switches is the minimum for a redundant design. Each leaf connects to both spines, so if one spine fails, all leaf switches can still communicate through the remaining spine. In production data centers, two spines is the starting point, and four or more spines is common in large-scale deployments for added bandwidth and fault tolerance.

Question 6

Which option lists the two tiers of a Clos-collapsed core architecture?

• Aggregation and access
• Spine and leaf
• Spine and access
• Collapsed core and leaf

Correct Answer

✓ Spine and leaf

Explanation

The Clos-collapsed core architecture — commonly called spine-and-leaf — collapses the traditional three-tier model into two layers. The spine layer replaces both the core and aggregation layers of the three-tier model, while the leaf layer replaces the access layer. This simplification reduces complexity and improves performance for modern east-west data center traffic patterns.

Question 7

If you are running out of physical ports, which action should you take to increase physical connectivity for end devices?

• Add an additional core switch and directly connect it to each leaf switch.
• Add an additional core switch and directly connect it to each core switch.
• Add an additional leaf switch and directly connect it to each core switch.
• Add an additional leaf switch and directly connect it to each leaf switch.

Correct Answer

✓ Add an additional leaf switch and directly connect it to each core (spine) switch.

Explanation

In a spine-and-leaf fabric, end devices connect to leaf switches, not to spine switches. When you need more ports for end devices, you add a new leaf switch and connect it upward to every spine switch. This is one of the key design advantages of spine-and-leaf — horizontal scale-out is straightforward and non-disruptive. You never connect leaf switches to each other, and you never connect spine switches directly to each other. Adding a new spine switch would add inter-leaf bandwidth, not end-device ports.

Section 3 — Cisco Unified Data Center

Question 8

Cisco Unified Data Center is based on which three pillars of Cisco innovation? (Choose three.)

• Cisco Unified Computing System
• Cisco Unified Fabric
• Cisco Unified Access
• Cisco Unified Communications
• Cisco Unified Management
• Cisco Overlay Transport Virtualization
• Cisco FabricPath

Correct Answer

✓ Cisco Unified Computing System    ✓ Cisco Unified Fabric    ✓ Cisco Unified Management

Explanation

The Cisco Unified Data Center framework is built on three foundational pillars: (1) Unified Computing System (UCS) — converges compute, networking, storage access, and virtualization into a single cohesive system; (2) Unified Fabric — consolidates LAN and SAN traffic onto a single network fabric using technologies like FCoE, reducing cabling complexity; (3) Unified Management — provides a single management platform (Cisco UCS Manager / Cisco APIC) for the entire data center infrastructure. "Unified Access" is a campus networking concept, not a data center pillar. OTV and FabricPath are individual technologies, not framework pillars.

Question 9

Cisco Unified Data Center infrastructure eliminates tiered silos and allows consolidation of which option?

• LAN and WAN
• LAN and SAN
• LAN and WLAN
• Performance and security management

Correct Answer

✓ LAN and SAN

Explanation

One of the core value propositions of Cisco Unified Data Center is the convergence of LAN (Ethernet/IP) and SAN (Fibre Channel storage) traffic onto a single unified fabric using Fibre Channel over Ethernet (FCoE). Traditionally, data centers ran two completely separate physical networks — one for data (LAN) and one for storage (SAN). This required separate cables, separate switches, separate teams, and separate budgets. Cisco Unified Fabric eliminates this separation, reducing infrastructure costs and operational complexity.

Section 4 — SAN and Storage Network Design

Question 10

What are three benefits of the two-tier storage network design? (Choose three.)

• It is recommended for larger storage environments.
• It is elastic in case of failures.
• It is recommended for small-to-medium–sized environments.
• It is redundant through dual-fabric design.
• It is very expensive.
• It is a single point of failure.
• It is optimum for IP storage.

Correct Answer

✓ Recommended for larger storage environments    ✓ Elastic in case of failures    ✓ Redundant through dual-fabric design

Explanation

The two-tier SAN design uses core and edge SAN switches, similar in concept to the two-tier network model. Its key advantages are: scalability for larger environments (the core tier aggregates multiple edge fabrics), elasticity (edge switches can be added or removed without redesigning the core), and redundancy via dual-fabric (each server has two HBAs connecting to two separate fabrics — Fabric A and Fabric B — so a single switch failure never causes a storage outage). "Single point of failure" and "very expensive" are characteristics of a direct-attached or poorly designed storage setup, not of a properly implemented two-tier SAN.

Question 11

What are two benefits of the SAN storage network design? (Choose two.)

• Allows for easier maintenance of servers.
• It is redundant through dual-fabric design.
• It is very affordable.
• It is a single point of failure.
• It is optimum for IP storage.

Correct Answer

✓ Allows for easier maintenance of servers    ✓ Redundant through dual-fabric design

Explanation

A SAN (Storage Area Network) separates storage traffic from the general data network. Key benefits: Easier server maintenance — because storage is centralized on the SAN and not directly attached to individual servers, you can take a server down for maintenance without losing access to the storage data; other servers can still access shared storage. Dual-fabric redundancy — SANs are always designed with two independent fabrics (Fabric A and Fabric B). Every server connects to both fabrics, so no single switch or cable failure causes a storage outage. "Very affordable" is not accurate — SAN infrastructure (Fibre Channel switches, HBAs) is costly, which is why many organizations choose iSCSI or NFS as lower-cost alternatives.

Section 5 — Hyperconverged Infrastructure (HCI)

💡 Key HCI Facts for the Exam: In most hyperconverged solutions, the minimum cluster size is three nodes. Each Nutanix node contains three software layers: server firmware (Cisco UCS), hypervisor (Nutanix AHV or VMware ESXi), and hyperconverged storage software (Nutanix AOS).

Question 12

Which statement about Cisco Compute Hyperconverged with Nutanix is correct?

• It provides network connectivity with the Cisco Nexus 9500 series switches.
• Hardware compute platforms used in Cisco Compute Hyperconverged with Nutanix are Cisco UCS blade servers.
• The Cisco Compute Hyperconverged with Nutanix solution is a combination of hardware and software.
• It uses SAN protocols like Fibre Channel and iSCSI for server addition and retiring.

Correct Answer

✓ The Cisco Compute Hyperconverged with Nutanix solution is a combination of hardware and software.

Explanation

Hyperconverged infrastructure (HCI) by definition integrates compute, storage, and networking into a single software-defined solution running on standard x86 hardware. The Cisco + Nutanix solution combines Cisco UCS hardware (compute servers) with Nutanix software (AOS for storage, AHV or ESXi for virtualization) — making it explicitly a hardware + software solution. The hardware used is Cisco UCS rack servers, not blade servers. HCI does not use traditional SAN protocols like Fibre Channel — storage is managed entirely by the Nutanix software layer across the cluster nodes using its own distributed storage fabric.

Question 13

Which are the three characteristics of a hyperconverged storage system? (Choose three.)

• Easy expansion
• No SAN network
• Usage of multiple storage arrays
• Usage of redundant SAN switches
• Easy deployment and maintenance
• Fast convergence

Correct Answer

✓ Easy expansion    ✓ No SAN network    ✓ Easy deployment and maintenance

Explanation

HCI's three defining characteristics in this context: Easy expansion — add a new node to the cluster and it automatically joins the storage pool; no manual SAN reconfiguration needed. No SAN network — HCI eliminates the traditional SAN entirely; storage is distributed across the compute nodes themselves using software. Easy deployment and maintenance — HCI clusters are typically deployed in hours, not days, and managed through a single interface. "Multiple storage arrays" describes traditional SAN or NAS architecture, not HCI. "Redundant SAN switches" is again a traditional SAN concept that HCI specifically eliminates. "Fast convergence" is a routing protocol term, not an HCI characteristic.

Section 6 — Converged Infrastructure and Scaling

💡 Converged Infrastructure Solutions to Know:

• FlexPod — Cisco + NetApp
• FlashStack — Cisco + Pure Storage
• Hitachi Adaptive Solutions for CI — Cisco + Hitachi

These are validated designs — not custom builds — which means faster deployment and guaranteed interoperability.

Scenario Question

You are working in the IT department of a small banking company that needs a new storage solution. The IT infrastructure consists of a single Cisco UCS server hosting five VMs. The company will soon expand, a new server will be added, and a centralized storage array will be needed. Which network design approach is required?

• Cloud storage solution
• Three-tier network with Cisco MDS multilayer switches
• Directly attached network
• Storage area network

Correct Answer

✓ Storage Area Network (SAN)

Explanation

The scenario describes growth from one server to multiple servers with a centralized storage array. This is the classic use case for a SAN. A SAN allows multiple servers to share the same storage array over a dedicated, high-performance network (Fibre Channel or iSCSI). Directly attached storage cannot be shared between multiple servers. A cloud storage solution could work but introduces latency and ongoing costs not suitable for a small banking environment with on-premise requirements. A three-tier network with MDS switches is correct conceptually (Cisco MDS is a SAN switch) but is overspecified for a small environment — simple SAN is the right answer at this scale.

Key Topics Summary

Topic	Key Fact to Remember
Three-tier architecture	Core → Aggregation → Access. Nexus 9500 / Catalyst 6800 / 6500 at core.
Spine-and-leaf	Every leaf connects to every spine. Two hops max. Minimum 2 spines for redundancy.
Scalability comparison	Spine-leaf offers ~25% greater scalability than three-tier for data center designs.
Cisco Unified DC pillars	Unified Computing System + Unified Fabric + Unified Management
LAN/SAN convergence	Cisco Unified Fabric consolidates LAN and SAN onto a single fabric using FCoE.
SAN dual-fabric	Every server connects to Fabric A and Fabric B — no single point of failure.
HCI minimum size	3 nodes minimum. No SAN needed. Compute + storage on same nodes.
Nutanix layers	Cisco UCS firmware + AHV or ESXi hypervisor + Nutanix AOS storage

How to Use This for Exam Prep

• Score yourself: 12–13 correct = Exam ready. 9–11 = Review weak areas. Below 9 = Re-study the topic sections.
• Focus on understanding why each answer is correct — the exam often rephrases questions to test the same concept differently
• Pay special attention to the "choose two" and "choose three" questions — these require complete knowledge of the topic, not just recognition of one correct answer
• The spine-and-leaf section is heavily tested — know the full mesh topology, two-hop latency, and scale-out process cold

Related Posts on Networklearner

• Data Center Foundation — Concepts and Reference Guide
• Cisco ACI Decommission Only vs Remove vs Secure Remove Explained
• How to Safely Decommission a Leaf Switch in Cisco ACI
• Why Service Graphs Matter in Cisco ACI — Complete Guide

Cisco Data Center DCFNDU Spine Leaf Three Tier Architecture Cisco UCS Hyperconverged SAN Data Center Exam Cisco Certification

NL

Networklearner

CCIE Data Center certified engineer with 18+ years of experience. Specializes in Cisco ACI, Nexus, and data center design. Available for consulting and freelancing work.

📧 rockingoa@gmail.com

Why Service Graphs Matter in Cisco ACI — Complete Guide with Configuration Examples

 If you have worked with Cisco ACI for any length of time, you have almost certainly heard the term Service Graph. Many engineers treat it as an advanced topic they will "get to later." In reality, Service Graphs are one of the most powerful and most misunderstood features in ACI — and ignoring them means you are missing the core value of ACI's policy-driven architecture.

This guide explains what Service Graphs are, why they exist, how they work under the hood, and how to configure them step by step. It is written from real production experience, not from a lab that has never seen a firewall.

Table of Contents

1. What is a Service Graph in Cisco ACI?
2. Why Service Graphs Matter
3. How Service Graphs Work
4. Key Components Explained
5. Go-To, Go-Through, and One-Arm Mode
6. Step-by-Step Configuration
7. Real-World Use Cases
8. Common Mistakes to Avoid
9. Interview Questions and Answers
10. Final Summary

1. What is a Service Graph in Cisco ACI?

A Service Graph in Cisco ACI is a policy construct that defines how traffic between two Endpoint Groups (EPGs) should be redirected through one or more network service devices — such as a firewall, load balancer, or intrusion prevention system — before reaching its destination.

Without a Service Graph, traffic between two EPGs is controlled only by ACI Contracts. A Contract can allow or deny traffic, but it has no concept of routing that traffic through a third device. A Service Graph fills exactly that gap.

Simple definition: A Service Graph tells ACI — "before you allow this traffic from EPG A to EPG B, send it through this firewall and this load balancer first."

The Service Graph is attached to a Contract. When a Contract with a Service Graph is applied between two EPGs, ACI automatically stitches the traffic flow through the defined service devices using its internal policy engine — without requiring manual static routing changes on every device in the fabric.

2. Why Service Graphs Matter

In traditional data center networking, inserting a firewall or load balancer into a traffic path requires careful planning of VLANs, routing, and physical cabling. When topologies change, you update routing tables, reconfigure VLANs, and sometimes repatch cables. This is slow, error-prone, and does not scale.

Cisco ACI was designed to solve this problem through policy automation. Service Graphs are the mechanism that makes service insertion dynamic and repeatable. Here is why they matter:

a) Policy-Driven Service Insertion

Instead of manually routing traffic through a firewall, you define a Service Graph that says "all traffic matching this Contract must pass through this firewall." ACI handles the forwarding automatically. When the policy changes, ACI updates the fabric — not the engineer.

b) No Manual VLAN Management

Service Graphs automate the VLAN stitching between the ACI fabric and the service device. ACI allocates encapsulation VLANs dynamically based on the graph configuration. This removes one of the most common sources of human error in service chaining.

c) Reusability Across Tenants

A Service Graph template can be defined once and reused across multiple tenants and applications. You do not rebuild the same firewall insertion logic for every application. This is critical in multi-tenant environments.

d) Consistent Security Policy Enforcement

When security policy says "all traffic between the web tier and the database tier must go through the firewall," a Service Graph enforces this at the fabric level. There is no way for traffic to bypass the service device — the fabric simply will not forward it any other way.

e) Integration with Third-Party Devices

ACI supports Service Graphs for both Cisco and third-party service devices. Cisco provides device packages for vendors like Palo Alto, F5, Citrix, and ASA. These device packages allow ACI to programmatically configure the service device as part of graph deployment.

Bottom line: Service Graphs turn what was once a complex, manual, error-prone process into a repeatable policy that ACI enforces automatically across the fabric.

3. How Service Graphs Work

Understanding how Service Graphs work requires understanding the traffic flow before and after graph insertion.

Without a Service Graph

Traffic from EPG-Web to EPG-DB is governed by a Contract. If the Contract permits port 1521 (Oracle), traffic flows directly across the ACI fabric from leaf to leaf. There is no third device involved.

With a Service Graph

When a Service Graph is attached to the same Contract, ACI intercepts the traffic flow and redirects it through the defined service node — for example, a firewall — before delivering it to EPG-DB. The firewall inspects the traffic, applies its own security policies, and either forwards or drops the connection.

ACI accomplishes this redirection using Policy-Based Redirect (PBR) at the leaf switches. The leaf where EPG-Web is connected sees the traffic, matches it against the Service Graph policy, and forwards it to the firewall's interface instead of directly to the destination leaf. After the firewall processes the traffic, it forwards it back into the fabric, which then delivers it to EPG-DB.

Key insight: The service device does not need to be physically inline between the source and destination. ACI uses PBR at the leaf layer to logically redirect traffic to the service device regardless of physical position.

4. Key Components of a Service Graph

Before configuring a Service Graph, you must understand the objects involved. Each has a specific role.

Component	What It Is	Where It Lives
L4-L7 Device	The actual service device (firewall, load balancer). Defines interfaces, VLANs, and connectivity to the fabric.	Tenant or Common Tenant
Service Graph Template	Defines which service devices are in the chain and their order. Reusable across applications.	Tenant
Device Selection Policy	Binds a specific L4-L7 Device to a Service Graph Template. Maps logical interfaces to physical/virtual device interfaces.	Tenant
Contract with Graph	The Contract that triggers the Service Graph when applied between two EPGs.	Tenant
Function Node	Represents one service device inside a Service Graph Template. A graph can have multiple function nodes (e.g., firewall → load balancer).	Inside the Graph Template
Connector	The interface connection on a function node. Each node has a consumer connector (traffic coming in) and a provider connector (traffic going out).	Inside the Graph Template
Bridge Domain (BD)	Each connector on the service device is placed in a Bridge Domain, providing Layer 2 stitching between the fabric and the device.	Tenant

5. Go-To, Go-Through, and One-Arm Mode

Cisco ACI Service Graphs support three insertion modes. Choosing the wrong mode is one of the most common mistakes in production deployments.

Go-Through Mode (Most Common)

The service device has two logical interfaces — one on the consumer side and one on the provider side. Traffic enters through the consumer interface, is processed by the device, and exits through the provider interface. This is used for firewalls in routed or transparent mode.

Go-To Mode

Traffic is redirected to the service device, which then forwards it directly to the destination without returning through the ACI fabric on a separate interface. This is less common and is used for specific routing scenarios.

One-Arm Mode

The service device has a single interface connected to the fabric. Both inbound and outbound traffic use the same interface. This is the standard mode for load balancers, where the load balancer receives traffic and sends the response back through the same interface.

Mode	Interfaces	Typical Use Case
Go-Through	Two (consumer + provider)	Firewall (routed or transparent)
Go-To	One (provider only)	Specific routing edge cases
One-Arm	One (shared)	Load balancer (F5, Citrix)

6. Step-by-Step Configuration — Firewall Service Graph

The following steps walk through configuring a Service Graph for a firewall in Go-Through mode. The scenario is: all traffic from EPG-Web to EPG-App must pass through an ASA firewall.

Step 1 — Create Bridge Domains for Service Device Interfaces

Create two Bridge Domains: one for the consumer side (facing EPG-Web) and one for the provider side (facing EPG-App). Do not enable Unicast Routing on these BDs unless the firewall is routing traffic.

# APIC GUI Path:
Tenant → Networking → Bridge Domains → Create Bridge Domain

# BD 1: Consumer side
Name:      BD-FW-Consumer
L2 Only:   Yes (no IP gateway needed for transparent mode)

# BD 2: Provider side
Name:      BD-FW-Provider
L2 Only:   Yes

Step 2 — Create the L4-L7 Device

Define the physical or virtual service device and its interfaces.

# APIC GUI Path:
Tenant → L4-L7 Services → L4-L7 Devices → Create L4-L7 Device

Name:            FW-ASA-01
Service Type:   Firewall
Device Type:    Physical
VMM Domain:     (leave blank for physical)

# Add Concrete Interfaces:
Interface 1:    consumer  → maps to leaf port connected to FW inside int
Interface 2:    provider  → maps to leaf port connected to FW outside int

Step 3 — Create the Service Graph Template

Build the graph template and define the function node.

# APIC GUI Path:
Tenant → L4-L7 Services → L4-L7 Service Graph Templates → Create

Name:              SGT-Firewall
Graph Type:       L4-L7 Services

# Drag the device into the graph canvas:
Function Node:    FW-ASA-01
Function Type:    GoThrough
Managed:          No (unless using device package for auto-config)

# Connect Consumer EPG → FW Consumer Interface → FW Provider Interface → Provider EPG

Step 4 — Create the Device Selection Policy

This binds the graph template to the actual device and maps connectors to Bridge Domains.

# APIC GUI Path:
Tenant → L4-L7 Services → L4-L7 Policy-Based Redirect → Device Selection Policies

Name:                    DSP-SGT-Firewall
Service Graph:          SGT-Firewall
Node:                    FW-ASA-01

# Map connectors to Bridge Domains:
Consumer Connector:     BD-FW-Consumer
Provider Connector:     BD-FW-Provider

Step 5 — Apply the Graph to a Contract

Attach the Service Graph Template to the Contract that governs traffic between your EPGs.

# APIC GUI Path:
Tenant → Contracts → [Your Contract] → Service Graph

Service Graph:           SGT-Firewall
Device Selection Policy: DSP-SGT-Firewall

Step 6 — Verify the Service Graph is Deployed

# APIC GUI — Check deployment state:
Tenant → L4-L7 Services → Deployed Graph Instances

# Look for:
State:    deployed    (not "failed" or "incomplete")

# CLI verification on leaf switch:
show zoning-rule scope <vrf-vnid>
show pbr policy

# Confirm PBR redirect entries are programmed:
show endpoint

Deployment confirmed when: The graph shows state "deployed", the leaf has PBR entries for the relevant traffic, and traffic between EPG-Web and EPG-App is visible in the firewall logs.

7. Real-World Use Cases

Use Case 1 — Web to App Tier Firewall

The most common use case. All traffic from the web tier EPG to the application tier EPG passes through an ASA or Palo Alto firewall. The firewall enforces stateful inspection and blocks unauthorized ports. Without a Service Graph, this requires complex routing. With a Service Graph, it is a policy decision.

Use Case 2 — Load Balancer for Application Tier

An F5 BIG-IP or Citrix ADC is deployed in one-arm mode. The Service Graph redirects traffic destined for the virtual IP of the application to the load balancer, which then distributes the load across multiple application servers. ACI handles the VLAN stitching automatically.

Use Case 3 — Chained Services (Firewall + Load Balancer)

A single Service Graph can chain multiple service devices. Traffic flows from the web EPG → through the firewall → then through the load balancer → then to the app EPG. Each device is a separate function node in the same graph template. This is service chaining at its most powerful.

Use Case 4 — Shared Services in Common Tenant

A company runs one shared firewall for all tenants. The L4-L7 Device is defined in the Common Tenant and referenced by Service Graphs in each individual tenant. This avoids duplicating device configuration and allows centralized firewall management.

8. Common Mistakes to Avoid

Mistake	Impact	Correct Approach
Enabling unicast routing on service device BDs when firewall is in transparent mode	Traffic routing bypasses the firewall	Disable unicast routing on BDs for transparent mode firewalls
Wrong function type (Go-To vs Go-Through)	Graph deploys but traffic is not redirected correctly	Match function type to the device's network mode
Not mapping connectors to correct Bridge Domains	Graph deployment fails or traffic loops	Carefully map consumer/provider connectors to separate BDs
Applying graph to wrong Contract direction	Only one-way traffic goes through the service device	Apply graph to the Contract, not just a filter — it applies bidirectionally
Using a managed graph without a device package	Deployment fails with "device package missing" fault	Use unmanaged mode unless you have the correct device package installed
Missing PBR redirect policy on leaf	Graph shows deployed but traffic goes direct	Verify PBR entries with show pbr policy on the leaf

9. Interview Questions and Answers

Q: What is the difference between a Contract and a Service Graph?

A Contract defines whether traffic is allowed or denied. A Service Graph defines the path that traffic must take when it is allowed — through which service devices and in which order. A Service Graph is always attached to a Contract.

Q: Can a Service Graph be reused across multiple Contracts?

Yes. A Service Graph Template is reusable. You can attach the same template to multiple Contracts using separate Device Selection Policies. This is one of the key advantages of the template-based approach.

Q: What is the role of Bridge Domains in a Service Graph?

Bridge Domains provide the Layer 2 stitching between the ACI fabric and the service device interfaces. Each connector on a function node is associated with a Bridge Domain. This allows ACI to extend the fabric logically to the service device without requiring additional physical VLANs to be manually configured on every leaf.

Q: What happens if a Service Graph deployment fails?

The graph enters a "failed" or "incomplete" state. Traffic between the EPGs may be dropped entirely or may bypass the service device depending on the contract configuration. Check faults on the graph instance in APIC and verify connector-to-BD mapping, device package availability, and PBR entries on the leaf.

Q: What is the difference between managed and unmanaged Service Graphs?

In an unmanaged graph, ACI handles only the fabric-side stitching. The service device (firewall, load balancer) must be configured manually. In a managed graph, ACI uses a device package to automatically push configuration to the service device as part of graph deployment. Managed graphs require the correct vendor device package to be installed in APIC.

Q: Can a Service Graph have more than one function node?

Yes. A graph can chain multiple function nodes — for example, a firewall followed by a load balancer. Traffic is redirected through each node in sequence. This is called service chaining.

Q: Where should the L4-L7 Device be defined for a shared firewall used by multiple tenants?

In the Common Tenant. Devices defined in the Common Tenant can be referenced by Service Graphs in any user tenant, enabling a single shared device to serve multiple tenants without duplication.

10. Final Summary

Key Takeaways

• A Service Graph defines the path traffic must take between two EPGs — through firewalls, load balancers, or other service devices
• Service Graphs are attached to Contracts — the Contract permits or denies traffic, the graph defines the path
• ACI uses Policy-Based Redirect (PBR) at the leaf layer to redirect traffic to service devices without requiring inline physical placement
• Choose the correct insertion mode — Go-Through for firewalls, One-Arm for load balancers
• Service Graph Templates are reusable — define once, apply to many applications
• Shared service devices belong in the Common Tenant for multi-tenant environments
• Always verify deployment state in APIC and PBR entries on the leaf after configuring a graph

Service Graphs are one of the features that truly differentiate Cisco ACI from traditional networking. Once you understand them, you realize they eliminate entire categories of operational complexity that have existed in data centers for decades. If you are preparing for a CCIE DC exam or a senior ACI role, mastering Service Graphs is non-negotiable.

Have questions about Service Graphs in your environment? Drop a comment below or reach out at rockingoa@gmail.com — I am available for Cisco ACI and Nexus consulting and freelancing work.

Cisco ACI Service Graph L4-L7 Services Data Center ACI Configuration CCIE DC Network Security Policy-Based Redirect

NL

Networklearner

CCIE Data Center certified engineer with 18+ years of experience in enterprise and data center networking. Specializes in Cisco ACI, Nexus, and data center design. Available for consulting and freelancing.

📧 rockingoa@gmail.com

Related Posts

• Cisco ACI Decommission Only vs Remove vs Secure Remove Explained
• Cisco ACI Leaf Node ID Swap on vPC Pairs — Risks and Steps
• How to Safely Decommission a Leaf Switch in Cisco ACI