The Cisco Application Centric
Infrastructure (ACI) treats services as an integral part of an application. Any services that are required are treated as a service graph that is instantiated on the ACI fabric from the Cisco Application Policy Infrastructure Controller (APIC). Users define the service for the application, while service graphs identify the set of network or service functions that are needed by the application.
A service graph represents the network using the following elements:
Function node—A function node represents a function that is applied to the traffic, such as a transform (SSL termination, VPN gateway), filter (firewalls), or terminal (intrusion detection systems). A function within the service graph might require one or more parameters and have one or more connectors.
Terminal node—A terminal node enables input and output from the service graph.
Connector—A connector enables input and output from a node.
Connection—A connection determines how traffic is forwarded through the network.
After the graph is configured in the APIC, the APIC automatically configures the services according to the service function requirements that are specified in the service graph. The APIC also automatically configures the network according to the needs of the service function that is specified in the service graph, which does not require any change in the service device.
A service graph is represented as two or more tiers of an application with the appropriate service function inserted between.
A service appliance (device) performs a service function within the graph. One or more service appliances might be required to render the services required by a graph. One or more service functions can be performed by a single-service device.
Service graphs and service functions have the following characteristics:
Traffic sent or received by an endpoint group can be filtered based on a policy, and a subset of the traffic can be redirected to different edges in the graph.
Service graph edges are directional.
Taps (hardware-based packet copy service) can be attached to different points in the service graph.
Logical functions can be rendered on the appropriate (physical or virtual) device, based on the policy.
The service graph supports splits and joins of edges, and it does not restrict the administrator to linear service chains.
Traffic can be reclassified again in the network after a service appliance emits it.
Logical service functions can be scaled up or down or can be deployed in a cluster mode or 1:1 active-standby high-availability mode, depending on the requirements.
The following figure provides an example of a service graph deployment:
Figure 1. Example Service Graph Deployment
By using a service graph, you can install a service, such as an ASA firewall, once and deploy it multiple times in different logical topologies. Each time the graph is deployed, ACI takes care of changing the configuration on the firewall to enable the forwarding in the new logical topology.
Deploying a service graph requires bridge domains and VRFs, as shown in the following figure:
Figure 2. Bridge Domains and VRFs of a Service Graph
If you have some of the legs of a service graph that are attached to endpoint groups in other tenants, when you use the Remove Related Objects of Graph Template function in the GUI, the APIC does not remove contracts that were imported from tenants other than where the service graph is located. The APIC also does not clean endpoint group contracts that are located in a different tenant than the service graph. You must manually remove these objects that are in different tenants.