The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
In unmanaged mode, Cisco APIC allocates only the network resources for the service graph and programs only the fabric side during graph instantiation. You must configure the unmanaged device in an external application or tool.
When you add an unmanaged network device, Cisco APIC does not require the device package for that device.
For more information about unmanaged mode, see the Cisco APIC Layer 4 to Layer 7 Services Deployment Guide.
For unmanaged devices, the Application Policy Infrastructure Controller (APIC) allocates only the network resources for the service graph and programs only the fabric side during graph instantiation.You cannot configure an unmanaged device in the APIC.
Step 1 | Add an unmanaged device cluster. |
Step 2 | Add at least one concrete device to the unmanaged device cluster.
See Adding a Concrete Device to an Unmanaged Device Cluster. |
Step 3 | For a virtual concrete device, add at least one vNIC to the concrete interface on the device. |
Step 4 | For a physical concrete device, add at least one path to the concrete interface on the device.
See Adding a Path Interface to an Unmanaged Physical Concrete Device. |
Step 5 | Add at least one logical interface to the unmanaged device cluster.
See Adding a Logical Interface to an Unmanaged Device Cluster. |
Step 6 | Create an L4-L7 service graph template with the configuration parameters you want to use for the device cluster. |
Step 7 | Apply the L4-L7 service graph template to configure the device cluster. |
By default, when a device is registered with Cisco APIC, the device is set to be in managed mode. When a device is configured as managed, Cisco APIC manages the device and programs the device during graph instantiation.
Step 1 | Add a managed device cluster. |
Step 2 | Add at least one concrete device to the managed device cluster. |
Step 3 | For a virtual concrete device, add at least one vNIC to the concrete interface on the device. |
Step 4 | For a physical concrete device, add at least one path to the concrete interface on the device.
See Adding a Path Interface to a Managed Physical Concrete Device. |
Step 5 | Add at least one logical interface to the managed device cluster. |
Step 6 | Create an L4-L7 service graph template with the configuration parameters you want to use for the device cluster. |
Step 7 | Apply the L4-L7 service graph template to configure the device cluster. |
A device cluster, also known as a logical device, contains one or more concrete devices that act as a single device. A device cluster has cluster interfaces, also known as logical interfaces, which describe the interface information for the device cluster.
Device clusters can be managed or unmanaged.
When the Application Policy Infrastructure Controller (APIC) renders and instantiates service graph templates, it does the following:
Associates function node connectors with the cluster interfaces.
Allocates network resources for a function node connector, such as VLAN or Virtual Extensible Local Area Network (VXLAN) resources
Programs those network resources onto the cluster logical interfaces
The service graph template uses a specific device that is based on a device selection policy, known as a logical device context.
Each device cluster can have a maximum of two concrete devices in active/standby mode.
A concrete device has concrete interfaces. When a concrete device is added to a logical device cluster, concrete interfaces are mapped to the logical interfaces. During service graph template instantiation, VLANs and VXLANs are programmed on concrete interfaces that are based on their association with logical interfaces.
You can create multiple cluster interfaces on a concrete device and then specify which cluster interface will be used for the connector in the device selection policy. This cluster interface can be shared by using multiple service graph instantiations.
An APIC function profile provides default values for the parameters of a particular function associated with a device package that is managed by Cisco APIC. You can then include one or more APIC function profiles in an L4-L7 service graph template. For example, you can create a function profile that provides default values for the Cisco ASA firewall function.
In Cisco UCS Director, you create APIC function profiles within function profile groups.
Function profile groups organize function profiles to make it easier to identify the profiles that you want to include in a specific service graph template.
![]() Note | Cisco UCS Director supports only the configuration of Cisco ASA devices through APIC function profiles and service graphs. You can create service graph template and function profile with load balancer service. But the parameters that are added for the function profile through individual workflow task, user interface action, and REST API in Cisco UCS Director, are supported for firewall service alone. |
Add one or more APIC function profiles to the function profile group.
![]() Note | Cisco UCS Director supports only the configuration of Cisco ASA devices through APIC function profiles and service graphs. |
Create an APIC function profile group.
Create an APIC firewall policy.
Click View Details and add one or more parameters to the function profile from Function Profile Parameters. After you add the parameters, they are displayed on either L4L7 Function Profile Parameters or Function Profile Function Parameters.
A service graph template contains configuration parameters, which you can specify through one or more of the following:
Device package
EPG
Application profile
Tenant context
You can apply a service graph template to multiple devices and ensure that all of those devices have the same configuration.
A function node within a service graph template can require one or more configuration parameters. You can lock the parameter values to prevent any additional changes.
The values of the configuration parameters in a service graph are passed to the device script within the device package. The device script converts the parameter data to the configuration that is downloaded onto the device.
Create at least one function profile for the function and device.
Depending upon the configuration parameters you plan to use, create the following:
Consumer EPG or external network
Provider EPG or external network
Contract
Device clusters
Cluster interfaces
Bridge domains, if you plan to use a general connector type
Router configuration, if you plan to use route peering
Service graphs identify the set of network or service functions that are needed by an application. You can instantiate service graphs on the ACI fabric through Cisco UCS Director.
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.
A service graph represents the network using the following elements:
Function node—A function node represents a function that is applied to network 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 you configure a service graph, the network services are automatically configured according to the service function requirements in the service graph. This 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 them.
A service appliance (or 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.
For more information about the requirements of service graphs and their deployment, see the Cisco APIC Layer 4 to Layer 7 Services Deployment Guide.
A filter policy is a group of resolvable filter entries. Each filter entry is a combination of network traffic classification properties.
The service graph uses a specific device based on a device selection policy, known as a logical device context.