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
- What is a Service Graph in Cisco ACI?
- Why Service Graphs Matter
- How Service Graphs Work
- Key Components Explained
- Go-To, Go-Through, and One-Arm Mode
- Step-by-Step Configuration
- Real-World Use Cases
- Common Mistakes to Avoid
- Interview Questions and Answers
- 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.
